一份需求文档产品经理吭哧吭哧写两天评审、拍板、上线。然后它躺进某个网盘、某个飞书空间或者某人电脑里的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 IDAC ID给定Given当When则ThenAC-F03-001金额≤200、非风险名单、已签收进入自动判定自动通过并原路退回记录命中理由AC-F03-002金额200 元进入自动判定转人工理由超金额阈值AC-F03-004风险名单接口超时进入自动判定触发降级转人工不自动放行你看 AC-F03-004——它把接口挂了怎么办这种异常路径也写进了验收。只写正常流的 PRD 是半成品这是第六条铁律。3. 它到底落在哪。不是随便一个文件而是直接落进业务知识库的原始层team-biz-wiki/raw/prd/{日期}-{业务线}-{需求名称}.md。命了名、带了可追溯的 frontmatterbrd_source、status: draft天生就是给下一个 skill 当输入的。实际怎么用你不用背命令。跟它说人话就行——「基于这份 BRD 写个 PRD」「把这个需求整理成需求文档」skill 就触发了。然后它会问你一句最关键的你有上游 BRD 或素材想让我分析还是从零开始构思这就是它的两种模式•有 BRD/素材最常见你把 BRD 甩给它它提取、你确认、快速补全。•从零开始没有上游材料时它用引导式提问一步步帮你想清楚。之后是6 步每步做完停在一个菜单等你敲C继续绝不自己闷头往下冲步骤干什么产出章节1初始化 吃 BRD/素材元信息、需求分析背景/价值/目标 G-xx2角色与权限ROLE 清单、权限矩阵3场景 端到端流程S-xx 场景表、主流程/异常流程 Mermaid 图4功能需求核心F-xx 每个功能的 GWT 验收5NFR UI 全局说明量化的非功能需求、UI 要点、名词解释6依赖约束 追溯校验D/A/C、追溯映射、闭环校验这里有个设计我很喜欢它把自己定位成引导者不是内容生成器。它不替你瞎编需求而是用结构化提问帮你把脑子里的东西挖出来、摆整齐。因为需求这东西AI 编得再顺也得是你脑子里的那个需求才算数。第 6 步的追溯校验是临门一脚。它会自动检查每个场景是不是都挂了功能每个功能是不是都有 GWT非目标列没列我们那次跑它就老老实实标出来「F-02/F-04/F-06 的 GWT 从略了」——该抓的缺口一个没漏。产出长什么样拿订单退款那份的一个真实切片感受下——一张端到端主流程图AI 画的是否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只读原始层→ wikiLLM 合成层→ schema规范层三个操作 Ingest / Query / Lint。wiki-ingest干的就是 Ingest。核心心法ingest 不是复制是提炼 编织这是最容易做错的地方。很多人以为沉淀知识就是把文件拷进 wiki 目录。不是。Karpathy 那句话点得很透wiki 是一个持续复利的产物每摄入一份材料就让它更丰富一点。所以 ingest 是三个动作读懂 → 提炼 → 把要点编织进已有的条目网络。判断一条信息要不要留就一个标准下一个人、下一个任务会来查它吗会查的留不会查的丢。我们那次从退款 PRD 里留下了这 4 类、丢掉了一堆提炼出的条目类目丢掉的东西退款审批关键术语业务术语埋点事件清单订单退款自动审批放行规则业务规则UI 色带、原型链接订单退款审批流程业务流程评审人名单风控名单接口降级规则异常规则灰度放量节奏留下的是「规则、流程、术语、异常兜底」——三个月后真会有人来查的丢掉的是界面细节和过程信息——查它的概率约等于零。而且它们不是 4 个孤岛。每条都用related和[[双链]]互相引用规则 ↔ 流程 ↔ 降级 ↔ 术语。知识要成网不成岛——这样 AI 检索时能顺着链子把相关的一并捞出来。比如那条业务规则提炼后长这样注意sources回指了 raw 的具体章节可追溯--- 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 常常触及多个文件raw/prd/…订单退款自动审批.md 只读源全程没动它一个字 wiki/ ← 新增 4 条status: draft → active catalog.md ← 4 条登记到对应类目单一事实源wiki 有的这里必须有 log.md ← 追加一行 ingest 记录append-only contributions/ ← 清空草稿全部晋升catalog.md里那条登记长这样一句话摘要让人和 AI 都能秒判断## 业务规则 - [订单退款自动审批放行规则](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 三件套才是完整的闭环。