基于知识图谱与LLM构建产品大脑：从信息孤岛到智能决策

1. 项目概述：构建一个基于知识图谱的“产品大脑”

如果你是一名产品经理，或者身处产品团队，你一定经历过这样的场景：用户访谈记录散落在不同的文档里，数据分析报告躺在邮件附件中，产品需求文档的版本号混乱不堪，而设计稿的链接则淹没在群聊里。当需要为下一个季度的规划寻找决策依据时，你不得不像一个考古学家一样，在浩如烟海的碎片信息中挖掘、拼凑。更糟糕的是，你永远无法确定，昨天刚更新的那份用户研究报告，是否已经同步到了正在评审的PRD中。这种信息孤岛和连接断裂，是产品决策效率低下、团队认知不一致的根源。

PM-Wiki v1 正是为了解决这个痛点而生。它不是一个简单的文档仓库，而是一个活的、互联的产品知识图谱。其核心哲学是：产品知识不是一堆孤立的文件，而是一个由用户洞察、数据证据、产品决策和实验结果构成的动态网络。这个项目基于 Obsidian（一个强大的本地 Markdown 知识库工具）和任意大语言模型（LLM），通过一套精心设计的自动化工作流，将你零散的输入——访谈笔记、数据截图、会议纪要、竞品分析——自动转化为结构化的知识节点，并智能地建立和维护它们之间的关联。

想象一下，当你导入新的用户访谈记录后，系统不仅能自动生成一份结构化的访谈摘要页面，还能识别出这与某个已有的“用户痛点”机会点相关，进而自动更新所有依赖该机会点的产品需求文档（PRD）的“证据库”部分，并在PRD的变更日志中留下记录。整个知识网络像拥有生命一样，一处更新，处处感知。这背后的组织框架，是产品发现领域广受认可的“机会解决方案树”（Opportunity Solution Tree, OST），但你不必手动维护这棵树——它会从你的日常工作中自动生长出来。

2. 核心设计理念：从文件夹到知识图谱的范式转变

2.1 为何是“图谱”而非“文件夹”？

传统的信息管理方式，无论是云盘、Notion还是Confluence，本质都是“文件夹”思维。你将文件分门别类地放好，依赖的是人的记忆和手动链接来建立关联。这种方式在信息量小、团队人少时或许可行，但随着项目复杂度提升，它立刻变得脆弱不堪。链接会失效，文件更新后依赖它的其他文档无从知晓，历史的决策上下文在一次次的文件覆盖中丢失。

PM-Wiki v1 的设计基石是“图谱思维”。在这个系统中，每一个知识单元（如一次用户访谈、一个数据洞察、一份PRD、一个已批准的技术决策）都是一个节点（Node），节点之间通过有向边（Edge）连接，形成一张网。例如，“用户访谈A”支持“机会点B”，“机会点B”催生了“解决方案C”，“解决方案C”对应着“实验D”。这种连接是双向且可追溯的。

注意：这里的“图谱”是一个逻辑概念，并非一定要用图数据库实现。在PM-Wiki v1中，它是通过Markdown文件中的YAML Frontmatter元数据和双链笔记（[[链接]]）功能来模拟和实现的。Obsidian 的原生图谱视图可以直观地展示这些连接，但系统的智能维护能力来自于LLM对元数据和链接关系的理解与操作。

这种设计的优势是革命性的：

1. 影响面分析：当源头信息（如一个核心数据指标的定义）变更时，系统可以自动追溯所有依赖它的PRD、决策和实验，并标记它们需要复审。
2. 自动生成视图：你可以随时基于某个目标（如一个季度OKR），让系统自动生成一棵完整的“机会解决方案树”，清晰地展示从目标到机会、到解决方案、再到实验的完整推导链条，并高亮显示证据的强弱和存在的缺口。
3. 上下文感知的问答：当你向系统提问“我们为什么要做这个功能？”时，它给出的答案不是基于模糊的语义搜索，而是沿着图谱的链接，精准地引用上游的用户研究、数据支持和相关决策记录。

2.2 双智能体架构：图书管理员与分析师

为了让LLM更可靠、更可控地执行任务，PM-Wiki v1 引入了明确的“智能体”（Agent）角色分工。这不是两个不同的程序，而是赋予LLM的两种不同的“人格”和任务指令集。

