把 Claude Code 放进真实开发流程：读代码、修 Bug、补测试、做 Review

第一步：让它读现状，不要急着改#

开场可以这样说：

1
请先阅读这个项目，不要修改文件。
2
目标是理解这个 bug 可能发生在哪里。
3
请告诉我：
4
1. 相关模块和文件。
5
2. 当前数据流。
6
3. 可能的原因。
7
4. 你建议先检查什么。

这一步的价值是把 Claude Code 从“生成代码模式”拉回“工程分析模式”。很多 bug 并不难修，难的是找准位置。

第二步：给它复现信息#

如果你有报错、截图、日志或复现步骤，一次性给齐：

1
复现步骤：
2
1. 登录普通用户账号。
3
2. 打开 /settings/profile。
4
3. 修改头像后点击保存。
5

6
实际结果：页面提示成功，但刷新后头像恢复旧图。
7
期望结果：刷新后仍显示新头像。

如果有日志，贴关键几行即可。不要把几千行日志直接塞进去，可以先让它告诉你需要哪一段。

第三步：让它提出最小修改方案#

在动手前，让 Claude Code 输出方案：

1
请给出最小修改方案。
2
要求：
3
1. 尽量不改变现有接口。
4
2. 不做顺手重构。
5
3. 说明需要补哪些测试。
6
4. 说明可能影响哪些页面。

如果方案里出现“顺便统一重构”“改造整个状态管理”之类的内容，要让它收窄。真实项目里，小而确定的改动通常更容易上线。

第四步：执行并验证#

确认方案后再让它实现：

1
按方案实现。完成后运行相关测试和构建。如果验证失败，先解释失败原因，再继续修复。

你也可以明确验证命令：

1
npm run test
2
npm run build

如果项目很大，不一定每次都跑全量测试。可以先跑相关测试，再在提交前跑完整检查。

第五步：让它做提交前 Review#

改完后，不要马上提交。让 Claude Code review 自己的改动：

1
请 review 当前未提交改动。
2
重点看：
3
1. 是否有行为回归。
4
2. 是否有遗漏测试。
5
3. 是否有无关改动。
6
4. 是否有敏感信息或调试代码。

这个步骤很有用，因为 Claude Code 在“实现模式”和“审查模式”下关注点不同。让它切换视角，经常能发现刚才没注意到的问题。

第六步：整理提交说明#

如果 review 没有问题，再让它生成提交说明：

1
请基于当前 diff 生成一个简洁的 git commit message。
2
格式：
3
第一行不超过 50 个字符。
4
正文说明修改原因和验证方式。

好的提交说明应该解释“为什么改”，而不只是罗列“改了什么”。

推荐模板#

可以把这段保存成自己的常用提示：

1
我们要处理一个真实开发任务。请按以下流程工作：
2
1. 先阅读相关代码，不要修改文件。
3
2. 总结现状、数据流、风险点。
4
3. 提出最小修改方案和验证方式。
5
4. 等我确认后再实现。
6
5. 实现后运行验证命令。
7
6. 最后 review 当前 diff，列出风险和测试结果。

如果你经常使用这套流程，可以把它沉淀成 Claude Code Skill，让它成为团队标准工作流。

适用边界#

Claude Code 很适合帮你推进明确目标的工程任务，但不适合替你拍板模糊的产品决策。涉及安全、计费、权限、数据删除、线上发布时，一定要保持人工确认。

把它当成一个很能干的协作者，而不是无人监督的自动提交机器，效果会更稳定。

参考资料#

• Claude Code 官方文档
• Claude Code GitHub Actions
• Claude Code 团队内部使用指南
• 50 个 Claude Code 日常使用技巧与最佳实践