Claude Code 输出太啰嗦怎么设置：让回复更短、更像工程汇报

Claude Code 用久了，很多人会遇到一个小烦恼：它能干活，但回复太长。

明明只是让它修一个测试，它先解释一遍测试框架，再复述任务，再写一段“我将会”，最后才说改了哪个文件。代码没问题，但阅读成本很高；长会话里还会把上下文塞满，让后续任务更慢、更贵。

解决这个问题不要只靠一句“简洁一点”。更稳的做法是分层设置：临时任务用短提示词，项目长期规则写进 CLAUDE.md，固定风格用 output style 或自定义 slash command，审查和提交这类固定场景则单独规定输出格式。

这篇整理一套实用设置方法，目标是让 Claude Code 的输出更像工程汇报：结论靠前，少铺垫，少复述，只保留必要文件、命令、风险和下一步。

先给结论：用这 4 层控制输出

层级	适合场景	怎么做
临时提示词	当前这一轮太啰嗦	直接要求“只输出结论、改动、验证、风险”
`CLAUDE.md`	当前项目长期偏好	写入简洁输出规则和固定汇报格式
Output style	想全局固定语气和格式	用 Claude Code 的 output styles 定义回答风格
自定义 slash command	代码审查、修测试、提交总结等固定任务	把短输出模板保存成命令

最推荐的顺序是：

先用临时提示词止血；
再把稳定规则写进 CLAUDE.md；
如果每个项目都想保持这种风格，再做 output style；
如果是固定任务，做自定义 slash command。

快速止血：本轮直接这样说

如果 Claude Code 当前已经开始啰嗦，直接发：

1
2
3
4
5
6


后续回复请压缩：
- 不复述我的需求。
- 不写礼貌铺垫。
- 先给结论。
- 只列改动文件、验证命令、结果、风险。
- 没有风险就写“未发现额外风险”。

做代码修改时可以更具体：

1
2
3
4
5
6
7


请用简短工程汇报格式输出：
1. 改了什么
2. 改了哪些文件
3. 跑了什么验证
4. 还有什么风险

不要解释通用背景，不要复述任务。

做排查时：

1
2
3
4
5
6


只输出：
- 最可能原因
- 证据
- 下一步验证命令

不要写长篇分析过程。

这类临时提示词马上生效，但只适合当前会话。长期还是要沉淀到项目规则里。

写进 CLAUDE.md：项目级简洁输出规则

如果你希望当前项目里的 Claude Code 一直少说废话，可以在项目根目录的 CLAUDE.md 加一段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


## Response Style

- Be concise and engineering-focused.
- Do not restate the user's request.
- Do not include generic explanations unless asked.
- Put the result first.
- For code changes, report only:
  1. changed files
  2. behavior changed
  3. validation run
  4. remaining risks
- If no validation was run, say so directly.
- If no extra risk is found, write "未发现额外风险".

中文项目可以写成：

1
2
3
4
5
6
7
8
9


## 回复风格

- 默认用中文，简洁、直接、工程化。
- 不复述用户需求。
- 不写礼貌铺垫。
- 不解释通用背景，除非用户明确要求。
- 修改代码后只汇报：改动文件、行为变化、验证命令、剩余风险。
- 没有运行验证时必须明确说明。
- 没有额外风险时写“未发现额外风险”。

这比每次都说“简洁一点”更稳。

但不要把 CLAUDE.md 写成几百行输出风格大全。它本身也会进入上下文，太长会反过来增加负担。关于提示词和规则文件怎么压缩，可以看：/2026/07/10/ai-coding-prompt-compression-guide/。

用 Output Style：固定回复语气和格式

Claude Code 官方文档提到，output styles 会改变 Claude 的回应方式，例如角色、语气和输出格式。它不是让 Claude 学会新知识，而是改变回复风格。

如果你经常反复要求“简洁、少解释、像工程汇报”，就适合做一个自定义 output style。

一个简洁工程风格可以这样写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Concise Engineering

Respond like a senior engineer giving a short handoff.

Rules:
- Lead with the result.
- Avoid restating the task.
- Avoid generic explanations.
- Use short bullets only when useful.
- For code work, include changed files, validation, and risks.
- If blocked, state the blocker and the next concrete action.
- Keep final answers short unless the user asks for detail.

如果你希望中文输出，可以写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 简洁工程汇报

默认用中文回答，风格像资深工程师交接工作。

规则：
- 先说结果。
- 不复述用户需求。
- 不写通用背景。
- 不写“我将会”这类过程铺垫。
- 代码修改后只汇报改动、验证、风险。
- 遇到阻塞时只说明阻塞点和下一步。
- 用户没有要求长解释时，回答保持短。

注意：output style 更适合控制“表达方式”，不适合塞项目路径、测试命令、禁区文件。这些项目事实仍然应该放在 CLAUDE.md。

用 /config 调整 output style

Claude Code 的命令文档里提到，/config 可以打开设置界面，调整主题、模型、output style 等偏好；较新的版本也支持通过 key=value 形式直接设置部分配置。

因此你可以先在 Claude Code 里输入：

1

/config

然后在设置里查找 output style 相关选项。

如果你的版本支持直接设置，也可以按当前版本提示使用类似方式：

1

/config outputStyle=你的样式名

不同版本的 key 名可能会调整，最稳的是先用 /config 打开界面确认当前可用字段。不要盲目照抄网上某个旧命令。

