YUHAN · AI Product Manager

前提：你读过心法篇，认同三层协作——化石层留痕迹、时间层让思考流动、意图层守方向。你也读过路径篇，知道信号怎么升级为决策、四个场景怎么跑。现在你决定搭一套具体的系统。这篇文章回答的问题是：怎么选工具、怎么配规则、怎么让它跑起来。

一个提醒：这篇文章讲的是我的配置，不是"最佳实践"。基于下面要讲的选择标准，经过半年迭代，目前稳定下来的方案。如果你用别的工具组合也能满足同样的标准，完全没问题。方法论不绑定工具。

选工具的三个标准

在看具体工具之前，先建立判断标准。否则你会陷入功能对比的泥潭——每个工具都有独特的优点，每个社区都在说"我们最好"。
标准一：它知道自己只做一层的事吗？
最好的工具是不试图包打天下的。
笔记工具好好做笔记，不要假装能替你思考。AI 好好做对话，不要假装能替你判断。一个工具越是试图覆盖所有层级，每一层都做得平庸。
这个问题的根源不是某个工具做得不好。是 All-in-One 的设计哲学跟三层模型根本冲突——它假设一个工具能同时冻结时间、让时间流动、还给时间方向。心法篇论证过：这三件事不可能在同一个空间里同时做好。
标准二：层与层之间有清晰的边界吗？
信息在哪采集、在哪加工、在哪沉淀——应该一目了然。不存在灰色地带。
如果两个工具的功能重叠，你会不断犹豫"这个该在哪里做"。犹豫本身就是摩擦。而摩擦是系统死亡的第一原因。
标准三：操作的摩擦够低吗——对人和对 AI 都算？
知识工夫的重点是思考，不是维护工具。
对人来说：采集不超过两秒，归档不需要手动分类，沉淀不需要手动搬运。如果一个系统需要你每天花二十分钟维护——整理标签、归档笔记、同步状态——它不会活过三个月。所有需要"坚持"的系统都会失败。活的系统是那些你几乎感觉不到它在运行的。
但在一个"你只做判断，AI 做其余"的体系里，人的操作成本之所以能低到这个程度，是因为大量体力活被 AI 接管了。这就引出同一个标准的另一面：AI 能不能碰到你的工具？
如果你的采集工具只有一个 app 界面，AI 没法帮你筛选书签——你得自己打开 app，一条条翻，一条条判断。如果你的笔记工具没有 API，AI 没法帮你创建记录——你得自己复制粘贴，手动填属性。每多一个"需要人类手动切换"的环节，系统的运转成本就上升一级，AI 从"协作者"退化为"建议者"。
具体来说，看一个工具有没有 CLI 或 API。CLI 意味着 AI 可以在对话过程中直接操作它——读取、写入、搜索、修改，不需要你在中间当搬运工。这是我选 Cubox、Anytype 和 Claude Code 的一个重要原因：它们都支持 CLI 或 API。三个工具之间，信息可以自动流转，不需要人在中间传话。
反过来说，如果一个工具功能再强、设计再好，但只能通过 GUI 操作，它在这个体系里就会成为瓶颈——所有经过它的信息都需要人类手动搬运。你的系统不会比最弱的那个接口更自动化。

每一层跟时间的关系

这三个标准背后有一个更深的判断逻辑：你选的不是工具的功能，是每个层级跟时间的关系。
化石层要冻结时间。越稳定越好，越不变化越好。它跟时间的关系是：停住。所以化石层的工具要可靠，不要灵活。
时间层要让时间流动。承载思考逐步展开的过程——追问、反驳、转身、推进。它跟时间的关系是：往前走。所以时间层的工具要能推进，不要能存储。
意图层要给时间方向。从所有可能的路径中砍掉大部分，只留一条。它跟时间的关系是：只往一个方向。意图发生在你身上，但意图的痕迹留在化石里——以日志的形式，记下当时的情境、你做的决定、以及你为什么这么做。
一个工具好不好，不是看它能做什么。看它跟时间的关系对不对。

我的配置

采集入口：Cubox

