## Coding 是一个开始，还是一个例外 （TODO：标题带有逗号）

ChatGPT 让 LLM 大火之后很长一段时间里，coding 场景上的应用并不比别的场景更出色。写文案、做表格、答问题、生成图片，大家都在同一个起跑线上，而且都能感觉到模型隔几个月就变强一截。当时要是有人断言，几年后 AI 最有价值的落地场景会是写代码，多数人大概会觉得这只是一句行业内部的偏袒。

后来的事情我们都知道了。Anthropic 对 coding 的重视，把 coding 做成了 AI 最有价值的场景之一，也让「模型到底能不能变现」这个问题暂时有了一个可以拿出手的答案。在我看来，它甚至支撑住了那点岌岌可危的 AI 泡沫。

这件事之所以让很多人反复琢磨，是因为它并不符合直觉。不止我一个，不少人花了一段时间才消化过来：为什么跑出来的是 coding。而更要紧的是，现在普遍的看法是，coding 的成功只是开始，接下来会有更多应用场景爆发——毕竟那么大的投资规模需要更大的叙事来支撑。（TODO：严禁破折号）

所以我想问的是：coding 是一个可以推广的开始，还是一个极其独特的例外。它当然会继续发展下去——那么它成功的几个原因里，有多少可以复制到别的场景里去，能复制的又有多少。（TODO：严禁破折号）

## 智能体卡住的地方在于如何表征这个世界

要回答这个问题，得先绕开一个被反复讨论的层面：模型够不够聪明。

先说 Frame Problem。它听起来抽象，其实说的是一件很朴素的事：一个系统要做对某个动作，就得知道哪些事情会因为这个动作而改变、哪些不会。麻烦在于，现实世界不会附赠一份清单，告诉你「相关的就这些」。哪些信息此刻重要，哪些可以忽略，这个问题本身没有先验答案，只能靠系统自己去框定。框错了，它的推理没错，结论还是错的。这就是所谓的框架问题：不是不会推理，而是不知道该把哪些东西算进推理。（TODO：不是而是 问题，这句可以改成：这就是所谓的框架问题：系统不知道应该在推理时考虑哪些合适的条件）

POMDP 说得更直接一些。它是「部分可观测马尔可夫决策过程」，名字拗口，（TODO：前面这部分可以改成：POMDP，即「部分可观测马尔可夫决策过程」，它也是类似的理论，）核心意思一句话就能说清：智能体面对的世界是部分可观测的，它看不到完整状态，只能根据历史观察去估计当下发生了什么。于是真正困难的不是决策算法本身，而是它用来理解世界的那套表征。表征错了，或者根本建不出来，再强的推理也无处安放。

这就是智能体落地时那道真正的坎。它不是「模型还不够聪明」，而是「世界太滑了，抓不住」。（TODO：不是而是，可以改成 模型是否聪明已经不是对世界穷尽表征的瓶颈）

而这恰好能解释 coding 为什么特殊。代码领域是一个已经存在的、绕开了这些问题的世界。（TODO：前面加上”因为“）

Brooks 说过一句很有名的话：世界就是它自己最好的模型。他的意思是，与其在系统内部艰难地重建一个世界的表征，不如让系统抛开一切中介，到世界里去感知和行动。大多数领域并没有提供这样的便利，因为它们的「世界」散落在人脑、会议、纸面约定和口头共识里，智能体没有单一可读取的对象。

但代码领域不一样。它本身就是一个被完整写下来的世界：所有状态都在文件里，所有变化都通过提交记录呈现，所有规则都由编译器、测试和运行时来执行和检验。你不需要在模型内部重新表征这个世界，因为这个世界的表征就是它自身，智能体可以直接读取它、修改它、运行它、回滚它。

## Coding 的优势，是被工程体系准备好的（TODO：标题中带逗号）

沿着表征这条线索考察下去，coding 的那些独特优势每一件都能对上前面那个问题，「模型特别会写代码」这种含糊的说法已经不够用。