• 图书管理员（Librarian）：负责“写”操作，维护系统的结构与秩序。它的核心任务是执行如/wiki-ingest（内容摄取）、/wiki-propagate（变更传播）等命令。它的思维模式是系统性的、客观的，严格遵守预设的规则和模式（Schema）。它只关心信息的准确归类、链接的正确建立、变更的合规传播，绝不会对产品决策本身发表意见。这保证了知识图谱底层数据操作的可靠性和一致性。
• 分析师（Analyst）：负责“读”与“分析”操作，提供洞察与建议。它的核心任务是执行如/wiki-query（智能问答）、/wiki-ost（生成机会树）、/wiki-prd-check（PRD审查）等命令。它的思维模式像一个资深的、熟读了所有资料的产品负责人，擅长综合、批判性思考，总能引用来源，并指出矛盾之处。它基于图谱中的数据为你提供分析结论。

这种分离至关重要。它避免了让同一个“大脑”既当裁判又当运动员可能带来的混乱，也使得整个系统行为更加可预测、可审计。在实际操作中，你通过不同的命令来“召唤”不同的智能体。

2.3 基于Git的版本控制与协作

所有由智能体产生的更改，都会自动生成语义化的Git提交。这意味着：

• 完整的审计轨迹：知识图谱的每一次演变都有据可查。你可以看到“PRD A的证据库在4月12日因为导入了访谈B而更新”。
• 无缝的团队协作：团队可以将知识库仓库放在GitHub、GitLab等平台上。成员通过git pull获取最新知识，通过git push分享自己的工作成果。由于大部分内容是追加而非覆盖，合并冲突很少发生。
• 数据安全与所有权：你的所有知识资产都以Markdown文本文件的形式存储在本地，你拥有绝对的所有权。Git仓库让你可以轻松备份、回滚或分支。

3. 从零开始：环境准备与初始化实战

3.1 工具链选型与配置要点

PM-Wiki v1 的核心依赖非常简单，但每一步的选择都关乎后续使用的顺畅度。

1. Obsidian：这是你的“阅读器”和“编辑器”。它免费、离线、基于Markdown，且拥有强大的双链笔记和图谱视图功能。

   • 实操：直接从官网下载安装即可。无需安装复杂插件，PM-Wiki v1 的工作流不依赖特定插件，而是通过LLM驱动。
   • 心得：建议在Obsidian设置中，将“默认新建笔记位置”设置为你的知识库目录下的raw/子文件夹，这样临时记录的想法能直接进入待处理区。

2. Git：版本控制系统。这是必需项。

   • Windows用户：推荐安装 Git for Windows ，它包含了Git Bash命令行工具。
   • Mac/Linux用户：通常系统已预装，或可通过包管理器（如Homebrew, apt）安装。
   • 关键配置：安装后，务必设置你的用户名和邮箱，这是Git提交的标识。

     git config --global user.name "你的名字" git config --global user.email "你的邮箱"

3. 大语言模型（LLM）接口：这是系统的“大脑”。你有多种选择，选择取决于你对数据隐私、成本和性能的需求。

   • 云端API（高隐私要求）：Claude for Enterprise或Azure OpenAI服务是首选，它们提供合同保障的零数据保留策略，符合企业安全规范。你需要能通过API密钥调用这些服务。
   • 云端API（通用）：OpenAI GPT-4 API 或 Anthropic Claude API，在账户设置中明确选择“不将数据用于训练”。
   • 本地模型（最高隐私）：使用Ollama或LM Studio在本地电脑上运行开源模型（如 Llama 3、Qwen 等）。这完全杜绝了数据外泄，但对电脑硬件（尤其是GPU内存）有一定要求。
   • 集成开发环境（IDE）插件：Cursor、Zed AI或Continue等智能IDE，它们内置了LLM能力并能直接操作文件系统，是体验最无缝的方式。

重要安全提示：绝对不要使用面向消费者的网页版ChatGPT、Claude.ai或Gemini来处理包含真实用户数据、未脱敏的访谈记录、内部指标等敏感信息。这些服务默认可能将你的输入用于模型训练，这会违反公司的数据安全政策及相关法律法规。在将任何真实产品数据放入系统前，请务必确认你的LLM渠道的数据处理政策。

3.2 项目初始化与仓库搭建

假设我们为一个名为“星辰电商”的项目搭建产品知识库。

1. 克隆模板仓库： 打开终端（或Git Bash），执行以下命令。这里我们将仓库克隆到本地并重命名为star-mall-pm-wiki。

   git clone https://github.com/bicodeurubu/pm-wiki-v1.git star-mall-pm-wiki cd star-mall-pm-wiki

2. 修改远程仓库地址（为团队协作准备）： 为了将你的工作推送到团队共享的仓库（例如在GitLab上新建的空仓库），需要更改远程地址。

   # 将下面的URL替换成你团队仓库的实际地址 git remote set-url origin https://gitlab.your-company.com/your-team/star-mall-pm-wiki.git

   如果只是个人使用，可以跳过此步。

