Coding Agent的墙式散文：为什么我们需要它用眼睛能看懂的方式说话

Agent在纸面上越来越聪明，用起来的体验却在一个关键维度上明显变差。以前大家喜欢Claude的声音、性格和“灵魂”，现在这些东西在RL的地牢里被冲刷干净。每天都能收到这种回复：整墙术语、层层嵌套的解释，眼睛直接开始发麻。连前Reddit CEO、pi的作者Mario Zechner、Replicas的Connor都公开吐槽过同样的问题。有人甚至专门写了/bro技能，只为求模型“说人话”。

我起初以为只要再提示一次“简化语言”就够了；后来每天被这些墙式散文淹没，才意识到真正的问题不在词汇，而在信息形态本身。人类视觉皮层经过数百万年训练，处理丰富视觉信息几乎不费力；分析大段文字却又累又慢。工具必须适配人的心智，就像斧头必须适配人手。

用视觉约束替代墙式文字

我们内部开始尝试让Agent用简洁视觉来解释正在发生的事，而不是堆砌散文。这套方法被做成了show-me技能，已经在humanlayer里上线，也可以接到其他coding agent上。

核心就一句话：show me。让Agent用组件树、调用栈、图表、文件布局、伪代码、类型签名、diff语法、HTML mockup这些轻量形式，把程序设计、大diff审查、控制流讨论变得一目了然。它比HTML还轻、还快，对绝大多数开发形状的问题已经足够好。

程序设计阶段很多人现在直接跳过，但我认为它仍然关键。你应该先讨论代码的形状——类型、签名、调用栈——再让Agent动手写。同样的技术也能用来事后探索大diff，决定审查时该挖哪里。

几种真正能用的视觉形态

组件树：前端问题里，只保留真正重要的状态hooks和模块边界，其余全部省略。

调用栈：后端或编排类问题，直接画出控制流形状。有人甚至写了工具从AST直接算出这些栈。

图表：如果聊天界面支持内联Mermaid，状态图和时序图往往比文字更直接（偶尔还是会有slop，但通常比读字好）。

文件布局：浅层文件树，每行只写一个职责。适合回答“这东西住在哪”和确定重构范围。

伪代码：算法类问题里，往往比真实代码更紧凑。

类型与签名：代码存在之前的形状——对架构文档来说太内部、但对Agent来说又容易写错的部分。

diff语法：大部分内容不变时，直接用diff形式展示组件变化、调用树变化、文件布局变化，甚至状态/控制流的伪代码变化。

HTML mockup和HTML图表：很多原型工作已经用HTML取代了Figma。Agent可以直接在回复里塞HTML，或者你打开浏览器看。

这些形式的共同逻辑很简单：把“分析信息”的重活，转交给已经进化了数百万年的视觉通路。

为什么这比单纯简化语言更有效

单纯要求“少用术语、说人话”只能治标。Agent智能提升后，它仍然倾向于用最完整、最防御性的文字把自己的推理过程全部倒出来。视觉约束则从形态上强制它压缩：必须选出真正重要的节点、边界和关系，其余全部丢掉。

结果是，人类注意力可以重新聚焦在真正需要判断的地方——品味、意图、架构——而不是先穿越一堵术语墙。下游的人只在自动化护栏失效时才被拉进来，注意力变得稀缺而精准。

怎么立刻用起来

安装技能后，直接调用/show-me，或者明确要求Agent使用show-me技能。指向一个路由、服务、功能、PR或当前话题，也可以只让它把刚才的问题/陈述重新用视觉方式说一遍。

“内容太多了，show me。”
或者
“/show-me 用HTML explainer的形式。”

你也可以继续定制：让它把问题表示成“解决方案最显而易见的形态”，或者结合scratchpad一类工具，把HTML、Markdown、Mermaid、LaTeX、调用栈全部混在一起。

Agent已经能写大量代码，下一步真正拉开体验差距的，不是再多一点智能，而是让它说话的方式重新适配人类的感知通道。视觉不是装饰，是约束，也是背压。

你最近一次被Agent的墙式回复劝退，是在讨论什么类型的问题？组件结构、控制流，还是大diff？欢迎直接贴场景，我们一起试着转成视觉。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。