目录

上一篇《pdlc-skills 如何在 AI 辅助编程中保障项目质量？》讲的是质量链。这篇讲看得见的东西：AI 一个下午能推进三个功能，人要是看不清走到哪、改一处牵动谁、这一段做得怎么样，自动化就全在黑箱里跑。管这事的是三个工具：状态栏和 /pdlc-status、/pdlc-relate、/pdlc-retro，分别盯住三个时间尺度——现在、变更前、每个月。

三个工具，一个数据源

三个工具有个共同点：都只读 docs/.pdlc-state/ 下的状态文件，不解析文档正文，不猜。第 3 篇《三大工程在 pdlc-skills 怎么联动？》说过三层靠同一块记分牌联动，这三个工具读的就是它，区别只在回答的问题：状态栏和 /pdlc-status 回答”现在在哪”，impact 回答”改这个会波及谁”，retro 回答”这一段做得怎么样”。

三个工具读同一个状态目录，回答三个时间尺度的问题：状态栏随时看现在在哪，impact 在改动前查波及范围，retro 按月看趋势

状态文件写得准不准，决定它们看到的是不是真的——这点文末回来说。

现在在哪：状态栏和 /pdlc-status

先看状态栏真实的一行：

● PDLC 控制台三期 · PRD·设计·TDD·实现·[评审]·发布 · →发布 · 🤖 · ✓unit ✓lint ✓cov · ⏱9d

从左到右：功能名、六段轨道与当前位置、下一步、运行模式（🤖 自主循环，👤 手动）、三项检查结果、当前阶段停了多久。

状态栏一行的六个字段：功能名、六段轨道、下一步、运行模式、检查结果、停留时长；下方是 blocked 时的整行格式

这一行里有三个取舍值得说。

  1. 不显示”第 4 步 / 共 6 步”：bug 修复不走满六段，数字会误导，改成固定轨道、高亮当前位置。
  2. 三项检查只在自主模式下默认显示：手动模式下你自己在跑测试，显示出来是噪音；它的价值在无人值守时一眼看出循环健不健康。
  3. 卡住的时候整行换一种格式：⛔ PDLC xxx blocked: PRD 取舍需人工 · ⏱12m。循环停下来等人拍板，人得第一眼看见——这是状态栏的头号任务。

状态栏用 /pdlc-settings statusline 一条命令开启，它会追加在你已有的状态栏后面，不动原配置。/pdlc-status 是同一份数据的命令版，输出进行中、已完成、待办建议三块，如果建过关系索引，再附一棵关系树。它会核实而不只罗列：功能停在”评审完成、待发布”超过 10 天，它会去 CHANGELOG 和 git tag 确认是不是真没发；--stale 3 把各功能的停留天数列成表。

工具把问题摆到人眼前就到头了，接下来怎么办，得人来定。

改一处波及哪：关系图

功能之间谁扩展谁、谁依赖谁、谁取代谁，这些关系一共六种，四种有方向：扩展（extends）、依赖（depends_on）、取代（supersedes）、解决（resolves）；两种对称：冲突（conflicts_with）、相关（relates_to）。记录不用人手填：/pdlc-feature 分配功能 ID 时扫一遍已有功能，/pdlc-prd 扫描需求里”基于、扩展、依赖、替代”这些词，识别到的关系连原因一起写进 PRD 和状态文件。拿一个真实项目举例：它有三个迭代，二期三期都扩展一期，一期扩展最早的 MVP。

跑一次 rebuild，它扫描状态文件，建出节点和边的索引，外加一张 mermaid 图。MVP 是接入 pdlc 前就完成的，没有状态文件，它没报”悬空引用”，而是标成历史终态节点保留。

控制台项目的关系图：二期和三期扩展一期，一期扩展 MVP；对一期做 impact 分析，红圈是直接下游，绿圈是历史节点

impact 才是关系图存在的意义。对一期跑一次，输出分三层：🔴 直接影响（二期、三期），🟡 间接影响（隔一层的），🟢 历史（MVP，只作审计）。它还会给建议：一期已被两个完成评审的功能扩展，要改就该新建一个 supersedes 它的功能，而不是就地改——否则下游已完成的评审结论就作废了。

其余子命令：query 看单个功能的出边入边，orphans 找没有任何关系的功能，validate 按五条规则查悬空引用、自引用、成环、矛盾对，以及对称关系两边是否都记了。set 是唯一会写状态文件的：加一条对称关系，两端文件会同步各补一条，然后重建索引。

这段时间做得怎么样：复盘

/pdlc-retro 默认看最近 30 天，把状态文件的历史汇总成报告：交付量、各阶段自检通过率、耗时中位数、卡点案例，写进 docs/07_reviews/retro/ 下按月归档的文件。

一次真实运行的通过率：需求、设计、TDD 三个阶段 100%，实现 93.8%，评审 54.9%。口径是自检清单里判”过”的检查项占比——评审没过的那四成多，就是标出来等人拿主意的地方，平均每功能 7 处。

控制台项目复盘：五个阶段的自检通过率和耗时中位数，人工介入集中在评审阶段

这个数字恰恰是对的：前四环把机器能判的判完，判不了的全留到评审，评审”通过率”低说明前面几环干了活。要是评审也 100%，反而该怀疑它有没有认真看。

耗时中位数：需求 0.0 小时、设计 0.1、TDD 0.6、实现 0.9、评审 5.0。评审这 5 小时要打折：算的是从进入评审到完成头尾多久，夜里没人干活也算在内，不是净工时。

报告处理坏数据的方式值得说：有个功能评审完成时间比实现还早，时间戳倒挂，它没算出负数糊弄，而是剔除样本、单列一条”数据异常，建议排查落盘时序”。把时间窗换成最近 7 天重跑，窗口里没有任何活动，它四个小节全写”无数据”并说明原因。这和上一篇的假绿是同一条纪律：不可判就写不可判，不填成绿。

边界：它们只显示记录了的东西

三个工具都只读状态文件，不会去核对代码。状态文件是 AI 在每个阶段收尾时写的，写偏了这三个工具不会报错，只是悄悄少显示一项、少算一个阶段。示例项目里就有两处：三项检查的键名，旧功能写成 tests_green，新功能才是规范的 tests_pass，状态栏只认规范那套，旧功能的检查结果就不显示；历史记录没有开始时间，耗时只能拿相邻的完成时间相减。关系也一样，只在立项时自动记一次，后面需求变了，得自己 set。

所以这三个工具的前提，是把状态文件当数据来维护：字段、时间戳、关系都按规范写。

看得见之后

回到开头的问题：AI 一个下午推进三个功能，人怎么跟得上。这三个工具各答一个问题，现在走到哪、改一处牵动谁、这一段做得怎么样，答案都从同一份状态文件里读出来，不用翻文档、不用猜。它们不替人做决定，停住的功能要不要推、基线该不该动、评审留下的人工项怎么排，还是人来定，只是做决定的时候，手里有了数据。看到状态栏少了一项、复盘少了一个阶段，先怀疑记录，再怀疑工具。

下一篇

三个工具讲完，讲机制的部分就结束了。下一篇回到一个真实项目，从第一条命令到最后一次发布走一遍，看这套东西装上后到底怎么用起来。

想自己试一下：

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

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

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

你项目里最久没人动的功能，停了几天了？欢迎评论区聊聊。