3. 在Obsidian中打开知识库： 打开Obsidian，点击“打开文件夹作为知识库”，选择刚刚克隆的star-mall-pm-wiki文件夹。Obsidian会将其识别为一个独立的知识库（Vault）。

4. 向LLM“介绍”这个系统： 这是关键一步。你需要让你选择的LLM接口“看到”并理解这个知识库的整个结构和工作规则。

   • 如果你使用 Cursor/Continue/Zed：直接在IDE中打开star-mall-pm-wiki文件夹。然后新建一个聊天窗口，LLM会自动读取当前文件夹下的文件作为上下文。你可以先发送一句“请阅读本项目的 CLAUDE.md 文件以了解系统规则。”
   • 如果你使用 Claude API 或 ChatGPT 等聊天界面：你需要手动将整个项目文件夹（或至少是CLAUDE.md和主要目录结构）作为上下文上传或粘贴。CLAUDE.md是这个系统的“宪法”，LLM通过阅读它来理解所有的页面类型、命令和规则。

5. 执行初始化命令： 在你的LLM聊天界面中，输入初始化命令：

   /wiki-init

   智能体（图书管理员）会开始工作：检查所有必要的文件夹（raw/,wiki/下的各子目录）是否存在，创建缺失的目录，放置好模板文件，并执行第一次Git提交。你会在聊天窗口看到类似“Vault initialized. First commit made.”的确认信息。

至此，你的“产品大脑”的基础设施就搭建完毕了。接下来，就是喂给它“养料”——你的原始工作资料。

4. 核心工作流深度解析：从原始资料到互联知识

4.1 第一步：投放原料到“收件箱”（raw/）

raw/目录是你的收件箱，所有未经处理的原始资料都丢到这里。它的子目录有明确的用途划分，这相当于给LLM提供了最初的分类线索。

实操心得：养成“即收即存”的习惯。开完用户访谈会，立刻将要点整理成Markdown丢进raw/interviews/。看到一个关键数据图表，截图并配上简短说明丢进raw/data/。这个动作越轻量，你坚持使用的阻力就越小。

4.2 第二步：启动“消化”过程（/wiki-ingest）

当raw/目录下积累了一些文件后，在LLM界面中输入核心命令：

/wiki-ingest

智能体（图书管理员）会启动一个复杂的多步处理管道：

1. 分类：读取raw/下的每个文件，根据其内容和所在文件夹，判断其类型（是用户访谈、数据洞察还是竞品信息）。
2. 提取与结构化：调用对应的“技能”（Skill），将非结构化的文本转化为结构化的知识页面。例如，对于访谈笔记，它会运行interview-synthesis技能，生成一个包含“参与者信息”、“关键引用”、“发现的痛点”、“关联的机会点”等字段的标准化页面，并存入wiki/users/目录。
3. 连接发现：这是最智能的部分。系统会分析新创建页面的内容，在已有的知识图谱中寻找关联。例如，新访谈中提到的“支付流程复杂”，可能会与已有的wiki/users/opportunity-checkout-friction.md机会点页面匹配。它会自动在访谈页面和机会点页面之间建立双向链接。
4. 变更传播：如果新内容关联到了一个已有的“父节点”（如一个PRD），系统会触发propagate-changes流程，自动更新那个父节点的“证据库”部分，并在其“变更日志”中追加一条记录，说明因何更新。
5. 提交存档：上述每一步更改，都会生成一条清晰的Git提交信息，如feat(wiki): ingest interview-premium-user as user-interview。

现场实录：假设我们放入了三份关于“购物车放弃率”的访谈记录和一份数据报告，然后执行/wiki-ingest。你将在LLM的回复中看到一个详细的处理日志：

Processing: interview-cart-abandon-01.md → Type detected: user interview → Running: interview-synthesis → Created: wiki/users/interview-cart-abandon-01.md → Updated: wiki/users/persona-casual-shopper.md (added new quote) → Connected to: wiki/users/opportunity-cart-complexity.md (existing opportunity) → Git commit: feat(wiki): ingest interview-cart-abandon-01 Processing: dashboard-cart-funnel-q1.png → Type detected: analytics data → Running: extract-data-insight → Created: wiki/data/insights/cart-abandon-rate-peaks-at-shipping.md → Created stub: wiki/data/metrics/cart-to-order-conversion-rate.md → Connected to: wiki/users/opportunity-cart-complexity.md → Propagating changes... → wiki/specs/prd-simplify-checkout-v2.md → evidence base updated, flagged for review → Git commit: feat(wiki): ingest cart-funnel data, updated dependent spec

