【AI早读 0705】更好模型与更糟工具的悖论

上周四，Armin Ronacher - 就是 Flask 的作者 - 发了一篇博客，题目叫“Better Models: Worse Tools”。光看标题就让人坐直了。

他遇到的问题是：新版 Claude 模型(Opus 4.8 和 Sonnet 5)在调用 Pi 编辑工具的 edits[] 数组时，会凭空捏造一些不存在的字段 - requireUnique、oldText2、newText2，甚至还有 event.0.additionalProperties。编辑内容本身是正确无误的，但工具调用却因为 schema 校验失败被拒了。更奇怪的是，老版本模型反而没有这个问题。

链接：Better Models: Worse Tools

工具调用不是魔法

要理解这个悖论，先得搞清楚语言模型调用工具的底层机制。很多人以为工具调用是某种“结构化输出”的黑盒，但 Ronacher 的梳理很清楚：工具调用本质上是一种带内信令(in-band signalling)。模型收到的是一整段拼接后的提示 - 包含系统提示词、对话历史和工具定义 - 然后在某个时间点输出一段特殊标记，客户端再把它解释成“调用这个工具 + 这些参数”。

对于 Anthropic 的模型来说，工具调用的序列化格式有点像 XML 加 JSON 的混合体。顶级字符串参数直接内联在标记里，而嵌套的对象数组(比如 edits[])则用 JSON 序列化。这意味着模型生成工具参数时，本质上是靠“记忆训练时见过的格式惯例”，而不是靠语法约束。

链接：Better Models: Worse Tools

为什么越新的模型越差

Ronacher 的最强假设是：这不是随机退化，而是训练产物的副作用。

老版 Anthropic 模型训练时参考的是一些通用工具文档，但那时还没有像 Claude Code 这样面向终端用户的成熟编辑器。而新版模型在 post-training 阶段很可能大量接触了 Claude Code 或类似工具的运行数据。Claude Code 的编辑工具接口相对扁平 - file_path、old_string、new_string 加一个可选 flag - 而不是 Pi 那种嵌套的 edits[] 结构。

更关键的是，Claude Code 客户端本身包含了大量容错逻辑：参数别名、类型强制转换、未知字段过滤、Unicode 修复等等。如果一个工具调用在 Claude Code 自己的 harness 里不会被拒绝，那 RL 训练时模型就收不到负反馈。久而久之，模型学会了在容忍度高的环境里“差不多就行”，但到了 schema 更严格的环境里就开始露馅。

换句话说，模型的工具调用能力不是在退化，而是在过度适配到 Claude Code 的容错范式中。当你换一个工具接口时，模型越强，它套用熟悉的格式惯例就越用力 - 结果就越是出错。

链接：Better Models: Worse Tools

Fable 5 时代的提示工程：盲点才是瓶颈

同一天，Anthropic 开发者 Thariq Shihipar 分享了 Fable 5 的提示技巧，视角恰好与 Ronacher 形成镜像。Shihipar 的观点是：Fable 5 是第一个输出质量真正被用户自身“盲点”限制的模型。他把知识分成了四类 - 已知已知、已知未知、未知已知、未知未知 - 其中真正卡住模型的不是模型本身，而是用户没有意识到的“未知未知”。

Shihipar 建议几个实操技巧。“Blindspot pass” - 让 Claude 扫描代码库后告诉你，你有哪些盲区。“结构化面试” - 让 Claude 一个问题一个问题地问你关于需求中的模糊点，优先问那些会影响架构设计的问题。“实现笔记” - 让 Claude Code 在运行过程中维护一个 implementation-notes.md，记录所有它做的决策和遇到的边界情况。

最有趣的是他指出：提示词写得太细，模型会僵化执行错误的方向;写得太粗，模型会退回到业界默认答案。中间的平衡点只能靠系统性地暴露自己的盲点来找。

链接：Anthropic developer shares prompting tips for Fable 5

pxpipe:用 PNG 编码文字绕过 token 计费

如果说 Ronacher 的发现揭示了模型行为的一个诡异侧面，那 pxpipe 则展示了用户如何以更诡异的方式对抗 token 定价。

pxpipe 是一个开源工具，原理是把大量文本(系统提示、工具文档、历史对话)渲染成 PNG 图片，再传给 Claude Code。为什么这样做？因为 Anthropic 对图片按像素尺寸计费，而不是按图片里包含的文字量计算。一张 PNG 可以塞进约 48000 个字符，作为图片只消耗约 2700 个 token;如果作为纯文本发送，同样的内容要吃掉约 25000 个 token。一趟会话下来，总 token 消耗可以降低 59% 到 70%。

代价是有的 - 精确字符串（如 hash 值）可能读取错误，而且图片需要经过视觉编码器处理，速度比纯文本慢。但开发者 Steven Chong 的基准测试显示，Fable 5 在处理数学题时可以达到 100% 的准确率。Opus 4.7 和 4.8 则约有 7% 的误读率。

链接：Open-source tool pxpipe hides text in PNGs to cut token costs

一条共同的线索

这三件事看似无关，但围着同一个核心在转：模型的“智能”在持续提升，但它与外界交互的协议和计费规则并没有同步进化。

Ronacher 的数据告诉我们，模型花了大量训练周期去适应某个特定 harness 的容错习惯，换一个环境就会出问题。Shihipar 的经验告诉我们，模型的能力已经强到用户的认知盲区才是瓶颈。pxpipe 的存在则说明，当 API 定价策略和模型的实际使用方式错位时，用户总能找到让你意外的应对办法。

从工具链开发者的视角看，这件事的启示可能是：不能在 harness 里默默修掉所有模型的异常输出，然后等着模型在别处出问题。应该主动暴露脆弱性，把容错逻辑当作训练信号的一部分，而不是事后补救。

从用户的角度，如果你在用 Fable 5 或 Opus 4.8,试试 Shihipar 的 blindspot pass - 先花五分钟让模型识别你的盲区，再开始写代码。时间投在这里，回报可能比反复调提示词要大得多。

---

• 博客原文：Better Models: Worse Tools
• Anthropic 提示技巧：The Decoder
• pxpipe 仓库：GitHub

来源：VerySmallWoods Research Feed - 2026-07-05 UTC