AI-Native 软件工程(5):从 Intent 到 Delivery,一套完整的工程结构

前面写了不少的概念，怎么把这些零散的概念拼成一张完整的图。

Agent 不是工程单元，Skill 才是。AI Coding 不是写代码，而是执行系统。Coder Engine 是把 Skill 串成生产力的调度层。——每一篇单独看都说得通，但放在一起，总觉得少了一根线。

直到最近我把自己团队的开发流程从头到尾画了一遍，这根线才出现。

---

传统软件工程的流程，大多数人都能背出来：

需求 → 设计 → 编码 → 测试 → 上线

这个结构跑了几十年，核心假设是：人写代码，系统运行代码。

AI 时代，这个假设变了。代码不再由人逐行编写，而是由模型生成。但"生成代码"只是整个工程链条里的一小段。需求怎么定义、任务怎么拆解、执行怎么调度、结果怎么验证、最终怎么交付——这些问题不会因为代码生成变快了就自动消失。

如果你把 AI-Native 软件工程的流程重新画一遍，会是这样：

Intent → Plan → Execute → Verify → Delivery

看起来只是把步骤名换了？不是。这不是名词替换，而是工程结构变了。

---

先说 Intent。

传统流程的起点是"需求文档"。产品经理写 PRD，开发拿着 PRD 去写代码。需求文档的质量参差不齐，但没关系——人类工程师可以在写代码的过程中不断补全理解，遇到模糊的地方去问产品，遇到冲突的地方自己判断。

AI 没有这个能力。

你给 AI 一个模糊的需求，它不会来问你"这个字段允不允许为空"。它会猜。猜对了你觉得 AI 真聪明，猜错了你觉得 AI 真蠢。但问题不在 AI，在于你没有把意图定义清楚。

所以 AI-Native 软件工程的起点不是"需求"，而是 Intent——一个包含目标、约束和上下文的精确描述。

---

再说 Plan。

传统流程里，"设计"通常是架构师或高级工程师的工作。画几张图，写个技术方案，然后分任务开干。

AI 时代，Plan 这一层变得更关键了。因为 AI 不会自动把一个复杂需求拆成合理的子任务。你让 AI "写一个用户系统"，它可能一口气给你吐出 2000 行代码——把注册、登录、权限、密码重置、邮件验证全塞在一个文件里。

不是 AI 不够强。是没有人告诉它：先做数据模型，再做接口，最后做测试。先注册，后登录，最后权限。

这就是 Planner 的职责：把一个大的 Intent 拆解成有序的、有依赖关系的子任务，让执行层可以逐步消化。

---

然后是 Execute。

上一篇已经详细写过 Coder Engine，这里不重复。核心观点：执行不是"调一次 API 拿到结果"，而是一个包含生成、运行、验证、重试的循环系统。Skill 提供能力，Engine 提供调度，两者配合才能把任务真正做完。

---

Verify 是这条链路上最容易被忽视的环节。

很多团队的 AI 工作流是这样的：AI 生成代码 → 人 review 一眼 → 合进去。

这个流程在小项目上没问题。但一旦规模上去了，人 review 的可靠性会急剧下降。你真的每次都能看出 AI 生成的代码里有没有边界 case 没处理？有没有引入不兼容的依赖？有没有破坏已有的测试？

Verify 层不是"最好有"，而是"必须有"。它包括：自动化测试、类型检查、lint 规则、接口契约校验，甚至代码风格一致性检查。这些不是新东西——传统 CI/CD 早就在做。但在 AI-Native 工程里，Verify 的权重比传统工程更高，因为代码的产出速度快了 10 倍，出错的密度也可能高了 10 倍。

---

最后是 Delivery。

生成的代码通过了所有验证，然后呢？它需要能合进主干、能打包构建、能部署上线、能在生产环境里正常运行。

Delivery 不只是"git push"。它意味着：

代码可运行——不只是语法正确，而是在真实环境里跑得通
代码可维护——其他人能读懂、能修改、能扩展
代码可上线——满足安全、性能、合规等生产标准

如果 AI 生成的代码只能在本地 demo 里跑一下，那它就只是一个玩具，不是工程产出。

---

回到开头那个问题：这五个层和传统的五个步骤有什么本质区别？

传统流程的每一步之间，靠的是人。人理解需求，人设计方案，人写代码，人跑测试，人负责上线。步骤之间的衔接、信息的传递、异常的处理，全部依赖人的判断力和责任心。

AI-Native 流程的目标，是让系统承担尽可能多的衔接工作。Intent 定义清楚了，Planner 自动拆解。拆解结果直接进入 Engine，Engine 调度 Skill 执行。执行结果自动进入 Verify 层，验证通过自动进入 Delivery 流程。人的角色从"每一步都亲自干"变成"定义起点、审核终点、处理异常"。

这不是自动化幻想。这是工程结构变化。

当你把这五层真正搭起来、跑通、调稳的时候，你会发现一件事：你不再是在用 AI 工具，而是在运营一套 AI 软件工程系统。

---

这篇是整体结构的鸟瞰图。接下来三篇，我会分别深入每一个关键层。

下一篇先写最被低估的一层：Intent。

为什么我说 AI 软件工程的起点是 Intent，而不是代码？为什么大多数人定义 Intent 的能力，远比他们以为的差？

这个认知如果不建立起来，后面的 Plan、Execute、Verify 都会在错误的方向上空转。