5个需求，32个开发工时，以前要一周，现在一上午搞定。这套「知识库底座+三专家智能体」的SPEC需求生产流水线，不靠卷prompt，而是靠沉淀领域知识和设计分工协作流程。本文拆解如何搭建知识库、配置三个专家智能体，并分享这套方法的适用边界与核心优势。

先给大家看一组我自己的实操数据：

5个需求，每个对应约32个开发工时的工作量，放在以前，从业务梳理到输出完整PRD加原型，我至少要花一天做一个，全部做完得整整一周。

而用我现在这套方法，一个上午，并行处理完了。

很多人聊AI写需求，第一反应都是卷prompt、堆skill、换更强的模型。但我自己实践下来的感受是：真正决定产出质量和效率的，从来不是prompt写得有多精妙，而是你给AI搭了什么样的知识底座，以及设计了什么样的生产流程。

今天就把我这套跑通了的「知识库底座+三专家智能体」SPEC需求生产流水线完整分享出来。

一、别再卷prompt了，知识库才是真正的护城河

我见过太多人陷入一个误区：AI输出的需求不对业务、不符合现状，就觉得是prompt写得不好，于是反复调措辞、加约束、堆规则，结果越写越长，效果却提升有限。

问题根本不在prompt上。

通用大模型的逻辑能力、表达能力其实已经足够强了，它缺的不是指令技巧，是你的领域背景知识。你不把业务规则、历史沉淀、字段定义、场景边界告诉它，它再聪明也只能凭空生成通用方案。

我的核心思路很简单：好料进，好答出。先把领域知识沉淀成高质量的底座，再让智能体带着背景去干活，效果比调一百遍prompt都稳。

我的喂料进化史：从给人看的，到给AI读的

知识库不是随便把历史文档丢进去就行的。我踩过很多坑，原料形式前后迭代了好几轮：

• 最开始直接投喂图片、扫描版PDF，结果OCR识别错误多、格式混乱，AI经常读错字段、理解偏差，召回效果一塌糊涂；
• 后来换成表格、Word文档，好了一些，但依然有大量冗余格式、排版干扰，有效信息密度低；
• 最终稳定在纯Markdown文档。结构清晰、没有冗余格式、层级分明，是最适合AI读取的原料形态。

但光有md还不够，我会先按细分子领域把历史需求、操作手册梳理成独立的md文档，再让AI对每份文档做二次加工，统一术语、提炼核心规则、梳理场景边界，最后导入Dify做成可调用的知识库。

Dify这一层的价值在于分段、召回打标、子分段管理和API化调用。它不是简单的文档存储，而是把知识拆成了可被精准检索的片段，智能体需要什么就能调取什么，避免无关信息干扰，也更省token。

知识库是活物，不是建完就一劳永逸

很多人建知识库的动作停留在「导入一批文档」，这其实只是开始。

我的做法是把知识库当成持续运营的资产：

• 每一个新需求上线后，我都会把对应的SPEC文档、业务规则变更提取出来，合并进对应子领域的知识库，同时记录更新时间，保证知识永远和线上现状对齐；
• 历史文档里常见的术语不统一、字段命名不一致的问题，我会让AI在梳理阶段全部提取出来，由人工确认统一标准，再入库；
• 遇到AI输出结果不对的情况，我不会直接改prompt重生成，而是先追问它「这个判断的知识来源是哪一段」，快速定位是知识库内容有误、还是召回错了片段，从根上解决问题。

说到底，prompt是技巧，知识库才是家底。技巧谁都能学，但沉淀下来的领域知识，是别人抄不走的护城河。

二、把产品团队装进三个智能体

有了知识底座，下一步是设计生产流程。

我没有用一个大而全的智能体包打天下，而是拆成了三个分工明确的专家智能体，分别对应真实产品团队里的三个角色：调研规划、需求设计、风险审查。各司其职，串行联动。

1. 调研规划专家：需求分析师

这是流水线的第一环，核心是「做对方向」。

它的能力是读取领域知识库，围绕我提出的初步想法做头脑风暴，通过对话不断补全需求细节、明确业务目标、划定场景边界，直到前期信息足够充分，最终输出一份结构化的需求设计框架。

配套的skill主要是两类：知识库读取skill，保证它基于业务现状思考；脑暴发散skill，帮我补全没考虑到的角度。

这个环节人必须在回路。AI可以帮你发散、帮你梳理，但需求的优先级、核心价值、取舍判断，只能由人来拍板。

2. 需求设计专家：产品设计师

框架确认后，就进入第二环，核心是「做对规格」。

