AI工作流跑不起来，问题可能出在PRD
刘宇帅前面几篇，聊了团队怎么搭 AI 工作流、怎么建知识库。
今天聊聊 AI 在 PRD 编写和质量保障上，我们做了些什么。
其实这块从一开始就在工作流里。只是在开始的MVP版本里，核心全压在开发环节。
等大家真用起来，一个问题立马浮出水面：
PRD 质量一般，工作流出来的技术方案，质量自然也上不去。
道理特别朴素：垃圾进，垃圾出。
源头的 PRD 含糊，后面 AI 再能干，也只是替你把这份含糊"发扬光大"。
所以我决定还是要治理一下这个源头。
第一步：先给 PRD 做个体检
我做的第一件事，是一个 PRD 质量检测 skill。
注意，它不碰业务逻辑，只做"规范层"的体检，就盯三件事：
一是合不合规范。 符不符合我们的 PRD 模板，项目背景、目标、涉及部门、影响系统、验收标准等是否齐全。
二是细节够不够完备。 这里的"完备"，是指有没有把诉求真正讲清楚——
而不是像过去那样，产品写一半，剩下一半靠和开发"你懂的""意会一下"。
三是前后自不自洽。 别上面说 A，下面说 B，自己跟自己打架。
就这三点就已经能筛掉不少"一看就要返工"的 PRD。
第二步：给产品经理一个趁手的工作台
光有检测还不够。
我们原来的工作流，是纯开发视角设计的。
你让一个产品经理，捧着 IDE 加命令行去写 PRD？
体验可想而知。😅
所以做在做产研工作台的时候，我特意分了两种模式：开发模式、产品模式。
产品经理进产品模式，底层那些命令和视图我全给封装了——他看到的，就是几个干净的按钮：起草 PRD、检测 PRD、提交 PRD。
按钮背后主要是三个命令在干活：
起草 PRD。 两种玩法：一句话，或者一份 BRD。给它素材，它结合知识库和代码、套上我们的 PRD 模板，直接吐一份草稿出来。
业务逻辑搜索。 这个不为写 PRD，是为了解决另一个老问题——产品一有疑问，就跑去找开发查代码。现在他直接问这个命令，它结合知识库和代码，把现有逻辑讲给他听。
PRD 质量检测。 在前面那三点之上，再加一层逻辑：融合知识库和代码，拿 PRD 跟线上的真实逻辑去比对，看有没有冲突、有没有遗漏的地方。
中间踩的一个坑
做这块，中间有个小波折，挺值得说。
一开始，我有个顾虑：产品同学对代码库的安全意识，未必有开发那么强。
所以最初那版，我没敢在命令里加"拉代码、读代码"的能力，只让它读知识库。
结果交付给 PM 用，反馈是——
"比不用知识库，好了那么一丢丢。" 🤦
为什么这么拉胯？
我前面讲知识库时说过：我们的知识库，不是代码的完整翻译，只是对海量代码的一层分层索引。
索引能告诉你"大概在哪、大概是什么"，但真要抠具体的业务逻辑，它太单薄了。
只读索引、不读代码，PRD 检测自然飘在半空。
想明白这点，我还是把代码 clone 和分析的能力，加了回去。
中间也纠结过，要不要给代码加一层加密。
试了试，没找到更好的方案，最后放弃了。
放弃加密，其实也是因为想得更远了
放弃，有两个理由。
一是为了快速受益。 先用起来、先受益，比什么都重要。
二是，我看到了更远的未来。
现在每个命令，都是自己按需去翻知识库、翻代码，各翻各的。
但等整套流程跑稳，你会发现：不管读代码还是读知识库，翻来翻去就那么几种固定姿势。
到那时，我会把这些"读取能力"统一抽出来，做成服务端的 MCP 能力——比如按关键字检索某个系统、某个业务域、某个服务或接口。
能力都收到服务端了，命令本身不再直接碰代码，安全这个问题，自然就不存在了。
具体方案，等真做的时候再细抠吧。
要不要给 PRD 单独建一套知识库？
还有两个问题，做知识库的团队大概率都纠结过，我也纠结过：
一，产品知识库和开发知识库，要不要分开建？
二，产品这边，要不要单独维护一套"永远最新"的 PRD 文档？
我想了挺久，结论是——都不必。
PRD 就是个一次性产物。写完、评审完、开发完，它的使命基本就结束了。
真正的事实层，只有一个，就是代码。
别再额外去养一层事实层了——不管它叫知识库，还是叫"一份永远最新的 PRD"。
为什么？先说个现实。
以往 AI 还没这么强的时候，PRD 你再怎么精心管理，也做不到真正清晰——
产品经理想从 PRD 里查到"系统某个功能现在到底长什么样"？基本查不到。
那现在 AI 强了，能帮我们管 PRD 了，行不行？
还是不行。
因为从 PRD 到代码，中间要过太多道关：技术方案、测试方案、问题修复、验收优化、线上处理……
不可能每一次变更，都老老实实从 PRD 发起。
只要有一个环节绕过了 PRD，那份"最新 PRD"就开始失真。
养一层注定会过时的事实层，最后只会变成又一个没人敢信的文档库。
所以我的判断很明确：未来很长一段时间，代码，仍然是唯一的事实层。
PRD 只负责把"这次要做什么"说清楚，仅此而已。
至于"现在系统到底是什么样"——去问代码，去问那份从代码扫出来的知识库。
最后
回头看，PRD 这件事给我最大的提醒是：
AI 工作流的质量，往往不是卡在 AI，而是卡在喂给它的东西。
源头脏，下游再使劲也是白费。
与其在后面拼命纠错，不如先把最前面那一道——PRD，弄干净。
这事还在磨。
未来两周的时间里，我会花大量的时间在这上面，主要解决3个问题。
- 立标准：什么是 AI 时代更友好的 PRD？
- 给方法：如何写出 AI 时代更友好的 PRD？
- 降门槛：如何让人人都能轻松的写出 AI 时代更友好的 PRD？
刘宇帅
非著名程序员，全栈开发工程师，长期专注系统开发与架构设计。
提示
功能待开通！
相关文章
AI Coding 搞了一年,我才认准真正的护城河是知识库
AI Coding 时代最大的护城河，不是模型，不是 Agent，也不是工作流。 而是知识库。 这是我折腾了一整年 AI Coding，到最后才慢慢看明白的事。 可一开始，我和大多数人一样，劲儿全使在另一个地方——工作流。 怎么把写 PRD、出方案、写代码、生成测试串成一条链路，让 AI 一步步往下跑。 工作流跑通了，下一个问题马上冒出来—— AI 跑这些命令的时候，到底读什么？ 光给它代码，不够。 于是所有人又一窝蜂去搞知识库。研发在搞，产品在搞，业务也在搞。 可搞着搞着我发现一件事：几乎没人能说清，知识库到底该是什么。 先说说，知识库不该是什么 很多人理解的知识库，是"把代码翻
Loop Engineering：每篇文章都在讲，但没人告诉你怎么搭
最近 Loop Engineering 在持续刷屏。 公众号在刷，各种群里在讨论，我也看了好几篇文章。 每篇都有道理——五个组件、目标定义、古德哈特定律，逻辑很清晰，我都信了。 但看完之后有点空。 我的工作流该怎么 Loop 化？从哪起手？搭出来以后长什么样？ 没一篇说清楚。 所以想聊聊我自己的理解，以及我们实际在做的事——我们团队搭了个叫 Talos 的系统，算是目前我见过最接近"生产级 Loop Engineering"的垂类实践。 Loop 其实只有两种形态 在我看来，Loop Engineering 这件事，放长了看只有两个终点。 第一个是通用智能 AI。 它足够强
从个人提速到团队提效：我们这半年的AI Coding工程化实践
去年开始，团队里每个人都用上 AI 写代码了。 按理说，效率该起飞了。 可折腾了大半年，我才慢慢看清：每个人都明显变强了，但团队的合力却没跟着强起来。 会用 AI 的人，效率飞涨。 用得浅的人，被甩在后面。 几十个开发，几十套打法——各自的 prompt 习惯、各自的提示词、各自摸索出的一套方法。 这本来不是坏事。 坏就坏在，大家的产出开始对不上了。 同一个功能，不同人让 AI 写出来的代码，风格能差出十万八千里。 某个同事摸到一个好用的技巧，群里截图一发，热闹两句，然后就沉底了。 下一个新人进来，还是从零开始踩。 文档呢？散在各个服务的 README 里，或者干脆躺在某个人的电脑里。 遇到跨
大家都在说工作流，那我们到底是用开源的呢，还是定制自己的呢？
做团队 AI 工作流，第一个把我卡住的问题，不是技术。 而是——到底该用开源的，还是自己造一套？ 说实话，我一开始也很犹豫。 毕竟"自己造轮子"这四个字，听着就不太聪明。 所以动手之前，我特意花了不少时间，认真研究了一圈现成的方案：BMAD、OpenSpec、SuperPowers、SpecKit…… 一个个看下来，我的第一感受是：真优雅。 👏 设计思路清晰，工程化也讲究，看得出背后都是高手。 可越往深里看，我越发现：它们再好，也不是为我们这种团队设计的。 所以，最终我还是决定做我们自己的工作流。 三个绕不过去的坎 具体说，是三个坎，每一个都硌得慌。 第一个，它们几乎都是冲
AI Coding 跑顺了,真正的难关才开始
最近这几天，我又开始焦虑了。 原因是，我突然意识到一件事。 已经有一阵子，没人反馈 Zeus 的问题了。 Zeus 是我们团队做的一套 AI Coding 工具体系。 说白了，就是想让 AI 把"写代码"这件事，从头到尾接过去。 用了两个多月，大家从一开始的别扭、吐槽、不信任，慢慢变成了—— 用得挺顺。 顺到，没人抱怨了。 按理说，这是天大的好事。 可那一刻，我心里咯噔一下。 因为"没人提问题"，有两种可能：一种是真的没问题了，另一种是，大家已经看不见问题了。 我估计，是后者。 浮在水面上的，是看得见的成绩 这半年，团队是真的变样了。 Zeus、Zeus