采集是化石层的入口。信息不会自己走进来，你需要一个采集机制。
采集机制的核心要求：两秒以内，不跳转，不判断。
在中文互联网里，这不是一个容易解决的问题。你读的内容散在围墙花园里：微信公众号、小红书、即刻、抖音。大多数书签工具跨不过这些墙。你在微信里看到一篇好文章，想存到 Pocket——复制链接，切到 app，粘贴，等它识别。三步之后你已经忘了自己刚才在想什么了。
Cubox 解决的就是这件事。浏览器扩展一键收藏网页。微信里转发给 Cubox 机器人，直接剪藏公众号文章。小红书帖子，把链接发到企业微信里的机器人，秒存。不需要跳转 app，不需要填任何东西。
更关键的是：它有 CLI——一个给 AI 用的命令行接口。AI 可以在任何时候调用你的阅读库——搜索、筛选、提取、跨工具分发。你从"主动去翻收藏"变成"收藏自动来服务你"。
这一层的可替换性最高。如果你不在中文互联网环境里，Raindrop、Pocket、Instapaper 都可以——哪个的采集路径最短就选哪个。但别忘了标准三的另一面：如果替代品没有 CLI 或 API，AI 就没法帮你批量筛选和处理，你得自己打开 app 一条条翻。核心标准不变：两秒以内，不跳转，不判断，AI 能碰到。
我做过一件事值得提：把所有 app 里的自带收藏全删了——微信收藏、浏览器书签、Twitter 书签、小红书收藏——统一收进 Cubox。一个入口。从此不用再想"该存哪"。
这个「一个入口」后来长出了一个自动化上游。我在 Armbian 小主机上跑了一个 Hermes Agent，每天早上六点扫描 26 个 RSS 源，AI 做第一轮筛选——噪音直接丢掉，值得读的自动存进 Cubox，同时给我微信推一份简报。我只看简报决定哪些要深读，其余的在 Cubox 里等着被场景一消化。采集层从「全靠手动收藏」变成了「手动收藏 + AI 自动喂入」，但 Cubox 作为统一入口没变。下游的 Claude Code 和 Anytype 完全感知不到上游的变化——这正是层级分离的好处。

化石层：Anytype

选择理由：数据在你手里，且足够结构化。
Anytype 是本地优先的。数据存在你的设备上，通过 P2P 同步。不依赖任何公司的服务器。即使 Anytype 这个公司明天消失，你的数据还在你的硬盘上。
它支持自定义类型、属性和关系——意味着你可以用认知阶段（信号→线索→锚点→决策）来组织信息，而不是用文件夹或标签。你不是在"分类"，你是在标记一段知识走到了哪一步。
关于其他选项的诚实判断：Notion 功能强大但数据在云端，且 All-in-One 设计会诱惑你在同一个工具里混合采集、沉淀和思考。Obsidian 灵活到几乎无限，但无限本身就是问题——你会花太多时间在"怎么组织"上。另一个容易被忽略的维度是编程接口：Notion 有 API，Obsidian 可以通过文件系统直接读写 Markdown，Anytype 有 REST API 和 CLI——它们都能让 AI 操作，只是方式不同。这些都是真实的权衡，但我不会假装它们是决定性的缺陷。Anytype 自己也有问题：生态小、插件少、学习曲线陡。我选它有个人偏好的成分——我愿意为数据主权和结构化能力付出生态代价。你如果更在意生态和社区，Obsidian 也能跑通整个体系。
关键不是具体选哪个，是你选的化石层工具要满足几个底线：数据可靠、结构化足够、操作成本低、有 API 或 CLI 让 AI 能直接操作。

时间层：Claude Code

很多人把 AI 当"更快的搜索引擎"或"更好的摘要器"。那是把 AI 放在了化石层——让它帮你整理已有信息。心法篇说过，这不是 AI 最有价值的位置。
AI 最有价值的位置是进入时间层。
Claude Code 不只是一个聊天窗口。它是一个能动手的对话伙伴。它能读你的化石（Anytype 里的笔记），帮你恢复当时的问题现场。它能指出旧判断里的矛盾。它能把散乱材料排列成几条可能路径。它模拟反方。它追问。
你和它的对话天然具备时间层的特征：逐步展开，不可逆，有上下文，有推进感。好的对话会让你觉得"我想清楚了一点"，而不是"我收到了更多信息"。
为什么是 Claude Code？两个具体原因。第一，它能直接操作你的工具——读 Cubox、写 Anytype、执行命令。对话中产生的判断可以直接沉淀到化石层，不需要你手动搬运。第二，它有持久记忆。通过一个每次对话自动加载的配置文件（CLAUDE.md）和按需加载的 skill 系统，它能跨对话记住你是谁、你怎么工作、你的项目状态。

