什么是 AI Native 软件工程：角色、分工与一个真实案例

核心观点 AI Native 软件工程不是「让 AI 写代码」，而是把 agent 当作一等参与者来设计整个工作系统：规则写给 agent 读，门禁由另一个 agent 把，人只保留裁定权与验收权。本章用一个八天投产的真实项目，把这句话落成一张角色表和一条流程。

从「AI 帮我写代码」到「为 agent 设计工作系统」

过去两年里，大多数团队对 AI 的用法可以叫做 AI-assisted：人坐在编辑器前，AI 负责补全、解释、生成一段函数。流程没有变，只是键盘上多了一双手。

这套用法有一个隐含前提：人仍然逐行读过代码，人仍然是每一次修改的直接执行者。一旦 AI 的产出速度超过人阅读的速度，这个前提就不成立了。第 02 章讲的「认知欠债」正是从这里开始积累的。

AI Native 的差别不在于用了更强的模型，而在于工作系统本身是为 agent 设计的：

• 规则写成 agent 能读、能引用的文档，而不是留在某个人的脑子里或者聊天记录里；
• 功能边界用一个非代码、非对话的物理载体来承载，agent 能查证「这个功能在不在范围内」；
• 验收写成可证伪的条目，agent 报告的「完成」必须附实际命令与结果；
• 缺陷门禁由另一个独立的 agent 把守，写代码的 agent 不审自己的代码；
• 人退到裁定与验收的位置，做的事变少，但每一件都不可让渡。

左边：人做所有事，AI 是一个补全气泡。右边：agent 在各自的工位上按规则工作，中间有门禁，人只在上面裁定。

这个区分不是术语游戏。它决定了当代码产生得比人理解得更快时，系统靠什么保持可控——靠人加班读代码，还是靠一套能约束 agent 行为的结构。

四个角色，各有不可让渡的职责

Agent X-Ray 项目里有四个角色，外加一个管理面。它们的分工从第一天起就写在仓库根目录的 CLAUDE.md 里：「Claude Code solo 开发，codex 独立审查；不做视觉 review」。

所有者是唯一用蓝色画出来的角色：不是因为做得最多，而是因为裁定权只在这一处。

三点值得展开。

所有者的工作是裁定，不是指挥。 项目里最重要的所有者动作几乎都以「裁定」两个字记录在 ROUNDS.md 与各轮任务卡里：让 agent 使用 skills 的七条裁定、让 agent 读访客指定网页的十条裁定、备案通过后一次性定下的五条裁定。每条裁定都带日期，很多条还带一句「代价已认」。第 15 章专门讲这件事。

实现 agent 与审查 agent 必须是两个独立的 agent。 这不是「两个模型比一个模型准」的统计学考虑，而是职责隔离：写代码的 agent 天然倾向于证明自己的实现是对的，审查 agent 的唯一职责是找缺陷。项目里的规则更进一步——审查只报缺陷，不出方案；findings 若指向设计缺陷，停下来回到所有者层面重定方案，而不是在「整改 → 复审」的循环里逐条堆补丁。第 13、14 章讲这两条。

设计 agent 的产物是边界本身。 这个项目的功能范围只有一个定义：design/ 目录里的 20 块画板加一个可交互原型。任何画板上没有的功能都不许实现，想扩边界就先改画板。第 08 章讲这个机制。

一条流程和它的门禁

四个角色由一条流程串起来。它写在 CLAUDE.md「开发模式与轮次流程」段，全文只有七行：

开工：从模板建任务卡，按 ROUNDS.md 该轮拆解填好
  → 实现（遵守硬性规则）
  → 验证：check / test + 任务卡验收项全过
  → codex 独立审查
  → findings 逐条处理（采纳整改 / 不采纳写明理由），回填任务卡
  → 只要有采纳整改的 findings → 再发一轮复审
  → commit + 更新 ROUNDS.md 进度表

把它展开成节点，每个节点都有一个落点：

VERIFY 与 REVIEW 前面画着栏杆：它们是能把流程拦下来的门禁，不是走过场。

这条流程里有两个门禁是「能停」的：验证不过不进审查，审查有 high 级 findings 不许合并。还有一个更早的止损：里程碑表里写着「R1 任一门禁不过 → 停，重新评估架构」。第 11、12 章讲止损怎么设计。

后面每一章都是这条流程上的一个节点，或者是让这条流程跑得起来的约束。

