AI原生的SDLC手册（47分钟阅读）

# AI 原生软件开发生命周期实践手册 来源：https://claude.com/blog/the-ai-native-sdlc-playbook ## 代码不再是瓶颈 企业已开始使用 AI 以一年前难以想象的速度编写代码，但围绕代码的流程并未同步改变。许多工程团队仍沿用相同的审批关口、评审机制、交接流程和规范，这阻碍了使用智能体编程解决方案（如 Claude Code）带来的生产力提升。 软件开发生命周期（SDLC）是将软件从创意推向生产环境的流程。大多数组织采用包含六个阶段的通用模式，涵盖规划、设计、构建、测试、部署和维护软件。传统上，每个阶段由不同角色独立负责：产品经理编写需求，技术架构师将其转化为设计，工程师构建实现，受监管企业的质量保证团队进行验证，发布团队交付成果，运维团队监控运行状态。工作流通过文档、工单和审批在各阶段间流转。 传统 SDLC 流程繁重，旨在确保每个环节的问责与控制。然而，传统 SDLC 诞生于编码实现最耗时耗力的时代，而如今情况已变。产品需求文档（PRD）、估算会议和产品安全评审的存在，都是为了在可能长达数周、数月乃至数季度的开发周期中保持对齐。传统 SDLC 还包含假设所有步骤均由人类执行的控制机制。 最具价值的组织已围绕智能体 AI 的当前能力重构流程，同时确保人类保持决策权。在本指南中，我们结合与客户合作的经验，分享应用 AI 团队在各 SDLC 阶段内部署 Claude 的最佳实践，以加速开发并提升流程效率。 当代码不再是瓶颈，且构建阶段运行速度快于传统 SDLC 的允许范围时，三个现象成为现实： - 瓶颈转移至构建阶段左右两侧的步骤，主要是规划、评审/测试和部署，这些环节仍以人类速度运行 - 控制机制与现实脱节并变得难以管理：当 AI 代理生成大部分代码差异时，逐行手动审查不再可行 - 治理成本上升，因为异常情况仍需通过周会或月度委员会处理 构建阶段不再是约束——围绕其的人类速度步骤才是。当人类速度阶段保持原有时长，构建时间却压缩至数小时。 以安全瓶颈为例：安全团队按人类产出配置人力，当 AI 代理使代码产出倍增时，要么审查队列堆积，要么代码未经充分审查即发布。受监管组织无法接受任一结果，因此其安全与策略检查必须与 AI 代理同步。 为更好地实现智能体 AI 的生产力增益并确保安全，传统 SDLC 需要与实施阶段同等程度的转型。 ### 什么是 AI 原生 SDLC？ AI 原生 SDLC 是重新构想的流程，将传统控制目标与新型执行机制相结合。流程从线性变为循环，AI 嵌入每个节点。该模式促进自动化交接与后续操作触发，解决传统 SDLC 阶段间人工交接的笨重问题。 ### 关键转变 下表对比传统 SDLC 与由 Claude 支持的 AI 原生 SDLC 的核心差异，大多数组织介于两者之间： | 阶段 | 传统 SDLC | AI 原生 SDLC | |--------------|---------------------------------------------------------------------------|-----------------------------------------------------------------------------| | **规划** | 通过委员会收集需求，经研讨会精炼并签署，手工撰写文档 | Claude 直接综合多源信息，生成可读且机器可执行的 `intent.md` 文件 | | **设计** | 分析师编写规格书，设计师解析 | 需求与设计在与智能体的协作会话中完成，遵循编码为技能的标准，并在 Git 中版本管理 | | **构建** | 手工编写测试和代码，文档在开发完成后补充 | AI 生成测试和代码，机构知识维护为版本化的机器可读 `CLAUDE.md` 文件及技能 | | **测试** | 阶段边界设置质量门禁 | 持续评估贯穿实现全过程 | | **部署** | 人工审查每行代码，治理在评审周期中进行（常不一致） | 多层智能体评审，人类仅审查受监管和关键代码。治理通过 AI 执行钩子强制实现 | | **维护** | 人工监控生产环境缺陷 | 智能体监控实时部署，控制阈值突破时自动生成诊断并回写新的 `intent.md` | 右侧列的贯穿线索是**版本化交付物**：每个阶段通过向版本控制系统提交文件结束（包括 `intent.md`、`spec.md`、`plan.md`、差异文件及测试、带评审结论的 PR、事故记录），下一阶段从读取该文件开始。早期阶段主要使用 .md 文件，因其可被人机共同读取；构建阶段后，交付物转为代码及相关记录。提交链即审计轨迹：谁提出需求、智能体产出什么、谁批准了决策。人类对需判断的决策始终保持问责。 在智能体 SDLC 中，人类注意力随需审查的交付物转移。每个阶段提交下一阶段可读取的文件，共同构成完整审计轨迹。 ## 操作剧本 操作剧本是本手册的核心，分为六个非线性阶段（规划、设计、构建、测试、部署、维护），覆盖完整生命周期。每个剧本包含： - 变更内容 - 起步条件 - 实施具体步骤 - 治理考量 - 效果评估方法 这些步骤模块化设计，组织可根据需求分阶段优先转型。每个剧本在"前提条件"中列出依赖项，依赖关系图进一步说明：阶段通过提交交付物结束，该提交触发下一阶段启动。 已接受的 `intent.md` 触发需求设计阶段，批准的 `spec.md` 触发规划模式，合并的 PR 触发流水线，生产环境控制阈值突破则写入新的 `intent.md`，形成持续循环。 首先，您需手动提示每个步骤，最终形成闭环：每个已接受的交付物自动触发下一关口。人类注意力集中于关口审查智能体标记的内容，而非从零开始每个阶段。 以下按阶段列出操作剧本，箭头表示采用顺序（两者可能不同）。从任何无入向箭头的剧本开始——无需前置条件。其他剧本的入向箭头指向需先采用的剧本。 **01** ## 规划 创意无需等待专人记录。意图一次性捕获，以发起者原话生成版本化文件，供下一阶段执行。 ### 捕获为 intent.md 启动软件开发的 `intent.md` 可通过多种途径产生：个人创意、提交的工单，或告警触发的事故（见阶段6：维护）。个人创意可通过与 Claude 头脑风暴生成 Markdown 原型规格书。传统 SDLC 中，发起者需说服产品团队成员协助记录；而 Claude 生成的原型规格书人类可读、版本可控，且可立即供下一阶段使用。该文件保存为 `intent.md`。 无论意图源于事件触发还是智能体，步骤相同：产品负责人在提交前审阅并修正智能体撰写的 `intent.md`。 | 传统模式 | AI 原生模式 | |--------------------------------------------------------------------------|-----------------------------------------------------------------------------| | 创意需经待办列表、用户故事、故事点及精炼会议后方可行动，每次交接转移所有权，导致最终需求与原始意图脱节 | 发起者与 Claude 头脑风暴，将结果写为 `intent.md`——以原术语描述的原型规格书，包含需求、动机及约束条件，重复流程通过技能编码 | ### 起步条件 **基础设施** - 为非工程师提供 Claude 访问权限（claude.ai 或 [Cowork](https://claude.com/product/cowork)） - 统一的 `intent.md` 模板 - 产品负责人监控的版本化意图存储库。单产品最简方案为产品仓库内的 `intent/` 目录，保持交付物与衍生代码临近。仅当意图跨多仓库时需独立仓库，单仓环境用目录即可。 #### 实施步骤 1. 发起者用原话向 Claude 描述问题：当前限制、受影响用户、理想状态或排除范围，无需正式术语 2. 头脑风暴至创意具体化：Claude 会像分析师一样询问范围、用户、约束及成功标准 3. 要求 Claude 按组织模板生成 `intent.md`（可编码为技术团队创建并由负责人批准的技能集），涵盖问题、预期成果、受影响用户与系统、约束条件及待解决问题 4. 发起者修正 Claude 的理解偏差 5. 将 `intent.md` 提交至共享存储库，作者和时间戳自动记录，产品负责人从此处接手 ```markdown # 意图：理赔状态自助服务 作者：J. Ortiz (理赔运营) 状态：草稿 ## 问题 客户致电客服中心查询理赔进度，约三分之一通话时间用于状态查询。 ## 预期成果 客户可在门户查看理赔状态、后续步骤及预计时间。 ## 受影响用户与系统 理赔处理员、门户团队、理赔核心 API ## 约束条件 门户会话不得引入新个人身份信息，仅使用现有认证机制。 ## 待解决问题 第三方损失理算师是否需要访问权限？ ``` #### 治理考量 证据为已提交的 `intent.md`，包含作者、时间戳及完整修订历史，记录于意图存储库的 Git 历史中。产品负责人通过合并或关闭评审做出接受/拒绝决策，决定意图进入阶段2：设计。 ### 效果评估 **先行指标**：从首次对话到提交 `intent.md` 的时长（从意图存储库 Git 历史读取），预期从数周需求精炼周期缩短至数小时。 **滞后指标**： - 意图存活率——产品负责人接受进入设计阶段的 `intent.md` 比例（决策记录为文件合并或评审关闭） - 首次 `spec.md` 提交后对 `intent.md` 的修改次数 **02** ## 设计 需求与设计合并为单次会话，策略在规格书编写时同步应用，而非数周后评审才发现问题。 ### 需求与设计 产品负责人批准后，Claude 接受 `intent.md` 并生成需求与设计规格书，遵循组织在品牌、安全、合规及用户体验方面的技能要求。产品负责人审阅规格书但不参与编写。此流程旨在创建工程团队可规划、且标注关注点的规格书。 前端工作是最典型示例：接受 `intent.md` 后，产品负责人在 [Claude Design](https://claude.com/product/design)（测试版）中基于 `intent.md` 制作设计原型，迭代后导出至 Claude Code 构建。 | 传统模式 | AI 原生模式 | |--------------------------------------------------------------------------|-----------------------------------------------------------------------------| | 需求与设计分离，分属不同团队：分析师规范化需求，设计师据此创作设计，分离虽明确问责但缓慢且损耗大 | 两个阶段在单次提示会话中完成，Claude 生成受组织技能约束、标注关注点的需求设计规格书 | ### 起步条件 **前提条件**： - 编写 `intent.md` 文件 - 将品牌、安全、合规及用户体验策略写为技能 **基础设施**：具备 Claude 访问权限的产品负责人（无需工程技能） #### 实施步骤 1. 产品负责人在支持组织技能的会话中附上 `intent.md` 2. 提示指向 `intent.md`，指定约束并要求标注关注点。初始手动运行，后固化为组织级斜杠命令。此后以意图存储库的 `intent.md` 接受为触发器，通过非交互作业在合并时加载组织技能执行，将 `spec.md` 作为 PR 提交（阶段5的部署剧本涵盖流程），产品负责人首次参与即为审阅 3. 同一产品负责人对照创意审阅规格书：是否解决问题？`intent.md` 待解决问题是否解答或跟进？ 4. 优先处理标注的关注点（分析师通常会升级的问题），产品负责人在工程团队接触规格书前与策略所有者解决每个问题 5. 将 `spec.md` 与 `intent.md` 一并提交，文件对记录需求及决策 6. 产品负责人决定是否推进至构建阶段，高风险事项咨询技术负责人。人类始终做出此决策，接受规格书即启动阶段3：构建的规划模式 #### 提示示例 ```markdown 阅读附件 intent.md，生成将其集成到现有代码库的需求设计规格书。应用可用技能使计划符合品牌指南、安全策略和 UX 标准。将规格书完整记录为 spec.md，准备移交工程团队。明确标注关注点，特别是无法满足矛盾策略的领域。 ``` #### 治理考量 （后续内容待续）