用 AI 跑通软件研发全流程：PDCA 里的体力活外包指南

大纲

上周和一个刚带团队的朋友聊天，他很焦虑：组里几个年轻人用 AI 写代码飞快，一天能提五六个 MR，他一个人 review 到眼睛发花，还总觉得哪里不对劲。他问我：是不是该禁掉 AI？

我说别急着禁，你先想清楚一件事——AI 到底在你的研发流程里干什么活。

大多数人对 AI 的用法还停留在"帮我写个函数"。这就像雇了个能扛能跑的壮劳力，却只让他递扳手。软件研发从可行性到上线再到优化，是一整条流水线，每个环节都有大量重复、繁琐、靠体力堆的活。AI 最该接管的，正是这些体力活；而判断、取舍、把关这些需要"负责任"的事，还得人来。

这篇我用 PDCA（Plan-Do-Check-Act，计划-执行-检查-改进）把 SDLC 串一遍，每个阶段告诉你：哪些活可以放心外包给 AI，哪些必须自己盯着，以及具体怎么做。文末给一张总 checklist，可以直接抄去对着用。

• 核心分工：AI 负责"生成和铺量"，人负责"定标准和验收"。
• 这不是"用不用 AI"的问题，是"在哪一步用、用到什么程度"的问题。

先立一个原则：谁来背锅，谁就得把关

在讲每个阶段之前，先把总原则钉死，否则后面全是散招。

凡是出了事需要有人负责的判断，AI 不能替你做；凡是可以推倒重来、代价很低的产出，尽管让 AI 多来几遍。

这条原则是我踩过坑换来的直觉。AI 生成一段代码错了，你删掉重来，成本几乎为零；但如果你让 AI 替你决定"这个需求要不要做""这个方案上不上生产"，一旦错了，赔进去的是几周的工期甚至一次线上事故——而 AI 不会为此负责，只有你会。

所以每个阶段我都会分两栏：可以外包的体力活，和必须人来的判断活。分工清楚了，速度和安全才能同时要。

Plan：让 AI 当陪练，别让它当裁判

计划阶段两件事：可行性分析、需求分析。这两件事的共同点是——信息密集，但结论必须人拍板。

可行性分析：AI 铺信息，人做减法

可行性分析最耗时的是前期调研：这个技术方案有没有人做过、有哪些坑、性能天花板在哪、有没有现成的库。这些"查资料"的活，AI 一天能干完你一周的量。

具体做法： 把你的技术设想丢给 AI，让它扮演反方，列出所有可能失败的理由。

我准备用 WebSocket + Redis Pub/Sub 做一个万人同时在线的实时协作后端。请你扮演一个挑刺的资深架构师，列出这个方案在 10k 并发下最可能出问题的 5 个点，每个点给出为什么，以及业界常见的替代方案。

AI 会给你一份"风险清单"。注意——这份清单是靶子，不是结论。里面一半可能是幻觉或过时信息，你要做的是逐条核实，然后做减法：哪些是真风险，哪些不适用于你的场景。

• 能外包：技术选型的横向调研、竞品/开源方案对比、性能量级的初步估算。
• 不能外包：这个项目值不值得做、赶不赶得上业务窗口、团队有没有这个能力——这些要你结合业务和团队现实来判断。

需求分析：AI 帮你把话问清楚

需求分析最痛的不是写文档，是发现需求里的窟窿。产品说"做个搜索功能"，AI 可以帮你把这句话炸开成一堆必须澄清的问题。

具体做法： 让 AI 用"提问"的方式帮你补全需求，而不是直接写需求文档。

这是一条原始需求："用户可以搜索订单。"请你以一个严谨的需求分析师身份，列出在动手前必须向产品经理澄清的问题，按"数据范围、权限、性能、边界情况、异常处理"分类。

AI 列出来的问题里，"搜索历史订单还是只搜近三个月""无权限用户搜到别人的订单怎么办"这类你可能当场就想不全。它替你把体力活（穷举提问角度）干了，你负责判断哪些问题真的重要、去找谁问。

Plan 阶段清单：

1. 让 AI 扮演反方做可行性挑刺，产出风险靶子。
2. 逐条核实风险，剔除幻觉和不适用项。
3. 让 AI 把模糊需求炸成澄清问题清单。
4. 人来判断：做不做、能不能做、优先级怎么排。

