给四个编程智能体各 100 美元预算做 PDF 编辑器，结果如何

TLDR；我给了 4 个编码智能体 100 美元的预算来构建一个功能性的 PDF 编辑器。这些实现还算可以，但算不上出色：点几下我就能在几乎所有的实现里找到 bug。我推测部分原因是智能体不像人类那样与软件交互：它们不会追求具体目标并在过程中体验摩擦，而且它们看 UI 的次数也少得多。因此，除非我们改变 LLM 的运作方式，否则我们将被恼人的 SlopWare 所困扰。

一点背景。作为一名研究 LLM for Code 的研究者，我大部分时间都在试图弄清楚为什么软件开发过程中还需要人类。这个问题的答案正在迅速变化。六年前，答案是根本不存在任何能把自然语言需求转化为功能性代码的系统。三年前，这个问题已被 ChatGPT 解决，问题转移到了上下文关联上：现有系统（大多是纯 LLM 补全）不了解其运行所处的复杂环境、已有功能、语言约束、输入形态。这个问题的答案最终被证明是编码智能体。它们是围绕 LLM 的非常通用的符号化封装，允许与目标系统交互，像开发者一样阅读、编辑和执行代码。再在上面撒一点强化学习来雕琢出目标导向行为，瞧。

当然，我的研究还没有结束。人类软件工程师仍然存在。与那个梗相反，我确实认为他们存在是有原因的，具体来说是因为他们仍然提供价值。但这种价值是什么？根据我使用编码智能体的经验，它归结为两件事：

1. 保持正轨，并在智能体过早退出时按下回车。

2. 注意到并报告那些烦人/损坏的地方。

在这篇文章中，我主要关注第 2 点，因为它常常与“品味”混为一谈。我在这里试图更具体地分析这一点。

一个小实验。我主要从两个 LLM 交互经验池中汲取素材。一个更偏轶事，是我使用编码智能体构建更好的开源软件（OSS）的经验。第二个是我最近出于好奇设立的一个小实验：如果我给智能体 100 美元的预算，并告诉它创建一个具有出色用户体验的开源工具——它会怎么做？它能自主设计出一个令人愉悦、交互良好的界面吗？

对于后一个实验，我让 Gemini 3.8 Flash、GPT Astra 6、Opus 5 和 Fable 5 创建一个出色的 PDF 编辑器。PDF 编辑器显然还没有好的开源替代品，我明确指示它们检查现有工具，并在互联网上搜索潜在用户反映的缺失之处。这些模型在各自的 harness 中启动，拥有可自由支配的自己的 VM（例如用来安装计算机使用工具），并在返回后只要 100 美元预算还没用完就被再次唤醒。这些智能体最初必须在隐私状态下运行，主要是为了不互相影响。产出的工件链接在那里，可通过生成的 Web 应用轻松访问。因为最终所有模型都决定构建一个 Web 应用。¹

千刀万剐。

Web 应用。在我看来，这是他们犯的第一个错误。PDF 编辑器在原生安装时才有用。它们应该是我系统上的标准 PDF 查看器。如果模型构建一个 Web 应用，它应该确保易于访问和安装，最好是作为原生应用。在公共仓库的第一次尝试中，Gemini 生成的东西只提供了通过 npm 安装的说明——失败！相比之下，Astra 确实确保了有 GitHub Pages 部署可用。这涉及两次公开的开发运行，后来的运行明确是私有的，所以我不能责怪模型没有发布网站。但据我所知，没有模型花精力确保应用可以本地安装为例如 Android 应用，或可执行文件。我只能推测，模型被驱使去生成与所有操作系统兼容的东西，但未能认识到这会严重抑制其工具的实用性。

交互。在 Gemini 的第一次尝试中，创建的 PDF 查看器支持插入图片。选择图片后，Gemini 3.8 Flash 的工具会在点击 PDF 时将图片插入到当前光标位置。这非常不可用！首先，我看不到图片是否被正确选择，更重要的是，其次，我得不到点击时图片将出现在哪里的预览。更糟的是，之后选择图片以删除或移动它是不可能的。Claude 和 Codex 后来巧妙地绕过了这个问题，只是将图片直接插入到随机位置，并让我拖放它。也许他们只是在初稿中运气好，或者从训练中蒸馏出了足够的经验，表明这是正确的方式。但尚不清楚如果他们一开始就坚持这样做，是否会*注意到*这个问题。

界面导航。当我告诉 Astra 构建一个非常直观的设计时，它决定在每个（！）按钮上放置明确的文字描述。我认为这与直观相反。这是明确的，但没有使用常见且人类在文化上已经训练过的设计语言，这与人类在界面上直观期望的完全相反！相反，Gemini 创建了一百万个按钮，图标或多或少有些可疑地清晰。一个实际上对界面导航很棒的现代功能是能够搜索设置/可用工具。注意 Android 和 iPhone 都在短时间内（可能相隔一年）迅速为它们的设置应用推出了搜索功能。我记得小时候，我经常花头几天玩我的新手机，查看所有设置，以便知道在哪里找到相关的东西。没有模型决定包含这样的搜索或帮助工具。