资料系统：OneDrive + PARA

路径篇第五条规则说过：思考的和存放的不要混在一起。
Anytype 只存你想过的东西——你的判断、假设、决策、推演。PDF、图片、设计文件、归档文档放在另一个地方：OneDrive 本地文件夹，用 PARA 方法组织。

总库/
├── 00-Inbox/          ← 不知道放哪的东西
├── 01-Projects/       ← 有明确目标和截止日期的
├── 02-Areas/          ← 持续维护的领域
├── 03-Resources/      ← 兴趣和学习资源
└── 04-Archives/       ← 不再活跃但保留的

PARA 不是按主题分的。它按你跟这个东西的关系分。一个 Blender 教程，如果你正在学 Blender 做一个具体项目，放 Projects。如果学 Blender 是长期兴趣但没有具体项目，放 Resources。学完了不打算再碰，放 Archives。同一个东西可以在不同阶段出现在不同位置。不要纠结"这个东西应该属于哪个主题"，要问"我现在跟它是什么关系"。
两个系统之间的桥梁是链接。在 Anytype 里引用 OneDrive 的文件，用 file:// 链接。点击直接跳转，不需要记住文件放在哪。
一条"不做什么"的规则：不是所有资料都需要在 Anytype 有一条对应记录。只有当一份资料触发了你的思考——你对它产生了判断、假设、或者把它和你知道的东西连起来了——才值得在 Anytype 建一条索引。大部分资料只是存着以备将来。不需要你的思考系统给每份资料发一张身份证。

系统配置

工具选好了。怎么让它们各归其位、互相配合？

Type 体系：每种思考有自己的形状

很多人的知识系统只有一个类型：笔记。所有东西都是笔记。三个月后你打开一条记录，不知道它是一个想法、一个决定、一个项目还是一段随手记。
我用五种 Type，每种对应一种认知动作：

Type	存什么	对应的认知动作	走认知阶段？
Page	对外部内容的判断	"我在判断"	是（信号→线索→锚点）
Thought	写给自己的随笔、感悟	"我在感受"	否
Journal	做了什么决定	"我决定了"	是（决策）
Project	有目标、有进度的事	"我在做"	否（用项目状态代替）
Domain	主题集合	"我在组织"	否

Page 是默认载体。不确定用什么 Type，用 Page。
Thought 不走认知阶段，不走升级流程。它是纯粹的私人空间——人生感悟、情绪反应、不需要被结构化的思考。
Journal 记录决策。不是记"今天做了什么"，是记"在什么情境下做了什么决定、为什么"。三个月后回头看，你能校准自己的判断力。
Project 用项目自身的状态（进行中/暂停/完成）而不是认知阶段来追踪。但项目中的关键判断应该作为单独的 Page 或 Journal 存在，挂到 Project 下面。
不要创建太多 Type。五个足够。如果两个 Type 的区别只是标签不同而不是认知动作不同，合并它们。

认知阶段的属性设计

认知阶段是整个系统的关键属性。心法篇和路径篇定义过它的含义，这里讲它在工具里怎么实现。
每条 Page 有一个 Select 属性叫"认知阶段"，四个选项：信号、线索、锚点、决策。
不同阶段的 Page 可以按需添加不同属性：
线索阶段需要的：

核心问题 — 你在追什么
当前假设 — 你现在怎么看的
状态 — 探索中 / 收敛中 / 已结题

锚点阶段需要的：

命题 — 你的核心判断
为什么信 — 判断的来源和推演过程
边界条件 — 什么前提下你信这个，什么条件下不信

