两看相厌：Agent 和传统软件，都觉得对方是屎山

ESSAY

一个传统后端工程师看 Claude Code 自动生成的代码，命名混乱，不遵守团队规范，几百行逻辑挤在一个文件里。他的评价：屎山

反过来，一个跑在 Claude Code 上的 agent 试图调用这位工程师维护了三年的系统。登录要 session，改个配置要导航五层菜单，接口文档是给人类读的散文体，报错信息是一句自然语言弹窗。agent 的评价大概也差不多

两边都觉得对方不堪用。这个状态，叫「两看相厌」

历史上每次出现这种互相嫌弃，都是范式切换最诚实的信号。汇编程序员嫌高级语言臃肿浪费，高级语言嫌汇编不可维护。C 程序员嫌 Java 慢得离谱，Java 嫌 C 的手动内存管理是野蛮操作。每一次，双方在各自的评价体系里都是对的

但最终的结局，都是出现了一个新的中间层，让两边不再需要直接面对对方

过去每一次，都是两代程序员之间的事。这一次，其中一方换了物种

人类工程师的嫌弃清单

AI 写的代码确实有一堆问题

不遵守团队约定的命名规范、目录结构、注释风格。几百行逻辑塞进一个文件。没有模块化，没有抽象层，写完就扔。在任何一个 code review 里，这种代码都会被打回

这些嫌弃完全合理，在人类工程师的评价体系里

但这里有一个前提值得拆开看：人类对「代码质量」的直觉，建立在一个假设上。这段代码要被人读很多遍。要被维护，要被改，要被另一个人在凌晨三点 debug 的时候读懂

如果代码只被执行一次然后丢弃呢？评价标准就应该从「可读性」变成「执行正确性」。这两个标准选出来的代码，长得完全不一样

而且这一侧的问题有一个重要特征：它在自动消解。明年的模型写出来的代码就比今年干净一大截，后年更好。这条曲线在自动上升

记住这个特征，后面会用到

Agent 那边嫌弃什么

Agent 看传统软件，嫌弃的东西更多，也更根本

鉴权。传统软件的登录、session、cookie，整套体系围绕一个假设设计：有一个人坐在屏幕前，持续操作。agent 的调用模式是无状态的、高并发的、随时中断再随时恢复的。这套假设从根上就不匹配

状态耦合。传统前端框架把数据状态绑在 UI 组件树上。agent 想操作一个数据，必须先理解组件的嵌套层级。CLI Anything 做的事情之一，就是把数据从 UI 组件里解绑出来，让 agent 能直接触达

版本更新。人类有 changelog 和迁移指南可以读。agent 需要的是机器可读的接口变更 diff。现在几乎没有软件提供这个东西。每次软件更新，agent 之前建立的调用逻辑就可能失效

配置体系。传统软件的设置页面有几十上百个选项，散落在各处，给人类慢慢调。agent 需要的是一个声明式的配置 schema，一次性把所有偏好注入进去。要改一个设置项，可能得导航五层菜单

这四件事有一个共同点：全部围绕「操作者是人类」这个假设设计。当操作者换成 agent，假设本身就塌了

和上一段对比一下。人类嫌 AI 代码烂，这个问题会随着模型变强自动消解。但 AI 嫌传统软件不好用，这个问题不会自动消解。已经部署的几百万个服务，不会自己重新设计鉴权体系，不会自己把状态从 UI 组件里解绑，不会自己生成机器可读的版本 diff

这是一个根本性的不对称

心智模型断了

上面讲的是接口层面的冲突。再往下一层，还有一个更深的断裂

人类程序员理解一个系统，靠的是「心智模型」。入职一家公司，花几周甚至几个月，把整个系统的架构、数据流、模块关系内化成脑子里的一张地图。之后的每一次修改，都在这张地图上定位、操作

Agent 没有这张地图。每次进入一个代码库，都是从零开始构建上下文

