背景：和 AI 配对编程半年的反思
过去半年我大量使用 各种AI编程工具（vscode\cursor\winsurf\claudecode等等） 做开发，从写 demo 到生产代码都有覆盖。 模型本身能力没什么可挑剔的——它的代码质量在很多场景下已经达到甚至高级工程师水平。尤其是claude code + opus 4.7模型
但有一件事让我反复挫败：AI 完成一个 feature 的”过程”，几乎全部丢失在聊天里。
具体表现：
- PRD 只在对话记录中存在，docs/ 目录空白
- 测试通常在实现之后才补，不是 TDD
- 跨会话状态丢失，新 session 无法回答”feature X 现在在哪一步”
- Lint / 类型检查循环修复消耗大量 token 仍不收敛
这些不是 Claude 的 bug，是 LLM 作为无状态执行者的本质特性。
我意识到，光靠”在 CLAUDE.md 里写规则让它遵守”是不够的—— 软约定对人类工程师有用，对 LLM 几乎无效，因为它没有跨 prompt 的工作记忆。
我需要的是工程化的硬约束：约束写在 workflow 层，模型想跳过也跳不过。
解决方案：PDLC（Product Development Life Cycle）
我设计并开源了一个 Claude Code 插件，名为 PDLC。
它提供 31 个 slash 命令，分成 3 层架构：
入口层（3 个，one-shot 驱动整条链）
| 命令 | 作用 |
|---|---|
| /pdlc-feature | 端到端做新功能（PRD → 设计 → TDD → 实现 → review → 发布） |
| /pdlc-fix | 端到端修 bug |
| /pdlc-status | 查看项目所有 feature 当前所处阶段 |
阶段层（11 个，精细控制单步）
/pdlc-prd、/pdlc-design、/pdlc-tdd、/pdlc-implement、/pdlc-review、 /pdlc-e2e、/pdlc-refactor、/pdlc-ship、/pdlc-deploy、/pdlc-retro、/pdlc-task
工具层（17 个，专项场景）
涵盖 UI 设计、数据库迁移、性能优化、安全审计、i18n、code generation 等。
核心：5 条工程铁律
PDLC 的真正价值不在命令多，在每个会产生工件的命令都强制执行 5 条不变量。
铁律 1：产物落盘
每个阶段产生的文档必须以文件形式存在于
docs/目录下。
实现细节：每个命令的尾部都有一个”工件持久化”步骤，验证文件实际写入磁盘。 没写入磁盘，命令报错。
价值：所有 AI 产出可以 git diff、可以 review、可以传递给团队。
铁律 2：状态机持久化
每个 feature 维护一个
docs/.pdlc-state/<feature-id>.json，记录当前阶段、已完成 artifact、下一步建议。
实现细节：每个阶段命令在退出前更新状态机文件，包含 timestamp、artifact 列表、next_step 字段。
价值：跨 session 状态不丢失。/pdlc-status 是一个全局视图，可以用一行命令了解项目所有 feature 当前位置。
铁律 3：测试先行红光门（⭐ 最关键）
/pdlc-implement必须在/pdlc-tdd已产出失败测试的前提下才能执行。
实现细节：
/pdlc-implement启动时读取该 feature 的测试 artifact 路径- 若文件不存在 → refuse
- 若文件存在但运行后 pass（不是 fail）→ refuse
- 仅当存在且当前 fail 时 → 进入实现阶段
价值：杜绝”先写代码后补测试”的伪 TDD。 这条规则在工程实践中是 PDLC 与”在 prompt 里说请先 TDD”最大的区别。
铁律 4：阶段边界自审
每个阶段在标记完成、进入下一阶段前，运行一次 self-check。
实现细节：每个命令的最后一步是一个 audit prompt，对照该阶段的 deliverable checklist 检查 artifact 完整性。 未通过 → 阶段不结束。
价值：drift 在阶段边界被拦截，不会累积到 review 阶段才发现整个 PRD 漏了关键场景。
铁律 5：一次性自动修复
自动 fix-check 循环最多执行 1 次。失败则降级给人类处理。
实现细节：每个 audit 失败后允许 1 次 auto-repair，仍失败则在状态机中标记 human_review_required: true。
价值：避免 LLM 在错误方向上反复”修复”消耗 token，强制升级到人类介入。
工程上的几个权衡
为什么只支持 Claude Code？
依赖了 Claude Code 的 slash command + skills 两个原生抽象。Cursor / Cline / Codex CLI 没有等价物。 Bash + Markdown 实现，理论上可移植，但没必要先做。
为什么是 31 个命令而不是 1 个？
入口层（/pdlc-feature）已经覆盖 80% 场景。 阶段层和工具层是给”需要精细控制的工程师”准备的。 你不必学完 31 个，从 3 个入口开始就够。
是否会引入工程开销？
会。对一次性脚本 / 3 行 CSS 修改是过度工程。 这种用 /pdlc-fix 较短链路，或直接走原生 Claude。 PDLC 的目标场景是”你以后想 git diff、想给别人接手”的功能。
安装与使用
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global
在 Claude Code 中调用：
/pdlc-feature 加一个手机号验证登录
具体会自动 ID 分配、链式执行、artifact 落盘、状态机更新。
总结
PDLC 的核心观点：
在 LLM 时代，工程纪律必须从”软约定”升级为”硬约束”。
软约定（如 prompt 里写”请先写测试”）依赖模型的”自觉”， 这种自觉在 LLM 上不可靠，因为它没有跨 prompt 的工作记忆。
硬约束（如 /pdlc-implement 在没有失败测试时直接 refuse）依赖 workflow 工具的强制力， 这种强制力对 LLM 才真正有效。
PDLC 是这个思路的一次实践。 不一定是最优解，但它的确可能帮助提升10x以上的研发效率。欢迎在 issues 中讨论。
