本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。
AI 带来的真正变化，不是程序员少写了多少代码，而是企业必须重新设计从意图、实现、验证到生产反馈的整个软件生产系统。
过去一年，关于 AI 如何改变软件工程的讨论很多。但现在真正值得追问的，已经不是“AI 能不能写代码”，而是一个更深层的问题：
当代码能够被快速、规模化地生成，我们是否拥有同样强大的能力，去定义、验证、治理和维护这些代码？
为了回答这个问题，今天咱们系统研究并交叉比较了四份来自 Google、OpenAI、Anthropic 和 LangChain 具有代表性的行业材料。它们讨论范围也不完全相同，却逐渐汇聚到一个共同结论：AI 对软件工程最大的影响，不是提高某个开发环节的效率，而是迫使企业重新设计整个软件开发生命周期。
Google 发布的 《The New SDLC with Vibe Coding: From Ad-hoc Prompting to Agentic Engineering》 从宏观层面描述了软件开发从 vibe coding 走向 agentic engineering 的过程，提出 Context Engineering、Harness Engineering、Factory Model，以及开发者从 Conductor 转向 Orchestrator 等关键概念。它强调的核心分界不是“是否使用 AI”，而是 AI 输出周围是否存在充分的规格、测试、约束、反馈和人工判断。
LangChain 发布的《The Agent Development Lifecycle》将视角延伸到 Agent 产品的生产环境，把生命周期概括为 Build → Test → Deploy → Monitor，并在外层加入持续迭代和治理。它特别强调：传统软件监控关注服务是否正常运行，而 Agent 监控还必须回答它是否选择了正确工具、遵循了正确路径、使用了正确上下文，以及是否真正完成了任务。
Anthropic 发布的《The AI-Native SDLC Playbook》则提供了一套更接近企业落地的流程蓝图：从 intent.md、spec.md、plan.md，到代码、测试、Pull Request、审查记录和生产事故，每个阶段都产生一个既能被人理解、又能被 Agent 继续处理的版本化制品。它还明确区分了 Skills 与 Hooks：前者告诉 Agent“应该怎样做”，后者从技术上限制 Agent“不能怎样做”。
OpenAI 发布的《Building an AI-Native Engineering Team》把重点放在团队工作方式上。它通过 Delegate、Review、Own 三种责任关系，重新划分规划、设计、构建、测试、审查、文档和部署维护中的人机边界：Agent承担第一轮分析和机械执行，人类负责复核完整性，并继续拥有产品意图、架构取舍、质量和生产风险的最终责任。
这四份材料并不是四个版本的同一套方法论。
Google提供的是范式与总体框架；LangChain关注Agent产品如何持续运营；Anthropic提供制品链、控制点与企业流程；OpenAI讨论工程团队如何重新分工。正因为它们的出发点不同，它们共同强调的内容才更值得重视：
- 代码生成正在从稀缺能力变成基础能力；
- 软件交付的瓶颈正在向需求、验证、审查和治理迁移；
- 模型能力不能单独决定工程结果，Context与Harness同样重要；
- 测试、Evals、运行轨迹和生产反馈必须形成持续闭环；
- 人类不会退出软件开发，但会从主要实施者转向意图定义者、系统设计者和风险责任人。
当然，这些材料主要来自AI模型和Agent平台提供方，不能被视为完全中立的学术研究。它们给出的生产率数字、企业案例和工具建议，也带有各自的产品背景。因此，本文不会简单复述四家机构的观点，而会重点分析它们相互印证的部分、各自没有充分回答的问题，以及企业真正落地时必须面对的成本、风险和组织约束。
综合来看，四份材料共同指向了一个关键判断：
AI Native SDLC不是在传统流程中加入更多AI，而是把需求、组织知识、质量标准、安全政策和生产反馈，重新构造成Agent可读取、可执行、可验证、可审计的工程系统。
过去，软件工程的核心工作是把人的意图翻译成代码。现在，代码翻译本身正在被自动化，真正稀缺的能力变成了另外几件事：能否准确表达意图，能否设计可靠的验证机制，能否控制Agent的行动边界，以及能否对最终结果作出专业判断并承担责任。
---
代码更快了，为什么项目不一定更快？
AI编码工具最容易制造的一种错觉是：代码生成速度提高了，整个项目自然也会同比加速。
但软件交付从来不是单一环节，而是一条完整的价值流。只加速其中一个阶段，通常只会把瓶颈推向其他地方。
当实现工作从数周压缩到数小时，规划、测试、代码审查、发布审批和安全治理仍然以人的速度运行。如果这些环节没有同步升级，团队就会面临两个结果：
一方面，Agent生成的变更大量堆积在审查队列中，工程师从“编写代码的瓶颈”变成“审核AI输出的瓶颈”；另一方面，为了追求速度，团队可能降低审查标准，让未经充分验证的代码进入生产环境。
这也是为什么AI带来的局部生产率提升，未必会自动转化为组织层面的交付能力。
真正需要衡量的，不是Agent生成了多少代码，而是从一个意图提出，到可靠结果进入生产环境，整个系统花费了多长时间、经历了多少返工、消耗了多少人工注意力，并带来了多大的后续维护成本。
换句话说，AI Native SDLC的目标不是提高代码产量，而是提高“从意图到经过验证的业务结果”的整体吞吐量。
---
从AI辅助开发到AI原生开发
目前大多数团队所处的阶段，更准确地说是AI-assisted development，也就是AI辅助开发。
工程师在IDE里使用代码补全，通过对话生成函数或测试，遇到报错时再把错误交给模型。AI提升了某些局部任务的效率，但需求传递、架构设计、测试、代码审查、发布和生产治理仍然按照原来的方式进行。
AI Native SDLC则意味着重新设计这套系统。
两者之间至少存在五个本质区别。
第一，意图成为正式工程输入
在传统流程中，需求往往分散在会议记录、即时通信、工单和人的记忆中。Agent得到的通常只是其中一个经过多次转述的片段。
在AI Native流程中，意图必须被结构化和版本化。它需要说明问题是什么、为什么值得解决、影响哪些用户和系统、有哪些约束、哪些内容不在范围内，以及怎样才算成功。
AI可以帮助提出问题、发现遗漏，但不能替组织决定优先级和业务价值。意图的准确性和最终取舍仍然需要人类负责。
第二，组织知识变成可执行上下文
过去，代码规范、架构原则、安全要求和常见错误可能存在于Wiki、文档或资深工程师的经验中。对新员工来说，这些信息难以发现；对Agent来说，它们甚至可能完全不可见。
AI Native团队会把这些知识转化为规则文件、Skills、工具定义、检索系统、代码示例和验证命令，让Agent在执行任务时得到与成熟工程师相近的工作背景。
第三，验证与生成同时发生
传统测试经常位于实现之后。AI Native开发要求Agent在把结果交给人类之前，先运行构建、测试、lint、静态分析和必要的视觉检查，并根据真实结果自行迭代。
“完成”不再意味着Agent停止生成，而意味着它能够提交可检查的证据。
第四，治理发生在行动时
安全和合规要求不能只写在政策文件或Prompt里。哪些目录不可修改、哪些凭据不可读取、哪些网络不可访问、哪些生产操作必须审批，都需要由权限、沙箱、Hook、CI和身份系统强制执行。
第五，生产反馈重新进入开发循环
生产事故、用户反馈和Agent运行轨迹不再只是事后分析材料。它们需要转化为新的需求、回归测试、Eval样本、规则或监控信号，进入下一轮开发。
这使软件开发从一条“需求到上线”的单向流水线，转变为一个持续学习的闭环：
Intent → Spec → Plan → Build → Verify → Review → Deploy → Observe → New Intent
---
从vibe coding到agentic engineering
Vibe coding的价值不应该被低估。
对于原型、个人工具、一次性脚本和探索性工作，它能够显著降低创造软件的门槛。开发者可以用自然语言表达想法，在极短时间内得到一个可运行的结果。
问题在于，生产软件不能只满足“看起来可以运行”。
支付、身份认证、数据基础设施和企业核心业务需要回答更严格的问题：边界条件是否完整？错误是否被正确处理？依赖是否真实存在？系统是否遵循既有架构？权限是否符合最小化原则？未来的团队是否能够理解和维护这些代码？
Agentic engineering与vibe coding的区别，并不在于使用哪个模型或工具，而在于AI输出周围存在多少结构、约束和验证。
一个周末原型可以依赖“运行一下，看起来没问题”；一个生产系统则必须拥有正式规格、测试与Evals、确定性门禁、审计记录和明确的人类责任。
这不是非黑即白的选择。不同任务可以位于不同的风险等级：
- 原型和探索可以允许较高自由度；
- 普通业务功能可以由Agent实现并自测，但由工程师批准计划和合并；
- 身份、支付、数据和基础设施变更则需要更严格的架构、安全和生产审批。
真正成熟的团队，不会要求所有任务采用同一种自治程度，而是根据风险、可逆性和验证能力动态决定人机边界。
---
新的软件生产链：从意图制品到生产反馈
Anthropic提出的制品链提供了一种很有代表性的AI Native工作方式：
`intent.md → spec.md → plan.md → 代码与测试 → PR与审查记录 → 事故记录 → 新intent.md`
文件名不是重点。重点是每个阶段都会产生一个既能被人理解，又能被Agent继续处理的正式制品。
规划：让最初的意图少经历几次转述
传统需求经常经历多层交接：业务人员提出问题，产品经理整理需求，分析师补充细节，工程师再把它解释成技术方案。每次转述都可能造成信息损失。
在AI Native流程中，最初提出问题的人可以直接与Agent对话，将问题、目标、约束、影响范围和开放问题整理成意图制品。
Agent还可以结合代码库判断哪些服务会受影响、现有能力能否复用、需求中是否存在明显矛盾。
但优先级、商业价值和战略方向仍然必须由人决定。Agent可以分析“能否做”和“可能怎样做”，不能替组织决定“是否应该做”。
设计：在代码产生之前处理风险
获得明确意图后，Agent可以结合代码库、设计系统、安全政策和历史架构，生成初步规格，列出实现方案、依赖关系、风险和待决事项。
这会改变政策应用的时间点。
过去，安全、合规或架构问题可能在数周后的审查中才被发现；现在，相关政策可以在规格产生时就被读取和应用。
但是，一致性与可用性、短期速度与长期维护、复杂度与扩展性、构建与采购等架构取舍，仍然依赖业务背景和组织战略。AI可以扩大方案空间，却不能替组织承担选择的后果。
构建：先审查计划，再生成代码
传统开发中，工程师往往直接开始实现。会修改哪些文件、采用什么顺序、如何证明功能正确，可能只存在于个人脑中。
AI Native开发更强调“先计划，后实现”。
Agent先阅读意图、规格和代码库，形成实现计划，说明：
- 哪些文件和模块需要变化；
- 实施顺序是什么；
- 存在哪些风险和集成点；
- 哪些方案被考虑过但没有选择；
- 哪些测试能够证明功能正确。
工程师在代码产生之前修正计划，因为此时改变方向的成本最低。计划被接受后，Agent才开始实施；如果实现偏离计划，相应制品也需要同步更新。
这样，代码审查就不再只是阅读一个突然出现的巨大diff，而是可以判断实现是否忠于意图、是否遵循计划，以及偏离是否合理。
---
测试正在从阶段变成语言
在AI Native SDLC中，测试不仅用于检查代码，也成为向Agent表达意图的一种方式。
自然语言很容易产生歧义，而可执行测试能够更精确地说明系统在给定条件下应该怎样表现。
这使测试的重要性进一步提升：生成能力越强，团队越需要一个不可轻易误解的事实来源。
Agent可以阅读需求和实现，提出边界案例、故障路径和属性测试；它也可以运行测试，根据失败结果进行修复。但这并不意味着测试可以完全交给Agent。
如果同一个Agent同时编写实现和测试，它可能把同一个错误假设带入两者。更危险的是，Agent可能通过删除失败测试、降低断言强度或使用Stub，让结果“看起来通过”。
因此，生产级流程需要建立独立验证：
- 在实现前确定关键验收条件；
- 验证新测试在功能实现前确实会失败；
- 将实现与最终验证放在不同会话或不同Agent中；
- 禁止修复任务删除或弱化失败测试；
- 对UI工作加入截图或浏览器验证；
- 对模型、Prompt、Skill和工具更新运行回归Evals；
- 将生产事故转化为永久回归案例。
验证系统的意义，不只是发现错误，更是降低人类审查每一行代码的必要性。机械证据越充分，人类越能把注意力放在意图、架构和风险上。
---
普通软件需要测试，Agent产品还需要Evals
这里必须区分两种常被混为一谈的AI Native。
一种是使用Agent开发普通软件；另一种是开发的软件本身就是Agent。
对于普通软件，测试主要验证确定性行为：输入是否产生预期输出，状态是否正确变化，接口是否符合契约。
Agent产品则存在更多非确定性。它可能最终给出一个看似合理的答案，却在过程中调用了错误工具、跳过了审批、使用了不可靠数据，或者执行了大量无效步骤。
因此，Agent Development Lifecycle除了传统测试，还需要：
- 代表真实任务的数据集；
- 标准和评分规则；
- 多轮交互模拟；
- 完整工具调用轨迹；
- 人工与模型评审；
- 用户反馈和行为信号；
- 版本间对照实验；
- 对成本、延迟和工具使用效率的监控。
对Agent来说，“服务没有报错”并不等于“任务成功完成”。
一个客服Agent可能正常返回了HTTP 200，却错误批准退款；一个研究Agent可能生成了流畅报告，却引用了不存在的依据；一个编码Agent可能通过了基础测试，却跳过安全检查。
传统可观测性回答系统是否正常运行，Agent可观测性还必须回答：它做了什么、为什么这样做，以及做得是否正确。
---
真正决定效果的，往往不是模型，而是Harness
团队采用Agent时，容易把所有成功或失败都归因于模型能力。
模型升级了，Agent似乎就更聪明；任务失败了，就认为模型还不够强。
这种判断过于简单。
模型只是推理引擎。让它能够完成实际工程任务的，是包围在模型之外的一整套Harness：
- 项目指令和规则文件；
- 代码库、架构和领域知识；
- 工具、API和MCP服务；
- 会话状态与持久记忆；
- 沙箱和执行环境；
- 权限、身份和凭据；
- 任务分解与Agent编排；
- Hooks与审批门禁；
- 日志、轨迹、成本和质量监控。
许多所谓的模型错误，实际是Harness设计错误：上下文不完整、工具描述模糊、反馈信号不足、权限过大，或者上下文窗口被无关信息占满。
这也是为什么Prompt Engineering正在进一步演化为Context Engineering。
好的上下文工程不是向模型提供尽可能多的信息，而是在正确时间提供完成任务所需的高信号信息。
必须始终遵守的项目规则可以放入基础指令；只与特定任务有关的知识应当按需加载；反复使用的组织流程可以封装为Skills；不能违反的要求则必须由Hook、权限和CI强制执行。
上下文过少，Agent会反复犯错；上下文过多，则会造成噪声、成本、注意力稀释和数据暴露风险。
因此，成熟团队需要像管理代码一样管理上下文：明确所有者、版本、审查流程、适用范围和回归测试。
---
Skills告诉Agent应该做什么，控制系统决定它不能做什么
AI Native SDLC的一个关键原则是：治理不能只存在于政策文档和Prompt中。
Skills适合编码组织知识，例如安全审查步骤、API设计规范、品牌要求和文档流程。它们能显著提高Agent遵守规则的概率，但本质上仍然属于建议性控制。
如果某条规则必须始终成立，就需要确定性机制：
- 受保护路径禁止Agent修改；
- 凭据、个人数据和生产秘密不能进入上下文；
- Shell命令只能在隔离环境中运行；
- 网络访问采用域名白名单；
- Agent使用独立身份和短期凭据；
- 所有代码变更必须通过Pull Request；
- Agent不能自行批准自己生成的代码；
- 生产部署必须获得命名责任人的明确授权；
- 所有允许、拒绝和覆盖行为都要留下审计记录。
治理的目标并不是让Agent什么都不能做，而是定义一条清晰的行动边界。
在开发环境中，Agent可以自由构建和测试；在预发布环境中，它可以执行更多操作，但需要留下证据；在生产环境中，它可以准备发布、分析状态、提出回滚建议，甚至触发预先批准的Runbook，但不能越过明确的生产门禁。
真正成熟的治理，不是增加更多会议，而是把政策嵌入行动发生的时刻。
---
工程师不会消失，但工作的重心正在变化
OpenAI提出的Delegate、Review、Own，为AI时代的人机分工提供了一个实用框架。
Delegate指适合交给Agent的工作：边界明确、重复、风险较低并且可以自动验证，例如脚手架、常规接口、测试初稿、依赖维护、文档更新和日志关联。
Review指Agent可以提供第一版，但需要人类检查其完整性和影响的工作，例如设计方案、性能分析、测试覆盖、代码审查和故障诊断。
Own则指组织必须由人承担责任的事项，包括产品方向、核心架构、风险接受、重大安全决策和生产授权。
这比笼统地说“Human in the Loop”更有价值，因为它明确了人在回路中究竟负责什么。
随着实现工作越来越多地交给Agent，工程师的角色正在转向：
- 定义意图和成功标准；
- 设计架构和工程边界；
- 分解与调度Agent任务；
- 维护上下文与Harness；
- 设计测试、Evals和反馈机制；
- 审查例外并接受剩余风险；
- 对最终结果承担责任。
这种变化不意味着工程基础能力不再重要。恰恰相反，如果工程师缺少调试、安全、性能和架构判断，就更难识别那些“看起来正确”却包含隐蔽错误的AI输出。
AI放大的不是工具本身，而是团队原有的工程文化。拥有清晰架构、良好测试和健康审查机制的团队会得到更大收益；基础薄弱的团队则可能更快地产生技术债务。
---
多Agent并不天然等于高效率
当一个工程师可以同时启动多个Agent时，团队很容易把并行度当作成熟度。
但并行Agent增加的是在制品数量，不一定增加最终吞吐量。
如果多个任务修改同一批文件，就会产生冲突；如果规划不足，Agent会在不同方向上重复工作；如果审查能力没有同步增加，大量结果会堆积在工程师面前。
因此，并行度的真正上限不是平台允许启动多少Agent，而是团队能够认真评估多少结果。
合理的做法是：
- 只并行处理文件和依赖相对独立的任务；
- 为每个任务使用独立分支或Worktree；
- 将研究、验证、代码简化等重复工作交给职责明确的子Agent；
- 限制同时在制的任务数量；
- 将审查质量和返工率与并发数一起观察。
如果并发增加后，变更量上升但返工、事故和审查等待也同步增加，这不是效率提升，只是把成本推迟到了价值流的下游。
---
AI Native SDLC的经济账，不能只看Token
Vibe coding看起来拥有极低的启动成本：一个订阅、一段Prompt，几分钟后就能得到可运行结果。
但低生成成本可能隐藏高昂的长期成本：
- 反复提示和修复造成的Token浪费；
- 不一致代码带来的维护负担；
- 缺失测试导致的生产缺陷；
- 安全问题的后期整改；
- 工程师理解陌生AI代码所需的时间；
- 模型和工具升级后的行为漂移。
Agentic engineering则需要更高的前期投入：规格、测试、Evals、规则文件、Skills、沙箱、Hook、可观测性和共享基础设施。
这些投入不会立刻表现为更多功能，却可能显著降低后续返工和事故成本。
不过，把这种差异简单描述为“高CapEx、低OpEx”仍然不够完整。企业需要计算的不只是Token，还包括人工审查时间、基础设施、治理成本、上下文维护、供应商切换风险以及生产事故。
更合理的经济指标是“每个被接受变更的综合成本”，而不是单次模型调用价格。
---
如何衡量AI Native转型是否成功
最危险的指标是代码行数、生成次数和Pull Request数量。它们奖励产量，却不代表价值。
更有意义的指标可以分为四组。
交付效率
- 从意图提出到验证通过的时间；
- 从计划批准到PR合并的时间；
- 部署频率；
- 审批门等待时间；
- 每名工程师可管理的并行工作量。
质量与可靠性
- 首次实现通过CI的比例；
- 每次变更的返工轮次；
- 严重问题在合并前被发现的比例；
- 缺陷逃逸率；
- 变更失败率与MTTR。
Agent质量
- Eval通过率及关键场景覆盖率；
- 工具调用正确率；
- 不必要调用和重复循环；
- 人工纠正频率；
- 生产事故进入回归集所需时间。
成本与治理
- 每个被接受变更的Token与基础设施成本；
- 人工审查分钟数；
- Agent越权和门禁阻止次数；
- 审计轨迹完整率；
- 政策覆盖率与例外数量。
这些指标必须组合观察。单纯追求速度，可能降低质量；单纯追求Eval通过率，也可能造成测试集过拟合。最终仍要回到业务结果、系统可靠性和总体拥有成本。
---
企业应该从哪里开始？
AI Native SDLC不需要一次性推翻现有流程。更稳健的方法，是让Agent自治程度随着团队的验证和治理能力逐步提高。
第一阶段：建立一个可验证的工作流
选择范围清楚、风险较低但真实存在的任务，例如测试补充、文档更新、小型缺陷修复或依赖维护。
为代码库建立精简的规则文件，将构建、测试和lint封装成Agent可以直接运行的命令，并记录Agent的执行轨迹、人工修改和失败原因。
此时，Agent只创建分支或Pull Request，不直接修改主分支和生产环境。
第二阶段：建立制品链与确定性边界
开始使用正式的意图、规格和计划制品，让Agent在实现前完成代码库分析和计划。
将反复出现的组织知识封装为Skills；对不可违反的安全和质量要求增加Hooks、沙箱、CI门禁、分支保护和最小权限。
引入独立验证会话或审查Agent，避免实现者完全验证自己。
第三阶段：形成持续评估和生产反馈
建立初始Eval数据集，并在模型、Prompt、Skill和工具变化时执行回归评估。
将真实生产事故转化为测试案例和Eval；允许Agent进行只读运维分析、日志关联和低风险修复建议。
为开发、测试、预发布和生产设置不同的自治等级。
第四阶段：运行受控的闭环
当验证、权限和审计基础成熟后，生产事件可以自动触发Agent进行诊断，生成新的意图或修复PR。
但闭环不等于无条件自治。高风险操作仍应通过确定性检查、独立评审和明确的人类授权。
组织应当始终能够回答：
- Agent做了什么？
- 它为什么这样做？
- 使用了哪些数据和工具？
- 哪些证据证明结果可以接受？
- 谁或哪条政策授权了关键行动？
- 失败后的影响范围是否受控？
- 同类失败是否已经进入下一轮改进？
如果这些问题无法回答，继续扩大Agent权限只会放大不确定性。
---
结语：生成不再稀缺，判断才是
AI Native SDLC揭示的，并不是一个“AI替代程序员”的简单未来。
它揭示的是一个长期被代码生产成本遮蔽的事实：真正决定软件质量的，从来不仅是代码本身，而是代码之前的意图、代码周围的约束、代码之后的验证，以及组织是否愿意为最终结果负责。
当代码生成变得充裕，验证、判断和方向就成为新的稀缺资源。
未来最有竞争力的团队，不一定是拥有最多Agent、生成最多代码的团队，而是最早学会把组织知识变成可执行上下文，把质量标准变成自动反馈，把安全政策变成技术边界，并把人类注意力集中到真正需要判断的地方的团队。
AI Native SDLC的实质，不是让AI更自由地写代码，而是建立一个让AI能够可靠工作、让人类能够有效负责的软件生产系统。
成熟度的真正分界线也不是“团队是否使用了Agent”，而是：
当Agent出错时，团队能否及时发现错误、限制影响、解释原因，并确保同类错误不再发生。
如果不能，这仍然只是速度更快的vibe coding。
如果能够，组织才真正开始走向agentic engineering，以及完整意义上的AI Native SDLC。
