像素的烦恼

给你描绘一个场景。凌晨两点，你对着同一个 CSS 布局问题折腾了一个小时。终于受不了了，截了个图扔进终端，打字："把这个按钮对齐问题修一下。"

AI 助手努力"看"了看你的截图，绞尽脑汁猜测——也许给了你点有用的东西。但黑箱里面发生的事是这样的：模型先烧一堆 token 来"看"你的屏幕，再烧一堆来"理解"看到了什么，然后在一块 1440p 屏幕上的 47 个 UI 元素里猜你到底指的是哪个。

凌晨两点的调试时间，可经不起这么猜来猜去。

没人跟你说的 Token 账本

AI 编程助手厂商不会主动告诉你的是：你每发一张截图，都是在烧真金白银，而且还在蚕食你的上下文窗口。一张普通视网膜屏幕截图，在 Claude 上光是视觉处理就要消耗 1500+ 个 token。GPT-4o 大概 1100 个。Gemini 2.5？大约 1550 个。

然后这只是单次。乘以一个来回迭代的调试会话试试。你每隔几个提示就要给 agent 看一下当前屏幕状态——如果你跟我一样在调试复杂 UI 问题，一个会话下来少说 15 到 20 次。

这么一算，光是"看屏幕"这件事，你就花掉了 22000 到 31000 个 token。在一个 200k 的上下文窗口里，这是要不回来的空间。要是跑的是 Opus 4.7 或 4.8？同一套操作下来，视觉 token 直接飙升到大约 96000。

换一种方式呢？用结构化 JSON 描述你的 UI 元素：位置、颜色、文本内容、语义角色。同样的屏幕状态，用 JSON 表示？大约 700 个 token。20 轮会话下来：总共 14000 个左右。

这不是边际改善。这是"能不能完成重构"和"做到一半被上下文压缩踢出去"的区别。

结构完爆像素：真正的优势

但比 token 账本更重要的，是另一个问题——也是我一直在琢磨的一点。

你发截图的时候，agent 每轮都要重新"理解"一遍。原始像素不是可持续的推理状态。你在第六轮追问一个跟进问题，模型又得眯着眼睛看像素、重新理解、重新猜测。

结构化 JSON 完全改变了这个逻辑。你给 agent 的不再是"这些像素可能代表什么"，而是它可以参考、可以延续的事实："元素 e4 是一个按钮，位置 [0.34, 0.60, 0.32, 0.07]，颜色 #3B82F6，标签是'注册'。"

Agent 不需要猜你指的是哪个输入框。schema 已经定义好了。推理基于的是下一轮也会用到的同一套基本元素。你不是在"展示"，你是在"告诉"。

这跟 Vibe Coding 有什么关系

说到底，这背后有一个更大的趋势——AI 辅助开发正在发生变化，也就是有些人说的"vibe coding"。

Vibe coding 的核心是你应该能描述你想要什么、快速迭代、然后让 AI 处理实现细节。但 vibe coding 有一个前提：AI 必须拿到关于当前状态准确的信息。

截图是有损的。PNG 里的标注不过是红色像素画在矩形上。但结构化 JSON 里的标注带着意图：指向哪个元素、要突出什么、你想让 agent 怎么处理。

把猜测去掉，摩擦就没了。而去掉摩擦，才是 vibe coding 的本质。

实际建议

不是说截图就不能用。有时候就是想快点展示点什么。但如果你在认真跟 AI 编程助手做迭代式的工作——重构、调试、搭复杂 UI 的功能——结构化数据才是正道。

懂这个道理的工具有些已经在进化了。不懂的，迟早要掉队。因为说到底，你发图片的时候，AI 助手并不是真的在"看"。它在解释。而解释是有成本的、有损耗的、不稳定的。

给它点能真正"读"的东西吧。

你觉得呢？长会话里有没有感觉到上下文窗口的压力？留言聊聊——我们都在摸着石头过河，你的经验很重要。