Introduction

Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven't changed at the same pace.各组织已开始利用人工智能以一年前难以想象的速度编写代码，但围绕代码的流程却没有以同样的速度发生改变。

Many engineering teams still have the same approval gates, reviews, handoffs, and policies, stalling productivity gains made by using agentic coding solutions like Claude Code.许多工程团队仍然沿用着相同的审批门槛、审查、移交和政策，这阻碍了通过 Claude Code 等智能体编码解决方案所带来的生产力提升。

The traditional SDLC传统的软件开发生命周期 (SDLC)

The software development lifecycle (SDLC) is the process that takes software from idea to production. Most organizations run some version of the same six stages, covering planning, design, building, testing, deploying, and maintaining software. Traditionally, each stage is a discrete phase owned by a different role. Product managers write requirements, technical architects turn them into designs, engineers build the designs, QA teams at regulated enterprises verify the software, release teams ship it, and operations monitors what is running. Work moves between the phases through documents, tickets, and sign-offs.软件开发生命周期 (SDLC) 是将软件从构思推向生产的过程。大多数组织都运行着相同流程的某个版本，涵盖计划、设计、构建、测试、部署和维护软件这六个阶段。传统上，每个阶段都是由不同角色负责的独立环节。产品经理编写需求，技术架构师将其转化为设计，工程师构建设计，受监管企业的质量保证 (QA) 团队验证软件，发布团队交付软件，运营团队监控运行情况。工作通过文档、工单和签字确认在各个阶段之间流转。

The traditional software development lifecycle (SDLC) is process-heavy to ensure accountability and control at each step. However, the traditional SDLC was designed to maximize efficiency in an era where the most time-consuming and expensive stage was writing and implementing code, which is no longer the case. Product requirements documents (PRDs), estimation rituals, and product security reviews all existed to force alignment during what could be weeks, months, or quarters of development work.传统的软件开发生命周期 (SDLC) 流程繁琐，旨在确保每一步的问责制和控制。然而，传统 SDLC 的设计初衷是在编写和实现代码这一最耗时、最昂贵的阶段实现效率最大化，而现在情况已不再如此。产品需求文档 (PRD)、估算流程和产品安全审查等机制，都是为了在长达数周、数月甚至数季度的开发工作中强制保持一致性而设立的。

The traditional SDLC also features controls that assume every step is performed by humans. The organizations generating the most value have rebuilt their process around what agentic AI can now do, while ensuring that humans stay in the loop. In this guide, we walk through several of our Applied AI team's best practices for integrating Claude internally across each stage of the SDLC to accelerate development and make processes run faster, inspired by working with our customers.传统 SDLC 还包含假设每一步都由人工执行的控制措施。那些创造出最大价值的组织已围绕人工智能智能体目前的能力重构了流程，同时确保人类始终参与其中。在本指南中，我们将结合与客户合作的经验，介绍我们应用人工智能 (Applied AI) 团队的一些最佳实践，以在 SDLC 的每个阶段集成 Claude，从而加速开发并提升流程运行速度。

When code is no longer the bottleneck当代码不再是瓶颈时

When code is no longer the bottleneck and the build phase runs faster than the traditional SDLC allows for, three things become true:当代码不再是瓶颈且构建阶段的运行速度超过传统 SDLC 的限制时，以下三点将成为现实：

1. The bottleneck moves to the stages on either side of the build phase: mainly plan, review/test, and deploy, which still run at human speed.瓶颈转移到了构建阶段的前后环节：主要是计划、审查/测试和部署，这些环节仍以人类的速度运行。

2. The controls stop matching reality and become intractable. Reviewing each line by hand made sense when a person had written it, but it can't keep up once agents write most of the diff.控制措施不再符合现实，变得难以执行。当代码由人工编写时，逐行审查是有意义的，但一旦智能体编写了大部分差异代码，这种方式就跟不上节奏了。

3. Governance costs increase because exceptions still route through meetings and committees that meet weekly or monthly.治理成本增加，因为例外情况仍需通过每周或每月召开的会议和委员会来处理。



Let's use a security bottleneck as an example. Security teams are sized for human output, so when agents multiply code output, either the review queue builds or code ships under-reviewed. A regulated organization can't accept either outcome, so its security and policy checks have to keep pace with the agents.以安全瓶颈为例。安全团队的规模是基于人类产出设定的，因此当智能体成倍增加代码产出时，要么审查队列积压，要么代码在未经充分审查的情况下发布。受监管的组织无法接受这两种结果，因此其安全和政策检查必须跟上智能体的步伐。

