五年前，我与大多数软件工程师交谈时，他们没有写过任何自己的程序。（我经常问这个问题，试图理解 Tailscale 如何融入工程师的生活。）工程师们整天使用他人编写的程序来为他人编写程序。我们中的许多人通过配置文件、插件或扩展来定制我们使用的程序，同时我们中的许多人也作为用户使用我们为他人编写的程序。问别人他们为自己写的东西并了解他们的博客、家庭自动化或家庭实验室背后的定制软件，总是特殊的享受，而不是市售的、几乎合适的静态站点生成器或 Zigbee 设备。这种状态对我来说是完全合理的。多年来，我为自己编写了很多软件，而这样做的回报总是值得怀疑。我每天只能写这么多。总有更重要的事情要做（工作有问题），而且在一年后回到一个项目进行维护总是非常痛苦。在我的职业生涯中，有很多年份我都扔掉了我所有的自定义软件，使用最基本的环境来写代码。在我早期作为 Google 工程师的岁月里，我甚至没有拥有个人电脑。那是过去的事。现在情况不同了。如何个性化软件 在今天，个性化软件是惊人的简单。使这一切成为可能的有两类通用的代理提示：下载 <软件> 的源代码并为本地使用构建它。修改 <您的代理使用的任何内存> 以知道未来对该软件的任何更改意味着更改源代码并替换当前版本。在版本控制中记录更改背后的初衷。更重要的是：设置一个夜间 cron 作业，执行提示：获取 <软件> 的上游更改，并将所有本地更改重新基于上游。在此过程中检查软件是否按预期工作并更换当前版本。核心的认识是，代理不仅可以为特定用途编写一些代码，还可以自动管理与上游发布同步更改的过程。这意味着代理在定制软件的投资回报率上同时改变了两个方面：开始个性化要容易得多，保持下去也要容易得多。另一个令人惊讶的事实是，上述两个提示可以直接构建到一个代理中。只要代理是开源的，甚至不需要编程。这两个提示可以加载到一个技能（即一些文本指令）中，放在代理可以发现的地方。我们将其集成到 Shelley 中，因此现在如果你想编辑 Shelley，甚至不需要前言或配置定时器。它会为你处理这些。你可以输入诸如“使 Shelley 的用户界面高对比度”之类的提示，这样你就个性化了你的代理。一个实际的个性化示例：Shelley 和 Meat 我有一个个人项目，在过去一个月中偶尔玩弄：meat.dev。原则在于，虽然代理编写代码，但在推送到我们严肃的系统之前，我仍然会阅读代码。随着基础模型的改进，我所寻找的内容也发生了变化。我花了二十年为人类审查代码，始终在边缘情况下挣扎：错误是否报告有用信息；是否处理了 nil-checks 等等。（我们都这样做；在编写代码时，我是最糟糕的违规者之一。）作为审查者，我的一个角色是寻找这些细节。在过去的六个月中，我发现我不再需要关注这些边缘情况：模型在机械正确性上比人类更勤奋。他们的错误局限于架构、意外用例、测试环境未反馈给他们的视觉输出等。这意味着我审查的代码行大多数时候并没有太大用处。因此，我编写了一个工具，提取 diff 并使用 LLM 来剔除无关紧要的内容。我几乎不需要再看到 import 块、nil-checks 或错误处理，所以把它们从屏幕上删除，让我可以专注于重要内容。我喜欢这个工具，但它有两个缺点：首先，我喜欢在 Shelley 中以良好的用户界面阅读我的 diff，而不是在终端。其次，LLM 处理和最小化 diff 需要几分钟，我不想等待。因此，我理想情况下不想在命令行上运行 meat，而是希望将其内置于 Shelley 中，并在提交创建的瞬间进行预处理。事实证明，我可以用一个简单的提示做到这一点：请将 meat.dev 构建到 Shelley 中。安装最新版本到 PATH。当 Shelley 创建 git 提交时，在后台开始处理提交的 meat。为 Shelley Diffs 视图添加一个切换按钮。如果提交仍在处理中，则让用户知道正在处理。这个简单的提示不仅使 meat 添加到 Shelley，还使得