目录

三个概念分清楚之后，真正该问的是下一个问题：有没有一个真东西，是这三层同时长齐的？这一篇就拿我自己在做的 pdlc-skills 来对一遍。先说结论——它跟三大工程契合，是个巧合。但巧合背后有原因，那个原因才是这篇想说的。

上一篇我们把三个容易混在一起的词分开了：

  • 提示词工程管的是这一次怎么跟模型说话；
  • Loop 工程管的是一件事反复做到什么条件才停；
  • Graph 工程管的是整条路上哪些步骤不许跳。

它们不在同一层，不是三选一，而是可以叠起来的三层。

讲完之后，一个很自然的问题就冒出来了：这三层听着都有道理，可有没有一个真东西，是三层同时长齐的？

这一篇就拿一个来对——我自己在做的 pdlc-skills。

pdlc-skills 是什么？

它是一个 Claude Code 插件，干的事可以用一句话说完：把 AI 写代码从”聊出来的”变成”落在磁盘上的”。

装上之后，你会多出 38 条斜杠命令，一条命令对应流程里的一个阶段。最常用的是 /pdlc-feature——开一个新功能就用它起手，然后 AI 会顺着 PRD → 设计 → TDD → 实现 → 评审 → 发布这条线往下走，每到一个阶段停下来交接一次。

它跟”让 AI 帮我写个功能”最大的区别有三条：

  • 产物必须落盘。PRD、设计、评审记录都是 docs/ 下的真文件，不是聊天记录里的一段话。
  • 每个功能有一份状态。走到哪一步、上一步过没过，都记在磁盘上。换个会话接着干，它知道自己在哪儿。
  • 测试必须先红。没有失败的测试，不许进实现——这是硬门，不是建议。

MIT 开源。它在 Claude Code 上功能最全，同一套方法论也能通过适配器在别的 AI 编程工具上跑。

它的来路其实很普通

这三层不是我设计的，我做它的时候压根没听过”Loop 工程”“Graph 工程”这些词。

它就是照着软件工程里那套现成的产品开发生命周期做的。需求、设计、测试、实现、评审、发布——这套流程在行业里躺了几十年，没有任何新东西。我做的只是把它翻译给 AI：每个阶段做什么、产出什么、什么条件才算过，写成一条条命令，让 AI 顺着流程走，而不是想到哪写到哪。

配套定了一条规矩：每个阶段都必须往磁盘上写东西。

  • PRD 落到 docs/01_requirements/
  • 设计落到 docs/02_design/
  • 评审记录落到 docs/07_reviews/
  • 每个功能还有一份自己的状态文件

都是普通文本，随时能打开看，也能 git diff 出这一轮 AI 到底动了什么。

做完之后，这几个新词流行起来了。我拿它们回头对了一遍，发现处处对得上——不是我照着做的，是它自己就长成了那样。

那就按提示词、Loop、Graph 的顺序，一层一层对过去。

🔵 提示词层：对上的是”规范只有一份”

流程里对应的是什么。 软件工程有条老规矩：规范文档只能有一份，不能这里一套那里一套。放到 pdlc 上，就是那些所有命令都得守的规则——产物必须落盘、交接前必须自检、修复只做一次——不能在每个命令里各写一遍。

具体怎么做的。 把公共规则抽成片段，在构建期展开进各个 skill。现在是 13 个片段，编译进 38 个 skill 里的 36 个（剩下两个不含的是 pdlc-loop-next 和 pdlc-status，它们太轻，没有可共享的规则）。那六条不变量——文件必须落盘、阶段必须落章（每完成一段就往历史里追加一条）、测试必须先红、自检必须执行、修复只做一次、状态必须推进（current_stage 得真的变，防止外层循环拿着滞后状态空转）——就写在其中一个片段里。改一处，全体生效。

13 个共享片段在构建期展开进 36 个 skill，改一处规则全体生效

对上了哪一层。 提示词工程管的是”这一次给模型看什么”。这里做的事其实没变，只是拿代码那套办法管它：抽公共、编译期展开、单一真源。

新词叫提示词工程，老规矩叫单一真源。两个说的是同一件事——这就是第一处巧合。

🟢 Loop 层：对上的是 TDD 的红灯门

流程里对应的是什么。 TDD 是软件工程里的老东西了，规矩就一条：先写会失败的测试，再写实现，直到测试变绿。pdlc 把它照搬了过来——实现之前必须先有红灯测试。

它顺手带来了什么。 测试写在实现之前，意味着”做完了没有”这件事有了一个跟模型无关的答案：跑一遍，退出码是 0 就是过了，非 0 就是没过。

这个答案值钱的地方在于它不经过模型。让写代码的模型给自己的代码打分，它会系统性地往好里说——不是它想骗你，是它真觉得写得挺好。所以在 pdlc 里，模型的自检结果是单独记的，只当参考，永远不作为该不该停的依据。

