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个问题。

1. 立标准：什么是 AI 时代更友好的 PRD？
2. 给方法：如何写出 AI 时代更友好的 PRD？
3. 降门槛：如何让人人都能轻松的写出 AI 时代更友好的 PRD？