阅读时长约12分钟难度★★☆☆☆适合人群看完第01课准备动手试一试的开发者学完之后你能独立用 Director Mode 完成一个真实任务并理解每一步在做什么别再听我讲道理了直接上手第01课我们聊了一堆概念操作者模式、导演模式、AI开发团队……概念听再多不如自己跑一遍。这节课的安排很简单一个任务两种做法你自己感受差距。我会用一个几乎每个开发者都做过的事情——给 API 接口加输入验证——来带你完整走一遍。先用操作者模式做再用导演模式做。做完你就知道差距在哪了。 你不需要跟我用一样的项目。看完这节课之后我会给你三个难度的练习任务你可以在自己的项目里试。任务背景假设你接手了一个后端项目有一个用户注册接口长这样// src/controllers/user.controller.ts exportasyncfunction registerUser(req: Request, res: Response) { const { email, phone, password, nickname } req.body; // 直接存数据库没有任何验证 const user await userService.create({ email, phone, password, nickname, }); return res.status(201).json({ success: true, userId: user.id }); }问题一眼就看出来了什么验证都没有。邮箱格式没验证、手机号没验证、密码强度没验证、昵称长度没验证。这个接口在生产环境上裸奔。你的任务补上完整的输入验证。第一遍用操作者模式做我们先用大多数人习惯的方式——一步一步告诉 Claude 做什么。第1轮对话你看一下 src/controllers/user.controller.ts 里的 registerUser 函数Claude我看了这个函数它接收 email、phone、password、nickname 四个字段直接调用 userService.create 存入数据库。 目前没有任何输入验证。好它读懂了。接着来。第2轮对话你给 email 字段加一个格式验证Claude好的我加了一个正则表达式验证邮箱格式 const emailRegex /^[^\s][^\s]\.[^\s]$/; if (!emailRegex.test(email)) { return res.status(400).json({ error: 邮箱格式不正确 }); }行邮箱好了。下一个。第3轮对话你再加手机号验证要支持大陆手机号Claude好的加了手机号验证 const phoneRegex /^1[3-9]\d{9}$/; if (!phoneRegex.test(phone)) { return res.status(400).json({ error: 手机号格式不正确 }); }第4轮对话你密码要求至少8位包含大小写字母和数字Claude[加了密码验证]第5轮对话你昵称限制2-20个字符Claude[加了昵称验证]第6轮对话你现在帮我写测试Claude好的我给每个验证规则写了测试用例。第7轮对话你等等我看了一下项目里其他接口他们用的是统一的错误响应格式 你没有按那个格式来。改一下。Claude抱歉我来修改。请问错误响应格式是什么样的你在 src/utils/response.ts 里有个 errorResponse 函数 你去看一下按那个格式来。Claude[看了文件重新修改所有验证的错误返回格式]第8轮对话你测试里的错误格式也要同步改Claude[改了测试]盘点一下操作者模式的过程总共对话轮数8轮实际可能更多 你的工作量 ✗ 你自己分解了任务邮箱→手机→密码→昵称→测试 ✗ 你自己决定了验证规则 ✗ 你漏掉了项目规范后面回头返工 ✗ 每一步都要你来发起 耗时大约 20-30 分钟最大的问题不是慢而是返工。因为你一步步给指令Claude 的视野被限制在你当前让我看的这一个文件里。它不知道项目里有统一的错误处理规范直到你第7轮才发现这个问题。第二遍用导演模式做现在我们换一种方式。只需要1轮对话给 src/controllers/user.controller.ts 中的 registerUser 接口 补上完整的输入验证 需要验证的字段 - email标准邮箱格式 - phone中国大陆手机号 - password至少8位包含大小写字母和数字 - nickname2-20个字符 要求 1. 查看项目中现有接口的验证方式和错误响应格式保持一致 2. 验证失败时返回具体的错误信息说明哪个字段有问题 3. 写完整的单元测试覆盖每个字段的正常和异常情况 4. 不要引入新的依赖库发出去。等着。Claude 的执行过程Claude 收到这个 prompt 后它做了什么→ 读 registerUser 函数理解当前逻辑 → 扫描项目里其他 controller 文件看别人怎么做验证的 → 找到 src/utils/response.ts 里的统一错误格式 → 找到 src/middleware/validator.ts如果有的话 → 按照项目现有风格实现四个字段的验证 → 用项目统一的错误响应格式 → 写测试覆盖正常和异常情况 → 完成一轮对话全部搞定。10分钟以内。而且注意——它自己找到了项目的错误处理规范因为你的 prompt 里写了查看项目中现有接口的验证方式和错误响应格式保持一致。你不需要告诉它规范在哪个文件里它自己会去找。拆解导演模式的 Prompt 每一句在做什么我们刚才那个 prompt 不是随手写的。每一句都有明确的作用。我逐句拆给你看给 src/controllers/user.controller.ts 中的 registerUser 接口 补上完整的输入验证→ 定位目标。告诉 Claude 具体改哪个文件的哪个函数。不说用户注册那个接口这种模糊描述直接给路径和函数名。越精确Claude 的理解偏差越小。需要验证的字段 - email标准邮箱格式 - phone中国大陆手机号 - password至少8位包含大小写字母和数字 - nickname2-20个字符→ 定义具体需求。把每个字段的验证规则说清楚。注意中国大陆手机号这个细节——如果你只写验证手机号Claude 可能给你一个国际通用的格式不一定适合你的业务场景。业务细节越明确返工越少。要求 1. 查看项目中现有接口的验证方式和错误响应格式保持一致→ 这是整个 prompt 最关键的一句。它让 Claude 主动去了解项目规范而不是凭空写代码。操作者模式里我们第7轮才发现的格式不一致问题导演模式在一开始就避免了。2. 验证失败时返回具体的错误信息说明哪个字段有问题→ 定义质量标准。不说这句Claude 可能给你一个笼统的参数错误。说了这句它会返回email格式不正确密码强度不足这种具体信息。3. 写完整的单元测试覆盖每个字段的正常和异常情况→ 把测试也包进来。操作者模式里测试是单独一轮对话。导演模式里它是需求的一部分Claude 会在写代码的同时就考虑测试。4. 不要引入新的依赖库→ 设置约束。不说这句Claude 可能给你装一个 Joi 或者 Zod。有时候你就是不想加新依赖——明确告诉它。四个组成部分记住这个结构刚才的拆解其实就是导演模式 Prompt 的通用结构。后面你写任何 prompt都可以用这个框架┌─────────────────────────────────────────────┐ │ 1. 目标定位 │ │ 改什么文件、做什么事 │ ├─────────────────────────────────────────────┤ │ 2. 具体需求 │ │ 业务细节、功能要求 │ ├─────────────────────────────────────────────┤ │ 3. 质量标准 │ │ 做到什么程度算完成 │ ├─────────────────────────────────────────────┤ │ 4. 约束条件 │ │ 不能做什么、必须遵守什么 │ └─────────────────────────────────────────────┘不是每个 prompt 都需要四个部分全写。简单任务可能只需要1和2。但复杂任务这四个要素越完整结果越好。再来一个快速的例子感受一下❌ 操作者模式 帮我优化一下首页的加载速度 ✅ 导演模式 首页加载时间从 3.2s 降到 1.5s 以内目标定位 质量标准。 重点检查图片懒加载、API 请求合并、组件按需加载三个方向具体需求。 查看现有的性能监控配置优化后的指标要能在监控面板里看到约束条件。 改完跑 Lighthouse确认 Performance 分数 90质量标准。看到区别了吗操作者模式给了一个模糊的方向Claude 只能自己猜你要优化到什么程度。导演模式给了精确的目标、明确的方向和可衡量的标准。导演模式不是万能的三个常见翻车场景我不打算只给你看成功案例。导演模式有它不好用的时候你得知道边界在哪。翻车1需求本身是模糊的优化一下用户体验这种 prompt不管是操作者模式还是导演模式都做不好。因为问题不在工具在于你自己还没想清楚要什么。解决方法先跟自己对话把模糊需求拆成具体问题。优化用户体验拆成注册流程从5步减到3步表单报错信息从弹窗改成行内提示首次加载加上骨架屏——每一个都可以用导演模式搞定。翻车2任务之间有强依赖先设计数据库表结构然后基于这个结构写 CRUD 接口然后写前端页面这三步有严格的先后依赖接口依赖表结构前端依赖接口。如果你把它们放在一个 prompt 里Claude 可能会在表结构还没定稿的情况下就开始写接口。解决方法有强依赖的任务拆成2-3轮每一轮用导演模式但轮与轮之间你来验收。第1轮设计用户模块的数据库表结构要求…… → 你验收表结构 第2轮基于刚才的表结构写完整的 CRUD 接口要求…… → 你验收接口 第3轮基于这些接口写前端页面要求……这不是退回操作者模式——每一轮内部Claude 依然是自主规划和执行的。你只是在关键节点做验收。翻车3你的项目 Claude 看不懂如果你的项目结构很混乱文件随便放、命名不规范、没有文档Claude 在查看项目现有规范这一步就会翻车——因为没有规范可查。解决方法这种情况下先给 Claude 必要的上下文项目的错误处理方式是这样的[贴一段示例代码]。 新代码按这个风格来。后面第04课会教你用 CLAUDE.md 一次性解决这个问题——把项目规范写进一个文件Claude 每次都会读。两种模式的完整对比我把刚才的体验整理成一张表方便你回头查阅操作者模式 导演模式 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 对话轮数 8轮以上 1-2轮 你的角色 任务分解者 目标定义者 Claude 的角色 逐步执行者 自主规划执行 项目规范 容易遗漏后期返工 prompt里要求一开始就对齐 测试覆盖 经常忘记补做 写在需求里同步完成 总耗时 20-30分钟 10分钟以内 返工概率 高视野受限 低全局理解 适合场景 探索性任务、学习阶段 目标明确的开发任务注意最后一行导演模式不是所有场景都适合。当你自己还不确定要做什么、需要边做边想的时候操作者模式反而更合适——它让你一步步探索。导演模式要求你在下 prompt 之前就想清楚目标如果目标本身不清楚它无处发力。课后实操轮到你了看完不练等于没看。现在打开你自己的项目从下面三个任务里选一个试试。 入门难度加一个输入验证跟刚才的案例一样在你项目里找一个缺少验证的接口用导演模式补上。Prompt 模板给 [文件路径] 中的 [函数名] 补上输入验证 需要验证的字段 - [字段1][规则] - [字段2][规则] 要求 1. 查看项目现有的验证方式和错误处理规范保持一致 2. 验证失败返回具体的字段级错误信息 3. 写完整的单元测试 进阶难度给现有功能加日志找一个核心业务函数用导演模式给它加上完整的日志。Prompt 模板给 [文件路径] 中的 [函数/模块] 加上完整的操作日志 日志需要覆盖 - 关键操作的入参和出参 - 异常情况的详细信息 - 性能关键节点的耗时记录 要求 1. 查看项目现有的日志工具和格式规范 2. 日志级别要合理info/warn/error 3. 不能在日志里暴露敏感信息密码、token等 4. 不影响现有功能和性能 挑战难度写一个新的工具函数项目里有没有你一直想封装但没时间做的公共函数现在试试。Prompt 模板在 [目标目录] 下创建一个 [功能描述] 的工具函数 功能要求 - [具体功能1] - [具体功能2] 要求 1. 查看项目现有的工具函数风格[工具函数目录]保持一致 2. 完整的 TypeScript 类型定义 3. 处理所有边界情况 4. 写单元测试覆盖正常和异常场景 5. 在 [需要用到的文件] 中把旧的实现替换成新的工具函数做完之后问自己三个问题Claude 的实现跟你项目的现有风格一致吗如果不一致说明你的 prompt 里查看现有规范这句可能不够具体下次可以指明具体看哪个文件。有没有你没想到、但 Claude 替你考虑了的细节比如边界情况、错误处理、类型定义。这就是导演模式的价值——Claude 的视野比你一步步指挥时更广。哪个部分 Claude 做得不对记下来。第04课我们会专门讲怎么写 CLAUDE.md 把你的规范固化下来减少这种偏差。本课小结操作者模式你分解任务→你逐步指挥→容易遗漏规范→返工多导演模式你定义目标→Claude 自主执行→全局理解→一步到位导演模式 Prompt 四要素目标定位 具体需求 质量标准 约束条件导演模式不是万能的需求模糊、强依赖任务、项目结构混乱时要调整策略最重要的你得自己试一遍。光看不练什么模式都没用下一课预告第03课Prompt 的结构化思维这节课我们用了一个四要素框架来写 prompt。但说实话这只是最基础的结构。下一课我们会深入讲怎么根据不同类型的任务Bug修复、功能开发、代码审查、性能优化……来调整 prompt 的侧重点。配10组真实的正反对比案例每组你都可以直接拿去改成自己项目的版本。本课是《Claude Code 从入门到精通》合集第2课。完整合集包含 16 课系统教学 10 个场景 Prompt 模板 3 个完整项目案例。推荐阅读CLAUDE.md 不是给人看的说明文档而是给 Claude 用的项目级配置文件。理解这个区别是用好 Claude Code 的第一步。我把过去半年用 Claude Code 做内容型项目踩过的坑、总结出的方法写成了一本完整的实战手册包含 6 篇深度正文 14 份可直接复制使用的模板《CLAUDE.md 与内容型知识库项目协作实战手册》小册介绍这本手册解决什么问题第 1 篇重新理解 CLAUDE.md——它不是文档而是项目协作的配置中枢第 2 篇从零搭建——一份内容型知识库项目的 CLAUDE.md 实战编写第 3 篇规则分层——用 docs/ 文档体系实现渐进披露第 4 篇内容即数据——frontmatter 规范、数据结构与构建链路的工程化设计第 5 篇让 Claude 少犯错——验证机制、测试策略与发布检查清单第 6 篇从文件到系统——CLAUDE.md 与 hooks、subagents 的协作升级附录篇全套模板汇总 一周落地计划 常见问题正在编写中如果你正在用 Claude Code 做内容站、知识库或文档型项目这本手册能帮你少走很多弯路。