课程目录

第 10 课 · AI 原生软件开发生命周期

Adoption Checklist and Maturity Assessment

本篇听书

8 分钟 · 双主持人讲解

配套视频里没有与本篇对应的段落

落地顺序与成熟度自评

AI 原生 SDLC 不适合一次性“大爆炸”改造。官方手册强调，六个生命周期阶段与 Play 的采用顺序不是一回事：先做没有前置依赖的能力，再沿依赖关系扩展。对多数团队，可靠路径是先建立工件与项目上下文，随后缩短验证反馈、统一评审和动作门禁，最后才把非交互执行接入生产反馈闭环。

学习目标

  • 能根据依赖、风险与当前瓶颈安排落地顺序。
  • 能用清单完成一个小范围、可度量的试点。
  • 能对团队的工件、反馈、治理和闭环能力做成熟度自评。

核心概念

生命周期顺序描述一次变更如何流动；采用顺序描述组织先建设哪些能力。两者不能混淆。例如，维护闭环依赖结构化 intent.md、评审门、动作边界和已演练回滚；如果这些基础不存在，先做自动修复会把不确定性直接送入生产。

下面的路线是 AIKnow 根据官方依赖原则整理的实施建议，不是 Anthropic 的逐字路线图：第一阶段测基线并建立 intent.md、plan.md 和精简 CLAUDE.md；第二阶段建设测试/验证内环与少量真实 eval；第三阶段统一 PR 分层评审、Hooks、分支保护、权限和沙箱；第四阶段把代理接入只读 CI，再逐步开放可逆写操作；第五阶段用确定性控制带启动受限诊断，最终让事故回到意图与 eval。

采用不是追求最高自主等级。不同仓库可停在不同层：受监管核心服务可能长期保留更多人类门，而低风险文档仓库可以更自动。成熟度看证据是否可靠、边界是否明确、失败是否可恢复，而不是看代理能连续运行多久。

图 3：分阶段采用阶梯（AIKnow 原创示意）

图注及中文替代文本： 五级阶梯从基线与工件开始，依次增加验证内环、统一评审与执行边界、非交互 CI，最后才进入受控生产闭环。每一级都设停止条件：质量证据下降或关键控制未达标时，不扩大自主权。下方纯文本阶梯和后文 30 天清单提供不依赖图像的同等信息。

从基线与工件、验证内环、统一评审与边界、非交互 CI，逐级发展到受控生产闭环。
分阶段采用阶梯（AIKnow 原创示意）移动端可左右滑动查看细节
第 5 级  ┌─────────────────────────────┐
         │ 受控生产闭环：确定性检测 → 受限诊断 → 人类分流 │
第 4 级  ├─────────────────────────────┤
         │ 非交互 CI：只读任务 → 可逆写入 → 已演练回滚   │
第 3 级  ├─────────────────────────────┤
         │ 统一评审与边界：Hook / 权限 / 沙箱 / 分支保护  │
第 2 级  ├─────────────────────────────┤
         │ 验证内环：失败测试 / 新鲜输出 / 真实任务 eval │
第 1 级  ├─────────────────────────────┤
         │ 基线与工件：intent / spec / plan / CLAUDE.md   │
         └─────────────────────────────┘
                  ↑ 先证明，再向上扩大自主范围

实践步骤

30 天试点清单

  • [ ] 选一个低到中风险、改动频繁、有现成测试的仓库，并指定产品、工程和策略负责人。
  • [ ] 用最近 20 个变更建立端到端周期、首轮 CI 成功率和生产逃逸缺陷基线。
  • [ ] 为一个真实需求使用 intent.md → spec.md → plan.md 工件链，并记录接受人。
  • [ ] 精简 CLAUDE.md，加入准确命令、架构边界和完成前验证要求。
  • [ ] 从近期工作建立 5–10 个冒烟 eval；至少一个来自真实事故。
  • [ ] 启用统一 PR 评审策略和分支保护，让作者代理不能自批。
  • [ ] 把一个不可例外规则落实为 Hook 或 CI 阻断，并测试阻断信息与例外路径。
  • [ ] 仅在非生产环境试行非交互代理；使用短期凭据、沙箱和明确工具允许列表。
  • [ ] 在预发布演练回滚，并把结果附到发布证据。
  • [ ] 比较试点前后周期与质量指标，由负责人决定扩大、调整或停止。

成熟度自评

以下成熟度模型与分数阈值为 AIKnow 原创示意，不是 Anthropic 官方评级标准。

每项按 0–3 分评分：0=没有；1=依赖个人习惯；2=已版本化且大部分执行；3=有确定性门、证据与定期演练。

维度 自评问题
意图与工件 下一阶段能否只读已接受工件理解目标、约束与历史？
项目上下文 CLAUDE.md/Skills 是否短、准确、有所有者并随政策更新？
反馈与 eval 缺陷是否先复现，完成是否有新鲜输出，事故是否进入 eval？
评审与职责分离 所有 PR 是否一致分层检查，作者是否无法自批？
权限与执行边界 工具、文件、网络、凭据和生产动作是否按环境最小授权？
可恢复性 写操作是否可逆，回滚是否在预发布定期演练？
生产闭环 检测是否确定性，异常能否形成 intent.md 并由人分流？
度量与审计 是否能追踪请求、规则版本、产物、批准人与质量后果？

总分只用于定位下一步，不用于团队排名。0–7 分先补工件和基线；8–14 分优先反馈、评审与边界；15–19 分可扩大非交互试点；20–24 分才考虑受限生产闭环。若“职责分离、权限边界、可恢复性”任一低于 2 分，不应提升生产自主权。

常见误区

  • 先购买平台再找流程。 应从可观察瓶颈和控制目标出发。
  • 把全部仓库设成同一自治等级。 数据分类、可逆性和法规责任不同，边界也应不同。
  • 试点只展示成功案例。 必须主动演练失败、阻断、降级和回滚。
  • 成熟度分数变成绩效排名。 这会诱导隐藏风险；分数只服务能力建设顺序。
  • 完成自动化后停止维护。 工件模板、Skills、Hooks、eval 和控制带都需要所有者与复审周期。

动手练习

召集产品、工程、平台和安全各一人，独立填写成熟度表，再比较分歧。选择最低且会阻断下一能力的维度，写一项两周内可验证的改进：明确负责人、输入、输出、测试和一对指标。最后安排一次失败演练，验证门禁确实阻止越权且团队知道恢复路径。

要点回顾

采用顺序应服从依赖和风险，而不是照着 Plan 到 Maintain 机械部署。先建立工件、上下文和反馈证据，再统一评审与边界，最后逐步开放非交互执行和生产闭环。人类判断始终位于循环之上；高成熟度意味着系统能证明它为何行动、由谁批准、失败后如何恢复。

参考来源