开发者工具必须是开源的

# 开发者工具必须开源 来源：https://blog.exe.dev/devtools-must-be-open-source 五年前，我交谈过的大多数软件工程师都没有为自己编写过的程序。（我当时经常问这个问题，因为我想了解 Tailscale 如何融入工程师的生活。）日复一日，工程师们使用他人编写的程序来为他人编写程序。我们中的许多人通过配置文件、插件或扩展来定制自己使用的程序，也有许多人作为用户使用我们为他人编写的程序。当你问别人为自己写了什么，听到他们博客背后的定制软件、家庭自动化或家庭实验室，而不是现成的、几乎正好合适的静态网站生成器或 Zigbee 设备时，这总是一种不寻常的享受。这种情况我觉得很有道理。多年来，我为自己写了不少软件，但这样做的回报总是存疑。我每天只能写这么多。总有更重要的事情要做（工作中出了状况），而一年后回到某个项目去做维护总是极其痛苦。在我职业生涯中有好多年，我抛弃了所有定制软件，使用我能用的最普通的环境来编写代码。在谷歌担任工程师的早期，我甚至没有个人电脑。那是过去。现在情况不同了。 ## 如何个性化软件 如今，个性化软件惊人地容易。有两类针对智能体的提示词让这一切成为可能： 1. *下载软件的源代码，并在本地构建使用。同时修改设置，让智能体知道：今后对该软件的任何更改都意味着修改源代码并替换当前版本。在版本控制中记录更改背后的原始动机。* 以及，**更重要的是**： 2. *设置一个每晚运行的 cron 任务，执行以下提示：获取上游对该软件的更改，并将所有本地修改变基到上游之上。检查软件是否按预期工作，然后替换当前版本。* 其核心在于认识到，智能体不仅能为特定用途拼凑出代码，还能自动管理与上游版本同步的过程。这意味着智能体在两个方面同时改变了个性化软件的投入产出比：开始个性化变得容易得多，持续进行也容易得多。 关于上述两个编辑软件的提示，另一件令人惊讶的事情是，你可以把它们直接构建到智能体中。只要智能体是开源的，甚至不需要编程。这两个提示可以加载到一个技能（skill）中（即一些文本指令），放在智能体可以发现的地方。我们已经把这一点构建到了 Shelley 中，所以现在如果你想编辑 Shelley，你甚至不需要那些开场提示，也不需要配置定时器。它会为你处理一切。（https://blog.exe.dev/customizing-shelley）你可以输入类似“让 Shelley 的界面变成高对比度”的提示，然后你就完成了对智能体的个性化。 ### 一个实际个性化示例：Shelley 和 Meat 我自己有一个项目，过去一个月我一直在随意折腾：meat.dev（https://meat.dev/）。它的原则是：虽然智能体会写代码，但在推送到我们的正式系统之前，我仍然会阅读这些代码。随着底层模型的改进，我审阅时关注的东西也变了。过去二十年我为之审阅代码的人类，总是在边界情况上挣扎：错误是否报告了有用信息；nil 检查是否处理了等等。（我们都会这样；写代码时，我是最糟糕的人之一。）作为审阅者，我的一个职责就是寻找这些细节。在过去的六个月里，我发现我不再需要为这类边界情况而阅读代码：模型在机械正确的方面远比人类勤奋。它们的错误仅限于架构、意外用例、测试环境没有反馈给它们的视觉输出等等。这意味着我审阅的大部分代码行并不是很有用。所以我写了一个工具，它接收 diff，并使用 LLM 去除不重要的内容。我几乎不再需要看到导入块、nil 检查或错误处理，所以把它们从屏幕上移除，让我专注于“肉”（重要内容）。 我喜欢这个工具，但它有两个缺点：第一，我喜欢在 Shelley 中通过良好的 UI 阅读 diff，而不是在终端里。第二，LLM 需要几分钟来消化和精简一个 diff，我不想等。所以理想情况下，我不会在命令行运行 `meat`，而是把它集成到 Shelley 中，让它在提交一创建就预处理这些提交。事实证明，我可以用一个提示词做到这一点： > 请把 meat.dev 构建到 Shelley 中。安装最新版本到 PATH。当 Shelley 创建 git 提交时，在后台对该提交启动 meat 处理。为 Shelley 的`Diffs`视图添加一个 meat 开关。如果提交仍在处理中，向用户显示它正在处理中。 这一条提示词就足够了，不仅把 meat 加入了 Shelley，还在我回到会话审阅 diff 之前，在后台恰当地预处理提交，省去了我等待模型精简 diff 的时间。模型做出的唯一不幸选择是用了 🥩 表情符号作为开关按钮。想象一下，试图把它插入 VS Code 扩展 API 会有多么纠结痛苦！或者试图把它弄进 `vimdiff`。这当然是可能的，但要在提交一出现时就开始预处理的机制几乎是不可能的。我还不如实现一个带外（out-of-band）的 `meatd`，监听文件系统并为 `meat` 工具提供一个缓存，供自定义 API 使用，因为扩展和配置的切入点不会是合适的形态。 这就是经典配置/定制与智能体驱动的个性化之间的根本区别：你能做的多得多。智能体会去完成理解源代码并修改它以适配你心中特定任务的艰苦工作。有了个性化，我们日常使用的软件会强大得多。你所需要的只是源代码。 ## 个性化软件的时代 在智能体出现之前的开发成本意味着，复杂的软件配备大型配置文件、扩展系统和插件系统是合理的。即使是像 Vim 这样中等规模的项目，其核心代码也庞大而复杂，人类需要数周才能消化。如果想让行号默认打印，一位工程师就去学习整个代码库并为自己添加这个功能，这种想法是不合理的。更好的做法是设计成可供他人共享，这样实现成本可以通过分摊到许多用户身上而显得合理。随着代码库中功能越来越多，寻找通用抽象以拆出扩展或插件系统是有意义的。而现在，学习代码并进行修改的成本已经大幅下降。智能体承担了繁重的工作。对于单个用户——这意味着程序运行在极其受限的条件下——一个顶级智能体通常可以一次性添加一个功能。对于单用户软件，仔细代码审查的需求通常可以用“看起来能用吗？”来替代。结果是，可以个性化的软件不需要插件系统或配置文件。想改变文本编辑器中的字体大小？把源代码交给智能体并告诉它。如果是一个硬编码的值，它会找到并修改它。如果是硬编码的位图字体，它会下载另一个并替换掉，或者它会用 Monobit 为你生成一个！你随时可以调用令人难以置信的能力。 ## 整个软件产品类别都需要被重新发明 个人软件也同样适用于小团队。当一个工程团队可以从常见构件中组装出他们想要的功能时，为什么还要购买一个高度可配置的任务管理器（或 CMS、CRM），花时间学习和配置它，并让团队在其限制下扭曲自己呢？个性化软件的前期固定成本和持续成本都已经消失了。你正在阅读的博客就是定制软件，用 Shelley 编写，因为拼凑并个性化 Tiptap 等库，比尝试定制传统软件产品要容易。如今，终端用户产品要在公司中有意义，就必须是可个性化的。这意味着我们需要源代码。 ## Codex 与 Claude Code 的分歧之处 同样的基于技能（skill）的技术，被应用到 Shelley 使其可个性化，也可以轻松地应用于其他开源智能体，比如 Pi。（以至于我都在想，为什么 Pi 需要内置扩展系统。源代码就是扩展系统。）这会需要多得多的 token，但你可以对 Codex 做同样的事情，它是一个开源智能体。然而，你会碰壁的地方是 Claude Code。它是闭源软件，所以你无法对它进行个性化。Claude Code 中有很多老式的定制钩子。但愿你对智能体工作方式的期望能契合它们提供的钩子。如果不能，那就换一个允许你个性化的智能体吧。