如何把 pdlc-skills 用到真实项目上？

前七篇讲的是机制。这一篇回到一个真实项目，回答六个装上之后才会遇到的问题：功能怎么拆、人和 AI 怎么分工、循环怎么跑起来、花了多久、产出了多少、质量靠什么保住。项目是我自己在用的一个控制台项目，三个功能交给 pdlc 自带的循环引擎并行收敛，88 分钟全部到评审终态，补完质量闸门后发布、部署到两台机器。机器跑出来的数字都来自事件流和 git，人花的时间是估的，文里会标出来。

起点

这个项目是 8 月下旬用 /pdlc-bootstrap 起的骨架，五天里从最小可用版本一路做到控制台第三期，之后放了三周。再打开的时候先补了两样东西：用 /pdlc-test-setup 把单测、覆盖率、lint 三条命令写进 test-commands.yml，三条都真跑一遍才算数；把几份旧的状态文件按新格式迁一遍。没有这两步，后面每一步的”检查通过”都没有依据。前一天刚接上 E2E，45 条核心流每条都有测试跑过。这轮的起点就是 421 个单测、52 个 E2E 用例，覆盖率 89.6%。

功能怎么拆

这轮做三件事：让审核方可以在另一台机器上、让通知按任务来源过滤、给基准测试加两个审核开关。下面分别叫它们跨节点互审、通知来源过滤、基准审核开关。三件都不大，正好拿来试循环。拆分按三条原则走。

第一条，按代码依赖切成链或独立。基准审核开关要用跨节点互审的远端投递和结论回流，这两件是一条链，后一个等前一个收敛再起跑；通知来源过滤独立，立刻起跑。

第二条，一个功能多大合适，以三步能跑完为准，三步就是 TDD、实现、评审各一步。这轮三个功能的改动量在 800 到 1500 行之间。

第三条，并行的功能不碰同一个文件。这一条这轮没守住，三个功能都要改回执聚合那个模块，代价是后面合分支时要一处处解冲突，多花了十分钟。

PRD 用 /pdlc-prd --autonomous 生成，输入是几段需求原文，三份加起来 17 分钟，依赖关系是命令自己从原文里写出来的。每份末尾都留着几条”待确认问题”，三份共十条，主控逐条拍板写回：回流查询失败该记成什么事件、指定的那台机器没登记在配置里该报什么错。这类事不定下来，三个进程会各按各的理解写。

人和 AI 怎么分工

四个角色：我、一个长期开着的主控会话、用完就退的子进程、一个外层脚本。主控会话也是 AI，但它不写功能代码，只做协调和复核。

做哪几件事、并行怎么排，由我定。需求先由主控起草原文，再由命令生成 PRD，待确认项由主控拍板。

设计阶段每个功能起一个新进程跑 /pdlc-design --autonomous，三份并行 12 分多钟，主控审了 15 分钟，退回一处重写：基准审核开关的设计里，跨节点那一段写的是”依赖还没做好，收到请求先拒掉、留条记录”，可它本来就排在跨节点互审之后的分支上，实现时该真去调远端投递。

TDD、实现、评审三段交给循环，没人看着，模型全程用 sonnet，每个功能整轮跑下来有预算上限。每个功能收敛后，主控读 diff 对设计、亲自跑三项检查，然后开 PR；发布、部署和验收的命令也由它跑。我做的是合并 PR、看质量报告和复盘、决定放不放行。一定要人的地方就两处：定做什么，和发布放不放行。

循环怎么跑起来

pdlc 自带的循环引擎是 /pdlc-loop-run：从当前阶段出发，TDD、实现、评审每一段派给一个新的子代理，每段跑完读一次状态文件，照一张固定的对照表决定下一步，到 review_done 就停，绝不自己发布。这里是两层：外面每个功能一个进程，进程里面 loop-run 每跑一段再派一个子代理。护栏是步数上限 4、一步失败就停、状态没推进就停。

它一次只管一个功能。多个功能并行，外面还得再包一层调度，这次是一个三百多行的 bash 脚本。它读每个功能状态文件里的 depends_on 排先后，没有前置的立刻起跑，有前置的等前置收敛后从它的分支上分出来；每个功能给一个 git worktree，各跑各的；每个功能起一个进程：

claude -p --model sonnet --max-budget-usd 20 --permission-mode acceptEdits \
  "/pdlc-loop-run $fid --max-steps 4 --autonomous"

进程退出后读状态文件、提交产物。脚本还每 15 秒看一眼状态文件，把阶段切换的真实时刻记下来，因为状态文件里模型自己写的时间戳不可信。

起跑时跨节点互审和通知来源过滤同时起。通知来源过滤最快，三步 30 分钟收敛；跨节点互审用了 51 分钟，它一收敛，脚本隔了 13 秒就从它的分支上把基准审核开关拉起来，又跑了 37 分钟。三个功能 88 分钟全部到 review_done，每个都只用了 3 步，没撞上限流，也没有哪一步把预算跑光，中途一次都没停。

