委派结果，不指挥步骤
别逐行指挥 AI。描述你要的最终状态，让它自己规划路径、回报取舍。
两种人问 AI 的方式：一种说「第 15 行改成这样、第 20 行那段删了」，另一种说「让这个模块改成支持非阻塞读取，保持接口不变」。前一种把 AI 当打字机，后一种把它当工程师。在 vibe coding 里，后一种对得多。
读完你能回答：
- 为什么逐行指挥既慢又不好？
- 怎么把一个需求写成「描述结果」而不是「描述步骤」？
- 委派结果遇到 AI 跑偏了怎么办？
指挥步骤的问题
- 慢：你给的步骤，AI 照做，但你没比它快，你只是把它的活又复述了一遍
- 丢掉它的长处：AI 的优势是见过大量模式、能选更好的方案；你把它限制在死步骤里，等于把它当打字机
- 你自己已经想死了：逐行指挥意味着方案已经定死，你失去让 AI 给你更优解的机会
委派结果的写法
写「目标 + 约束 + 完成标准」，剩下的路径交给 AI anthropic-sdlc：
| 目标 | 我想要什么最终状态 |
|---|---|
| 约束 | 别碰哪些、采用哪套 |
| 完成标准 | 怎么做算对，可验证 |
| 回报 | 方案差异、取舍，回报给我 |
给它最基本的信息，剩下的规划放手。让它在做之前把「打算怎么做、有哪些取舍」说给你，你再决定放行。这既用了它的探索能力，又保住了你的判断权。
跑偏了怎么办
委派结果不是说撒手不管。跑偏时：
- 先问它为什么这么选，而不是立刻纠正——它可能有你没看到的取舍 google-patterns
- 说目标，不说步骤：「这个结果不是我想要的，我要的是 X 状态」——别把它的路径重写一遍
- 报错就让它自己修：第一次修不好，说结果让它再试
委派的结果由其验收定生死
委派的前提是你前面已经定了「完成标准」。所以这一步落点又回到：结果能不能验证。 能，就放手放得大一点；不能，先回去把标准提出来。
委派要建立在「结果能验收」之上，而「验收结果靠证据」正是下一章主题：审阅 AI 的产出。