一个AI维基，怎么让产品经理告别手动整理访谈？

安德烈·卡帕西（Andrej Karpathy）开源的那个大语言模型维基工具，被一位产品经理拿去做了一件完全不同的事——结果出奇地好用。

这位产品经理的日常是什么？从客户访谈转录稿里扒金句、写用户故事、聚类成功能点、再按投入产出比排优先级。10场访谈下来，眼睛和脑子一起报废。他决定把卡帕西的工具链整个搬过来，用AI代理替代手工流程。没有数据库，没有服务器，就是纯文本加一个大模型。

三层结构：把混乱的访谈变成可导航的知识库

这套系统的核心是一个文件夹结构。最底层是raw/，扔进去原始转录稿，只进不出。中间层是wiki/，AI代理自动维护的输出——按客户拆分的引用片段、提炼后的用户故事、故事聚类出的功能点，外加一本总目录和变更日志。最上层是CLAUDE.md，定义代理怎么干活：什么值得打标签、用户故事怎么写、哪些内部发言人要过滤掉。

三层之间泾渭分明。原始数据 immutable，代理输出 disposable，规则文件 editable。跑之前改提示词，重跑时不瞎覆盖你手工调过的内容，也不重复造轮子。

这位产品经理特别提了一个功能：图谱视图。在Obsidian里打开，能从用户故事一路下钻到背后的客户原话。如果你用AI写代码，可以把这些证据当成上下文喂进去——模型理解"为什么要做这个"，比理解"做什么"重要得多。

为什么不用传统工具？

他列过手工流程的痛点：tedious and error-prone。10场访谈的跨文档检索，人脑不是为这个设计的。传统项目管理工具要么太僵（强制字段模板），要么太散（笔记和表格割裂）。这个方案取巧在：用Markdown的开放性换灵活性，用AI的批量处理能力换人力，用图谱的可视化换记忆负担。

仓库自带3份虚构访谈和预置维基（3个客户、2个故事、2个功能点），开箱就能看效果。自己的数据准备好了，往raw/一丢，跑ingest。示例文件和真实数据共存，想删随时删，不影响已有维基。

卡帕西原版的影子，产品经理的改造

卡帕西那个工具本来是用大模型管理大模型相关的知识库——论文、代码、概念互相链接。这位产品经理把同一套逻辑平移到了定性研究领域：客户声音是"论文"，用户故事是"概念"，功能点是"实现"。

关键改造在CLAUDE.md。原版可能关注技术概念的精确性，这里换成了产品语言的精确性：怎么定义一个"值得提取的引用"，用户故事要不要带场景，证据标签打哪些（痛点/频次/付费意愿？）。提示词即产品需求文档，改提示词就是改需求。

他还埋了一个细节：config.md里可以过滤内部发言人。访谈里常有自己人（销售、客户成功）插话，这些声音不该混进客户证据。手工整理时容易漏，规则文件里写死就一劳永逸。

谁还能用？

作者自己说了：customer success, customer research, or design，任何需要从定性数据里提炼主题的场景。本质是主题建模（topic modeling）的人工可控版——不丢给黑箱算法，每一步AI的产出都可见、可编辑、可追溯。

技术门槛被刻意压到极低。Claude Code或Codex就能跑，「deceptively non-technical」。不需要懂向量数据库、不需要写API、不需要部署。会扔文件进文件夹、会改Markdown、会在Obsidian里点图谱节点，就能用起来。

一个信号：AI工具链正在碎片化重组

这件事的有趣之处不在工具本身，而在它代表的趋势。卡帕西的原版是工程师给自己造的锤子，产品经理拿过来发现也能钉自己的钉子。没有等官方出"产品管理版"，没有买SaaS， fork过来改提示词就跑了。

背后是两个判断：第一，大模型的能力层正在 commoditize，真正的差异化在"怎么把能力接到我的工作流"；第二，Markdown + 本地文件 + 开源代理，这种"简陋"架构反而比All-in-one产品更抗迭代——提示词坏了改提示词，模型换了换模型，数据永远是自己的。

这位产品经理最后补了一句：如果你没用过Claude Code或Codex，他可以搭把手。工具链的民主化，有时候就差一个愿意先跑通的人。