当研究反复重做、发现散落不可检索时，用研究仓库让洞察可发现…

适用于跨团队持续沉淀研究发现、避免重复研究并基于累积证据做产品决策的场景。

适用场景

解决思路

1. 设计并维护研究仓库的系统、标注约定和例行流程，使研究发现可发现、可复用，避免团队重复研究，并能基于累积证据做决策。
2. 建立三层架构中的 Insights：离散、独立的发现（如“用户不理解 X 和 Y 的区别”），是最可复用的单元。
3. 建立三层架构中的 Studies：产生 insights 的研究项目（访谈系列、可用性测试、问卷），为评估 insight 有效性提供上下文。
4. 建立三层架构中的 Raw data：transcripts、recordings、survey exports，是 insights 背后的证据，不是主要搜索目标。
5. 把仓库设计成以 insights 为主要入口，而不是以 studies 或 raw data 为主要入口。
6. 每条 insight 包含 Statement：一句清晰的话（过去时、具体）。
7. 每条 insight 包含 Confidence：High（多个研究、大样本）/ Medium（单个研究、已验证）/ Low（一次会话、早期信号）。
8. 每条 insight 包含 Method：收集方式（interview、usability test、survey、analytics）。
9. 每条 insight 包含 Date：收集时间。
10. 每条 insight 包含 Sample：谁（segment、n）。
11. 每条 insight 包含 Tags：topic、feature area、user segment、sentiment。
12. 每条 insight 包含 Source links：链接回 study 和 raw data。
13. 每条 insight 包含 Related insights：手动或自动关联。
14. 在填充仓库前先定义标签系统；标签系统是仓库最关键的设计决策。
15. 定义 Topic/theme 标签维度：navigation、onboarding、pricing、notifications、mobile、accessibility 等。
16. 定义 Feature or product area 标签维度：checkout、dashboard、settings、home feed 等。
17. 定义 User segment 标签维度：new users、power users、enterprise、mobile-only、特定 personas 等。
18. 定义 Sentiment 标签维度：pain、delight、confusion、trust 等。
19. 定义 Recency signal 标签维度：evergreen vs time-bound findings。
20. 定义 Status 标签维度：validated、superseded、conflicting。
21. 标签规则：任何人开始标注前，先定义受控词表。
22. 标签规则：标签用复数和小写，例如 `onboarding`，不要 `Onboarding` 或 `onboard`。
23. 标签规则：每条 insight 限制 5–8 个标签，防止标签膨胀。
24. 标签规则：每季度审查并调和标签。
25. 添加研究：每项研究在视为“完成”前，都要产出带标签 insights 的结构化摘要。
26. 添加研究：研究完成后一周内添加 insights。
27. 添加研究：raw data（transcripts、recordings）存储时链接到 study 记录。
28. 保持最新：每季度审查，当新证据与旧 insights 矛盾时，把过时 insights 标记为 superseded。
29. 保持最新：把新发现链接到它们强化或矛盾的 insights，建立证据链。
30. 保持最新：归档（不要删除）被取代的 insights——你曾经怎么想以及为什么的历史有价值。
31. 让仓库有用：每周或每月向团队发送 “research digest”，突出新 insights。
32. 让仓库有用：在产品 briefs、design rationale 和 PRDs 中链接仓库 insights。
33. 让仓库有用：开始新研究时先搜索仓库——已经知道什么？
34. 选择工具时按场景取舍：Notion 强在灵活结构、链接、较好搜索，弱在需要严格设置且搜索近似。
35. 选择工具时按场景取舍：Airtable 强在筛选、标注、视图，弱在不太适合叙述内容。
36. 选择工具时按场景取舍：Dovetail 为研究定制，强在标注 + transcripts，弱在成本高且团队需采用另一个工具。
37. 选择工具时按场景取舍：Confluence 与 Jira 工作流集成，弱在搜索差且难按 insight 浏览。
38. 选择工具时按场景取舍：EnjoyHQ 为研究定制，强在标注好，弱在成本高且较不常见。
39. 工具不如结构和标注约定重要：维护良好的 Notion 比维护不佳的 Dovetail 更有用。
40. 在认为仓库可用前，测试检索问题：“What do we know about why users churn?” 应返回带标签 insights，而不只是研究名称。
41. 测试检索问题：“Has anyone tested the mobile checkout?” 应返回相关 study。
42. 测试检索问题：“What did [persona] say about notifications?” 应能按 segment 和 topic 过滤。
43. 测试检索问题：“What research exists from more than 2 years ago that might be outdated?” 应能按日期过滤。
44. 最佳实践：从过去 6 个月的 insights 开始，往前倒推；不要等有全部内容才让它有用。
45. 最佳实践：指定一名 repository owner；没有具名 owner 的共享 ownership 等于没有 owner。
46. 最佳实践：把仓库纳入 onboarding——新成员第一天就应被引导到那里。
47. 最佳实践：仓库是团队资源，不只是研究团队资源——产品经理和工程师也应阅读。
48. 针对常见失败模式：不要按团队而按主题组织 findings；不要让报告长且无结构；不要让标签不一致或缺失；不要建了仓库却无人添加；不要把 insights 和 raw data 混在一起。

适用边界 · 注意事项

• 仅需综合单个研究时，不要搭完整仓库，应使用 `affinity-diagram`。
• 没有指定仓库负责人、无法坚持季度审查与日常维护，或团队不会贡献内容时，仓库会失败，不适合启动。
• 只有一次性或临时研究，不需要跨项目复用或累积证据时，不必建立仓库。