写给同样被信息淹没、工具装了一堆却用不起来的人。这是一篇工程实操笔记，具体的目录、插件、规则、踩过的坑。至于”为什么要搭回路”这种思路层面的反思，我放在另一篇《为什么存了那么多却用不上》里，这篇不展开。

一、我想要的是一条会自己流的管道

两年前我干过一件蠢事：Obsidian 装了 40 多个插件，笔记软件换过四五个，收藏夹里躺着上千条”稍后读”。结果真正要写点东西的时候，什么都调不出来。

工具没少装，知识没少攒，但它们散落在浏览器、笔记 app、聊天记录、脑子里，谁也不认识谁。仓库膨胀到 4GB+，真正有用的产出占不到 3%，clone 一次半天。

后来我花了一段时间，搭了一套自己用得起来的”知识中枢”。这篇记的是工程层面怎么做。

我要的，是一条信息能自己流过去的管道：

输入（信息进来）
  → 处理（提炼成知识）
    → 输出（写出来、发出去）

每一环都尽量”零摩擦”，不需要我费脑去分类、整理、维护，能自动的都交给 AI。

二、输入：00.Inbox，随手扔，不分类

第一环是收集。我设了一个 00.Inbox/ 文件夹，所有信息源——网页剪藏、读后感、灵感、学习材料——都往里扔，不分类、不打标签、不想该归哪。

关键就一条：扔的摩擦要趋近于零。一旦分类需要思考，收集就被打断，信息就丢了。先扔，后整理，甚至不整理，交给下一步。

手机上随手能打开的 Inbox，电脑上随手能丢进去的剪藏，够了。别在收集环节上讲究。

三、处理：Karpathy Wiki，让知识在后台自动长出来

第二环是把信息提炼成知识。这是最该自动化的一环，靠人手动整理，永远不会做。

我用的是 Karpathy LLM Wiki 插件（基于 Andrej Karpathy 的思路）。它做三件事：

自动监听：往 Inbox 和 Project 扔材料，它后台自动监听（autoWatch）。这里有个我刻意定的规则——只监听”流动区”（Inbox + Project），不监听 Area。产出已经是知识，没必要再当原料扫一遍；还在流动的原料才需要被提炼。
自动提炼：调用 AI 把材料里的实体（人、组织、项目、概念）提取出来，生成互相链接的知识页面，沉淀到 wiki/。
自动合并：多源信息遇到同一个概念，自动合并去重。

我什么都没做，知识图谱就在后台自己长。要查的时候，打开 Query 面板，用大白话问（比如”出海有哪些支付方案？”），它基于已沉淀的页面回答。前提是先扔材料，先有料，才有得问。

四、输出：账号设定 + 三道闸 + 多语言 + 自动发布

第三环是把知识变成能发布的东西。这一环最复杂，因为我有好几个发布账号、不同定位。我做了几层规范。

账号化：每个发布账号有一份”设定文件”，定位、受众、voice、发布规则。写作时 AI 读它，自动校准风格。不用每次想”这篇该写成什么样”。

三道闸审校：写完不直接发，过三道闸（用独立 AI 子代理并行审）。闸1 查事实 + 去 AI 腔 + 校 voice；闸2 费曼测试（能否讲清）+ 真需求判断；闸3 模拟目标读者盲测（注意力曲线、转发动机）。

多语言：用脚本批量翻译，按市场优先级——重点语言精译，次要语言机翻占位。

自动发布：git push 后，GitHub Actions 自动同步到博客仓库构建发布。写完 push 就发了。

这三道闸和写作原则背后的思路，我也写在了另一篇里展开，这里只讲工程怎么串。

五、踩坑换来的几条工程教训

搭这套的过程里踩过几个坑，换回来几条教训。

工具服务于流程，不是反过来

最容易犯的错，是先看到工具再想”它能干嘛”。正确的顺序是先想清楚工作流（输入→处理→输出），再找工具填进每一环。Wiki 插件、翻译脚本、审校命令，都是为流程服务的零件。流程是主，工具是仆。

零摩擦的核心是”自动”

零摩擦的核心，是让人只做必须人做的事——扔材料、提问、拍板——中间所有能自动的都交给 AI。Wiki 自动提炼，审校自动并行，发布自动同步。凡是需要人记得去做的维护，长期都会荒废。这条我交了学费才信。

