pdlc-skills 如何在 AI 辅助编程中保障项目质量？

上一篇讲了循环怎么自主运转。跑得越快，一个老问题就越突出：AI 产出的这些东西，质量谁来保证？ 它不知疲倦，一个下午写出的代码，够人审好几天。这一篇讲我在 pdlc 里怎么解决这件事：不靠某一道关卡，靠一条链上的七个环节。

为什么 AI 写代码，质量反而更重要

以前写代码，质量靠两件事撑着：一是写的人自己心里有数，二是产出量有限，评审看得过来。AI 一来，这两个前提同时没了。

它没有”心里有数”这回事。 让 AI 给自己的工作打分，它会系统性地往好里说。这不是撒谎，它确实认为自己做得不错。所以在 pdlc 里，模型的自检结果单独记一栏，不参与任何”该不该停”的判断。

量也变了。 上一篇那次无人值守，一个下午跑完了一个三期迭代：四个后端接口组、三个前端页面、一整套通知规则。这些活以前要做好几天。产出快了，但”判断它对不对”这件事没有变快，还是同一双眼睛、同样的时间。

这个差距本身就是风险，跑得越快，错的东西传得越远。所以质量保障不是拖速度后腿的负担，恰恰是让速度真正能用得上的刹车和方向盘。但它显然不能靠人逐行看代码，那等于把省下来的时间又还回去。

先说结论：七个环节串成一条链

我把质量保障拆成七个环节：

需求 → 设计 → TDD → 实现 → 单测 → E2E → 换个 AI 评审

前两环由 AI 写、AI 评，人在最后复核一次；中间四环由机器强制检查，没有商量余地：TDD 先立红灯，实现看退出码，单测要堆到足够厚，E2E 只守核心链路；最后一环换一个 AI 来做评审。这七环是串联的，不是并联的，任何一环出问题，前面几环的保证都会打折扣。需求写错了，后面测得再严，也只是把错的东西做得更结实。

下面按顺序逐个说。

环 1 与环 2：需求和设计，AI 写、AI 评、人复核

把需求和设计算进质量控制，可能有点出人意料，但这两环在最上游，它们决定了后面所有测试到底在验证什么。

这两份文档是 AI 写的。PRD 阶段有八项自检：背景和目标是否清楚、用户故事够不够、验收标准能不能量化、功能清单有没有标优先级，等等。过不了自检，就不能进入下一阶段。最后那项看起来最不起眼，讲到假绿的时候会发现它最要命。

写完之后，先由另一个 AI 评一遍，人最后复核一次。这个顺序不能反过来。如果需求和设计都要人从头写、逐字审，那 AI 产出得越快，人就越是瓶颈，回到开头那个问题，等于什么都没解决。人的位置是复核，不是执行。

但复核这一下不能省。该不该做、边界划在哪、拆成几块，都是判断题，没有任何命令能给出退出码。所以第 5 篇那条自主循环从来不碰这两环，只接手 TDD → 实现 → 评审。能自动发现错误的交给机器，不能的留给人拍板。

环 3：TDD，先写会失败的测试

写代码之前，先写一批注定跑不过的测试。这不是”建议先写测试”那种软性要求，而是硬要求。它带来一个实际的好处：从这一刻起，”做完了没有”有了一个跟模型无关的答案。跑一遍测试，退出码是 0 就是过了，不是 0 就是没过。

这道门能立住，前提是上一篇讲的 test-commands.yml 已经配好了。判定完全靠真跑命令，模型说自己做得挺好，在这里不算数。

环 4：实现，只看退出码

到这一步才轮到写代码。很多人觉得这一步没法管，代码是 AI 写的，总不能盯着它一行行看。其实这一步反而管得最严，因为进去之前和出来之后各有一道检查。

进门只查一件事：相关的测试必须存在，而且此刻是红的。 这条写在 pdlc 的铁律里，找不到测试，实现命令直接不执行，让你回去先补 TDD。”先写着，测试回头补”这种做法不被接受。

写代码的规矩只有一条：用最少的代码让这批测试变绿，然后才允许在测试保护下重构。这条规矩针对的是 AI 最省事的那条路，测试跑不过的时候，改测试永远比改代码容易。所以实现阶段不允许改测试文件，pdlc 的自动化验收里专门有一条断言：测试文件被改动，直接判失败。

写完之后要过三项检查：单测、覆盖率、lint。三项都是真跑命令看退出码，lint 要求零警告，不是”警告数别比上次多”就行。结果写进状态文件，pdlc 明确规定这三个字段只能填命令的退出码，不能拿模型自己的检查结果代替。有一项没过，这个阶段就不算完成，流程不往下走。

出了这道门还不算完。代码接着要送去评审，而评审也有自己的入口条件：测试没有全绿，评审不受理。夹在实现和评审之间的，就是接下来这两环。

环 5：单测要厚，但它只能证明零件是对的

有了前面两道门，接下来是把单测堆厚。我自己一个规模较大的项目，有四千多个单测用例，覆盖率 90% 以上。但堆到这个量级之后，我反而更清楚它的边界在哪：单测证明的是每个零件单独拿出来是对的，仅此而已。

有个数字最容易被当成保险：覆盖率。它衡量的是”这行代码被执行到了”，不是”这个业务逻辑是对的”。下面这个测试就能把一个函数的覆盖率拉满：

it('计算订单总价', () => {
  expect(calcTotal(order)).toBeDefined();
});

函数跑了，分支走了，报告上这一行是绿的，但它算得对不对，这个测试一个字都没说。倒不是谁存心作假，覆盖率天生只看执行，看不见断言。你越拿它当验收标准，它就越会朝”让数字好看”的方向漂移。

所以 90% 这个数我照写，但它证明的是”测试铺得够广”，不是”质量够好”。要回答后一个问题，得靠下一环。