这些属性不需要一开始就全部填满。信号阶段只需要标题和原始链接。随着认知推进，属性自然变丰富。只定义你真正会回头看的字段。多一个属性就多一个"要不要填"的犹豫。犹豫就是摩擦。

AI 的角色

整个系统的运转离不开 AI。但 AI 的角色需要分清楚。
AI 做的事：读完书签全文、判断分级、创建 Anytype 对象、设置属性、建立关联、归档已处理内容、提醒你审视。
你做的事：看一眼 AI 的判断结果，说"对"、"这条改成线索"、"这条不要了"。然后在推演中做判断——这是你唯一不可外包的认知动作。
一个容易犯的错：让 AI "总结这篇文章的要点"，然后把总结存为笔记。这不是思考，是压缩。AI 帮你把 3000 字压缩成 300 字，信息密度变高了，但你的认知没有前进——你依然不知道这篇文章跟你的什么问题有关、你同意还是不同意、它改变了你的什么假设。正确的做法是：AI 读完后，你判断它属于哪个认知阶段、跟你当前在想的事有没有关联。注意区分：路径篇里 AI 帮你做的"分级"是判断"这条信息对我意味着什么"——是信号还是线索、跟我在想的事有没有关系；这里说的"总结"是压缩"这条信息说了什么"——内容变短了，但你和它的关系没有建立。前者推动认知前进，后者只是节省阅读时间。不是"这篇文章说了什么"，而是"这篇文章对我意味着什么"。
AI 最高效的用法不是当秘书，是进入时间层：拿你的旧判断去碰撞新材料，在你的思考路径上制造阻力、分岔和转向。阻力才是思考发生的地方。摘要不是。

三个最常见的坑

系统跑了大半年，踩过三个坑。提前说，省得你踩。
坑一：在化石层过度设计。
刚开始用的时候，你会忍不住定义很多类型、很多属性、很多关系。觉得"以后可能会用到"。不会用到。化石层的唯一标准是"下次打开能不能快速重新激活"。只定义你真正会在对话中引用的字段。
坑二：跳过时间层，直接从信号到锚点。
读完一篇文章，觉得自己"想清楚了"，直接创建一个锚点。大概率没有想清楚。你只是被文章的修辞说服了。锚点必须经过推演——跟 AI 对话，或者自己写出来，或者找一个反例试一下。没有经过时间层的锚点，只是换了称呼的收藏。
坑三：把 AI 当秘书而不是对话者。
"帮我总结""帮我整理""帮我归档"——这些是秘书活。AI 能做，但这是对它最低效的用法。最高效的用法是让它在你的思考路径上制造阻力：拿你的旧判断去碰撞新材料，模拟反方，追问你的假设。如果你跟 AI 的对话从来没有让你觉得"我好像想错了"，那你还没有真正用过它。

最后

这篇文章讲的不是"最好的配置"。它讲的是"一套足够简单的配置"。
足够简单的意思是：你能记住它，你能在不想用的时候也用它，你能在发现不对的时候改它。
配置不是一次性的事。它会在使用中被验证、被修正、被简化。如果你发现某条规则连续两周没有被自然地遵循，不是你不自律，是这条规则不对。改它。
系统是为人服务的。当人开始为系统服务的时候，系统就该重配了。

给 AI 一个大脑

