跳到主要内容

输出风格

让 Claude Code 说你的话​

输出风格配置是让 Claude Code 更好服务你的秘密武器。就像调试一个得力助手的沟通方式，通过精心配置输出风格，你可以让 AI 的回答更符合你的工作习惯、团队文化和项目需求。

为什么需要定制输出风格？​

默认风格的局限性​

# Claude Code 的默认输出风格
🤖 标准化 - 适合大多数用户，但不够个性化
📚 详细解释 - 有时太冗长，影响效率
🎯 通用建议 - 缺少项目特定的优化
💬 正式语调 - 可能不符合团队文化

定制风格的好处​

# 定制输出风格的价值
⚡ 提高效率 - 获得直接可用的答案
🎨 风格一致 - 与团队代码风格匹配
🧠 认知适配 - 符合个人思维模式
📋 格式标准 - 满足项目文档要求

输出风格的维度​

1. 详细程度 📊​

控制输出信息的丰富程度：

# 简洁风格
> 修复登录bug

AI回答：

检查 AuthService.validateToken() 方法， token 过期判断逻辑有问题。

修改第47行：

  • if (token.exp > Date.now())
  • if (token.exp * 1000 > Date.now())

# 详细风格  
> 修复登录bug

AI回答：

问题分析​

登录状态丢失通常由以下原因造成：

  1. JWT token 过期判断错误
  2. 前端存储清理不当
  3. 服务端验证逻辑问题

根因定位​

检查 src/services/AuthService.ts:47 发现 token.exp 是秒级时间戳，但 Date.now() 返回毫秒

解决方案​

修改时间戳比较逻辑：

  • if (token.exp > Date.now())
  • if (token.exp * 1000 > Date.now())

验证步骤​

  1. 清除localStorage
  2. 重新登录测试
  3. 等待token过期自动测试

2. 代码风格 💻​

匹配项目的编码规范：

// 函数式风格偏好
const getUserProfile = async (userId) => {
  const response = await api.get(`/users/${userId}`);
  return response.data;
};

// 面向对象风格偏好
class UserService {
  async getUserProfile(userId) {
    const response = await this.api.get(`/users/${userId}`);
    return response.data;
  }
}

// TypeScript 严格类型风格
interface UserProfile {
  id: string;
  name: string;
  email: string;
}

const getUserProfile = async (userId: string): Promise<UserProfile> => {
  const response = await api.get<UserProfile>(`/users/${userId}`);
  return response.data;
};

3. 语言风格 🗣️​

调整沟通的语调和措辞：

# 正式技术风格
> "基于现有架构，建议采用工厂模式实现用户认证模块的扩展性..."

# 轻松对话风格  
> "这里用个工厂模式比较合适，这样以后加新的登录方式会很方便..."

# 直接实用风格
> "用工厂模式。参考 src/auth/AuthFactory.ts 的实现。"

# 教学解释风格
> "我们来用工厂模式解决这个问题。工厂模式的核心思想是..."

4. 输出格式 📋​

定制信息的组织结构：

# 问题解决型格式
## 问题
用户登录后状态不一致

## 原因  
Redux store 初始化时机问题

## 解决方案
[具体代码和步骤]

## 测试方法
[验证步骤]

---

# 代码审查格式
### ✅ 优点
- 错误处理完善
- 类型定义清晰

### ⚠️ 建议改进
- 可以提取重复逻辑
- 考虑添加单元测试

### 📝 具体修改
[代码修改建议]

---

# 快速参考格式
**命令**: `npm run build`
**作用**: 构建生产版本
**注意**: 需要先设置环境变量
**相关**: build.sh, webpack.config.js

配置输出风格​

1. 在 CLAUDE.md 中配置 🛠️​

# CLAUDE.md 输出风格配置

## 输出偏好
- **详细程度**: 简洁实用，避免冗长解释
- **代码风格**: TypeScript + 函数式 + React Hooks
- **语言风格**: 直接、技术导向，少用"建议"多用"应该"
- **错误处理**: 必须包含完整的错误处理代码
- **测试要求**: 每个功能都要给出测试示例

## 输出格式模板
```bash
## 解决方案
[核心代码]

## 关键要点
- 要点1
- 要点2

## 验证方法
[测试步骤]

团队规范​

  • 使用 ESLint + Prettier
  • 组件使用 PascalCase
  • 常量使用 UPPER_SNAKE_CASE
  • 文件名使用 kebab-case

### 2. 实时风格调整 ⚡

```bash
# 在对话中动态调整风格

> 接下来的回答请用简洁风格，只给核心代码，不要解释

> 切换到教学模式，详细说明每一步的原理

> 用我们项目的代码风格，参考 src/components/UserCard.tsx

> 按照我们的 commit message 格式：feat/fix/docs + 详细描述

3. 角色和场景定制 🎭​

# 不同场景的风格配置

## 代码审查场景
> 你是一个经验丰富的 Senior Developer，正在进行代码审查。
> 关注：安全性、性能、可维护性
> 风格：犀利但建设性，指出问题并给出改进建议

## 新手指导场景  
> 你是一个耐心的技术导师，正在指导初级开发者。
> 关注：基础概念解释、最佳实践、避免常见陷阱
> 风格：友好、详细、循序渐进

