别再一步步教 Claude 写代码了：指挥式 Prompt 实战
前面我们聊了怎么把需求拆清楚（五步拆解 + 原子化开发）、怎么选编排策略（Subagents 还是手动多窗口）、也拿点赞功能跑了一遍完整案例。拆好了、选对了，最后还差一步——你给 AI 的指令本身质量够不够。
同样的任务，同样的 Claude，有人 8 轮对话还在返工，有人 1 轮对话直接交付。差距不在工具，在你写 Prompt 的方式。
这篇文章讲的就是这件事：怎么用一份结构化的指挥简报，让 Claude 一次做对、减少返工。
微操式 vs 指挥式：判断权交给谁
两种写 Prompt 的方式，核心区别在于谁来做判断。
| 微操式 | 指挥式 | |
|---|---|---|
| 谁判断 | 你凭自己的经验 | AI 凭训练数据的积累 |
| 怎么做 | 逐步发号施令，Claude 逐步执行 | 写一份完整指挥简报，Claude 自主规划执行 |
| 判断范围 | 你见过什么、记得什么，就指挥什么 | AI 见过几千万个开源项目，覆盖面广得多 |
举个例子：同样是"补错误处理"——
- 微操式：你凭经验知道要先加 try-catch、再加重试、再对齐错误格式、再补日志——你按这个顺序一步步指挥 Claude。但你可能漏掉了项目里已有的日志工具，因为你的经验里"加日志" = "console.log"。
- 指挥式：你告诉 Claude "查项目现有的错误处理方式和日志工具，保持一致"——Claude 自己去扫项目文件，找到 winston 和统一错误格式，一步到位。它为什么能找到？因为它见过太多项目，训练数据里"项目一般有统一的日志工具和错误格式"这个模式已经刻进去了。
微操式靠人的经验判断，指挥式靠 AI 的训练数据判断。
人的经验受限于你见过的项目、走过的坑；AI 的训练数据是几千万个开源项目喂出来的，覆盖面广得多。当你说"查项目现有规范"的时候，它知道该去哪些目录找、该看哪些文件——这个判断力来自训练数据，不是来自你。
但反过来，你的经验在 AI 不了解的领域更有价值——比如你们团队内部的约定、业务上的特殊逻辑、代码审查时反复强调的偏好。这些东西训练数据里没有，只有你知道。
所以不是"谁比谁强"，而是判断权该交给谁，取决于这个判断依赖的是广度经验还是深度经验。
一个任务，两种做法
我用一个几乎每个后端开发者都做过的事情来演示——给裸奔的服务层函数补上完整的错误处理。先用微操式做，再用指挥式做。做完你就知道差距在哪了。
你不需要跟我用一样的项目，看完之后拿自己的代码试就行。
任务背景
假设你接手了一个项目，有个订单查询函数，长这样：
// src/services/order.service.ts
async function getOrders(userId: string) {
const orders = await prisma.order.findMany({
where: { userId },
orderBy: { createdAt: 'desc' },
});
return orders;
}
问题一眼就看出来了：什么错误处理都没有。 数据库挂了直接抛异常、网络超时没重试、查询结果没判空、错误信息对前端不友好。
你的任务：补上完整的错误处理。
第一遍：用微操式做
大多数人的习惯方式——凭自己的经验判断该做什么，然后一步步告诉 Claude。
第1轮
你：看一下 src/services/order.service.ts 里的 getOrders 函数
Claude：看了，这个函数直接查数据库返回结果，没有任何 try-catch，
如果 Prisma 查询失败会抛出未捕获的异常。
好，它读懂了。你凭经验判断：第一步应该加 try-catch。
第2轮
你：给它加上 try-catch，捕获数据库异常
Claude：加好了，用 try-catch 包裹了 Prisma 查询，
catch 里返回了一个通用的错误信息。
你的经验告诉你：数据库操作需要重试。
第3轮
你：数据库连接失败和网络超时要能自动重试，最多3次
Claude：加了一个简单的重试逻辑，用 for 循环实现了最多重试3次。
第4轮
你：查询结果为空的时候要返回空数组，不要返回 null
Claude：改了，现在查不到数据时返回 []。
到这儿，你的经验用完了。接下来的事情你没想到——但项目里早就有现成的规范。
第5轮
你：错误信息要按项目的统一格式返回
Claude：请问项目的错误响应格式是什么？
你：去 src/utils/error.ts 里看一下
Claude：[看了文件，按格式重新改了错误返回]
你突然想起项目里应该有统一格式——这是返工的开始。
第6轮
你：重试逻辑也要返回统一格式，还有加个日志记录一下重试次数
Claude：[改了重试部分的格式，加了 console.log]
你凭经验加了日志，顺手就写了 console.log——因为大部分项目就是这么干的。但你忘了这个项目用的是 winston。
第7轮
你：项目用的是 winston 做日志，不是 console.log，去看一下 src/utils/logger.ts
Claude：[换成 winston 了]
又返工了。
第8轮
你：补上单元测试
Claude：[写了一组测试用例]
盘点微操式的过程
| 维度 | 微操式 |
|---|---|
| 对话轮数 | 8轮以上 |
| 判断来源 | 你的个人经验——你见过什么、记得什么，就指挥什么 |
| Claude 的角色 | 执行者，只做你说的，视野限于当前指令 |
| 项目规范 | 容易遗漏——你没想起来，它就不会主动去找 |
| 返工原因 | 你的经验覆盖不了项目的全貌，缺什么补什么，补了又发现不对 |
| 核心瓶颈 | 判断权全在你手里，但你的经验有盲区 |
最大的问题不是慢，而是返工。 而且返工的根源很清楚——你凭经验做的判断，受限于你个人见过的项目和走过的坑。项目里有统一错误格式、有 winston 日志工具，但你没想到，Claude 也不会主动找。
微操式下，AI 的训练数据判断力被完全浪费了——它明明见过几千个项目的日志配置，但你没让它去找，它就不会动。
第二遍：用指挥式做
换一种方式——把广度判断交给 AI。
只需要1轮对话
给 src/services/order.service.ts 中的 getOrders 函数补上完整的错误处理：
需要处理的场景：
- 数据库查询失败：自动重试，最多3次，间隔递增
- 查询结果为空：返回空数组而不是 null
- 网络超时或连接异常：归类为可重试错误，走重试逻辑
要求：
1. 查看项目中现有的错误处理方式和日志工具，保持风格一致
2. 错误响应使用项目统一格式，不要自己发明
3. 日志用项目现有的 logger，不要用 console.log
4. 重试时记录每次重试的原因和耗时
5. 写完整的单元测试，覆盖正常查询、空结果、各类异常场景
发出去。等着。
Claude 的执行过程
Claude 收到这个指挥简报后做了什么：
→ 读 getOrders 函数，理解当前逻辑
→ 扫描项目目录，找到 src/utils/error.ts —— 统一错误格式
→ 扫描项目目录，找到 src/utils/logger.ts —— winston 日志工具
→ 基于训练数据的判断：这个项目用了 winston，日志格式应该是……
→ 基于训练数据的判断：错误返回应该走统一格式，不是自己造一个
→ 按项目现有风格实现错误处理 + 重试逻辑
→ 写测试，覆盖正常和异常情况
→ 完成
一轮对话，全部搞定。10分钟以内。
注意关键区别——第2步和第3步，是你微操式里第5轮和第7轮才发现的问题。但指挥式里 Claude 自己找到了，不需要你提醒。为什么？因为你的指挥简报里写了"查看项目中现有的……保持风格一致"，而 Claude 的训练数据里"项目一般有统一的错误处理和日志工具"这个模式已经刻进去了——它知道该去找，也知道去哪找。
把判断权交给 AI 训练数据的效果：你不需要凭经验想到"这个项目可能有 winston"，Claude 自己就会去查。你只负责告诉它"去找"，它负责"找到什么"。
拆解：指挥式 Prompt 每一句在做什么
这个指挥简报不是随手写的，每一句都有明确作用。
① 目标定位
给 src/services/order.service.ts 中的 getOrders 函数补上完整的错误处理：
直接给文件路径和函数名，不说"订单那个函数"这种模糊描述。越精确，理解偏差越小。
② 具体需求
需要处理的场景：
- 数据库查询失败：自动重试，最多3次，间隔递增
- 查询结果为空：返回空数组而不是 null
- 网络超时或连接异常：归类为可重试错误，走重试逻辑
把每个场景的期望行为说清楚。注意"间隔递增"这个细节——如果你只写"自动重试"，Claude 可能给你固定间隔。业务细节越明确，返工越少。
这里你用的是自己的经验——"重试3次、间隔递增、空结果返回空数组"，这些是你的业务判断，训练数据做不了这个主。
指挥式不是把所有判断都交给 AI，而是把广度判断（找规范、找工具）交给 AI，把深度判断（业务逻辑、团队约定）留给自己。
③ 最关键的一句
1. 查看项目中现有的错误处理方式和日志工具，保持风格一致
它把"找规范"这个判断交给了 AI——你不需要知道项目里有没有统一格式、用的是什么日志库，Claude 自己去查。它的训练数据见过太多项目，知道去哪些目录找、该看哪些文件。
微操式里第5轮才发现格式不一致、第7轮才发现日志工具不对——指挥式在一开始就把这类广度判断交给了 AI，直接避免返工。
④ 质量标准 + 约束
2. 错误响应使用项目统一格式，不要自己发明
3. 日志用项目现有的 logger，不要用 console.log
4. 重试时记录每次重试的原因和耗时
5. 写完整的单元测试，覆盖正常查询、空结果、各类异常场景
- "不要自己发明"很管用——Claude 的训练数据里有无数种错误格式，它可能给你搞一套看起来很合理的。明确告诉它不要自创，就用项目里已有的。
- "不用 console.log"是经验兜底——你知道大多数开发者会本能地写 console.log，所以提前排除。AI 的训练数据虽然覆盖广，但在"选最通用方案"这个倾向上反而容易翻车，明确排除才能避免。
- 测试包进需求——微操式里测试是单独一轮对话，指挥式里它是需求的一部分，Claude 在写代码的同时就考虑测试覆盖。
四要素结构，写任何 Prompt 都能用
上面拆解的，其实就是指挥式 Prompt 的通用结构：
| 要素 | 作用 | 谁来做判断 |
|---|---|---|
| 目标定位 | 锁定改什么、做什么 | 你——只有你知道要做什么 |
| 具体需求 | 业务细节、功能要求 | 你——业务逻辑是你的深度经验 |
| 质量标准 | 做到什么程度算完成 | 你定标准，AI 用训练数据去达到 |
| 约束条件 | 不能做什么、必须遵守什么 | 你——排除 AI 训练数据里的"通用但不对"的方案 |
目标定位和具体需求依赖你的深度经验，质量标准和约束条件是你给 AI 训练数据判断力划边界。 指挥式不是让 AI 全权决策，而是你定方向、定边界，让 AI 在边界内用训练数据做广度判断。
再来一个快速对比：
❌ 微操式："帮我优化一下首页的加载速度"
✅ 指挥式："首页加载时间从 3.2s 降到 1.5s 以内（目标 + 质量标准）。
重点检查图片懒加载、API 请求合并、组件按需加载三个方向（具体需求）。
优化后的指标要能在现有的监控面板里看到（约束条件）。
改完跑 Lighthouse，Performance 分数 > 90（质量标准）。"
微操式给了一个模糊方向，Claude 只能凭训练数据猜你要优化到什么程度。指挥式给了精确目标、明确方向和可衡量标准——你的深度经验定方向，AI 的广度经验去执行。
指挥式不是万能的：三个常见翻车场景
翻车1：需求本身是模糊的
"优化一下用户体验"
这种 Prompt，不管是微操式还是指挥式，都做不好。问题不在工具，在于你自己还没想清楚要什么。
解法：先把模糊需求拆成具体问题。"优化用户体验"拆成"注册流程从5步减到3步""表单报错从弹窗改成行内提示""首次加载加骨架屏"——每一个都能用指挥式搞定。
拆需求本身就是深度判断，AI 替不了你。
翻车2：任务之间有强依赖
"先设计数据库表结构，然后基于这个结构写 CRUD 接口，然后写前端页面"
这三步有严格先后依赖：接口依赖表结构，前端依赖接口。放在一个指挥简报里，Claude 可能在表结构还没定的情况下就开始写接口——它的训练数据知道"表结构影响接口设计"，但它不知道你的表结构长什么样。
解法：强依赖的任务拆成2-3轮，每轮内部用指挥式，轮与轮之间你来验收。
第1轮："设计用户模块的数据库表结构，要求……"
→ 你验收表结构（深度判断：表结构是否符合业务需求）
第2轮："基于刚才的表结构，写完整的 CRUD 接口，要求……"
→ 你验收接口
第3轮："基于这些接口，写前端页面，要求……"
这不是退回微操式——每一轮内部，AI 依然用训练数据做广度判断（找规范、选方案）。你只是在关键节点用深度经验做验收。
翻车3：项目本身没有规范可查
如果项目结构混乱（文件随便放、命名不规范、没有文档），指挥简报里写"查看项目现有规范"就落空了——因为 AI 的训练数据再广，也找不到不存在的东西。
解法：直接在指挥简报里给 Claude 必要的上下文，用你的深度经验补位：
"项目的错误处理方式是这样的：[贴一段示例代码]。
新代码按这个风格来。"
更好的做法是先整理项目规范，写进 CLAUDE.md——Claude 每次执行都会自动读取。
把你的深度经验沉淀成文档，AI 的广度判断就有了锚点。
两种方式完整对比
| 维度 | 微操式 | 指挥式 |
|---|---|---|
| 对话轮数 | 8轮以上 | 1-2轮 |
| 判断来源 | 你的个人经验（深度，但有盲区） | 你的深度经验 + AI 的训练数据广度 |
| Claude 的角色 | 执行者，只做你说的 | 规划 + 执行者，在边界内自主判断 |
| 项目规范 | 你没想到，它就不找——遗漏后返工 | 你让它找，它用训练数据去找——一步到位 |
| 测试覆盖 | 你记得就补，忘了就漏 | 写在需求里，同步完成 |
| 总耗时 | 20-30分钟 | 10分钟以内 |
| 返工概率 | 高（经验盲区） | 低（AI 广度补位） |
| 适合场景 | 探索性任务、AI 不了解的领域 | 目标明确的开发任务 |
指挥式不是所有场景都适合。 当任务依赖的是只有你知道的深度经验（团队内部约定、业务特殊逻辑、历史包袱），微操式更可靠——AI 的训练数据里没有这些信息，它做不了这个判断。当任务依赖的是广度经验（找规范、选方案、识别模式），指挥式更高效——你让 AI 去判断，它比你见得多。
小结
- 微操式：你凭经验判断 → 逐步指挥 → 经验有盲区 → 返工多
- 指挥式：你定方向和边界 → AI 用训练数据做广度判断 → 全局理解 → 一步到位
- 核心区别：判断权交给谁——微操式靠人的经验，指挥式靠 AI 的训练数据
- 指挥式 Prompt 四要素：目标定位 + 具体需求 + 质量标准 + 约束条件
- 深度判断留给你（业务逻辑、团队约定），广度判断交给 AI（找规范、选方案）
- 指挥式不是万能的：需求模糊、强依赖任务、项目没规范时要调整策略
