Claude Code 日常使用 SOP

把每天使用 Claude Code 的动作固定成一个稳定流程：先开场、再只读分析、再计划、再执行、再验收、最后收尾。

每天打开 Claude Code 后，不要直接说“帮我改一下”。先把任务带进一个固定流程，CC 的输出会稳定很多。

开场确认 -> 只读分析 -> 计划拆分 -> 小步执行 -> 运行验证 -> 审查收尾 -> 记录经验

SOP 的目的不是把使用变复杂，而是让每次任务都有边界、有检查、有收尾。越是熟练，越应该让流程自动化，而不是靠临场感觉。

第一步：开场先定边界

开始任务时，先告诉 CC 当前任务的目标、范围和禁止事项。

不要这样说：

帮我优化一下这个项目。

更稳的说法是：

请先只读分析当前项目，不要修改文件。

目标：
我想了解这个项目的页面结构、启动方式和主要风险。

请输出：
1. 项目技术栈。
2. 主要目录分别负责什么。
3. 常用启动和检查方式。
4. 你认为后续改动最容易出风险的地方。
5. 下一步建议先做哪一个小任务。

这一步的重点是：先让 CC 建立项目地图，而不是让它马上动手。

真实项目里，最危险的不是 CC 不会写代码，而是它在不了解上下文时写得太快。

常用开场模板：

请进入只读分析模式。

本轮不要修改任何文件，不要运行会改动文件的命令。

请先阅读与【任务名称】相关的文件，并回答：
1. 当前实现在哪里。
2. 数据或状态从哪里来。
3. 哪些文件可能需要改。
4. 哪些地方不应该碰。
5. 最小修改方案是什么。

只要任务不是纯文案，建议都先用这一步。

计划不是一句“我会修改 A、B、C”。一个合格计划要包含：

可以直接这样要求：

请把计划改成可验收版本。

每一步都要包含：
1. 要做什么。
2. 为什么需要做。
3. 涉及哪些文件。
4. 完成后怎么验证。

如果某一步无法验证，请拆小或先不做。

计划写不清楚时，不要批准执行。

CC 很擅长一次性改很多文件，但日常使用不应该追求“一口气做完”。

建议按这个节奏推进：

可以这样对话：

先只执行计划里的第 1 步。

要求：
1. 不要顺手做第 2 步。
2. 修改完成后暂停。
3. 汇报改动文件和改动原因。
4. 说明我应该怎么验收这一步。

这样做会慢一点，但可控很多。

CC 说“已完成”不等于任务真的完成。验证时要看三件事：

可以直接让 CC 用固定格式收尾：

请做本轮验证总结。

请输出：
1. 已执行的检查。
2. 每个检查的结果。
3. 没有执行的检查，以及原因。
4. 还需要人工确认的地方。
5. 是否可以进入代码审查。

如果它没有跑检查，也要明确写出来，不能用“看起来没问题”代替验证。

写完之后，应该让 CC 切换成审查视角。

请用代码审查视角检查刚才的改动。

重点看：
1. 是否有无关文件被修改。
2. 是否超出原始任务范围。
3. 是否有潜在兼容性问题。
4. 是否遗漏边界情况。
5. 是否需要补充测试或文档。

请先列问题，不要先总结优点。

审查阶段不是让它夸自己，而是让它找风险。

任务完成后，不一定每次都要更新 CLAUDE.md。只有长期有效的项目规则才应该沉淀。

适合沉淀的内容：

不适合沉淀的内容：

收尾模板：

请判断本次任务是否有值得沉淀到项目记忆的内容。

要求：
1. 只列长期有效的信息。
2. 不要记录临时任务细节。
3. 不要写入密钥、账号、Token。
4. 如果没有值得沉淀的内容，请直接说明不建议更新。

请按“只读分析 -> 计划 -> 小步执行 -> 验证 -> 审查 -> 收尾”的流程处理这个任务。

本轮先不要修改文件，先告诉我你理解的目标、范围、风险和建议计划。

这句话适合绝大多数日常任务。