代码不再是瓶颈，你才是——AI 原生软件开发生命周期全解
1. 代码不再是瓶颈
当 agent 让构建（Build）阶段从数周压缩到数小时后，三件事随之发生：
- 瓶颈左右移动：计划、评审/测试、部署仍以人类速度运行，成了新的短板；
- 控制与现实脱节：逐行人审在"人写的每一行"时代有意义，在"agent 写了大部分 diff"时难以为继；
- 治理成本上升：例外仍要走每周/每月的委员会，队列越积越长。
结论：编码已经不再是一个限制因素了，要兑现智能编码的生产力，围绕代码的流程必须经历与写代码本身同等的变革。
2. 基于人工智能的软件开发生命周期
基于人工智能的软件开发生命周期（AI-native SDLC）是一种重新设计的流程，它将传统的控制目标与新的执行机制相结合。这个流程不再遵循线性流程，而是形成了一个循环模式，并且在每个环节都融入了人工智能技术。这种流程能够实现自动的交接处理，并触发后续的开发步骤，从而解决传统软件开发生命周期中手动交接所带来的繁琐问题。
术语说明：本文标题中的 SDLF（Software Development Life Framework）与正文中的 SDLC（Software Development Life Cycle）指同一概念——软件开发生命周期。SDLF 强调"框架"视角（流程+工件+治理的整体），SDLC 强调"周期"视角（从计划到维护的循环），两者在此混用。
2.1. SDLF vs AI-SDLF
| 阶段 | 传统式软件开发生命周期 | 人工智能原生 SDLC | 关键活动 | 目标 |
|---|---|---|---|---|
| 计划 | 由委员会收集需求，经研讨会层层筛选和逐级签署确认，最后手工整理成文 | Claude 直接从原始来源综合痛点，写入 intent.md——人可读、机器可执行 |
用 intent.md 捕获意图（问题、预期结果、约束、开放问题），非工程师也可经连接器让 Claude 代为提交 |
想法不再排队等人代笔，意图结构化从数周缩短到数小时 |
| 设计 | 由分析师撰写规格说明，设计师再将其解析为设计方案 | 需求与设计压缩为与 agent 的一次工作会话，标准以 skills 编码、经 git 版本化管理 | 需求与设计合并为一次会话，组织政策编码为 skills 作为约束 | 政策在写 spec.md 时即被应用，而不是数周后的评审中才暴露 |
| 构建 | 测试与代码均由人工编写，文档在主体开发完成之后才补写 | 测试与代码由 AI 生成，制度知识以版本化、机器可读的 CLAUDE.md 与 skills 维护 |
plan mode 先出计划获批准再实施，CLAUDE.md 承载项目记忆，hooks 作确定性护栏，worktree 并行会话加子代理 |
知识外置为文件、护栏以代码而非习惯运行 |
| 测试 | 在各阶段边界处设置 QA 质量关卡 | 持续评估（evals）编织进整个实施过程 | 反馈回路（agent 会话在人看到之前自检自查），bug 修复先写失败测试，持续 evals 给 agent 配置做回归测试 | 给 agent 可量化的验收目标，不能让修代码的 agent 改测试 |
| 部署 | 人工逐行评审代码，治理在评审周期中进行，且往往不一致 | 多层 agent 评审，人工评审仅保留给受监管与关键代码；治理以 hooks 作为审批门，在 AI 行动的同时执行 | Claude 双向参与评审（审别人的 PR、处理自己 PR 的意见），hooks 作为审批门，managed settings 锁权限与沙箱 | 写代码的 agent 无权批准代码，治理随行动实时执行 |
| 维护 | 由人工监视生产环境、发现缺陷 | agent 监控线上部署，指标一旦越出控制带即触发诊断，并作为新的 intent.md 写回循环 |
确定性脚本监控控制带并分级响应（1σ 记录、2σ 只读诊断、3σ 经预批准路径提案），定期安全扫描，Claude Tag（协作渠道中的 on-call agent）值班 | 闭环自喂养，发现自动回写为新 intent.md 重启循环 |
注：维护行中"控制带"和"σ 分级响应"的详细解释见 3.4. 确定性检测与统计规则。
3. 核心机制
3.1. 工件链与循环
初期，每个步骤都由人工提示；最终形态是一个自动循环——每个被验证的"工件"触发下一个步骤。人类的注意力集中在这些验证关口上，回顾 agent 所标记的内容，而无需从零开始处理每一个阶段。
AI-native SDLC 的精髓在于：每个阶段以提交一个工件结束，下一个阶段从读取它开始。这些文件既是协作媒介，也是审计记录。
-
工件链：
intent.md→spec.md→plan.md→ diff+tests → PR+review findings → incident record。每个阶段结束时都会把一些信息写入版本控制系统（包括intent.md、spec.md、plan.md，以及 diff 及其测试、PR 的审查发现和事件记录）；下一个阶段则从读取这些文件开始。在初期阶段，主要工件是.md文件，因为产品负责人和 agent 都能读取并处理同一份文件；从构建阶段起，工件变成代码及其相关记录。 -
提交链即审计链：谁要求了什么、agent 产出了什么、谁批准了它，全在 git 历史里。需求描述、规格说明、实施计划、diff 与评审结果共同构成审计追踪。
-
注意力随工件上移：人仍然对每个需要判断的决策负责，但注意力从"逐行读代码"上移到"审标记出的发现、判断意图与风险"。
-
每个工件文件涵盖的内容包括：
- 有什么变化呢；
- 开始；
- 具体的实施步骤；
- 治理方面的考虑因素；
- 如何衡量它是否有效。
3.2. 工程中的核心 md 文件
下表汇总了工程中几个关键 md 文件的作用、生成时间、使用时机与更新方式：
| 文件 | 作用 | 生成时间 | 何时使用 | 更新 |
|---|---|---|---|---|
intent.md |
意图工件：以发起者自己的语言记录"要什么、为什么、什么约束"，是想法的结构化原型规格（proto-spec），含问题、预期结果、受影响用户与系统、约束、开放问题 | 计划阶段开始时：发起者与 Claude 头脑风暴后生成；维护阶段确定性检测脚本发现指标越出控制带、扫描发现超出单个 PR 的问题时，也会自动写入新的 intent.md |
① 产品负责人审查并决定接受/拒绝，接受即触发设计阶段；② 设计阶段 Claude 读取它生成 spec.md |
发起者修正 Claude 的误解后提交到共享的 intent/ 目录（git 记录作者与时间戳）；接受/拒绝决策记录为 merge 或关闭的 review；进入设计阶段后原则上不再大改（其后的改动次数是质量滞后指标） |
spec.md |
需求与设计规格：Claude 在组织 skills（品牌/安全/合规/UX）约束下从 intent.md 生成的规格，并标记需关注的区域（areas of concern） |
设计阶段：intent.md 被接受后，由 Claude 在一次会话中生成，产品负责人审核但不亲自动笔 |
① 产品负责人对照原始想法审查，先解决被标记的关注点；② 构建阶段作为 plan mode 的输入；③ 部署阶段 PR 评审的合规性对照基准 | 关注点由产品负责人与政策负责人逐一解决后，与 intent.md 一起提交；构建开始后的 spec.md 再提交（需求返工）被当作质量滞后指标统计 |
plan.md |
实施计划：列明要改的文件、工作顺序、证明性的测试与风险，是"没有经过认可的计划就不实施"的载体 | 构建阶段：Claude Code plan mode 中生成，工程师反复盘问（会破坏什么/哪步最险/放弃了哪些备选方案）迭代后批准 | ① 批准后作为 Claude 实施的依据（好计划下实施通常一次通过）；② PR 评审时对照 diff 与 plan.md 是否一致；③ 并行会话按它拆分互不冲突的任务 |
实施偏离计划时在同一 commit 中同步更新（可用 hook 强制两者同步）；计划本身进入审计链，记录谁批准了哪个版本 |
CLAUDE.md |
项目记忆/新成员上下文：构建/测试/lint 命令、约定、架构、Claude 常犯的错误，是每次会话开始时被读取的"活的团队知识" | 构建阶段：在仓库运行 /init 生成初版，再由工程师裁剪到一页以内、只留新成员第一天需要的东西 |
每次 Claude 会话开始时自动读取；PR 评审也读取它，因此写进其中的纠错从下一个 PR 起生效 | "同一错误犯第二次就写入"规则；评审发现重复问题时随该次评审更新；像代码一样进 git、走 PR 评审，全团队共享一个版本 |
.claude/skills/<name>/SKILL.md |
制度化知识的操作化：把必须一致执行的政策（安全标准、API 约定、品牌规则）编码为带触发条件的技能，是咨询性（advisory）控制 | 任意阶段（多在设计/构建）：选定一项当前执行不一致的政策，工程师依据政策负责人的权威来源编写，政策负责人签署 | frontmatter 的 description 定义触发时机（如"创建或修改对外 API 端点时"），任务命中即自动加载 |
政策变化时修改 skill 并由政策负责人签署变更；放在 repo 的 .claude/skills/ 随代码发布，或经 plugin 组织级分发；工程师下次会话自动获得新版 |
REVIEW.md |
评审政策：定义评审的 pass（bug/安全/合规）、Important 与 Nit 的界限、nit 数量上限、不报告的内容 | 部署阶段：tech lead 在仓库根目录编写 | 每次 PR 评审：Claude 按 pass 执行并给发现标注严重级别；严重级别计数以机器可读格式发布，供平台工程师做门禁 | tech lead 每月调优：给发现评级让 reviewer 改进、收紧 nit 上限、排除 CI 已覆盖与生成路径 |
.claude/agents/*.md |
子代理定义：把重复性工作（verifier 验证器、researcher 研究员、代码简化器）封装为有独立上下文窗口和工具限制的范围化助手 | 构建阶段：工程师把在多个任务中重复出现的职责沉淀为子代理 | 会话内按 description 条件调用；如 verifier 在会话报告完成前用全新上下文复核行为是否匹配 plan.md |
定义 check into git，全团队共享，像代码一样演进 |
补充：
.claude/settings.json（hooks）与bands.yaml（维护阶段的控制带分级）等配置文件虽非 md 工件，但同属"配置即治理"的一环——团队钩子放.claude/settings.json进 git，不可协商的钩子放平台管理的 managed settings，个人无法关闭。
3.6. 落地顺序与依赖
原文强调 plays 之间有依赖关系，并建议按依赖顺序分批采纳，而非整套照搬：
| 剧本 | 前置依赖 | 可否首批起步 |
|---|---|---|
CLAUDE.md |
无 | ✓ |
| plan mode | CLAUDE.md（非硬性，原文称其 helps） |
✓ |
| 反馈回路（make test） | 测试套件（基础设施，非剧本依赖） | ✓ |
| skills | 一项有书面来源的政策 | |
| hooks | 权限配置 | |
| evals | CLAUDE.md + 测试套件 |
|
| PR 评审 loop | CLAUDE.md + skills + subagents |
|
| hooks 作审批门 | hooks | |
| CI/CD 集成 | PR 评审 + hooks | |
| 闭环（维护） | 前面全部 |
✓ 的判定标准：无前置剧本依赖、当天可落地。
推荐的最轻量起步组合
推荐的最轻量起步组合是 CLAUDE.md + plan mode + 反馈回路，零流程改造即可起步；intent.md/spec.md 链条的价值则在多角色、强合规的组织中才充分体现。
个人观点：通常情况下，
CLAUDE.md+intent.md才是个人最轻量的起步组合——因为plan.md本就依据intent.md（经spec.md）编写，个人场景可直接从意图驱动：
intent.md描述要什么（意图与验收目标），CLAUDE.md描述怎么构建和验证（命令、约定、架构）。- 依据这两项，由大模型编写
spec.md；此后修改intent.md时，同样由大模型同步更新spec.md，保持两者一致。- 人工确认
spec.md后，由大模型在 plan mode 中依据spec.md生成plan.md；人工批准后再实施代码，分步骤迭代，实现偏离计划时同步更新plan.md。- 同时依据
spec.md生成测试用例并写入test.md，人工确认后作为每次迭代的验收基准，确保代码符合需求（个人扩展：原文工件链中没有test.md，其对应物是可执行的测试套件——test.md在此指供人工确认的测试计划，最终仍应落为测试代码）。- 通过以上循环，最终达成
intent.md设定的目标。
3.3. 治理的三层控制模型
- Skill（咨询性）：让违规变罕见，但不强制；
- Hook（确定性）：让违规接近不可能，每次动作都检查，无例外；
- Human gate（判断性）：审批集中在门上（如生产发布需具名的 release manager 授权）。
原文点睛之句：“The skill makes violations rare and the hook makes them close to impossible.”
受监管企业的 managed settings 配置要点：
| 配置项 | 作用 | 常见配置位置 |
|---|---|---|
permissions.deny |
禁止 agent 读取 .env*、./secrets/**，禁止 WebFetch、curl、wget |
repo / managed |
permissions.allow |
预批准安全的内循环命令（git *、make build/test/lint），减少审批疲劳 |
repo / managed |
disableBypassPermissionsMode |
禁止任何人通过命令行参数绕过权限规则 | 仅 managed |
sandbox |
OS 级文件/网络隔离，域名白名单阻止未授权外联 | 仅 managed |
credentials |
阻止沙箱命令读取 ~/.ssh、~/.aws/credentials，剥离环境变量中的密钥 |
仅 managed |
allowManagedHooksOnly |
仅允许平台管理的 hooks 运行，个人无法添加或替换 | 仅 managed |
allowManagedMcpServersOnly |
agent 的工具面是平台团队管理的白名单 | 仅 managed |
requiredMinimumVersion |
拒绝在低于批准版本的 Claude Code 上启动 | 仅 managed |
repo 级配置放进仓库的
.claude/settings.json（团队自助、随代码评审）；managed 级由平台/IT 通过管理控制台统一下发，工程师无法编辑或覆盖。受监管企业通常把 repo 级的两项权限配置也提升为 managed 管理。
任何 deny 都以能力为代价——正确的平衡取决于仓库的数据分类。
3.4. 确定性检测与统计规则
3.4.1. Western Electric 规则
Western Electric（西方电气公司，AT&T 的制造部门）1956 年在《Statistical Quality Control Handbook》里提出的一套控制图判异规则，用于判断一个过程是"只有正常随机波动"还是"已经失控"。它建立在带均值中心线和 ±1σ/±2σ/±3σ 控制带的图上，经典四条：
| 规则 | 条件 | 抓的是哪种异常 |
|---|---|---|
| Rule 1 | 单点超出 ±3σ | 大的突刺（spike） |
| Rule 2 | 连续 3 点中有 2 点在同侧超出 ±2σ | 中等幅度的突然偏移 |
| Rule 3 | 连续 5 点中有 4 点在同侧超出 ±1σ | 小幅度的持续偏移 |
| Rule 4 | 连续 8 点落在中心线同一侧 | 缓慢漂移（drift） |
四条合在一起，既能抓突发的尖峰，也能抓渐进的退化——而固定阈值（比如"失败率 > 5% 就报警"）只能抓前者，对缓慢漂移无能为力。
3.4.2. 检测完全确定性、不涉模型
这是原文一个刻意的架构选择：
- 检测脚本只是算术：取滚动窗口的均值和标准差，数有几个点落在哪个 σ 带外，套用上述 if 规则。同样的输入永远得出同样的结论，可单元测试、可版本控制、可审计。
- 它不让 AI 模型来判"这是不是异常"。模型判异常是概率性的：同一份指标数据跑两次可能给出不同结论，会"幻觉"，无法被审计员复核。
- 模型只在规则已经触发之后才登场——去做"为什么偏了、怎么修"的诊断，而且行动还要再过一道审批门。
3.4.3. 把判断权交给统计规则
在 AI-native SDLC 里，有一种诱惑是让 AI 顺手把监控也做了。但"要不要启动调查"这个决定，恰恰最需要可靠、可复现、可审计，而不是聪明。所以原文把职责切得很干净：
- 统计规则：决定"何时算异常、严重到哪一级"——确定性，像 hook 一样无例外、无情绪；
- AI agent：决定"异常是什么、怎么修"——擅长解读上下文，但行动受门约束；
- 人：决定"修不修、什么时候修"——判断与授权。
这和全文的三层控制模型（skill 咨询 → hook 确定性 → human gate 判断）是同一个思想：越是"必须每次都成立"的环节，越要用确定性机制兜底，把 AI 的不确定性挤到后面去。审计员能读脚本、能复盘"为什么 2σ 触发了"，但没法复盘"模型当时为什么觉得不对"——这正是受监管组织能接受这套闭环的前提。
3.5. 度量文化
每个剧本都定义了领先/滞后指标，且几乎全部可从 git 历史、PR 元数据、CI 日志、OpenTelemetry 导出中自动读取——例如 intent.md 与 spec.md 两次提交之间的间隔、构建开始后的 spec.md 返工次数、首次 CI 通过率、每工程师并行会话数、门禁等待时长。度量本身也被工程化，不靠人填报表。
4. 我的理解与思考
4.1. 这套流程真正解决的不是"写代码"，而是"过程可审计"
表面看 AI-native SDLC 是效率工程，细读会发现它的重心是用机器可读的 md 工件链重建可审计性。敏捷时代我们甩掉了文档，换来的是知识驻留在少数人脑中、过程不可追溯；AI 时代文档以"人机共读"的形式被请了回来——intent.md 既是给产品负责人看的备忘录，也是下一阶段 agent 的输入。这解释了为什么原文反复强调"git 提交链就是审计链"：对受监管组织，可追溯性是采纳 agent 的前置条件，而不是副产品。
4.2. 这套流程是 SDD 和 TDD 的融合
AI-native SDLC 的本质，是**规格驱动开发（Spec-Driven Development，SDD）与测试驱动开发（Test-Driven Development，TDD）**在 agent 时代的融合。
- SDD 一侧：
intent.md→spec.md→plan.md构成规格链，规格先于代码存在、驱动代码生成，并充当后续评审的对照基准。这是"左移"的极致——把所有对齐成本压到写代码之前。 - TDD 一侧：反馈回路（测试、构建、截图比对）让会话在人看到之前自证；bug 修复先提交失败的测试；evals 给 agent 配置做回归；维护阶段的控制带与事故 eval 把防线延伸到生产之后。
- 融合点：规格回答"做什么"，测试回答"怎样才算做到"；两者都是机器可执行的验收标准，且都在代码之前提交。传统 SDD 的规格写完即过期（文档与代码脱节）；TDD 虽测试先行，但测试始终是开发者的私人契约，难以充当跨角色、可机读的验收基准。而 agent 让"规格→代码→测试"的往返成本趋近于零，规格才第一次能够持续地驱动开发而不是一次性地描述它。
对日常编码的启示：与其把精力花在逐行检查生成的代码上，不如花在**写好规格（intent/spec/plan）和定义好测试（验收标准）**上——这两端是人最能施加杠杆的地方，中间的代码生成反而是流水线上最便宜的一环。
4.3. 对具体编码的指导作用
以下是对 4.2 论点的操作化展开：4.2 说"把精力花在规格和测试两端"，本节给出具体怎么做。
- 把返工从 diff 阶段提前到文档阶段。改一段 markdown 和改一个已实现的 diff，成本差一个数量级。plan mode 的价值正在于此：先盘问计划（会破坏什么？哪步最险？放弃了哪些备选？），迭代到"没参与对话的工程师也能照计划实施"才放行。日常编码中，这意味着写码前先让 agent 出计划、自己审计划，而不是等 diff 出来再返工。
- 知识外置，错误变资产。
CLAUDE.md的"同一错误犯两次就写入"是一条可以立刻落地的规则：每次 agent 犯重复错误，就是一次免费的知识沉淀。长此以往，团队的约定、命令、坑从 wiki 和口口相传变成每次会话自动加载的上下文——团队知识完成了"服务化"。 - 验收目标必须可机检。"代码质量好"对 agent 无效，"make test 全绿、lint 零告警、截图与 mock 一致"才有效。给 agent 的每个任务都应附上量化的完成判据，并要求它在报告完成前贴出证据输出。
- 不能让被考核者改考核标准。测试阶段"hook 阻止 agent 在修复任务中编辑测试文件"这一细节极具启发性：agent 修 bug 时最省事的路径是改测试让它通过，hook 从机制上堵死了这条路。凡是"执行者有动机弱化检查"的地方（测试、指标、日志），都值得一个确定性护栏。
- bug 修复的 TDD 变体：先让 agent 把 bug 复现成一个失败的测试并提交，再让它在不碰测试的前提下修复。先于修复存在、agent 无法改写的测试，才是"虫子已死"的证明。
4.4. 如何提高编码效率
- 并行度的新约束是"审"，不是"写"。原文明确：并行会话的上限是"一个人能好好审几路"，评审跟不上就不加会话。因此提效的杠杆从产出侧移到了消费侧——用
REVIEW.md收敛 nit、让 agent 附上机械证据、人只判断意图与风险，都是在扩大"审"的吞吐。 - 子代理保护主上下文。researcher 型子代理探索代码库后只回报结论，不把搜索过程灌进主上下文；verifier 用全新上下文做终检，避免"写代码时的假设污染验收判断"。这是对抗上下文膨胀和确认偏误的实用模式。
- auto mode 是挣来的，不是默认的。自动接受的前提是护栏成熟：调优过的
CLAUDE.md、编码政策的 skills、阻断危险动作的 hooks、agent 能自己跑的测试套件。信任分级递进——小爆炸半径+测试已覆盖的常规工作先自动化，高风险路径永远留人工门。 - 配置即代码，evals 是它的回归测试。
CLAUDE.md、skills、hooks 这些"引导 agent 的配置"直接决定产出质量，理应像代码一样被回归测试：换模型、改提示词、改 skill 时跑一遍 20–50 个真实任务的 eval 套件，通过率下降的配置变更不得合并。这是 agent 工程区别于传统脚本工程的核心实践。
4.5. 批判性思考与边界
- 落地有轻重之分。最轻量的起步组合与采纳顺序见 3.6：原文推荐
CLAUDE.md+ plan mode + 反馈回路（零流程改造），个人场景亦可从CLAUDE.md+intent.md起步。不必整套照搬，原文的依赖关系也明确支持按需选路。 - 合规不能寄托在 prompt 上。skill 是咨询性的，session 可以不遵守；凡是"必须无例外成立"的政策，背后必须有 hook 或评审 pass 兜底。把这条原则推广开：任何以自然语言表达的控制都应视为"尽力而为"，确定性控制才是底线。
- 与静态分析的互补。模型驱动的扫描覆盖"依赖上下文、难以写成规则"的漏洞，确定性静态检查留在 CI 兜底；扫描发现走 PR 评审门而非直接入库，覆盖率的时效以"最后一次运行"计。规则引擎与模型扫描是互补关系而非替代关系——正如 skill 与 hook 的分工。
- 闭环的自喂养值得警惕。维护阶段的自动闭环（指标越界 → headless 诊断 → 新
intent.md）效率极高，但噪声会自我放大：被驳回的发现必须带理由记录并回馈调优控制带，否则 triage 队列会被自动生成的 intent 淹没。自动化闭环的瓶颈最终落在人的分诊带宽上——这再次印证：整条 SDLC 里，人的注意力永远是最稀缺、也最该被精打细算的资源。
5. 总结
-
AI-native SDLC 的核心论点可以用一句话概括：当代码生成不再是瓶颈，真正的杠杆转移到规格、测试和治理。
-
六个阶段的工件链（
intent.md→spec.md→plan.md→ diff+tests → PR+review → incident）既是协作媒介，也是审计记录； -
三层控制（skill 咨询 → hook 确定性 → human gate 判断）把 AI 的不确定性挤到后面；度量全部从 git/PR/CI 元数据自动读取。
-
对个人而言，最低成本的起步点见 3.6：原文推荐
CLAUDE.md+ plan mode + 反馈回路，个人观点认为CLAUDE.md+intent.md更轻量； -
对组织而言，闭环的瓶颈最终落在人的分诊带宽上——人的注意力永远是最稀缺、也最该被精打细算的资源。
6. 参考
- The AI-Native SDLC playbook
- 点赞
- 收藏
- 关注作者
评论（0）