在 PD sidebar 起草需求

产品 / BA 用 PD sidebar 写 10 件 PD 制品，或先在 Studio 协同后端起完再流转过来

如果你是产品 / BA，PD sidebar 是你在 IDE 里的主战场。

你要起草的 10 件文档

文档	写什么	千万别写
`vision.md`	为什么做、给谁、什么时候发	功能能力 / NFR 数字
`stories.md`	用户视角的场景与故事	"系统 SHALL" 系统视角
`requirements.md`	系统应做哪些功能	NFR 数字 / API 字段
`nfr.md`	系统属性的目标值	功能行为 / 实现策略
`acceptance.md`	怎样算达标	测试步骤 / 实现方案
`product-design.md`	产品层设计约束	表结构 / API 字段
`risks.md`	产品视角的风险	工程实施细节
`rollout.md`	怎么发布、监控、回滚	代码级监控
`glossary.md`	术语是什么意思	mermaid 图
`ai-spec.md`	为什么用 AI、怎么评、怎么兜底	具体模型品牌

每件详细规格看每件文档怎么写。

起草方式 1：在 IDE 里直接写

打开 PD sidebar，选要写的文档，开始填。编辑器自动校 entity schema，违规字段会红色下划线。

起草技巧：调 /aiko-pd-package <feature>-pd 让 AI 按你的 vision 一口气起 10 件骨架，你只改不写：

> /aiko-pd-package add-coupon-discount-pd

✓ vision.md      (5 条 VISION-* / 2 条 GOAL-*)
✓ stories.md     (8 条 STORY-* / 12 条 SCEN-*)
✓ requirements.md (15 条 REQ-FN-* / 3 条 REQ-ALG-*)
✓ nfr.md
✓ acceptance.md  (18 条 ACC-* 引用 REQ-FN-*)
⚪ product-design.md (s 档可选,跳过)
✓ glossary.md

起草方式 2：在 Studio 协同后端写，再流转过来

如果是多角色协作 / 需要评审，先在 Studio 协同后端写：

Studio 端的协同优势：

多人同时编辑
评审 / 审批 / waiver 状态机
影响分析（改一条事实立刻看下游受谁影响）
多租户隔离 + 审计

定稿后流转到仓库，PD sidebar 直接读，validate 一次就能跑 14 个 Validator。

ID 规范一览（写时随时查）

文档	ID 长这样
`vision.md`	`VISION-001` / `GOAL-002` / `PERSONA-003` / `SCOPE-004` / `MILE-005`
`stories.md`	`STORY-001` / `SCEN-002`
`requirements.md`	`REQ-FN-001` / `REQ-ALG-002` / `REQ-SEC-003` / `REQ-DOC-004`
`nfr.md`	`REQ-NFR-PERF-001` / `REQ-NFR-AVAIL-002` / `REQ-NFR-SEC-003` / `REQ-NFR-OBS-004` / `REQ-NFR-COMPAT-005` / `REQ-NFR-I18N-006` / `REQ-NFR-A11Y-007`
`acceptance.md`	`ACC-001`
`product-design.md`	`DESIGN-001` / `IA-002` / `INTERACT-003` / `INTEG-004` / `CONSTR-005`
`risks.md`	`ASSUM-001` / `DEP-002` / `RISK-003`
`rollout.md`	`ROLL-001` / `METRIC-002` / `ALERT-003` / `SOP-004`
`glossary.md`	`GLOSS-001`
`ai-spec.md`	`AI-FRAME-001` / `MODEL-002` / `DATA-003` / `EVAL-004` / `GUARD-005`

ID 三位数起，自增。同一个 change 内不能重复。

不要写错地方（SSoT 守则）

每个 PD 文档只回答一个问题，越界写会被 ssot Validator 抓出。

最常踩坑：

❌ 在 vision.md 写功能能力（应该归 requirements.md）
❌ 在 requirements.md 写 NFR 数字（应该归 nfr.md）
❌ 在 acceptance.md 写测试步骤（应该归 test-cases.md）

详细的"严禁写"清单看为什么不要复制粘贴。

起草顺序建议

按这个顺序写最顺：

vision.md 先 —— 想清楚为什么做
stories.md —— 用户场景说人话
glossary.md —— 先把术语锁定，后面统一引用
requirements.md —— 转成系统功能
nfr.md —— 加性能 / 可用性 / 安全数字
acceptance.md —— 每条功能写"怎样算达标"
剩下的（product-design / risks / rollout / ai-spec）按矩阵看是否必填

写完之后

./scripts/aiko-validate.sh

14 个 Validator 全过 = PD 包 ready。

PD 包就绪后，调 /aiko-pd-to-arch / /aiko-pd-to-test / /aiko-pd-to-dev 让 AI 推下游三个包的骨架。