4 条产品线，3 个 Wiki 子库，我让 AI 成为最懂我业务的分析师
一只阿木木约 17 分钟竞品库、用研库、方法论库——我的 Obsidian 配置实录
我在用这套系统大概八个月的时候，遇到了一个朋友——我叫他小林，是一家 B2B SaaS 公司的产品负责人。
他管着四条产品线：
一个面向中大型企业的核心产品 一个新孵化的 AI 功能模块 一个刚从客户需求里长出来的垂直行业版本 一个内部工具（因为老板临时说「你顺手管一下吧」）
四条线同时跑。
团队只有他一个产品经理，加上两个实习生。
他来找我聊，是因为他感觉自己「随时都在失控的边缘」：
「我知道每条线在发生什么，但我不知道它们合在一起说明了什么。
我知道竞品动态，但我不知道竞品在告诉我我们哪里有问题。
我知道用户在说什么，但我记不住上一次用研的结论。
我有想法，但我的想法没有地方积累，每次要用都得重新想一遍。」
我们花了一个下午，给他的工作场景设计了一套 Obsidian 配置。
这篇文章，就是那套配置的完整记录。
一、先搞清楚产品经理的信息痛点
在设计系统之前，我们做了一件重要的事：把他的信息流拆开来看。
作为产品经理，每天涌进来的信息大概分这几类：
text
竞品动态
→ 竞品发布了新功能
→ 竞品的客户在社区里说了什么
→ 行业媒体关于竞品的报道
→ 竞品的定价/GTM 策略变化用户声音
→ 用研访谈记录
→ 客服反馈汇总
→ NPS 评论
→ 用户在社区/论坛里的讨论
产品方法论
→ 行业里的产品文章
→ 书摘（从产品设计的书里）
→ 其他 PM 的经验分享
→ 框架和思维模型
工作任务
→ 需求评审的待办
→ 和研发/设计的对齐记录
→ 各种会议纪要
→ 截止日期和 deadline
个人积累
→ 自己对某个问题的思考
→ 对某个决策的复盘
→ 想法碎片
拆完之后，我们问了一个问题：
这五类信息，哪些应该「被积累」，哪些只是「被执行完就消失」？
结论是：
工作任务 → Ephemeral/Operational，进任务层和项目管理层，不进 Wiki 竞品动态 → Reference，进竞品 Wiki 用户声音 → Reference，进用研 Wiki 产品方法论 → Reference + Evergreen，进方法论 Wiki 个人积累 → Evergreen，进日记 Fleeting Ideas，再手动升级
这就是小林最终选定的三个 Wiki 子库：
text
03-Resources/
├── competitors/ ← 竞品情报 Wiki
├── user-research/ ← 用研洞察 Wiki
└── product-methods/ ← 产品方法论 Wiki
加上他自己的完整 Vault 结构：
text
ObsidianVault/
├── CLAUDE.md
├── .claude/skills/
│ ├── triage.md
│ ├── wiki-compile.md
│ ├── daily-open.md
│ ├── weekly-review.md
│ └── competitor-scan.md ← 专属 Skill（后面会讲）
├── 00-Inbox/
├── 01-Projects/
│ ├── core-product/ ← 核心产品
│ ├── ai-module/ ← AI 功能模块
│ ├── vertical-edition/ ← 垂直行业版本
│ └── internal-tools/ ← 内部工具
├── 02-Areas/
│ ├── career/ ← 职业发展
│ ├── health/
│ └── finance/
├── 03-Resources/
│ ├── competitors/
│ ├── user-research/
│ └── product-methods/
├── 04-Archive/
├── Periodic/
└── AI-Log/
二、三个 Wiki 子库的详细设计
Wiki 子库一：竞品情报（competitors）
这是小林最在意的一个子库。
他的行业竞争激烈，主要竞品有 5 家，每家都在快速迭代。
以前，他的竞品追踪方式是：
关注竞品的公众号、Twitter、官网更新 看到重要动态就截图或者摘录几句话扔进 Notion 偶尔做一次竞品对比分析表格
问题：
「每次我需要用竞品信息，我都要重新爬一遍记录。
而且我完全不知道某个竞品的「一年来的演进轨迹」，
因为我的记录都是孤立的快照，不是时间线。」
competitors/CLAUDE.md 的核心设计：
Markdown
# Wiki 子库：competitors（竞品情报）## 定位
追踪和分析主要竞品的产品策略、功能演进、市场定位。
目标不是「记录竞品做了什么」，
而是「理解竞品的演进逻辑，对我们的产品决策有参考意义」。
## 覆盖范围
当前追踪的竞品（按优先级）：
- 竞品 A：最直接的竞争对手，功能覆盖高度重叠
- 竞品 B：上游竞品，正在向我们的领域渗透
- 竞品 C：海外竞品，用于了解行业最佳实践
- 竞品 D / E：间接竞品，低频关注
## 页面类型
竞品主页（wiki/entities/[competitor].md）：
- 产品定位和核心价值主张
- 功能地图（持续更新）
- GTM 策略（定价、客户群、销售策略）
- 我们的差异化分析
- 时间线（所有已记录的动态按时间排列）
动态页（wiki/updates/YYYY-MM-[competitor].md）：
- 单次产品更新的详细记录
- 发布时间 + 功能描述 + 我的解读
对比页（wiki/comparisons/[topic].md）：
- 在特定维度上的多竞品横向对比
- 例：「AI 功能对比」「定价模式对比」「企业集成能力对比」
## 编译规则
每次有新的竞品动态进入 raw/，编译时必须：
1. 更新对应竞品主页的「时间线」区块
2. 判断是否影响我们的「差异化分析」，如果影响，同步更新
3. 判断是否有相关「对比页」需要更新
## 特殊规则：时间线永不删除
竞品主页的时间线区块只追加，不修改历史记录。
这是为了能看出竞品的「演进轨迹」，而不只是「当前状态」。
一个竞品主页长什么样：
Markdown
---
type: wiki-entity
entity-type: competitor
tier: 1
name: 竞品 A
updated: 2026-05-20
---# 竞品 A
## 1. 核心定位
[一句话描述：他们的核心价值主张是什么，服务什么客户]
## 2. 功能地图（持续更新）
| 功能模块 | 成熟度 | 我们的对应 | 差距判断 |
|---------|--------|-----------|---------|
| 核心工作流 | ★★★★★ | ✅ 有 | 持平 |
| AI 辅助 | ★★★ | ✅ 有 | 我们落后约 6 个月 |
| 数据分析 | ★★★★ | ❌ 无 | 我们的空白 |
| 第三方集成 | ★★★ | ✅ 有 | 持平 |
| 移动端 | ★★ | ✅ 有 | 我们领先 |
## 3. GTM 策略
- 定价：[当前定价信息]
- 主要客户群：[他们在打哪类客户]
- 核心销售策略：[他们怎么卖]
## 4. 我们的差异化判断
[基于以上信息，我们当前的核心差异化在哪里，
哪里是我们的优势，哪里是我们需要警惕的]
> [!warning] 当前最大风险
> [一句话说明竞品对我们最大的威胁是什么]
## 5. 动态时间线
| 日期 | 事件 | 重要程度 | 我的解读 | 详情链接 |
|------|------|---------|---------|---------|
| 2026-05-15 | 发布企业版 SSO | ★★★ | 开始发力大企业，我们需要加速这块 | [[2026-05-update-sso]] |
| 2026-04-02 | 调整定价，降低起步价格 | ★★★★ | 在抢中小企业市场，我们的下沉策略需要重新评估 | [[2026-04-pricing-change]] |
| 2026-02-18 | 发布 AI 写作助手 | ★★★ | 这个方向我们 Q3 也会做，提前看他们的版本 | [[2026-02-ai-writing]] |
| 2025-11-10 | 完成 B 轮融资 | ★★ | 有更多资源加速，接下来 6 个月会有更多动作 | [[2025-11-funding]] |
让系统「喂养」竞品 Wiki 的方式：
小林的做法是：建立一个「竞品信息收集习惯」。
每天早晨花 10 分钟，扫一遍：
竞品的官方更新博客（RSS 订阅） G2/Capterra 上的新评论 竞品员工在 LinkedIn 上的动态 相关行业社群里的讨论
遇到值得记录的内容：
直接扔进 00-Inbox/写一两句话：「竞品 A 今天发布了 XXX，我的判断是……」
每周运行一次 /wiki-compile competitors，把本周积累的竞品动态编译进 Wiki。
专属 Skill：/competitor-scan
为了让竞品情报追踪更系统化，小林自己写了一个额外的 Skill：
Markdown
# Skill: /competitor-scan — 竞品情报周报生成## 触发方式
用户输入 /competitor-scan
建议频率：每周一次
## 工作目标
基于过去一周进入 competitors/ 子库的所有新动态，
生成一份「本周竞品动态总结」，帮助产品负责人快速掌握竞争态势变化。
## 执行步骤
### Step 1：扫描本周更新
读取 wiki/log.md，找出本周（过去 7 天）所有编译记录。
列出涉及的竞品和变更内容。
### Step 2：判断重要程度
对每条竞品动态，判断：
- 这个变化，对我们的产品策略有影响吗？
- 如果有，影响的是哪个维度（功能、定价、客户群、渠道）？
### Step 3：生成报告
输出格式：
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔍 本周竞品情报简报 ━━━━━━━━━━━━━━━━━━━━━━━━━━━
本周动态数：[N] 条（涉及 [N] 个竞品）
⚡ 需要立刻关注（影响当前季度决策）： → [竞品名] [动态描述] — 影响：[一句话说明对我们的影响]
📋 值得追踪（中期参考）： → [竞品名] [动态描述]
📌 备案留存（暂时无直接影响）： → [竞品名] [动态描述]
差异化分析变化： [如果本周有任何竞品动态改变了差异化格局，说明]
建议下周关注： [基于本周动态，下周需要主动收集哪类信息]
━━━━━━━━━━━━━━━━━━━━━━━━━━━
同时把报告追加到 AI-Log/ 本周目录。
这份周报，每周一出现在小林的 Obsidian 里，是他周一早会之前最重要的「准备材料」之一。
Wiki 子库二：用研洞察（user-research）
用研数据对产品经理来说，是一种很特殊的知识：
它既不是「可以永久有效的方法论」，也不是「完成就废弃的任务」。
它是「在一段时间内有效的、关于特定用户群体的认知」。
这意味着：
半年前的用研结论，今天可能已经不再成立（用户在变化） 但「用研方法」和「用户群体的深层需求」，可能具有更长的生命周期
user-research/CLAUDE.md 的核心设计：
Markdown
# Wiki 子库：user-research（用研洞察）## 定位
沉淀用户研究的核心洞察，让每一次用研都产生超越「当次报告」的累积价值。
## 覆盖范围
- 用户访谈记录和分析
- 可用性测试发现
- 问卷/NPS 数据洞察
- 客服反馈的系统性分析
- 用户行为数据的解读
- 竞品用户的反馈（来自公开渠道）
## 不覆盖
- 原始访谈录音/视频（存在 raw/recordings/ 不编译）
- 问卷的原始数据表格（存在 raw/data/ 不编译）
- 单个用户反馈（除非有代表性，否则不创建单独页面）
## 页面类型
**用户洞察页**（wiki/insights/[topic].md）：
针对某个问题维度的跨研究综合洞察
例：「企业用户的核心痛点」「用户对 AI 功能的接受度」
**研究摘要页**（wiki/studies/[YYYY-MM-study-name].md）：
单次用研的结构化摘要
包含：研究目的、样本描述、核心发现、行动建议
**用户画像页**（wiki/personas/[persona-name].md）：
基于多次研究综合的用户类型描述
不是一次研究出来的，是随多次研究持续迭代的
## 特殊规则：时效性标注
所有用研洞察必须标注「有效截止」：
- 核心发现：标注「来自 [日期]，建议 [N 个月] 内重新验证」
- 如果后续研究推翻了某个结论，不删除原来的，而是追加「已更新」标注
## 编译规则
每次有新的用研材料进入 raw/ 时：
1. 生成研究摘要页
2. 判断这次研究是否强化、更新或推翻了已有的「用户洞察页」
3. 更新对应洞察页，标注变化和时间
4. 判断是否需要更新「用户画像页」
一个用户洞察页长什么样：
Markdown
---
type: wiki-insight
topic: 企业用户对数据导出的核心诉求
created: 2025-08-10
updated: 2026-05-15
valid-until: 2026-11（建议在此前重新验证）
confidence: high
sources:
- ../../raw/interviews/2025-08-user-interviews-batch1.md
- ../../raw/interviews/2026-01-enterprise-deep-dive.md
- ../../raw/feedback/2026-05-nps-comments-analysis.md
---# 企业用户对数据导出的核心诉求
## 核心洞察（综合三次研究）
企业用户对「数据导出」的诉求远比产品团队最初理解的更复杂。
**表层诉求**（用户说出来的）：
- 「能导出 Excel 就行」
- 「格式不重要，只要能拿到数据」
**深层诉求**（研究发现的）：
- 导出是为了「交给别人看」，不是「自己看」
→ 这意味着格式的「可读性」远比「完整性」重要
→ 用户不需要所有字段，需要一个「可以直接发给老板」的版本
- 导出背后是「汇报场景」，不是「数据处理场景」
→ 用户不需要原始数据，需要「已经处理好的摘要 + 少量原始支撑」
→ 这是一个完全不同的产品设计方向
## 行动影响
> [!important] 对产品设计的直接影响
> 我们当前的导出功能是「完整数据导出」，
> 但用户真正需要的是「汇报式摘要导出」。
> 这是一个产品方向的判断错误，不只是功能细节问题。
## 更新历史
| 日期 | 更新内容 | 来源 |
|------|---------|------|
| 2025-08-10 | 初始洞察建立，来自 5 个企业用户访谈 | 2025-08-batch1 |
| 2026-01-15 | 深度访谈 8 个大企业用户，强化了「汇报场景」这个判断 | 2026-01-enterprise |
| 2026-05-15 | NPS 评论分析发现 23% 的负面评论提到导出功能，验证了这个问题的严重性 | 2026-05-nps |
## 待验证的问题
- 不同规模企业（50人以下 vs 500人以上）对这个需求是否有差异？
- 「汇报对象」是什么角色？是否影响格式偏好？
用研 Wiki 对小林最大的帮助是什么？
他告诉我这样一件事：
有一次，研发团队在讨论「要不要花两周时间优化导出功能的 UI」。
他打开了 user-research/wiki/insights/企业用户对数据导出的核心诉求.md，把这个页面放在屏幕上，说：
「根据我们过去三次用研的综合结论，用户对导出功能的诉求不是『更好看的 UI』， 而是一个完全不同的功能形态——『汇报式摘要导出』。
所以我建议我们不优化现有功能，而是重新立一个『汇报模式』的新需求。」
然后他说：
「以前，我也知道这个结论，但我说不出来那么清晰。 因为这个洞察分散在三次不同的用研报告里，我记得大意，但我说不出具体依据。 有了这个 Wiki 页面，我可以直接给研发看：你看，三次研究的原始结论， 这里都有，不是我的感觉，是有记录的推断。」
这就是用研 Wiki 的核心价值：让你的判断从「直觉」变成「有迹可循的推断」。
Wiki 子库三：产品方法论（product-methods）
这是三个子库里「最接近传统 LLM-Wiki」的一个。
它的内容是长期有效的、领域通用的产品方法论知识：
各种产品框架（JTBD、MVP、OKR、Double Diamond……） 产品经典书的书摘（《Inspired》《产品方法论》《增长黑客》……） 优秀产品经理的方法论文章 小林自己在实践中总结的「个人方法论」
这个子库的设计和标准的 LLM-Wiki 基本一致，没有太多特殊之处。
唯一值得强调的一点是：
「个人方法论」的特殊处理。
小林在实践中，会不断形成自己的「产品判断」——
「我判断需求优先级的标准」 「我在评审设计稿时的检查清单」 「我判断一个功能是否值得做的决策框架」
这些不是从任何书或文章里来的，是他自己的经验积累。
他把这类内容放在 product-methods/raw/personal/ 目录下，标注来源为 personal-experience，置信度设置为 medium（因为是个人经验，不是普遍规律）。
编译后的页面，他会格外仔细地审阅，因为这些是真正属于他的知识资产。
三、四个项目，怎么用 PARA 管理
三个 Wiki 子库是「知识层」，四个产品线是「项目层」。
两者分开，各司其职。
每个项目的文件夹结构：
text
01-Projects/
└── core-product/
├── README.md ← 项目定义（目标、阶段、团队）
├── tasks.md ← 当前任务清单
├── log.md ← 进展追加日志
├── decisions/ ← 关键决策记录
│ ├── 2026-05-15-export-feature-direction.md
│ └── 2026-04-02-pricing-tier-change.md
└── refs/ ← 项目相关参考（链接到 Wiki，不复制）
decisions/ 目录是小林特别设计的。
每个重要的产品决策，他都会记录一个「决策日志」，格式很简单：
Markdown
---
type: decision
date: 2026-05-15
project: core-product
status: decided
---# 决策：导出功能方向
## 背景
[一段话说明决策背景]
## 选项
**选项 A**：优化现有导出 UI（工期 2 周）
- 优点：快，风险低
- 缺点：没有解决根本问题（见用研洞察）
**选项 B**：新建「汇报模式」导出（工期 6 周）
- 优点：解决了用户真正的痛点
- 缺点：工期长，需要重新设计
## 我的决定
选 B。
## 理由
基于三次用研的综合洞察（见 [[03-Resources/user-research/wiki/insights/企业用户对数据导出的核心诉求]]），
用户的核心诉求是「汇报式摘要导出」，不是「UI 更好看的导出」。
优化 UI 是在错误的方向上优化。
## 结果追踪
[等上线后填写：这个决定对不对，数据怎么说]
为什么要记录决策日志？
小林说过这样一段话，我觉得很有道理：
「产品经理最大的成长，不是学了多少方法论，而是能不能在事后诚实地回看自己的判断—— 我当时基于什么做了这个决定？这个判断后来对了还是错了？ 如果错了，是我判断错了，还是外部变量变了？
大多数 PM 都没有这个记录，所以他们对自己的判断质量完全没有感知。 他们只记得结果，不记得逻辑，所以他们很难从失败里学到真正的东西。」
决策日志 + 结果追踪，是产品经理的「判断能力复利」工具。
四、一周工作流：系统真正跑起来的样子
光讲结构不够，还要看它在真实工作日里是什么感觉。
我让小林描述了他的典型工作周，下面是还原。
周一：开启新的一周
08:30，上班路上
刷到竞品 A 发布了一个新功能，截图，用 iOS Shortcut 发到 Inbox。 顺带写了一行备注：「这个方向我们 Q2 说要做，但他们先做了，质量怎么样？」
09:00，坐下来，运行 /daily-open
日记打开，看到：
今日任务：4 条（包括一条上周遗留的「Q2 路线图对齐会」） Inbox 待处理：7 个文件（昨天没有处理，周末积累了一些）
09:05，运行 /triage
7 个文件被分拣：
那条竞品动态：进 competitors/raw/两篇产品文章：进 product-methods/raw/articles/两个客户反馈截图：进 user-research/raw/feedback/一个任务提醒：进今日任务 一条自己昨天的想法：进 Fleeting Ideas
09:15，运行 /competitor-scan
看到上周的竞品周报。
竞品 A 在「数据分析」方向有两个新动作，和他们当前的弱势功能重叠。
小林在周记的「本周需要关注」里加了一条：「竞品 A 在数据分析上在发力，需要评估我们的优先级」。
09:30，开始真正的工作
周三：用研内容进来了
客服整理了一批本月的用户反馈，发给了小林。
小林扫了一遍，觉得有一个反复出现的主题值得深挖：「用户抱怨功能 X 的学习成本太高」。
他把这批反馈文档放进 user-research/raw/feedback/，然后给它加了一条备注：
「重点关注「学习成本」这个主题，编译时看看这是否和之前的用研结论有关联。」
运行 /wiki-compile user-research。
编译报告出来：
「在现有的用户洞察页中，找到了相关内容： wiki/insights/新用户激活路径问题.md 本次反馈强化了该页面的第三条洞察，已追加更新。 同时发现了一个新主题「功能学习成本」，已创建新的洞察候选页。」
小林打开那个新创建的洞察候选页，发现它里面已经有了：
来自这批反馈的核心发现 和现有洞察的关联分析 一个 [!note]：「此洞察目前只有一次来源，需要至少一次正式用研验证后才能作为产品决策依据」
他在日记的工作日志里写了一行：
「功能 X 学习成本问题，可能是下次用研的核心议题。」
周五：写 PRD 的时候
小林需要给「汇报模式导出」写 PRD 初稿。
他没有打开谷歌，没有翻旧文档，而是打开 Claude Code，说：
「帮我梳理一下写『汇报模式导出』PRD 需要的背景知识：
用研洞察里关于这个功能的核心结论 竞品 Wiki 里，竞品们在导出功能上的现状 我在 product-methods Wiki 里有没有关于『汇报场景产品设计』的相关方法论」
AI 扫描三个 Wiki，给出一份「PRD 背景摘要」：
text
━━━━━━━━━━━━━━━━━━━━━━━
PRD 背景摘要：汇报模式导出
━━━━━━━━━━━━━━━━━━━━━━━用研洞察（来自 user-research Wiki）：
核心结论：企业用户的导出诉求是「汇报场景」，
不是「数据处理场景」。用户需要「可以直接发给老板的版本」。
来源：3 次研究，置信度：high
见：[[企业用户对数据导出的核心诉求]]
竞品现状（来自 competitors Wiki）：
竞品 A：标准导出 + 模板导出，无汇报模式
竞品 B：有「PDF 报告」功能，但用户评价一般
竞品 C（海外）：有完整的汇报模式，是目前最佳实践参考
见：[[竞品 A]] [[竞品 C]]
方法论参考（来自 product-methods Wiki）：
在「汇报场景」相关内容里，找到了：
- 「Jobs to be Done：用户雇佣产品来完成什么工作」框架
- 建议参考：[[JTBD-框架]] [[竞品C-export-case-study]]
━━━━━━━━━━━━━━━━━━━━━━━
小林拿着这份背景摘要，开始写 PRD。
他说：
「以前写 PRD 的背景部分，我要花一两个小时翻旧材料。 现在这个摘要 10 秒就出来了，而且因为有来源，我在 PRD 里引用的时候不是在「讲故事」， 是在引用有记录的研究结论。这让我在评审会上更有底气。」
周日：每周回顾
运行 /weekly-review。
机器轨道的内容自动填充：
本周任务完成率 78% Wiki 更新：competitors 3 条动态，user-research 1 个新洞察候选，product-methods 2 篇文章 本周进入 Inbox 总数：23 个，全部已处理 项目 B（AI 功能模块）本周计划任务完成 0/3 ⚠️
然后小林开始填写人类轨道的「本周反思」：
这一周，最重要的完成是什么？
「把用研结论转化成了产品决策，并且写出了有依据的 PRD 初稿。 这件事让我感觉到系统的价值——不是工具变了，是我做事情的方式变了。」
项目 B 本周零进展，真实原因是什么？
「老实说：我对 AI 功能模块的技术可行性还没有想清楚， 我在等技术同学给我方案，但我知道这不对——我应该主动和他们对齐， 而不是被动等待。下周要主动约一次技术探讨。」
五、六个月后，这套系统改变了什么
小林用了大概六个月，到今天，他的三个 Wiki 子库的规模是：
competitors/：5 个竞品主页，约 40 条动态记录，6 个对比页user-research/：12 个研究摘要页，7 个用户洞察页，3 个用户画像页product-methods/：约 60 个概念页，20 个实体页，8 个「个人方法论」页
但规模不是最重要的变化。
他说，真正变化的有三件事：
变化一：从「感觉」到「推断」
以前，他很多产品判断是「我感觉用户需要这个」「我感觉这个方向是对的」。
现在，同样的判断变成了：
「基于两次用研的结论（见 洞察页），加上本季度的 NPS 评论分析，我判断……」
不是他变得更厉害了，是他的判断有了「可以被追溯的依据」。
这让他在评审会上说话更有分量，也让他在复盘时能更诚实地检验自己的判断质量。
变化二：竞品追踪从「快照」到「演进」
以前，他了解竞品是「当前时刻的静态快照」。
现在，他能看到竞品过去一年的「演进轨迹」——
「竞品 A 从六个月前开始，持续在『数据分析』方向发力， 每隔两个月就有一个新动作。这不是偶然，这是他们的战略方向。 对我们的影响是：我们在这个维度已经落后了，需要决定是否跟进。」
这种「看趋势」的能力，在竞品 Wiki 积累到一定深度之前是不可能有的。
变化三：新人接手的速度大幅提升
小林公司来了一个新 PM，他们用了两小时，带着新同学浏览了三个 Wiki 子库。
新同学说：
「这两小时，我对这个行业的竞争格局、用户核心诉求、产品方法论， 的了解程度，超过了我原本估计要花两周才能了解的东西。」
一个团队的 Wiki，是一种知识传承机制。
它让「新人快速上手」的成本，从「跟着老人转几个月」，变成「花一天认真读 Wiki」。
六、给产品经理的「最小起步」建议
如果你是产品经理，看完这篇，你可能有两种反应：
一种是：「太复杂了，我哪有时间搭这个。」
另一种是：「听起来很有价值，但我不知道从哪里开始。」
如果你是第二种，我给你一个「最小起步版」：
第一步：只建一个 Wiki 子库
选一个你最痛的信息混乱点：
竞品信息最混乱？先建 competitors/用研结论总是记不住？先建 user-research/方法论知识总是散的？先建 product-methods/
只建一个，先跑通，再扩展。
第二步：建一个「决策日志」文件夹
不需要任何技术配置，只需要在你现有的笔记系统里建一个文件夹，叫 decisions/。
每次做了一个重要的产品决策，花 10 分钟，写下来：
我当时的选项是什么 我选了什么 我基于的最重要的理由是什么
三个月后回头看，你会发现那些「基于什么」的质量在提升。
第三步：建立「用研洞察」的最简版本
每次做完用研，不只是存报告。
花额外 30 分钟，提炼出 3 条「核心洞察」，写成一个单独的文件。
不需要格式，不需要 AI，只需要用自己的语言把「这次用研告诉了我什么」说清楚。
这三步，不需要 Obsidian，不需要 Claude Code，不需要任何技术。
它们只需要你改变一个认知：
你的工作信息，是一种资产，值得被认真管理，而不只是「用完就扔」。
当你有了这个认知，后面的工具配置就是顺理成章的事了。
我是一只阿木木 | AI数字大脑实践者
扫码加入行动营👇 获取更多Obsidian + AI数字大脑方法论