It is lossy —— 有损取舍，与「省钱技巧」的证伪课
普通课约 40 分钟
本课导读
上一课把「把上下文渲染成 PNG」的原理讲透了：一次针对计价规则的套利，约 1.9 → 19 chars/token。听起来像白捡的钱。
但那个 Reddit 段子的评论区里，有一条评论比段子本身狠得多：
这个讽刺真正揭露的是——所谓的「成本优化」讨论，大部分就是人发现了有损压缩，然后管它叫创新。把文本转成图片再 OCR 回来，本质上就是给你的流水线加了一道 JPEG 步骤，然后假装那些丢失的信息不存在。这么多人把这包装成「聪明技巧」而不是「保真度取舍」，说明大多数团队根本没在测量输出质量——他们就是在凭感觉检查。
这条评论写在一个段子底下，却精准命中了本课的两个主题：代价到底是什么，以及你凭什么相信一个技巧有效。
本课双线：主线拆「有损」这个概念和它在 LLM 场景下最阴险的形态；副线教一个雷达元技能——怎么鉴定一个「省钱/提速技巧」的成色。预计 40 分钟。
有损 vs 无损：先把这两个词分清楚
这是计算机领域最基础、也最常被话术模糊的一对概念：
- 无损（lossless）：压缩后还原，能拿回一模一样、每个比特都不差的原始数据。ZIP、PNG、
git里存的每个版本，都是无损的。 - 有损（lossy）：压缩时主动扔掉一部分信息，换取体积暴跌，还原时拿回的是「看起来差不多」的近似品。JPEG、MP3、你上传到微信被压过的图，都是有损的。
有损本身一点问题都没有——你手机里的照片、听的歌，全是有损的，因为人眼人耳察觉不到被扔掉的那部分。有损的正当性，来自「扔掉的东西在这个用途下确实不重要」。
出问题的永远是第二步：把有损说成无损，或者压根不提这回事。 上一课那个 hack，满网教程都在喊「无损省下 30-600% token」——而它显然不是无损的：文字画成像素、再让模型用视觉读回来，这中间隔着一次渲染 + 一次识别，和 OCR（Optical Character Recognition，光学字符识别，把图片里的字认成文本）是同一类过程，而 OCR 从来没有 100% 准确过。
注意
建立一个终身受用的雷达警报：看到「无损」两个字，先问「那被扔掉的是什么」。 如果一个方案宣称既省了一个数量级的成本、又什么都没损失，那多半只是代价还没被测量，不是代价不存在。
pxpipe 最值得学的一章：作者自己写的「The honest part」
有意思的是，pxpipe 的作者完全没打「无损」的牌。README 里专门有一章叫 The honest part（老实话部分），标题下第一行只有四个字：
It is lossy.
然后直接甩数据（把一串 12 位十六进制字符串画进图，让模型盲读）：
| 模型 | 从图片中读对 12 位 hex 字符串 |
|---|---|
| Fable 5 | 13 / 15 |
| Opus 4.8 | 0 / 15 |
同一个技巧，换个模型直接归零。作者还记录了一次真实翻车：模型从图片化的聊天历史里回忆一个人的名字，「自信地给出了一个错误的名字。没有报错，只是一个看起来合理的、但不对的名字。」
最阴险的地方：静默失败
请把上面那句话读两遍。这才是本课真正的重点——LLM 场景下的「有损」，和 JPEG 的有损有一个致命区别：
- JPEG 有损，你看得见：画质糊了、边缘有色块，损失是可见的、可量化的。
- 图片化上下文的有损，你看不见：模型读不清那串 hex 时，它不会报错、不会说「这里我看不清」，它会按照最像的样子自信地补一个给你。
这就是 静默失败（silent failure）——错误发生了，但系统没有任何异常信号，一路顺畅地把错的东西交付给你。它和你熟悉的报错完全是两种东西：
| 报错（loud failure） | 静默失败（silent failure） | |
|---|---|---|
| TypeScript 里 | 红波浪线、构建失败 | —— |
| 数据库里 | 约束冲突、事务回滚 | —— |
| 图片化上下文 | —— | 模型自信地给出一个合理但错误的答案 |
| 你的成本 | 当场修好 | 可能永远发现不了 |
能报错的错误是最便宜的错误。 上一课单元里那句「AI 翻车了为什么没人知道」，在这里有了最具体的形态：不是模型坏了，是你的流水线在悄悄降低保真度，而没有任何环节会告诉你。
所以，什么内容绝对不能图片化，答案就很清楚了：
- 精确 ID、哈希值、密钥、token、账号数字 —— 差一个字符就全错，且错了无声无息；
- 正在被逐字引用的内容 —— 比如你要求「照抄这段配置」。
而 pxpipe 的定位也因此非常清醒：它不是「无损省钱」，是「在可以接受精度损失的地方省钱」。 它默认保持最近几轮对话为纯文本，只折叠久远的历史；而代码编辑场景风险相对低，是因为 agent 在改文件前会重新读一遍文件，以磁盘上的实际内容为准——磁盘是唯一真相来源，图片里的旧记忆只是线索，不是依据。
说明
这个思路值得抽象出来带走：有损策略安不安全，取决于「错了以后有没有第二道校验」。 磁盘上的真文件、数据库里的真记录、能重新拉取的真数据，都是第二道校验。凡是「图片里的记忆就是最终依据、没有别的地方能对照」的场景，有损就是纯风险。
副线元技能：怎么鉴定一个「省钱技巧」的成色
现在处理副线。你会不断刷到「省 X% token」「提速 Y 倍」的帖子，绝大多数经不起看。pxpipe 恰好是个反例——它把功课做全了，正好当标尺。四问：
第一问：它承认代价了吗？
没有代价的优化不存在。 一个帖子只讲收益不讲代价，不是它没代价，是作者没测或者不想说。pxpipe 用一整章讲代价，还把最难看的数据（Opus 4.8 上 0/15）放在最显眼处——主动暴露自己最差的那组数据，是可信度最强的信号之一。
第二问：它测的是「省了多少」还是「答对了没」？
这是那条 Reddit 评论最狠的一刀：「大多数团队根本没在测量输出质量。」
省了多少 token 是平凡的——把上下文全删了能省 100%。真正的问题是在同样省钱的前提下，模型还答不答得对。pxpipe 公开的 benchmark 是一组 A/B 对照（同样任务，纯文本 vs 图片模式，比准确率）：
| 测试 | 纯文本 | 图片模式 | 说明 |
|---|---|---|---|
| 算术测试 | 100/100 | 100/100 | token 减少 38% |
| Gist 回忆 A/B（含干扰项，15k-45k 字符会话） | 98/98 | 98/98 | 长会话里能否找回关键信息 |
| 状态追踪（值被改 3 次，问最终值/初始值/次数） | 18/18 | 18/18 | 多轮状态是否记得住 |
| 捏造检测（问从未出现的事实，越低越好） | 0/16 | 0/16 | 都不瞎编 |
| SWE-bench Lite | —— | 10/10 通过 | 请求体积减少 65% |
| SWE-bench Pro | 15/19 | 14/19 | 见下文 |
几个跟着扫盲的名词：
- A/B 测试：唯一变量对照。这里唯一变量是「上下文是文本还是图片」，其余全同——没有对照组的性能数字一律不可信。
- 干扰项（distractor）：故意塞进去的相似但无关的内容。只有加了干扰项，「找回信息」才算真本事，否则模型可能靠猜也能中。
- 捏造检测：问一个上下文里根本不存在的事实，看模型会不会硬编。这是「越低越好」的指标——看 benchmark 表格时务必先确认每个指标的方向。
- SWE-bench：业界标准的软件工程基准，拿 GitHub 上真实的 issue 让 AI 去改代码、跑测试验证。Lite 是简化版，Pro 是完整版。这是「真任务」而不是「玩具题」，含金量高得多。
第三问：差异是真差异，还是噪声？
看 SWE-bench Pro 那行：图片模式 14/19，纯文本 15/19。差了 1 题——这是不是说明图片模式更差？
作者的处理方式是本课最值得学的一手：复现三次，差距消失，归结为 run-to-run variance（运行间随机波动）。
LLM 的输出天然带随机性，同一套输入跑两次结果可能不同。所以在小样本上（19 道题），1 题之差完全可能是掷骰子的结果。判断准则：
差异小于噪声幅度时，它不是结论，只是噪声。 想说「A 比 B 好」，要么把样本量做大，要么多跑几轮看差距稳不稳定。
这条准则的适用范围远超 AI——你以后看任何「快了 3%」「转化率高了 2 个点」的对比，都该先问一句「跑了几次、波动多大」。
第四问：能不能自己复现？
pxpipe 把测量方法、原始数据和复现脚本全放在仓库的 eval/ 目录下。可复现 = 你可以亲自证伪它。这是「公开的 benchmark」和「作者说他测过」之间的天堑。
说明
还有个有趣的细节可以当第五问的彩蛋：pxpipe 的代码和文档，大部分是由跑在 pxpipe 后面的 AI 会话写出来的——它读着自己被折叠成图片的历史，写着自己。这叫 dogfooding（吃自己的狗粮）：作者本人是产品的重度用户。它不能替代 benchmark，但它意味着「坑会先坑到作者自己」，这在工具类项目里是很硬的信任信号。
那么，这东西你该不该用
把两课合起来，判断很清楚：
- 值得用：你大量用 Claude Code 做开发，每天产生海量 tool_result（文件读取、命令输出、日志），这些内容占 token 大头、又不需要逐字精确回忆。
- 不值得用：你主要用 AI 做对话和写作，每次请求本身就短——省下的那点 token 会被渲染图片的延迟吃掉，净亏。
- 别用：流程里有精确 ID、密钥、哈希，且没有第二道校验能兜底。
对你（学径的场景）的结论是「暂时不用」，三条理由：写课程时每次请求本身不长，省下的 token 会被渲染图片的延迟吃掉；上一课那条 19 chars/token 的盈亏线是按拉丁字形标定的，中文内容能不能照搬根本没人测过；而写代码那部分，你现在的账单量级还不值得为它引入一个会改写请求的中间件。但两课里的认知是马上就能用的：知道钱花在反复重发的上下文上、知道「无损」二字要警惕、知道看到性能数字先问「有没有对照组、跑了几次、能不能复现」。
够用判断线
一句话总结：「把上下文画成图」是有损的，而 LLM 场景下的有损最阴险之处在于静默失败——模型读不清时不会报错，只会自信地编一个合理的错答案，所以精确 ID、哈希、密钥必须留在文本里，而有损策略安不安全取决于「错了以后有没有第二道校验」；至于任何「省 X%」的技巧，四问定成色：承不承认代价、测的是省钱还是答对率、差异是不是噪声、能不能自己复现。
对你的现实指导：这四问是通用的，以后刷到任何优化技巧都能套。值得深学的信号：等你真要给学径做一次「AI 功能提速/降本」的改造时，先把 A/B 评测搭起来再动手改 ——否则你会和那条 Reddit 评论说的一样，在「凭感觉检查」。
随堂测验
1. 为什么说「把上下文渲染成图片」的有损，比 JPEG 的有损更危险？
2. pxpipe 的 SWE-bench Pro 结果是「图片模式 14/19，纯文本 15/19」。作者是怎么处理这 1 题之差的？这体现了什么准则？
3. 那条 Reddit 评论说「大多数团队根本没在测量输出质量，他们就是在凭感觉检查」。为什么「省了多少 token」这个数字本身没有意义？
4.挖空
鉴定一个「省钱技巧」的四问：一问它承不承认（没有代价的优化不存在）；二问它测的是省了多少还是；三问差异是真差异还是；四问能不能自己。而看到「无损」二字，第一反应应该是问「被扔掉的是」。
划选正文任意文字可高亮、批注或加入复习卡
讨论
载入中…