用了一年多 Claude Code，我把自己最近半年的工作流抽出来，写下这 7 条。每一条都是在真实开发过程中感受到痛苦后总结出来的可复用原则。

新手最容易犯的错不是不会用，而是把它当成更聪明的 ChatGPT 用。用对了，它是一个可以被你调教的工程师；用错了，它就是一个有幻觉、会撒谎、会"看起来跑通了但其实没改对"，不叫就不会动的懒虫。

做好下面这 7 条，AI 就是你的最佳拍档。

1. 不要把它当聊天框，把它当成你的同事/下属

想象一下你是 leader，今天你要把一个活派给一个新来的下属。如果你只丢一句"帮我加一个删除功能"就走人——他不知道你删什么、删完之后页面怎么跳、有没有软删除、要不要二次确认、删了之后日志里要不要留痕、哪些用户有权限删……他只能凭自己的想象往下做。最后交付的东西大概率不是你要的。

这不是这位下属能力不行，是你没把任务讲清楚。

AI 完全一样。你丢一句"帮我加一个删除功能"，它没有你脑子里那张完整的产品图，没有你最近一周和 PM 的对话记录，不知道这个项目里"删除"在别的模块是怎么实现的，也不知道你心里期望的验收标准。它只能猜，猜出来的东西大概率不是你要的。

把它真正当成一个新来的同事：

  • 任务目标 —— 这件事做完之后，用户能看到什么、系统会变成什么
  • 详细需求 —— 删什么、怎么删、删完之后跳哪里、有没有软删除、有没有权限校验、要不要确认弹窗
  • 当前项目状态 —— 这个项目用的什么栈、相关模块在哪里、之前类似功能是怎么实现的、有没有可以参考的 pattern
  • 验收标准 —— 哪些测试要跑通、哪些边界要覆盖、跑完测试之前不要停下来

把这四件事讲清楚，他才能给你交付合格的代码。

新手最常见的错误是省了讲清楚的那五分钟，然后花两小时反复纠正它走歪的方向。讲清楚那五分钟从来不是浪费——是整个任务里 ROI 最高的五分钟。

判断你有没有用对的标准：你的鼠标和键盘在变忙还是在变闲？ 用对了应该是越用越闲。

2. 用好 CLAUDE.md，他是 AI 的工程红线

CLAUDE.md 是 Claude Code 必须永远遵守的底线，由于每一次对话都会被加载，所以需要在保持精简的同时讲清楚规则。

  • “每一次对话都会被加载” —— 它占用你宝贵的 context window，写得越长，每一轮对话的成本越高。所以能一句话说清的绝不写三句，能用条目的绝不用段落。

  • “必须永远遵守” —— 它不是建议，是硬约束。所以只写那些你真的希望它每一次都遵守的事，不要写"最好"、“尽量”、“偶尔"这种模糊词。

该写进 CLAUDE.md 的：

  • 工程红线（注释语言、commit 规范、不确定就搜不能猜）
  • 文件产出规则（报告写到哪里、哪些不能生成、测试放在哪里）
  • 响应格式约束（用什么语言、结尾必须带什么结构）
  • 绝对不能做的事（比如禁用 --no-verify、禁止强制提交被 gitignore 的文件）

不该写进 CLAUDE.md 的：

  • 具体代码风格细节 —— 那是 linter / formatter 的活
  • 项目架构背景和业务逻辑 —— 那是 Design Doc 的活
  • 你希望它"偶尔"做的事 —— 写了也不会稳定执行，反而稀释了真正的红线
  • 长段解释和举例 —— 占 token，条目化的祈使句就够

还要分清全局 CLAUDE.md 和项目级 CLAUDE.md 各自该写什么，两边写错地方都是浪费：

  • 全局 CLAUDE.md（~/.claude/CLAUDE.md）写跨项目的个人习惯：注释和 commit 用什么语言、不确定必须先搜、响应格式约束、记忆仓库位置、文件产出规则。这些是**“你这个人”**的规则，换哪个项目都成立。

  • 项目级 CLAUDE.md（仓库根目录）只写这个项目特有的东西：技术栈和版本、测试怎么跑、部署怎么走、哪些目录是禁区、这个项目的 Design Doc 路径。一句话：如果把这条规则挪到别的项目还成立，就不该写在项目级。

一个实操建议：红线是踩出来的，不是想出来的。 新项目第一版的 CLAUDE.md 可以很短，每次它做错一件让你真的生气的事，回来加一条。一个月后你会得到一份只属于你自己的、密度极高的规则文档。

3. 把高频任务封装成 Skill，别每次重新解释

很多人可能都听说过 Skill，但还没有开始使用。Skill 是提高生产力最好用的功能。它本质是"加了入口的 prompt 模板 + 工具白名单”。

举个我自己踩过无数次的例子：写 Design Doc。

