AI原生软件开发实战手册：从线性流程到持续闭环的转型指南
代码不再是瓶颈，瓶颈转移了
当Claude Code等Agent式编码工具将代码实现周期从数周压缩到小时级时，一个关键问题浮出水面：围绕代码的流程是否已经同步进化？答案是令人警醒的——许多工程团队仍沿用传统的审批门禁、审查、交接和政策，这些机制形成于代码编写和实现最耗时、成本最高的年代。
传统的软件开发生命周期通常分为六个阶段：规划、设计、构建、测试、部署和维护。每个阶段由不同角色负责，产品经理整理需求、架构师完成设计、工程师编写代码、QA团队负责验证、发布团队推动上线、运维团队监控生产系统。文档、工件和批准记录承担着阶段之间的交接。
这种设计的隐含前提是大部分工作都由人完成。当人类逐行编写代码时，人工审查可以跟上产出速度；构建需要数周时，每周一次的审批会议也未必影响大局。然而，当Agent开始成倍提高代码产出时，原有假设开始失效。
首先，瓶颈会转移到构建阶段的两侧。需求仍在排队，设计仍要等待会议，测试和安全审查仍按人工能力配置，部署仍依赖固定窗口。构建时间虽然显著缩短，完整交付周期却未必同步下降。其次，原有控制措施越来越难执行。Agent可以持续生成代码差异，审查者却无法同比增加。如果继续要求人工查看每一行内容，审查队列会不断积压；如果为了速度降低审查强度，又可能让缺少验证的变更进入生产环境。
构建不再是制约因素，真正的制约因素转移到了它周围仍以人类速度运行的环节。安全审查最能说明这种变化——多数安全团队的规模按照人类工程师的产出能力配置，当Agent成倍提高代码产出时，安全团队只能面对不断增长的积压，或者接受覆盖不足的审查。
什么是AI原生SDLC
AI原生SDLC是一种重新构想的软件开发流程：原有控制目标得到保留，执行这些控制的机制则围绕Agent的能力重新设计。流程由线性接力转为持续运行的反馈闭环，AI嵌入每一个阶段，已被接受的结果可以自动触发下一项实践方案。
核心变化可以概括为减少依赖人工发起的交接，让意图、设计、实现、验证和生产反馈在同一条可追踪的链路中流动。这条链路依靠一组受版本控制的工件连接。
在规划阶段，团队提交intent.md，记录想解决的问题、期望结果和约束；设计阶段提交spec.md，把意图转化为需求和设计；构建前提交plan.md，说明将修改哪些文件、采用什么顺序以及如何验证；构建阶段生成代码差异和测试；部署阶段由PR保存审查发现、修复和批准；维护阶段记录故障及诊断结果，并将新的工作重新写入intent.md。
每个阶段结束时都会产生一个可以由下一阶段读取的工件。早期阶段主要使用Markdown，因为产品负责人和Agent可以阅读同一份内容并据此行动；进入构建后，工件逐渐变为代码、测试、PR和运行记录。这些提交同时构成审计轨迹——谁提出了什么要求，AI生成了什么，规划如何变化，哪些检查已经运行，以及谁批准了最终结果。
需要特别强调的是，AI原生SDLC并没有移走人的责任。人的注意力会随着工件转移：提出者确认意图、产品负责人批准规格说明、工程师批准规划、代码所有者批准PR、发布经理批准生产部署、服务负责人分诊生产环境中的发现项。凡是需要判断的决策，最终责任仍然由人承担。
规划阶段：从构想开始
在传统流程中，一个构想往往要经过待办事项、用户故事、故事点和需求细化会议，才能交到工程团队手中。所有权在多次交接中不断转移，最终需求可能已经与提出者的原意产生距离。
AI原生SDLC让提出者先用自己的语言和Claude讨论问题。对话可以从一个构想、一张工单或一次生产故障开始。提出者只需说明当前无法完成什么、影响了谁、理想状态是什么、存在哪些约束，以及哪些内容暂时不在范围内。Claude在讨论中继续追问用户、范围、系统边界、成功标准和待解决问题，并将结果整理为intent.md。
intent.md是一份可供人阅读、可由机器继续处理、受版本控制的原型规格说明。一份典型的intent.md会记录问题、预期成果、受影响的用户和系统、约束条件以及尚未回答的问题。
提出者需要纠正Claude对原意的误解，然后把工件提交到统一的意图存放区。对于单一产品，最直接的位置通常是产品仓库中的intent/目录；涉及多个仓库时，也可以使用专用意图仓库。没有Git使用经验的业务人员可以通过连接器，让Claude代表他们提交Markdown文件。
产品负责人仍然负责决定一项意图是否进入设计阶段。接受可以记录为合并，拒绝及其原因保留在审查记录中。作者、时间戳和完整修订历史都随Git记录保存。重复使用的intent.md模板可以编码为Skill，让不同部门用一致结构描述问题，同时保留提出者自己的表达方式。
设计阶段：规格说明的生成与评审
一旦intent.md获得产品负责人接受，Claude就可以在同一个协作会话中生成需求与设计规格说明。组织的品牌、安全、合规和UX标准通过Skill加入会话，成为生成spec.md时必须考虑的约束。
在AI原生SDLC中，产品负责人无需亲自从空白文档开始编写规格说明。他将已接受的intent.md交给Claude，要求它结合现有代码库和组织标准生成spec.md，并明确标出存在冲突、信息不足或需要策略负责人判断的部分。
前端工作可以进一步借助Claude Design。产品负责人根据intent.md制作并迭代原型，再将设计导出到Claude Code中进入构建。需求、界面和实现上下文因此能够保持关联。
产品负责人的核心工作转向评审：规格说明是否解决了原始问题，待解决问题是否已经获得回答，未解决事项是否被明确延续，组织政策之间有没有冲突。Claude标出的问题应在工程团队开始构建前交给对应负责人处理。
完成评审后，spec.md与intent.md一起提交。两份工件分别记录最初意图和最终决定。常规事项由产品负责人批准；被组织归为较高风险的事项，还需要技术负责人参与判断。这套过程可以先由人工启动，成熟后再由合并事件触发非交互式作业。
构建阶段：规划先行与知识固化
构建阶段首先处理一个常被忽略的问题：在生成任何代码之前，团队是否真正理解了实现方案。Claude Code的规划模式允许Claude阅读代码库、分析依赖、提出问题和生成规划，但在工程师接受规划前不能修改文件。
工程师把intent.md和spec.md提供给Claude，要求它说明需要修改哪些文件、工作的先后顺序、潜在风险、可能受影响的行为，以及用于证明实现正确的测试。规划需要经过反复推敲。工程师可以追问哪一步风险最高、有哪些替代方案被放弃、当前方案可能破坏什么。
判断规划是否足够清晰的一种方法是：一名没有看过此前对话的工程师，能否仅凭这份文档完成实现。获批的规划会提交为plan.md，成为后续构建、测试和PR审查的依据。如果实现偏离规划，应在同一次变更中更新plan.md，以免审计轨迹记录的计划与实际代码脱节。
CLAUDE.md：团队知识的载体
CLAUDE.md是构建阶段的关键工件之一。它向Claude提供新成员第一天就需要知道的信息，包括构建、测试和代码检查命令，重要约定，系统架构，以及Claude在这个仓库中反复犯过的错误。
一个实用规则是：当Claude两次犯下同一种错误，就把纠正方法加入CLAUDE.md。例如，金额必须使用BigDecimal，生成的类不可编辑，旧版目录已经冻结，集成测试应放在哪个位置。文件应尽量短，因为Claude会在每次会话开始时读取全部内容，过期信息会占用上下文并误导工作。
Skill：组织规范的传播机制
Skill承担另一类知识。需要在多个任务中一致应用的组织规范，可以写成带有触发条件和操作说明的SKILL.md，放入仓库的.claude/skills/，也可以通过插件在组织内分发。安全标准、API设计约定、品牌规则和规格说明模板都适合转化为Skill。
CLAUDE.md主要保存仓库内的工作知识，Skill更适合承载具有明确负责人、会集中更新、需要在特定任务中自动加载的组织知识。策略变化后，负责人审查并批准Skill的更新，后续会话便能使用新版本。
Skill属于建议性控制。它能显著提高Claude遵守政策的概率，却无法保证所有操作都符合要求。必须始终执行的规则还需要确定性的Hook。
Hook：不可协商的边界
Hook可以阻止编辑受保护路径，在文件变更后立即运行格式化和代码检查，或者阻止凭据进入代码差异。构建期间的Hook会频繁触发，因此应保持快速，并将检查范围限制在发生变化的文件。完整测试套件等较重操作更适合放在提交或PR阶段。需要人工批准的Hook则应集中到部署阶段。
并行会话与子Agent
当单个会话已经能够依据规划工作并验证结果，工程师便可以考虑并行会话。每个并行会话都是一个独立的Claude Code实例，在自己的git worktree中处理一项任务。任务拆分需要遵守文件边界。团队可以从两到三个会话开始，实际上限取决于一名工程师能够认真审查多少条工作流。
子Agent与并行会话解决的问题不同。并行会话负责同时推进多项独立任务；子Agent在一个主会话内部运行，拥有自己的上下文窗口和受限工具，适合承担重复出现的专门工作。团队可以建立只读取代码并返回报告的研究子Agent、移除不必要复杂性的代码简化子Agent，或在主Agent完成后运行应用并检查行为的验证子Agent。
测试阶段：自检与持续评测
Agent生成代码后，如果有效反馈只能等到几分钟后的CI、几天后的QA或几周后的生产故障才出现，人工就必须仔细检查全部输出。要让构建速度真正转化为交付速度，每个会话都需要在交给工程师前检查自己的工作。
反馈闭环可以是测试、构建、代码检查、端点响应或截图差异。关键在于结果能够被Claude直接观察，并具有清晰的成功标准。如果验证一项工作需要依次运行多条命令和依赖隐含的环境知识，团队应将它封装为一条命令，并确保失败时返回非零状态码。
修复缺陷时，应先编写一个能够复现问题的失败测试。Claude需要先运行它，确认测试因为预期原因失败，并提交这项测试；随后在不能编辑测试的条件下修改实现，直到测试通过。修复前已经失败、修复过程中又无法被Agent改写的测试，才能提供较强的证据。这一限制可以由Hook强制执行。
持续评测Agent配置
AI原生SDLC还需要持续评测。测试主要验证产品代码，评测则检查引导Agent的配置是否仍然有效。当团队切换模型、修改提示词、更新CLAUDE.md、Skill或Hook时，评测套件要判断Agent是否仍能按照原来的标准完成工作。
建立套件时，可以从近期任务中收集20到50个真实案例，为每个案例保留提示词、预期或已接受的结果，以及判断结果是否合格的检查项。检查项可以包括测试通过、Lint无问题、行为保持不变或政策得到遵守。
每次生产故障也应转化为新的评测用例，永久加入回归套件。评测套件需要持续更新，随着模型能力增强，过去具有区分度的案例可能变得过于简单；生产监控和实际工作中暴露的新问题，应不断补充进来。
部署阶段：人工授权的门禁
部署阶段的目标是让Agent完成生产门禁之前的工作，同时保留清晰的职责分离和人工授权。
PR审查首先形成双向反馈闭环。Claude可以按照统一政策审查所有传入的PR，也可以处理自己提交的PR上收到的评论。人工审查者因此能够把更多注意力放在变更是否符合意图、风险是否可接受，而不必反复检查已经由确定性工具覆盖的格式和机械问题。
技术负责人可以在仓库中维护REVIEW.md，规定审查维度和严重程度。审查内容通常包括逻辑错误与边界情况、安全漏洞，以及代码是否符合spec.md、plan.md和设计原则。文件还应区分真正可能破坏行为、泄露数据或违反政策的重要问题，与样式、命名等低影响建议，并排除生成文件和CI已经检查的内容。
职责分离必须保持清晰。编写代码的Agent无权批准自己的代码。PR中的发现、修复、评价和批准会一起构成审计记录，人工批准通过分支保护保存。
Hook守住的审批门禁
Hook可以在Claude执行操作前允许、阻止或暂停操作并请求人工批准。生产部署、数据库迁移、基础设施修改和受保护路径编辑，都可以根据组织的变更流程配置对应门禁。团队级Hook可以随仓库配置分发；不可协商的Hook则应放入由平台或IT管理员维护的托管设置，个人工程师无法关闭。
阻止操作时，Hook需要给出原因和获得批准的路径，让Claude能够向使用者解释当前缺少哪项授权。受监管组织还可以通过托管设置集中控制权限、沙箱、凭据、Hook、MCP服务器、插件来源和最低客户端版本。
CI/CD集成
CI/CD集成把这些控制连接到流水线。平台团队可以先让Claude执行只读判断，例如分析构建失败、总结不稳定测试或起草变更日志。稳定后，再在现有关卡之后加入写入步骤。Agent产生的修改仍应通过PR提交，并受分支保护约束，不能直接推送到主分支。
治理原则很清楚：Agent可以一路执行到生产门禁，但不能自行越过门禁。回滚应成为流水线中演练最充分的路径，需要定期在预发布环境验证。
维护阶段：让生产反馈重新进入开发流程
维护阶段让整个反馈闭环真正运转起来。生产环境中的控制带突破、缺陷工单、频道消息和定时任务，都可以在没有人工启动会话的情况下调用Claude。Claude负责诊断，并把发现重新写成intent.md，随后进入规划、设计、构建、测试和部署流程。
不同阶段之间设置独立的置信度门禁，由确定性检查或对抗性审查Agent判断上一阶段的输出可以继续流转，还是需要升级给人。控制带提供了一种可落地的触发机制。服务负责人可以选择具有稳定滚动基线的指标，例如CI测试失败率、部署后的5xx错误率或PR周期时间。
检测脚本根据滚动窗口计算均值和标准差，并使用西部电气规则或类似规则识别突增与缓慢漂移。达到1σ时，系统只记录日志；达到2σ时，以只读权限调用Claude进行诊断；达到3σ时，Claude可以提出行动，但路径仍受限制，只能向审查门禁提交PR，或者触发已经预先批准的运行手册。Agent不会因为发现严重异常就自动获得更高权限。
intent.md回流是这一阶段的关键。生产信号不会停在监控告警或复盘文档中，而会重新进入同一条工件链。每个发现都能追溯到触发指标、诊断过程、分诊决定、修复PR和新增评测。
实施路线图
本手册将转型拆成规划、设计、构建、测试、部署和维护六个阶段。六个阶段形成完整生命周期，但采用顺序无需严格按照阶段编号展开。
有些实践方案可以独立开始，例如创建CLAUDE.md、为Claude建立反馈闭环，或把现有政策转化为Skill。另一些实践方案具有明确依赖：自动构建需要稳定的测试和护栏，Agent进入CI/CD前需要PR审查与审批门禁，维护阶段的自主反馈闭环则依赖前面已经建立的工件链、审查机制和回滚路径。
最初，每一步可能都需要人工提示：有人让Claude整理意图，有人要求它生成规格说明，工程师手动启动规划模式，审查者再调用Claude检查PR。随着实践方案成熟，已接受的工件会成为触发器：合并intent.md后生成spec.md，批准spec.md后进入规划模式，合并PR后启动流水线，生产环境中的异常则写回新的intent.md。
最终形成的闭环仍包含关卡。自动化负责完成关卡之间的工作，人类负责审查Agent标记出的内容并作出关键决定。模型与运行框架的进步，使组织有机会重新设计完整的软件开发生命周期。代码生成速度提高之后，真正需要改造的是围绕代码运行的规划、设计、验证、审批和维护机制。
AI原生SDLC用受版本控制的工件连接六个阶段，用反馈闭环减少人工交接，用Skill传播组织知识，用Hook和托管设置落实边界，用测试与评测保护结果，再把生产环境中的发现通过intent.md送回流程起点。自动化扩大了人的判断能够覆盖的范围，但没有替代这项责任——凡是需要判断的决策，最终责任始终由人承担。