目录
最近读到 Josh Morony 的一篇文章：Why you should build your own tools in the age of LLMs。文章的主张很直接：在 LLM 时代，对于个人工作流来说，应该更多考虑自己做一个小工具，而不是默认去寻找一个功能齐全的第三方插件。
这不是“以后什么都自己造”的宣言。原文的重点其实是一个成本变化：以前，定制工具需要花很多时间学习、开发和维护；现在，一个描述清楚的需求就可能让 LLM 在几分钟内生成出可用的第一版。既然定制的价格下降了，我们就应该重新计算“自己做”和“安装一个大工具”之间的取舍。
LLM 改变的不是工具能力，而是定制成本
在没有 LLM 的时候，我想把一个小改进加入工作流，通常有三种选择：忍受现状，花时间寻找一个已有插件，或者自己学习相关 API 并维护一个新项目。
这三条路都不轻松。寻找工具需要读文档、比较方案、处理配置；自己开发则意味着要理解运行环境、处理边界情况，并承担后续升级的责任。一个只是为了节省几分钟操作时间的小需求，很难合理化几天的开发投入。
LLM 改变了这个计算方式。它可以处理本地环境配置，生成 shell 脚本、Neovim 配置、tmux 菜单和 gh 命令的胶水代码，也可以根据实际使用反馈继续修改。于是，过去“不值得做”的微小优化，现在有机会在一次短对话里变成一个可运行的工具。
这里真正降低的是定制成本，而不是软件工程的复杂度。生成第一版很容易，确认它没有误删文件、泄露令牌、绕过权限，或者在异常情况下留下半完成状态，仍然需要人来负责。
一个小工具可能比一个大插件更适合你
原文用 GitHub Pull Request 的处理流程举了一个很具体的例子。作者长期在终端、tmux 和 Neovim 中工作，但查看 PR 的文件级变更时仍然需要打开 GitHub 网页，用鼠标在多个文件之间切换。这种上下文切换打断了原本的工作节奏。
他没有直接安装一个功能完整的 Neovim GitHub 插件，而是让 LLM 按照自己的需求制作了一个终端工具。这个工具只覆盖他最常用的部分：列出 PR、查看基本信息、把 PR 放进独立 worktree 和 tmux 会话、浏览文件差异，以及在审查过程中进行修改和评论。
这个工具可能远远没有大型插件完整，但它有三个明显优势：
- 命令和快捷键按照自己的习惯设计，不需要重新学习一套陌生的操作方式。
- 只实现真正需要的功能，输入和输出都更容易理解。
- 工具可以直接贴合本地环境，比如自己的 shell、目录结构、编辑器和 worktree 习惯。
这让我想到一个常见误区：我们经常把“功能更多”误认为“更适合”。但个人工作流的目标不是覆盖所有人的场景，而是让自己的高频路径更短、更稳定。一个只做六件事的小程序，有时比能做六十件事的大插件更容易使用。
第三方依赖的成本经常被忽略
安装一个成熟工具当然有很多好处：它经过更多人的使用，文档和功能通常更完整，也可能已经处理了我们尚未想到的边界情况。但依赖一个工具，至少要付出几种成本。
首先是维护和安全成本。我们依赖它继续工作、继续维护，依赖它不会在更新后改变行为，也依赖它的依赖链没有引入新的风险。LLM 让工具发布变得更快，这种速度同样意味着我们需要更谨慎地审查来源、权限和代码行为。
其次是复杂度成本。第三方工具需要服务很多用户，因此功能会不断扩展，配置项、抽象概念和兼容逻辑也会越来越多。它解决了很多问题，但其中大部分可能与你无关。你获得了功能，也接受了别人为通用性做出的设计决定。
最后是学习成本。一个成熟插件通常有自己的命令、快捷键、术语和配置方式。即使它最终能提高效率，也需要先投入时间理解它。对一个每天只重复几次的操作来说，这个学习成本未必划算。
自己做的小工具也有依赖成本，但依赖的是更少、更透明的东西：操作系统提供的命令、Git、gh、编辑器和你能看懂的几百行脚本。出现问题时，你知道应该从哪里开始检查。
“自己做”不等于拒绝成熟软件
这条原则的边界同样重要。原文并不主张自己重写 Neovim，也不主张让 LLM 为每种语言生成一套语法高亮解析器。成熟软件在复杂度、兼容性和社区验证方面有明显优势，重复制造这些基础设施通常没有意义。
更实用的判断方式是：把稳定、通用、复杂的基础能力交给成熟工具，把贴合个人习惯的胶水层留给自己。
例如，Git 本身值得依赖；但“列出我关心的 PR，然后为它创建一个隔离 worktree 并启动对应 tmux 会话”可能非常适合写成自己的脚本。Neovim 值得依赖；但“按我项目的约定打开某类文件，并跳到最近一次失败的检查”可以由一个小命令完成。成熟工具负责提供能力，定制工具负责把这些能力连接成你的工作流。
这也是我理解的“本地工具优先”：不是拒绝生态，而是在添加依赖之前先问一句，这个需求是否足够具体，具体到几百行脚本就能更好地解决？如果答案是肯定的，自己做往往更简单。
AI 生成的工具也需要工程约束
让 LLM 写一个工具很快，但“能运行”不等于“值得长期使用”。一个工作流工具通常拥有很高的本地权限：可以执行命令、读写文件、调用 GitHub API，甚至创建和删除 worktree。它越方便，出错时的影响范围就越大。
我会给这类工具设置几条最低限度的约束：
- 破坏性操作必须显式确认，不能因为参数缺失就默认执行删除或关闭操作。
- 默认使用当前项目和当前分支的明确上下文，避免在错误仓库里执行命令。
- 访问令牌只通过现有的安全凭据机制传入，不能写入脚本、日志或临时文件。
- 每一步都尽量可观察，告诉我执行了什么、目标是什么、结果是什么。
- 先把工具做成一个小而清晰的命令，再根据真实使用频率增加功能。
这些约束会抵消一部分“几分钟生成”的速度，但它们决定了工具能否进入日常工作流。一个偶尔成功、偶尔悄悄做错事的工具，最终只会增加焦虑。
从一个具体的烦恼开始
这类工具最适合从一个明确而重复的烦恼开始，而不是从“我要打造一套开发平台”开始。比如：
- 每次审查 PR 都要重复打开几个页面和几个终端窗口。
- 每次发布前都要手动执行一组固定检查。
- 每次切换项目都要重新设置环境变量、日志窗口和开发服务。
- 每次处理失败的 CI 都要在多个命令之间复制粘贴同一组信息。
先把其中一个流程描述成输入、动作和结果，再让 LLM 生成最小实现。使用几次之后，你会知道哪些步骤真的高频，哪些只是当初想象出来的功能。工具应该从真实的摩擦中长出来，而不是从一份宏大的功能清单开始。
我认为这也是 LLM 时代一个容易被低估的变化：我们不必再把工作流完全适应现成软件。只要需求足够具体，就可以让软件反过来适应自己。
最后还是要判断依赖是否值得
自己做工具的默认倾向，不代表每次都应该自己做。一个第三方解决方案如果足够成熟、维护稳定、安全边界清晰，而且能明显节省长期成本，就应该直接使用。真正需要避免的是不加判断地接受依赖，或者为了几分钟的便利接入一个复杂、权限过大的系统。
LLM 让“做一个小工具”变得便宜，于是我们获得了更多选择：可以使用成熟工具，可以组合现有命令，也可以为自己的工作流写一层薄薄的定制代码。选择的标准不再只是“有没有现成插件”，而是哪个方案更符合自己的边界、习惯和维护能力。
对我来说，最值得记住的不是“以后都自己写工具”，而是这一句：当定制成本足够低时，个人工作流不必再迁就通用软件的默认形状。