它有明确的输入和输出。需求加已有代码库是输入，一组可运行的修改是输出。「这一轮做完了没有」不靠感觉，靠代码能不能编译、能不能跑通。（TODO：不是而是 问题）这就是框架问题被外部解决了：相关和不相关的边界，不靠模型临场猜，而是由需求、代码库和测试共同划出来。（TODO： 不是而是 问题）

它有密集而且廉价的可验证性。测试能发现大量错误，Diff 能精确指出改了什么，Review 能判断方向对不对，版本管理提供了犯错之后的退路。模型写错代码并不可怕，因为后面还有一整套东西接着。（TODO：”接“这个字的AI味太重，单独出现时要严格禁止）

它的反馈是连续的，不是一次性验收。（TODO：不是而是 问题）写代码不是「交出去然后等三个月看结果」，而是每一步都能立刻知道对不对。（TODO：不是而是 问题）

它还有成熟的工具链可以调用：仓库、编译器、测试框架、CI、监控、日志。Agent 不需要从零发明一个软件世界，只需要学会在正确的时候使用这些工具。（TODO：不是而是问题，但是在这个语境勉强能够接受）

这些条件有一个共同的来源：AI 写代码以前，软件工程已经这样运转了很多年。LLM 补上的是过去很难用传统程序完成的那一段——理解自然语言里的需求，读懂大量已有代码，根据上下文生成修改，再根据测试结果继续调整。（TODO：破折号，加上平铺式描述）它补上的是理解和判断，而别人早就替它铺好了那条轨道。用前面那套话说，代码领域不需要智能体自己解决表征问题，因为表征早就被写下来，早就由工程体系维持着，也被每一轮反馈不断校正。

所以 Coding Agent 能成功，是因为模型能力恰好落在了唯一一个已经被完整工程化的世界里。别的领域难以照搬复制这套做法，原因在于它们真正缺的往往是那个「世界」，模型那部分它们并不缺。

## Service 和 Operations 的结构相似程度有多高

那别的场景呢？围绕这个问题有两种说法，彼此差别很大。

一种是：Service 和 Operations 结构上根本不像 coding，只是长得像。如果这样，可迁移性弱就是性质判断，coding 的成功基本上是一次孤例。

另一种是：它们结构上像，只是成熟度不够。我在之前那篇讲 Agent 该建在哪里的文章里，把这类工作归成过三种模式：Build、Service、Operations，也说过程度不够会带来什么。现在回到这个主题上，我的判断仍然是后者：它们已经是最接近的两类了。只是这次我想把「像」说得更具体一点，讲到具体的环节，不必再把两边都有的条件重复罗列一遍。

Build 和 coding 的关系，其实是一回事的两面。我自己原来那篇文章里说的 Build，指的就是那种围绕一个数字对象反复修改、可以测试、可以交付的工作，coding 正是它的原型。这一类本来就同构，所以不存在「像不像」的问题。要区分的其实是 Service 和 Operations 这一类。

Service 的典型是客服。客户说什么完全不可预测，同一个问题有几十种说法，话里还带着情绪、历史和各种例外。但从 workflow 看，客服已经被企业建设了很多年：识别身份、读取账户和历史、按知识与业务规则判断、调用后台系统完成动作、处理不了就升级、最后用解决率和重复咨询率衡量效果。（TODO：平铺式描述）真正长期困扰传统自动化的，恰好是前面几步——客户不会按数据库字段说话，他会问「为什么我的钱还没有回来」，系统则需要判断这句话对应哪笔交易、退款到哪一步、适用什么政策。（TODO：平铺式描述，破折号，禁用词”真正“）这一段正是 LLM 擅长补的。（TODO：”补“是一个单字动词）企业内部的 IT Service 结构完全一样，只是服务对象从客户换成了员工。

把它和 coding 并排放在一起，可以一直比到具体的环节。（TODO：”放“、”比“两个单字动词）coding 里「读懂需求」对应客服里「读懂这句话要干什么」，两边都要把自然语言落到一个明确对象上，这就是同构的部分，也正是 LLM 补进来的那一段。但这一步往后，两边就走上了不同的路：coding 里理解完需求，接下来产出的是可以编译、可以运行的代码，对错几秒内见分晓；客服里理解完需求，接下来要调用业务规则和后台系统，动作有没有做对，要等一段时间的解决率和客户反馈才知道。同样是「理解」这一步，后面要处理的对象却不一样，同构的关系到这里就结束了。