用自定义 slash command：固定任务固定输出

如果你不是所有回答都想变短，而是某些任务固定要短，比如代码审查、修测试、提交总结，可以用自定义 slash command。

例如创建：

1

.claude/commands/short-review.md

内容：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


只读审查当前改动，不要修改文件。

输出格式：

1. 高风险问题
2. 中低风险问题
3. 缺失测试
4. 结论

规则：
- 每个问题最多 2 行。
- 必须给文件路径。
- 没有问题时写“未发现高风险问题”。
- 不要复述任务。
- 不要写通用审查方法。

之后你只要运行类似：

1

/short-review

就能复用这套短输出格式。

同理可以做：

1
2
3


.claude/commands/short-fix.md
.claude/commands/short-test.md
.claude/commands/short-summary.md

这种方式比每次复制一大段提示词更稳，也更容易团队共享。

代码修改后的推荐输出格式

最实用的是固定最终汇报格式。

可以要求 Claude Code 每次修改后只输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


结果：
- ...

改动文件：
- path/to/file

验证：
- 命令：...
- 结果：...

风险：
- ...

更短版本：

1
2
3
4


改动：...
文件：...
验证：...
风险：...

如果没有验证：

1

验证：未运行，原因是 ...

这比“我已经完成了……这个实现通过……另外……”更好扫。

代码审查时让它少废话

代码审查很容易啰嗦。建议把输出限制得更窄：

1
2
3
4
5
6
7


只读审查当前 diff。

只输出真实问题，不输出优点。
按严重程度排序。
每个问题包含：文件路径、问题、建议。
没有问题就写“未发现高风险问题”。
不要写总结性夸奖。

如果你同时用 Codex 做独立审查，可以把 Claude Code 负责实现，Codex 负责只读 review。三工具分工可以看：/2026/07/10/cursor-codex-claude-code-workflow-division/。

修测试时让它少解释

测试失败时，Claude Code 经常会解释测试框架、推测原因、列很多可能性。可以改成：

1
2
3
4
5
6
7


请修复当前 failing test。

输出限制：
- 不解释测试框架。
- 不复述错误日志。
- 只保留失败原因、改动文件、验证结果。
- 连续失败两次后停止修改，先总结共同原因。

这能减少无效循环。

如果是 token 消耗变高，尤其要控制日志输出。相关排查可以看：/2026/07/08/claude-code-token-usage-spike-troubleshooting-faq/。

不要把所有回答都压到极短

输出太啰嗦要控制，但也不要把 Claude Code 永久压成电报风。

这些场景适合短输出：

bug 修复；
测试失败；
commit 总结；
代码审查；
简单命令解释；
已经明确范围的实现任务。

这些场景不适合太短：

新人学习项目；
架构取舍；
复杂故障复盘；
安全风险分析；
数据库迁移方案；
需求还没澄清。

一句话：执行阶段短，设计阶段可以稍微展开。

和 caveman 这类工具的区别

站内之前写过 caveman，它是把 Claude Code、Codex 等 Agent 的输出压缩成更短风格的 skill / plugin：/2026/07/03/caveman-agent-output-compression-guide/。

本文的方法更基础：

临时提示词控制本轮；
CLAUDE.md 控制项目；
output style 控制整体表达；
slash command 控制固定任务。

caveman 更像现成压缩工具；本文这套更像自己搭规则。你可以先用本文方法，如果仍然觉得输出太长，再考虑专门的压缩工具。

常见误区

1. 只写“简洁一点”

太模糊。Claude Code 可能少写几句，但仍然不知道哪些内容该保留。

更好：

1

只保留：结果、文件、验证、风险。

2. 在每个提示词里重复风格要求

重复多了会污染提示词。稳定规则放进 CLAUDE.md 或 output style。

3. 把项目规则写进 output style

不要这样做。output style 负责语气和格式，项目事实放 CLAUDE.md。

4. 把安全说明也压没了

危险操作、数据库、权限、生产配置、文件删除相关说明不能省。短输出不是少审查。

5. 让它完全不解释

有些任务需要解释。更好的写法是：

1

默认短输出；只有遇到设计取舍、风险或阻塞时再解释。

一套可直接复制的配置

可以把下面这段加入项目 CLAUDE.md：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


## Response Style

- Default language: Chinese.
- Be concise and engineering-focused.
- Do not restate the user's request.
- Do not include generic background unless asked.
- For code changes, report only:
  - result
  - changed files
  - validation
  - risks
- For reviews, list only actionable issues.
- For test failures, summarize the failing cause and next command only.
- If validation was not run, say that explicitly.
- If no risk is found, write "未发现额外风险".

再配一个临时短输出提示：

1
2
3


本轮请使用短汇报格式：
结果 / 文件 / 验证 / 风险。
不要复述任务，不要解释通用背景。

这两段已经能解决大多数“输出太啰嗦”的问题。

总结

Claude Code 输出太啰嗦，不一定要换工具，也不一定要强行压所有回答。先把输出分层控制：当前会话用短提示词，项目长期偏好写进 CLAUDE.md，全局表达用 output style，固定任务用 slash command。

真正好用的设置不是“越短越好”，而是让 Claude Code 在正确时机说正确长度的话：实现和测试汇报要短，架构和风险讨论可以展开。这样既省阅读时间，也能减少上下文噪音。