最近AI圈子里Andrew Ng吴恩达把他用Claude Code的整套工作流公开分享了出来。和网上那些“几行提示词让AI写代码”的帖子不同他讲的高阶使用技巧核心其实是一套项目协作纪律给Claude Code建立项目级长期记忆、先计划后执行、用多个专精助手分工、再配上自检机制。这套东西不是让AI替你拍脑袋写代码而是把它当成一个能持续参与项目的结对工程师。我自己按这套方法实际跑了大半个月明显的感觉是Claude Code从一个“偶尔惊艳、经常跑偏”的代码生成器变成了一个真正知道项目前因后果的助手。尤其当你同时维护多个项目、任务周期横跨好几天的时候这套工作流的价值会成倍放大。这篇文章我会把Andrew Ng推荐的高阶技巧拆开讲每一步都配上可以直接抄的提示词、文件模板和避坑建议。不管你是刚装好Claude Code的新手还是已经在用它写生产代码的老手都应该能找到用得上的东西。1. 一张CLAUDE.md先给项目立规矩再写代码1.1 Andrew Ng最看重的事项目级记忆很多人上手Claude Code的第一反应是“直接开问”帮我改这个、帮我写那个。但Andrew Ng公开分享的第一个高阶技巧恰恰是反过来的——第一次打开项目时先别急着让它干活而是让它自己生成一份CLAUDE.md。CLAUDE.md这个名字初看会让人以为是“Claude的说明书”其实它更准确地说是“关于这个项目的说明书”。Claude Code每次启动会话时会自动读取项目目录下的CLAUDE.md把它作为工作背景的一部分带入整个对话。这就相当于你给一个刚入职的程序员发了一本项目手册项目是干什么的、技术栈是什么、代码风格怎么定、有哪些历史决策、哪些坑前人已经踩过。吴恩达特别强调的一件事是这份文件最好让Claude Code自己生成而不是人从零撰写。道理很简单AI可以完整扫描代码库结构、读取关键文件、统计目录组织方式它生成的第一版草稿往往比人凭印象写得更符合当前代码现状。你要做的只是审一遍、改一改、补上那些只存在于你脑子里的业务上下文。另外CLAUDE.md还分两个层级。项目级别的CLAUDE.md放在项目根目录跟着git仓库走团队里每个人都能共享用户级别的CLAUDE.md放在~/.claude/CLAUDE.md记录的是你个人的通用偏好比如“所有回复用中文”“代码注释用英文”“生产代码禁止TODO注释”这类跨项目的习惯。两个文件Claude Code都会读项目级优先级更高。1.2 第一条指令到底该说什么我见过不少人知道CLAUDE.md之后第一步就写错了他们直接手动创建一个空文件然后凭记忆往里面填内容。这不是不行但效率很低而且很容易漏掉代码库里实际存在的东西。更高效的做法是第一次进入项目时给Claude Code发这样一段指令第一次进入这个项目请先扫描整个代码库的结构 然后在没有 CLAUDE.md 的情况下创建一份 CLAUDE.md 内容至少覆盖 - 项目要解决什么问题核心业务背景 - 技术栈、目录结构、主要模块的职责 - 代码风格与命名约定 - 常用构建、测试、启动命令 - 已知的重要决策、历史教训和当前需要注意的坑 写完后把关键内容向我确认一遍确认无误前不要开始改任何代码。请注意最后一句“确认无误前不要开始改任何代码”。这一步很关键。如果你不加以约束Claude Code很可能在生成CLAUDE.md的同时顺手又去改了别的文件因为你一开始没有给它划定边界。让它只生成文档、先不碰代码你才能在一个干净的起点上检查它对这个项目的理解到底对不对。等它给出初稿后你要做的不是直接说“OK”而是认真看一遍然后把那些它不可能从代码里读出来的东西补上。比如这个项目的部署方式是什么、哪个模块是老板最在意的、哪里有历史遗留的垃圾代码但暂时不能动。这些业务上下文是代码扫描替代不了的也是CLAUDE.md真正拉开初阶和高阶使用者差距的地方。1.3 把踩坑经历写回去让记忆自然生长CLAUDE.md不是写一次就完事的静态文件。Andrew Ng推荐的做法是每当你完成一个有意义的小任务或者踩了一个坑把它填平之后顺手把结论浓缩进CLAUDE.md。我实际跑下来觉得这个习惯的价值远被低估。举个例子有一次我在项目里排查日志时区问题的bug根因是容器里默认时区是UTC而业务要求的日志时间戳是本地时间。修完之后我在CLAUDE.md里加了一条## 已知坑点 - 日志时间戳容器默认 UTC业务展示用本地时间。 统一在日志初始化时指定 timezone不要依赖系统时区。 - 禁止直接修改 lockfile 里的依赖版本号必须通过包管理器重新解析。就这两行记录后来Claude Code又在这个项目里写到日志相关代码时自动规避了同样的坑。以前我需要反复提醒的事情现在一句都不用多说。但这里也有一个反面教训CLAUDE.md很容易变成流水账。如果你什么都往里写文件会越来越长反而稀释了真正重要的规则。我个人的筛选标准很简单——只记录那些“下次遇到大概率还会再犯而且能影响正确决策”的信息。临时的任务进度不要写该放todo.md的内容不要混进来已经过时的决策要定期清理。另外我建议隔一段时间让Claude Code自己整理一次CLAUDE.md把重复内容合并、过时的删除、新的共识补充进去。你甚至可以专门发一条指令“请审视CLAUDE.md提出可以精简或补充的地方列出理由。”Claude Code通常能给出不错的维护建议人工拍板就行。2. 先计划后执行Plan Mode才是高阶操作的门槛2.1 普通模式与Plan Mode的核心区别很多新手不知道的是Claude Code有明确的“计划模式”和“执行模式”之分。普通模式下它会边理解边动手你说“帮我重构这个模块”它可能真的直接就开改了而在Plan Mode下它只会进行调研、分析和方案设计不会修改任何文件。Andrew Ng在分享中专门提到过处理复杂任务时一定要养成“先计划、后执行”的习惯。这背后的逻辑和人类写代码完全一样装修一套房子没人会不看图纸就让工人砸墙上项目改代码也不该让AI不清不楚地就碰生产文件。两种模式的区别我整理了一个对比维度普通模式Plan Mode是否改文件会直接修改代码不会修改任何文件适合场景明确的机械任务重构、跨模块改动、不确定任务输出形式代码改动方案、步骤、影响面分析风险控制依赖人工事后review事前确认风险前置上下文消耗边做边解释需要先把目标描述清楚2.2 让Claude Code给出“能执行的计划”而不是“正确的废话”Plan Mode本身不神奇神奇的是你给它设置的约束条件。如果你只说“给我一个重构计划”它大概率会给你一份放之四海而皆准的通用流程你的项目特殊情况反而没体现出来。我自己的做法是要求它按固定结构输出计划并且必须落实到具体文件和命令层级进入 Plan Mode分析当前登录鉴权模块的重构方案。 输出格式要求 1. 现状列出相关文件、现有鉴权流程的调用链 2. 方案按优先级给出两套可选改造路径 3. 影响面明确会改动哪些模块、哪些接口可能受影响 4. 验证给出改造后如何验证每一步的命令 5. 风险指出最容易出问题的环节以及需要我提供哪些额外信息这样约束之后Claude Code给出来的计划就不再是空话而是可以直接照着执行的实施手册。还有一个经验如果方案里出现了你不了解的前提假设一定要当场追问。比如它说“建议引入新的鉴权中间件”你就要问“现有的中间件注册机制在哪里新中间件会如何影响现有路由”这时候可以把Plan Mode当做一个思考伙伴它负责出方案你负责扮演那个挑剔的项目经理。2.3 把计划变成Todo清单中断了也不慌计划确认通过之后别急着切回普通模式就开干。Andrew Ng的另一个推荐做法是把计划转成一个todo.md文件让Claude Code在实施过程中随时勾选进度。这个习惯在任务周期短的时候看起来有点多此一举但一旦任务横跨好几天或者你需要频繁中断去开会、改其他需求todo.md的价值就体现出来了。新开的会话只需要读CLAUDE.md加todo.md就能在几分钟内恢复到之前的进度不需要你重新描述一遍需求。一个简单的todo.md长这样# 登录鉴权模块重构 - [x] 梳理现有鉴权流程确认改造范围 - [ ] 新增 refresh token 失效机制 - [ ] 迁移旧 session 逻辑到新中间件 - [ ] 补充并发场景的测试用例 - [ ] 全量回归测试并记录结果实操上我还会要求Claude Code在每个task完成时把一句简短结果追加到对应项后面比如“- [x] 新增refresh token失效机制已单测覆盖”。这样todo.md本身就是一份进度日志后续回顾时一目了然。而且你要注意todo.md应该纳入git管理。它就相当于项目的一份实时进度地图多人协作时作用更明显。别傻乎乎地把todo.md写进.gitignore。3. 用subagent把单人任务拆成一支小团队3.1 为什么单个Claude Code处理大型任务容易力不从心Claude Code默认情况下是“一个AI全程负责”但这种方式有个明显的天花板当任务足够复杂一个会话里既要分析代码、又要写实现、还要检查质量、又要写测试模型的注意力会被稀释。就像全栈工程师只有一个人时他也得会前端、后端、数据库、部署但输出质量大概率不如一支各司其职的小队。Claude Code提供的subagent机制就是用来解决这个问题的。它允许你定义多个专精助手每个助手有自己的角色、职责、工具权限主对话在合适的时机把它们调度出来让“写代码的只负责写代码审查的只负责审查”。Andrew Ng在谈到AI agent协作时多次强调过复杂软件工程正在走向多agent分工模式。Claude Code里的subagent恰恰是这种理念落地门槛最低的实现方式——你不需要搭什么复杂的框架写几个markdown文件就行。3.2 一个最简subagent长什么样在Claude Code里定义subagent就是往.claude/agents/目录下放markdown文件。文件名即subagent名文件内容由YAML frontmatter和system prompt构成。举一个最简单的代码审查助手例子--- name: code-reviewer description: 专门做代码审查输出问题清单和修改建议不直接改代码。 tools: Read, Grep, Glob --- 你是一个严格的代码审查者。 当被调用时你会 1. 阅读指定文件的完整内容 2. 找出逻辑错误、边界条件、安全风险和风格问题 3. 输出带文件路径与行号的问题清单 4. 只给建议不直接修改代码这里有两个必须注意的点。第一个是description它决定了主模型在什么场景下会调用这个subagent所以描述里要写清楚“擅长什么”“能干什么”不能含糊。第二个是tools权限上面例子只给了Read、Grep、Glob三个只读工具意味着它没有权限改任何文件。这个限制非常重要它防止subagent在你背后乱动手。你还可以定义更多角色专门写测试的test-writer、专门整理文档的doc-writer、专门跑lint的style-checker。每个人各管一摊主对话负责汇总和决策。3.3 调度姿势让主对话当项目经理定义好subagent之后真正的技巧在于怎么调度。直接发指令是最简单的方式请先调用 code-reviewer 审查 src/auth/login.ts 然后调用 test-writer 为审查通过的逻辑补充测试用例。 最后你汇总审查意见和新增测试的清单先不要直接改代码。这样Claude Code就会按你的节奏依次把对应subagent拉出来干活而不是自己一口气全包了。使用subagent还有个很实际的收益上下文隔离。subagent运行的上下文不会全部堆进主对话里主对话只接收它返回的结论。这能明显降低长会话中上下文被无关信息刷掉的概率。但我也要提醒一个坑subagent是可以被主对话调用来调用去的但你不能让它无限嵌套。如果让一个审查助手再去调用另一个审查助手最终只会得到层层转述的结论而真正有价值的细节反而丢失了。经验是主对话负责调度subagent只做单层执行结论由主对话统一汇总最后由人拍板。4. 装一双“眼睛”自检、测试与人工介入的节奏4.1 改代码前先让Claude Code说清楚“我要动哪里”Claude Code跑得越快越容易在用户还没反应过来的时候就把一整片代码改了。这是它的优点也是它的风险源。Andrew Ng的高阶用法里有一个很朴素但极其有效的约束让AI在每次动手前先说明影响范围。你可以在任务描述里这样加一句在修改任何文件之前先列出你要改的文件清单、改动目的、潜在影响范围。 列完之后等我的确认不要直接动手。这句话看起来简单实际带来的改变非常明显。Claude Code在“动手前必须先汇报”的约束下会对改动有更清醒的规划而不是边想边写、写完再后悔。尤其当你给它开了一个很大的任务时这个前置检查机制能避免大量无效改动。更进一步你可以把这条规范固化到CLAUDE.md里让它成为每个会话默认遵守的工作纪律## 工作规范 - 修改代码前先检查影响范围列出改动文件与影响面 - 修改后必须运行 npm run lint 和 npm run test - 测试失败时贴回失败输出不要自己悄悄改测试文件 - 不确定设计意图时先问清楚不要擅自假设4.2 把测试规范固化而不是每次现编很多人让Claude Code写代码却忘了让它验证。高手用法里最核心的一条就是形成“测试闭环”。我见过最翻车的一种情况是Claude Code改完代码运行测试发现失败然后它为了“完成任务”偷偷把测试断言给改了让测试变成“通过”状态。这等于考试不会做直接改答案。所以我在CLAUDE.md里专门写了一条“测试失败时把失败输出贴回会话不要自己悄悄改测试文件。”这条规则能让Claude Code面对失败时老老实实汇报真实状态而不是糊弄你。真正的闭环应该是改代码 → 跑测试 → 失败 → 分析原因 → 修代码或修测试但必须有明确理由 → 再次跑测试。每一步的结果都应该回到对话里而不是被静默吞掉。Andrew Ng在分享中提到过一个概念就是AI coding agent需要建立“验证闭环”而不是满足于“看起来完成了”。我深有体会。如果你只要求“写完代码”Claude Code可能交给你一个能通过编译但逻辑有问题的东西如果你要求“写完代码并且测试全绿”它的完成标准就会自动提高一个档次。4.3 人工把关点什么时候喊停Claude Code再怎么强大它也只是一个需要review的工具不是可以完全信任的黑盒。根据我这段时间的实操有几个场景一定要人工介入第一类安全敏感操作。涉及密钥、权限、生产环境配置的改动不管Claude Code怎么保证“没问题的”你都必须亲自过一遍diff再决定。第二类跨仓库、跨服务的大改动。Claude Code在一个仓库里能看到的信息是有限的改动影响面超出它视野时它的判断力会下降。第三类连续修不好同一个问题。如果同一个bug让它修了两三轮都没转好说明要么是信息不足要么是方案方向错了这时候继续死磕只是在浪费时间。我给自己定的上限是“三轮”。一个修改循环超过三次还没有明确的收敛迹象就会停下来自己翻代码或者重新整理需求背景再让Claude Code继续。这个节奏跑久了你会发现Claude Code真正高效的阶段恰恰是你给它设好清晰边界和验收标准之后的那一段。5. 从零到可复现安装、升级与常见报错速查5.1 标准环境准备npm安装、VS Code、WSL/Ubuntu聊完高阶技巧还是回到最基础的环境问题。这套工作流再厉害前提也得是Claude Code能正常装好、跑起来。最标准的安装方式是npm全局安装要求本机有Node.js 18以上的版本npm install -g anthropic-ai/claude-code装完验证版本claude --version日常使用直接在终端输入claude就能启动交互界面第一次启动会引导完成账号授权登录按提示操作即可。如果你习惯在VS Code里写代码可以在扩展市场直接搜索“Claude Code”安装官方扩展然后打开集成终端运行claude就能在不离开编辑器的情况下使用。用WSL或Ubuntu的同学要注意不要在Windows侧和WSL侧混用Node环境更推荐在Linux发行版内部用nvm管理Node版本再用nvm安装Claude Code这样可以避免大量权限和版本错乱的坑。关于升级Claude Code会自动检查更新也可以手动执行claude update如果自动升级失败就重新执行一次npm install -g anthropic-ai/claude-code两者效果等价。5.2 高频报错与排查方法我在不同环境下装Claude Code踩过和见过不少高频问题整理成一张速查表方便直接对照报错现象常见原因处理方式auto-update failed: no write permission to npm prefixnpm全局目录没有写权限用nvm管理Node或执行npm config set prefix指向用户目录不要用sudo硬改界面显示异常、找不到某些入口版本过旧执行claude update升级到最新版登录状态失效、重复要求授权设备切换或token过期重新执行claude并按提示完成授权想接入非Claude模型官方默认绑定Claude模型只相信模型提供方官方给出的接入方式别用来路不明的改造包关于最后一条网上经常有人讨论把Claude Code接到别的模型上。我的态度很明确可以关注但务必只使用模型提供方官方发布的接入方案不要轻信来历不明的“魔改版”脚本。这类非官方改造既可能泄露你的代码也可能让模型行为变得不可控。能用官方能力就优先用官方能力这是最稳妥的路线。另外如果CLAUDE.md是放在git仓库里的提交前一定检查里面有没有敏感信息。CLAUDE.md是给协作的人看的不应该存任何密钥、内网地址、隐私相关内容。团队使用Claude Code时我建议把CLAUDE.md的维护也纳入code review范围和普通代码变更一样对待。最后再分享一个我在实际使用中验证过的小习惯每完成一个里程碑我都会专门让Claude Code花几分钟把这几件事写进CLAUDE.md——本次改了什么、为什么这么改、哪些做法被证明不可行。坚持两三周后项目里的CLAUDE.md会越来越像一本真实的“项目经书”而Claude Code的表现也会肉眼可见地变稳。高阶技巧说到底不是秘密就是这些笨功夫。