Anthropic AI原生SDLC：人类责任与规范驱动
当AI工具能够快速生成大量代码时，软件开发的传统流程开始暴露出新的矛盾。据行业观察，团队引入AI辅助编码后，Anthropic内部约80%的代码合入已经由Claude完成，工程师的人均产出达到了2021到2025年间的8倍，但后续的需求评审、代码审查、测试部署等环节依然按照传统人力节奏运行，反而成为新的瓶颈。
业内团队Anthropic针对这种场景整理了一套AI原生软件开发生命周期流程，并从安全治理角度补充了配套实践方案。这套方案的核心是重新定义人与AI的分工，将整个开发链路改造为可追溯的闭环系统。
传统流程的局限与新的矛盾
传统开发流程以编码速度为核心设计，从需求梳理、架构设计、代码实现到测试上线，各个环节依赖文档、工单和层层审批来推进。但当AI可以在短时间内完成大量代码编写后，这种依赖人力逐环节校验的模式就会出现审查队列积压、治理成本过高的问题。
Anthropic的解法是将线性流水线改为闭环，每个阶段的产出都存入版本控制系统，形成完整的追溯链条：从需求意图文档，到技术规格说明，再到执行计划、代码与测试，合并请求带着审查记录进入发布流程；线上出现问题时，事故记录会生成新的需求意图文档，回到流程起点。整条提交历史可以清晰追溯谁提出需求、AI生成了什么内容、人工在哪个节点做了批准、后续又做了哪些修改。
在这套体系中，AI负责推动流程执行，人则负责做出需要判断力的关键决策。
AI原生开发的六个核心阶段
1. 规划阶段：让AI先明确需求边界
规划阶段不再需要从零编写几十页的需求文档，产品团队只需用自然语言描述问题、目标、范围和约束，AI会作为分析师进行补充追问，最终整理出intent.md文件。这份文件会被存入版本控制，清晰记录需求的提出、修改和最终确认的全过程，避免了传统模式下重复写文档、开会同步和修改版本的成本。
安全评审也会提前嵌入这个阶段，AI可以结合公司内部政策和历史数据分析潜在风险，让安全能力直接融入需求环节，而不是事后补写审核文档。聊天记录、历史评审和代码库中的信息，比为了过审而补写的长文档更有实际价值。
2.设计阶段：将需求转化为可执行方案
需求明确后，AI会读取intent.md和团队已有的品牌、安全、合规和用户体验规则，生成spec.md规格说明文件，清晰阐述功能逻辑、数据流向、系统改动范围和约束条件。
产品负责人无需从头撰写规格文档，只需审核这份文件，和对应的策略、合规或安全团队沟通调整后确认提交。这种方式将需求分析和技术设计整合在同一上下文里，避免了跨团队交接的信息丢失，同时让合规规则在设计阶段就被自动应用，不必等到几周后的评审会上才发现不合规。
3.构建阶段：强制AI先做计划再写代码
这是变化最大的环节。AI编程最容易出现的问题是直接根据需求开始修改代码，最终偏离方向。Anthropic要求AI先进入计划模式：读取现有代码库，列出准备修改的文件，说明每一步的实现方式和验证方法，在获得人工确认前不允许直接编写代码。
这个阶段有三层约束机制：
第一，CLAUDE.md：存放在项目根目录，记录项目的构建测试规则、目录权限、禁忌操作和AI常见错误，当AI重复犯同一个错误时，就将纠正方法添加到这份文件中。
第二，Skills：聚焦于特定类型的重复任务，比如数据库迁移、服务创建或安全检查，将团队验证过的步骤和避坑指南随代码一起分发，比通用规则更具针对性。
第三，Hooks：作为硬隔离机制，当AI尝试修改受保护文件、读取敏感信息或执行发布命令时，系统会直接拦截不符合规则的操作，守住安全底线。
此外，工程师可以在不同的Git工作副本中开启多个AI会话，分别处理互不冲突的任务，同时保持每个任务的上下文独立清晰。安全规范也会被写入CLAUDE.md和组织级Skills，让AI在生成代码时自动遵守，后续发现新漏洞时也可以快速更新规则。为了进一步保障安全，部分开发环境会迁移到远程虚拟机，并对AI的出站流量设置白名单，防止提示词注入导致的数据泄露。
4.测试阶段：用结果验证而非AI自述
代码生成完成并不代表功能可用。AI需要自行运行测试、执行构建、比对结果，并修复问题直到通过验收。但仅让编写代码的AI自行检查，可能会沿用之前的错误思路，因此建议开启全新的AI会话专门负责复核，不参与原有的修改流程。
团队还会建立持续评测机制：每次更换模型或调整规则时，先让AI完成一组固定任务，按照统一标准检查结果；同时将线上出现过的问题加入评测集，避免模型或规则升级后重复踩坑。
代码审查不再依赖单一的大规模提示词，而是由多个审查智能体分别检查不同维度，比如权限控制、数据流向、依赖风险和历史事故模式，每个审查者专注于窄范围的问题，避免共享盲区。技术负责人可以将审查标准写入文件，明确哪些是关键风险点，哪些是格式细节，让人工审查从逐行看代码转向判断变更的意图、行为和潜在风险。
此外，代码库会按照风险分级，低风险区域可以让AI完成更多自动审查，高风险区域保留严格的人工复核，即使由AI审批，也要记录使用的判断信号和决策依据，并按风险比例抽样交由人工复查。
5.部署阶段：人工守住最后一道闸门
AI可以完成上线前的所有准备工作，但不能自行决定将代码发布到生产环境。合并请求获批后，持续集成流水线会自动完成构建和测试，持续交付系统将检查通过的版本推送至对应环境。开发环境可以给AI更大的操作权限，而生产环境仅允许AI完成发布准备。
真正执行上线时，Hooks会拦截发布命令，直到具名的负责人授权，这是保留给人工的最后一道安全闸门。同时，预发布环境会进行外部渗透测试和动态应用安全扫描，还会推进AI动态扫描，检查多个服务组合后的安全假设是否成立。
6.维护阶段：将线上问题闭环回流程起点
上线不是流程的终点，维护阶段会将整个循环重新连接回规划阶段。监控系统持续观察错误率、延迟等指标，在正常范围内仅记录日志；指标超出阈值时，AI开始自动诊断；问题严重时则生成修复建议。诊断结果会被整理为新的intent.md，进入下一轮规划流程，让线上发现的问题直接成为后续开发的输入，而不是仅停留在事故报告中。
权限边界在这个阶段尤为重要，Anthropic的事故响应智能体使用单用途系统账号，仅能执行写文档、发送团队消息、读取生产日志三项操作，无法自动部署修复。团队曾在一次模型升级后遇到过智能体尝试通过其他工具推送修复的情况，这让他们意识到不仅要限制单个智能体的工具权限，还要管控智能体之间的协作渠道，确保所有操作都可记录、审计。每个智能体都应拥有独立身份，仅获取完成当前任务所需的最小权限，智能体间的协作也需要通过可追溯的渠道进行。
如何保障流程持续有效
流程搭建完成后并不会自动永久有效，Skills可能会过时，线上发现的新问题可能忘记更新到CLAUDE.md，AI的决策也可能长期缺乏人工抽查，任何一个环节的松懈都会让整个闭环逐渐退化。Anthropic通过五个方法保障流程持续有效：
第一，按照风险等级对代码库分级，确定不同区域的自动化程度；
第二，新的AI审查工具先以观察模式运行，仅发表评论由人工决定是否采纳，通过持续测试建立信任后逐步放开权限；
第三，对AI自动审批的结果进行风险加权抽样，定期交由人工复查；
第四，通过仪表盘跟踪各个安全流程的关键指标，监控流程是否正常运行、效果是否发生变化；
第五，将AI的审批、工具调用和智能体间的通信记录到安全信息和事件管理系统，确保每个操作都可归因、复盘和审计。
安全工程师的工作也从紧盯单个代码漏洞，转变为监控整个闭环是否正常运行。
落地实践的渐进式路径
这套方案并不要求团队一次性完成所有环节，可以根据自身需求逐步推进。如果需求经常在开发中途变更，可以先从建立intent.md开始；如果AI频繁重复犯错，可以先整理CLAUDE.md文件；如果AI总是声称任务完成却拿不出有效证据，可以补充测试反馈机制；如果担心高风险命令失控，可以先添加Hooks拦截；如果AI一次性改动范围过大，可以强制要求AI先提交执行计划。
这些基础操作没有复杂的前置条件，不需要一次性配齐所有工具。当团队熟练后，可以将成熟的方法整理为Skills，将复杂任务拆分为多个subagent处理，通过持续评测检查模型和规则升级是否带来体验退步。后续还可以逐步让AI接入需求设计、合并请求审查，进入持续集成和持续交付流程，最后连接线上监控，让系统自动诊断异常并生成新的intent.md，形成完整的闭环。
写在最后
Anthropic这套AI原生SDLC最核心的变化，是重新定义了人的位置。在流程入口，人负责确认需求意图；开发前，人负责批准执行计划；上线前，人负责最终授权；系统运行后，人负责抽查AI决策、更新规则和修正循环。
过去散落在Wiki、会议记录和老员工经验中的组织知识，也被写入版本控制系统，变成AI可以读取、流程可以执行的标准化规则。
如果希望在团队中尝试这套方法，不必先搭建完整系统，可以从项目根目录的CLAUDE.md开始：写清楚项目的构建测试规则、目录权限和禁忌操作，补充AI曾经犯过的错误的纠正方法。至于CLAUDE.md、Skills、Hooks、远程虚拟机和安全审计系统，都是Anthropic在自身生态中的具体实现，不需要完全照搬。
归根结底，AI可以加速开发执行，但需求意图的确认、风险的把控和最终的上线授权，依然需要清晰的人类责任边界。
