把线性流程改造成证据闭环

AI 原生不等于把一个代理塞进六个旧阶段。更关键的设计，是让每一阶段输出下一阶段可以直接读取的版本化工件，并用工件的接受事件触发后续动作。这样，计划、设计、构建、测试、部署和维护不再只是单向瀑布，而是围绕生产反馈持续运行的闭环。

学习目标

• 能说明六阶段流程为何是可回流、非线性的循环。
• 能为每个阶段定义可读、可审、可追溯的交接工件。
• 能为工件设置自动触发与人类判断门。

核心概念

官方手册把工件链放在流程中心：意图由 intent.md 表达，设计决策进入 spec.md，实现方案进入 plan.md；随后差异、测试结果、PR 评审记录和事故记录继续形成证据。早期采用 Markdown，是因为业务负责人和代理都能读取；进入构建后，代码与工具链记录成为主要工件。

“提交即交接”有三个价值。第一，下一阶段不必重新听一遍口头背景；第二，修订记录说明谁在何时改变了什么；第三，自动化可以监听明确事件。已接受的意图可以启动设计，已批准的规范可以启动计划模式，合并的 PR 可以进入流水线，生产控制带越界又可生成新的意图。

这里的自动触发不是自动批准。代理可以准备材料、执行机械检查和标出风险；产品取舍、较高风险设计、受监管代码与生产授权仍由指定人员判断。理想结构是：系统自动把完整证据送到门口，人只处理需要判断的部分。

图 1：AI 原生生命周期闭环（AIKnow 原创示意）

图注及中文替代文本： 六个阶段按 Plan、Design、Build、Test、Deploy、Maintain 前进；Maintain 从生产证据生成新意图并回到 Plan。箭头表示信息流，不表示代理可绕过人类批准。下方纯文本节点可按行顺序阅读，不依赖图像或颜色。

┌────────────┐    ┌────────────┐    ┌────────────┐
│ Plan       │ →  │ Design     │ →  │ Build      │
│ 问题与意图 │    │ 规范与约束 │    │ 计划与差异 │
└────────────┘    └────────────┘    └────────────┘
       ↑                                      ↓
┌────────────┐    ┌────────────┐    ┌────────────┐
│ Maintain   │ ←  │ Deploy     │ ←  │ Test       │
│ 指标与事故 │    │ 评审与发布 │    │ 测试与评估 │
└────────────┘    └────────────┘    └────────────┘
       └────── 生产证据形成新 intent.md ──────┘

阶段	主要输入	可提交工件	关键判断门
Plan	问题、事件或想法	intent.md	产品负责人接受问题定义
Design	已接受意图与组织策略	spec.md	方案和未决风险获批准
Build	规范、代码库上下文	plan.md、差异与测试	工程师接受计划
Test	实现与验收条件	测试、评估结果	证据是否充分
Deploy	PR 与全部检查	评审、发布记录	代码所有者与发布人授权
Maintain	指标、告警、工单	事故记录或新 intent.md	值班/服务负责人分流

图 2：工件交接与依赖门（AIKnow 原创示意）

图注及中文替代文本： 每个工件先经过一名有责任的人类接受，才成为下一工件的输入；实现后由确定性检查、独立评审和生产授权逐层收窄风险。底部回流线表示控制带异常可以重新生成 intent.md。相邻正文与表格包含同样信息。

想法 / 工单 / 异常
        │
        ▼
   [ intent.md ] ──产品负责人接受──▶ [ spec.md ]
                                            │
                                     方案/策略负责人接受
                                            ▼
                                      [ plan.md ]
                                            │
                                      工程师接受计划
                                            ▼
                                   [ diff + tests ]
                                            │
                         CI 检查 ─▶ 独立 PR 评审 ─▶ 发布人授权
                                            │
                                            ▼
                                      [ 生产记录 ]
                                            │
                         控制带越界 ─────────┴────▶ 新 intent.md

实践步骤

1. 选一条真实变更路径，列出每次交接的输入、输出和负责人。
2. 删除“发消息通知某人”这类不可验证输出，改成一个有状态、有版本的工件。
3. 为每个工件写接受条件，例如 spec.md 必须回答意图中的开放问题，或明确保留它们。
4. 先用人工命令触发下一阶段，确认工件质量稳定后再接入 CI 或事件监听。
5. 为每个自动触发保留失败队列和升级路径；触发失败不能静默丢失工作。

常见误区

• 阶段顺序等于采用顺序。 官方手册明确区分生命周期阶段和 Play 的依赖关系；团队应先实施没有前置依赖的能力。
• 提交了文件就等于被批准。 工件状态、审批人和接受事件必须清晰。
• 每个系统都保留一份“真相”。 仓库、需求工具与变更系统可以共存，但应指定一个权威源，至少保持记录 ID 与提交 SHA 双向链接。
• 让一个代理既写又批准。 独立检查与职责分离是闭环可信的前提。

动手练习

为“给内部报表增加导出功能”画出六个节点。每个节点只允许写一个主要工件，并标注：谁可以修改、谁可以接受、什么事件触发下一节点、失败去哪。最后故意加入一个生产错误，验证它能否沿维护节点回到新的 intent.md，而不是只停留在聊天记录里。

要点回顾

AI 原生循环依靠的不是连续对话，而是连续证据。工件必须同时服务人类审查、代理读取和审计追踪；触发器负责搬运，判断门负责承担责任。闭环完成的标志，是生产经验能够以结构化意图重新进入计划阶段。

参考来源

• Anthropic / Claude 官方文章：The AI-Native SDLC playbook，重点参见 “What is an AI-native SDLC?” 与 “Plays”，核验日期：2026-08-26。