这个过程完成后，你打开Obsidian，会发现wiki/目录下多了几个新页面，并且它们之间已经有了链接。更重要的是，相关的PRD页面已经被自动标记为“需要复审”。

4.3 第三步：消费与决策——智能体的分析能力

当知识图谱有了内容，你就可以召唤“分析师”智能体来帮你思考和决策了。

• 审查PRD的完备性：/wiki-prd-check wiki/specs/prd-simplify-checkout-v2.md分析师会按照内置的检查清单（问题陈述是否清晰、证据是否充分、是否关联到机会点、成功指标是否有基线值、是否有实验计划等）给PRD打分，并给出具体的改进建议。这就像有一个不知疲倦的资深产品同事在帮你做设计评审。

• 生成机会解决方案树：/wiki-ost wiki/strategy/q2-okrs.md这是系统的杀手锏。你指定一个目标（如一个OKR页面），分析师会自动遍历图谱，找出所有与这个目标相连的机会点，每个机会点下的解决方案，以及每个解决方案下的实验，并以Mermaid图表的形式生成一棵可视化的树。同时，它会高亮显示证据的强弱（比如某个机会点只有一份数据支持，缺乏用户访谈），指出当前的缺口在哪里。这为季度规划会议提供了无与伦比的清晰度。

• 进行战略问答：/wiki-query “基于当前证据，我们应该优先解决哪个用户体验问题？”分析师不会凭空臆想。它会检索整个图谱，综合评估各个机会点的证据强度、关联的实验结果、影响的用户范围等，给出一个带有引用来源的、有理有据的建议。你可以问任何关于产品现状的问题。

• 追溯决策链条：/wiki-trace wiki/decisions/use-oauth-for-login.md当有人质疑“我们当初为什么决定用OAuth登录？”时，这个命令可以展示出完整的证据链：从哪些用户研究指出了注册繁琐，到哪些数据支持了流失率，再到当时的几个备选方案和最终的决策记录。所有信息一目了然。

5. 高级配置与团队协作实践

5.1 自定义技能与智能体

PM-Wiki v1 的扩展性极强。如果你的团队有特定的工作方法（比如使用DACI框架做决策，或用Shape Up方法进行项目规划），你可以通过创建自定义技能来让系统支持。

1. 创建自定义技能：复制skills/_skill-template.md到skills/custom/skill-daci-format.md。这个模板文件定义了技能的用途、触发条件、输入输出格式和规则。例如，你可以创建一个技能，当智能体遇到一个决策记录时，自动将其格式化为标准的DACI（驱动者、批准者、贡献者、知情者）模板。
2. 注册技能：在.claude/SKILLS.md文件中添加对新技能的描述和路径。之后，图书管理员智能体在执行任务时就能调用它了。
3. 创建自定义智能体：类似地，你可以复制agents/_agent-template.md来创建一个新的智能体角色，比如“技术评审员”，它的视角更关注技术可行性、依赖和风险评估，并在评审PRD时被调用。

5.2 多知识库联动

在大公司里，一个产品团队的知识可能与其他团队（如平台团队、公司战略团队）紧密相关。PM-Wiki v1 支持跨知识库查询。

1. 在公司战略团队的知识库中，维护着company-okrs-v1。
2. 在你的产品知识库的context.md文件中，添加引用：

   - path: ../company-okrs-v1 description: Company-level OKRs and strategic decisions use_when: Aligning product decisions to company direction

3. 当你在自己的知识库中运行/wiki-context “公司本季度的核心增长目标是什么？”时，分析师智能体会去读取引用的战略知识库，找到相关信息并反馈给你，而无需你将内容复制过来。这既保持了知识的单一来源，又实现了信息的连通。

5.3 Git团队工作流

团队协作的核心是Git。

• 每日开始：git pull origin main获取队友的最新更新。
• 工作期间：放心使用/wiki-ingest和各类命令。所有更改都已自动提交到本地。
• 每日结束或完成一个模块：git push origin main推送你的更改。由于智能体生成的提交信息非常清晰，代码审查（如果需要）也会很轻松。
• 处理冲突：冲突很少见，因为大部分页面是独立的。如果发生，通常是因为两人同时编辑了同一个文件的同一部分（如都向一个PRD添加了证据）。使用git mergetool或直接在IDE中解决即可，本质就是合并Markdown文本。

6. 常见问题与避坑指南

在实际部署和使用PM-Wiki v1的过程中，我遇到并总结了一些典型问题，希望能帮你绕开这些坑。

Q1: LLM在处理我的文件时，似乎理解有偏差，分类或提取不准确。

