我一直觉得 [[X]] 的 Bookmark 是个很尴尬的功能。收藏的时候特别顺手，回头找的时候却基本靠运气。我的书签列表也是这样，技术帖子、产品发布、研究分享、各种零碎灵感全都混在一起，存得越多，越像一个只能往里扔东西的抽屉。最近我频繁在用 [[Claude Code]] 和 [[Codex]]，于是对这件事更在意了：这些明明是我自己筛过一遍的信息，能不能别只躺在网页里，而是真正进到本地工作流里。
我看到 [[Field Theory CLI]] 的第一反应，就是这东西抓的点很准。它不是再造一个书签页面，也不是给收藏夹换一套花哨 UI，而是干脆把 X 的书签拉到本地文件和本地数据库里，再把搜索、分类、统计、Markdown 导出、知识库整理这些动作全接到命令行上。思路很直接，但就是这份直接让我觉得它靠谱。因为一旦书签进了本地，它就不再只是网页侧栏里那串几乎不会点开的历史记录了。
项目仓库在 https://github.com/afar1/fieldtheory-cli，官方页面在 https://www.fieldtheory.dev/cli/。如果你平时确实会在 X 上攒很多技术链接、开源项目、研究论文或者长贴，这个项目大概率会让你有点共鸣。
它解决的不是同步问题，而是书签失活问题
[[Field Theory CLI]] 最打动我的一点，是它对收藏夹这件事情的判断很现实。我使用这个项目之后，才发现我从开始使用 X 以来已经收藏了超过 9000 条内容，而这些内容之前一直都是不可搜索、不可分类、基本也谈不上再利用。不是书签没价值，而是它们被堆到最后，价值几乎被锁死了。
这个项目的解决方案也不绕。先把书签抓下来，变成你自己的本地数据；然后建立搜索索引；再看你是想做分类、统计，还是继续导出成 Markdown，甚至整理成知识库。官方 README 给出的默认目录是 ~/.ft-bookmarks/，里面至少会有 bookmarks.jsonl、bookmarks.db、bookmarks-meta.json 这几类文件。如果你走 API 模式，还会多出 oauth-token.json；如果继续用 ft md 或 ft wiki，还会生成 md/ 目录。
我自己最看重的就是这一步。一旦数据落到本地，整个问题就变了。你不再是被困在 X 的网页里翻旧收藏，而是手里真的有了一份自己的数据集。你可以全文检索，可以按作者、日期、分类过滤，可以做统计，也可以把它变成 Markdown 再扔给 AI 去问答。说白了，它解决的不是同步难题，而是“收藏之后就再也不看”的老问题。
如何安装和完成第一次同步
安装没什么门槛，官方推荐命令就是：
npm install -g fieldtheory
要求也很明确，核心前提是 [[Node.js]] 20 及以上。装完以后你会得到 ft 这个命令，当然也可以直接调用 fieldtheory。
第一次上手，我建议按官方 quick start 来，先确认整个链路跑通，不要一开始就把所有高级功能全打开：
ft sync
ft search "distributed systems"
ft viz
ft categories
ft stats
ft sync 是整个流程的入口。按 README 的说法，第一次运行时它会尝试从浏览器会话里提取你当前的 X 登录状态，然后把书签下载到本地的 ~/.ft-bookmarks/。如果你在 macOS 上，这一步通常最顺手，因为项目一开始就是围绕 Mac 场景做的。macOS 支持 Chrome、Brave、Arc、Firefox 的会话同步，Linux 和 Windows 也写明可以通过 Firefox 或 OAuth API 模式来使用。
如果你不想让工具直接读浏览器会话，或者你本来就在非 macOS 环境里，那更稳妥的方式就是走 OAuth：
ft auth
ft sync --api
这套模式的跨平台兼容性更好，语义也更清楚。默认的 ft sync 用的是 X 网页端自己的内部 GraphQL 接口，官方文档已经明说了；而 ft sync --api 则是走 OAuth 认证后的 API 模式。前者省事，通常不需要你单独折腾开发者接口；后者更正规，也更适合跨平台环境。
我最看重的几个命令
如果只把 [[Field Theory CLI]] 当成一个“下载书签”的命令，那就有点低估它了。真正让我觉得它有意思的，是作者顺手把下载之后的利用场景也做进来了。根据当前的 ft --help 和 README，下面这些命令最值得先上手。
ft search "llm memory"
ft list --category tool
ft show 12345
ft classify
ft categories
ft domains
ft stats
ft viz
ft search 用的是 BM25 全文搜索，不是最基础的字符串匹配。这点很重要，因为书签这种东西，你大多数时候记不住精确标题，只记得大概和哪个概念、哪个框架、哪个作者有关。ft list、ft show、ft stats 则分别对应过滤、单条查看和整体统计，适合用来快速摸清自己的收藏到底都堆了些什么。
另一个让我眼前一亮的能力是分类。项目里既有 ft classify --regex 这种轻量、规则驱动的做法，也有 ft classify 这种直接调用大模型来分类的路线。当前 CLI 帮助里甚至明写了，这个动作依赖 claude 或 codex CLI。换句话说，它一开始就默认你会把本地书签和本地 AI 工具链一起用。这和很多传统 Bookmark 工具的思路很不一样，因为它不是停在“给内容加标签”这一步，而是把分类直接接进了 agent 工作流。
如果你收藏的大量内容本身就是论文、开源项目、产品发布、研究线程或者安全事件，这套分类体系会挺顺手。官方 README 里当前列出的默认类别包括 tool、security、technique、launch、research、opinion、commerce。它不算特别细，但拿来先把一团乱麻理出第一层结构，已经够用了。
它真正特别的地方，是把书签变成 agent 可用上下文
我觉得 [[Field Theory CLI]] 和普通 Bookmark 工具真正拉开差距的地方，不是界面，而是后面的这几组命令：
ft md
ft wiki
ft ask "What have I bookmarked about MCP tools?"
ft ask "Which tools should I revisit this month?" --save
ft skill install
这里面的意思很明确。ft md 可以把书签导出成独立 Markdown 文件，ft wiki 可以进一步把它们整理成互相关联的知识库，ft ask 则是直接对这套本地知识库提问。我越来越觉得，个人知识管理里真正稀缺的不是“存链接”这件事，而是存下来之后还能不能继续查、继续问、继续重组。这个项目就是在补这一段。
如果你平时就在用 [[Obsidian]]、[[Claude Code]] 或 [[Codex]]，这个项目的价值会更明显。因为现在很多人的工作流已经变成这样：代码、文档、笔记、shell 命令都在本地协同，而 AI 代理只要能读到这些文件，就能继续帮你做搜索、总结、比较和判断。[[Field Theory CLI]] 做的事情，就是把原本锁在 X 产品里的 Bookmark 也拽进这套流程里。作者甚至直接提供了 ft skill install，用来给 Claude Code 和 Codex 安装 /fieldtheory skill。看到这里我基本就明白了，它压根不是后来才想到和 agent 结合，而是一开始就是按这个方向设计的。
所以这个工具最适合的，不是“我偶尔收藏两条推文”的用户，而是已经把 X 当成技术情报流、研究资料流或者项目观察流在用的人。你收藏过的内容，本质上就是你长期关注方向的一份样本库。样本库一旦进了本地知识系统，AI 才真的有机会帮你做更高层的整理和调用。
使用时我会注意的几个边界
虽然我挺喜欢这个项目的方向，但有几个边界还是应该先说清楚，不然很容易把预期拉太高。
首先，它的核心价值是本地化和可搜索，不是云端多端同步。你如果要的是那种随手点开 App，就能在手机和网页之间无缝同步的消费级收藏工具，它可能不是最合适的选项。它更偏开发者，也更偏本地工作流。
其次，默认同步用的是 X 的内部 GraphQL 接口。官方文档已经把这件事说得很直白了。这种做法的好处是省事，不用受官方 API 配额限制；代价也很明显，它天然会受平台接口变化影响。所以我会把它看成一个很好用的个人工具，而不是某种被平台正式背书、可以永远稳定运行的官方集成。好在项目还提供了 ft auth 和 ft sync --api 这条更正规的路线，真遇到变化，至少还有备选方案。
再次，分类和问答能力虽然很吸引人，但它们依赖你本地本来就有相应的 AI 工具链。比如当前 CLI 帮助里明确写着，ft classify 需要 claude 或 codex CLI。也就是说，[[Field Theory CLI]] 不是自己内置了一整套远端 AI 服务，而是尽量复用你机器上已经有的 agent 环境。就工程设计来说，我反而很喜欢这种做法，因为它更轻，也更符合“数据留在本地”这件事。
最后，这个项目虽然已经不只是一个 “Mac 专用小工具” 了，但官方站点和 README 的表述还带着一点阶段性差异。简单说，首页强调的是它最早起家的环境，README 展示的是现在扩展后的能力。真要上手，还是以你自己的浏览器、操作系统、登录方式能不能跑通 ft sync 或 ft sync --api 为准，不要只看首页那一句话就下结论。
最后
如果只用一句话来概括，我会说 [[Field Theory CLI]] 做的事情是：把原本死在平台里的 X Bookmarks，重新变成你自己能检索、能分类、能导出、还能交给 AI 继续工作的本地数据。
我喜欢这种工具，是因为它解决的不是“再做一个入口”，而是“把已经有的信息重新激活”。很多时候我们并不缺收藏能力，缺的是让收藏重新流动起来的那一步。[[Field Theory CLI]] 正好补上了这一段，而且做法非常贴近今天真实存在的本地 AI 工作流。对于已经在用 [[Obsidian]]、[[Claude Code]]、[[Codex]]，又长期把 X 当成信息雷达的人来说，它很值得试一试。
你不一定非要把它理解成一个书签工具。更准确一点说，它是一个把个人信息流回收到本地，再继续加工成知识库和 agent context 的 CLI。我自己很看好这个方向，因为接下来很多真正有价值的个人数据，大概率都会慢慢从“继续放在平台里”转向“先拿回本地，再交给自己的工具链处理”。而在这个方向上，[[Field Theory CLI]] 是一个很典型、也很有意思的开源项目。