一个真实案例：Agent X-Ray 的八天

站点是什么。 Agent X-Ray 是一个「Agent 运行时」网站：访客与一个 AI agent 对话，右侧面板像浏览器的开发者工具一样，实时展示 agent loop 内核的 34 种事件轨迹。除了这个 Runtime 工作台，站点还有 Notes 研习库、Skills 技能库和 About 页。本教程就发布在它的 Notes 里；读者可以在同一个站点上看到本书讲的那个 agent 在跑。

它是怎么做出来的。 项目 2026-08-28 开工，2026-09-02 投产，到 2026-09-04 完成第七次生产发版。八天里的节奏大致如下：

一共 202 次提交，ROUNDS.md 进度表 24 行加一轮进行中。这个数字本身不重要，重要的是与它并列的另一组数字：每一轮都有审查记录（只有三轮由所有者裁定跳过，且跳过的原因与残留风险写在任务卡里），每一次发版都有留证行。速度与责任是同一张表上的两列。

仓库长什么样。 目录结构本身就是这套工作系统的物理形态：

注意 rounds/、design/、docs/ 三个目录的存在：它们不是代码，却占了仓库里相当一部分的提交。在 AI-assisted 的工作方式里它们经常是可选的；在这套系统里它们是让 agent 能够自我约束的基础设施。

为什么这套系统对 agent 尤其必要

人也需要规则、边界和门禁，但 agent 对它们的依赖更强，原因有三。

agent 会「自己加戏」。 一个能干的 agent 遇到没有明说的地方，会用自己的判断补上——多加一个参数、多做一层防御、把「第一轮命名」改成「模型自己判断的某一轮」。这些补充单独看都有道理，累积起来就是范围失控。项目里的应对不是「提示词写得更细」，而是让边界可查证：画板上有没有、任务卡「禁止」段有没有写、硬性规则有没有编号可引用。第 14 章会讲一个真实的「加戏」案例和它被回滚的过程。

agent 的验证与它的实现来自同一个上下文。 它写完代码之后说「已完成」，这句话的证据来自它自己刚才做的事。所以验收必须外置：命令与期望写在任务卡里、由独立 agent 做缺陷门禁、由人做最终验收。第 13、17 章讲这两层。

agent 没有跨会话的记忆。 每个新会话都从零读仓库。那些「上次踩过的坑」「所有者说过不要这样做」如果只存在于对话里，下一次就会再犯。所以规则要进 CLAUDE.md，裁定要进 ROUNDS.md，纠正要进记忆文件。第 09、20 章讲这些文档的分层。

反过来说，这套系统对人也有好处：所有者不必读每一行代码，因为验收表、审查记录与发布留证已经把「什么被验证过」写清楚了。人可以把精力集中在真正需要判断的地方。

本书怎么读

第一部分（02–06）建立认知：AI 改变了生成的成本，没有改变判断、验证与责任的必要性。

第二部分（07–11）讲开工之前的四件事：系统设计、功能边界、项目宪法、风险前置。

第三部分（12–15）讲迭代机制：轮次、独立审查、审查的边界、所有者的裁定。这四章是全书骨架。

第四部分（16）讲不能商量的约束：安全模型与供应链。

第五部分（17–19）讲交付：验证与证据、发布与运维、投产之后怎么继续。

第六部分（20–21）讲人与工具：上下文与记忆、失败模式与复盘。

每章末尾都有「案例来源」列出仓库路径，「学习产出」给出一件可以立刻做的事。建议按顺序读，但第三部分可以先读。

案例来源

• CLAUDE.md「项目定位」「仓库结构」「开发模式与轮次流程」
• AGENTS.md
• docs/architecture.md「总览」「关键决策（已定）」
• ROUNDS.md「进度表」「里程碑」
• docs/releases.md「生产」表
• git 提交统计（2026-08-28 至 2026-09-04）

学习产出

为自己正在做或准备做的项目画一张角色表和一张流程图。角色表至少回答：谁有裁定权，谁把门禁，门禁失败时谁停下。流程图上标出哪些节点是「能停」的，以及停下之后回到哪里。

Related Documents

• 为什么 Vibe Coding 不可以？
• 轮次机制：任务卡、可证伪验收、BACKLOG 与止损
• 独立审查作为缺陷门禁：codex 审查循环
• AI Native 软件工程教程