每次新项目我都得交代一遍：写到 <memory_root>/docs/design.md、根据项目规模选 Lite 还是 Full 模板、架构图必须从用户入口画起而不是只画后端内部、必须包含 Overview / Ultimate Vision / Tech Stack / Architecture Diagram / Feature Status / Current Milestone / Key Decisions 这几段、没填的段落标 TBD 不要瞎编、已经存在 design.md 就别覆盖改走 update 流程……

这套标准我说烦了。每次复述既浪费 token，又总有哪条漏掉，每个项目的 Design Doc 长得都不一样。

后来我把它打包成 /init-design skill：模板固定、路径固定、规则固定、填充逻辑固定。现在起新项目只需要一句 /init-design 这个项目是 XXX，十秒钟一份符合规范的 design doc 就出来了。

反例：每次新项目重复描述十几条标准，希望 AI 这次别漏。 正例：把标准沉淀成 skill，用的时候只输入 /init-design。

我现在常用的 20+ 自定义 skill：/plan、/build、/debug、/codex-review、/init-design、/update-design、/commit、/contribute、/loop、/schedule……每一个都对应一个你之前会反复打字解释的工作流。

判断该不该做成 skill 的标准：你在重复打之前写过的 prompt 的时候觉得烦吗？ 烦就立刻封装。

4. 建立"记忆仓库"，让上下文跨对话存活

Claude Code 单次对话的 context window 再大也是会清零的。真正让 AI 助理"认识你"的不是 prompt engineering，是一个稳定的、可读可写的、跨对话的记忆系统。

简单的记忆仓库 ~/memory/ 长这样：

  • USER.md —— 你是谁，用户画像
  • NOW.md —— 你正在做什么，每轮对话结束更新
  • docs/INDEX.md —— 项目文档地图
  • daily-logs/ —— 最近 14 天对话日志
  • lessons/ —— 从对话里沉淀的经验教训，hook 自动提炼
  • projects/ —— 各项目的 design.md / plan/

lessons/ 沉淀对话里所有的踩坑过程，记录成可复用的经验文件，保证 AI 不会反复犯同一个错。

每次新对话或 Compact 之后的第一件事：读 NOW.md 恢复上下文。

配合 hook 自动维护，你会发现AI 开始比你自己更记得上周做了什么。

5. 自动化的事交给 Hooks，不要靠 prompt 提醒

CLAUDE.md 里写的"每次都要 X"不可靠，因为模型会忘、会偷懒、会被 context 覆盖。

Hook 是真正在 harness 层执行的 shell 脚本，它不是 LLM 决策的，所以可靠性是 100%。

Claude Code 目前支持 9 个 hook 事件，每一个都是一个你可以插入自动化逻辑的钩子：

  • SessionStart —— 新会话开始时
  • SessionEnd —— 会话结束时
  • UserPromptSubmit —— 用户刚按下回车、还没给模型看到之前
  • PreToolUse —— 模型决定调用某个工具、执行之前
  • PostToolUse —— 工具执行完毕之后
  • Notification —— 系统需要通知用户（比如等待授权）时
  • Stop —— 模型完成一轮回答、停下之前
  • SubagentStop —— 子 agent 停下之前
  • PreCompact —— 上下文即将被压缩、长期记忆要丢失之前

重点是把"该在什么时候做什么"对准"该用哪个 hook"。举几个我实际在用的例子：

  • Stop → 语音播报"这一轮跑完了"，支持自定义播报内容与播报声音，让 Claude Code 真正有人味
  • PreToolUse（Bash）→ 危险命令拦截，扫到 rm -rf /、git push --force 之类的命令先弹出确认
  • PostToolUse（Write / Edit）→ 自动跑 update_docs_index，每次写新文档都自动注册进全局文档索引，下次别的 agent 可以直接查
  • Stop → 自动保存对话日志 + 跑 git status，这一轮改了什么一目了然；同时异步跑一个 extract_lessons 把对话里值得留下的经验提炼进长期记忆
  • SessionEnd → 自动更新 NOW.md，把这一轮对话干了什么总结一下，下次新 session 第一件事直接去读
  • PreCompact → 自动跑 update_user_preference，在 context 被压缩、对话细节要丢失之前，先把"用户这次新暴露出来的偏好 / 踩过的雷 / 被反复纠正的点"提炼出来存进长期记忆

口诀：“自动行为用 hook，灵活判断用 prompt”。 凡是"每次 X 都要 Y"的需求，永远不要写在 CLAUDE.md 里——写到 hook 里去。CLAUDE.md 是规则，hook 才是执行。

6. 文档与验收驱动开发，不是聊天驱动

新手的典型流程：丢一句话 → 看着它写代码 → 发现写歪了 → 让它改 → 又歪了 → 沮丧地关掉。

我的完整流程是三步主线 + 一道收尾：

Design → Plan → Build → Manual Acceptance

