“开发工具必须开源”——这篇博客正在 Hacker News 上热议，我们完全赞同。https://blog.exe.dev/devtools-must-be-open-source … 其中一个最妙的想法是“长期运行的 fork”：让一个智能体每晚自动合并上游变更。这恰好是 OpenHands Agent Canvas 自动化（https://docs.openhands.dev/openhands/usage/agent-canvas/managing-automations …）的完美用例，它可以让你执行这些由智能体驱动的重复性任务。我们在这里快速做了一个，祝你 fork 愉快！：https://github.com/OpenHands/extensions/pull/435 …

开发工具必须开源

来源：https://blog.exe.dev/devtools-must-be-open-source

五年前，我交谈过的大多数软件工程师都没有给自己写过程序。（我当时经常问这个问题，想了解 Tailscale 如何融入工程师的生活。）工程师们每天从早到晚都在用别人写的程序来为别人写程序。我们中的许多人会通过配置文件、插件或扩展来定制自己使用的程序，也有许多人会以用户的身份使用自己为别人写的程序。当你问一个人为自己写过什么，然后了解到他们博客背后的定制软件、或他们的家庭自动化、或他们的 homelab，而不是现成的、尺寸几乎合适的静态站点生成器或 Zigbee 设备时，那总是种难得的乐趣。这种状态对我来说很有道理。多年来，我为自己写了不少软件，但这样做的回报总是值得怀疑。我一天只能写这么多代码。总是有更重要的事情要做（“工作中出了状况”），而一年后回到一个项目去做维护总是极其痛苦。在我职业生涯中有好多年，我扔掉了所有定制软件，用我所能找到的最普通的环境来写代码。早年在 Google 当工程师时，我甚至没有个人电脑。那是过去的事了。现在不同了。

如何个性化软件

如今，个性化软件惊人地容易。实现这一切的提示词（prompt）大致分为两类：

1. 下载软件的源代码，并构建为本地使用。修改后，要明白以后对该软件的任何更改都意味着修改源代码并替换当前版本。在版本控制中记录更改背后的原始动机。

以及，更重要的是：

2. 设置一个每晚运行的 cron 任务，执行这样的提示：获取上游对软件的更改，将所有本地更改 rebase 到上游之上。检查软件是否按预期工作，并替换当前版本。

这里的核心在于认识到：智能体不仅能为特定用途拼凑出代码，还能自动管理与上游版本同步变更的过程。这意味着智能体在两个方面同时改变了软件定制的投资回报率：开始个性化变得更加容易，持续进行也变得更加容易。

有关上述两个软件编辑提示的另一件惊人之处在于，你可以直接将它们构建到智能体中。只要智能体是开源的，这甚至不需要编程。这两个提示可以加载到一个技能（skill）中（即一些文本指令），放在智能体可以发现的地方。我们已经把它内置到 Shelley 中，所以现在如果你想修改 Shelley，你甚至不需要前面的引导步骤或配置定时器。它自己会处理好。（https://blog.exe.dev/customizing-shelley）你可以输入类似“让 Shelley 的 UI 变成高对比度”的提示，然后你的智能体就被个性化好了。

一个实际的个性化示例：Shelley 与 meat

