CLAUDE.md 让 Claude Code 输出更清晰

Claude Code 默认会尽量完整地回答问题，但在日常开发里，过于完整有时反而会带来几个问题：结论埋得太深、解释太长、操作步骤不够集中、修改后的总结不够稳定。

这个问题不一定需要插件解决。更简单、稳定的方式是：在 Claude Code 的全局配置文件 ~/.claude/CLAUDE.md 中加入一段“输出规范”，让后续所有会话默认按更清晰的结构回答。

适用场景

这篇方法适合以下情况：

• 希望 Claude Code 默认使用中文回答；
• 希望回答先给结论，再给步骤；
• 希望减少大段背景解释和重复内容；
• 希望代码修改后固定说明“改了什么、怎么验证”；
• 不想每次提问都重复写“请按结论/步骤/风险输出”。

如果只是偶尔一次想要结构化回答，直接在 prompt 里临时要求即可；如果是长期偏好，推荐写入全局 CLAUDE.md。

配置文件位置

Claude Code 的用户级全局配置通常放在：

~/.claude/CLAUDE.md

它会作为用户级行为说明被 Claude Code 读取。与项目内的 .claude/ 配置相比，用户级配置更适合放个人偏好，例如语言、回答长度、总结格式和交互风格。

常见作用域可以这样理解：

位置	作用	适合放什么
~/.claude/CLAUDE.md	当前用户全局生效	个人输出风格、默认语言、回答结构
项目内 CLAUDE.md	当前项目生效	项目约定、技术栈、构建命令、代码规范
项目内 .claude/	当前项目 Claude Code 配置	agents、commands、hooks、settings

本文关注的是第一种：用户级全局输出规范。

推荐配置模板

可以把下面内容追加到 ~/.claude/CLAUDE.md。

## Claude Code 输出清晰度规范

### 基本原则

- 默认使用中文回答。
- 结论先行，不要先铺垫背景。
- 优先使用标题、列表、表格、代码块。
- 避免大段连续文字，避免重复表达。
- 不确定时明确写“待确认”，并说明原因，不要猜测。
- 能直接给方案时，不要反复询问。
- 如果需要用户决策，只给少量明确选项，并标出推荐项。

### 默认回答结构

除非用户明确要求自由发挥，否则优先按以下结构输出：

#### 结论
用 1-3 句话给出核心判断。

#### 推荐方案
说明最推荐的做法，以及为什么。

#### 操作步骤
1. 第一步
2. 第二步
3. 第三步

#### 注意事项
- 只列真正重要的风险、限制或前提。

#### 下一步
给出一个明确的下一步动作。

### 技术问题输出规范

当回答代码、排查、架构、配置相关问题时，优先使用：

#### 结论
先说明问题本质或推荐做法。

#### 原因
用简短列表说明依据。

#### 修改建议
- 文件：`path/to/file`
- 修改点：
  - xxx
  - xxx

#### 示例
使用可复制的命令或代码块。

#### 验证方式
说明如何确认结果正确。

### 代码修改后的说明

修改完成后只说明：

- 改了哪些文件
- 改了什么
- 如何验证

不要输出冗长过程日志。

### 回答长度控制

- 简单问题：不超过 5 行。
- 普通技术问题：控制在 3-6 个小节内。
- 复杂问题：可以详细，但必须分层、分标题。
- 如果没有必要，不要解释背景知识；优先给结论和可执行步骤。

一键写入方式

如果本机还没有 ~/.claude/CLAUDE.md，可以先创建目录和文件：

mkdir -p ~/.claude
touch ~/.claude/CLAUDE.md

更推荐先备份，再追加：

mkdir -p ~/.claude/backups
cp ~/.claude/CLAUDE.md ~/.claude/backups/CLAUDE.md.$(date +%Y%m%d_%H%M%S).bak
cat >> ~/.claude/CLAUDE.md <<'EOF'

<!-- READABLE_OUTPUT_START -->
## Claude Code 输出清晰度规范

### 基本原则

- 默认使用中文回答。
- 结论先行，不要先铺垫背景。
- 优先使用标题、列表、表格、代码块。
- 避免大段连续文字，避免重复表达。
- 不确定时明确写“待确认”，并说明原因，不要猜测。
- 能直接给方案时，不要反复询问。
- 如果需要用户决策，只给少量明确选项，并标出推荐项。

### 默认回答结构

除非用户明确要求自由发挥，否则优先按以下结构输出：

#### 结论
用 1-3 句话给出核心判断。

#### 推荐方案
说明最推荐的做法，以及为什么。

#### 操作步骤
1. 第一步
2. 第二步
3. 第三步

#### 注意事项
- 只列真正重要的风险、限制或前提。

#### 下一步
给出一个明确的下一步动作。

### 技术问题输出规范

当回答代码、排查、架构、配置相关问题时，优先使用：

#### 结论
先说明问题本质或推荐做法。

#### 原因
用简短列表说明依据。

#### 修改建议
- 文件：`path/to/file`
- 修改点：
  - xxx
  - xxx

#### 示例
使用可复制的命令或代码块。

#### 验证方式
说明如何确认结果正确。

### 代码修改后的说明

修改完成后只说明：

- 改了哪些文件
- 改了什么
- 如何验证

不要输出冗长过程日志。

### 回答长度控制

- 简单问题：不超过 5 行。
- 普通技术问题：控制在 3-6 个小节内。
- 复杂问题：可以详细，但必须分层、分标题。
- 如果没有必要，不要解释背景知识；优先给结论和可执行步骤。
<!-- READABLE_OUTPUT_END -->