于是这一段就能交给循环了：tdd → implement → review 自己跑，跑到评审通过为止。前面的 PRD 和设计交不了——这个功能要不要做、拆成哪几个模块、边界划在哪，是判断题，没有任何一条命令能给出退出码。判断题留给人，这条线划得很清楚。

流程里哪一段能交给循环、哪一段必须留人，判据写在旁边

对上了哪一层。 Loop 工程有句话可以当公理：一个循环 = 一个任务 + 一次校验，没有校验的任务只是许愿。而 TDD 给的正是校验。

我做 TDD 是因为软件工程要求先测后写，不是为了给循环准备靠尺。但那把靠尺就那么现成地放在那儿了——这是第二处巧合。

护栏、上限、预算这些怎么定，我留到第 5 篇专门讲。

🟣 Graph 层：对上的是阶段划分和评审闸门

流程里对应的是什么。 生命周期这个词本身就带着顺序：需求在设计前面，设计在实现前面，实现完了要评审，评审过了才发布。软件工程里这套顺序不是建议，是纪律——跳步的代价，行业已经交过几十年学费了。

具体怎么做的。 每个阶段结束时把状态写进磁盘，下一个阶段先读状态，不满足前置条件就不许进。不许跳过测试直接实现，不许没评审就发布。

除了纵向的顺序，还有横向的一层：功能与功能之间的关系。/pdlc-relate 把这些关系显式记下来，六种有向边——扩展、依赖、取代、解决、冲突、相关。然后 impact <功能ID> 一条命令查改动的影响半径：🔴 直接依赖它的、🟡 隔了一层的、🟢 已经收尾不用管的。

纵向是一条带闸门的线性管道，横向才是真正的有向图

这里得说句实话。 纵向那条严格来说不是图，是一条线性管道加几道闸门。它没有条件分支，没有并行节点，也不能从任意一点回滚——图该有的东西它基本没有。真正符合”图”的是横向那张依赖关系图：有方向、能遍历、能查出循环依赖、能检测指向不存在功能的悬空引用。

对上了哪一层。 那纵向凭什么算 Graph 层？因为 Graph 层的本质不是”画成图”，是负向约束——宣布哪条路不许走。上一篇那个说法可以再搬一次：轨道不规划旅程，它只是让某些方向根本走不了。

阶段闸门约束的是顺序，依赖图约束的是影响范围，两者做的是同一件事。而”按阶段推进、关键节点评审”这条纪律，软件工程早就写在流程里了——这是第三处巧合。

六种有向边构成关系图，impact 按距离标出影响半径

三次巧合就不是巧合了

一次对上可以说是碰巧，三次都对上，那就该问问为什么了。

我的答案是：这两套东西本来就在解决同一批问题。

三大工程范式是这两年从 AI Agent 实践里总结出来的新词。而软件工程那套流程，是几十年里被真实项目反复教育出来的。人和 AI 干工程活时会犯的错，其实高度重合——想到哪写到哪、规范各写一套、说做完了但没验、改了这里不知道会炸哪里。老流程为治这些毛病立的规矩，翻译到 AI 身上依然有效。

所以新词描述的那些约束，老流程早就用另一套语言写过一遍：

三大工程的说法 软件工程里早有的规矩
提示词工程要统一上下文 规范只能有一份，别到处抄
Loop 工程要有客观校验 先写测试再写实现
Graph 工程要做负向约束 按阶段推进，关键节点评审

这才是”天然契合”的意思：不是我把三层搭进去了，是这套老流程本来就长着这三层，只不过以前没人用这三个词叫它。

还有一处，是老流程里没有、但落地时自己冒出来的：三层最后共用了同一份东西——磁盘上的状态。

图靠它判断走到哪一步了， 循环靠它判断这一轮有没有推进， 提示词靠它拿到这一次该看的上下文。

三层共用磁盘上同一份状态文件

这也给了一把现成的尺子：判断一个工具的三层是不是真结合，看它们共不共用一份状态。 共用才叫结合；各管各的，那只是三个机制装在了同一个仓库里。

下一篇：它们各自什么时候起作用？

如果这篇只留一句话，我希望是这句：想让 AI 干工程活，与其发明新框架，不如先把已有的工程流程用起来。 那套流程不新，但它治的毛病，AI 一样会犯。

知道了三层各自落在哪，下一个问题是：在一次真实的功能开发里，它们各自什么时候起作用？ 下一篇跟着一个功能从头走到尾，把三层的时间线标出来，也说清楚它们之间是怎么交接的。

想自己试一下：

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

项目主页：kanfu-panda.github.io/pdlc ｜ 源码：github.com/kanfu-panda/pdlc-skills

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

如果这篇让你对”三层怎么落地”有了具体的印象，点个赞或者加个关注；要是你身边也有人在琢磨怎么让 AI 按流程干活，转给他。