如何让 pdlc-skills 在项目里跑起来？
目录
前三篇都是图纸：三层各自是什么、落在哪、怎么联动。这一篇换个方向——把图纸落到你自己的项目上。读完你应该能装上它、知道该从哪条命令起手、跑通第一个功能。中间有一步最容易被跳过，我会把它单独拎出来说，因为跳过它，前一篇讲的那套东西会整个落空。
前三篇把理论部分讲得差不多了，下面来看 pdlc-skills 在真实项目里怎么运转起来。
有很多人会有疑问，是先把测试补齐吗？文档要不要先写全？一个跑了两三年、代码堆了一堆、谁都不太敢乱动的老项目，接进来是不是第一天就得先还技术债？
先把答案给你：都不用，装上只要一行命令，一分钟的事。
真正会卡住你的是另一件事——装完之后那个”然后呢”。我自己接入第一个项目时，盯着一屏 /pdlc- 开头的命令，愣了半天不知道该敲哪个。这一篇就是来回答那个”然后呢”的：你该从哪条命令起手，中间哪一步绝对不能跳。
装上：一行命令，两个落点
# 全局：这台机器上所有项目都能用
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global
# 项目级：只在这一个仓库里生效
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --project /path/to/my-project
前三篇给的一直是全局那条，因为它最短、最不容易出错。这里说说什么时候该用项目级。
两个落点的区别只有一个：装进 ~/.claude/plugins/pdlc/ 还是 <项目>/.claude/plugins/pdlc/。但带来的影响是实打实的——项目级安装让版本跟着仓库走。团队里其他人 clone 下来，拿到的是和你同一个版本；你手上同时开着好几个项目时，也不会因为一次全局升级把所有项目一起动了。
一个人、一台机器、项目不多，那就全局，别折腾。
装完确认一下真的生效了，两步：
ls ~/.claude/plugins/pdlc/ # 全局装的看这里
ls <项目>/.claude/plugins/pdlc/ # 项目级装的看这里
能看到 skills/ references/ VERSION 这些就对了。然后在 Claude Code 里敲 /pdlc-，下拉框里应该列出 38 个命令。列出来了，就装好了。
你是哪种起点？
38 个命令铺开确实唬人，但第一次只需要认三个。挑哪个，取决于你手上是什么：
| 你的起点 | 第一条命令 |
|---|---|
| 全新项目，代码还没写 | /pdlc-bootstrap |
| 已有项目，代码一大堆 | /pdlc-adopt scan |
| 已经接入了，日常开发 | /pdlc-feature |
全新项目用 /pdlc-bootstrap：给它一句话描述，它做技术栈选型、生成目录骨架和文档草稿。适合”我想做个 X”还停留在念头阶段的时候。
已有项目是大多数人的情况，也是我最想让你注意的一条：第一条命令是 /pdlc-adopt scan，而 scan 全程只读——扫描你的技术栈、服务结构、数据库、已有测试，输出一份接入报告和健康检查结果，一个字节都不改。
我觉得这个设计比功能本身更值得说。让 AI 碰一个跑着的老项目，谁都会犹豫。所以它把”看”和”动”拆成了两条命令：先 scan 出报告，你看完觉得靠谱，再 /pdlc-adopt init 生成基线文档。试探的成本降到了零。
别跳过这一步：先把”什么叫过”定下来
这是全篇最重要的一段。
上一篇讲过状态文件里那两个格子：第一个格子只准填真跑命令得到的退出码，模型自评被单独放在第二个格子里，永不参与判停。
那就有个问题了——那些命令是从哪来的？
答案是 /pdlc-test-setup。它做四件事：探测技术栈、逐条验证命令真能跑、写进 docs/00_standards/test-commands.yml、再把测试目录和本地钩子搭起来。
仓库里对这一步的定位写得很直白：整套东西的命门是”checks 只认命令退出码，绝不用模型自评”，但在此之前没有任何东西帮你把这个文件立起来，没有它，整条客观化链路就是空的。
它有一条不可协商的纪律：写进这个文件的每条命令，必须先被真跑过一次、亲眼看到退出码。猜出来的一律不写。理由是那句我觉得最值得注意的话——
一条”看起来对但跑不了”的命令，比留空更坏。
留空，下游知道这个阶段没东西可判，会老老实实空着；而一条跑不通的假命令，会让每个阶段都拿到假的 checks，报告还是绿的。这条道理反过来还有个镜像：最危险的”自动修复”，是把已经立起来、但坏掉了的检查悄悄置空——闸门当场就松了，你还看不出来。
所以跳过这一步会发生什么？没有命令可跑 → 第一个格子按规矩必须留空 → 判停无据可依 → 你以为的”客观校验”，实际上一直是模型在自我感觉良好。上一篇那套设计的地基，就在这一步。
顺带一提，这个文件会过期——脚本改名、工具换代、子项目增删都会让它失真。不用你盯着，下游阶段遇到”命令跑不了”会主动提示你，看到提示再 /pdlc-test-setup --refresh 就行。
跑第一个功能
地基有了，正式开工只需要一句话：
/pdlc-feature 给登录加手机号验证
然后它顺着 PRD → 设计 → TDD → 实现 → 评审往下走，每到一个阶段停一次、交接一次。修 bug 是同一个用法，换成 /pdlc-fix；想看当前进展，/pdlc-status。
日常你就用这三个。 剩下 35 个是需要精细控制时才往下钻的——想单独重跑设计阶段、想只做一次代码评审、想加一份数据库设计，那时候再去翻就行。
磁盘上多出来的东西，哪些要进 git
跑过一轮之后，docs/ 下会多出一批目录：需求、设计、测试、部署、评审各有其位，还有一个 docs/.pdlc-state/，每个功能一份 JSON。
前面那些是文档，进不进 git 你自己决定。但有一个必须进：
docs/.pdlc-state/ 要提交进 git，别加进 .gitignore。
它看着像缓存——一个点开头的目录、一堆机器读的 JSON，很容易让人顺手忽略掉。但它不是缓存，是交接物。换个会话、换台机器、换个人接手，能说清”这个功能走到哪一步、上一步过没过”的，只有它。不进 git，就等于每次重开会话都失忆一次；团队协作时，别人根本看不到你这边的进度。
仓库里给它的定性是”项目交付审计记录”。按审计记录对待，就不会想着忽略它了。
老项目接入的两条纪律
如果你是从老项目接进来的，有两条纪律值得提前知道，因为它们决定了这件事现不现实：
第一，只生文档，不动代码。 接入过程中一行业务代码都不改，只逆向生成基线文档。
第二，增量接入。 旧代码统一标成”已接入基线”，只有新功能才走完整流程。不要求你先把历史债还清。
第二条是关键。我见过太多流程工具死在第一天：一接入就报出几百个存量不合规，人一看这个数字就放弃了。把存量圈起来放过，只管新增，这条流程才有活到第二天的可能。
什么时候不该用它
也说说边界。一次性脚本、跑完就删的 demo、纯文档仓库——这些别用，流程的成本收不回来。它是给”要活很久、要被人接手、要对质量负责”的项目准备的。
判断标准很简单：这个项目三个月后还有人会打开吗？ 会，就值得；不会，别折腾。
照着走一遍
把上面这些压成一张单子，你可以直接照做：
- 装：
curl … | bash -s -- --global（多项目或团队协作就换--project <路径>） - 验：
ls ~/.claude/plugins/pdlc/，再在 Claude Code 里敲/pdlc-看有没有列出 38 个命令 - 认起点：新项目
/pdlc-bootstrap；老项目/pdlc-adopt scan看报告，满意再/pdlc-adopt init - 立地基：
/pdlc-test-setup——这一步别跳，它决定后面所有”过没过”是真是假 - 开工：
/pdlc-feature 你的一句话需求，然后/pdlc-status随时看走到哪了 - 提交：把
docs/.pdlc-state/一起 commit 进去
第 4 步是唯一一个”看起来可以先放放、实际上放不得”的。其余按顺序照走就行。
下一篇：能不能让它自己往下跑？
到这儿，装上、起手、立地基、跑通第一个功能，一条线走完了。如果这篇只留一句话给你带走，我希望是这句：先把”什么叫过”定下来，再开始跑——顺序反了，后面所有的自动化都是空转。
下一篇是这个系列的重点篇：装好了、也跑起来了，能不能让它自己一轮一轮往下跑，不用你守着？ 会讲透那条收敛循环的机制、契约，和四条不可协商的护栏——也包括我自己踩过的那次：嘴上约束治不住 Token 消耗，最后是一条硬预算把它接住的。
想自己试一下：
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global
仓库在这里：https://github.com/kanfu-panda/pdlc-skills
觉得有用的话，给个 star 是对我最大的支持 ⭐
这一篇是我按自己接入项目的真实顺序写的，如果有疑问，欢迎留言讨论。如果你照着走通了，回来告诉我一声；卡在哪儿了也告诉我，我补进下一版。
评论