速度。几周前，我 fork 了一个很棒的网页版家谱管理与查看工具 Gramps，Gramps-Web。 这个工具显然是在非常重的编码智能体支持下生成的。而且显然没有人对这个工具做过“压力测试”。我加引号是因为当家谱包含 1500 人时，我注意到了性能下降。对于家谱数据库来说这算比较大，但考虑到计算机工作负载，这其实很小。尽管如此，UI 还是极其缓慢。仔细检查后，我发现许多后端请求要花约几秒钟，更糟的是，前端还是按顺序发送这些请求的。此外，后端把通用 SQL 查询和 Python 中的手动 join 混在一起（不用说，一团糟）。Codex 在给出明确指引和两次额外提示后能够找出问题，但之前没有人自己注意到或费心去修复这个问题。

野心。 对于这个设定，我曾指示 LLM 实现 OS 工具中缺失的功能并查阅资料。它们整齐地构建了一个基于 pdf.js 的查看器和一些基本编辑工具：插入图片、签名（有时）、评论、形状、遮盖文本、重排页面、压缩（仅 Gemini）。Fable 完全走极简路线，除了高亮和文本之外什么都不支持：没有水印、遮盖、形状、多选，甚至不能选中单个已添加元素（你必须先选中图片添加工具，才被允许选择和调整图片大小）。只有 Opus 甚至想到了更有野心的东西：编辑 PDF 中已有的文本。它仍然缺少其他相关（也更明显）的实用功能：编辑或移动图片、分隔线等图形元素，OCR，或矢量图形操作。快速用 ChatGPT 搜索一下就会发现，至少有三款流行的 PDF 编辑器支持这些功能。我的假设是 pdf.js 是这方面的限制因素，但我不在乎：它显然缺失。

平台。 大多数应用至少有点问题，或者在移动平台上无法工作（除了桌面端，这是我唯一测试过的平台）。在 Fable 的应用中，触摸滚动 PDF 会卡顿。在 Gemini 的应用中，显示比例不会从桌面端改变，所以你会看不到一半的控件。请注意，这些模型被明确指示要跨平台测试它们的应用，结果仍然如此。

Bug，Bug，Bug。 尽管缺乏野心，bug 却一点也不少。例如，在最初开发的 Gemini 应用中，导出的 PDF 中图片是歪斜的，深色模式下 PDF 的颜色会反转。Opus 的文本编辑器会改变被编辑文本的字体。图片旋转经常缺失，对不同图片类型的支持也缺失。在框选一块区域准备遮盖并*没有*应用遮盖后，编辑框会一直留在那里，直到手动点击移开。即使在 Fable 的应用中，我也无法在已有绘图内部绘制，因为在绘图模式下，点击一个绘图会选中该绘图以进行缩放和移动。当然，没有任何应用有 bug 报告按钮（甚至没有源代码链接）。

LLM 不是人类

这一切指向什么？ 对我来说，以上所有问题都指向所有编码智能体共有的一个 overarching 问题：它们不像人类那样与软件交互。

• 人类是目标驱动的：他们有特定的文档，希望实现特定的修改。任何阻碍他们的事情（找到正确的设置、光标与图像放置之间的错位、未能保存结果）都会被注意到。
• 人类缺乏耐心：在这种交互中，他们会遇到缓慢的操作。虽然模型在这方面有所改进，但它们通常不会花时间将操作减少几个数量级，即使这是可能的，并且会极大地改善迭代时间或可用性。
• 人类是实时交互的：特别是在图像放置设置中，我注意到LLM计算机使用与人类之间存在明显差异。LLM检查截图，移动光标，检查另一个静态截图。人类在操作输入的同时实时检查显示器。这塑造了我们对UI应该如何表现的许多直觉，也为我们大部分的UI学习提供了动力。

我的假设是，不以人类方式与软件交互的AI代理将无法设计出优秀的人类友好软件。

天下没有免费的午餐。我最近遇到一些观点，认为我们很快就会有每个商业可用软件的开源克隆。这些结果和我个人的经验不同意这一点。开源软件的主要问题通常是可用性。而这似乎正是编码代理挣扎的维度。因此，仍然需要人类来引导代理解决所有让软件使用起来刺耳的小错误和问题。换句话说，开源开发者将是一个产品经理。谁愿意免费做产品经理呢？历史上，开源软件源于编写小块美丽代码的愿望。会出现喜欢做产品经理的新开发者吗？

总之，对人类存在和内省UI设计能力的正是编码代理驾驶座上人类提供的主要价值之一。如果你想让编码代理更好，解决AI与人类软件交互之间的差异。

1. 实验发布在这里：https://github.com/GreatOSS ↩︎