Agent 花光 100 美元造 PDF 编辑器,点几下就露馅

花 400 美元，四个顶级模型，四个 PDF 编辑器——没有一个内置「报告问题」的按钮。

做实验的人叫 nielstron，研究方向是 LLM for Code。10 月 8 日他发了《The Remaining Shortcomings of Coding Agents》：给 Gemini 3.8 Flash、GPT Astra 6、Opus 5、Fable 5 各 100 美元预算，各自独占一台虚拟机，任务是独立开发一个「用户体验极好」的开源 PDF 编辑器，还被要求去调研现有工具、搜索用户的抱怨。预算没花完就随时唤醒，继续干。

他的总结只有一句：点几下，就在几乎每个成品里找到 bug。

你要是也用编码 agent 写软件，这个实验等于替你把 400 美元花了。今天上午我跑了无头浏览器，把四个成品逐个点开。它们都挂在 GitHub Pages 上，仓库在 GreatOSS 组织下。四个站点全部正常打开，控制台零报错。

零报错不代表什么。我数了它们的按钮：Gemini 的成品有 46 个可见按钮，Fable 的只有 6 个，Opus 和 Astra 各 4 个。我核对了四个站点的页面源码，没有一个地方能点到「报告问题」，也没有任何指向 issue 的链接。说实话，点开之前我以为至少有一个模型会想到加个反馈按钮。

Astra 的成品点「Try a sample」能打开一个三页样例，按钮变成 Open、Download PDF、Read、Add text、Highlight、Add pages。Opus 的成品我喂了一个本地生成的 test.pdf，它渲染出 3 个画布。四个模型都交了货，界面也都像模像样。

坑都长在交互细节里

Gemini 的第一版插入图片，是把图插到「当前光标位置」：插入前没有预览，插入后不能选中、不能删除。后来的版本学聪明了，改成「插到随机位置再让你拖拽」——他说这更像是碰巧蒙对，不是真的注意到了问题。

Astra 给每个按钮加一段文字说明，理由是更直观，这恰恰是直觉的反面。没有任何一个成品给设置加搜索框，尽管 Android 和 iOS 多年以前就证明这是设置页最重要的功能。

性能坑更典型。他 fork 过一个被 agent 重度开发的家谱工具 Gramps-Web，家谱里存 1500 人。这个量对计算机是零头，UI 却慢到不可用。查下去：后端一堆请求要几秒，前端还串行发送；Codex 拿到明确线索加两次推动才定位问题，之前没有任何 agent 自己注意到。

功能清单也高度同构：全是 PDF.js 壳子加插图片、签名、批注、遮挡、重排页面这几样。只有 Opus 想到编辑 PDF 里已有的文字。OCR、矢量编辑、移动图形元素，全部缺席。

四台虚拟机收敛到同一件事

实验的账目在 GreatOSS 的台账里：四份预算从 100.73。Astra 最夸张，1.53 小时、3 个周期就把 100 美元烧完了。四台虚拟机、四个独立会话，最后全部收敛成浏览器网页应用，前端同款。

为什么失败方式这么一致？nielstron 的答案是交互方式：agent 是「看截图、动鼠标、再看一张静态截图」，而人是带着目标、不耐烦、实时地盯着屏幕。人会在保存失败、图片位置不对的那一瞬间被硌一下；agent 不会。

他的解释成立。写代码这条链路，模型有测试、有编译错误、有 lint 反馈；「这个界面好不好用」这条链路，唯一能反馈它的是人。agent 自己点不出「硌」。我的判断是，四个模型最贵的那部分能力是写代码，而它根本没被检验到；露馅的全是它们看不见的那半。

有人会说：这只是这一代模型不行

有人会说，这只是这一代模型的快照，能力再涨几版，UI 直觉也会补上。我不这么看。实验锁住的是评估方式，不是模型版本。四个不同模型、四台独立虚拟机，同构地失败在同一种盲区上，说明这是结构问题，不是个体水平问题。

四个模型都写得出代码，没有一个验得出自己造的东西。验收这个动作，现在落在你身上——这就是那份 400 美元账单买到的边界。