过程里有一件值得记的事。三个功能写进状态文件的阶段名并不一致：收敛时两个写 review_done、一个写 review；其中一个功能的 TDD 步直接写成了 tdd_done。按字面理解，_done 结尾就是做完了，循环本可能在 TDD 之后就当作收敛停下来。loop-run 没被这个写法骗到，照常起了实现步。但这说明判断”有没有往前走”不能只看阶段名，还得看下一步字段有没有变。

花了多久，产出了多少

每个功能的步数、机器时间和改动行数如下，测试后面括号里是新增的用例数。

三个功能合计新增 3351 行，其中测试 1770 行，比功能代码本身还多两倍。PRD 和设计另算，1833 行。单测从 421 个到 516 个，E2E 用例从 52 个到 65 个，覆盖率从 89.6% 到 90.3%。

整条线是这么走下来的：起草需求、生成 PRD、审完设计，三个功能起跑，88 分钟后全部收敛，合分支，跑质量报告，红灯；补齐之后报告达标，发布 v0.3.0，两台机器部署，再做真机验收。人花的时间是估的，加起来两个半小时上下，都花在写需求、审设计、每个功能收敛后复核、集成和补闸门上。

质量靠什么保住

没人看着的时候，质量靠四层。

第一层是每一步的客观检查。每一步要跑哪几条命令，写在 test-commands.yml 里，只认退出码，不认模型自己说”我检查过了”。TDD 那步验的是新写的测试真的红了，实现和评审两步验单测、覆盖率、lint 全过，其中两个功能还带上了 E2E。覆盖率 85% 的门槛直接写在命令参数里，pre-commit 跑 lint，pre-push 跑单测，取的都是这份文件里的命令。这一轮三个功能各三步，九步记下来的检查项没有一条是红的。

第二层是收敛后的复核。主控在每个功能收敛后读 diff 对设计、亲自跑三项检查再开 PR。这轮三个功能的 diff 都和设计一致，唯一一次人工修正发生在更早的设计评审，就是上面说的那处。集成时三个文件里有四处冲突，多半是两边各加了个字段，留下双方就行。合完再跑一遍全套：516 个单测、覆盖率 90.3%、56 个 E2E 用例全过。

第三层是发布前的质量报告。/pdlc-quality 看四项：覆盖率、E2E 核心流覆盖、lint、PRD 与核心流清单的对账。第一次报告前三项全绿，对账这一项拦下来了：三个新功能的 19 条验收条目，一条都没进核心流清单。报告里写得很直白，说 45 条全绿不代表这三个新功能过了闸门，只代表旧的那 45 条还健康。其实循环里的子代理给每个功能都写了 E2E，只是没往清单里登记。

处理办法不是签字放行，是补上：19 条进清单，已有的 4 条测试直接引用，另写 9 条 E2E 覆盖剩下的。第二次报告四项达标，64 条核心流、65 个用例全部真跑通过。

第四层是发布后的真机验收。两台机器都部署上，真派几个任务跑一遍。通知按来源过滤直接在生产控制台上配好，验收和基准这两个来源进了静音名单，之后跑的任务都带着来源标记。这套过滤的行为在 E2E 里验过：来源命中就不推完成通知，失败的照推。

跨节点互审也真跑了一遍：审核任务投到另一台机器，那边执行、归档，本机把结论拉回来，控制台上能看到是哪台机器审的。结论是失败，因为那台机器上的 claude 命令没登录过。这一层抓到的是环境问题，倒是把”审核失败了结论怎么传回来”这条路真跑通了一遍。验收还发现收结果那一步没加互斥，两个进程同时跑会把同一份结果处理两次。

边界：循环在哪里会失灵

循环快的地方，都是有客观检查的地方；慢下来和出错的地方，都是记录不准的地方。

最明显的是时间。状态文件里的时间戳是模型自己写上去的，复盘工具照它算，得出 TDD 阶段的中位数是 2.1 小时；而外层脚本轮询记下来的真实耗时，三个 TDD 步分别是 10、21、13 分钟。前面说的阶段名写法不一致，也是同一类问题。

所以外层的判断别建立在模型写的字段上：耗时以事件流和 git 提交时间为准，进度看下一步字段或者进程退出时打的完成标记。这也是这一轮给 pdlc-skills 提的两条改进：阶段名要统一，时间戳该由命令来取。

系列到这里

八篇从三层范式讲起，讲了怎么装起来、怎么跑循环、怎么守质量、怎么让过程看得见，最后在一个真实项目上从头跑到尾。说的是同一件事：把靠不住的判断挪到有客观检查的地方，人只守两头，定做什么和放不放行。

想自己试一下：

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

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

觉得有用，给个 star 就是最大的支持 ⭐

八篇看到这里，谢谢。你要是也在一个真实项目上跑过一次，哪一段最花人的时间，评论区聊聊。