AI生成PRD看似完美，实则暗藏陷阱——它能精准描述单一功能，却难以捕捉模块间的蝴蝶效应。本文揭示产品知识管理的本质矛盾：需求文档堆积如山却无法还原产品现状，并给出从知识结构化到影响链路可视化的系统解法，让AI真正理解产品全貌而非片段信息。

AI 写需求最容易让人产生一种错觉：只要提示词写得够细，它就能交出一份完整的 PRD。

实际用起来，AI 经常能把眼前的功能写得像模像样，却会漏掉相邻模块和上下游流程。商家端改了商品字段，客户端要不要同步？订单快照该保存哪个版本？难点在于，这些规则散落在不同平台、页面和旧需求里。

模型没有遗漏一段文字。它缺的是整个产品的当前状态。

需求文档保存了变化，却很难还原现状

大多数产品知识都散落在需求文档里。每份文档只记录一次改动。迭代多了以后，想知道一个功能今天怎么运行，就得拼起几年的文档，再判断哪些规则已经失效。

人都容易看漏，AI 也一样。

长上下文能让模型读进更多材料，却无法自动解决版本冲突。十份文档出现十种描述，模型还得判断哪一份代表现在。缺少这层判断，再大的上下文也只是一个更大的抽屉。

所以我开始按“系统—模块—页面—功能”重新整理产品。

这套层级把文档中的自然语言重新落到产品实体上。每个功能都有位置、当前规则、角色和更新时间。迭代完成后，旧逻辑被更新，变更记录继续保留。AI 查询“商品创建”时，先拿到生效规则，需要时再沿版本追溯。

到这里，知识库才开始接近产品本身。

目录让 AI 找到功能，关系让 AI 看见影响

仅有层级还不够。

系统、模块、页面、功能解决的是“东西放在哪里”。真正棘手的问题，是一个改动会沿着哪些关系向外扩散。

商家创建商品，客户端会展示商品；商品数据进入搜索和推荐；用户下单后，订单保存商品快照；商品下架后，历史订单仍然要展示当时的信息。它们分散在多个平台，却共享同一组业务事实。

一旦把这些关系记录下来，需求分析就从关键词检索变成了影响传播：

[商家创建商品]

|

+–> [客户端商品详情]

+–> [搜索与推荐]

+–> [库存与价格]

+–> [下单与商品快照]

这张关系网的意义很直接。以后修改商品字段，AI 可以顺着依赖关系逐层检查：哪些页面要展示，哪些接口要返回，哪些数据库字段要调整，哪些历史数据需要兼容，哪些测试用例应该补上。

过去依赖产品经理经验完成的“顺手多想一步”，终于有机会变成系统能力。

全链路生成的前提，是全链路对齐

沿着这个逻辑继续往下走，产品知识库还可以连接 UI、前端和后端。

页面对应哪些组件，交互调用哪个接口，接口读写哪些表，字段受哪些规则约束。当这些对象拥有稳定标识并互相连接，一句话需求才可能沿链路向下编译：定位功能、修改 PRD、生成 UI，再找到前后端代码的落点。

这条链路不会因为画出知识图谱就自动可靠。知识要更新，关系要校验，代码和文档要对齐，结果还要经过测试。任何一层停留在旧版本，AI 都可能一本正经地改错地方。

因此，真正值得建设的能力有三层：第一层让知识可定位，第二层让影响可追踪，第三层让变更可验证。缺少任何一层，“一句话改产品”都只能停留在演示里。

我昨天搭出的只是起点。它先解决一个朴素的问题：让 AI 知道产品今天究竟长什么样。

当产品现状能够被机器准确读取，需求就不再只是一段等待扩写的文字。它会变成一次针对产品状态的变更指令。

未来真正拉开差距的，也许不会是谁写出了更长的提示词，而是谁先把自己的产品整理成了 AI 能理解、能推理、也能验证的世界。