我有一个过去一个月里一直在闲玩的项目：meat.dev (https://meat.dev/)。其原则是：虽然智能体会写代码，但在推送到我们严肃的系统之前，我仍然会阅读代码。随着底层模型的改进，我关注的东西也变了。我花了二十年为其审查代码的那些人，总是在边界情况上挣扎：错误是否报告了有用的信息？nil 检查是否处理妥当？等等。（我们都会这样；写代码时，我是最糟糕的违规者之一。）作为审查者，我的一个职责就是关注这些细节。但在过去六个月里，我发现我不再需要为这类边界情况而阅读了：在机械性的正确性上，模型比人远为勤勉。它们的错误集中在架构、意外用例、测试环境没有反馈给它们的视觉输出，等等。这意味着我审查的绝大多数代码行都不太有用。于是我写了一个工具，它接收 diff，使用 LLM 把不重要的部分剔除掉。我几乎不再需要看导入块、nil 检查或错误处理了，所以把它们从屏幕上拿掉，这样我就能专注于“肉”（meat）了。我喜欢这个工具，但它有两个缺点：第一，我喜欢在 Shelley 里通过良好的 UI 阅读 diff，而不是在终端里。第二，LLM 消化并精简一个 diff 需要几分钟，我不想等。所以理想情况下，我不会在命令行运行 meat，而是把它构建进 Shelley，并在 commit 一创建时就进行预处理。事实证明，我可以用一条提示做到这一点：

请把 meat.dev 构建进 Shelley。在 PATH 中安装最新版本。当 Shelley 创建 git commit 时，在后台对该 commit 启动 meat 处理。在 Shelley 的 Diffs 视图中为 meat 添加一个切换开关。如果 commit 仍在处理中，让用户看到它正在处理。

这条提示不仅把 meat 加进了 Shelley，还会在我回到会话审查 diff 之前，在后台适当地预处理 commit，省去了我等待模型精简 diff 的时间。模型唯一做出的不幸选择是给切换按钮用了 🥩 表情符号。想象一下，要把它插进 VS Code 扩展 API 会是多么纠结的苦差事！或者试图把它弄进 vimdiff。那当然有可能，但要一有 commit 出现就开始预处理的机制几乎是天方夜谭。我更应该实现一个带外的 meatd，监听文件系统，并为 meat 工具提供一个缓存，供定制 API 使用，因为扩展和配置的切入点不会是合适的形态。这就是传统配置/定制与智能体驱动的个性化之间的根本区别：你能做的事情多得多。智能体会去完成理解源代码并针对你心中的特定任务进行修改的繁重工作。有了个性化，我们日常使用的软件会强大得多。你只需要源代码。

个性化软件的时代

在智能体出现之前，开发成本意味着复杂软件携带大型配置文件、扩展系统和插件系统是合理的。即便是像 Vim 这样中等规模的项目，其核心代码也庞大而复杂，人类需要数周才能消化。设想一下，一个工程师因为想要默认打印行号，就会去学习整个代码库并为自己加上这个功能——这太不合理了。更好的做法是把它设计成可以被他人共享，这样可以通过在众多用户中分摊实现成本来证明其合理性。随着代码库中的功能增多，寻找公共抽象、进而拆出扩展或插件系统就有了意义。现在，学习代码并做出修改的成本已经急剧下降。繁重的工作都由智能体承担了。对于单用户（意味着程序运行的条件极其受限）来说，顶级智能体现在通常可以一蹴而就地添加一个功能。对于单用户软件，“仔细代码审查”的需求往往可以被“看起来能用吗？”所取代。结果是，可以被个性化的软件不需要插件系统或配置文件。想更改文本编辑器中的字体大小？把源代码交给智能体，告诉它去做。如果是硬编码的值，它会找到并编辑它。如果是硬编码的位图字体，它会下载另一个并替换掉，或者用 Monobit 为你制作一个！你触手可及的能力令人难以置信。

整类软件产品都需要被重新发明

个人软件同样适用于小团队。当一个工程团队可以从常见构件中组装出他们想要的特性时，为什么还要购买一个极其可配置的任务管理器（或 CMS、CRM），花时间学习和配置它，并让团队扭曲自己去适应它的限制？个性化软件的初始固定成本和持续成本都已经消失了。你正在阅读的博客就是定制软件，是用 Shelley 写的，因为把 Tiptap 这样的库拼凑并个性化，比尝试定制传统软件产品更容易。如今，面向终端用户的产品若想在公司里有意义，就必须是可个性化的。这意味着我们需要源代码。

Codex 与 Claude Code 的分歧

同样的基于技能（skill）的技术，被用于让 Shelley 变得可个性化，它也可以轻而易举地应用于其他开源智能体，比如 Pi。（以至于我不禁想知道，Pi 为什么还需要内置扩展系统？源代码就是扩展系统。）它会需要多得多的 token，但你可以对 Codex 做同样的事，因为 Codex 是一个开源智能体。不过，你会撞墙的地方是 Claude Code。它是闭源软件，所以你无法个性化它。Claude Code 里有很多老式的定制钩子（hooks）。但愿你对智能体工作方式的期望能恰好符合它们的钩子。如果不能，那就换一个允许你个性化的智能体吧。