The AI-Native SDLC playbook

当 AI 写代码越来越快以后，整个软件开发流程也必须重新设计。

SDLC 就是 Software Development Life Cycle，中文叫“软件开发生命周期”：一个想法从提出，到设计、开发、测试、上线，再到后续维护的全过程。

先理解最核心的问题

传统流程像一家老工厂：

1. 产品经理花几周写需求。

2. 设计师和架构师做方案。

3. 程序员花几周写代码。

4. 测试人员检查。

5. 负责人审批上线。

6. 运维人员监控故障。

以前“写代码”最慢，所以其他流程都围绕程序员安排。

现在 AI 可能几小时就写完代码，但需求确认、评审、测试、审批仍需要几天。于是堵车点从“写代码”转移到了代码前后的环节。

所以，AI-native SDLC 不是只改造编程阶段，而是让 AI 参与整个生命周期，同时把人类注意力集中到真正需要判断和负责的地方。原文：The AI-Native SDLC Playbook

flowchart TD
    A["计划<br/>intent.md"] --> B["设计<br/>spec.md"]
    B --> C["开发<br/>plan.md + 代码"]
    C --> D["测试<br/>测试结果 + Evals"]
    D --> E["部署<br/>PR 审查 + 人工批准"]
    E --> F["维护<br/>监控、诊断、回滚"]
    F -->|"发现新问题"| A

用一个例子理解六个阶段

假设我们要给电商网站增加“订单物流进度查询”。

1. Plan：先说清楚“为什么做”

业务人员直接告诉 AI：

客服每天收到很多查询物流进度的电话。我希望用户能自己查看，减少客服工作量。

AI 继续追问：

• 哪些用户可以看？

• 展示哪些信息？

• 什么不能展示？

• 怎样算成功？

最后生成 intent.md：

# 目标
让登录用户自行查看订单物流进度。

# 原因
物流查询占客服咨询量的 30%。

# 约束
不能暴露收件人的完整手机号和地址。

# 成功标准
物流类客服咨询减少 20%。

重点：intent.md 描述的是“为什么做、想达到什么效果”，不是急着决定代码怎么写。

人类要检查 AI 有没有理解错，然后批准。

2. Design：把想法变成可执行规格

AI 读取 intent.md，结合公司的安全、品牌和技术规范，生成 spec.md：

# 功能
用户可在订单详情页查看物流节点和预计送达时间。

# 接口
GET /api/orders/{id}/tracking

# 权限
只能查询当前登录用户自己的订单。

# 隐私
隐藏完整手机号和详细地址。

# 异常情况
物流服务不可用时展示稍后重试。

这里 AI 负责起草，人类负责判断：

• 这个设计真的解决了原问题吗？

• 安全和隐私有没有遗漏？

• 成本是否合理？

• 风险是否值得接受？

3. Build：先写施工计划，再写代码

工程师先让 AI 只读代码库，不马上修改，然后生成 plan.md：

# 修改文件
- tracking-api.ts
- OrderTrackingPanel.tsx
- tracking-api.test.ts

# 实施顺序
1. 添加后端物流查询接口
2. 添加权限校验
3. 编写测试
4. 添加前端展示组件

# 风险
第三方物流接口有频率限制，需要缓存。

工程师先检查这个计划。计划正确以后，AI 才开始改代码。

好处是：如果方向错了，改一份计划很便宜；等几千行代码写完再发现方向错了，返工就很贵。

四类文件最容易混淆

最重要的区别是：

CLAUDE.md 和 Skill 主要是在“告诉 AI 应该怎么做”；Hook、权限和测试才是在“确保它不能乱做”。

例如：

• Skill 告诉 AI：“日志中不能记录用户手机号。”

• Hook 或静态检查发现手机号字段进入日志时，直接阻止提交。

文章明确指出，Skill 属于建议性控制；必须百分之百执行的规则，需要 Hook、测试或审批机制兜底。

4. Test：让 AI 自己验证，而不是写完就交差

AI 每完成一部分，都要获得明确反馈：

• 运行测试；

• 编译项目；

• 执行代码检查；

• 打开网页并截图；

• 将截图与设计稿比较。

发现错误后，AI继续修改和验证，直到检查通过。

修复 Bug 时尤其推荐：

1. 先写一个能复现 Bug 的测试。

2. 确认测试确实失败。

3. 锁住测试，不让 AI 修改它。

4. 只允许 AI 修改业务代码。

5. 直到原测试通过。

另外，普通测试和 Eval 不一样：

• 测试：检查软件写得对不对。

• Eval：检查 AI 的工作方式有没有退化。

5. Deploy：AI 可以走到生产门口，但不能自己闯过去

AI 可以：

• 自动审查 PR；

• 检查安全、逻辑和合规问题；

• 根据评论修改代码；

• 分析构建失败原因；

• 准备发布；

• 准备回滚方案。

但高风险操作仍由人类批准，例如：

• 合并关键代码；

• 修改数据库；

• 发布到生产环境；

• 访问敏感数据。

文章的原则可以概括成：

AI 可以完成生产门之前的一切，但不能自行通过生产门。

而且“生产环境需要批准”不能只写在提示词里，应该通过 Hook、分支保护和权限系统强制执行。

6. Maintain：生产问题自动回到开发流程

系统上线后，监控程序发现错误率异常：

1. 确定性的监控规则先判断是否越界。

2. 轻微异常只记录。

3. 中等异常调用 AI 进行只读诊断。

4. 严重异常允许 AI 创建修复 PR，或执行预先批准的回滚。

5. AI 把问题写成新的 intent.md。

6. 问题重新进入计划、设计、开发、测试和部署流程。

这里有一个非常重要的安全设计：

是否出现异常，最好由确定性的监控规则决定；AI 负责解释和处理异常，不负责随意判断什么时候应该启动自己。

这样，SDLC 就不再是一条做到上线就结束的直线，而是一个不断学习和修正的闭环。

人类的工作发生了什么变化？

人类没有被移出流程，只是从“亲手执行每一步”转向：

• 定义目标；

• 澄清约束；

• 判断风险；

• 审批关键决策；

• 检查 AI 提出的异常；

• 改进规则、测试和知识库。

简单说：

AI 负责跑流程，人类负责定方向、设边界和承担责任。

小团队应该怎么开始

不需要一次性照搬整套企业方案。我建议按这个顺序：

1. 写一份简短的 CLAUDE.md。

2. 要求 AI 修改代码前先提交计划。

3. 把构建、测试、检查统一成几个简单命令。

4. 明确“完成”必须附带测试结果。

5. 引入 intent.md → spec.md → plan.md。

6. 增加 AI PR 审查。

7. 用 Hook 保护生产发布、密钥和关键文件。

8. 最后才考虑自动监控、自动修复和多 Agent 并行。

不要一上来追求“完全自主”。如果测试、权限和审批都没有成熟，并行运行更多 Agent 只会更快地产生更多待审查代码。

最后用一句话记住整篇文章：

AI-native SDLC = 让 AI 贯穿开发全流程，让文档和代码成为可传递、可审计的接力棒，让机器负责执行，让人类负责判断。