用 PDLC 工作了几个月之后，我在一个项目的 docs/ 目录里看到了这些文件：
bash
docs/
├── architecture-2025-10-03.md
├── architecture-2025-11-14.md
├── architecture-2025-12-01.md
├── architecture-2026-01-08.md
└── architecture-2026-02-19.md五份架构文档，每份都带日期。我不知道哪份是现在的架构。
这不是用户操作失误，是 PDLC v1.0 的设计失误。v1.0 把所有阶段产物都当成 append-only 的历史记录来处理。这个逻辑用在 PRD 上是对的，用在架构总览上就产生了这堆垃圾。
v1.1 修了两个这样的设计错误。
错误一：没有区分两种完全不同的产物
做这件事之前，我先想清楚了一个分类：产物在时间维度上是什么形状？
有一类产物，记录的是"发生了什么"。PRD、设计决策、会议纪要------每份都是历史证据，不能篡改，只能追加。你不会去改一份三个月前的 PRD 让它变成"最新的"，那会毁掉决策链。这类产物叫 ledger 型（账本）。
另一类产物，记录的是"现在是什么状态"。架构总览、团队编码规范、API 契约------永远只有一份"现在有效的版本"。你维护它的方式是就地更新，而不是另存一份带日期的副本。这类产物叫 surface 型（当前状态面）。
v1.0 没有这个区分，AI 默认给所有产物追加日期戳。于是 /pdlc-arch 每次运行都生成 architecture-YYYY-MM-DD.md，三个月后变成上面那五份文件的局面。
更糟的是规范文档。团队有一份 coding-style.md，被改了一次之后变成了 coding-style-v2.md。然后是 coding-style-v3.md。没人知道该 follow 哪份，干脆都不看。
v1.1 的修法很直接：让 AI 在生成产物之前先判断类型。ledger 型继续 append-only，加日期戳、不能就地改；surface 型则强制就地维护一个固定路径的文件------/pdlc-arch 只维护 docs/ARCHITECTURE.md 这一份，每次更新就地改，遗留的带日期文件自动归档到 docs/archive/。
新指令：/pdlc-standard
规范文档是 surface 型产物里最典型的一类，所以 v1.1 为它单独加了一个指令。
/pdlc-standard 管理 docs/00_standards/ 目录下的规范文档。它做几件事：
add ：新建一份规范，命名强制用语义路径（coding/style、api/versioning），禁止带版本号或日期。 edit ：就地修改现有规范，自动记录修改时间，但文件名不变。 archive ：如果一份规范彻底废弃，可以归档，但已有引用不会断。 index：输出当前所有有效规范的索引，用于 onboarding 或 review。
最关键的一条约束在提示词里是硬写的：如果 AI 在生成 coding-style-v2.md 这样带版本号的规范文件，必须中止并提示用户用 edit 子命令替代。
这条约束从根上杜绝了版本号蔓延。
错误二：feature 之间互不相识
v1.0 的状态机管理每个 feature 是一个独立的闭环：PRD → 设计 → TDD → 实现 → 评审 → 发布。这个纵向的流程设计是对的。
但现实里 feature 从来不是孤立的。
我在 aitm 项目里遇到了典型场景：feature/安全层 被 feature/工具调用 依赖。改安全层的黑名单规则，实际上会影响工具调用的确认逻辑。但 PDLC 的状态机只看单个 feature 的进度，没有任何地方告诉我这两个 feature 之间有关系。
结果是每次改安全层，我都要靠记忆去想"这会不会影响工具调用那边"------这是把本该系统记住的事情放进了人脑，不合理。
新指令：/pdlc-relate
v1.1 加了 /pdlc-relate，专门管理 feature 之间的关系。
关系类型有六种：
| 类型 | 含义 |
|---|---|
extends |
这个 feature 是另一个的扩展 |
depends_on |
这个 feature 依赖另一个的实现 |
supersedes |
这个 feature 替代了另一个（另一个应该归档） |
resolves |
这个 feature 修了另一个 feature 引入的问题 |
conflicts_with |
两个 feature 有已知冲突，不能同时激活 |
relates_to |
宽泛的关联，不属于以上类型 |
建立关系很简单：
bash
/pdlc-relate set feature/工具调用 depends_on feature/安全层但杀手锏是另一个子命令：
bash
/pdlc-relate impact feature/安全层这个命令输出：直接依赖这个 feature 的有哪些、通过传递关系间接影响的有哪些、历史上被它替代或解决的有哪些。一个命令，把改动的辐射范围摊开来看。
做这个功能的时候有个反直觉的选择：关系数据存在 docs/.pdlc/ 下面的结构化文件里，而不是某种专有数据库格式。理由是，这些关系是"团队的知识"，应该随代码一起提交、review、合并。如果存在黑盒里，换机器或换人就丢了。
两个功能一起踩的坑
surface 型产物的迁移，比我预想的麻烦。已有项目里那些旧的带日期架构文件，PDLC 怎么知道哪份是"最新的"？答案是不猜------/pdlc-arch 检测到遗留文件时会停下来问你："我看到 architecture-2026-02-19.md，要用这份作为 ARCHITECTURE.md 的初始内容吗？"一个确认步骤，避免自动迁移出错。
关系类型的设计，我也走了点弯路。第一版草稿里只有三种关系：依赖、扩展、冲突。拿真实项目试跑了一遍，发现有不少 feature 之间的联系根本描述不了------比如"这个 feature 修了那个 feature 的遗留问题"，归不进三类里的任何一个。最后扩展到六种，六种是够用的边界，再多就变成分类游戏了。
当前状态
v1.1 已经用在了三个项目上：aitm、pdlc-skills 自身、一个SaaS 项目。
ledger/surface 分离解决了最让人抓狂的问题------docs/ 不再是时间轴，是可以查找信息的地方。/pdlc-relate impact 在做跨 feature 的改动时每次都在用，省了不少"这会不会影响那边"的回溯排查。
33 个标准化阶段的核心结构没有变，v1.1 只在产物形状和关系建模上做了修正。如果你已经在用 v1.0，升级基本上是无感的------除了 /pdlc-arch 下次运行时会问你迁移旧文件。
安装 / 升级
首次安装（需要 Claude Code）：
bash
/claude install kanfu-panda/pdlc-skills升级已有安装：
bash
bash <(curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh) --upgrade源码在 GitHub，MIT 开源。用了遇到问题，Issues 开着，我在看。
下一篇
PDLC 把流程拆细、步步留产物------好处是不跳步、不跑偏，代价是它比"直接让 AI 写"更吃 token。今天就有人跟我说："文档一多，token 不就烧得更凶？"
这事值得单独聊一篇：这笔 token 账到底该怎么算（我没精确测过，但有些反直觉的地方），以及在用这套重流程的同时，我是怎么把花销压下去的。省 token 说到底就是省钱，但也不只是省钱。