ARTICLE · 1205837

笔记+视频 | AI原生软件开发生命周期手册

发布时间：2026-10-18 17:04:37 最近访问：2026-10-18 17:04:40

AI原生软件开发生命周期手册

AI大幅加速代码生成，但传统SDLC流程、审批、治理机制仍为人类节奏，成为新瓶颈，需要对完整SDLC做重构，而非仅引入AI写代码；转型后保留人的最终决策权，流程变为闭环循环，AI嵌入每个阶段。

核心认知：代码不再是瓶颈

传统SDLC：以「编码是最耗时环节」设计，分计划、设计、构建、测试、部署、维护6个线性离散阶段，不同角色分工，依靠文档、工单、审批流转。
AI带来的变化：Agent可以快速产出代码，但「计划、评审测试、部署仍为人类速度」，成为新瓶颈；逐行人工评审跟不上AI大量代码输出；治理、合规会议跟不上迭代节奏。
AI‑Native SDLC（也叫Agentic SDLC）：不抛弃原有管控目标，改变执行方式；流程由线性改为闭环循环；每个阶段产出「可版本控制的制品（Markdown文档）」，制品自动触发下一阶段流转，形成可审计链路；人聚焦高价值判断，而非重复执行工作。

关键制品：intent.md、spec.md、plan.md、CLAUDE.md，全部纳入Git版本管理，同时作为审计线索。

传统SDLC vs AI‑Native SDLC六阶段对比

阶段	传统SDLC	AI‑Native SDLC
计划Plan	委员会收集需求，会议评审，人工编写	AI从原始信息提炼，输出机器可读+人可读`intent.md`
设计Design	分析师写规格，设计师再解析做设计	Agent读取intent，结合组织规范技能一次性产出设计spec.md，Git版本管理
构建Build	人工写代码、后补文档	AI生成代码和测试；团队知识保存在`CLAUDE.md`与skills中
测试Test	阶段边界设置QA关卡	实现过程持续评估（continuous evals）
部署Deploy	人工逐行代码评审，评审周期治理，一致性差	多层Agent评审，人仅评审高风险/受监管代码；AI执行时就施加治理，设置审批钩子
维护Maintain	人工盯生产环境bug	Agent监控线上；指标异常后生成新`intent.md`回灌到流程闭环

六大阶段实操要点

1. Plan 计划阶段：产出intent.md

intent.md是流程起点：由想法、工单、线上事故告警生成，记录问题、预期结果、影响用户/系统、约束、开放问题。
工作流：提出人用自然语言和Claude头脑风暴 → AI生成初稿 → 提出人修正 → Git提交；产品负责人评审。
收益：将数周的需求提炼周期缩短至数小时；Git历史完整记录作者、时间，作为审计证据。
不强制所有人会Git，可通过连接器让Claude代为提交Markdown。

2. Design 设计阶段：产出spec.md

输入：已批准intent.md；组织预先把品牌、安全、合规、UX封装为「Skills（技能集）」。
工作流：Agent读取intent，加载组织约束技能，输出spec.md，标记风险点；产品负责人评审，提前解决风险，再进入构建阶段。
价值：需求与设计合并为一次会话，避免多团队传递带来信息损耗；策略在编写规格时就生效，而不是数周后评审才发现。

3. Build 构建阶段：产出plan.md，核心配置CLAUDE.md、Skills、Hooks、并行会话

「Plan Mode（计划模式优先）」：工程师先让Agent输出实现计划plan.md，明确变更文件、工作顺序、风险点、验证方案；工程师确认计划后AI才生成代码；代码变更偏离计划时同步更新plan.md。
「Auto Mode自动模式」：成熟后常规变更启用，减少逐编辑确认，工程师转为审查最终制品。
「CLAUDE.md」：放在代码库根目录，相当于AI版新员工手册，记录构建命令、编码规范、架构、AI高频踩坑点；规则：AI重复犯错两次就要写入此文件，保持简短。
「Skills技能」：把组织制度、安全标准封装为可复用、版本化组件；适合需要全局一致执行的制度；仅为建议性约束。
「Hooks钩子」：确定性强制防护，弥补Skills的非强制缺陷；可阻止修改受保护文件、清理凭证、运行格式化检查。
「并行会话 & Subagents」：工程师同时运行多个独立Claude Code会话（git worktree隔离）提升吞吐量；重复任务封装为子Agent；工程师角色转为编排者、评审者。
迁移提示：不必完全替代Jira/Figma等旧系统，设置单一可信源，或者双向链接Git制品与旧系统记录。

