Anthropic 把应用 AI 团队与客户一起改造软件开发流程的经验，整理成了这份实战手册，以下是译文。
AI 原生软件开发生命周期实战手册
作者：Louis Claxton
代码不再是瓶颈
各组织已经开始使用 AI，以一年前难以想象的速度编写代码，但围绕代码的流程还没有以同样的速度变化。
许多工程团队仍沿用原来的审批门禁、审查、交接和政策。这套流程形成于代码编写和实现最耗时、成本最高的年代。PRD、估算会议、产品安全审查和多轮签字，都是为了在一项可能持续数周、数月甚至数个季度的开发工作开始前达成共识。
传统的软件开发生命周期通常分为六个阶段：规划、设计、构建、测试、部署和维护。每个阶段由不同角色负责。产品经理整理需求，架构师完成设计，工程师编写代码，QA 团队负责验证，发布团队推动上线，运维团队监控生产系统。文档、工单和批准记录承担着阶段之间的交接。
这种设计还隐含了一个前提：大部分工作都由人完成。人类编写代码时，逐行人工审查可以跟上产出速度；构建需要数周时，每周一次的审批会议也未必影响大局。Claude Code 等 Agent 式编码工具把实现周期压缩到小时级后，这些假设开始失效。
首先，瓶颈会转移到构建阶段的两侧。需求仍在排队，设计仍要等待会议，测试和安全审查仍按人工能力配置，部署仍依赖固定窗口。构建时间虽然显著缩短，完整交付周期却未必同步下降。
其次，原有控制措施越来越难执行。Agent 可以持续生成代码差异，审查者却无法同比增加。如果组织继续要求人工查看每一行内容，审查队列会不断积压；如果为了速度降低审查强度，又可能让缺少验证的变更进入生产环境。
最后，治理成本会随例外情况增多而上升。代码生成速度提高后，需要安全、合规或架构团队处理的事项也会增加，而这些事项仍要等待按周或按月召开的委员会。
*构建不再是制约因素，真正的制约因素转移到了它周围仍以人类速度运行的环节。*
安全审查最能说明这种变化。多数安全团队的规模按照人类工程师的产出能力配置。当 Agent 成倍提高代码产出时，安全团队只能面对不断增长的积压，或者接受覆盖不足的审查。对于受监管组织，两种结果都难以接受。安全检查、政策执行和审批机制必须能够跟上 Agent 的速度。
因此，Agent 式 AI 带来的变化不能停在构建阶段。规划、设计、测试、部署和维护都需要重新组织，同时保留明确的人类责任。
什么是 AI 原生 SDLC
AI 原生 SDLC 是一种重新构想的软件开发流程：原有控制目标得到保留，执行这些控制的机制则围绕 Agent 的能力重新设计。流程由线性接力转为持续运行的反馈闭环，AI 嵌入每一个阶段，已被接受的结果可以自动触发下一项实践方案。
这种方式也被称为 Agent 式 SDLC、AI SDLC 或 Agent 式软件开发。名称有所不同，核心变化相同：减少依赖人工发起的交接，让意图、设计、实现、验证和生产反馈在同一条可追踪的链路中流动。
这条链路依靠一组受版本控制的制品连接起来。
规划阶段提交 intent.md，记录想解决的问题、期望结果和约束；设计阶段提交 spec.md，把意图转化为需求和设计；构建前提交 plan.md，说明将修改哪些文件、采用什么顺序以及如何验证；构建阶段生成代码差异和测试；部署阶段由 PR 保存审查发现、修复和批准；维护阶段记录故障及诊断结果，并将新的工作重新写入 intent.md。
每个阶段结束时都会产生一个可以由下一阶段读取的制品。早期阶段主要使用 Markdown，因为产品负责人和 Agent 可以阅读同一份内容并据此行动；进入构建后，制品逐渐变为代码、测试、PR 和运行记录。
这些提交同时构成审计轨迹：谁提出了什么要求，Claude 生成了什么，规划如何变化，哪些检查已经运行，以及谁批准了最终结果。团队原有的 Jira、ServiceNow、Figma 或需求管理系统可以继续使用，但每类制品需要明确事实来源。仓库可以保存权威记录，也可以只保存与遗留系统关联的工作副本；最低要求是双方能够通过记录 ID 和提交 SHA 相互追溯。
AI 原生 SDLC 没有移走人的责任。人的注意力会随着制品转移：提出者确认意图，产品负责人批准规格说明，工程师批准规划，代码所有者批准 PR，发布经理批准生产部署，服务负责人分诊生产环境中的发现项。凡是需要判断的决策，最终责任仍然由人承担。
实践方案
本手册将转型拆成规划、设计、构建、测试、部署和维护六个阶段。六个阶段形成完整生命周期，但采用顺序无需严格按照阶段编号展开。
有些实践方案可以独立开始，例如创建 CLAUDE.md、为 Claude 建立反馈闭环，或把现有政策转化为 Skill。另一些实践方案具有明确依赖：自动构建需要稳定的测试和护栏，Agent 进入 CI/CD 前需要 PR 审查与审批门禁，维护阶段的自主反馈闭环则依赖前面已经建立的制品链、审查机制和回滚路径。
*图中的阶段表示实践方案在生命周期中的位置，箭头表示采用依赖。团队可以从没有前置依赖的实践方案开始，再逐步把它们连接起来。*
最初，每一步可能都需要人工提示：有人让 Claude 整理意图，有人要求它生成规格说明，工程师手动启动规划模式，审查者再调用 Claude 检查 PR。随着实践方案成熟，已接受的制品会成为触发器：合并 intent.md 后生成 spec.md，批准 spec.md 后进入规划模式，合并 PR 后启动流水线，生产环境中的异常则写回新的 intent.md。
最终形成的闭环仍包含关卡。自动化负责完成关卡之间的工作，人类负责审查 Agent 标记出的内容并作出关键决定。
阶段 01：规划
在传统流程中，一个构想往往要经过待办事项、用户故事、故事点和需求细化会议，才能交到工程团队手中。所有权在多次交接中不断转移，最终需求可能已经与提出者的原意产生距离。
AI 原生 SDLC 让提出者先用自己的语言和 Claude 讨论问题。对话可以从一个构想、一张工单或一次生产故障开始。提出者只需说明当前无法完成什么、影响了谁、理想状态是什么、存在哪些约束，以及哪些内容暂时不在范围内。
Claude 在讨论中继续追问用户、范围、系统边界、成功标准和待解决问题，并将结果整理为 intent.md。它是一份可供人阅读、可由机器继续处理、受版本控制的原型规格说明。
一份典型的 intent.md 会记录问题、预期成果、受影响的用户和系统、约束条件以及尚未回答的问题。例如，客户频繁致电查询理赔进度，预期成果可能是让客户在门户中查看状态、下一步操作和预计日期；约束则可能包括不得在门户会话中引入新的个人身份信息，只能沿用现有身份验证。
提出者需要纠正 Claude 对原意的误解，然后把制品提交到统一的意图存放区。对于单一产品，最直接的位置通常是产品仓库中的 intent/ 目录；涉及多个仓库时，也可以使用专用意图仓库。没有 Git 使用经验的业务人员可以通过连接器，让 Claude 代表他们提交 Markdown 文件。
产品负责人仍然负责决定一项意图是否进入设计阶段。接受可以记录为合并，拒绝及其原因保留在审查记录中。作者、时间戳和完整修订历史都随 Git 记录保存。
重复使用的 intent.md 模板可以编码为 Skill，让不同部门用一致结构描述问题，同时保留提出者自己的表达。这样，构想只需被记录一次，下一阶段便能直接读取，不必由另一个角色重新解释。
阶段 02：设计
一旦 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 一起提交。两份制品分别记录最初意图和最终决定。常规事项由产品负责人批准；被组织归为较高风险的事项，还需要技术负责人参与判断。
这套过程可以先由人工启动，成熟后再由合并事件触发非交互式作业：当 intent.md 被接受，作业加载组织 Skill，生成 spec.md，并以 PR 的形式等待产品负责人评审。自动化缩短了准备时间，接受规格说明的决定依然由人作出。
阶段 03：构建
先把规划写下来
构建阶段首先处理一个常被忽略的问题：在生成任何代码之前，团队是否真正理解了实现方案。
Claude Code 的规划模式允许 Claude 阅读代码库、分析依赖、提出问题和生成规划，但在工程师接受规划前不能修改文件。工程师把 intent.md 和 spec.md 提供给 Claude，要求它说明需要修改哪些文件、工作的先后顺序、潜在风险、可能受影响的行为，以及用于证明实现正确的测试。
规划需要经过反复推敲。工程师可以追问哪一步风险最高、有哪些替代方案被放弃、当前方案可能破坏什么。判断规划是否足够清晰的一种方法是：一名没有看过此前对话的工程师，能否仅凭这份文档完成实现。
获批的规划会提交为 plan.md，成为后续构建、测试和 PR 审查的依据。实现如果偏离规划，应在同一次变更中更新 plan.md，以免审计轨迹记录的计划与实际代码脱节。团队还可以使用 Hook 检查两者是否同步。
从规划模式进入自动模式
规划获批后，Claude Code 可以进入自动模式。在这种模式下，Claude 无需为每一次文件编辑单独请求批准，可以按照规划完成一组连续修改。适合自动执行的工作通常具有清晰的 spec.md、较小的影响范围、可靠的测试覆盖，以及已经调优的 CLAUDE.md、Skill 和 Hook。
随着护栏成熟，工程师的工作会从观察每一次编辑，转向在一段较长的自主会话结束后审查制品。自主程度来自明确的边界和反馈闭环，不能只依赖模型自行判断。
把团队知识变成文件和护栏
CLAUDE.md 是构建阶段的关键制品之一。它向 Claude 提供新成员第一天就需要知道的信息，包括构建、测试和代码检查命令，重要约定，系统架构，以及 Claude 在这个仓库中反复犯过的错误。
团队可以在仓库中运行 /init 生成初始版本，再删去冗余内容，只留下真正会影响工作的说明。文件通常放在仓库根目录并纳入版本控制，所有成员共享同一个版本，其变更也像代码一样接受审查。
一个实用规则是：当 Claude 两次犯下同一种错误，就把纠正方法加入 CLAUDE.md。例如，金额必须使用 BigDecimal，生成的类不可编辑，旧版目录已经冻结，集成测试应放在哪个位置。文件应尽量短，因为 Claude 会在每次会话开始时读取全部内容，过期信息会占用上下文并误导工作。
Skill 承担另一类知识。需要在多个任务中一致应用的组织规范，可以写成带有触发条件和操作说明的 SKILL.md，放入仓库的 .claude/skills/，也可以通过插件在组织内分发。安全标准、API 设计约定、品牌规则和规格说明模板都适合转化为 Skill。
CLAUDE.md 主要保存仓库内的工作知识，Skill 更适合承载具有明确负责人、会集中更新、需要在特定任务中自动加载的组织知识。策略变化后，负责人审查并批准 Skill 的更新，后续会话便能使用新版本。
Skill 属于建议性控制。它能显著提高 Claude 遵守政策的概率，却无法保证所有操作都符合要求。必须始终执行的规则还需要确定性的 Hook。例如，Hook 可以阻止编辑受保护路径，在文件变更后立即运行格式化和代码检查，或者阻止凭据进入代码差异。
构建期间的 Hook 会频繁触发，因此应保持快速，并将检查范围限制在发生变化的文件。完整测试套件等较重操作更适合放在提交或 PR 阶段。需要人工批准的 Hook 则应集中到部署阶段，避免工程师频繁回到多个会话中处理提示。
并行会话和子 Agent
当单个会话已经能够依据规划工作并验证结果，工程师便可以考虑并行会话。每个并行会话都是一个独立的 Claude Code 实例，在自己的 git worktree 中处理一项任务。worktree 提供独立分支和检出目录，使多个会话不会同时争用同一组文件。
任务拆分需要遵守文件边界。涉及相同文件的工作应在同一会话中顺序执行，相互独立的任务才适合分配给不同 worktree。团队可以从两到三个会话开始，实际上限取决于一名工程师能够认真审查多少条工作流。增加会话数量的前提是审查仍能跟上。
子 Agent 与并行会话解决的问题不同。并行会话负责同时推进多项独立任务；子 Agent 在一个主会话内部运行，拥有自己的上下文窗口和受限工具，适合承担重复出现的专门工作。
团队可以建立只读取代码并返回报告的研究子 Agent、移除不必要复杂性的代码简化子 Agent，或在主 Agent 完成后运行应用并检查行为的验证子 Agent。定义文件可以放进 .claude/agents/ 并纳入版本控制，让所有会话共享。
随着并行能力提高，工程师的职责逐渐转向编排和审查。他需要决定工作如何拆分、每个会话可以使用哪些工具、哪些结果能够自动合并，以及哪些异常必须交给人处理。
阶段 04：测试
先让每个会话检查自己的工作
Agent 生成代码后，如果有效反馈只能等到几分钟后的 CI、几天后的 QA 或几周后的生产故障才出现，人工就必须仔细检查全部输出。要让构建速度真正转化为交付速度，每个会话都需要在交给工程师前检查自己的工作。
反馈闭环可以是测试、构建、代码检查、端点响应或截图差异。关键在于结果能够被 Claude 直接观察，并具有清晰的成功标准。
如果验证一项工作需要依次运行多条命令和依赖隐含的环境知识，团队应将它封装为一条命令，并确保失败时返回非零状态码。相关命令和预期输出写入 CLAUDE.md。Claude 由此可以在报告完成前自行运行构建、测试和代码检查，读取失败原因，修改代码并再次验证。
目标也要足够具体。相比“检查一下功能”，更有效的描述是某个测试文件中的所有测试通过、端点返回 200 并包含指定字段，或者页面截图与已批准的原型一致。UI 工作可以通过浏览器或截图工具形成视觉反馈闭环，通常需要实现、截图、比较和调整两到三轮。
贯穿任务的自检反馈闭环与最终的验证器子 Agent 有所区别。前者会随着实现反复运行，帮助 Claude 及时修正错误；后者在会话认为工作完成时，以新的上下文进行独立检查，避免沿用生成代码时的假设。验证器可以报告与 plan.md 不一致的行为，但不必自行修复，从而保留一层独立判断。
修复缺陷时，应先编写一个能够复现问题的失败测试。Claude 需要先运行它，确认测试因为预期原因失败，并提交这项测试；随后在不能编辑测试的条件下修改实现，直到测试通过。修复前已经失败、修复过程中又无法被 Agent 改写的测试，才能提供较强的证据。
这一限制可以由 Hook 强制执行：在修复任务中禁止修改测试文件。团队也可以在 PR 审查中单独检查测试差异，拒绝通过删除、跳过或弱化断言来制造成功结果。反馈闭环本身必须受到保护，否则负责修复代码的 Agent 也拥有削弱验证条件的能力。
测试证据来自实际工具链，包括测试原始输出、构建日志、检查结果和截图差异。它们可以保留在会话记录和 PR 检查中，供代码所有者和后续审计人员查看。自动验证承担机械检查后，审查者可以把注意力集中到意图、行为和风险上。
持续评测 Agent 的配置
AI 原生 SDLC 还需要持续评测。测试主要验证产品代码，评测则检查引导 Agent 的配置是否仍然有效。当团队切换模型、修改提示词、更新 CLAUDE.md、Skill 或 Hook 时，评测套件要判断 Agent 是否仍能按照原来的标准完成工作。
建立套件时，可以从近期任务中收集 20 到 50 个真实案例，为每个案例保留提示词、预期或已接受的结果，以及判断结果是否合格的检查项。检查项可以包括测试通过、Lint 无问题、行为保持不变或政策得到遵守。
评测可以在配置变化时由 CI 触发，也可以按固定周期离线运行。导致通过率下降的配置变更应进入合并门禁，由负责该配置的团队审查。每次生产故障也应转化为新的评测用例，永久加入回归套件。
评测套件需要持续更新。随着模型能力增强，过去具有区分度的案例可能变得过于简单；生产监控和实际工作中暴露的新问题，应不断补充进来。这样，Agent 的代码和引导 Agent 的配置都能接受回归检查。
阶段 05：部署
让 Claude 进入 PR 审查
部署阶段的目标是让 Agent 完成生产门禁之前的工作，同时保留清晰的职责分离和人工授权。
PR 审查首先形成双向反馈闭环。Claude 可以按照统一政策审查所有传入的 PR，也可以处理自己提交的 PR 上收到的评论。人工审查者因此能够把更多注意力放在变更是否符合意图、风险是否可接受，而不必反复检查已经由确定性工具覆盖的格式和机械问题。
技术负责人可以在仓库中维护 REVIEW.md，规定审查维度和严重程度。审查内容通常包括逻辑错误与边界情况、安全漏洞，以及代码是否符合 spec.md、plan.md 和设计原则。文件还应区分真正可能破坏行为、泄露数据或违反政策的重要问题，与样式、命名等低影响建议，并排除生成文件和 CI 已经检查的内容。
托管式 Code Review 可以直接为仓库提供审查；需要控制流水线或通过组织自己的云服务协议调用模型时，也可以使用 claude-code-action。审查结果按严重程度排序，但发现问题本身不应自动批准 PR。分支保护继续要求代码所有者作出最终决定。
作者或审查者可以在评论中标记 Claude，让它处理意见并推送修复。PR 讨论会同时保存请求、代码变化和后续检查。Claude 创建的 PR 还可以持续处理未解决评论与失败检查，直到所有自动检查通过，只留下代码所有者的批准。
审查发现应回流到构建配置。如果 PR 审查第二次发现同一种错误，团队可以在当前审查中把纠正规则写入 CLAUDE.md，让之后的构建会话提前避免它。团队还应定期调整审查政策，限制低价值建议的数量，并通过对审查结果的评价改善审查器。
职责分离必须保持清晰。编写代码的 Agent 无权批准自己的代码。PR 中的发现、修复、评价和批准会一起构成审计记录，人工批准通过分支保护保存。
用 Hook 守住人工审批
Hook 在这里承担审批门禁。它可以在 Claude 执行操作前允许、阻止或暂停操作并请求人工批准。生产部署、数据库迁移、基础设施修改和受保护路径编辑，都可以根据组织的变更流程配置对应门禁。
团队级 Hook 可以随仓库配置分发；不可协商的 Hook 则应放入由平台或 IT 管理员维护的托管设置，个人工程师无法关闭。阻止操作时，Hook 需要给出原因和获得批准的路径，让 Claude 能够向使用者解释当前缺少哪项授权。
受监管组织还可以通过托管设置集中控制权限、沙箱、凭据、Hook、MCP 服务器、插件来源和最低客户端版本。拒绝规则可以避免敏感文件进入 Agent 上下文；命令允许列表可以预先批准安全的构建、测试和 Git 操作；操作系统级沙箱可以限制文件系统与网络访问；凭据规则可以从沙箱命令中移除长期密钥。
这些控制需要相互补足。工具层禁止网络读取，不能自动约束 shell 命令的网络访问，因此还需要沙箱的域名允许列表。文件工具的拒绝规则也未必能阻止 shell 读取用户目录中的凭据，因此还要单独限制凭据文件和环境变量。沙箱初始化失败时，受管环境可以直接拒绝启动，避免命令退回到缺少隔离的环境。
托管设置还可以只允许管理员批准的 Hook 和 MCP 服务器，禁止从未经批准的位置加载 Skill、Agent 或插件，并要求客户端达到经过组织评估的最低版本。具体限制应依据仓库的数据分类设置，过度收紧同样会损失有效能力。
再把 Claude 接进 CI/CD
CI/CD 集成把这些控制连接到流水线。平台团队可以先让 Claude 执行只读判断，例如分析构建失败、总结不稳定测试或起草变更日志。稳定后，再在现有关卡之后加入写入步骤，让它修复 Lint、更新生成文档或处理 PR 意见。
Agent 产生的修改仍应通过 PR 提交，并受分支保护约束，不能直接推送到主分支。执行环境需要沙箱化，使用短期且范围受限的令牌，默认不持有生产凭据。
部署、状态查询和回滚可以通过 MCP 作为按环境限制的工具开放给 Agent。开发环境允许更高自主程度，预发布环境保留更多关卡，生产环境则由 Agent 准备发布、发布经理授权，再由 Hook 强制执行审批门禁。
回滚应成为流水线中演练最充分的路径。它需要是一条 Agent 可以调用的稳定命令，并定期在预发布环境验证。维护阶段一旦根据控制带触发回滚，系统才能依赖这条路径及时恢复。
治理原则很清楚：Agent 可以一路执行到生产门禁，但不能自行越过门禁。
阶段 06：维护
让生产反馈重新进入开发流程
维护阶段让整个反馈闭环真正运转起来。生产环境中的控制带突破、缺陷工单、频道消息和定时任务，都可以在没有人工启动会话的情况下调用 Claude。Claude 负责诊断，并把发现重新写成 intent.md，随后进入规划、设计、构建、测试和部署流程。
这种工作通常以无人值守的 headless 模式运行。不同阶段之间设置独立的置信度门禁，由确定性检查或对抗性审查 Agent 判断上一阶段的输出可以继续流转，还是需要升级给人。
控制带提供了一种可落地的触发机制。服务负责人可以选择具有稳定滚动基线的指标，例如 CI 测试失败率、部署后的 5xx 错误率或 PR 周期时间。检测脚本根据滚动窗口计算均值和标准差，并使用西部电气规则或类似规则识别突增与缓慢漂移。
检测过程保持确定性，不由模型决定指标是否越界。脚本、单元测试和响应层级都纳入版本控制。
达到 1σ 时，系统只记录日志；达到 2σ 时，以只读权限调用 Claude 进行诊断；达到 3σ 时，Claude 可以提出行动，但路径仍受限制，只能向审查门禁提交 PR，或者触发已经预先批准的运行手册。Agent 不会因为发现严重异常就自动获得更高权限。
触发器可以来自定时工作流、监控系统的 Webhook 或内部 Cron Job。Claude 可以作为 CI 运行器中的非交互步骤，也可以通过 Agent SDK 运行在沙箱服务中。每次调用保持无状态，因此反馈闭环能够自行开始和结束。
诊断结果按照规划阶段的格式写入 intent.md，记录异常及其证据、期望结果、受影响系统和待解决问题。服务负责人或值班工程师随后分诊：立即修复、进入排期或驳回；面向产品的事项再交给产品负责人。
驳回同样是有价值的反馈，可以用来调优控制带并减少噪声。修复进入生产环境后，团队还要为这类故障补充一项评测，使同类问题以后能够在更早阶段被发现。
例如，CI 测试失败率突破 3σ 后，Agent 可以隔离不稳定测试或创建撤销变更的 PR，由审查门禁决定是否合并；部署后的 5xx 错误率突破 3σ，且时间窗口内确实发生过部署时，可以触发预先批准的回滚流水线；PR 周期时间出现持续漂移时，Agent 可以生成供工程管理层判断的报告。
intent.md 回流是这一阶段的关键。生产信号不会停在监控告警或复盘文档中，而会重新进入同一条制品链。每个发现都能追溯到触发指标、诊断过程、分诊决定、修复 PR 和新增评测。
定期扫描代码库
定期安全扫描提供了另一类反馈。代码库持续变化，模型能力也在更新，一次扫描只能反映特定时间点的状态。AI 原生做法是按照固定周期重新扫描代码库，并让发现项经过与其他代码变更相同的门禁。
Claude Security 是这种实践方案的托管形式，目前面向 Claude Enterprise 组织提供公开测试版。连接 GitHub 仓库后，它会在 Anthropic 的基础设施上使用 Claude Mythos 5 执行扫描。每个发现项在报告前都会经过验证，并附带置信度评级；建议的补丁可以在 Claude Code 网页版中接受审查和应用。
首次扫描应被视为基线，即使仓库此前已经使用其他工具或早期模型检查过。活跃开发的服务可以从每周扫描开始；大型或内容混杂的仓库可以限定目录、分支或项目范围。安全负责人需要从一开始明确仓库和发现项的归属。
范围明确、可以在单个 PR 内解决的问题，进入正常的 PR 审查门禁。提出补丁的 Agent 无权批准补丁。涉及架构弱点、跨服务重复模式或无法由单个补丁解决的问题，则转化为 intent.md，重新从规划阶段处理。
修复完成后，还应将对应漏洞类别加入持续评测。确定性的静态分析和依赖扫描继续保留在 CI 中，模型驱动的扫描负责发现更依赖上下文、原有规则没有覆盖的问题。扫描历史、验证结果、置信度和驳回原因可以共同记录组织发现、修复或接受了哪些风险。
让 Claude 进入值班频道
Claude Tag 则把反馈闭环延伸到 Slack 等工作协作渠道。它目前在 Slack 中提供公开测试版，可以用独立身份加入频道。当晚上出现紧急故障消息时，Claude 可以立即承担第一响应者的工作，而无需等待某个人手动创建会话。
频道成员可以共同引导调查、检验假设和探索方案。Claude 通过 MCP 查询系统状态，确认指标是否已经恢复到基线，并在线程中记录结果。请求、诊断、人工授权和后续行动都留在原频道，使对话本身成为审计轨迹的一部分。
调查结束后，Claude 可以把复盘写入受版本控制的经验文件，供未来故障读取。范围较小、边界清晰的修复以 PR 进入审查门禁；规模更大的问题写成 intent.md，再次启动六阶段反馈闭环。
Claude Tag 也可以处理工单或频道中的一般请求。入口发生变化，制品链、权限边界和人类责任保持一致。
结语
模型与运行框架的进步，使组织有机会重新设计完整的软件开发生命周期。代码生成速度提高之后，真正需要改造的是围绕代码运行的规划、设计、验证、审批和维护机制。
AI 原生 SDLC 用受版本控制的制品连接六个阶段，用反馈闭环减少人工交接，用 Skill 传播组织知识，用 Hook 和托管设置落实边界，用测试与评测保护结果，再把生产环境中的发现通过 intent.md 送回流程起点。
闭环可以持续运行，Agent 也可以完成越来越多关卡之间的工作，但人的判断始终高于闭环。产品负责人决定意图和规格说明是否成立，工程师决定规划是否可靠，代码所有者决定 PR 是否可以合并，发布经理控制生产部署，服务负责人处理生产发现。
自动化扩大了人的判断能够覆盖的范围，没有替代这项责任。
参考链接
原文：https://claude.com/blog/the-ai-native-sdlc-playbook Claude Code：https://claude.com/product/claude-code Claude Design：https://claude.com/product/design Plan mode：https://code.claude.com/docs/en/permission-modes CLAUDE.md：https://code.claude.com/docs/en/memory Skills：https://code.claude.com/docs/en/skills Hooks：https://code.claude.com/docs/en/hooks worktree：https://code.claude.com/docs/en/worktrees 子 Agent：https://code.claude.com/docs/en/sub-agents Code Review：https://code.claude.com/docs/en/code-review claude-code-action：https://code.claude.com/docs/en/github-actions Agent SDK：https://platform.claude.com/docs/en/agent-sdk/overview Claude Security：https://claude.com/product/claude-security Claude Tag：https://claude.com/product/tag