蓝图优先：把一行目标变成多 Agent 可冷启动的工程计划

有一类工程任务最容易被低估：目标说得清，但执行跨好几个会话、涉及多个 Agent、中间可能要切换人手。你以为一句话能讲清楚，结果下一个 Agent 或下一个会话接手时，先花半小时重建上下文，然后从一个错误的假设出发，把前面的工作踩掉一半。

这不是 Agent 能力的问题，是任务的「携带信息密度」不够——任务本身没有把执行它所需的上下文编码进去。

计划文件是工程产物，不是过渡草稿

一个常见的工作方式是：先做一个粗略的口头计划，然后「直接上」，边做边调整。这在单人、单会话、小任务里没问题。但一旦任务跨越多个会话或需要并行子 Agent，这套方式就会暴露问题——调整的成本比重写还高，因为每个参与者都在凭自己的局部记忆补全信息，容易补出不同的版本。

蓝图方法的前提是把计划文件当作一等工程产物：它不是让自己看的便签，而是让任何人（任何 Agent）读完就能执行的规格文档。这意味着每个步骤至少要包含：

• 上下文简报：这一步为什么存在，它的输入来自哪里，输出给谁用
• 任务清单：具体做什么，边界在哪里
• 验证命令：怎么判断这一步做完了，测试怎么跑，状态怎么检查
• 退出条件：满足什么才能进入下一步，不满足该怎么处理

这四件事都写齐了，步骤就具备了「冷启动能力」——不需要读前面的步骤，不需要记忆会话历史，打开这一步就能执行。

依赖图比执行顺序更重要

大多数人在拆解任务时想到的是「第一步做什么、第二步做什么」，但这样拆出来的计划有个隐患：顺序是根据直觉排的，不是根据实际依赖关系排的，导致本来可以并行的步骤被串行化，或者依赖关系被隐含在执行顺序里而不是显式标注。

蓝图的正确做法是先建依赖图，再从依赖图里推导执行顺序。两个步骤之间的依赖有两种：一种是输出依赖（A 的产物是 B 的输入），一种是文件冲突（A 和 B 改同一批文件，不能并行）。把这两类依赖显式标注出来，你会发现很多任务天然存在可并行的子树——这是可以同时派发多个 Agent 的机会，也是计划整体工期的压缩空间。

依赖图还有另一个好处：它暴露「关键路径」。关键路径上的步骤值得用更强的模型、更细的 spec，因为它一旦出问题，下游全部堵死；非关键路径的步骤可以用更轻量的模型和更粗的验证粒度。

对抗性审查是计划的出厂测试

计划写完之后，最容易犯的错误是自己审查自己的计划。你熟悉目标，你会无意识地填补计划里的空白，以为没问题。

一个健康的做法是在计划定稿前，专门做一轮对抗性审查——用最强的模型（或另一个 Agent）扮演挑剔的审查者，对着一个检查清单质问计划：

• 每个步骤的完成条件是可客观验证的吗，还是靠感觉判断？
• 步骤之间的依赖有没有遗漏？有没有隐含的顺序假设？
• 有没有某一步骤失败后没有回滚路径，直接导致死局？
• 计划的粒度是不是均匀的——有没有某一步突然变成「实现整个模块」？

审查者的职责不是补全计划，而是找出计划在最坏情况下的断裂点。发现问题后回到设计阶段修，而不是带着已知缺陷进入执行。

一句话心法

蓝图的价值不在于「你知道要做什么」，而在于「任何一个全新的执行者打开任意步骤，都能立刻知道做什么、怎么验证、做完了是什么样子」。