Agent 编程最隐蔽的盲区：你出了 loop，谁来替你摸 Tab 键

Agent 编程最隐蔽的盲区：你出了 loop，谁来替你摸 Tab 键

Agent 帮我接管了一个模块的 UI 细节。

我定好需求，写清楚约束，agent 生成代码，我看最终 diff，跑一下测试，感觉没问题就合并。没有逐行 review，也没有亲自打开产品试。我把这理解成”提效”——人把时间留给更高层次的决策，执行的事交给 agent 跑。

效果确实快。快到我开始觉得这就是正确的姿势。

---

jlongster 在做 OpenCode 的 diff viewer 时遇到了一个细节问题。文件树和 diff 区域并列，用户按方向键，应该滚动 diff，还是移到文件树的下一个文件？两个区域都在，谁响应键盘是个判断。

他让 agent 处理了焦点逻辑。Agent 给的方案是用 f 键切换文件树的 focus 状态——f 代表 focus，语义清楚，没跟别的快捷键冲突。他看了 diff，觉得说得通，合并了。

后来他真的去用这个功能，手自然地按了 Tab。

就是 Tab。Web 和原生 app 几十年来切换 focus 的方式。所有人的手指都记得 Tab，没有人的手指记得 f。

他在原文里写：等一下，当然是 Tab！这就是所有 web 和原生 app 的工作方式。

但 agent 没有”当然”。它没有在任何一个真实界面上摸过 Tab 键，它只有从上下文里搜集来的下一个 token。f 这个答案，在推理层面是合理的。在使用层面是错的。

---

agent 生成的是 plausible，不是 right

Plausible 是：逻辑说得通，测试能过，代码审查找不出明显问题。Right 是：用户坐在那里的时候，手会自然落在对的地方。

“用户的手会自然落在哪里”这件事，不在任何文档里，不在平台设计规范里，不在 CLAUDE.md 里。它在肌肉记忆里，在你每天打开十几个 app 的经验里。你让 agent 遵循”平台交互惯例”，它能找到写下来的那部分，找不到从来没人写出来的那部分。

这不是 prompt 写得不够细的问题。你可以把需求描述得更详细，但你需要描述的恰恰是那些”这还用说吗”的东西——而那些东西之所以没被写出来，就是因为你觉得不用说。

Plausible 和 right 之间有一条缝。这条缝，就是用户会掉进去的地方。

“看 diff”和”在 loop 里”是两件事

我之前把这两件事混在一起了。

审 diff 能告诉你代码做了什么，感受不了 Tab 按下去的感觉对不对。这两个信息不是同一种信息。前者是结构层面的，后者是体验层面的。你只看前者，体验层面的判断就空着，然后 agent 的 plausible 就顺势填进去了。

jlongster 说他现在大部分时间活在 OpenCode 里，只在必要时打开编辑器。他不是在盯着 agent 的每一步，是一直在旁边跑着自己的产品。Agent 在改代码，他在用这个产品。

这两件事可以同时发生。冲突的不是”用 agent 跑”和”在 loop 里”——冲突的是把”agent 在跑”理解成”我可以不用了”。

品味的判断权不能外包

读完 jlongster 那篇，我把 agent 接管的那个模块打开，像新用户一样从头点了一遍。第三步我的手停住了：填完表单，手指习惯性地敲了回车，没反应——确认按钮在弹窗右下角，必须用鼠标去点。测试是过的，逻辑也没问题。这种”说不出哪里不对，但用着就是别扭”，是 review diff 找不出来的。

Agent 给不了你品味判断。倒不是说它傻，是说品味来自于使用，而 agent 不用你的产品。你把品味的判断权交出去，就是把它交给了一个从来不用你产品的东西去填。它填的是它训练数据里最常见的那种，不是最适合你产品的那种。

你不用微观管理 agent 的每一行代码，但你必须保持使用这个产品的习惯。 执行可以外包，品味判断不行。

越晚发现，越贵

有人会说：问题早晚会暴露，用户反馈，然后改。

改 f 键改成 Tab 键，一句话的事。但 agent 用的那个”拧巴的操作流程”，如果已经成了三个功能的交互基础，用户也开始有了肌肉记忆，这时候再改就是破坏。

而且更安静的情况是：用户不会告诉你”这个流程拧巴”。他们只是觉得不顺，然后用少了，然后流失了。你出了 loop，看不见这件事在发生。

jlongster 原文里有一句话值得直接引：你能出 loop，是因为 agent 给你了这个选项。但你的用户没有出 loop，他们每天都在用你做的东西。

---

用 agent 提速是真的——但前提是，你还在用你做的产品。不然快是快了，但快的方向是错的，你不知道。

你的用户没有出 loop。你凭什么出去？