跳转至

AI 原生开发工作流

Ch09.115 AI 原生开发工作流

📊 Level ⭐⭐ | 8.0KB | entities/ai-native-development-workflow.md

AI 原生开发工作流

摘要

AI 原生开发工作流以自然语言 Spec 为源、Agent Loop 为执行引擎、Human-in-the-loop 为质量门禁，取代传统敏捷中以人写代码、CI/CD 被动验证为核心的组织方式。其本质是把「意图 → 代码 → 验证」的完整闭环交给可观察、可迭代的 Agent 系统执行，人类从操作员退居监督者，范式沿 Vibe Coding → Loop Engineering → Fleet Loop 演进，每一步都把隐式智能外化为显式系统结构。

核心要点

  • 映射链即信息精化链：自然语言 Spec → 结构化任务 → 代码生成 → 自动验证，每环都是翻译与约束，信息丢失模式决定质量上限。
  • Spec 是契约不是文档：每条规格应对应可执行验收测试——测试是 Spec 的机器可读投影。
  • Agent Loop 是主动执行引擎：与传统 CI/CD 的本质区别——Loop 从「检验者」变「执行者」，人类从「操作员」变「监督者」。
  • 演进逻辑是智能控制的外化：Vibe Coding 的智能困在单次对话；Loop Engineering 将其编码进提示词模板、验证步骤、回滚机制；Fleet Loop 再外化为协作协议。
  • 质量门禁必须可扩展：人工介入集中在高代价错误与低置信度决策，而非逐行审查。
  • Loop 可观察性是前提：状态日志与决策理由是调试与信任的基础，LLM 的非确定性使黑盒 Loop 几乎不可维护。
  • 投资阈值：同类任务重复 5 次以上才值得投资 Loop Engineering。

深度分析

映射链：每一环都是一次信息翻译与丢失

整条链是四次连续的信息翻译，每环丢失特定信息。Spec 阶段：模糊需求被约束为明确行为描述，丢掉「歧义」（有益），但也可能丢掉「语境」——隐式假设与业务约束在口语表达中被省略。任务分解阶段：Spec 被拆为可验证原子单元，丢掉「全局关系」——跨任务依赖与一致性问题在此埋下。代码生成阶段：任务被翻译为实现，丢掉「意图」——代码忠实字面却偏离本意，正是「能跑但不对」类缺陷的根源。验证阶段：测试比对实现与 Spec，是唯一能把前面各环节丢失显式找回来的环节。

由此得出关键结论：验证环节是映射链的「信息守恒器」。验证弱，前面的丢失被静默接受并进入生产；验证强，Spec 歧义在第一时间被测试暴露而非被代码固化。这解释了 Spec-Driven Development 为何与测试文化天然绑定：其核心假设「结构化规格比隐式任务描述更精确、更可验证」只有通过测试才能兑现。Spec 定义「应该发生什么」，测试证明「实际发生了什么」，二者差异就是映射链的真实信息丢失量。

Agent Loop 与 CI/CD：从检验者到执行者

传统 CI/CD 是被动流水线：提交触发构建测试，只检验不生产，控制点在人工「提交」动作上。Agent Loop 是主动执行引擎：目标 → 读状态 → 决策 → 执行 → 验证 → 反馈，循环自己产生代码并验证产出，控制点迁移到 Loop 内部的决策函数。

控制权迁移伴随错误模式迁移。CI/CD 时代典型错误是「人写错代码、流水线抓出来」；Loop 时代是「Loop 在无人监督路径上做出错误决策并自我强化」——错误发生在循环内部，且因上下文遗忘与路径依赖被后续迭代放大。因此 Human-in-the-loop 是门禁设计问题而非审查岗：介入时机取决于错误代价函数——破坏性操作（删库、发布、改权限）必须人工门禁，低代价迭代全自动放行。监督的可扩展性来自「只拦截高代价动作 + 事后审计轨迹」，而非「事前逐行审批」——后者只是把体力劳动换成脑力劳动，瓶颈未消除。

智能的外化：Vibe Coding → Loop Engineering → Fleet Loop

三阶段共同逻辑是「逐步外化智能控制」。Vibe Coding：智能困在单次对话上下文，人承担全部系统结构（记需求、手动验证、手工回滚），产物是一次性对话。Loop Engineering：把隐性工作编码为显式结构——提示词模板（知识外化）、验证步骤（判断外化）、回滚机制（纠错外化）、状态管理（记忆外化），Loop 变成可复用工程资产。Fleet Loop：多个 Loop 并行协作，进一步外化协作协议——任务分配、上下文隔离、结果仲裁。

外化并非免费：每次外化都用「显式固定结构」换「隐式灵活智能」，代价是刚性与维护成本——模板冻结知识也冻结更新节奏，验证约束行为也约束探索空间。因此外化收益高度依赖任务重复频率：低频任务外化成本收不回来，高频任务收益随执行次数线性累积。这正是「重复 5 次以上才值得 Loop Engineering」阈值的理论依据；Fleet Loop 同理，只有先有多个成熟 Loop，协作协议收益才可能大于协调成本。

可观察性与度量：Loop 时代的工程基建

Loop 从辅助工具变成执行主体后，可观察性从锦上添花变成生存前提，分两个层面。运行层：每个循环输出状态日志与决策理由——不仅记「做了什么」还要记「为什么这么做」。LLM 的非确定性使同样输入可能产生不同决策路径，没有决策理由的日志几乎无法复现调试；状态日志是断点续跑与回滚的依赖。组织层：需要事件级 AI Coding 度量（可下钻到 Agent、模型、Skill、部门粒度），而非 CI/CD 聚合 KPI。DORA 的 J-Curve 表明采纳 AI 工具初期会经历生产力下降期，度过谷底 ROI 才兑现——没有细粒度度量，团队无法判断自己处于谷底还是方向性错误。

实践启示

  1. 从最弱环节下手：诊断四环节中哪个信息丢失最严重（Spec 模糊、粒度不当、生成偏离、验证缺失），最弱环节决定质量上限。
  2. 测试是 Spec 的一等公民：写 Spec 时同步写验收测试，让「可验证」成为硬约束——测试写不出来的规格条目本质还是模糊需求。
  3. 门禁按错误代价分级：破坏性操作设人工门禁，低代价迭代全自动放行，用审计日志保证事后追溯，介入点随 Loop 成熟度后移。
  4. 先建可观察性再扩规模：Loop 上线前必须有状态日志与决策理由；组织层面尽早建立事件级度量基线，否则无法度量 J-Curve 谷底与 ROI。
  5. 遵守 5 次重复阈值：同类任务重复 5 次以上才投资 Loop Engineering；Fleet Loop 在多个成熟 Loop 之后引入，避免过度工程。
  6. 保留人类监督的语义层：AI 验证「实现是否符合 Spec」，人类判断「Spec 本身是否正确」——需求语义判断是自动化无法外包的最后一环。

相关实体