有一个现象我观察了很久：很多人热衷于建工具、搭系统、做框架，但建完之后几乎不用。Notion 页面建了几十个，最终打开的还是备忘录。Obsidian vault 收藏了几百个模板，实际写笔记用的是微信文件传输助手。
问题出在哪？他们把手段当成了目的。
工具的两种诞生方式
工具的诞生只有两种路径：
自上而下： “我觉得我应该有一个 X 系统。” 然后你去研究各种工具，对比功能，设计架构，搭建框架。这个过程本身很爽——你感觉自己很有条理，很有方法论。但最后你几乎不会用它。因为你解决的是一个假想的问题。
自下而上： 你在工作中遇到了一个具体的淤堵——每次都要手动复制粘贴、信息散落在 5 个不同的地方、某个操作重复了 20 遍。你感到真实的痛苦，然后你用一个最简单的工具解决它。
第一种路径产出的叫”玩具”，第二种路径产出的才叫”工具”。
淤堵驱动
“淤堵”是我一直在用的一个词。它不是指大问题，而是指那种反复出现的微小摩擦——每次只需要多花 30 秒，但每天要经历 10 次。
- 每次写周报都要从 5 个地方收集信息 → 淤堵
- 每次切换项目都要重新加载上下文 → 淤堵
- 每次查一个 API 都要打开文档翻半天 → 淤堵
这些淤堵单独看都不算什么。但它们在持续消耗你的注意力和时间。更关键的是，它们是可自动化的——一旦你识别出模式，一个简单的脚本或工具就能消除它。
好的工具从淤堵中自然生长。 你不需要”设计”它，你只需要把那个让你反复摩擦的环节自动化。
Agent 时代的诱惑
AI Agent 的出现让”建工具”的门槛大幅降低，但也放大了”不为建工具而建工具”的问题。
以前你想搭一个自动化流程，至少需要写代码，这个成本本身就是过滤器。现在你只需要用自然语言描述你的需求，Agent 就能帮你实现。门槛越低，冲动越强。
我见过太多人花一整天时间配置各种 Agent workflow，最后产出的 workflow 一周运行不到两次。这不是工具的错，这是出发点的错。
判断一个 Agent workflow 是否值得建的标准很简单：它解决的那个淤堵，在过去一周里让你痛苦了多少次？
如果答案是 0，别建。如果答案是 1-2，想想有没有更简单的方式。如果答案是 5 次以上，值得投入。
最小可行工具
我的原则是：最小可行工具（Minimum Viable Tool）。
- 不需要数据库，能用文件系统就不用
- 不需要 Web UI，能命令行就不用
- 不需要多步骤 workflow，能单次执行就不用
- 不需要实时同步，能定时批量就不需要
这不是偷懒，这是尊重工具的演进规律。 每一个复杂系统最初都是一个简单脚本。过早引入复杂性，不是在建设，是在制造维护负担。
我的大部分”工具”其实就是几个 Bash 脚本和一些简单的 Python 文件。它们丑陋、没有文档、没有测试。但它们解决了真实的淤堵，我每天都在用。
完美是优秀的敌人。对于工具来说，可用是完美的前提。
知识管理系统的陷阱
知识管理是”不为建工具而建工具”的重灾区。
“我要建立一个知识库”——这个想法本身就有问题。知识不是需要”管理”的资产，知识是需要使用的工具。
你不需要一个”知识管理系统”，你需要的是：
- 写东西的时候能快速找到相关的素材
- 学到新东西的时候能把它和已有的知识连接起来
- 需要做决策的时候能快速调取相关信息
这三个需求，一个带搜索功能的 Markdown 文件夹就能满足。你不需要双链笔记，不需要知识图谱，不需要 AI 摘要。
当然，如果你的”淤堵”确实到了需要这些功能的地步，那就用。但大部分人没有到那个地步——他们的淤堵不是工具不够好，而是思考不够多。
系统思维的正确用法
我不是反对系统思维。系统思维非常有价值，但它应该在你已经有了足够多的小工具之后才介入。
正确的顺序是：
- 积累小工具——遇到淤堵就解决，用最简单的方式
- 观察模式——运行一段时间后，你开始看到工具之间的关系
- 自然整合——当多个小工具之间的切换成本变高时，才考虑整合
- 形成系统——系统是演化的结果，不是设计的起点
这个顺序不能颠倒。从第 4 步开始的人，大概率会陷入”建系统”的无限循环——系统还没建完，需求又变了，然后重新设计，永远在规划，永远没产出。
问自己一个问题
下次你想搭一个工具、建一个系统、配置一个 Agent 之前，问自己一个问题：
“在过去一周里，我因为缺少这个东西而感到具体的痛苦了吗？”
如果答案是”没有”或者”理论上应该有”——放下它，去做真正重要的事。
如果答案是”有”——别想太多，用最快的方式解决它。丑陋但可用，远比完美但不存在有价值。
工具是手段，不是目的。不要为了锤子的快感而找钉子，等钉子真的扎到你的时候，锤子会自己出现。