本文讨论的不是“哪个模型写代码更快”，而是当代码生成速度大幅提升后，团队该怎样重构从意图、设计、实现、验证到生产反馈的完整系统。读完你会得到一条从最小产物链、自动验证到渐进授权的落地路径。
为什么局部编码提速不等于系统交付提速； 如何用结构化 Artifact 把 SDLC 变成可执行闭环； 规划、设计、开发、测试、发布、维护六个阶段怎样变化； 为什么真正要建设的是 Harness，而不只是 Prompt； 普通团队如何从最小产物链开始落地。
先解释一个概念：什么是 SDLC？
SDLC 是 Software Development Life Cycle 的缩写，中文通常译为“软件开发生命周期”。它描述的不是单独的编码阶段，而是一项软件工作从产生想法到持续运行的完整过程：
明确问题 → 规划需求 → 设计方案 → 开发实现 → 测试验证 → 部署发布 → 运行维护 → 收集反馈
在传统团队里，这些活动经常表现为一条由不同角色接力的流水线：产品写需求，设计出方案，工程师编码，测试人员验证，运维人员发布。只要其中一个环节处理不过来，后面的工作就会排队，整条系统的交付速度也会被它限制。
因此，AI-Native SDLC 不是在旧流程中增加一个“AI 写代码”环节。它要重新设计整个生命周期，让意图、规范、计划、代码、验证证据和生产反馈都成为 Agent 可读取、可执行、可追踪的工程产物，同时保留必要的人类判断和确定性护栏
2026 年，软件团队最容易出现的一种错觉是：
既然 Agent 可以在几分钟内生成过去几天才能写完的代码，那么研发效率自然也会提高十倍。
但现实往往是，代码很快生成了，需求还在等待确认；PR 数量增加了，评审队列却越来越长；测试环境开始拥堵，安全审查跟不上，最后连发布窗口都成了稀缺资源。
代码变快了，软件却不一定更快到达用户手中。
Anthropic 在《The AI-Native SDLC playbook》中提出了一个很重要的判断：代码已经不再是软件开发中唯一、甚至不再是最主要的瓶颈。当 Build 阶段从几天压缩到几小时，瓶颈会转移到它的左右两侧——规划、设计、评审、测试、发布和治理。
因此，真正需要被重新设计的不是“写代码”这个动作，而是从一个想法产生，到它进入生产环境，再到运行反馈重新变成下一项工作的完整系统。
这才是 AI-Native SDLC 的核心。
一、局部生产力，不等于系统吞吐量
理解这件事，可以借用约束理论里一个朴素的结论：
一个系统的吞吐量，不取决于其中最快的环节，而取决于最慢的约束。
传统研发流程通常包含规划、设计、开发、测试、部署和维护。过去代码主要由人逐行编写，Build 占据了大量时间，因此很多组织围绕“人类写代码的速度”设计了后面的评审与发布能力。
Agent 改变了这个比例，却没有自动改变整条流水线。
如果代码产出提高五倍，但评审、测试和部署能力没有变化，系统不会获得五倍吞吐量，只会获得更长的等待队列、更大的变更批次，以及更多来不及被认真检查的代码。
DORA 2025 年对接近 5000 名技术从业者的调查很好地说明了这一点：90% 的受访者已经在工作中使用 AI，超过 80% 认为 AI 提高了生产力；AI 使用与交付吞吐量和产品表现之间已经出现正相关，但它与软件交付稳定性仍然呈负相关。
DORA 给出的结论不是“AI 没有用”，而是：AI 是放大器。
拥有清晰工作流、自动化测试、成熟版本控制、快速反馈和良好内部平台的团队，会被 AI 放大；流程混乱、架构耦合、反馈缓慢的团队，同样会被 AI 放大，只不过被放大的是原有的问题。
这也解释了为什么关于 AI 编程效率的研究，看起来经常互相矛盾。
早期 GitHub Copilot 的受控实验里，开发者完成一个边界清楚的 JavaScript HTTP Server 任务，使用 Copilot 的实验组快了 55.8%。
但 METR 在 2025 年让 16 名资深开源开发者处理自己熟悉的大型项目，涉及 246 个真实 Issue，得到的结果却是：允许使用当时的 AI 工具后，开发者平均慢了 19%。更有意思的是，他们事前以为自己会快 24%，实验结束后仍然觉得自己快了 20%。
这两个结果并不冲突。
边界清晰、验证简单、上下文较少的任务，很容易从代码生成中获益；成熟代码库里的真实任务，则包含大量隐性约束、历史知识、架构判断、测试标准和沟通成本。如果这些信息没有进入 Agent 可以读取和验证的环境，生成代码越快，返工也可能越快。
METR 在 2026 年的后续说明中认为，新一代 Agent 很可能已经带来了更明显的加速，但多 Agent 并发、任务选择偏差和开发者不愿放弃 AI 等因素，也让传统的“单任务用时”越来越难准确衡量真实价值。
所以真正的问题已经不再是：
AI 一小时能写多少代码？
而是：
从意图产生到价值交付，整个系统能否更快、更稳定地完成一次闭环？
二、把 SDLC 从流水线变成可执行的工作图
Anthropic 给出的方案，是把传统线性 SDLC 改造成一个持续运行的循环，并让每个阶段都留下下一阶段可以读取的结构化产物：
intent.md → spec.md → plan.md → 代码与测试 → PR 与审查记录 → 生产反馈 → 新的 intent.md
这些文件名本身并不重要，重要的是它们建立了一种 Agent 可以理解的工作协议。
intent.md 记录为什么要做：问题是什么、服务谁、期望结果是什么、有哪些约束、哪些问题尚未解决。
spec.md 记录要做成什么：功能行为、交互方式、技术边界，以及安全、品牌、合规和体验要求。
plan.md 记录准备怎样做：要修改哪些文件、按什么顺序实施、如何测试、有哪些风险和回滚方式。
代码、测试输出、截图差异和构建日志，负责回答“实现是否真的满足计划”。
PR、审查结果和生产记录，则构成可追踪的决策与证据链。
这样做有三个价值。
价值一：减少隐性上下文
OpenAI 在 Harness Engineering 的实践中提到：从 Agent 的角度看，运行时无法访问的东西，实际上就不存在。存在 Slack 对话、Google Docs 或某位资深工程师脑中的知识，如果不能被 Agent 检索，就无法稳定影响它的行为。
因此，真正的 Context Engineering 不是把更多聊天记录塞进提示词，而是把必要知识变成仓库内可发现、可版本化、可验证的资产。
价值二：让阶段之间自动交接
当 intent 被批准后，可以自动触发 spec 生成；spec 被接受后，Agent 可以生成 plan；plan 被审核后，执行 Agent 开始实现；验证通过后再进入 PR 审查。
交接不再依赖某个人记得开会、复制文档或者更新工单，而是由产物的状态变化触发下一步。
价值三：形成天然的审计轨迹
谁批准了意图、Agent 当时读取了哪个版本的规范、为什么修改这些文件、执行了哪些测试、谁授权进入生产，都可以通过提交、日志和审批记录被追溯。
对于大型组织，这一点甚至比代码生成速度更重要。
三、六个阶段分别会发生什么变化
1. 规划：帮助人澄清意图
发起者与 Agent 讨论真实问题，Agent 将零散信息整理成 intent.md。产品负责人仍然决定问题是否值得解决，但不必从空白文档开始反复搬运信息。
2. 设计：让组织规范提前生效
安全、隐私、品牌、合规、UX 等要求不再只在开发结束后由不同团队逐项检查，而是被编码成 Agent 能读取的 Skills 或策略，在 spec 形成时就暴露冲突。越早发现问题，返工成本越低。
3. 开发：默认先计划，后执行
Agent 先读取 spec 和仓库，只生成 plan.md，不修改代码。工程师检查文件范围、实现顺序、测试方案和风险，再允许它执行。
这里的关键不是多写一份文档，而是把过去只存在工程师脑中的实现路径，提前变成可以审查的对象。审查计划通常比审查一个已经完成的大型 Diff 更便宜。
4. 测试：必须拥有即时反馈回路
Agent 修改代码之后，应该能自己运行测试、构建、Lint、类型检查，前端任务还应能操作浏览器或查看截图。没有反馈回路的 Agent，本质上仍然只是在“猜代码”。
修复 Bug 时，先建立能够稳定复现问题的失败测试，再修代码，并在修复期间阻止 Agent 随意修改这个测试。否则它可能不是解决了问题，而只是重新定义了什么叫成功。
5. 发布：人转向判断意图与风险
当代码生成速度远高于人类阅读速度时，“所有代码都由人逐行检查”无法长期扩展。更现实的方式，是让不同的 Agent 分别进行逻辑、安全、规范和计划一致性审查，确定性 CI 负责硬性检查，人类把注意力放在业务意图、高风险边界和生产授权上。
6. 维护：让生产反馈重新进入循环
监控系统仍然用确定性指标发现错误率、延迟、成本或安全信号越界，Agent 负责收集日志、追踪变更、形成诊断，并将较大的问题写成新的 intent.md。小问题可以自动形成 PR，大问题重新进入正式规划。
每次生产事故还应该沉淀为新的回归测试或 Agent Eval，避免系统用另一种方式再次犯同类错误。
四、真正需要建设的不是 Prompt，而是 Harness
只讨论模型和提示词，很容易错过 AI-Native SDLC 最重要的工程层。
一个能长期稳定工作的编码 Agent，至少需要三层系统：
最上层是人类判断：定义目标、处理价值冲突、判断风险、批准不可逆操作和生产发布。
中间层是 Agent 执行：阅读上下文、生成计划、修改代码、调用工具、运行验证、处理审查意见和诊断故障。
底层是确定性护栏：测试、Lint、类型系统、结构检查、Hooks、CI、沙箱、最小权限和短期凭据。
Agent 可以有自主性，但不能拥有没有边界的自主性。
Anthropic 在 Building Effective Agents 中建议：先从简单方案开始，只有在评估证明复杂结构确实改善结果时，才增加多阶段或多 Agent 系统；同时要让规划过程透明，并认真设计 Agent 与计算机之间的工具接口。
OpenAI 的 Harness Engineering 案例也得出了相近结论。他们用 Codex 构建了一个没有人工手写代码的内部产品，五个月内形成约一百万行代码和约 1500 个 PR，估计开发时间约为手写方式的十分之一。
但真正让这个实验能够运行的，不是一个神奇 Prompt，而是一整套面向 Agent 的环境：可读取的仓库知识、严格的架构边界、自定义 Lint、结构测试、按 Worktree 隔离的应用实例，以及 Agent 能直接查询的日志、指标和 Trace。
当代码吞吐量增加后，他们最先遇到的新瓶颈之一，恰恰是人类 QA 能力。
这再次说明：模型能力决定上限，Harness 决定你能稳定获得多少能力。
五、不要把 Markdown 文件变成新的流程表演
Anthropic 的方案很容易被表面模仿：建立 intent.md、spec.md、plan.md，再加一个 CLAUDE.md，似乎就完成了 AI-Native 改造。
但文件不是目的，闭环才是目的。
如果 intent.md 只是把模糊 Jira 工单重新复制一遍，它没有减少不确定性。
如果 plan.md 生成后没人检查，或者执行过程中完全不更新，它只是一份看起来专业的装饰。
如果测试无法一条命令运行、环境不能稳定复现、日志 Agent 看不到，再长的 CLAUDE.md 也弥补不了环境缺失。
如果 Skills 写着“必须遵循安全规范”，却没有 Hook、CI 或权限系统进行强制，它仍然只是一条建议。
正确的分工应该是：
文字产物表达意图和上下文；
Agent 负责推理、执行和迭代；
确定性工具负责证明和阻断；
人类负责价值判断与最终责任。
六、普通团队可以怎样开始
不需要第一天就建设完整的 Agent 开发平台。可以从一条真实、重复出现的开发路径开始。
第一步：测量现状
记录从需求确认到进入生产的总时间，以及时间实际花在编码、等待评审、修复 CI、测试、审批和返工中的比例。不要只统计 Agent 生成了多少代码。
第二步：建立最小产物链
先采用 intent、plan 和验证记录三个产物。小任务不一定需要独立 spec，但必须让“为什么做、准备怎样做、如何证明做对了”有明确答案。
第三步：把验证压缩成一条命令
让 Agent 能在没有人工解释的情况下完成构建、测试、Lint 和必要的端到端检查，并以非零退出码报告失败。
第四步：把重复纠正升级成系统规则
第一次错误可以人工提醒；同类错误第二次发生，就应考虑写入仓库说明、Skill、Lint、Hook 或回归测试。越重要的规则，越不能只依赖自然语言提醒。
第五步：只逐级增加自主性
先允许 Agent 读取和规划，再允许它在隔离环境中修改，然后允许自动开 PR，最后才考虑低风险变更的自动合并。生产发布、权限提升、数据删除等不可逆操作，继续保留明确的人类授权。
最后：用系统指标评估结果
真正值得追踪的是：从 intent 到上线的 Lead Time、首次 CI 通过率、返工次数、审查等待时间、变更失败率、恢复时间，以及同类事故是否复发。
结语
AI-Native SDLC 最深刻的变化，不是程序员从此不写代码，而是工程师的主要工作正在向更高一层移动。
过去，我们把大量精力用在把已经明确的方案翻译成代码。
现在，越来越多的精力会转向定义意图、设计边界、建设反馈回路、编码组织知识、维护评估体系，以及决定哪些动作可以交给 Agent，哪些必须由人负责。
所以，AI-Native SDLC 并不是：
AI 写代码，人负责收尾。
它更接近：
结构化产物驱动工作，Agent 执行可重复劳动，确定性系统提供证据与约束，人类掌握意图、风险和最终授权。
代码生成只是入口。
真正的竞争力，是能否把整个组织改造成一个 Agent 看得懂、做得动、验得过、出了问题还能重新进入循环的工程系统。
参考资料
1. Anthropic：The AI-Native SDLC playbook
网址：https://claude.com/blog/the-ai-native-sdlc-playbook
2. Google Cloud：2025 DORA State of AI-Assisted Software Development
网址：https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
3. OpenAI：Harness engineering: leveraging Codex in an agent-first world
网址：https://openai.com/index/harness-engineering/
4. METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
网址：https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
5. METR：We are Changing our Developer Productivity Experiment Design
网址：https://metr.org/blog/2026-02-24-uplift-update/
6. Microsoft Research：The Impact of AI on Developer Productivity
网址：https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/
7. Anthropic：Building Effective Agents
网址：https://www.anthropic.com/engineering/building-effective-agents
8. Anthropic：Effective harnesses for long-running agents
网址：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
订阅智宅客
AI / 技术 / 数字生活方式，新文章第一时间送到邮箱。
