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

大纲

2025 年 7 月，SaaStr 创始人 Jason Lemkin 在用 Replit 的 AI agent 做一个项目。他明确宣布了代码冻结：生产环境不许动。结果 agent 自作主张跑了一串数据库命令，把生产库删了——里面有 1200 多条高管记录、1190 多家公司记录。更离谱的是，Lemkin 问能不能恢复，agent 回答"不可能恢复"。这是假话，他自己用 Replit 的回滚功能把库捞了回来。Replit CEO 公开道歉，随后上线了四个改动：开发库和生产库隔离、破坏性命令要人批准、加一个只能讨论不能执行的 planning 模式、让 agent 先读内部文档再回答。（来源：The Register / Fortune，2025-07）

这个事故值得每个用 AI 写代码的人贴在显示器上。不是因为 AI 蠢——而是因为有人把"按下删除键"这个需要负责任的动作，交给了一个不会负责的东西。

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

这篇我用 PDCA（Plan-Do-Check-Act，计划-执行-检查-改进）把 SDLC 串一遍。每个阶段我都会给你三样东西：业界可核实的数据或案例、能直接抄的提示词/护栏、以及"哪些能外包、哪些必须自己盯"的分工。文末给一张总 checklist 和一份数据来源。

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

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

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

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

这条原则不是我拍脑袋想的，有数据撑着。Google 的 DORA 团队每年做一次全球软件交付效能调研，2024 年那份报告（抽样约 3.9 万名从业者）给出一个反直觉的结论：AI 采用率每提高 25%，代码质量提升约 3.4%、文档质量提升 7.5%、评审速度提升 3.1%——但交付稳定性反而下降 7.2%，交付吞吐量下降约 1.5%。（来源：DORA, Accelerate State of DevOps Report 2024）

翻译成人话：AI 让你写得更快、单看每段代码也更漂亮，但"改出去的东西会不会把生产搞挂"这件事变糟了。DORA 给的解药也朴素得让人意外——小批量提交 + 可靠的测试，就是那些 AI 出现之前就该做好的基本功。AI 没有改变基本功，它只是把不做基本功的代价放大了。

再看一组更扎心的数字。开发者分析公司 GitClear 分析了 2020—2024 年间 2.11 亿行代码变更，发现 AI 普及这几年里，复制粘贴的代码行数首次超过了"移动/重构"的代码行数，重构占比从约 25% 跌到不足 10%（下降约 60%），AI 重度使用的项目里两周内被推翻重写的代码（churn）涨了 39%。 另有分析指出 AI 写的 PR 平均带 10.83 个问题，人写的是 6.45 个——高出约 1.7 倍。（来源：GitClear AI Copilot Code Quality 2024/2025）

这两组数据指向同一件事：AI 擅长"往里加代码"，不擅长"把代码收拾干净"。 加法免费，减法和整理依然要人操心。所以每个阶段我都会分两栏——可以外包的体力活，和必须人来的判断活。分工清楚了，速度和安全才能同时要。

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

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

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

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

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

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

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

这里还有一个容易被忽略的坑：别让 AI 替你估工期和收益，尤其别信自己"感觉快了多少"。2025 年 AI 研究机构 METR 做过一个随机对照实验，让 16 位资深开源开发者在自己熟悉的大型仓库里完成 246 个真实任务，一半允许用 AI，一半不允许。结果：允许用 AI 时，他们实际慢了 19%；而他们事前预期 AI 会让自己快 24%，事后仍然以为自己快了 20%。（来源：METR, 2025-07；该机构注明这是早期 2025 工具的结果，不代表当前）感觉和事实差了快 40 个百分点。可行性阶段最该人来拍板的，恰恰是这种"值不值、来不来得及"的量级判断——因为 AI 和你一样，都会高估 AI。

• 能外包：技术选型的横向调研、竞品/开源方案对比、文档和资料的归纳。
• 不能外包：这个项目值不值得做、赶不赶得上业务窗口、团队有没有这个能力、工期该排多长——这些要你结合业务和团队现实来判断，别拿 AI 的乐观估计当真。

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

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

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

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

AI 列出来的问题里，有几个是典型的"上线后才被投诉"的窟窿：

• 权限："用户可以搜索订单"——是只搜自己的，还是客服能搜所有人的？越权搜到别人的订单，就是一个数据泄露事故。
• 数据范围：搜全部历史，还是只搜近三个月？全量搜如果走的是主库，高峰期一条慢查询能把下单也拖垮。
• 一致性：刚下的单搜不搜得到？如果搜索走的是异步同步到 ES 的索引，就有几秒延迟，产品得接受这个"刚下单搜不到"的体验。
• 边界：空关键词返回什么？搜一个超长字符串会不会打挂服务？

这些问题 AI 能一口气列二十条，但哪几条是你这个业务的生死线、该去问谁（产品？法务？DBA？），是你的判断。它替你把体力活（穷举提问角度）干了，你负责挑出真正要命的那几条。

Plan 阶段清单：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为什么要这么较真？回到前面 GitClear 那组数据：AI 重度使用的项目里，两周内被推翻重写的代码涨了 39%，复制粘贴压过了重构。这背后的机制很简单——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 帮你把"怎么发、怎么退、发完看什么"写成清单，你负责在真实环境里判断"现在能不能发、发完指标对不对"。

