产品知识库的终点，是让一句需求直接穿透 PRD、UI 和代码
诸葛铁铁提出产品知识管理的本质矛盾：需求文档堆积如山却无法还原产品现状。解法是将产品从自然语言需求文档重新整理为”系统—模块—页面—功能”的层级化结构 + 功能间影响关系图谱，让 AI 能定位功能、追踪影响链路，最终实现需求变更的自动传播分析。
基本信息
| 维度 | 内容 |
|---|---|
| 作者 | 诸葛铁铁、养乐多 |
| 来源 | 人人都是产品经理 |
| 发布日期 | 2026-07-10 |
| 原文链接 | https://www.woshipm.com/ai/6410424.html |
| 主 raw | raw/articles/2026-07-10-woshipm-product-knowledge-base-prd-ui-code.md（telegram 捕获） |
| 重复 raw | raw/articles/2026-07-17-woshipm-product-knowledge-base-prd-to-code.md；raw/extracts/20260717-031714/woshipm.com/prdui.md；raw/extracts/20260717-032641/woshipm.com/prdui.md（同源再捕获，已去重，不另建摘要页） |
核心观点
-
需求文档无法还原产品现状的根本矛盾：每份 PRD 只记录一次改动，迭代多年后想知道”一个功能今天怎么运行”就得拼起几年的文档再判断哪些规则已失效。“长上下文只是更大的抽屉”——模型能读进更多材料，但无法自动解决版本冲突，十份文档十种描述，缺少”哪份代表现在”这层判断。（来源：本文第2节）
-
“系统→模块→页面→功能”四级层级化是产品知识库的结构底座：将散落在自然语言文档中的产品知识重新落到产品实体上——每个功能都有明确位置、当前生效规则、角色和更新时间。迭代完成后旧逻辑被更新，变更记录继续保留。AI查询”商品创建”时先拿到生效规则，需要时再沿版本追溯。这把产品知识库从”文档仓库”变成”产品现状的可机读镜像”。（来源：本文第2节）
-
影响关系图谱是需求分析从关键词检索升级为影响传播的关键：层级解决”东西放哪”，关系解决”改动往哪扩散”。以”商家创建商品”为例，其影响链为：客户端商品详情、搜索与推荐、库存与价格、下单与商品快照。修改商品字段时，AI可沿依赖关系逐层检查——哪些页面要展示、哪些接口要返回、哪些数据库字段要调整、哪些历史数据需要兼容、哪些测试用例应补上。（来源：本文第3节）
-
全链路生成（PRD→UI→代码）的前提是全链路对齐：页面对应组件、交互调用接口、接口读写表、字段受规则约束——当这些对象拥有稳定标识并互相连接时，“一句话需求”才可能沿链路向下编译。但这条链路的可靠性取决于三层能力建设：第一层让知识可定位、第二层让影响可追踪、第三层让变更可验证。任何一层落后，“一句话改产品”都只能停留在演示。（来源：本文第4节）
-
产品知识库的真正终点是让产品变成 AI 可理解、可推理、可验证的世界：当产品现状能被机器准确读取，需求就不再是”等待扩写的文字”，而是”针对产品状态的变更指令”。未来拉开差距的不是谁写更长的提示词，而是谁先把产品整理成 AI 能操作的知识体系。（来源：本文第4节）
实操内容保留
产品层级化结构模板
系统 → 模块 → 页面 → 功能
示例：
电商系统
├── 商家模块
│ ├── 商品管理页面
│ │ ├── 商品创建功能（当前规则：XX字段必填、XX校验逻辑、角色=商家、更新时间=2026-07-10）
│ │ └── 商品编辑功能
│ └── 订单管理页面
├── 客户端模块
│ ├── 商品详情页面
│ └── 下单页面
└── 搜索与推荐模块
├── 搜索结果页面
└── 推荐Feed页面影响链路（Impact Graph）模板
[上游功能]
|
+–> [下游功能A] —影响→ [涉及页面] / [涉及接口] / [涉及数据表]
+–> [下游功能B]
+–> [下游功能C]以商品字段变更为例：
修改”商品创建”的”商品名称字段”属性 | +–> [客户端商品详情] → 展示端：商品详情页 → 接口：getProductDetail +–> [搜索与推荐] → 索引端：商品索引 → 接口：searchProduct / recommendFeed +–> [下单与商品快照] → 历史数据兼容：订单快照表（orders_snapshot）需确认字段映射 +–> [库存与价格] → 如有字段关联价格规则，需校验
### 三层能力建设框架
| 层级 | 目标 | 核心动作 |
|------|------|----------|
| L1 知识可定位 | AI 能准确找到功能及其当前生效规则 | 按系统→模块→页面→功能层级整理，标注生效规则、角色、更新时间 |
| L2 影响可追踪 | AI 能沿依赖关系传播变更分析 | 记录功能间上下游关系，按链路逐层检查影响 |
| L3 变更可验证 | AI 的变更建议经过测试校验 | 全链路对齐（页面→组件→接口→表→字段），代码与文档同步 |
（本文无实操代码/模板/步骤——以上为作者结构化思想的总结转译）
## 关键概念
- [[产品知识库]] — 产品自身运行规则的结构化镜像；本文提出的核心实体
- **产品层级化结构**（系统→模块→页面→功能四级拆解）
- **影响链路**（功能间上下游依赖关系，用于变更影响追踪）
- **全链路对齐**（页面→组件→接口→表→字段的端到端标识一致）
- **产品现状的可机读镜像**（产品运行规则的结构化表达，使 AI 能读取产品当前状态）
- [[产品信息架构]]（层级化结构与信息架构方法论的关系）
- [[AI产品PRD]]（从 PRD 文档到结构化知识的演化）
- [[产品需求分析]]（关系图谱对需求分析的影响传播升级）
- [[知识库构建工程]]（个人/组织知识库 vs 产品运行规则知识库的对照）
## 与其他素材的关联
- **与 [[2026-07-11-woshipm-knowledge-base-engineering-practice]]（@Sean 知识库构建工程）**：@Sean 解决的是个人知识管理（如何消化外部文章），本文解决的是产品知识管理（如何结构化产品自身的运行规则）。二者在"目录设计""结构层级""AI可执行性"上形成镜像——前者是认知资产的整理，后者是产品现状的结构化表达。
- **与 [[2026-05-18-woshipm-ai-product-prd]]（AI产品PRD 方法论）**：AI产品PRD 强调"PRD从上线前快照变成持续演进日志"，本文进一步提出 PRD 下的产品实体也需要持续更新——每个功能标注当前生效规则和更新时间。
- **与 [[产品信息架构]]**：本文的"系统→模块→页面→功能"四级分层是对产品信息架构在产品知识管理场景下的具体落地形态，从静态架构图升级为可追踪影响的关联网络。
- **与 [[知识库构建工程]]**：本文从"产品知识库"角度补全了知识库构建工程的另一个维度——不只是个人/组织知识管理，也包括产品自身的结构化知识治理。
## 原文精彩摘录
> 模型没有遗漏一段文字。它缺的是整个产品的当前状态。
> 长上下文能让模型读进更多材料，却无法自动解决版本冲突。十份文档出现十种描述，模型还得判断哪一份代表现在。缺少这层判断，再大的上下文也只是一个更大的抽屉。
> 过去依赖产品经理经验完成的"顺手多想一步"，终于有机会变成系统能力。
> 当产品现状能够被机器准确读取，需求就不再只是一段等待扩写的文字。它会变成一次针对产品状态的变更指令。
> 未来真正拉开差距的，也许不会是谁写出了更长的提示词，而是谁先把自己的产品整理成了 AI 能理解、能推理、也能验证的世界。
## 相关页面
- [[产品知识库]]
- [[产品信息架构]]
- [[AI产品PRD]]
- [[产品需求分析]]
- [[知识库构建工程]]
- [[AI产品经理工作流]]
- [[业务设计]]