Operations 是另一个。它和前面最大的不同是，工作不一定等人提出请求：服务器延迟突然升高、网络大量丢包、设备振动异常，这些事件自己就会发生，先由系统把异常暴露出来，再交给人判断和处理。安全运营是目前比较成熟的例子，整条工作链正是围绕这一点展开的——读日志、关联身份和行为，判断是误报还是真实攻击，再决定要不要隔离。往外的 SRE、网络运维、制造设备、园区摄像头监控，输入形式不同，工作结构却很接近。

和 coding 对照，Operations 里最像的是「观察和诊断」这一段：输入是持续产生的系统状态，输出是异常被发现、处理并恢复，和 coding 从代码库到修改的结构确实同源。分叉同样在反馈的形态上。coding 的每一次改动都是一次可以立刻验证的假设；Operations 的一次处置是不是对的，往往要靠后面一段时间的指标才看得出来。

这三类工作的共同点，恰恰就是代码世界那些条件的弱化版：有明确的触发，有还算清楚的输入输出，有可以调用的工具，有方法判断做得好不好，而且评价结果还能回到系统里，成为下一轮的依据。（TODO：平铺式描述）

但「弱化版」这三个字很重要，而且它不只是程度上的差距，还是表征条件和反馈条件一起变弱。同样是可验证性，代码是编译和测试，几秒钟出结果，错误定位到行；客服是问题有没有被解决，靠事后的解决率和客户反馈；运维是系统有没有恢复，要等指标出来。同样是可回滚，代码可以 revert，一次错误的客诉处理或者设备操作往往收不回来。同样是工具链，代码的工具是给机器用的接口，企业的 CRM、知识库和业务系统，很多环节还依赖人手动操作。（TODO：平铺式描述）

这里就要认真回答那个「程度差距为什么致命」的问题。反馈延迟不只是慢一点，它会改变这个系统还能不能被迭代。当一轮动作和它的结果之间隔了很久，而且中间掺进了大量别的变化，你就很难把结果归因到动作上——做对做错，学到的东西都变模糊了。（TODO：破折号）做错了又不能轻易撤回，试错的代价就变成不可累积的：一次坏动作不是一次可以吸收的学习机会，而是一笔要单独承担的损失。再叠上工具链里那些必须靠人手过的环节，整条回路的闭合周期会更长。三样东西互相放大，差距不会停在线性上加起来的程度，它会在迭代能力上累积成质变。（TODO：平铺式描述）

所以我的结论是：Service 和 Operations 是结构上最像 coding 的领域，也是最有可能跑出来的两类，是这个问题上最该往下走的方向，虽然它确实很难。它们和 coding 之间的差距不是「还没用上最新模型」这种可以靠升级弥补的差距，而是反馈密度、可验证性和可回退性的差距。这个差距不是性质上的——它们的结构确实支持工程化——但它相当程度上是程度上的，而程度上的差距累积起来也可以非常致命。

这就是为什么我对「接下来会有更多场景爆发」这个说法保持距离。不是因为别的领域不可能成功，而是因为它成功的难度远高于把 coding 的成功经验平移过去。

## 要能关闭回路，而不是先画一张规划图（TODO：标题出现逗号）

那还能做什么？我的看法是，方向要从「怎么规划一个完整的智能体」换成「怎么先让一个回路能关闭」。

传统做法是先画图：把一项工作拆成若干步骤，规定每一步的输入输出，设计好流程，然后让 AI 去执行。这套思路在 coding 里能成立，是因为软件工程早已画好那张图，你只需要把内容填进去。在没有这张图的领域里，硬画出来的规划往往在遇到第一个例外时就崩掉。用前面的话说，硬画规划等于在没有表征的地方假装已经有了表征。

以反馈的方式建构，意思是反过来做：先找到那个能让现实给出反应的最小环节，让系统在那里动起来，看结果，再根据结果调整。这一轮做完，我能不能知道它做对了还是做错了，这个判断能不能变成下一次的输入，才是我用来衡量的标准。