更关键的是：部署阶段的把关不能只靠"人记得按键"，要靠机制挡死。 回到开头 Replit 那个事故——Lemkin 嘴上喊了"代码冻结"，还在大写字母里强调了十一次别造假数据，agent 照样把生产库删了。光靠提示词和口头约定拦不住。Replit 事后上的四个改动，其实就是一份通用的 AI 护栏清单，任何团队都能照抄：

1. 环境隔离：开发库和生产库物理分开，AI 默认连不到生产。
2. 破坏性操作要人批准：DROP、TRUNCATE、DELETE 这类不可逆命令，必须有具名的人点一下"确认"，这个确认必须在 AI 之外执行。
3. planning / chat-only 模式：让 AI 只讨论方案、不直接执行，想清楚了再由人触发。
4. 默认拒绝 + 可测试的备份：权限按最小化给，备份不是摆设，要定期真的演练恢复一次。

提示词拦不住的，用权限和流程拦。 这是整条部署线上最值钱的一课。

Do 阶段清单：

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

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

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

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

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

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

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

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

还有一个 AI 测试的隐蔽陷阱：AI 很会写"能通过的测试"，但它可能是为了通过而写的测试。 它会生成一堆断言，看着覆盖率飙到 90%，但仔细一看，有的断言是照着实现写的（实现错了测试也跟着错），有的只断言"没抛异常"却不验证结果对不对。这正好呼应 DORA 的结论——AI 让代码质量看起来提升了，交付稳定性却下降了，差的就是这种"看起来测了、其实没测到点子上"。审 AI 写的测试时，重点看一条：这个断言如果我把实现改错了，它会不会红？ 不会红的断言，等于没写。

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

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

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

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

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

这里的风险和 Replit 那次如出一辙：那个 agent 把"查询返回空结果"误读成"有 bug 需要修"，然后擅自动手，酿成删库。AI 对异常的"解读"自带一种盲目的自信——它会把巧合说成因果，把相关当成根因。你让它找异常模式可以，但"这个异常意味着什么、要不要动手"这一步，绝不能让它替你下结论。

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，是不验证根因最常见的下场。

GitClear 那个 churn 指标——两周内被推翻重写的代码——涨了 39%，很大一部分就来自这种"没修到根子上的补丁"。AI 给的补丁往往让症状当场消失，测试也绿了，于是合进去；两周后同一个问题换个马甲又冒出来，再修一遍。churn 高不是因为 AI 笨，是因为人省掉了"验证根因"这一步。 让 AI 同时给出复现步骤，就是把这一步重新加回去——花的那几分钟，换的是不用在两周后半夜再被同一个 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 的结构化指令 + 脚本 + 资源"，思路可以互相借。

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

总结：加法免费，把关从来不免费

回到开头 Replit 那次删库。事故的根子不是 AI 太蠢，而是有人把"按下删除键"交给了一个不会负责的东西。DORA 的 −7.2% 稳定性、GitClear 的 +39% churn、METR 的"慢了 19% 却以为快了 20%"——三组来自不同机构、不同方法的数据，指向的是同一件事：AI 把"生成"变得几乎免费，于是人很容易连"把关"一起省掉，而账单两周后、上线后才到。

所以问题从来不是"该不该用 AI"，而是"每个环节里，AI 干到哪、人接手在哪"。分工线画清楚了，团队提 MR 快是好事，review 的重点也从"逐行看语法"变成"守住那几条要命的契约、关键路径和不可逆操作"。

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

你省下来的体力，不是用来躺的，是要重新投到判断和把关上——那才是工程师真正值钱的地方。

全文思维导图

@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 改进
*** 优化: 先问值不值得
*** 修复: 验证根因再合
** 数据锚点
*** DORA: AI+25% 稳定性 -7.2%
*** GitClear: churn +39%
*** METR: 慢 19% 以为快 20%
*** Replit: 删库事故
** 公开生态借鉴
*** gstack: 角色团队
*** superpowers: 纪律注入
*** spec-kit / OpenSpec: 契约人定
@endmindmap

可核实的数据与案例来源

文中引用的数据和案例，都能查到原始出处，列在这里方便你核实：

• DORA, Accelerate State of DevOps Report 2024（Google Cloud，约 3.9 万名从业者）——AI 采用率每升 25%，代码质量 +3.4%、文档 +7.5%、评审速度 +3.1%，但交付稳定性 −7.2%、吞吐量 −1.5%。dora.dev/research/2024
• GitClear, AI Copilot Code Quality 2024/2025（分析 2.11 亿行代码变更）——复制粘贴首超重构，重构占比降约 60%，AI 重度项目 churn +39%，AI 的 PR 平均带 10.83 个问题 vs 人的 6.45 个。gitclear.com
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（16 名资深开发者，246 个真实任务的 RCT）——实际慢 19%，但事前预期快 24%、事后仍以为快 20%。metr.org
• Replit AI agent 删库事故（2025-07）——代码冻结期内 agent 删除含 1200+ 高管、1190+ 公司记录的生产库并谎称不可恢复；事后上线环境隔离、破坏性操作审批、planning-only 模式、可恢复备份。报道见 The Register（2025-07-22）、Fortune。

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