前面讲了选什么工具、怎么配。还差一样东西：你的 AI 怎么知道你是谁、你想怎么工作？
开箱即用的 AI 不知道你用 Cubox 收藏文章、用 Anytype 存笔记、用认知阶段标记知识。每次对话都要从零解释，跟每次见新同事都要自我介绍一样低效。
解决方法是给 AI 写一份配置文件。Claude Code 的配置文件叫 CLAUDE.md，放在你的 home 目录下，每次对话自动加载。它不是一个需要维护的文档——它是一张一次性写好、持续生效的"身份卡"。
最小有效结构只需要三样东西：
你是谁。背景、角色、认知风格。让 AI 知道该用多深的技术解释、什么领域的知识可以假设你已经知道。
你怎么协作。语言偏好、回复风格、结论先行的要求。让 AI 的输出格式匹配你的阅读习惯，而不是每次都要求它"简短一点"或"说中文"。
你的系统规则。你用什么工具、信息怎么流转、你做判断 AI 做其余。这是最重要的一段——它把心法篇的三层协作和路径篇的五条规则压缩成 AI 能直接执行的指令。
操作手册层面的东西——工具的具体命令、API 的调用方式、属性的 ID 编号——不要写进配置文件。这些放在 skill 文件里（~/.claude/skills/），按需加载，不会每次都占上下文。配置文件只放 AI 无法从对话中推断的东西。
配置不是一次写好就结束的。它会在使用中被验证——如果 AI 连续两次做了你不想要的事，不是它蠢，是你没有告诉它你的偏好。改配置，不要每次口头纠正。
这一个设计选择的意义很容易被低估：它把"每次对话都要重新建立共识"变成"共识自动生效、偏差持续修正"。你的 AI 不再是一个每次从零开始的聊天伙伴，而是一个越来越懂你的协作者。

附录：如果你想搭一套

这一节是给想动手搭建的人的技术参考。如果你只是想理解知识工夫，你不需要装任何工具。你只需要记住：笔记做化石。对话让思考流动。人守住方向。工具的事，等你真的开始练工夫再说。

需要什么

一台 Mac（以下命令基于 macOS）。没有 Mac 的话，把这篇文章丢给 AI，让它基于你的操作系统帮你配——核心是方法论，不是操作系统
Cubox 账号 + 浏览器扩展
Claude Code
Anytype 桌面客户端 + anytype-cli

隐私说明：这个系统需要给 AI 访问你的全部阅读历史和笔记。你对 AI 的信任边界就是系统的边界。如果你有不能让任何第三方看到的内容，不要放进这个系统。

Cubox 配置

从 cubox.pro 注册，安装浏览器扩展
微信里搜索"Cubox 收藏助手"，关注并绑定账号，之后转发即收藏
安装 Cubox CLI——把下面这段话发给 Claude Code，它会自动完成安装和配置：

帮我安装 Cubox CLI 和 Skill：
https://github.com/OLCUBO/cubox-cli

API Key 从客户端 设置 → 扩展中心 → API 扩展 获取

日常用法：看到有价值的内容，点扩展存进去。告诉 AI 你想做什么，AI 调用 CLI 完成。

Claude Code 配置

安装——在终端运行：

curl -fsSL https://claude.ai/install.sh | bash

~/.claude/CLAUDE.md 是每次对话自动加载的配置文件。它告诉 AI 你是谁、你怎么工作。
最小有效结构：

# 你的名字 — 你的角色

## 身份
你的背景、认知风格、核心视角。

## 协作规范
语言偏好、写作风格、搜索协议。

## Life OS
系统架构图 + 黄金规则（用户只做判断，AI 做其余）。

只放 AI 无法推断的东西。工具的技术细节拆到 skill 文件里（~/.claude/skills/），按需加载，不会每次都占上下文。

Anytype 配置

从 anytype.io 下载桌面客户端，创建一个 Space
安装 anytype-cli：

/usr/bin/env bash -c "$(curl -fsSL https://raw.githubusercontent.com/anyproto/anytype-cli/HEAD/install.sh)"

启动服务并创建 bot 账号：

anytype service install && anytype service start
anytype auth create my-bot

在桌面客户端的 Space 设置里生成邀请链接，bot 加入：

anytype space join <invite-link>

创建 API Key 并存到钥匙串：

anytype auth apikey create "my-api-key"
security add-generic-password -s "anytype-cli-apikey" -a "cli" -w "YOUR_API_KEY"

API 在 http://127.0.0.1:31012 可用，与桌面客户端端口互不冲突。

API 常见坑

AI 通过 REST API 操作 Anytype。三个最常见的坑：

Space ID 必须用完整 ID（含后缀），截断会返回 500
Select 属性赋值用 select 字段，不是 value
创建 tag 选项时必须包含 color 字段

完整 API 文档见 Anytype Developer Portal。

进一步阅读

心法篇：这套系统背后的认知框架
路径篇：四个场景和五条规则
Claude Code 最佳实践
Cubox CLI 帮助页
Anytype 开发者文档