## 紧急修复场景
> 你是生产环境故障处理专家，时间紧迫。
> 关注：快速定位、立即解决、后续改进
> 风格：简洁、直接、行动导向

高级风格定制​

1. 项目特定风格 🏗️​

# 针对不同项目类型的风格调整

## React 项目风格
- 优先使用 Hooks 而非 Class 组件
- 状态管理优先使用 useState 和 useReducer
- 样式使用 styled-components 或 CSS modules
- 测试使用 React Testing Library

## Node.js API 项目风格
- 使用 Express + TypeScript
- 错误处理必须包含适当的 HTTP 状态码
- 数据验证使用 Joi 或 Yup
- 日志记录使用 Winston

## 全栈项目风格
- 前后端类型定义共享
- API 设计遵循 RESTful 规范
- 数据库操作使用 Prisma 或 TypeORM
- 部署考虑 Docker 容器化

2. 团队文化适配 👥​

# 不同团队文化的风格调整

## 严谨型团队
- 强调类型安全和错误处理
- 详细的文档和注释要求
- 完整的测试覆盖
- 规范的代码审查流程

## 敏捷型团队
- 快速迭代和原型验证
- MVP 优先，后续优化
- 灵活的技术选择
- 持续集成和部署

## 创新型团队  
- 新技术和实验性方案
- 性能和用户体验优先
- 创造性解决方案
- 技术前瞻性考虑

3. 个人习惯适配 🎯​

# 个人开发习惯的风格定制

## 视觉型学习者
- 使用图表和代码示例
- 结构化的信息呈现
- 突出关键概念
- 提供视觉化的流程图

## 实践型学习者
- 直接给出可执行代码
- 提供完整的实现示例
- 包含测试和验证步骤
- 分步骤的操作指南

## 分析型学习者
- 详细的原理解释
- 多种方案的对比分析
- 决策的理由和权衡
- 深入的技术细节

输出风格模板库​

模板 1：快速解决方案​

## 🎯 问题：`[问题描述]`

### 解决方案
```{语言}
{核心代码}

验证​

{测试命令}

相关文件​

  • [文件1] - [作用]
  • [文件2] - [作用]

### 模板 2：详细技术分析

```markdown
## 📊 技术分析：`[主题]`

### 现状评估
- **问题点1**：`[描述]` 
- **问题点2**：`[描述]`

### 解决方案对比
| 方案 | 优点 | 缺点 | 适用场景 |
|------|------|------|----------|
| A | `[优点]` | `[缺点]` | `[场景]` |
| B | `[优点]` | `[缺点]` | `[场景]` |

### 推荐方案
**选择**：`[方案名称]`
**理由**：`[详细理由]`

### 实施计划
1. `[步骤1]`
2. `[步骤2]`
3. `[步骤3]`

模板 3：代码审查反馈​

## 🔍 代码审查：`[文件名]`

### ✅ 做得好的地方
- `[优点1]`
- `[优点2]`

### ⚠️ 需要改进
- **`[问题1]`**：`[具体描述]`
  ```{语言}
  // 修改建议
  [改进代码]
  • [问题2]：[具体描述]

🚀 优化建议​

  • [建议1]
  • [建议2]

📋 检查清单​

  • 单元测试覆盖
  • 错误处理完善
  • 性能优化确认
  • 安全性检查

## 动态风格切换

### 场景感知切换 🎬

```bash
# Claude Code 根据上下文自动调整风格

# 当检测到错误信息时 → 故障排除风格
> 自动提供：问题定位 + 快速修复 + 预防措施

# 当涉及架构设计时 → 设计思考风格  
> 自动提供：方案对比 + 权衡分析 + 最佳实践

# 当处理性能问题时 → 优化专家风格
> 自动提供：性能分析 + 具体优化 + 验证方法

# 当涉及安全问题时 → 安全专家风格
> 自动提供：漏洞分析 + 修复方案 + 安全检查

用户反馈学习 📈​

# 基于用户反馈调整风格

用户：> "太详细了，能简洁一些吗？"
Claude：> 切换到简洁模式，后续回答将更直接

用户：> "能解释一下原理吗？"  
Claude：> 切换到教学模式，增加原理解释

用户：> "按我们项目的代码风格来"
Claude：> 参考 CLAUDE.md 配置，应用项目特定风格

最佳实践​

✅ 高效风格配置​

  1. 明确需求 - 清楚定义你想要的输出类型
  2. 迭代优化 - 根据实际使用效果调整配置
  3. 团队一致 - 团队项目使用统一的风格配置
  4. 场景适配 - 不同任务使用不同的风格模式

❌ 要避免的误区​

  1. 过度定制 - 不要让风格配置变得过于复杂
  2. 忽视反馈 - 不根据实际使用效果调整
  3. 一成不变 - 不同项目阶段需要不同风格
  4. 风格混乱 - 在同一个对话中频繁切换风格

记住：好的输出风格配置能让 Claude Code 成为你的完美搭档。花时间调试风格配置，就像调试一个新团队成员的工作方式 - 磨合期的投入会带来长期的效率提升。

继续探索：排列组合框架 - 学习如何系统性地探索解决方案空间。