Do：AI 砌砖，你画图纸和验收

执行阶段四件事：设计、编码、构建、部署。这是 AI 最能出力、也最容易出事的地方。

设计：契约你定，实现让 AI 填

设计的核心是定契约——接口长什么样、数据怎么流、模块边界在哪。契约必须人来定，因为它决定了系统能不能长期演进；实现细节可以让 AI 填。

具体做法： 你写接口定义和约束，让 AI 生成实现骨架和多个设计选项。

这是我定的接口（贴上 OpenAPI 或函数签名）。约束：必须幂等（同一请求重复调用结果一致）、超时 3 秒、失败要能重试。请给出三种实现思路，分别说明各自的 trade-off。

拿到三个选项后，选哪个是你的判断。AI 给你的是"有哪些路可走"，走哪条路是工程师的活。

• 能外包：把接口翻译成实现骨架、生成样板代码、列出设计选项。
• 不能外包：接口定义、模块边界、数据模型、一致性保证——这些错了，后面全盘皆输。

编码：小步生成，即时验证

编码是 AI 最擅长的体力活，但也是"看起来对、跑起来错"重灾区。诀窍是别让它一次生成一大坨。

具体做法： 用测试先行的方式约束 AI。先让它写测试（或你自己写），再让它写实现让测试通过。

先根据这个函数签名和这几条验收标准写 pytest 测试用例，覆盖正常、边界、异常三类。写完等我确认，再写实现。

这样做的好处是——测试就是你给 AI 的"契约"，AI 写的实现能不能过测试，是可验证的，不靠你肉眼盯。AI 写代码的速度再快，也快不过一个能自动跑的测试给你的信心。

构建：把 AI 当"配置翻译官"

构建阶段的活——写 Dockerfile、CI 流水线、依赖管理——是高度模式化的体力活，AI 干这个又快又准。

具体做法： 直接让 AI 生成构建配置，但版本和源必须你来锁死。

给我一个多阶段构建的 Dockerfile，基础镜像用 python:3.12-slim，装依赖用 poetry，最终镜像不含构建工具。

AI 生成的配置里，基础镜像标签、依赖版本、镜像源这些安全相关的东西，一定要人来核对——别让它偷偷给你用了 latest 标签或来路不明的源。

部署：AI 写脚本和 MOP，人按下发布键

部署脚本、回滚方案、发布 MOP（Method of Procedure，操作手册），AI 都能写。但"按下发布键"这个动作永远是人的。

具体做法： 让 AI 生成部署步骤和对应的回滚步骤，成对出现。

我要把这个服务从 v1.2 灰度到 v1.3，先 10% 流量。请给出部署步骤，每一步配一个对应的回滚动作，以及每步之后应该检查的指标。

有回滚才敢发布。AI 帮你把"怎么发、怎么退、发完看什么"写成清单，你负责在真实环境里判断"现在能不能发、发完指标对不对"。

Do 阶段清单：

1. 契约（接口/边界/数据模型）人定，实现骨架让 AI 生成。
2. 测试先行，用可自动跑的测试约束 AI 的产出。
3. 构建配置让 AI 写，版本和源人来锁死。
4. 部署和回滚成对生成，发布键人来按。

Check：AI 铺量测试，人盯口径和异常

检查阶段两件事：测试、指标监控。这里 AI 能帮你把"覆盖面"做大，但"看得懂"还得靠人。

测试：AI 补全覆盖，人守住关键路径

写测试用例是标准的体力活——尤其是穷举边界情况、造测试数据、写重复的断言。AI 在这里能把你的测试覆盖率拉上去一大截。

具体做法： 让 AI 针对已有代码补测试，重点补你容易漏的边界。

这是我的函数实现。我已经写了正常路径的测试。请补充边界情况和异常路径的测试：空输入、超大输入、并发调用、依赖服务超时。

但要清醒：AI 补的是"数量"，你守的是"质量"。核心业务逻辑的关键路径，那几条最要命的测试，最好你亲自写或至少逐行审——因为这些路径错了，AI 补再多边界用例也救不回来。

指标监控：AI 帮你从噪声里捞信号