To better realize the productivity gains of and secure agentic AI, the traditional SDLC lifecycle requires the same level of transformation as the implementation phase has undergone.为了更好地实现智能体人工智能的生产力提升并确保其安全性，传统的 SDLC 生命周期需要经历与实施阶段同等程度的变革。

What is an AI-native SDLC?什么是人工智能原生 SDLC？

The AI-native SDLC is a reimagined process that combines the old control objectives with new enforcement. Instead of a linear flow, the process becomes a loop, and AI is embedded at each point. The AI-native SDLC promotes automated handover and triggering of subsequent plays, helping to address the manual and clunky nature of handoff between the phases of the traditional SDLC.人工智能原生 SDLC 是一种重构后的流程，它将旧的控制目标与新的执行方式相结合。该流程不再是线性流动，而是演变为一个循环，人工智能被嵌入到每个环节中。人工智能原生 SDLC 促进了自动化移交和后续操作的触发，有助于解决传统 SDLC 各阶段之间手动且繁琐的移交问题。



The shifts转变

The table below highlights the ends of the spectrum between traditional SDLC and AI-native SDLC, supported by Claude. Most organizations sit somewhere between the two columns.下表重点介绍了传统 SDLC 与由 Claude 支持的人工智能原生 SDLC 之间的差异。大多数组织处于这两者之间的某个位置。

What ties the AI-native column together is the committed artifact. Each stage ends by writing one to version control (including intent.md, spec.md, plan.md, the diff and its tests, the PR with its review findings, and the incident record), and the next stage begins by reading it. For the early stages, .md files are the predominant artifact because a product owner and an agent can both read and act on the same file. From Build onward, the artifact is code and its records. The chain of commits is also the audit trail: who asked for what, what the agent produced, and who approved it.将人工智能原生流程串联起来的是“已提交工件”。每个阶段都以向版本控制系统写入工件（包括 intent.md、spec.md、plan.md、差异代码及其测试、包含审查结果的 PR 以及事件记录）而结束，而下一个阶段则从读取这些工件开始。在早期阶段，.md 文件是主要工件，因为产品负责人和智能体都可以阅读并对同一文件采取行动。从构建阶段开始，工件即为代码及其记录。提交链也是审计追踪：谁请求了什么、智能体生成了什么、谁批准了它。

Humans remain accountable for every decision that requires judgment. In the agentic SDLC world, the human attention shifts along with the artifacts that must be reviewed.人类仍需对每一个需要判断的决策负责。在智能体 SDLC 的世界中，人类的注意力随着需要审查的工件而转移。

How the plays work操作手册如何运作

The plays are the core of the playbook and are grouped into six non-linear stages (Plan, Design, Build, Test, Deploy, Maintain), which together cover the complete lifecycle.这些操作是手册的核心，分为六个非线性阶段（计划、设计、构建、测试、部署、维护），共同涵盖了完整的生命周期。

Each play covers:每个操作涵盖：

• What changes变化之处
• Getting started入门指南
• Concrete steps for implementation具体的实施步骤
• Governance considerations治理注意事项
• How you measure whether it worked如何衡量效果

The plays are modular, and organizations may choose to prioritize transforming different stages at different times based on their unique needs. Each play names its dependencies under "Prerequisites," which the dependency graph further illustrates.这些操作是模块化的，组织可以根据自身独特需求，选择在不同时间优先转型不同的阶段。每个操作都在“先决条件”下列出了其依赖项，依赖关系图对此进行了进一步说明。

A stage ends by committing an artifact with the commit initiating the next stage. An accepted intent.md triggers the requirements and design pass, an approved spec.md triggers plan mode, a merged PR triggers the pipeline, and a breached control band in production writes the next intent.md, and so the loop continues.一个阶段以提交工件结束，该提交触发下一个阶段。已接受的 intent.md 触发需求和设计流程，已批准的 spec.md 触发计划模式，已合并的 PR 触发流水线，生产环境中超出控制范围的情况会写入下一个 intent.md，循环由此持续。

At first, you prompt each step by hand, with the end state being a loop in which each accepted artifact fires the next gate. Human attention concentrates at the gates, reviewing what the agent flagged rather than starting each stage from scratch.起初，您需要手动提示每一步操作，最终目标是实现一个循环，其中每个被接受的工件都会触发下一个门槛。人类的注意力集中在门槛上，审查智能体标记的内容，而不是从头开始每个阶段。

