个人知识库

产品知识库

12分钟阅读

产品知识库

把产品自身的运行规则整理成 AI 可定位、可追踪影响、可验证变更的结构化体系——区别于个人知识库/组织知识库，它描述的是“产品今天到底长什么样”，目标是让一句需求能穿透 PRD、UI 与代码。

简介

产品知识库不是“把所有 PRD 丢进文件夹”，也不是个人笔记式的 LLM Wiki。它专指产品自身运行规则的结构化镜像：每个功能在系统中的位置、当前生效规则、角色权限、更新时间，以及功能之间的上下游影响关系。

人人都是产品经理上诸葛铁铁（养乐多）的文章指出：AI 写需求最容易制造错觉——提示词写得够细，就能交出完整 PRD。实际结果却是：眼前功能写得像样，相邻模块与上下游流程漏掉；商家端改了商品字段，客户端是否同步、订单快照保存哪个版本，这些规则散落在不同平台、页面和旧需求里。模型并没有漏读一段文字，它缺的是整个产品的当前状态。

因此，产品知识库要解决的核心矛盾是：需求文档保存了变化，却很难还原现状。每份文档只记录一次改动；迭代多年后，想知道功能今天如何运行，就要拼起多年文档再判断哪些规则已失效。长上下文能塞进更多材料，却不能自动解决版本冲突——十份文档十种描述，模型仍不知道哪一份代表“现在”。缺少这层判断，更大的上下文只是更大的抽屉。

关键信息

维度内容
类型产品管理 / 知识工程方法论
领域AI 产品、B 端/多端业务系统、需求管理
与相近概念区别RAG 知识库 解决“检索文档”；知识库构建工程 解决“个人/组织认知资产”；产品知识库解决“产品运行现状可被机器读取”
核心组成系统—模块—页面—功能层级、当前生效规则、影响关系图、稳定对象标识、变更验证
适用场景AI 辅助写 PRD、改字段影响分析、一句话需求向下编译到 UI/接口/表结构
相关概念AI产品PRD、产品信息架构、产品需求分析、知识库构建工程

核心特性

1. 四级层级：系统 → 模块 → 页面 → 功能

把自然语言需求重新落到产品实体上。每个功能至少标注：

  • 位置：属于哪个系统/模块/页面
  • 当前生效规则：字段必填、校验、展示与权限
  • 角色：谁可创建/编辑/查看
  • 更新时间：规则何时变成当前版本

迭代完成后，旧逻辑被更新而不是只追加一篇新 PRD；变更记录可保留用于追溯，但查询默认先拿“生效规则”。例如查询“商品创建”时，AI 先拿到当前规则，需要时再沿版本历史回溯。

系统 → 模块 → 页面 → 功能
 
电商系统
├── 商家模块
│   ├── 商品管理页面
│   │   ├── 商品创建（当前规则 / 角色 / 更新时间）
│   │   └── 商品编辑
│   └── 订单管理页面
├── 客户端模块
│   ├── 商品详情
│   └── 下单
└── 搜索与推荐模块

这层解决的是“东西放在哪里”，是产品知识库的结构底座。

2. 影响关系：从关键词检索升级为影响传播

仅有层级不够。真正棘手的是：一个改动会沿哪些关系向外扩散。以“商家创建商品”为例，关系可能覆盖：

  • 客户端商品详情展示
  • 搜索与推荐索引
  • 库存与价格
  • 下单时的商品快照（下架后历史订单仍要展示当时信息）

这些对象分散在多平台，却共享同一组业务事实。把关系记录下来后，修改商品字段时，AI 可沿依赖逐层检查：哪些页面展示、哪些接口返回、哪些库表字段调整、哪些历史数据需兼容、哪些测试用例要补。

[商家创建商品]
 |
 +–> [客户端商品详情]
 +–> [搜索与推荐]
 +–> [库存与价格]
 +–> [下单与商品快照]

作者称之为：过去依赖 PM 经验“顺手多想一步”，有机会变成系统能力。

3. 全链路对齐：PRD → UI → 代码的前提

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

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

4. 三层能力建设（真正值得建设的部分）

层级目标核心动作
L1 知识可定位AI 能找到功能与当前生效规则系统→模块→页面→功能；标注规则/角色/更新时间
L2 影响可追踪AI 能沿依赖传播变更分析记录上下游关系，按链路检查页面/接口/表/历史兼容/测试
L3 变更可验证变更建议经测试与对齐校验页面→组件→接口→表→字段端到端标识一致；代码与文档同步

缺少任何一层，“一句话改产品”只能停留在演示。

5. 常见误区

  1. 把产品知识库当成 PRD 归档仓库：只堆积历史变更，不维护当前生效态，AI 仍会在版本冲突里迷路。
  2. 只有目录没有关系：层级解决存放，不解决影响扩散；改一个字段仍靠 PM 脑子补全。
  3. 只画图谱不维护对齐：UI/接口/表结构与文档脱节时，全链路生成会一本正经改错地方。
  4. 用更长提示词代替现状建模：提示词再细也补不齐“产品当前状态”这一层。
  5. 与个人知识库混为一谈：个人知识库编译外部认知；产品知识库镜像产品运行规则，对象与验收标准不同。

不同素材中的观点

  • 2026-07-10-woshipm-product-knowledge-base-prd-ui-code（诸葛铁铁）：
    • AI 写 PRD 的幻觉不在漏字，而在缺少产品现状。
    • 需求文档天然保存“变化”而非“现状”，长上下文无法自动消解版本冲突。
    • 用“系统—模块—页面—功能”把自然语言落到产品实体；用影响关系把需求分析从关键词检索升级为影响传播。
    • 全链路生成（PRD→UI→代码）的前提是全链路对齐与三层能力：可定位、可追踪、可验证。
    • 终点不是更长提示词，而是把产品整理成 AI 能理解、能推理、也能验证的世界；需求从“等待扩写的文字”变成“针对产品状态的变更指令”。

实用信息

建设起步清单

  1. 先选一条高耦合业务链（如商品创建→详情→搜索→下单快照），不要一上来全库重构。
  2. 为每个功能写四元组：位置、当前规则、角色、更新时间。
  3. 画出上下游影响边：页面 / 接口 / 表 / 历史兼容 / 测试各至少检查一层。
  4. 给对象稳定 ID：页面、组件、接口、字段用统一标识，便于机器连接。
  5. 迭代时更新生效态：新 PRD 合并进当前规则，旧版本进变更记录，而不是只追加文件。
  6. 验收三层能力：能否定位当前规则、能否列出影响面、能否用测试验证变更。

与 AI 写 PRD 的配合方式

  • 生成前：先检索功能的当前生效规则与影响图，再写变更。
  • 生成中：强制输出“相邻模块/上下游检查清单”。
  • 生成后：对照 L2 影响边与 L3 测试/对齐结果做 diff，不直接上线。

相关资源

相关页面

关系图谱

快速导航

反向链接