线上指标一大堆，Prometheus 面板几十个图。哪个指标异常、异常意味着什么，人盯着看很累。AI 可以帮你做初筛。

具体做法： 把指标数据或日志片段丢给 AI，让它找异常模式，但告警阈值和处置动作由人定。

这是过去一小时的接口延迟 P99 数据（贴数据）。帮我找出异常时间段，并推测可能的原因。

AI 能快速指出"14:20 到 14:35 延迟翻了三倍"，甚至猜出可能是 GC 或依赖抖动。但它的推测是线索，不是定论。真正定位根因、决定要不要拉警报、要不要半夜叫人起来，是你的判断。

Check 阶段清单：

1. 让 AI 补全边界和异常测试，拉高覆盖率。
2. 关键业务路径的测试人亲自写或逐行审。
3. 用 AI 从指标/日志里初筛异常模式。
4. 阈值、告警、处置动作由人定，AI 的推测只当线索。

Act：AI 给方案，你决定改不改

改进阶段两件事：优化、修复。这里最危险的一个诱惑是——看到 AI 给的方案很像那么回事，就直接采纳。

优化：先问"值不值得优化"，再让 AI 出招

性能优化最容易掉进的坑是"为了优化而优化"。AI 很乐意给你一堆优化建议，但"要不要优化这一块"是人先要回答的问题。

具体做法： 先用数据确认瓶颈真的在这，再让 AI 出优化方案，并让它说清代价。

这段代码 profiling 显示占了 40% 的耗时（贴 profiling 结果）。给出三种优化方案，每种说明预期收益和引入的复杂度/维护成本。

关键在最后半句——让 AI 把代价也说出来。一个把代码提速 20% 但让可读性崩盘的方案，多数时候不值得。收益和代价的权衡，是工程师拍板的地方。

修复：AI 定位 + 出补丁，人验证根因

修 bug 时，AI 能帮你快速定位嫌疑代码、给出补丁。但"这真的是根因吗"必须人来验证——AI 经常给你一个"能让症状消失"但没修到根子上的补丁。

具体做法： 让 AI 给出根因假设和补丁，但要求它同时给出"如何证明这就是根因"的验证方法。

这是错误堆栈和相关代码（贴上）。给出最可能的根因假设、对应补丁，以及一个能证明这个假设成立的最小复现步骤。

有了最小复现步骤，你就能验证 AI 的判断对不对，而不是"看着像对的就合了"。改一个 bug 引入两个新 bug，是不验证根因最常见的下场。

Act 阶段清单：

1. 优化前先用数据确认瓶颈真实存在。
2. 让 AI 给优化方案时，必须连代价一起给。
3. 修 bug 让 AI 给根因假设 + 补丁 + 复现步骤。
4. 人验证根因成立，再合补丁。

公开生态借鉴：别从零发明，先看别人怎么把关

上面这套分工，你不用从零搭。公开社区已经有一批开源的 skill 框架把类似思路固化下来了——有的能直接装来用，有的更值得读它的结构照着改。我按"贯穿全流程"和"单点能力"两档给你列出来，都是 GitHub 上能查到的公开项目。

一、两个当下最火的"全流程"框架

先说两个绕不开的名字，它们恰好代表两种相反的思路。

gstack（garrytan/gstack）——把 Claude Code 变成一支虚拟团队。 Y Combinator CEO Garry Tan 开源的个人配置，两个月冲到近 9 万星。它用 23 个角色 skill 扮演 CEO、Designer、Eng Manager、Reviewer、QA Lead、Security Officer、Release Manager、Doc Engineer……每个角色一个 slash command。它的 sprint 阶段流转是 Think → Plan → Build → Review → Test → Ship → Reflect——几乎就是本文 PDCA 的另一种写法。MIT 许可，遥测默认关，还能跑在 Codex CLI、Cursor、OpenCode 等十来个 agent 上。

一句诚实的边界：社区里有资深评价说它"看着比实际强"——角色扮演的骨架好看，深度未必够。当模板和编排范本看很好，当银弹用要留神。