过去几十年的代码组织方式，都预设了一件事：读者已经了解整体架构。文件拆分、模块划分、命名约定，全部建立在这个预设上。一个有心智模型的人，看到 UserService 就知道去哪里找 UserRepository。agent 不知道，它需要先遍历目录结构，读若干个文件，才能建立起局部的上下文

这也解释了一个让人类工程师很难接受的现象：agent 倾向于把逻辑集中在一个文件里。从 context window 管理的角度看，减少文件跳转就是减少 token 消耗，集中在一起反而是最高效的组织方式

人类几十年积累下来的工程规范（模块化、关注点分离、DRY 原则），在 agent 的评价体系里，大概率需要被重新审视。这些规范存在的理由是帮助人类协作。如果协作者换了物种，规范本身就得跟着变

GitHub 上出现了非人类的绿点

Agent 已经开始往 GitHub 上提交 PR 了

传统开源社区有一套围绕「人」建立的协作制度。人类写 PR，人类 review，人类 merge。你的 GitHub profile、commit 历史、社区里的口碑，构成了一个完整的声誉体系。谁靠谱、谁的代码可以信任，大家心里有数

但当 agent 开始参与，这套体系就遇到一个很实际的问题：你怎么给一个 agent 建立 reputation？一个 agent 的 PR 应该由谁来 review？如果答案是「由另一个 agent 来 review」，那人类在这个闭环里扮演什么角色？

开源社区大概是第一个正面撞上这个问题的地方。但这个问题会蔓延到所有围绕「人」组织的协作制度里：代码审查、质量认证、专业资质、知识产权归属

这些制度的底层假设都是：参与者是人。当参与者不全是人的时候，制度本身需要重建

这个不对称里的机会

「两看相厌」里最值得盯住的，是那个不对称

AI 对传统软件的嫌弃，催生的是一个真实的改造市场。谁帮传统软件长出 agent 可用的接口，谁就是这次范式切换里的基础设施提供商。CLI Anything、MCP、飞书 CLI，都是这个方向上不同的入口

它们做的是同一件事：帮现有软件「再接口化」，从为人类编译，变成同时为 agent 编译

纯数据驱动的服务（Boss 直聘的工作信息、小红书的用户内容），数字层占比最高，被 agent 接管的速度最快

触发物理世界交付的服务（美团、Uber、顺丰），数字端的操作本身很简单，但最后一公里需要物理实体介入。agent 只能完成前半段

需要法人背书的服务（银行转账、合同签署、投行报告），数字层完全可以自动化，但合规框架要求背后有真实的责任主体

依赖几十年积淀的专业黑盒的服务（FFmpeg、Blender 的几何求解器、CAD 引擎），agent 离不开它们，但会重新定义入口

「两看相厌」不会永远持续

历史上每次范式冲突的结局，都是出现了一个第三方的中间层，让双方各自面对中间层，不再直接面对彼此。汇编和高级语言之间出现了编译器，C 和 Java 之间出现了 JVM

历史上每次「两看相厌」的结局，都是第三个物种出现

这次的「第三个物种」，大概率是一种「双栖软件」。天然同时暴露人类界面和 agent 接口，两边的数据和状态实时同步。人类在 GUI 里编辑到一半的东西，agent 可以在 CLI 里接着完成。agent 在 CLI 里产出的东西，人类可以在 GUI 里继续调整

最先做出这种双栖架构的团队，可能拿到下一代软件基础设施的定义权

AI 不吃软件，AI 吃接口

软件会活着。FFmpeg 会活着，Blender 会活着，CAD 求解器会活着。但它们的入口会被重新定义

说不准这个中间层最终长什么样。MCP 是一种可能，CLI Anything 是一种可能，某种还没被命名的东西也是一种可能。窗口期大概率很短，一两年内就会有一个被广泛采纳的方案出现

现在唯一确定的是：两边都在嫌弃对方，而两边都是对的