环 6：核心链路交给 E2E

同一个项目里，核心业务流程的 E2E 有一百多条。四千比一百，这个配比本身就说明了两者的分工。

线上出事，很少是某个函数算错了，多半是几个各自正确的零件接在一起不对：状态没传过去、时序反了、边界上两边的理解不一致。这类问题单测天生看不见，因为它把依赖都 mock 掉了，而问题恰恰出在依赖之间。

所以核心链路必须有 E2E 守着。我用 Playwright 驱动 Chrome 跑真实页面：真的点进去、真的等接口返回、真的检查渲染结果。它慢，也更容易不稳定，但它是唯一能回答”这条业务流程今天还能不能走通”的手段。

/pdlc-quality 核对 E2E 的方式很直接：每条核心流程都要在映射文件里找到对应的测试，再到本次真跑的结果里确认它通过了，少一条就是红。不允许用”我觉得这条被别的测试覆盖了”来补空缺，那正是要消灭的主观判断。

环 7：每个阶段换一个 AI 来评审

最后一环是评审，而且不止一次：需求评审、设计评审、代码评审，各是一道。

关键在于”换一个”。开头说过，AI 给自己打分会系统性地往好里说，刚把一套设计想出来的那个 AI，紧接着去评这套设计，也不会例外。所以这几道评审我都是分开起的：换一个会话，用 subagent 拉起另一个 AI，或者干脆换个模型。上下文干净的评审者才看得见原作者看不见的东西。原作者脑子里那些”这块我当时是这么考虑的”的补充说明，在新会话里根本不存在，设计文档真正缺的那一块才会露出来。

代码评审这一道查得最细。它对照设计文档逐项核对：接口的参数和返回结构对不对得上，错误处理是否规范，有没有拼接 SQL、有没有漏鉴权、列表接口有没有分页、查询有没有 N+1 问题。能当场改的直接改掉；改不动的，比如架构层面的取舍、业务逻辑上的争议，写进报告标为待人工处理。

评审的仍然是 AI，不是人。人力不该花在”通读一遍找问题”上，那是 AI 干得动的活；人只处理它报上来、自己也拿不准的那几个点。评审遇到需要人拍板的事，pdlc 就停下来，写 blocked 交还给人。第 5 篇那次”三个配置字段没有任何后端消费方”，就是这样被拦下来的。

七环齐了，还要防假绿

链条搭齐，报告全绿，是不是就能信了？还差一层。最危险的从来不是红灯，红灯至少是诚实的。危险的是假绿：看起来一切正常，其实底下已经出了问题。

假绿有两种，都不是靠更努力就能避免的。

一是清单腐烂。 E2E 覆盖矩阵是拿”核心流程清单”去比对的，而清单靠人记得更新。新加了一条核心流程，没人往清单里补，矩阵照样全绿，它把”我们不知道”当成了”我们覆盖了”。这比没有检查更坏，因为它还附带一份绿色报告，让你安心地错下去。解决办法是每次运行都拿 PRD 强制对账：PRD 里有、清单里没有，直接判红。

二是把”不可判”当成”没问题”。 还记得 PRD 八项自检里最不起眼的那条吗，功能清单要标优先级。对账靠的正是这些 P0/P1 标记。如果某份 PRD 根本没标，提取出来就是空集，和清单一比，零漂移，报告就写”对账通过”。可事实是这整份 PRD 从来没有进入过检查范围。老 PRD 最容易出这个问题，而已经上线的主链路恰恰最不能漏。

所以规则改成：因为没有优先级标记而没参与对账的 PRD，必须单独列出来告警，对账这一项不能判通过，只能写成「⚠️ 无漂移，但另有 N 份 PRD 不可判」。这和第 3 篇那条”没有命令可跑就把格子留空、不许填通过”是同一个原则：量不到，就如实写”未测量”，不让空白冒充绿灯。

这套做法防不住什么

七环加上防假绿，也还有防不住的地方。

需求本身错了，它一样全绿。 这条链保证的是”你想做的东西被扎实地做出来了”，不保证”这个东西该做”。

它也不保证你真的配齐了。 我自己就有反例：另一个小一些的项目，单测和 E2E 都在跑，但覆盖率工具根本没配。链条缺一块，就不能说”质量有保障”。装上 pdlc 不等于自动达标，它只是把该做的事一件件列在你面前。

最后放行的还是人。 /pdlc-quality 只负责把实测数据整理成一份能核对的报告，达不达标它不下结论，要不要放行由人来定。如果写代码的一方同时也是下结论的一方，前面那些让机器说话的安排就没意义了。

这套做法换来了什么

回到开头那个差距：AI 让产出变快了，判断没有跟上。这七环做的事，说到底就是把”判断”也提速到能跟上产出。

具体到我身上，结果不是”没有 bug”，没人能保证这个。结果是我敢让它自己跑。上一篇那次无人值守，一个下午跑完三期迭代，我全程只介入了三次。靠的不是运气，是知道写错的东西会在某一环被拦下来，不用等线上用户来发现。

AI 该犯的错照样会犯，这条链做的，是让错误尽早地暴露出来，趁它还只是一个 bug、修起来还便宜的时候，而不是等它变成一场事故。

下一篇

下一篇我们换个方向，聊看得见：功能之间的依赖怎么记、改一处会波及哪儿、项目走到哪一步能不能一眼看全，以及复盘该怎么留下来。

想自己试一下：

curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global

仓库在这里：https://github.com/kanfu-panda/pdlc-skills

觉得有用的话，给个 star 是对我最大的支持 ⭐

这七环是我在自己项目上跑出来的配法，不一定适合所有项目。如果你有更精简的组合，或者觉得哪一环可以去掉，欢迎在评论区聊聊。