每一步各司其职，别混在一起：

  • Design —— High-level 设计。架构、原则、模块边界、数据流、终极目标。不写具体步骤。
  • Plan —— 执行计划。基于 design 拆具体步骤：哪些文件要改、改动顺序、风险点、回滚路径、每一步怎么验。
  • Build —— 按 plan 老老实实执行，不要随意发挥、不要顺手"优化"。
  • Manual Acceptance（手动验收） —— 你是老板，不是软件测试员。你是在验收交付物：打开应用、看看需求是否全部满足，是不是你想要的东西、数据库和日志看一眼有没有明显异常。

每一步结束后都接一道 review 闸门，而且这个 review 直接交给 codex 自动做。 Claude Opus 像部门里的老油条，什么都懂、协作规划能力强、架构能力强，但在执行层面常常偷懒；而 Codex 更擅长代码执行、debug、review 这些活。所以通常把 review 交给 codex：写完 design，codex review；写完执行 plan，codex review；plan build 完之后，codex review；最后你亲自验收。三道闸门全自动，你只在每道闸门之间做决策、在最后做签收。

验收不通过怎么办？ 不要自己去修，也不要只丢一句"报错了你看看"。你是老板，老板的工作是把问题描述清楚、把要求讲明白，然后让下属自己去解决。正确做法是：把完整的 error message 或异常现象原样贴回主对话（别省略、别转述），加一句场景 description（你点了什么、期望是什么、实际是什么），然后明确指令"自己调试、自己修、跑通为止，没跑通不要停"。

然后看着它自己重现、自己加日志、自己定位、自己修、自己再跑一遍。你的角色是老板和裁判，不是陪跑和 QA。

核心原则：让 AI 写你已经想清楚的东西，不要让 AI 替你想清楚。它擅长执行、不擅长定义问题。你的工作是定义问题和验收交付物，中间的所有脏活累活全部外包给 Claude Code。

7. 学会用 Subagent 提高效率，隔离上下文

主对话的 context window 是你最贵的资源。一旦被 200 个文件读、几千行 grep 结果、半本 PDF 塞满，模型就开始"显著变笨"。

Subagent 的核心价值不只是省 token，更重要的是——它跑在完全独立的对话里，看不到你主对话的历史，也不会被你之前的推理带偏。这相当于随时可以叫一个没被你洗脑过的同事来干活。

三个最常见的用法就够你 80% 的场景用了：

把"吵闹"的活外包出去。 跑测试、扫日志、读一堆文档、搜整个 codebase——这些都会产生海量中间数据但你只需要结论。丢给 subagent，它在自己的 context 里跑完，只把一两段摘要回给你，主对话干干净净。

需要独立第二意见时叫一个。 自己写的 design、自己做的 plan、自己改的代码——自己回头审几乎零价值（写的时候觉得对，审的时候还是觉得对）。开一个 subagent 从零看一遍，它没参与前面的讨论，反而能看见主对话看不见的问题。上一条的 codex review 本质就是这个玩法。

异步后台跑长任务，解放你的等待时间。 这是 subagent 最被低估的用法。跑完整测试、build 整个项目、爬一批文档、跑一个大 refactor——这些动辄几分钟甚至半小时的任务，你没必要盯着屏幕等。扔到后台让 subagent 跑，你继续在主对话里设计下一个功能、写下一段文档、改另一个模块。跑完了它会自动回来告诉你结果。一个人同时推进 3 件事，这才是 agent 真正给你的杠杆。按 Ctrl+B 可以随时把当前任务推到后台。

先开始用，按需再回来取

看完这 7 条，你可能会有个冲动：把所有配置一次性都搭起来，CLAUDE.md 写满、skill 写一打、hooks 全开、记忆仓库目录建齐，最后还没开始 Build 就力竭了。

别这么干。

这 7 条不是清单，是参考。你不需要一上来就全部用上——你需要的是先开始用，在真实项目里跑起来，然后等你撞到具体的问题再回来翻这篇文章：

  • 当你发现自己反复在交代同一句话 → 回来看第 3 条，封一个 skill
  • 当你发现 AI 又把上次说过的事忘了 → 回来看第 4 条，建记忆仓库
  • 当你发现自己一直在手动重复同一个动作 → 回来看第 5 条，写个 hook
  • 当你发现 AI 写歪了三次还在歪 → 回来看第 6 条，把流程立起来
  • 当你发现等一个长任务等到烦躁 → 回来看第 7 条，扔后台

每一条配置都应该是被真实痛点拉出来的，不是预防性准备的。提前堆配置只会让你疲惫然后放弃；按需取用才会让你越用越顺。

相信我，认真用一个月之后，你会收获一位得力的超级工程师员工——他知道你的偏好、记得你的项目、跑得动你的流程、能在你睡觉的时候默默把活做完。

而你只需要从今天开始，给他派第一个任务。