它接收调研规划专家输出的需求框架，调用需求设计skill，严格按照SPEC格式规范，输出标准的Markdown格式需求文档，同时生成对应的HTML原型。

SPEC和传统PRD最大的区别就是：它只写AI需要读懂的内容——核心逻辑、业务流程、边界条件、验收规则，所有为了方便人类理解的描述性铺垫、交互说明、背景故事全部砍掉。原型也不再嵌在文档里，而是以HTML形式独立关联，机器直接读结构就行。

这一步是效率提升的核心，以前最耗时间的写文档、画原型，现在基本由AI完成。

3. 风险审查专家：评审/QA

最后一环，核心是「守住质量」。

它会对需求设计专家输出的SPEC文档和HTML原型做全面审查：格式是否符合规范、设计是否和原始需求一致、有没有逻辑漏洞、有没有未闭环的场景、有没有潜在的业务风险。发现问题就标注出来，提示人工介入检查调整。

这是整个流水线的质量兜底。前面两步再快，最后这道关也不能省。只不过以前是拉着开发、测试开评审会人工找坑，现在由AI先筛一遍绝大多数常规问题，人只需要处理真正有争议的判断点。

三个专家串行跑通，就是一条完整的SPEC需求生产线。而因为每个环节都是独立的智能体，我可以同时开多个窗口并行处理不同需求，这也是能一上午干五个需求的关键。

三、为什么我放弃了Superpowers，选择自己搭

肯定有人会问：现在现成的工具比如Superpowers，脑暴、需求确认、架构设计、编码、测试、审查全链路都做好了，为什么还要自己搭？

我认真用过Superpowers，必须承认它能力很强，覆盖的环节非常全。但对产品经理这个角色来说，它有点「过重」了。

核心差异在定位：

• Superpowers是服务全栈开发者的，它的流程是从想法到代码全链路打通，后面的编码、测试、联调环节占了很大比重；
• 而我需要的只是「从想法到SPEC」这一段，代码生成是下游开发的事，产品阶段不需要。

带来的问题就是：流程臃肿，审查链路长，大量token消耗在产品不需要的环节上，反而不够灵活。

我自己搭的这套框架，前半段的需求脑暴、框架设计、SPEC输出、风险审查，质量和Superpowers是对齐的，但我砍掉了所有产品交付边界之外的环节，只保留最核心的需求生产部分。

换来的好处很明显：

• 更轻量：启动快，配置简单，贴合产品经理的日常作业习惯；
• 更省token：没有冗余环节，每一次调用都在产出有效内容；
• 更灵活：可以轻松多开窗口并行作业，同时处理多个需求。

工具没有好坏，只有合不合适。对开发者来说Superpowers是神器，但对只需要输出SPEC的产品经理来说，一套轻量化的自建框架反而效率更高。

四、这套方法的边界：什么时候不能靠知识库

最后必须说清楚边界，没有万能的方法论。

这套「知识库优先」的打法，在有历史沉淀的存量业务领域效果最好，它能保证AI输出的需求永远贴合业务现状，不会出现「外行式的正确废话」。

但如果是全新的0到1业务、完全没有历史文档的创新领域，知识库反而会成为包袱——旧知识会把AI的思路框在既有范式里，不利于创新。

这种时候我不会强行调用知识库，而是切换成另一套模式：

新增一个「调研专家」智能体，由它来收集外部行业资料、竞品信息，再加上人工输入的新业务背景资料，先帮AI建立对新领域的基础认知，再进入后续的需求生产流程。

简单总结就是：存量业务靠沉淀，增量业务靠调研。

不要试图用一套方法打所有场景，知道什么时候用什么工具，比工具本身更重要。

最后

回到开头那个「一上午干一周的活」的结果，其实一点都不神奇。

它不是靠某个神奇的prompt，也不是靠某个碾压一切的大模型，而是靠「高质量知识底座+分工化智能体流水线」叠加出来的必然结果。

我越来越觉得，AI时代的产品经理，核心竞争力很快就不会是「文档写得好不好、原型画得漂不漂亮」了。这些表达层的工作，AI只会做得比人更快更规范。

真正的差距会体现在两个地方：

一是沉淀领域知识的能力——你能不能把零散的业务经验梳理成可复用、可被AI读取的知识资产；

二是设计协作流程的能力——你能不能把复杂的需求工作拆成流水线，调度AI帮你高效完成。

AI不是一个帮你写文档的工具，它是你可以调度的一整个团队。

而你要做的，是当好这个团队的管理者。