一份需求文档，产品经理吭哧吭哧写两天，评审、拍板、上线。然后它躺进某个网盘、某个飞书空间，或者某人电脑里的 PRD_v2_final_最终版.md。三个月后，新来的同事问「退款到底什么情况下自动放行」，没人答得上来，只能翻聊天记录、翻代码、翻那份早就没人维护的文档。
更别提让 AI 来答了。你把那份 PRD 甩给 Claude，它能读，但读完也白读------因为那文档里全是「系统应该快速地、友好地处理退款」这种正确的废话，没有一条是它能稳定引用、能派生、能沉淀的东西。
本文全程用一个真实跑过的案例串起来：订单退款自动审批，看看怎么把「写完就死」的 PRD，变成「AI 真能查」的知识。
一条主线：从 BRD 到知识条目
先把全景放这儿，后面的每一步都在这张图上：
两个 skill，各管一段，接缝干净：第一个负责把需求写对、写成 AI 能用的样子；第二个负责把它沉淀成会复利的知识。 关键是它们中间那个 raw/prd/ ------ 它既是第一个 skill 的终点，又是第二个 skill 的起点。
Skill 一：prd-generator ------ 让 PRD 从"人能读"变成"AI 能用"
先说清楚，"AI 友好"到底友好在哪
这不是个玄学词。一份 PRD 对 AI（乃至对下游架构、测试）友不友好，就看三件事：
1. 有没有稳定 ID 的追溯链。
普通 PRD 里，角色、场景、功能都是散文里的名词，AI 没法稳定指向它们。这份模板强制给每个东西一个稳定编号，并且互相引用：
- •
ROLE-01消费者、ROLE-02客服、ROLE-03风控管理员 - •
S-01~S-05场景，每个场景挂着它需要的功能（S-02 → F-03） - •
F-01~F-06功能，每个功能回指它服务的场景和角色 - •
AC-F03-004、NFR-PERF-01、UI-01、D-01......
追溯链一旦闭合，下游就能干很省事的活：架构设计引用 ROLE-xx、测试用例直接从 AC-Fxx-xxx 派生 TC。链断了，就等于需求没定义清楚------这是模板的第一条铁律。
2. 验收标准是不是 GWT，而不是"功能正常工作"。
这是我最看重的一条。看两版对比，同一个功能：
❌
F-01 用户登录：系统应提供易用的登录界面，用户可以快速登录。------ "易用""快速"，AI 和测试都没法验证，等于没写。
✅ 用 GWT 表格，每条都可观测、可测试、有唯一 AC ID：
| AC ID | 给定（Given） | 当（When） | 则（Then） |
|---|---|---|---|
| AC-F03-001 | 金额≤200、非风险名单、已签收 | 进入自动判定 | 自动通过并原路退回，记录命中理由 |
| AC-F03-002 | 金额>200 元 | 进入自动判定 | 转人工，理由=超金额阈值 |
| AC-F03-004 | 风险名单接口超时 | 进入自动判定 | 触发降级，转人工，不自动放行 |
你看 AC-F03-004------它把"接口挂了怎么办"这种异常路径也写进了验收。只写正常流的 PRD 是半成品，这是第六条铁律。
3. 它到底落在哪。
不是随便一个文件，而是直接落进业务知识库的原始层：team-biz-wiki/raw/prd/{日期}-{业务线}-{需求名称}.md。命了名、带了可追溯的 frontmatter（brd_source、status: draft），天生就是给下一个 skill 当输入的。
实际怎么用
你不用背命令。跟它说人话就行------「基于这份 BRD 写个 PRD」「把这个需求整理成需求文档」，skill 就触发了。然后它会问你一句最关键的：
"你有上游 BRD 或素材想让我分析，还是从零开始构思？"
这就是它的两种模式：
- • 有 BRD/素材（最常见）：你把 BRD 甩给它，它提取、你确认、快速补全。
- • 从零开始：没有上游材料时，它用引导式提问一步步帮你想清楚。
之后是 6 步 ，每步做完停在一个菜单等你敲 C 继续，绝不自己闷头往下冲：
| 步骤 | 干什么 | 产出章节 |
|---|---|---|
| 1 | 初始化 + 吃 BRD/素材 | 元信息、需求分析（背景/价值/目标 G-xx） |
| 2 | 角色与权限 | ROLE 清单、权限矩阵 |
| 3 | 场景 + 端到端流程 | S-xx 场景表、主流程/异常流程 Mermaid 图 |
| 4 | 功能需求（核心） | F-xx + 每个功能的 GWT 验收 |
| 5 | NFR + UI + 全局说明 | 量化的非功能需求、UI 要点、名词解释 |
| 6 | 依赖约束 + 追溯校验 | D/A/C、追溯映射、闭环校验 |
这里有个设计我很喜欢：它把自己定位成引导者，不是内容生成器。它不替你瞎编需求，而是用结构化提问帮你把脑子里的东西挖出来、摆整齐。因为需求这东西，AI 编得再顺，也得是你脑子里的那个需求才算数。
第 6 步的追溯校验是临门一脚。它会自动检查：每个场景是不是都挂了功能？每个功能是不是都有 GWT？非目标列没列？我们那次跑，它就老老实实标出来「F-02/F-04/F-06 的 GWT 从略了」------该抓的缺口一个没漏。
产出长什么样
拿订单退款那份的一个真实切片感受下------一张端到端主流程图，AI 画的：
r
是
否
ROLE-01 消费者·提交退款申请系统·校验订单状态F-03 自动审批引擎·规则判定金额≤200 且 非风险名单 且 已签收?自动通过·发起原路退回转人工·进入 F-04 工作台节点上标着 ROLE-01、F-03、F-04------图和文字用的是同一套稳定 ID。这就是"AI 友好"的样子：不是给人看个热闹，是让机器和人指的是同一个东西。
Skill 二：wiki-ingest ------ 把 PRD 提炼成会复利的知识
PRD 落进 raw/prd/ 只是第一步。它还是一份"原始材料"------信息密度高，但也夹着一次性的东西（原型链接、评审人、灰度节奏）。真正值钱的知识，得再提炼一道。
这一步的方法论我抄的是 Karpathy 的 LLM Wiki：知识库分三层------raw（只读原始层）→ wiki（LLM 合成层）→ schema（规范层） ，三个操作 Ingest / Query / Lint。wiki-ingest 干的就是 Ingest。
核心心法：ingest 不是复制，是提炼 + 编织
这是最容易做错的地方。很多人以为"沉淀知识"就是把文件拷进 wiki 目录。不是。Karpathy 那句话点得很透：wiki 是一个持续复利的产物，每摄入一份材料，就让它更丰富一点。
所以 ingest 是三个动作：读懂 → 提炼 → 把要点编织进已有的条目网络。判断一条信息要不要留，就一个标准：
下一个人、下一个任务，会来查它吗？
会查的留，不会查的丢。我们那次从退款 PRD 里，留下了这 4 类、丢掉了一堆：
| 提炼出的条目 | 类目 | 丢掉的东西 |
|---|---|---|
| 退款审批关键术语 | 业务术语 | 埋点事件清单 |
| 订单退款自动审批放行规则 | 业务规则 | UI 色带、原型链接 |
| 订单退款审批流程 | 业务流程 | 评审人名单 |
| 风控名单接口降级规则 | 异常规则 | 灰度放量节奏 |
留下的是「规则、流程、术语、异常兜底」------三个月后真会有人来查的；丢掉的是界面细节和过程信息------查它的概率约等于零。
而且它们不是 4 个孤岛。每条都用 related 和 [[双链]] 互相引用：规则 ↔ 流程 ↔ 降级 ↔ 术语。知识要成网，不成岛------这样 AI 检索时能顺着链子把相关的一并捞出来。
比如那条"业务规则"，提炼后长这样（注意 sources 回指了 raw 的具体章节，可追溯）：
yaml
---
title: 订单退款自动审批放行规则
category: 业务规则
sources: [raw/prd/20260701-交易-订单退款自动审批.md]
related: [wiki/退款审批-业务术语.md, wiki/风控名单接口降级规则.md]
status: active
---
## 结论 / 定义
金额 ≤ 阈值(默认 200 元) 且 用户不在风险名单 且 订单已签收 → 自动通过；
任一不满足即转人工。一句话结论 + 可追溯来源，AI 一眼就知道该不该点进去、点进去能信。
那道最关键的闸：contributions 评审
这是我给 Karpathy 原版加的唯一一处改动，也是我认为最重要的一处：AI 不许自审自批。
流程是这样的：AI 干所有脏活------读源、提炼、起草，把草稿全写进 contributions/。然后它必须停下来 ，把草稿清单摆到你面前，请你逐条裁决：通过 / 修改 / 退回。只有你点头的，才晋升进 wiki/。
为什么这么设计？因为起草的是 AI，把关的必须是人。要是 AI 自己写自己批，这道闸就形同虚设，知识库迟早变成一个塞满 AI 幻觉的垃圾场。wiki 是提炼层，不是垃圾桶------这是知识库的铁律。
我们那次，AI 起草了 4 条，停下来问我。我说「都通过」，它才走下一步。
晋升那一下，一次动了 6 个文件
我点头之后，它做了一套连贯动作（这也印证了 Karpathy 说的"一次 ingest 常常触及多个文件"）：
lua
raw/prd/...订单退款自动审批.md （只读源，全程没动它一个字）
wiki/ ← 新增 4 条，status: draft → active
catalog.md ← 4 条登记到对应类目（单一事实源：wiki 有的，这里必须有）
log.md ← 追加一行 ingest 记录（append-only）
contributions/ ← 清空（草稿全部晋升）catalog.md 里那条登记长这样，一句话摘要让人和 AI 都能秒判断：
ini
## 业务规则
- [订单退款自动审批放行规则](wiki/订单退款自动审批放行规则.md) --- 金额≤200 且 非风险名单 且 已签收 → 自动通过，否则转人工 · active · 2026-07-01跑完我做了一次一致性校验：catalog 登记 4 条 = wiki 文件 4 个 ，每条都有 sources 回指 raw。闭环干净。
为什么是两个 skill，而不是一个
有人会问：干嘛不一步到位，PRD 生成完直接写进 wiki？
因为职责边界 。raw 是只读的原始材料层，wiki 是提炼后的合成层，中间隔着一道人工评审闸。PRD 是原始材料，天然属于 raw/prd/；它要不要、以什么形态进 wiki，是另一个决策，得过评审。
所以 prd-generator 故意止步于 raw/prd/ ，绝不越过 contributions/ 直接写 wiki。这不是偷懒，是纪律。两个 skill 各司其职，接缝就是那个 raw/prd/ 文件------上一个的终点，下一个的起点，清清爽爽。
几个我踩过或差点踩的坑
- • GWT 不能留空。 图省事把验收标准写成"功能正常工作"，等于没写，下游测试恨死你。宁可功能少写一个，也别让 F-xx 没有 AC。
- • 稳定 ID 别断链。 场景引用了一个没在 §3 声明的角色，或者功能没挂任何场景------第 6 步的校验会抓，但最好写的时候就别断。
- • raw 只读，是真的只读。 提炼时只读它、引用它，绝不回头改它。原始材料一旦可改，可追溯性就崩了。
- • 别让 AI 自审自批。 这条我再强调一遍。
contributions那道闸是知识库质量的命根子。 - • 别拿脏数据喂真库。 我上面这个案例是空跑演示，用的是假 BRD。演示完那几个文件我是要清掉的------知识库里只留真需求提炼出的真知识。
最后
这套东西跑顺之后，我最大的感受是：需求不再"写完就死"了。
一份 BRD，经 prd-generator 变成带稳定 ID、带 GWT、能追溯的 PRD，落进 raw/prd/；再经 wiki-ingest 提炼成术语、规则、流程、异常四类知识，进 wiki/、登 catalog。之后新同事的疑问、AI 的检索、下游的架构和测试，全都有一个可信的、会持续变丰富的源头去查。
配套：检索知识用
wiki-query，定期给知识库做体检和减法用wiki-lint。Ingest / Query / Lint 三件套，才是完整的闭环。