版本说明：本文介绍 design-doc v6（含 6.1 的产品基线落地）。若你还不熟悉分层文档、编码与人审定稿，可先读基础介绍；v5 时代「定稿即可实现」的主张见氛围编程与 v5。
1 定稿了，为什么还不能直接写代码？
v5 解决了一件大事：设计条目要经人确认，才能从草稿变成「正式」。没有这道闸，AI 很容易把聊天里的半成品当成规格去改仓库。
可产品一迭代，新问题就露出来了：
- 正式条目越积越多。有的属于下一季才该上的能力，有的刚定稿还没打算进这一版交付。
- 「正式」不等于「这一版可以动手」。若 AI 只认状态、不认版本切片，就会提前实现、错版实现，或者把未宣布的能力写进当前分支。
- 发版时说不清依据。对客、验收、回滚时，你需要的不是「仓库里所有正式项」，而是「这一版产品到底钉住了哪些条」。
一句话：人审定稿管的是质量；产品基线管的是「当前允许实现的范围」。 两件事叠在一起，按文档实现才站得住。
2 v6 加了什么：产品基线
产品基线是某一产品版本下、允许作为实现依据的细项集合。
你可以把它想成发版时盖的章：
| 概念 | 管什么 | 怎么变 |
|---|---|---|
| 细项 / 文档的修订 | 这条设计改过几轮 | 解冻修订时才动 |
| 产品版本（如 v5.17） | 这一版产品叫什么 | 你说「发版 / 升产品版本」才动 |
| 产品基线文件 | 这一版到底含哪些正式细项 | 随产品版本生成一份快照 |
它们正交：改一条规则的措辞，不必升产品版本；发一版产品，也不必把所有文档解冻重写一遍。
实现门禁因此变成两道：
- 细项（以及所在文档）须是正式（人审过）；
- 该细项还须出现在当前产品版本对应的基线里。
缺任一条件，AI 必须拒绝拿它去写或改代码，并提示你先定稿，或先升产品版本把条目纳入基线。
3 这对氛围编程意味着什么
v5 按住的是「没有依据的自由发挥」。
v6 按住的是「有依据，但越界实现」。
典型场景：
- 下个迭代才上的支付能力已经定稿，但还没进当前基线 → AI 不得提前写进本周要上线的分支。
- 本版要交付的网格规则都在基线里 → AI 可以按清单实现、审查、对照验收。
- 你发了下一版产品 → 基线更新，可实现集跟着变；历史基线只读，方便回溯「当时依据的是哪一包设计」。
人仍然做决策：定哪些条、何时发版、是否升主版本。技能负责把「当前可实现集」写清楚，并在写代码前执行门禁。
4 v6 仍然继承的东西
产品基线不是另起炉灶，而是架在 v5 已经立住的骨架上：
- SSoT：一条设计一个编码，引用走编码，废弃不删号；
- 人在回路：大纲、批量落码、废弃、收尾定稿，该停就停；
- 分层与模板：L0–L6 按需裁剪，多数项目仍从 L2 / L4 起步；
- 可检查：脚本核对编码、状态、引用，以及当前基线是否齐全、成员是否仍正式。
若你只需要「会写规范文档」，基础介绍就够用。若你已经靠定稿在写代码，却开始为「这一版到底依据哪些条」头疼，v6 的产品基线就是为这一层准备的。
5 开源，免费，可商用
designdoc 采用 MIT 许可：https://github.com/reddishz/designdoc
系列阅读：
- 基础介绍：designdoc
- v5（氛围编程与定稿闸门）：designdoc-vibe
- 本篇：v6 产品基线
安装与字段怎么配，以仓库根 README 与技能内说明为准；机制细节见技能包中的产品版本与基线专章。