这里值得把「回路」讲得再具体一点，因为它是整篇文章的核心自查点。（TODO：播报意图）

一个完整的回路要有四段：系统做了一个动作；现实产生了一个后果；这个后果能被观察到，并且能分辨出是好的还是坏的；这个判断能回到系统里，改变它下一次的动作。四段里缺了任何一段，这条反馈链在这个位置就无法闭合成环。缺少反馈的地方不会自己长出反馈来，只会不断堆积产物。（TODO：长出反馈，是一种无意义的拟人）

拿园区几百路摄像头来说。一个人要长时间注视几百路画面，根本撑不了多久，看得越久越麻木；这里最大的难处就在于持续观察本身，跟某一个画面好不好理解没有关系。（TODO：后半句的补充属于防御式描述）AI 先从大量画面里找出异常，人再确认是不是真风险，确认的结果又回去修正系统的判断。它不用第一天就接手整个安防团队，只要能把这轮机械观察压缩成少量需要关注的事件，价值就已经成立。这里四段都在：AI 提出候选，人承担判断，判断可观察，而且会回到系统里。所以它的回路从第一天起就是闭合的，它也因此能跑出来。反过来，一个生成报告的流程如果没人读、没人据此做决定，那它的第三段和第四段根本不存在——产出再多，回路始终没接上。

按照这个标准重新理解 Build、Service 和 Operations，我们看到的就是另外一层含义。它们是三种「回路长什么样」的观察，而不是一份需要照章执行的分类表：Build 从目标开始，Service 从请求开始，Operations 从事件开始。它们先跑出来，原因在于它们背后的行业积累最厚，回路最容易接上；换个角度看，它们也是最有可能慢慢把表征问题处理好的三类工作，因为它们的表征本来就有地方可读——代码在文件里，请求在工单和知识库里，事件在日志和监控里。

所以找智能体的落点，不该从部门和岗位问起。「能不能做一个 AI 财务」这种问题通常答不好，因为一个岗位里混着好几种完全不同的工作：HR 里，回答休假政策属于 Service，新人入职触发账号和设备准备更像 Operations，改某个数字系统的配置又是一种 Build。真正值得找的是那些已经存在多年、持续发生、并且有机会关闭回路的 workflow——输入在哪里，一轮结束该产生什么结果，能调用什么工具，做得好不好怎么判断，出错谁能发现，人的修正能不能成为下一次的反馈。这些问题有答案，智能体才算有了可以站进去的位置。（TODO：破折号，以及平铺式描述）

## 别沉迷于产出物的幻觉

我不太担心 AI 让人做出更多东西这件事本身。我更在意的是，行业叙事正在把「产出物变多了」当成「能力变强了」，再把这种个人层面的惊喜，直接推导成组织效率的提升和更大规模的投资合理性。一个普通人借助 AI 做出了像模像样的网页、报告、小工具，这当然是真实的体验，但验证、复用和长期维护把 demo 意义上的价值和生产力意义上的价值分隔开来。当评价口径被悄悄替换，展示的是惊喜，宣称的是革命。（TODO：这句话逻辑不通畅）

这种叙事与 coding 跑通路径所面对的技术问题，其实是同一问题的两面。coding 之所以能跑出来，是因为它周围有测试、有 diff、有回滚、有运维，产出物被真实世界的反馈反复检验过，表征有人替它写好了，回路也早就闭合了。而在那些没有这套东西的领域里，产出物的繁荣格外危险：它看起来像成果，但没有任何机制告诉你它对不对。如果我们在一个反馈回路尚未闭合的地方，靠产出物的数量和精美程度来判断进展，那我们得到的很可能只是堆积。

我不认为 coding 的成功可以照搬，也不认为别的场景注定不行。真实的情况是：这件事很难，难在需要先弄清楚每个领域自己的表征障碍在哪里、反馈能不能接上、代价能不能承担——但它并非不可能。区别只在于，我们是愿意花力气去搞清楚这些内在原因和真实约束，还是满足于屏幕上那个越来越好看的产出物。

前者慢，而且经常让人失望；但它至少是朝着能关闭回路的方向前进的。