• 原因排查：首先检查raw/下的文件内容。LLM依赖你提供的内容质量和初始分类提示（即放在哪个子文件夹）。一段杂乱无章、缺乏上下文的文本，LLM很难处理。
• 解决方案：
  1. 优化原料：在放入raw/前，花1分钟稍微整理一下。例如，访谈笔记不要只是零碎的对话记录，最好在开头写明“访谈对象：XX用户；访谈时间：XXXX；核心主题：购物车体验”。
  2. 提供示例：最有效的方法是，在skills/custom/中为你特定的内容类型创建一个自定义技能。在技能文件中，通过清晰的“示例”部分，告诉LLM exactly 如何解析你的数据格式。
  3. 事后修正：如果生成了错误的页面，可以直接在Obsidian中编辑那个wiki页面，修正链接和内容。知识图谱是宽容的，你可以手动调整。

Q2: 生成的“机会解决方案树”感觉链接不全，有些关系没被识别出来。

• 原因排查：连接发现依赖于页面内容中的关键词和LLM的语义理解。如果两个页面使用了完全不同的词汇描述同一件事（比如一个用“结账”，一个用“支付”），就可能无法自动连接。
• 解决方案：
  1. 使用标准术语：在团队内约定一些核心领域的关键词（如“转化漏斗”、“用户留存”、“A/B测试”），并在文档中尽量一致地使用。
  2. 手动加强链接：在Obsidian中，你可以随时在任何页面通过[[输入页面名来手动创建链接。这是双链笔记的优势，智能体生成的和手动创建的链接是等价的。
  3. 运行连接重建命令：对特定页面执行/wiki-connect [页面路径]，或对整个知识库执行/wiki-connect all，强制智能体重新扫描并建立连接。

Q3: 感觉维护这套系统本身也有学习成本，如何让团队快速用起来？

• 策略：不要试图一次性让团队所有人掌握所有命令。采用“渐进式启用”策略。
  1. 第一步：共享知识库。先简单地把Git仓库共享，让大家都能看到结构化的wiki页面和自动生成的图谱。这本身就有很大价值。
  2. 第二步：设立“收件箱”专员。可以由团队中的助理产品或项目经理负责，定期收集大家的原始资料，统一执行/wiki-ingest。其他人只需消费生成好的图谱和报告。
  3. 第三步：推广核心查询。在周会上，演示如何使用/wiki-ost生成规划图，用/wiki-query回答争议问题。当大家看到其价值后，学习命令的动机自然会产生。

Q4: 本地LLM模型（如Ollama）速度慢或效果不好怎么办？

• 硬件：本地推理需要较强的CPU和足够的内存。对于7B参数左右的模型，16GB内存是基本要求。对于更大的模型（如70B），则需要强大的GPU。
• 模型选择：不是所有开源模型都擅长这类结构化任务。建议选择在指令遵循和逻辑推理上表现较好的模型，如Llama 3 8B/70B Instruct、Qwen 2.5 系列或DeepSeek Coder（如果涉及代码类内容）。在Ollama中多尝试几个。
• 降级方案：如果本地模型实在不给力，可以退而求其次，使用云端API但严格处理数据：只将脱敏后的、不包含任何用户个人身份信息（PII）和核心商业机密的分析摘要放入系统，原始敏感数据仍存储在本地加密区域。让LLM处理的是“清洁过”的信息。

Q5: 和现有的项目管理工具（如Jira, Asana）如何集成？

• 当前状态：PM-Wiki v1 本身不直接与这些工具双向同步。它的定位是“决策与知识中枢”，而非任务执行跟踪器。
• 集成思路：
  1. 信息导出：你可以创建一个自定义技能skill-jira-export.md。当一份PRD在wiki中被最终确定后，运行这个技能，它可以基于PRD内容生成符合Jira格式的用户故事（Story）描述和验收标准，你只需要复制粘贴到Jira。
  2. 链接引用：在wiki的PRD或实验页面中，可以添加一个“跟踪任务”部分，手动贴上Jira任务的链接。这样就从知识（Why, What）链接到了执行（How, Who, When）。
  3. 定期同步：可以定期运行/wiki-query生成“本周已完成的实验结论”或“下季度待启动方案”的摘要，手动更新到项目管理工具的目标或史诗（Epic）描述中。

这套系统的魅力在于，它开始可能只是一个帮你整理笔记的工具，但随着你投入的内容越来越多，那个自动生长、互联互通的知识图谱会逐渐成为团队最宝贵的资产——一个永不遗忘、永远保持上下文、能随时为你提供决策支持的“产品大脑”。它改变的不仅仅是信息存放的方式，更是产品团队思考、协作和决策的底层逻辑。