AI-Native 软件工程(7):Planner Layer——AI 系统为什么需要＂规划能力＂

上一篇我说 Intent 是方向盘，Planner 是导航。

今天展开这个导航。

---

先讲一个真实场景。

有一次我让 AI 实现一个完整的"文章发布"功能。Intent 写得挺清楚的：支持富文本编辑、自动保存草稿、封面图上传、标签选择、定时发布、发布后推送通知。约束也给了：用现有的 tRPC 接口风格，前端 React + TipTap 编辑器，后端 Node.js。

AI 开始干活了。

它给我一口气生成了一个巨大的 Pull Request。3000 多行代码，一个文件里同时包含了编辑器组件、草稿自动保存逻辑、图片上传服务、标签管理接口、定时任务调度、推送通知集成。所有东西揉在一起，像一块巨大的意大利面条。

代码能跑吗？大部分能。但我根本没法 review。我也没法只合其中一部分。更别说测试了——你要怎么给一坨揉在一起的代码写单元测试？

这是没有 Planner 的典型结果。

---

问题不在 AI 的能力。AI 完全有能力分步骤完成这些子任务。问题在于，没有人告诉它应该分步骤。

当你给 AI 一个大的 Intent，它默认的策略是一次性解决。因为从模型的角度看，它的任务是"生成满足要求的输出"。它不会自己想："这个需求太大了，我应该先做数据模型，再做接口，最后做前端。" 它也不会想："图片上传和标签管理是两个独立功能，我应该分开实现。"

这些判断需要一个额外的层来做。这就是 Planner。

---

Planner 的职责可以用三个词概括：拆解、排序、定义。

拆解是把一个大 Intent 分成若干个子任务。每个子任务应该足够小，小到可以被一个 Skill 独立完成，也小到可以被独立验证。

排序是定义这些子任务的执行顺序。哪些有前后依赖——数据模型必须在接口之前，接口必须在前端之前。哪些可以并行——图片上传和标签管理互不依赖，可以同时做。

定义是明确每个子任务的输入和输出。第一个子任务的输出是什么格式？第二个子任务需要从哪里拿到这些数据？如果第三个子任务失败了，需要回退到哪一步？

这三件事听起来很简单。但如果你试过在真实项目里做 AI 工程，就知道——90% 的混乱都来自这三件事没做好。

---

回到刚才那个文章发布的例子。如果有 Planner，流程会变成什么样？

Planner 接收到 Intent 之后，先做拆解：

然后排序：1 是所有的前置。2 依赖 1。3、4、5 可以并行，都依赖 2。6 依赖 2 和状态机定义。7 依赖 6。8 依赖 2、3、4、5。

最后定义：每个子任务的输入是什么（上一步的产出），输出是什么（文件列表 + 测试），验收条件是什么（测试通过 + 类型检查通过）。

整个计划形成一张有向无环图。Engine 按图调度，每一步独立执行、独立验证。失败了只需要重试那一步，不需要推倒重来。

---

有人可能会问：这些不就是工程师本来就在做的事吗？任务拆解、排优先级、定依赖——这些是软件工程的基本功啊。

没错。Planner 做的事情，本质上就是工程师做的事情。

区别在于两点。

第一，频率。传统流程里，一个工程师一天可能只做一两次任务拆解。AI-Native 流程里，每一个 Intent 进来都需要一次拆解。如果系统每天处理 50 个 Intent，就需要 50 次拆解。靠人做不现实，必须让系统来做。

第二，一致性。人做任务拆解，水平参差不齐。有经验的工程师拆得好，没经验的工程师拆得差。今天状态好拆得细，明天赶工拆得粗。Planner 可以保证每次拆解都遵循同样的规则和标准——虽然不一定比最优秀的工程师好，但能保证不低于及格线。

---

在实际实现层面，Planner 的产出通常是一个结构化文档。

我在自己的项目里用的是 Spec + tasks.md 的模式。Spec 描述整体方案和约束，tasks.md 是一个按依赖排序的任务列表，每个任务标注状态（pending / in_progress / done / failed）、依赖关系、对应的 Skill、预期输出。

Engine 读取 tasks.md，按顺序调度执行。某个任务完成了，标记 done，解锁下游任务。某个任务失败了，标记 failed，阻断下游依赖链，反馈错误给 Retry 机制。

这套机制不复杂。复杂的是拆解本身——什么粒度算"够小"？任务之间的依赖怎么判断准确？并行度开多大合适？

这些问题没有标准答案，但有一个原则：

每个子任务应该小到可以在一次 Skill 调用内完成，大到包含一个完整的、可验证的功能单元。

如果一个子任务需要调用三个 Skill 才能完成，说明它太大了，需要再拆。如果一个子任务的输出无法独立验证——比如"定义变量"这种——说明它太小了，需要合并。

---

没有 Planner 的 AI 系统，就像一个没有项目管理的开发团队。每个人都很能干，但没人知道该先做什么、后做什么、谁的产出给谁用。结果要么是重复劳动，要么是方向冲突，要么是做了一堆东西最后发现拼不起来。

Planner 不是锦上添花。它是 AI 系统能否规模化的分水岭。

一两个简单任务，人脑可以充当 Planner。十个以上的复杂任务，没有系统级的 Planner，你就只能靠高级工程师手动调度——而高级工程师的时间，恰恰是团队里最稀缺的资源。

---

下一篇写 Verify。

代码生成了，任务拆好了，执行也跑通了——然后呢？为什么我说"没有 Verify，AI 生成的代码就不能进生产"？为什么验证层在 AI-Native 工程里的权重，比传统工程高得多？

如果 Intent 是方向盘、Planner 是导航，那 Verify 就是刹车。没有刹车的车跑得再快，你也不敢上路。