superpowers（obra/superpowers）——把工程纪律强制注入 AI 工作流。 Jesse Vincent 的项目，Claude 官方 marketplace 安装量过百万。它不玩角色扮演，而是一套可组合的 skill 库 + 自动 hook，覆盖 Testing（TDD、异步测试、反模式）、Debugging（系统化调试、根因追踪、验证）、Collaboration（头脑风暴、规划、代码评审）、Development（git worktree、子 agent），还有教你写 skill 的 meta skill。它最值得学的是架构：文件即 skill、平台无关核心、会话启动自动注入、技能优先级覆盖（个人 > 项目 > 库）。装法一行：/plugin marketplace add obra/superpowers。

两者对照着看更清楚：

一句话概括：gstack 教你把流程"分角色"，superpowers 教你把纪律"变强制"。都别整套照搬，拆开看它们怎么解决"人守判断权"这件事。

二、"规范驱动开发"框架：呼应"契约人定"

如果你认同本文"契约必须人来定"那条，这两个专门解决它：

• github/spec-kit —— GitHub 官方的 Spec-Driven Development 工具包，让 coding agent 按结构化流程走，把意图和证据固定成可执行规范。
• Fission-AI/OpenSpec —— 一条命令生成 proposal.md（为什么做）、specs/（需求场景）、design.md（技术方案）、tasks.md（实现清单），先对齐"做什么"再动代码，无需 API key。

三、单点能力与"总入口"清单

按 SDLC 阶段能直接借用或照抄的公开资源：

不想一个个搜，先翻这几个精选清单（持续更新）：

• hesreallyhim/awesome-claude-code —— 手工精选，质量最稳
• JackyST0/awesome-agent-skills —— 中文维护，覆盖 Cursor / Claude Code / GitHub Copilot 三个生态
• PatrickJS/awesome-cursorrules —— Cursor 生态的 rules 集合
• continuedev/awesome-rules —— 标准 Markdown + YAML frontmatter，跨多个 AI 助手通用

跨生态提醒：Cursor 的 .cursorrules、Claude 的 SKILL.md、Continue 的 rules，格式不同，但底层都是"给 AI 的结构化指令 + 脚本 + 资源"，思路可以互相借。

一句提醒：通用能力（评审、测试、需求澄清）从公开库借，能直接用；平台强相关的（部署、内部监控）绑得越深越好用，也越不可移植——这类更适合照着模板写自己的。

总结：AI 接管体力活，人守住判断权

回到开头那位焦虑的朋友。他真正要解决的不是"该不该用 AI"，而是"每个环节里，AI 干到哪、人接手在哪"。分工线画清楚了，年轻人提 MR 快是好事，他 review 的重点也从"逐行看语法"变成"守住那几条要命的契约和关键路径"。

把这条分工线钉在墙上，比任何提示词技巧都管用：

一句话记住它：

AI 让"生成"变得几乎免费，但"正确性"从来不免费。 你省下来的体力，要重新投到判断和把关上——那才是工程师真正值钱的地方。

全文思维导图

@startmindmap
<style>
mindmapDiagram {
  node {
    BackgroundColor #F8F9FA
    RoundCorner 10
    Padding 10
    FontSize 13
  }
  :depth(0) {
    BackgroundColor #1E3A5F
    FontColor white
    FontSize 18
    FontStyle bold
  }
  :depth(1) {
    FontSize 15
    FontStyle bold
  }
  :depth(2) {
    FontSize 13
  }
}
</style>

* 用 AI 跑通 SDLC (PDCA)
** 原则
*** AI 干体力活
*** 人守判断权
*** 谁背锅谁把关
** Plan 计划
*** 可行性: AI 挑刺, 人做减法
*** 需求: AI 炸问题, 人定优先级
** Do 执行
*** 设计: 契约人定, 实现 AI 填
*** 编码: 测试先行
*** 构建: 版本人锁死
*** 部署: 发布键人来按
** Check 检查
*** 测试: AI 铺量, 人守关键路径
*** 监控: AI 初筛, 人定阈值
** Act 改进
*** 优化: 先问值不值得
*** 修复: 验证根因再合
** 公开生态借鉴
*** gstack: 角色团队
*** superpowers: 纪律注入
*** spec-kit / OpenSpec: 契约人定
@endmindmap

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。 欢迎在我的个人网站 https://www.fanyamin.com 访问原文并评论。