草稿绝不进发布目录

我一开始把草稿放账号文件夹（想着”反正在本地”），结果差点 push 出去自动发布。后来改成草稿放隔离的”草稿区”（不参与自动发布），定稿才移回发布目录。发布机制的逻辑是”凡目录里的就发”，所以草稿不能进目录。用隔离代替靠人记得加标记。

原料不进 git，只跟产出

我一开始把 vault 里所有东西都提交进 git，仓库膨胀到 4GB+，全是课程视频、PDF、Keynote 课件这些”原料”，真正有价值的产出只占 3%。后来定了硬规则：Inbox 整目录不提交（临时中转）；Project/Area/Resource 按类型，文本（.md/.svg）进，大文件原料（视频、PDF、图片、字体、压缩包）不进。原料留本地靠云盘同步，git 只版本化我的产出。

最妙的是，原料不进 git 完全不影响 AI 提炼。因为 wiki 插件读的是文件系统不是 git，本地放着的 PDF 照样被监听、被提炼成图谱（那些图谱是 .md，进 git）。”原料”和”由原料炼出的知识”分了家：前者留本地不胀仓库，后者进 git 可同步可检索。

分类按状态，不按主题

标准 PARA（项目/领域/资源）很容易让人纠结”这个算项目还是资源”。我简化成按状态分。东西来到 vault，只问三句：

啥状态？（放哪）没想好 → Inbox；在做、有目标 → Project；做完了、是产出 → Area；备查不动 → Resource。
是产出吗？（进不进 git）Inbox 整目录不提交；其余按类型，文本进、大文件不进。
还在流动吗？（wiki 提不提炼）流动 → 让 AI 监控提炼；定型 → 不监控。

一句话记住：git——Inbox 不提交，其余文本进、大文件不进；wiki——只监控流动区。

为什么按状态、不按主题？主题是给图书馆分的（一本书归”出海”还是”技术”永远能吵），而知识是流动的——同一个东西今天是项目，下周做完了就成了产出，状态一变它就搬家。这个心智一旦建立，”放哪”永远一眼清楚，分类焦虑就消失了。

六、落地清单

如果你也想搭一套，核心组件：

结构：PARA（项目/领域/资源/归档）+ Inbox（收集口）
处理：Karpathy Wiki（autoWatch 自动监听 + 提炼）
输出：账号设定文件 + 三道闸审校 + 翻译脚本 + 自动发布（GitHub Actions）
隔离：草稿区（不发布）+ 定稿区（发布目录）

日常流转：

看到材料/冒想法
  → 扔 00.Inbox（不分类）
    → Wiki 后台自动提炼（无感）
      → 要用时 Query 提问取材
        → 写作（套账号设定）
          → 三道闸审校
            → 定稿 + push（自动发布）

搭完之后，我日常只做三件事：扔、问、写。中间全自动。

七、写在最后

这套东西搭完最大的变化，是从”看到新工具就装、装完吃灰、焦虑下一个”，变成了”流程清晰、工具各就各位、我只管扔和写”。

让信息顺畅地流过输入→处理→输出的管道，才是知识工作的本质。收集更多、整理更勤，都不是。AI 让这条管道的中间环节第一次可以全自动，前提是你先想清楚流程，而不是被工具牵着走。

如果你想知道”为什么该搭回路而不是仓库”、”输出环节怎么倒逼输入”这些思路层面的东西，看这篇的另一面：《为什么存了那么多却用不上》。

关于这篇，说得直白点

这篇讲的是工具和流程。但你也看出来了，工具解决的是”怎么把知识管起来”，解决不了”为什么我总想再优化一下、总觉得还差点意思”。那是另一层的事。

我自己就做 ICF 个人教练。这篇你可以当成一个工具党写给工具党的实操，也可以当成夹带私货，我都认。如果你工具搭得挺好，但那种”还不够、还得再调”的焦虑一直没散，也许卡点不在工具层。

ICF 个人教练对话预约：

走不走、什么时候走，你定。

如何搭一套零摩擦的知识中枢【Obsidian + AI：从随手扔到自动发布，我只管扔和问】