从项目记忆、预设提示词、规格驱动开发到多 Agent 与验证闭环，整理一套 Claude Code 的实战方法。重点不是堆工具，而是按任务规模选择流程，并用测试、Diff 和文档约束 AI 输出，让协作可控、可复查。
Claude Code 这类终端里的 AI 编程工具，短会话往往很惊艳：说一句需求，它就能改文件、跑命令、解释报错。但放到真实项目里，问题很快会暴露出来——上下文散落、需求越改越偏、生成代码缺少验证，最后变成“AI 写了不少，人却要花更多时间擦屁股”。
比较稳妥的思路不是寻找某个万能提示词，而是建立一套分层的工作方法：小任务保持轻量，大任务先写规格；把项目约定沉淀成记忆；用图、文档和测试给 AI 划边界。下面这些做法适合 Claude Code，也基本适用于其他 AI 编程工具。
先按任务规模选流程
最容易踩的坑，是用同一套重流程处理所有任务。改一个文案也写规格文档，会浪费时间；跨多个模块的改造只丢一句“帮我实现”，又几乎必然失控。
| 任务场景 | 推荐做法 | 不建议 |
|---|---|---|
| 单文件小改、修错别字、补日志 | 直接描述需求，改完看 Diff、跑相关测试 | 写长规格、拉多个 Agent |
| 涉及 2–5 个文件的功能 | 先让 AI 列影响文件和实施步骤，再分段修改 | 一次性大段生成 |
| 多页面、跨模块、重构 | 规格先行，明确验收标准和任务拆分 | 边写边改、没有回滚点 |
| 不熟悉的仓库 | 先让 AI 画架构图、列入口和调用链 | 直接上手改核心逻辑 |
规格驱动和“直接改”并不是谁更高级，而是适用场景不同。轻量改动追求反馈速度；复杂改动追求可预测性。社区里提到的 spec-kit、OpenSpec 等工具，本质都是把需求、计划和任务拆成可检查的中间产物。选一个顺手的即可，不必同时引入多套流程。
把项目记忆和预设提示词沉淀下来
Claude Code 的记忆机制很适合存放“每次都要重复说”的内容。可以在项目根目录维护 CLAUDE.md，或用 /memory 查看和编辑记忆；新项目也可以用 /init 生成初稿。不同版本命令可能略有差异，以 /help 和官方说明为准。
记忆文件不宜写成百科全书，建议只放四类信息：
- 常用命令：安装、启动、测试、Lint、构建；
- 代码约定：目录结构、命名、错误处理、日志规范；
- 禁区：生成目录、迁移文件、第三方代码不要随意改；
- 完成标准：改完要跑哪些检查，输出哪些说明。
一个简短的例子：
## 项目约定
- 安装：pnpm install
- 测试：pnpm test -- <path>
- 提交前：pnpm lint && pnpm test
- 不要修改 generated/、migrations/、vendor/
- 修改完成后列出改动文件、验证命令和未覆盖的风险
除了记忆，还可以把高频提示词做成仓库内的预设，例如“代码审查”“补测试”“定位线上报错”“生成变更说明”。预设提示词要写清输入、输出格式和边界，比“帮我优化一下”有效得多。记忆和预设都需要定期清理，过时规则比没有规则更危险。
复杂任务先写一页规格，再让 AI 动手
对于跨页面、跨模块的改动，建议先产出一页纸规格，至少包含：目标、用户场景、验收标准、涉及模块、非目标、测试计划。让 AI 先阅读代码并复述理解，确认无误后再进入实现。一个可复用的起手式是：
先不要改代码。阅读相关目录后输出：
1. 涉及哪些模块和文件；
2. 当前调用链和数据流；
3. 实施步骤与风险点；
4. 验收标准和测试建议；
5. 需要我确认的问题。
如果项目结构复杂，可以要求 AI 用 Mermaid 生成架构图、流程图或时序图。图不是为了好看，而是方便人快速检查 AI 是否理解错了调用关系。生成后要对照代码核实，不能把图当成事实。
规格文档也不宜过度膨胀。一次改造控制在能读完的篇幅，任务拆到可独立验证的粒度。社区工作流可以借鉴，但先在小项目里跑通，再决定是否引入团队。
多 Agent、Skills 和插件：少而可控
社区里围绕 Claude Code 已经形成了不少扩展方式：Skills 用来封装可复用流程，子 Agent 用来分工，插件用来连接外部工具。它们能提升效率，但也容易带来三个问题：权限过大、行为不可预测、多个 Agent 同时改代码产生冲突。
比较稳妥的用法是：
- 只安装来源可信、能看懂配置的扩展，先在小仓库试用；
- 给不同 Agent 明确角色，例如“只读分析”“实现”“审查”，不要让所有角色都能随意写文件；
- 需要并行时，用独立分支或独立工作目录，避免互相覆盖；
- 扩展升级后重新检查权限和命令，不盲目跟随最新配置。
对多数日常任务，一个主会话加一次独立审查已经够用。Agent 数量越多，协调成本越高，不一定更快。
用测试、Diff 和审查形成闭环
AI 说“已完成”不等于完成。可靠的闭环通常包括：
- 修 Bug 时先补一个能复现问题的失败测试；
- 让 AI 运行相关测试和 Lint，并贴出真实输出；
- 人看
git diff，重点检查边界条件、错误处理、权限和日志； - 让小 commit 承载单一改动，方便回滚；
- 长会话中及时用
/clear切换任务，必要时用/compact压缩上下文； - 任务结束后把新发现的约定写回记忆，删掉过时条目。
代码审查也可以交给另一个会话完成，提示词要具体：
请审查当前 Diff，只报告会导致错误、数据不一致、安全问题或测试缺失的地方。
按严重程度排序，每条给出文件、原因和建议修改方式；不要重写整个文件。
长任务与环境问题
如果任务需要连续数小时在线运行，或者本地网络经常中断、机器性能不足，可以把执行环境放到长期在线的远程 Mac 上，例如新加坡机房的独享 Mac mini，通过远程连接继续使用 Claude Code。普通短任务本地运行更直接，不必为了追新增加环境复杂度。
一个可落地的日常流程
- 判断任务规模，小改直接做，大改先写规格；
- 更新或检查项目记忆，确认命令和禁区；
- 让 AI 先读代码、列计划和风险，不改文件；
- 分段实现，每段后跑测试、看 Diff；
- 用独立审查会话检查遗漏；
- 小步提交，记录验证结果；
- 把可复用的经验沉淀成预设或记忆。
小结
Claude Code 的效率不取决于提示词有多长，而取决于流程是否匹配任务、上下文是否干净、验证是否到位。记忆解决重复交代，规格解决需求漂移，图和子 Agent 解决复杂结构，测试和 Diff 解决可信度。工具和命令会持续变化，具体用法请以当前版本的 /help 和官方文档为准；先建立自己的检查清单，再逐步引入扩展，通常比堆工具更稳。