4. Test 测试阶段：反馈闭环 + CI持续评估

「本地反馈闭环」：给Agent提供自测手段（单元测试、构建、UI截图比对），Agent提交给人之前自动修复失败项；通过Hook禁止Agent在修复bug时篡改测试用例。
「持续评估」：在CI流水线对Agent本身做回归测试；当CLAUDE.md/Skills/Hooks修改、模型升级时自动执行；线上事故转化为评估用例，防止同类问题复现。

目标：不让人承担全部AI产出的验证负担。

5. Deploy 部署阶段：AI参与PR评审、钩子审批闸门、CI/CD集成

「AI参与PR评审循环」：AI统一执行多维度评审（bug、安全、是否符合spec/plan），按严重程度分级；人聚焦业务意图与风险判断；AI可自动处理评审意见；评审发现的高频错误回填到CLAUDE.md。评审规则定义在REVIEW.md。
「Hooks作为审批闸门」：可以拦截、允许或暂停等待人工审批；关键场景：生产环境部署必须人工授权；受管控文件修改需要审批。企业可部署托管设置，工程师无法绕过管控。
「CI/CD集成非交互式Claude Code」：在流水线运行AI，做构建失败分析、生成更新文档；通过MCP工具暴露部署能力；按环境分级授权：开发环境Agent自由度高，生产环境必须人工审批；回滚方案要提前演练。
核心治理原则：Agent可以做所有到生产闸门之前的工作，但「不能越过生产审批闸门」。

6. Maintain 维护阶段：闭环闭环，事件回灌intent.md

目标：实现无人启动的自主触发，把线上异常重新输入SDLC流程。

「控制带监控闭环」：确定性脚本监控指标，当指标超出统计阈值（σ）分级处理：仅记录 → Agent只读诊断 → Agent提出修复PR/执行预定义预案；Agent输出诊断结果为intent.md进入Plan流程，由人做最终分诊；修复上线后增加对应的eval用例。
「定期代码扫描（Claude Security）」：定时扫描仓库，发现漏洞；简单问题生成PR，复杂问题生成intent.md进入流程。
「Claude Tag」：接入Slack/Teams等协作工具，作为事件第一响应者；可做问题排查、生成PR或intent.md；聊天记录作为审计链路。

治理与安全核心原则

所有AI相关配置文件（intent/spec/plan、CLAUDE.md、Skills、Hook配置）全部Git版本管控，变更可追溯，构成完整审计链路。
Skills是软性引导，高强制要求必须搭配Hook钩子做强制拦截。
企业托管设置：管理员统一管控权限、沙箱、网络、允许的MCP/插件，普通工程师不能绕过安全配置。
人保留全部高风险决策：审批、判断意图、风险评估；Agent负责执行、初步检查。

衡量指标体系

每个实践配套「领先指标（过程）、滞后指标（结果）」

领先：耗时、通过率、并发会话、变更通过第一版占比；
滞后：返工率、逃逸到生产缺陷、事故复现率、DORA部署指标。

落地建议

模块化落地，不用一次性改造全部SDLC，可以优先改造部分阶段；
从简单Play入手（无依赖项），逐步增加依赖能力；
保留现有企业工具链，采用链接或双记录过渡，不必立刻替换Jira、静态扫描等；
持续把事故、评审错误沉淀到CLAUDE.md、Skills、Eval测试集，持续训练约束Agent。

结语

AI原生SDLC不是仅仅让AI写代码，而是重构完整软件生命周期；「流程闭环运行，但人的判断始终处于上层，不被AI替代」。