本意很直接：从微信讨论、X 平台动态和日常工作卡点里，自动抽取选题、调研、成稿并发布。原本需要坐下来反复折腾的一串动作，全部交给了工作流。

从工程上看，这件事做得很顺。信息在进，文章在出，系统每天都在稳定发布。

但跑了一段时间，一件怪事浮上来了：网站每天都在产生新内容，随笔却彻底停了。

随笔列表的最后一篇，停在 8 月 23 日。(challenwang.com)

不发文章不等于不思考。但那种抓到一个新鲜苗头、愿意坐下来琢磨半天、跟模型来回较劲的冲动，确实淡了。

搭这套系统的初衷是帮自己沉淀认知，结果文章堆得越来越高，人反而被挤出了思考。

70 分的及格分，杀死了思考的悬念

仔细想想，ainews 和随笔吃的是同一批原料：群聊里的争论、X 上的新变化、手头项目的卡点。

以前遇到个有意思的事，只要没想透，它就是脑子里一个化不开的疙瘩。为了把它捋顺，得找模型盘逻辑、翻资料、推翻假设、找现实反例。整个过程敲键盘的时间其实不多，真正耗费的是一次次推翻重来的判断。

现在，流水线把这套链路一口气跑完了。同样的信息源，一转眼就变成了标题工整、结构齐整、甚至已经公开发布的成品。

按自己的尺度衡量，这些东西大多在 70 分上下。说不上错，但也绝没有往深处追。

诡异的地方就在这里：面对一堆 70 分的现成文章，根本不会有把它改到 90 分的冲动。

冒出来的念头往往是：行吧，大差不差也就是这个意思了。

“大差不差”最要命。

没写出来的问题，悬在心里才有张力；一旦白纸黑字发在线上，哪怕知道它粗糙，潜意识也会觉得“这事已经翻篇了”。何况上面还挂着 AI 生成的标记，再去改它，总觉得是在帮别人补作业，根本提不起精神。

流水线没有浪费时间，却把思考的悬念提前抹平了。

退一步讲，就算系统明天能自动生成 90 分的雄文，问题只会更严重：机器写得越滴水不漏，人就越没有下场的借口。

文章只是副产物，脑子里长出来的才是主料

这背后的别扭，其实是把两件事给搅和了：一件是内容的高效量产，另一件是借着写东西让自己长进。

折腾各种 AI 工具和开源项目，顺手把体会发出来，本质上是把工作过程公开化（build in public）。在《学 AI，不是给大脑刷短视频》(challenwang.com)里聊过一个逻辑：见过一样东西，和真正搞懂它，隔着十万八千里。

写随笔就是那个“搞懂”的过程。

有些念头刚冒出来时觉得精妙绝伦，一旦落笔，才发现连昨天的线上故障都解释不通；有些结论起初下得斩钉截铁，跟模型来回辩上几轮，才被逼着标出适用边界。这种被卡住、推倒、重构框架的折磨，字数统计看不到，但长出来的肌肉全在脑子里。

写随笔图的从来不是几篇存稿。文章只是思考排出来的副产物，真正值钱的，是在打磨过程中被反复修正的认知。

公开发布也是为了倒逼自己想透。但最大的陷阱，是把流水线吐出来的成品，当成了自己的认知资产。

自动化绕过了大脑，直接把产物印了出来。提示词跑完了，原本要练的功夫却被截胡了。

机械摩擦要归零，认知阻力得留着

把摩擦力归零，向来是工程师的本能。

4 月写过一篇随笔，记录怎么把录音下载、转写、提炼文稿做到近乎无感。(challenwang.com) 今天看，这类纯搬运、盯进度、转格式的杂活，依然得往死里砍。整天泡在这些脏活里，毫无认知增益。

但随笔断更这记闷棍说明了一件事：自动化的刀，不能顺着“麻不麻烦”胡乱切下去。

把一个模糊直觉磨成硬核论点，确实极慢、极费劲，完全违背高效生产的原则。如果只求快速出稿，这些推敲全是需要优化的成本。

可如果要的是提升认知深度，这种推敲的折磨，本身就是不可替代的阻力训练。

分界线很清楚：这个环节的阻力，到底是在消耗人，还是在锻炼人。

无谓的机械消耗，全部丢给机器；关键的判断与取舍，少一次下场就少一次长进。

搭建 ainews 确实学会了编排机制，那是真实的收获；但当系统转起来之后，把流水线的空转当成了自己的长跑训练，纯属自欺欺人。

流水线越来越顺，人却在边上退化

做 Agent 架构总会绕到自我进化（self-improvement）：怎么收集反馈、怎么迭代策略、怎么防止漂移。3 月写 Agent 自我优化时，就在反复追问目标对象和评估标准。(challenwang.com)

这次断更逼出来一个最朴素的问题：这一圈优化下来，被进化的对象到底包不包括坐在电脑前的人？

如果只看发文频次、生成速度和文本评分，把人的参与度降到零，在系统看板上算是一次完美的提效。但荒谬的现实是：流水线越来越聪明，负责搭系统的人却越来越迟钝。这种优化，本质上是奔着初衷的反方向在狂奔。

验收个人工作流，死盯产物指标没有任何意义。

真正该问的是：最近有没有哪个根深蒂固的偏见被现实砸碎了？碰到个新棘手场景，脑子里的雷达是不是比三个月前更管用了？

这些体感很难落进监控大盘，但只要在目标里漏掉了，人就会被系统悄悄架空。

把流水线截断在最难受的地方

想明白这层关系，没必要把 ainews 一棍子打死，但必须把它的手缩回去。

公开资讯的搜集、抓取、清洗和事实摘要，继续由它跑，这能省下大量无聊的信息搜集时间。

但凡是涉及个人思考的随笔，流水线必须截断在最难受的地方。

随笔不能这么写。机器把事实拼出来、把矛盾挑明就该刹车，甚至只撂下几个扎手的问题就够了。千万别急着给出一篇起承转合齐全的现成文章。

就像这次，真正把人敲醒的，根本不是什么关于自动化的利弊分析，就是那个刺眼的现实：网站天天在更新，自己的随笔却断更了。

哪怕最初只有一段两分钟的散碎语音，或者几句逻辑不通的粗暴判断，也必须由真人先把第一锹土挖下去。

有了自己的锚点，再让模型去找反例、挑逻辑漏洞、查证事实。

关键不在于观点是不是百分之百原创。真正的分水岭，是有没有亲自被那个问题折磨过、推翻过，而不是因为机器吐出的文章工整体面，就顺手滑过去。

回头看，8 月 23 日断更前的那篇随笔，标题正好是《做自己的编排中心，还是做系统的执行插件》。

当时聊的是个体怎么调用工具，结果转头自己就当了自动化的甩手掌柜。

工程上的确定感和流水线飞转的爽感，太容易让人上瘾了。人在这种自动化幻觉里，很容易误以为“事情做成了”就等于“自己变强了”。

网站能持续冒出新文章固然好看。

但更要紧的，是自己脑子里还有真正想不透、非得亲自写明白的东西。

先是看到 DeepSeek Harness 把 Everything is a Plugin 作为核心设计理念，模型、工具、Session、沙箱甚至执行循环本身，全都可以自由插拔。前几天我在《DeepSeek Harness 真正开源的不是代码，是替换权》里也讨论过这种把官方实现降格为默认插件的趋势。接着是 Codex 进一步开放自己的 Harness 和 SDK，不再只是把人圈在自己的客户端里，而是让任何独立应用都能直接调起它的代码执行能力。

这让我想起鸭哥之前做过一个语音识别 App。后来聊天时他说，语音识别可能从一开始就不该做成一个独立 App。用户真正需要的从来不是打开一个单独的录音软件，而是在任何需要打字的地方直接说话。

后来我把这套语音能力接进了自己魔改的鸭哥此前的 opencode-client，在终端敲代码或者写配置时随时按住说话，确实比在多个应用之间切来切去顺畅得多。

我一开始把这类动作简单归结为一个词：拥抱集成。

但顺着这个思路再往下想，集成只是表象。API 早就有了，插件也早就有了，软件行业几十年来一直在讲组件化和服务化。为什么到了今天，这件事突然成了整个行业最核心的叙事？

我的判断是：

AI 真正击穿的，不是单个功能的制造成本，而是围绕具体目标临时组织能力的编排成本。

这件事带来的连锁反应，可能远远超越代码与工具本身。它正在重塑软件的商业逻辑，开始影响组织的协作形态，也在悄悄重塑每一个身处其中的个体。

协作的本质：分工与编排的永恒博弈

要理解为什么编排成本下降会引发连锁反应，需要回到协作系统的底层逻辑。

无论是运行在服务器上的软件系统，还是由成千上万员工组成的企业组织，其运转逻辑本质上都包含两部分：

第一，是专业能力的生产（分工）。有人深耕语音算法，有人专注数据库优化；在企业里，有人负责写代码，有人负责跑销售，有人负责看财务。分工越细，单点的专业深度就越容易做深。

第二，是围绕具体目标的动态拼装（编排）。有了各个维度的专业能力之后，必须有人把它们按正确的顺序、传递正确的上下文、处理各种异常，最终合成一个完整的交付结果。

在过去漫长的发展中，单点专业能力的生产效率一直在提升，但动态编排的成本却始终高昂。

让不同的软件模块在运行时自由协商、传递状态，需要耗费大量的胶水代码与联调成本；让不同岗位的人针对一个临时目标高效协同，需要消耗巨大的沟通带宽与会议成本。

因为动态编排太贵、太不稳定，人类在数字世界和物理世界，各自发明了一种最经典的妥协产物：预制容器。

在软件世界里，这个容器叫独立 App 与软件孤岛。开发者把交互界面、业务逻辑、数据处理和计费系统封装在一个盒子里，做成预制的固定菜单，用户只能整体购买、按既定步骤点击。

在组织世界里，这个容器叫部门架构、汇报层级与静态 SOP。管理者把职能切成固定部门，制定规章制度与审批流程，层层传达、级级汇总，用固定的框架来防止协作陷入混乱。

预制容器从来都不是最灵活的解法，它往往伴随着僵化与冗余。但它是过去人类对抗高昂编排成本时，最有效的防御机制。

软件先行样本：预制容器的松动与控制权迁移

因为数字代码的接口摩擦力最小，AI 降低编排成本的苗头，最先在软件领域清晰地显露出来。

过去几十年，许多拥有出色核心技术（如语音识别、图表渲染、图像处理）的中小团队，明知理想状态是做成即插即用的组件，也倾向于做成独立软件。

这背后的商业考量很现实：过去终端用户缺乏自行编排的能力，组件只能等待大平台来集成。而一旦依赖大平台，团队就失去了直接面对客户的收费权，不仅要承担平台的分成成本，还面临被平台自研替代的风险。为了生存，大家往往选择给功能包上一层完整外壳，做一个体验相对割裂但能独立收费的孤岛型产品。

AI 的演进正在逐步改变这笔账。

AI 不仅在降低功能的生成成本，更关键的是，它开始有能力在运行时接管一部分理解目标、选择能力、传递上下文、安排执行顺序并验收结果的工作。

用户不再必须去买一套预先打包好的完整软件，而是可以拿着自己的私有上下文，通过 Agent 动态调起各个独立的专业模块：

语音能力直接嵌在终端命令行，查询能力直接嵌在笔记软件，代码执行能力直接嵌在浏览器。软件正在呈现出从“买一套预制功能”，走向“按需生成一次执行”的趋势。

当软件的预制外壳逐渐松动，一个值得关注的权力转移开始浮现：

能力的提供方越来越容易被抽象成可插拔的插件，而系统的价值和控制权，开始向掌握目标、私有上下文与验收权的编排层迁移。

规律的蔓延：当组织的静态容器开始被穿透

如果这种变化仅仅停留在软件工程领域，它充其量是一次技术架构的迭代。但协作的底层逻辑往往是相通的。

当数字世界的软件容器开始松动，由人组成的企业组织与分工模式，也开始显现出类似的演进趋势。

传统企业的组织架构之所以需要多层管理链路，很大程度上是因为信息跨层级传递的损耗较大。高层制定战略后，需要中层进行拆解和转译，变成固定的流程下发执行。这种静态编排虽然不可避免地带来沟通成本，但长期以来是维系规模化组织的必要手段。

然而，随着 AI 逐步能够辅助实时汇总一线数据、解析业务上下文并辅助拆解任务，传统组织赖以维系的“静态制度”，开始出现向更细粒度“动态调度”演进的苗头。

这就引出了宏观维度的第一个趋势：组织层面的编排权有可能进一步向上收敛。

在一些数字化程度极高的业务场景中，系统开始有机会把调度的触角延伸到更具体的业务动作。系统根据客户的实时反馈和项目的最新进展，动态向各个执行节点分发更明确的动作建议。

我不是说这种情况已经大范围发生，那确实没有。但这确实已经呈现出了某种趋势，而且随着工具链的完善，未来大概率会逐步深化。

十多年前科技界提出的“在 API 之下”（Below the API）概念，早期多见于标准化程度极高的线下配送与调度，比如网约车司机和外卖员，你也可以理解他们是平台算法在物理世界的执行工具。而在 AI 时代，类似的逻辑也开始在部分脑力工作中隐现，而终将逐步加深。基础代码编写、常规文案策划、标准化数据分析等工作，都开始不同程度地接入由 AI 辅助调度的协作链条中。

纯粹充当信息中转的角色面临被系统穿透的压力，而核心的编排与决策权力，则在平台和组织核心层呈现出进一步集中的倾向。

微观的逆转：普通人第一次拿到了调度世界的杠杆

但技术的演进从来不是单向的，硬币的另一面，是微观维度的第二个趋势：个人编排能力的边界正在被大幅拓宽。

在过去，“编排一个复杂体系为自己的目标服务”通常需要调动相当规模的团队和资金。如果你有一个商业构想或产品创意，单靠个人很难走完全部流程，往往需要招募多个专业角色共同协作。很多想法在启动阶段，就受制于协同成本而无法推进。

今天，这种门槛正在实质性地降低。

编写代码、设计界面、清洗数据、检索文献、调用外部接口，这些曾经需要不同专业分工才能完成的环节，如今正在变成越来越容易被随时调用的能力积木。

一个目标清晰的个人，只要拥有一台电脑和一个懂自己意图的 Agent，就能够把现成的能力模块组织起来，拼装出只为自己当下目标服务的专属工作流。

不需要先搭起庞大的团队架构，一个人借助 AI 的编排辅助，就有机会把一个想法从定义、开发、测试一直推向实际交付。

这正是当下最值得把握的红利：普通人开始拥有了调度多种专业能力、跑通端到端闭环的可能。

编排时代的个体：在系统与自我之间寻找支点

面对宏观上系统调度的集中，与微观上个人能力的释放，我们到底该如何定位自己？

很多时候，人们容易陷入非黑即白的二选一：要么悲观地认为所有人都会沦为系统的螺丝钉，要么盲目乐观地以为人人都成了超级个体。但真实的演进往往更加复杂，也更需要具体的立足点。

当编排成本逐步走低，行业里正在发生一个明显的价值分化：

那些通用的、标准化的执行动作，其边际价值正在快速摊薄。 仅仅是写一段规范的代码、画一张常规的配图、写一篇模板化的周报、做一份套路化的竞品调研，这些技能在 AI 面前越来越难建立真正的壁垒。

相反，有三样东西在变得越来越重要：

1. 对真实问题的定义能力：在执行变得便宜后，判断“什么问题值得被解决”成了最稀缺的能力。
2. 物理现场的私有上下文：系统再聪明，也无法凭空获取那些隐藏在水面之下的一线人际博弈、隐性业务规则和非标细节。
3. 最终交付的验收与责任承担：AI 可以给出多个备选方案，但谁来做最终的取舍、谁来兜底边缘异常、谁来对结果负责，决定了价值的终极归属。

理解了这三点，不同处境下的人自然能找到更实在的着力方向：

在日常职场中，最容易感到焦虑的，往往是那些每天只负责接收上游工单、填报标准数据、做固定格式流转的角色。这种纯粹的工时消耗型岗位，最容易被动态编排系统所替代。破局的关键，不是去和 AI 比拼标准任务的完成速度，而是主动深入那些系统触碰不到的真实业务现场，把用户真实的痛点、跨部门协作中未明说的阻力转化为高质量的信息输入；同时在关键节点敢于凭借业务直觉叫停错误、为复杂异常托底。在任何协作体系中，能处理异常、敢扛责任的节点，始终是最具韧性的核心资产。更重要的是，在工作之余，完全可以利用 AI 为自己搭建一套个性化的知识流或自动化工具，持续锻炼自己作为独立编排者的思维习惯。

对于正在学习成长的年轻人来说，学习的重心也需要发生转变。过去很多训练本质上是在培养“标准执行器”，把大量时间耗费在死记硬背语法规则、刷题复现固定答案上，而这些技能在 AI 面前半衰期极短。今天更值得培养的，是拆解复杂问题的架构思维，以及向 AI 清晰表达约束条件的能力。提升这种能力最直接的办法，就是尽早拥有自己的项目实践。哪怕只是为了解决生活中的一个小麻烦，去尝试写个自动化小脚本、搭个个人主页或做一个小工具，完整走一遍“提出问题、组织能力、调试报错、交付使用”的过程。能够独立跑通真实闭环的次数，往往比在标准化题库里的熟练度更能反映解决现实问题的真实潜力。

而对于尝试做产品或探索创业的人来说，这种视角的转变尤为关键。过去大家很喜欢讲“AI Builder”（AI 建造者），但在这个趋势下，“Builder”这个词容易给人一种误导，让人以为核心竞争力依然是从零砌砖、造一个封闭完整的独立产品。今天更贴切的定位，或许正在从“AI Builder”转向 “AI Orchestrator”（AI 编排者）。课代表的课，我记得去年的时候已经提到过 AI 熟悉程度的几个层级，其中的这个最高级，我想我到现在，似乎才明白一些其中的意思：Orchestrator 绝不是传统的技术架构师这么简单，编排者不再执着于重复制造每一个零部件，而是像一个交响乐指挥，把现成的高质量能力调度起来，为具体目标服务。

在这种视角下，当下最需要警惕的，恰恰是那些缺乏壁垒的“薄包装工具”。只是给通用的 AI 接口套一层好看的界面，试图靠信息差赚取溢价，在插件化和个人 Agent 演进的趋势下，很容易被底层能力的迭代直接绕过。真正能够立足的方向，要么是向下扎进特定垂直领域的深水区，去碰那些通用工具覆盖不到的脏活累活，掌握最专有的行业数据、业务合规与私有上下文；要么是向上做深与用户的专属信任，成为真正理解用户复杂意图、帮用户调度和把关一切能力的可靠中枢。

结语：一场关于编排半径的持续审视

一切皆可插拔、一切皆可编排的趋势正在逐步展开。

它没有带来绝对的平权，反而拉开了两极分化的张力：一极是庞大系统对微观执行的高效调度，另一极是独立个体对多样能力的灵活拼装。

这并不是一场需要非此即彼的零和博弈。

一个成熟的实践者，往往懂得在庞大的组织网络里，凭借不可替代的一线洞察与责任担当，做一个高价值、受信任的坚实节点；同时也懂得在属于自己的天地里，基于对真实问题的定义能力，借助现成的工具，做一个自主探索的编排者。

面对日新月异的技术与层出不穷的工具，我们或许可以在每一次动手实践时，都在心里做一次平静的审视：

在融入系统时，我们所扮演的执行插件，是否具备不可替代的高价值；而在属于自己的那方天地里，我们又是否真正握住了指挥棒，在为自己的真实目标编排一部专属的交响乐。

一位高级管理角色花了将近一个小时试用我们正在研发的数据智能问数系统。光是找对应业务的数据源就花了七分多钟；好不容易输入了一个问题，界面在漫长的两三分钟里没有任何明确反馈；最后吐出结果，系统先自作聪明选了一个主题，接着又弹出一堆指标、维度和过滤条件，让用户继续在对话框里手动点选确认。折腾到最后，这道题依然没有跑出一个准确的有效答案。

那一刻坐在旁边，我的体感极其强烈：这根本不是什么划时代的 AI-Native 体验。这本质上就是一套传统的手工多维分析系统，只是工程师把原本在页面上点选的复杂配置，极其生硬地切碎后塞进了对话框里。更糟糕的是，系统不仅没有替业务解决问题，反而在把数据治理的缺口、指标口径的歧义和底层的判断责任，一股脑地甩锅给屏幕前的用户。

这场试用让我们团队彻底停了下来。当天上午，我们做出了一个在过去几个月里最艰难、但也最清醒的决定：全面叫停“全业务自由问数”的宏大叙事，删掉汇报材料里所有关于“全覆盖”的承诺，把交付范围断崖式收缩到少数几个业务；在没有业务语义、权限不足或证据不全时，必须坚决、可靠地拒答。

很多人以为，企业 AI 的成熟度体现在它能支持多少个业务场景。但真实生产环境的残酷教训告诉我：生产级 AI 最重要的能力不是多回答，而是在语义、权限和证据不足时可靠拒答，并把用户导向一条可控的责任路径。

为什么删承诺比加功能难十倍

在技术团队里，做加法永远是顺人性的。

业务方提一个新诉求，工程师顺手加两张表、再包一个 Prompt、多挂一个组合 Skill、在中间抽象一层动态路由。每个人在周报和汇报材料里都能写上光鲜的“新进展”，架构图越来越花哨，支持的业务线列表越来越长。

但这种热闹掩盖了一个极其致命的事实：在没有业务知识和语义治理的前提下，让大模型直接面对裸库生成查询，准确率普遍只有 30% 到 40%。

我们拉出现场的真实评测数据：即使是由懂业务、懂数据的专业人员去使用主题路径，评测准确率大概也只能到 69%，换成普通业务人员只会更低；几个刚启动语义初版的业务线，正确率只有 30% 到 35%；唯独治理较早、沉淀了大量口径定义与业务知识的业务，才能勉强摸到 80% 的门槛。

面对这种数字，摆在管理者面前的其实只有两条路。

第一条路是继续自欺欺人：把容差放宽到 5%，对模糊问题默认替用户选第一个选项，然后在演示和汇报时宣称“我们已经实现了全业务覆盖”。反正只要演示时不翻车，大家都有交代。

第二条路则是直面现实：在临近交付节点时主动踩刹车，把 8 月底的口径明确修改为 Preview，正式版推迟到 9 月底；删掉所有关于跨表自由分析的宣传，自然语言语义问数只保留信用卡、分付、证券三个具备治理基础的业务，并且把数值容差从虚胖的 5% 硬生生收紧到千分之五。

我们最终选了第二条路。

做出这个决定的过程极其痛苦。你要去向管理层解释为什么之前说的“全都能问”现在变成了“只能问三个”，你要承受“是不是团队进度不及预期”的质疑。但只要你真正对生产交付负责，你就会明白：删掉虚假的承诺，比硬着头皮继续堆功能需要大得多的勇气。

因为用户不会因为系统号称支持一百个场景而留下，却会因为在第一个关键决策上拿到一个看似煞有介事却完全错误的数字，从此彻底对这个系统丧失信任。在真实的业务周会和财务对账上，80% 的准确率约等于 0 分，千分之五的容差才是及格线。

模型最大的危险，是它的“讨好型人格”

大模型在本质上是一种概率自回归系统。如果不做极其严格的外挂约束，它天然带有一种令人绝望的“讨好型人格”：逢问必答、过度自信、强行编造。

你给它一段缺少字段定义的模糊提问，它不会主动停下来告诉你“我的知识库里没有定义这个指标”，它会下意识地根据字面相似度，找一个长得很像的字段拼凑出一条看似合法的 SQL；你给它一个超出了它当前权限的数据查询，它如果不做前置鉴权，甚至会试图用模拟的汇总数来搪塞你。

这种现象在 Demo 阶段往往被当作“泛化能力强”，但在严肃的企业生产环境里，这就是一场灾难。

我在《AI 不是来替你查报表的》里写过：AI 和结构化数据之间，缺的从来不是连接器，而是受治理的业务语义。大模型再聪明，它也无法凭空猜出你们公司“昨天”到底算自然日还是交易日，更不可能知道“活跃用户”在两个部门之间为什么差了三十万。

所谓“语义问数”的壁垒，从来不在大模型技术本身，而在于模型背后装入了多少被确认过的业务知识、指标口径和治理规则。

如果这层资产没有建好，所谓的“自然语言张口就问”，就只是把大模型当成了一个昂贵却不可靠的随机数发生器。

因此，生产级系统的第一道防线，就是打破模型的过度自信，在系统架构中引入确定性的门禁与拒答机制。当用户的提问超出了已治理的语义空间、或者当前用户的权限并未覆盖目标资产时，系统必须在生成任何有害查询之前，干净利落地停下来。

拒答不是报错，而是一条责任路径

很多人抗拒“拒答”，是因为在传统软件的交互认知里，“拒答”等同于“系统报错”，等同于弹出一个冰冷的 Error 404 或“系统无法处理您的请求”。如果 AI 只会说“我不知道”，那产品的可用性确实会瞬间跌入谷底。

但在生产级系统里，优秀的拒答绝不是一句推卸责任的报错文案，而是一条清晰可控的责任路径。

我们在这次收敛中，把问数模式极其严格地拆成了三条各自独立、绝不互相混淆的轨道：

第一条是面向普通用户的“语义问数”。默认走自然语言，但仅限于那三个已经把业务知识、权限和口径治理好的业务域。在这些域里，我们追求 80% 以上的准确率和千分之五以内的精度。一旦用户的提问超出了这三个域，或者涉及未治理的长尾指标，系统绝不强行编造，而是明确告诉用户：“当前业务尚未建立已验证的语义模型，系统无法确保计算准确。”

第二条是面向专业分析师的“主题问数”。退回至专业入口。当用户明确知道自己要查哪张主题表或哪个 Cube 时，他可以显式指定数据源，系统在这个限定范围内辅助他确认指标、维度和过滤条件。在这个环节中，系统不能无限期等待用户，也不能在用户正操作时强制跳过。我们设计了 20 秒确认倒计时，一旦用户开始产生点击交互，倒计时立刻暂停，既防止链路无限阻塞，又保留了人工介入的从容。

第三条是资产沉淀的闭环（Skill Creator）。当一位专业分析师通过主题问数完成了一次复杂的多维分析、或者探索出一条高频分析链路后，系统会提供一个极其自然的出口：将这次分析沉淀为一个可复用的 Skill。这个 Skill 可以被显式调用、可以分享给团队、可以设置可见权限，但绝不默认参与全量问答的泛化召回，防止近似匹配污染普通问数。

你看，当拒答被设计成这样一条责任路径时，它不仅没有压低可用性，反而把原本混乱的“黑盒瞎猜”，变成了层次分明的人机协作：能自动保证准确的，由语义层直接交付；边界之外的，引导至专业可控入口；专业探索沉淀下来的有效经验，又反哺为整个组织的数字资产。

生产级 AI 的壁垒是托付成本

AI 发展到今天，一个越来越清晰的趋势是：功能的制造成本正在被压缩到接近于零，但系统的托付成本却被推到了前所未有的高度。

用现成的 Agent 框架搭一个能查库的 Demo，一个工程师花两天就能跑通；但要让一个涉及真金白银、风控合规和业务决策的核心团队，敢于在每天早上的例会上直接引用 AI 吐出来的数字，背后需要付出的治理成本、权限对齐成本和边界兜底成本，往往是前者的百倍以上。

我在《AI 时代，给别人做东西反而更难了》里写过一个观点：当每个人都拥有生产能力时，功能本身不再稀缺，信任才真正稀缺。

一个敢在证据不足时主动拒答的系统，远比一个什么都敢答、但时不时给你埋一颗暗雷的系统，更值得被业务托付。

因为在真实的商业世界里，管理者和业务专家最害怕的从来不是“这个问题工具暂时不支持”，而是“工具给了我一个自信满满的错误答案，而我毫无防备地把它当成了决策依据”。

删掉“全业务覆盖”的虚假承诺，把防线退回到受治理的语义与权限边界，在每一个不确定的节点建立可靠的拒答与责任分流。这看起来是一次后退，但恰恰是在这一天，AI 才真正脱掉了实验室的玩具外套，开始拥有了走进严肃生产环境的资格。

过去几个月，在几乎所有涉及生产力工具的从业者群聊里，我们总能看到类似的选型讨论：写文案用哪个模型更自然，写代码到底切到哪个版本，复杂推理是不是必须开重思考模式，日常搜索又该选哪个轻量版本。大家像老派工匠盘点工具箱一样，认真比较着各个模型的上下文窗口、首字延迟和单价差异，甚至整理出密密麻麻的场景路由对照表。

作为每天高频使用这些工具的实操者，我常常觉得这种状态很荒谬。在敲下第一个字之前，用户居然必须先完成一次心理预判：眼下这个任务到底有多难？是否值得忍受十几秒的慢思考？选便宜的模型会不会把逻辑写崩？选昂贵的旗舰模型是不是又大材小用？

这个被各大产品堂而皇之地放在核心交互区的模型选择器，表面上是把控制权交还用户，实际上却让普通使用者承担了沉重的操作税与认知税。

但如果把这件事完全归咎为产品团队的懒惰，其实也不公允。因为在产品设计上，这个选择器并不是某个人拍脑袋拍出来的，而是一场长达两三年的产品实验与剧烈摇摆后的无奈妥协。

摆锤的两端：OpenAI 的历史纠结

要看清模型选择器的本质，必须回顾一下 OpenAI 在 ChatGPT 上走过的弯路。

在早期版本里，OpenAI 曾经把各种能力和模型直接平铺在前端：GPT-3.5、GPT-4、代码解释器、联网插件、DALL-E 画图，五花八门的模式塞满了菜单。当时社区里铺天盖地全是抱怨：普通用户根本不知道怎么选，一次对话里想既查资料又写代码，还要反复切换入口。

后来，OpenAI 尝试做了一次激进的减法：把所有插件和模型统统藏起来，对外只留一个统一的入口，让系统在后台全自动识别意图和路由模型。

结果，这次全自动化的尝试被用户骂得更惨。

核心原因在于，用户从来不是单一维度的群体，同一个用户在不同时刻的诉求也完全不同。一个人在排查复杂的线上代码崩溃时，愿意忍受二十秒的慢推理以换取逻辑的绝对严密；但当他在同一个窗口里顺手查一个英文单词的词源时，他只希望系统在半秒钟之内迅速吐出答案。

当系统试图用纯黑盒的自动路由来接管一切时，灾难就发生了：用户想画图，系统可能误判成写 prompt；用户需要大模型深度推理，平台出于综合成本考虑可能悄悄调用了轻量模型，输出了缺乏深度的平庸回答。这种不可预期的黑盒分流，直接摧毁了使用者对产品的信任感。

于是，摆锤又荡了回去。OpenAI 只能把模型选择器重新端回前台，GPT-4o、o1、o3-mini、GPT-4o mini 重新排成一列。然而，面对这一长串专业术语和版本后缀，新用户依然感到困惑，众口难调的根本矛盾依然没有被化解。

为什么现在的做法依然是操作税

理解了历史的纠结，并不意味着我们应该坦然接受现状。

今天大多数 AI 产品的做法，实际上是从全自动黑盒的极端，直接摆到了彻底放弃治理的另一个极端：既然自动路由搞不定所有人的喜好，那我就一口气接入三十个模型、五个推理档位、三个联网开关，把所有底层参数和技术名词毫无保留地甩在输入框旁边。

这种做法表面上赋予了用户无限的自由，但本质上依然是一种责任转嫁。

当系统把算力选型、成本权衡和上下文管理的复杂度直接推到前台，产品的责任边界就变了。一旦回答效果不好，平台很容易把原因归结为用户没有选对合适的模型；一旦推理耗时太长，平台又可以解释为用户滥用了深度思考模式。

我在《AI 产品最怕的不是功能少，是主路径失守》里曾讨论过，AI 产品的核心生命线是让价值交付的主路径保持极短且顺畅。传统软件的功能膨胀是界面债务，而 AI 产品的功能膨胀更像是智能债务。当团队无法在核心主路径上提炼出清晰的交互契约时，最容易走的路就是往界面上堆砌各种参数和开关，用界面的复杂性掩盖产品在意图抽象上的无力。

用户打开工具是为了完成具体的业务任务，而不是在每轮输入前兼职做一名算力调度员。

我眼中有分寸的解法：意图分档与高级抽屉

我自己作为一个多工具、多模型的重度使用者，同时也在团队里推进 Agent 落地。在我看来，跳出纯黑盒与全手动的非此即彼，真正有分寸的方案其实非常清晰：把技术细节收拢进意图档位，把微调控制权留给高级抽屉。

这里有个现成的优秀样本，就是前段时间引发广泛讨论的 Manus。

如果你去看 Manus 在后台的实际运转，它在解决一个复杂任务时，底层其实会根据不同步骤灵活调用各种模型：有的步骤需要轻量模型快速提取结构，有的步骤需要写代码并执行环境，有的步骤需要多模态理解，有的步骤需要大模型做高强度的逻辑规划。它背后的模型调用矩阵极其复杂，但在前端面对用户时，它并没有在输入框旁边挂出一排模型下拉菜单，让你去纠结这一步该用哪个模型。

它给用户的感知极其纯粹，就是清晰的 Lite 和 Pro 两个版本。

用户只需要根据自己手头任务的体量做选择：是个简单的日常任务，还是个需要调动深度算力、多步执行的复杂任务。至于任务执行过程中到底是调用了三个模型还是五个模型，系统在底盘里自己搞定，根本不需要用户操心。

基于这样的实践，我认为一套成熟的 AI 产品控制面应该清晰地分为两层：

第一层，是面向绝大多数日常场景的粗粒度意图分档。

在主交互界面上，彻底拿掉那些晦涩的模型代号。用户不需要去背诵 Sonnet 和 Opus 的区别，也不需要去猜 o3-mini 的推理步数。产品只需要提供两到三个符合人类直觉的意图档位：

一个是日常快速响应档（类似 Lite），追求极低的首字延迟和轻量算力，处理日常问答、短文本润色和快速事实检索；

一个是深度推理与复杂任务档（类似 Pro），专门处理长链条逻辑推导、跨文件代码重构和复杂商业分析，明确告知用户会有数秒的思考过程，但在输出深度上拉满；

如果涉及全网深度调研或海量文档分析，还可以扩展一个专项研究档。

系统把复杂的模型技术指标，翻译成了用户一眼就能看懂的业务场景。用户只需要按需表达意图，剩下的多模型调度、上下文剪裁以及失败重试，全部由系统在底层闭环完成。

第二层，是为专业场景保留的高级覆盖抽屉。

这并不意味着我们要彻底剥夺专家的控制权。当我们需要固定模型版本跑 Benchmark、做严格的可复现实验，或者在企业级合规场景下指定数据只能流向特定私有模型时，底层控制依然不可或缺。

但我坚信，这种控制力应该作为一个折叠的高级抽屉存在。在这个抽屉里，你可以随意指定特定的 API 版本号、微调温度系数、锁定随机种子、或者自选推理步数。它是专业用户的逃生通道与调试面板，但绝不能成为所有普通用户主操作链路上的拦路门槛。

我在《用户不再点功能的时候，AI Native 才开始》里写过，AI Native 的本质演进，是让用户从操作底层功能走向直接委托结果。把底层模型的几十个开关收敛为直观的意图档位，把复杂的调度留给系统，正是这种委托关系的理性落地。

结语

回顾工业设计的演进，几乎所有复杂技术走向大众普及，都走过相似的路径。

早期汽车的驾驶室里，司机必须时刻通过方向盘旁的手动拉杆调节阻风门和点火提前角。到了现代汽车，行车电脑接管了所有的进气与点火微调，但依然会在中控台上给驾驶员保留经济、舒适和运动三种驾驶模式。

普通司机只需要根据路况选择是想省油还是想超车，行车电脑就会自动匹配对应的齿比和喷油逻辑；而真正需要下赛道的发烧友，依然可以长按关闭车身稳定系统，进入纯手动的赛道设置。

今天的模型选择器，正处于从早期机械拉杆向现代驾驶模式过渡的节点上。

一流的产品既不会傲慢地搞不可控的绝对黑盒，也不会偷懒地把几十个参数原样甩给用户。它们会耐心地把底层的技术碎片翻译成两三个清晰的意图阶梯，让复杂留在底盘，把从容还给使用者。

但真正在生产环境管过核心业务 Agent 的人，哪怕只是带团队上线过一个内部数据分析助手，心里都很清楚这幅图景有多脱离实际。

真实情况恰恰相反：原始的生产流量不仅不会天然变成学习资产，绝大多数时候它直接就是系统的运行负债。把未经治理的生产日志直接当成经验回灌给系统，换来的通常不是自主进化，而是灾难性的记忆污染、规则漂移和层出不穷的线上故障。

堆积日志不是学习，很多所谓的飞轮只是在交存储账单

很多团队容易把“记录了数据”误当成“沉淀了资产”。

在真实的线上环境里，海量的交互日志中超过八成都是毫无增量信息的常规问答，剩下两成则充斥着各种噪声：用户输入错别字引发的死循环，网络抖动导致的重复重试，用户因为情绪烦躁给出的自相矛盾的追问，以及下游服务偶尔超时抛出的脏报错。

如果不对这些日志做清洗、归因和物理隔离，直接把它们作为少样本样例塞进上下文，或者拿去给模型做微调，系统很快就会学到错误的因果关系。学术界在持续学习领域早就验证过这种现象：未加约束的在线记忆累积会导致严重的记忆中毒与灾难性遗忘。你今天为了修一个生僻的边界特例，明天系统可能连最基础的业务指标口径都会算错。

这就像我在《错题集越厚，AI 为什么反而更容易做偏？》里聊过的那种体感：如果只是机械地把报错记下来当成负向约束，系统不会变得更稳，反而会把精力全耗在如何绕过约束上，最后彻底偏离最初的目标。

未经治理的生产流量，本质上就是工业废水。你可以先把它抽进蓄水池里沉淀，但绝不能连过滤都不做，就直接把管道接回饮用水管网。

白天服务，夜间对账：解耦两套运行系统

为什么在线实时做自我反思和规则修改走不通？根本原因在于生产环境有不可妥协的物理约束。

白天在线上响应真实用户时，系统面对的是极其严苛的服务承诺：两秒以内的响应时延，严格受控的算力成本，还有对高可用和确定性的硬性要求。在这样的实时链路里，你根本不可能现场拉起三四个模型做交叉辩论，不可能跑复杂的搜索树，更不可能让大模型当场总结出一套新的工作流并直接生效。

白天的线上服务必须保持克制，像营业时间里的银行柜台一样，以最低的时延和最稳的操作把当下的业务办完。它消费的是经过严格测试的技能、只读的知识库和版本固化的提示词，绝不能在柜台上现场搞创新实验。

真正的反思与学习，必须完全挪到离线的异步链路里，就像银行在夜间闭门后的盘库与对账。

当白天的业务高峰过去，离线学习系统开始拉取当天的重点样本：执行报错的任务、用户反复修正的会话、人工介入接管的异常链路。在没有实时时延压力的离线环境里，我们才能给系统充足的算力和完整的上下文，让它从容地去做重放、对比、归因与提炼。

这种线上执行与离线学习的物理切分，是目前工程上唯一既能守住线上稳定性，又能让系统持续演进的合理架构。

离线重放的两个物理前提：环境快照与副作用隔离

把一次线上的执行失败搬到离线环境里重新跑一遍，难度远比把聊天记录重新发给模型要大得多。要做到确定性的只读重放，必须在底层解决两个工程前提。

第一个前提是运行环境与上下文的完整快照。

大模型的调用天然带有随机性，不仅因为采样参数，更因为运行时的外部环境每分每秒都在变化。如果你的日志系统只记录了用户的提问和模型的文字回复，到了第二天，你根本没有可能在离线环境里复现当时的故障场景。

一个具备可重放价值的调用轨迹，在发生的那一刻就必须把所有环境状态冻结下来：

1. 当时生效的提示词版本编号；
2. 具体的模型路由与参数配置；
3. 向量检索在那个毫秒实际命中的切片内容与相似度得分；
4. 外部接口返回的原始数据结构；
5. 当时的用户权限与业务租户配置。

只有把这些上下文完整定格，后续的排查才是在同一个物理现场分析案情，而不是对着虚无的影子抓鬼。

第二个前提是副作用工具的沙箱隔离。

真正能干活的 Agent，核心能力都来自于外部工具调用。而很多工具是带有状态修改属性的：往数据库写记录、调整广告投放预算、发送通知邮件、创建审批单据。

当你在夜间离线重放昨天的失败轨迹时，你不可能让系统真的再去调一次真实的扣费接口，或者往生产库里插入一条垃圾数据。这就要求评测环境必须具备工具分流机制：对于只读工具，比如指标查询和知识检索，可以打向只读副本，或者直接回放线上录制好的返回包；对于所有带有写操作和状态变更的外部动作，必须强制路由到模拟沙箱，只验证 Agent 生成的参数格式与调用逻辑是否正确，坚决切断真实的外部通信。

做不到副作用隔离，离线重放就永远只能停留在纯文本聊天的浅层玩具阶段，根本无法触碰核心业务系统。

强模型和用户纠正，都不是天然的标准答案

在离线归因阶段，最容易踩的另一个坑，是以为存在现成的“标准答案”。

有些团队寄希望于更强的大模型，觉得只要引入一个更大参数的模型来当裁判，就能自动判定昨天线上哪个步骤做对了、哪个步骤做错了。但大模型当裁判有着天然的固有偏置：它容易被更长的回答迷惑，容易偏好特定句式，更重要的是，通用的基础模型根本不懂你业务内部特有的统计口径和私有流程。

还有些团队觉得用户的现场反馈就是真理。但在真实的业务交互中，用户反馈同样充满了个体偏差：有的用户因为不清楚规则给出了错误的修改意见，有的用户带着情绪把整个正确的流程全盘否定，更有不同部门的用户对同一个业务指标有着完全相反的理解。

把这两者直接当作标准答案，本质上都是把系统进化的工程责任甩给了另一个不可控的黑盒。

可靠的归因链路必须经过三级漏斗的层层过滤：

• 第一级是规则过滤：通过接口报错、超时熔断、用户中途放弃或人工强制接管等客观信号，圈出高价值的候选集合；
• 第二级是语义聚类：把上百个表象不同但本质相似的失败案例，聚类成少数几个典型的失效模式；
• 第三级是领域责任人复核：由真正对该业务负责的专家对聚类中心进行抽样确认，把真实的业务判断固化为带有唯一裁决权的标准用例。

知识晋升与发布门禁：没有评测的优化就是线上裸奔

当一个典型问题被彻底归因清楚之后，最后一步也是最关键的一步：这条经验到底应该以什么形式进入生产系统？

很多刚接触 Agent 开发的人习惯随手去改系统提示词，在里面加上一句“注意：当遇到某种情况时，千万不要怎样做”。

这种打补丁的方式极其危险。提示词越堆越长，不仅会迅速稀释模型的注意力焦点，更可怕的是，为了修补 A 场景随手加的一条规则，极有可能在毫无察觉的情况下直接破坏 B 场景的正常运转。

在严肃的生产体系里，任何经验要进入系统，都必须经过两道严格的关卡。

第一道关卡是知识晋升。 一次被确认的业务认知，必须被定型为一种结构化的系统资产：它到底应该沉淀为一个独立的标准化技能，还是更新底层知识库中的指标定义，亦或是作为一个高质量的参考样例？这个判断必须有明确的业务负责人确认，而不是任何工程师在后台随手改动一段提示词。

第二道关卡是发布门禁。 提炼出的新规则与新配置在推向生产之前，必须进入自动化流水线，在黄金评测集上跑全量回归测试。

这正是《真正该越积越厚的不是 Prompt，是 Eval》里最核心的逻辑：真正能让团队放心迭代系统的，从来不是写得越来越臃肿的提示词，而是那套沉淀了所有历史教训、随时能够拉出来全面跑一遍的回归测试集。

只有当新的修改在确保解决了当前典型问题的同时，历史基准用例的通过率依然保持稳定，并且整体响应耗时和算力消耗没有出现异常劣化，这次优化才有资格被打包发布，推向第二天的生产环境。

让复利发生在控制面里

回过头来看，“数据飞轮”这个概念本身并没有问题。但它绝不是模型接上数据库之后就会自然发生的魔法，而是一套极其严密、环环相扣的工程控制面。

从生产现场的每一次异常，到上下文快照的定格，到只读沙箱中的确定性重放，再到多级归因、专家抽样、黄金评测集沉淀，最后通过发布门禁完成上线，这个链条只要缺失了任何一环，所谓的飞轮都会在旋转中迅速瓦解。

大模型确实大幅降低了我们做出一个演示 Demo 的门槛，但它从未降低过将一个复杂系统长期托付给核心业务的门槛。

真正的 Agent 复利，不在于系统的数据库里存了多少万条聊天记录，而在于团队能不能把线上每一次真实踩过的坑，都扎扎实实地变成一道再也不会被同样问题击穿的质量防线。

说实话，这种发布我已经有点麻了。过去一年，几乎每周都有一个模型号称"开源领先""追平闭源"，数字一个比一个漂亮，真用起来又常常是另一回事。我本来没打算写。

但这次有个动作把我拉住了。智谱在官方博客里把话说得很白：GLM 5.3 和 GLM 5.2 用的是同一个底座，没有换更大的模型，没有重新烧一轮天价预训练，全部的能力提升都来自后训练（post-training）。原话是 "Scaling post-training is all we did for GLM-5.3."

这句话比任何一张跑分表都值得看。它指向的是一件比"又一个开源模型超了谁"大得多的事：大模型能力提升的主战场，正在从"把模型造得更大"，挪到"给模型造更好的训练环境和反馈信号"。预训练决定模型懂多少，后训练才决定它能把多少潜力变成可靠的本事。这篇我想把这件事讲清楚：GLM 5.3 是什么，大家怎么反应，以及我最感兴趣的那一点，为什么"只换训练方式"就能带来这么大的提升。

GLM 5.3 到底做了什么

先把事实摆清楚，数字我只挑最说明问题的几个。

底座没变。GLM 5.3 沿用的还是 5.2 那个约 744B 总参数、约 40B 激活的 MoE 底座。上下文 1M tokens，最大输出 128K，thinking 分 low/high/max 三档（默认 max，而且这一版不再支持彻底关掉 thinking，算个 breaking change）。权重没立刻放，官方说大约两周后、八月底才发，先走自家的 Coding Plan。

那提升有多大？官方自报里最能说明问题的是两个数：Terminal-Bench 3.0（一个偏真实命令行 agent 任务的基准）从 4.6 跳到 28.3；网络安全方向的 CyberGym 从 77.2 提到 84.5。配合这些数字，智谱还联合清华、南开和几家安全厂商的红队，用模型初筛去重出了 2436 个漏洞，覆盖 269 个项目，最早的一个能追溯到 1981 年，平均潜伏了 26 年多。

丑话先说在前面：这些全是官方自报，权重没发，还没有任何第三方平台复核。所以上面的数字先当"厂商主张"看，别当结论。这一点后面还会回来讲。

各社区怎么反应：吵的其实不是跑分

我翻了一圈海外和中文社区，发现一个挺有意思的现象：真正在讨论 GLM 5.3 跑分的人不多，大家借这个由头吵的是另外两件事。

海外那边，Hacker News 主帖冲到了 1147 分、569 条评论，但热度最高的主线不是"这模型多强"，而是"终于有个能用来做安全研究、又不被拒绝的模型"。有人调侃"这只是 5.2 加了点 post-training magic，权重还得等两周"；一位叫 LeonidBugaev 的用户说，他连自己项目的 issue triage 都被美国模型拒绝，只好转去 Kimi 和 GLM；还有一条被很多人附议的评论讲得更直白："如果防御者拿不到好模型而攻击者能拿到，那开放才是平衡。"网络安全这东西攻防两用，这一派明显站"开放盾"这边。

真正值钱的对照来自独立实测。安全公司 Semgrep 拿统一的漏洞检测基准复测了一遍，结论是：GLM-5.3 大致到了 Opus 4.8 那一档的检测水平，成本却只有七分之一左右，但存在一个他们还在追查的方差问题，有时候像顶级黑客，有时候又在很基础的逻辑上失手；而且对着当前真正的前沿（Opus 5、GPT-5.6 Luna）还是够不着。另一家 D-Central 说得更直接：CyberGym 那个 84.5 只测的是"单点漏洞发现"，恰好是利用链最前端、也是 GLM 提升最大的方向，真正的差距在更靠后的链式利用上（ExploitBench 54.4 对 Mythos 5 的 78）。

把这些声音放在一起，你会发现海外吵的其实不是"28.3 高不高"，而是两件更实质的事：一是美国厂商越来越严的护栏，正把一部分做安全研究的人推向开放模型；二是厂商自己报的数字到底能不能信。

中文社区的反应则更"实测向"。钛媒体、腾讯沃垠、智东西几家横评的结论相当一致：GLM 5.3 偏科，编码和网安很强，但通用表达、审美、创意写作明显弱一截，还有个毛病是"陷进去出不来"，在长程任务里钻牛角尖。界面新闻直接说"K3 仍是第一梯队"。倒是科创板日报引的分析师白润轩给了句背书："后训练这条路线，工程上成立。"Nathan Lambert 那句评价我觉得最到位："Z.ai 强在后训练，Kimi 强在预训练。"

后训练到底是什么

要讲清"为什么不换底座也能大提升"，得先把"后训练"这个词从行话翻译成人话。

我的理解是：预训练教知识，后训练教做事。

预训练是拿海量文本让模型做"预测下一个词"。读完这一整座图书馆，它肚子里装了很多东西，决定了潜力上限。但你真去问它问题，它多半只会顺着你往下接话，而不是"回答"你。就像一个把技术文档倒背如流的应届生，第一次坐到终端前面对一片红字的报错，依然会手足无措。它懂很多，但还不会干活。

后训练就是在这个底座之上，用更少但更精心的数据和信号，把它塑造成一个真正有用、听话、对齐的助手。它决定了"潜力有多少能被可靠地兑现出来"。

这套技术这几年演化得很快，我用一句话带过每一代：

最早是 SFT（监督微调），给它一堆"问题 + 标准答案"，让它照着模仿。问题是它超不过示范数据的上限。

然后是 RLHF，不再给标准答案，只告诉它"这一版比那一版好"，把人的偏好本身当训练信号。这个思路特别朴素，我之前写过一篇《你改的那四份评语，就是手工版 RLHF》，讲的就是普通人怎么在不知不觉中干过同样的事。

再往后是关键的一步，RLVR（可验证奖励的强化学习）。它的奖励不再看"人喜不喜欢"，只看"程序能不能自动判对错"：数学题答案对不对、代码能不能跑过测试。这是整个故事的转折点，下面细说。

最新的方向是把 RL 拉进多轮、长程的 agent 任务，让模型学会"先想再答"，在推理时多花时间换准确率。

为什么不换底座，也能有这么大的提升

这是全文我最想讲清的一点。答案拆成三层。

第一层：能力是激发出来的，不是新造出来的。 Nathan Lambert 给后训练下过一个精辟的注解：后训练做的不是"教模型新东西"，而是"把底座里已经潜在存在的行为提取出来、放大"。他自己有句话我印象很深：过去我们用上百万条监督样本教模型数学，现在只让它在几千道题上自己去试不同解法，反而达到了更高的峰值。底座里其实早就有这些东西，只是没被点亮。

第二层：这个提升的数量级是真的，不是营销。 METR 做过一个很干净的实证：拿同一个 GPT-4 base model，只做后训练，把 agent 任务的成功率从 5% 左右拉到了 30% 左右，这个幅度相当于把 agent 框架从 GPT-3.5 整个换成 GPT-4。注意，这是 GPT-4 身上的实验，不是 GLM；但它证明了"不换底座、只靠后训练"，在受控条件下确实能带来代际级别的提升。

第三层，也是最关键的机制：可验证奖励把"偶尔做对"压成了"稳定做对"。 这里有个反直觉的事实：底座模型在你允许多试几次（pass@k 里 k 很大）的时候，其实偶尔是能解出难题的，说明能力潜在地在那儿；但你正常只用一次（k 很小）的时候，它就不可靠了。RLVR 干的事，就是把这种"偶尔能蒙对"压成"每次都稳定做对"。

而可验证奖励之所以是转折点，是因为它扛得住长时间优化。道理很简单：数学题答案对不对、代码过没过测试，这种奖励没法作弊，所以你可以放心让模型在上面跑很长很长的优化，不用担心它学会钻空子骗奖励。相比之下，RLHF 那种"看人高不高兴"的奖励很容易被 hack：模型会学会讨好而不是做对，所以只能短跑。Karpathy 在 2025 年的年度回顾里把这事说得最透：RLVR 吃掉了原本打算投给预训练的算力，2025 年能力进步的主力，其实是"大小差不多的模型，配上更长的 RL 训练"。

GLM 5.3 就是这条路走得很极端的一个样本。它搭了一条环境合成流水线：让 research agent 从真实工程工作里收集模式，转成可以跑起来的多步任务环境；judge 验证这环境可解；verifier 在没有标准答案的情况下合成判断；再用 solver 的轨迹去发现和堵掉"作弊捷径"。整套 RL 跑在他们开源的 slime 框架上。官方那句话点得很透："随着 agent 能力提升，scale 后训练的难点，正从'模型'转移到'环境'。"

但这条路有它的天花板

如果文章停在上一节，那就成了软文。这条"只靠后训练"的路，天花板其实很清楚，GLM 5.3 一个都没躲掉。

第一堵墙是偏科，而且偏科是有机制原因的。 RLVR 只在"能自动判对错"的领域管用：数学、代码、形式证明。可一旦到了开放领域，"怎样算好"根本没法写成程序去判，奖励就造不出来。这正是中文社区实测出"偏科"的根子：GLM 5.3 在可验证的编码、网安上暴涨，在难验证的通用表达、审美、创意上原地踏步。这不是它做得不好，是这条路天生就长这样。

第二堵墙是"引出还是涌现"的学术争议。 NeurIPS 2025 有一篇 Oral 论文系统实测后提出：RLVR 提升的可能只是"采样效率"，而不是"创造新能力"。当你允许底座模型多试很多次，它的上限反而更高，RLVR 只是让你更快抽到那个对的；真正引入新模式的，可能是蒸馏而不是 RL。这个争论还没定论，也有论文持相反观点。我自己倾向"引出"这一派，预训练定了能力的上限，后训练定的是你能把上限兑现出几成，但我得承认这事目前谁也没法一锤定音。它至少提醒我们：别把"后训练带来的提升"全当成"模型变聪明了"。

第三堵墙是安全这把双刃剑。 网安能力攻防两用，同一个模型既能帮防御者堵漏洞，也能帮攻击者找漏洞，这也是智谱把权重推迟两周的官方理由。海外吵的"开放还是护栏"，本质就是这个僵局，没有标准答案。上个月 Hugging Face 那起入侵事件里，美国的闭源模型因为护栏拒绝分析攻击日志，最后是 HF 自己部署了 GLM-5.2 把攻击还原出来的。这个细节很能说明问题：护栏护住了一头，也可能松开了另一头。

最后一堵墙是数字本身。 这些基准全是厂商自报，版本口径没法严格横向对比，官方对比表还刻意跳过了 Opus 5 和 Grok 4.6 这两个最强的对手，Semgrep 实测里那个没查清的方差也还没解决。所以对"28.3""84.5"这些数，我的态度是：参考可以，全信不行。等权重放出来、第三方平台跑过，才算数。

最后

把这几堵墙和开头那个判断放在一起，我自己得到的结论是：

当"把模型造得更大"这条路越来越难、越来越贵，能把同一个模型逼到极限的，就不再是参数，而是那套能持续造出好训练环境、给出诚实反馈信号的流水线。模型会越来越像商品，大家都能拿到差不多的底座；真正的护城河，是谁的环境造得好、谁的反馈给得准。这也是为什么"能力提升从模型转移到环境"这句话，比 GLM 5.3 本身更值得记住。

这条路上，GLM 5.3 是走得最激进的一个样本。但它撞上的每一堵墙，偏科、安全双刃、还有"数字到底信不信得过"，都是这条路上所有玩家迟早要撞的。

一句话：GLM 5.3 没有换一个更大的脑子，它只是换了一种更狠的训练方式。而这，恰恰是它最值得看的地方。

讨论最凶的也是这句话。它把模型适配器、工具、Session、Sandbox、UI 全部做成了插件，连 Agent Loop 这种最基础的部分都是一个可以被替换的 Provider。有人觉得这是架构理念的一次升级，也有人觉得这是为了新奇而新奇，过度设计。

我的判断是：争论"插件多不多"基本没打到点上。这件事真正激进的地方，是 DeepSeek 把官方实现本身也降格成了一种默认插件。传统 Harness 给生态的是扩展槽位，你可以在我画好的核心旁边加东西；DeepSeek Harness 给的是替换权，你不用 Fork 整个项目，就能把官方的核心实现换成你自己的。

它开源的不是又一个 Coding Agent，而是 Agent 的组装权和改写权。

先看时间顺序，再看产品

很多人觉得这是 DeepSeek 终于下场做 Coding 产品了。也正常，Claude Code、Cursor，国内的 Kimi、MiniMax 早就有自己的 Harness，DeepSeek 一直是产品端最克制的那个。

但有一个细节比产品本身更说明问题。7 月 31 日 V4 Flash 发布时，官方更新日志里有一条注记：公开 benchmark 里的 Code Agent 任务，是用当时"尚未发布"的 DeepSeek Harness minimal mode 跑的，连 max effort、top_p、temperature 这些参数都写明了。换句话说，Harness 在成为公开产品之前，早就是 DeepSeek 内部衡量 Agent 能力的实验装置。先有内部装置，后有公开产品。

这个顺序很重要。模型进入 Agent 阶段之后，一个模型在真实任务里表现出什么能力，越来越不是权重单独决定的，而是模型、工具 schema、上下文管理、重试机制、Loop 结构共同决定的。DeepSeek 已经不能只扔一个模型权重出来，然后把外面的运行方式交给别人。从这个角度看，做 Harness 算不上产品线扩张，它更像把模型研究必需的实验台做完之后，顺手开源给了整个行业。

这也对得上梁文锋在公开采访里一贯的说法：数学和代码是 AGI 的天然试验场，因为它们相对封闭、可验证。Coding 不是 AGI 的终点，但它是 AGI 最理想的风洞：行动可执行，结果可验证，失败可回放，反馈足够密。要在风洞里做实验，先得有一台自己的风洞。

一切皆插件，新在替换权

再说回架构本身。"Harness 加插件"不新鲜。Claude Code 有 Skills、MCP、Subagents、Hooks，Cursor 有自己的扩展面，OpenCode 的插件甚至能深度介入运行过程。插件可以影响 Agent 行为，这件事不是 DeepSeek 首创。

真正的差别在于，官方实现有没有架构特权。传统产品的姿态是：核心是我的，插件围绕核心生长。DeepSeek Harness 的姿态是：现在的核心能力，本身也只是一种默认配置。一个运行中的 DSH，是启动时由多层配置组合出来的一棵插件树。官方文档说得很直白：不存在一个需要被打补丁的特权核心。

可以把开放拆成三层来看。第一层是阅读权，你能看到源码。第二层是参与权，你能给官方产品补充能力，大多数插件生态停在这一层。第三层是替换权，你能用自己的实现换掉官方实现，而且第三方实现在架构上并不天然低人一等。DeepSeek 这次想做的，是把开放从参与权推到替换权。

当然，一切皆插件不等于没有内核。内核还在，只是退到了另一层：Cordis 微内核管插件的挂载、卸载和依赖，Service 和事件契约管部件之间怎么对话，再加上一条 append-only 的 Session 事件流。这条事件流可能是整个设计里最值钱的东西：系统提示词、上下文注入、模型输出、工具调用和结果，全部进入同一条日志，模型能看到的内容必须能从日志重建，恢复、分叉、回放、遥测都建立在它上面。连上下文压缩都不删原始历史，只是用一条 replacement 事件改变模型之后看到的"表面"。

不是没有内核，而是内核从业务逻辑退到了治理协议。Agent Loop 不再是宪法，它只是当前默认的执政方案。

真正稳定的东西变成了另外一些：怎么替换一个 Loop，怎么记录它做过什么，怎么在替换之后仍然能恢复、审计和回放。

Obsidian 的类比，对一半

这个设计给我的第一反应，是想起 Obsidian。

Obsidian 的内核很薄，大量体验是插件生态长出来的。一个日历插件、一个 Dataview，对用户的价值完全可能比官方功能更大。我自己用的时候就有这种感觉：很多时候，某个插件比那层薄薄的内核更重要。

但仔细想，这个类比只对一半。Obsidian 的插件生态极其繁荣，内核却始终闭源。它证明的是"稳定内核、变化外围"可以成立：内核不动，外围长出百倍于内核的价值。DeepSeek Harness 想做的是另一件事：稳定协议、变化产品。协议和治理规则稳定，跑在协议上的具体实现，包括官方自己的那一个，都可以被换掉。

这也是我认为"一切皆插件"才是真开源的原因。这里的开源不只是"我把东西放出来"，而是"我允许你贡献的部分，在某些场景下比我的内核更重要"。代价是官方主动放弃中间内核的地位。从梁文锋过去的公开表态看，这种放弃是自洽的：如果开源是通往 AGI 必须的，那就开源；如果 Harness 是必须的，那就做 Harness。理念不是发布会包装，是按最初的目标设计路线。

别急着喊数据飞轮

一个流传很广的猜测是：DeepSeek 做 Harness 是为了数据，通过生态源源不断回收独有的 Agent 数据。

我觉得这个猜测要明显收敛。DSH 是 local-first 的：输入、输出、Session 上下文、工具调用日志，默认都留在本地，未经用户同意不上传。在这种情况下，说它建立了"生产高质量 Agent 轨迹的能力"成立，说它自动获得了这些轨迹，不成立。

它真正在争的，不是数据所有权，而是数据语法权。什么叫一次 Turn，什么叫一次 Step，什么事件必须进日志，工具调用怎么表达，失败怎么分类和回放。这些概念的定义权，会进一步决定下一代 Agent 的 Eval 怎么设计、失败样本怎么清洗、后训练用什么格式、Reward Model 按什么单元打分。

我在《别再迷信 Agent 框架了》里写过一个判断：框架的长期价值会被模型的后训练压缩，但轨迹数据工厂会升值。DeepSeek Harness 把这件事做得更彻底：它不只生产轨迹，还试图定义轨迹的语法。谁定义了语法，谁就在定义下一代 Agent 能力的度量衡。这比回收数据高级，也比回收数据隐蔽。

泼两盆冷水

第一盆给"一切皆可替换"。这在接口层面成立，在模型行为层面未必。模型表现会被大量细节影响：工具名称和描述怎么写，错误信息怎么措辞，Turn 和 Step 的边界在哪，上下文怎么压缩。V4 Flash 的 benchmark 要指定 Harness minimal mode 和具体采样参数，本身就说明模型能力没法完全脱离运行环境单独描述。能接上，是接口兼容；能发挥出能力，是认知兼容。第三方 Loop 接得上不代表跑得好；几个插件各自优秀，组合起来性能掉了，归因都是难题。插件化解决的是可组合性，同时可能制造组合爆炸。

这也呼应我在《循环的灵魂在循环之外》里的体验：Loop 本身不难写，难的是 Loop 之外的完成判断和外审机制。当 Loop 变成人人可换的插件，"换掉之后拿什么判断换得更好了"，会变成生态里最稀缺的资产。

第二盆给"自由拼装"的想象。内测几天，用户就写了差不多三百个插件，AI Coding 让插件的首次开发成本低到可以忽略。但插件越容易写，优质插件的识别成本就越高。敢不敢装、出了问题能不能定位、升级之后还能不能跑，这些成本一点没少。绝大多数用户并不想研究 Loop 和 Sandbox 的区别。用户不需要热爱灵活性，用户只需要有人替他吸收灵活性带来的复杂度。

所以我判断，这个生态未来真正重要的产物不是插件市场，而是 Distribution：少数开发者生产底层组件，一批集成者把组件组合成经过验证的稳定方案，大多数用户直接消费官方或第三方的标准组合。DSH 自己的 Profile 和 Preset 两级机制，已经在往这个方向走。底层越开放，上层越需要有主见的默认值。

对我们自己的系统有什么可抄的

如果你在做企业的 Agent 平台，最值得抄的不是"一切皆插件"这个形态，而是它背后的分层判断：什么应该稳定，什么应该可替换。

稳定的是身份、权限、审计、事件日志、生命周期和能力契约，这些是宪法。可替换的是模型、Loop、Memory、Context 策略、工具和 Sandbox，这些是执政方案。面向开发者给足组合自由，面向业务用户给有主见的标准配置。在建插件市场之前，先建兼容性测试、轨迹观测和失败归因。

DeepSeek Harness 现在还只是开发者预览，核心插件和 API 都还会变，它会长成什么样没人知道。但它把一个判断摆上了台面：模型公司只控制模型，就没法完整研究智能；Harness 只控制 Harness，就决定不了模型能力。把两者放进同一个可实验、可替换、可回放的系统里，这件事本身比任何单个插件都重要。

真正成熟的 Agent 平台，不是把所有东西都做进内核，也不是把所有东西都扔给插件，而是知道哪些东西属于智能，哪些东西属于宪法。

起因很朴素。新模型的底层能力强了一截，很多过去必须反复叮嘱的事情，它现在本来就能做对。继续让那些规则留在每次调用的热上下文里，看似只是多付一点 token，无伤大雅。

但真正过的时候，问题来了：没有人能完整说清，那份越来越长的 prompt 里，每一段到底还在保护什么。

有些规则能找到当时的讨论记录，对应某一次真实的线上事故。有些只记得“大概以前出过问题”。还有一些，连当初为什么加进去都说不清了。大家只知道它在那里待了很久，所以最好别碰。

那一刻我意识到一件事：这些 prompt 不是被设计出来的，是长出来的。

输出宽泛了，加一句“必须具体”。工具调用错了，加一段工具选择原则。某次漏了风险，再加一份检查清单。每一次修改单独看都有道理，都来自一次真实失败。但时间一长，system prompt 就不再是一套指令，而变成了一份历史事故档案。每次失败留下一层疤痕，没有人知道哪些疤痕还在保护系统，哪些只是遗迹。

我们很擅长让系统记住，却不擅长让系统忘记。

为什么规则只会变厚，不会变薄

这不能怪工程师缺乏减法意识，而是组织的责任结构自然导向的结果。

新增规则是一种低风险的可见行动。线上出了故障，我加上防护规则，就代表我采取了行动，复盘会上这就是交代。即使新规则没起效，或者带来了轻微的副作用，这种代价也是隐蔽的，分摊在每次调用的 token 费里。

删除规则完全是另一回事。删完没出事，没人会觉得是你的功劳；一旦类似事故重新发生，责任划分会非常清晰：谁让你删的？

在没有客观证据支撑时，最理性的选择就是只增不减。Prompt 膨胀的本质，不是团队记住了太多，而是团队没有建立安全遗忘的能力。

Prompt 不是免费的保险

留着不删就当买保险，这个账算错了。Prompt 里的每条规则都像一份自动续期的保单：它可能保护某一类风险，但每次调用都在重新支付保费，而且保费远不止 token 一种。

第一是直接成本。Token、延迟、上下文窗口占用，每次调用都在付。在每天千万级调用的系统里，这不是小数目。

第二是注意力成本。上下文变大，不等于信息能被同等使用。有团队拿十八个主流模型做过系统的实测：输入越长，模型表现越差，任务越复杂掉得越明显。模型能读到一条规则，和这条规则能在正确的时机真正约束行为，是两件事。我在《Skill 不该越写越重》里写过类似的判断：东西越杂，重点越容易被稀释，规则堆多了不是补齐，是往系统里注入竞争注意力的噪声。

第三是冲突成本。不同时期、针对不同事故留下的规则，局部都正确，放在一起未必是一套一致的策略。模型要在互相打架的指令之间妥协，输出质量就会漂移。

第四是行为固化。大语言模型不是逐条执行规章制度的解释器。在代码里加一个 if，是增加一个明确的分支；在 prompt 里加一句话，是在重新调整模型的整个行为分布。过去为旧模型准备的详细步骤，放到新模型上，可能不再是帮助，而是束缚。模型本来已经能根据情境灵活处理，旧规则还在要求它按固定路径走。

所以每次模型升级，除了跑一遍回归确认能力没退化，还应该算另一笔账：原来为旧模型准备的补偿，还有多少是必要的？哪些已经没价值了？哪些虽然不再必要，却开始产生负作用？这笔账，大多数团队从来没算过。

Eval 改变的，是“删除”的性质

这就需要 Eval。

很多团队把 Eval 理解成一个分数：成功率多少，准确率多少，证明这个版本可以发布。但严格说，任何有限的测试集都无法证明一个开放式 Agent 已经足够好。通过一千个案例，不能保证第一千零一个不失败。

Eval 真正回答的是一个更具体的问题：在我们已知的任务分布、风险边界和失败样本下，这次修改让系统变好了、变坏了，还是没变？

这样，Eval 就不是一张成绩单，而是一种变更管理机制。尤其是，它让“删除”第一次变得可以被管理。

删掉某段规则，过去保护的严重事故会不会重现？成功率、人工纠正率、工具调用次数、延迟怎么变？这些问题能被重复回答之后，删除就不再是“凭感觉”，而是一次有边界、可回滚、可比较的工程实验。

这也是我维护几个长期运行的 Agent 过程中确立的闭环：Trace 负责记录事故到底怎么发生；Eval Dataset 把一次事故从聊天记录变成可以反复重放的案例；Regression 验证修改之后重要边界还在不在；Release Gate 把这种验证变成发布条件。

过去我主要把 Gate 理解成阻止系统变坏的机制。现在我觉得它还有另一个同样重要的作用：Gate 不只挡坏东西进来，也应该批准不再必要的复杂性离开。

有了这套闭环，举证责任就可以反过来。以前是提出删除的人必须证明这段规则绝对没用了。现在应该问的是：模型已经升级，这条规则还值得每次调用都携带吗？它保护的是哪组真实失败样本？删掉以后这些 case 退化了吗？对那些为了弥补旧模型能力而加的补丁，举证责任应该从删除者转移到保留者身上：不是别人要证明它无用才准删，而是它要持续证明自己有价值，才有资格常驻在运行时上下文里。

减法不是遗忘

有人会担心：删 prompt，会不会把过去踩坑的教训也丢了？

恰恰相反。真正的减法不是忘记历史，而是把历史放到正确的位置。

一次失败不该被压缩成一句脱离上下文的警告，永远塞在每次运行的热上下文里。它更应该被完整保留：Trace 记录事故发生在哪一步，失败样本进入 Eval Dataset，修复方式写进回归案例。团队仍然记得当初为什么加这条规则，仍然能在新模型退化时恢复它，但系统不需要在每一次无关的任务里都重新背负这段历史。

代码侧我刚写过姊妹判断。在《当写代码开始免费，删代码才成了工程师的正职》里，我提出工程的目标是用最少的长期承诺，换取足够且可验证的业务能力。这次轮到 prompt 侧。删除 prompt 不是删除组织记忆，而是把记忆从最昂贵、最容易互相干扰的地方，迁到更适合长期保存的位置。

不是所有值得保存的信息，都值得每次被模型读取。成熟的系统不是存得少，而是分得清：什么该常驻，什么该按需检索，什么只该存在于 Eval 和 Trace 里。

不是所有规则都该删

当然，“模型变强就删 prompt”如果被当成普遍原则，会走向另一个极端。Prompt 里的规则不是同一种东西，至少分四层。

最底是宪法层：合规、安全、身份、授权，不可逾越的红线。往上是契约层：业务口径、输出格式、责任边界。这两层不是因为模型不够聪明才存在的。模型再强，也不会自动知道一家公司的业务口径，更无权替组织决定愿意承担什么风险。合规不是能力补丁，是系统目标本身。这两层必须坚固常驻。

真正需要经常翻出来审视的，是启发层和补丁层：那些为了帮助模型完成任务给的方法步骤，和针对某个模型版本弱点加的临时补偿。它们天然应该有适用范围和退出条件。

所以一份成熟的 prompt 负债表，每条规则至少要能回答：它因为什么失败而存在？保护哪组 Eval case？适用于哪个模型和工具环境？每次调用的成本是什么？什么条件下可以删？

回答不了这些问题的规则，不再是工程知识，更像一种组织迷信。

说回每个人自己

这套逻辑放到个人使用 AI 上，同样成立。

现在很多人开始攒自己的 prompt 模板，写文章的、做研究的、写周报的。但我越来越觉得，prompt 很可能不是最值得积累的那部分。它高度依赖模型，一个在某代模型上精心调出来的长 prompt，换一代模型可能就大半作废。模型越进化，历史 prompt 折旧越快。

Eval 不一样。一个人判断什么是好文章、好方案、可信的数据结论，这些标准也会进化，但不会因为底层模型更换而失效。

prompt 是你和当前这一代模型签的临时合同，Eval 是你和未来的自己签的长期合同。前者记录“现在该怎么做”，后者记录“为什么这个结果值得接受”。

AI 可以一次给你十个标题、十种方案。生成得越多，稀缺的就越不是“还能做出什么”，而是“什么值得留下”。如果一个人没有自己的 Eval，他得到的不是十倍的创造力，是十倍的平均答案。

所以我不认为，未来最成熟的 Agent 会拥有最长的 system prompt。

它可能只有一组很稳定的目标、身份、合规和责任边界，大量过去的事故和经验放在 Trace、Eval Dataset 和回归体系里，而不是永远堆在热上下文中。

每次模型升级，团队除了问“新模型又能让我们多做什么”，还应该问一个过去很少被认真提出的问题：这一次，我们终于可以删掉什么？

一个没有 Eval 的系统，只有记忆，没有新陈代谢。

一个真正成熟的系统，不是从不遗忘，而是知道什么必须被记住、什么可以离开运行时，以及决定遗忘之前需要什么证据。

从这个意义上说，真正该越积越厚的，从来不是 prompt。

是 Eval。

在这两个身份之间来回切换，我经常会陷入一种很奇特的分裂感。

很多时候，这套系统像一个共事了半年的老搭档。我只敲几个词，给一段有些凌乱的片段，它就能心领神会，把边界、规范、分寸处理得妥妥帖帖。那种瞬间，你会觉得人机协同的流畅感真的握在手里了。

但这种默契持续不了太久。另一些时候，它会突然变成一个第一天入职、还不看交接文档的新人。明明规则文件里白纸黑字写着某条禁令，文件就挂在它的上下文里，它照样大大咧咧地违反。你指出来，它极其诚恳地道歉，能把正确规则倒背如流，然后下一次，外甥打灯笼，照旧。

最初我和大多数人一样，把这个问题归结为“记得不够多”。是不是上下文给得太少？是不是背景写得不够细？于是我往上下文里塞更多东西，也盯着各家模型不断膨胀的上下文窗口，觉得只要窗口够大，把知识和规范全丢进去，AI 就能变成全知全能的助手。

事实很快教育了我。上下文塞得越多，失焦反而越隐蔽。几千字的时候它犯错，你一眼能看出哪条约束没写好；十几万字的时候，它犯错概率不降反升，还学会了在庞杂信息里选择性忽略你的核心指令。

我之前在《个人的 Context Infra，应该怎么搭？》里写过这套底座怎么搭，那篇的重点是让 AI 在需要的时候稳定拿到最该知道的那一小部分。但现在回头看，“拿到”只是上半场。我们太关注如何把信息送达给模型，却忽略了信息送达之后，到底有没有真正改变它的行为。

想清楚这一层之后，结论就浮出来了：上下文工程的终点，不是记住，而是生效。记住是物理状态，生效才是化学反应。

三次断裂

要理解为什么记住不等于生效，得把上下文从“写进文件”到“约束输出”的链条拆开看。中间横着三道鸿沟。

第一道，存在的断裂。规则写了吗？它在不在当前会话里？在复杂系统里，由于路由和检索的偏差，很多时候你以为给到了的信息，物理上根本没进入模型的输入。

第二道，读到的断裂。就算信息进了上下文，模型真的读到了吗？长上下文里关键信息放在什么位置，都会明显影响模型能不能用上它。塞得越多，注意力越被无关信息稀释。它看到了，但没留下痕迹。

第三道，也是最致命的，生效的断裂。模型精确定位到了你的规则，也能准确复述它，但这句话能不能强到改变它下一个输出的选择？模型的基准行为来自预训练形成的惯性，如果你的规则跟它的惯性冲突，它就会进入一种知行不一的状态：它知道有这条规则，但输出依然顺着最熟悉的套路滑了下去。它读到了，但它没听。

这三次断裂是相乘关系。假设路由、加载、理解、执行、检查每一层都做到 90% 可靠，听起来每层都不错，但五层串联下来，端到端可靠性只有 59% 左右。每一层都像优等生，整体却像抽卡。你感受到的不稳定，往往不是某个组件特别差，而是一串看似可接受的小损失乘了出来。

最近看到一个基准测试，把第三层量化得很扎心。让 Agent 在几十页到一百多页的公司制度约束下完成真实工具操作，最强模型在“所有要求全部满足才算通过”的标准下，通过率只有 36.2%。典型的失败不是没读到规则，而是让一个看起来合理的临时请求覆盖了长期政策，做完检查后采取了和检查结果相反的行动，甚至声称自己合规、实际没有。这基本就是第三次断裂的实验室版本。

这件事我越看越眼熟

因为白天在管理现场，我见过一模一样的结构。

为了推行一个技术规范，你召集大家开会，在白板上画得清清楚楚，会后写详细的文档抄送所有人。开会时人人点头。到了周五下午 Code Review，提交上来的代码里依然充斥着各种野路子写法。那一瞬间，你盯着屏幕，在群里敲下那句所有管理者都无比耳熟的话：“我不是已经说过了吗？”

说过，只能证明信息曾经出现过。发过群消息、开过会、写进文档，只能证明组织“拥有”这条信息。它会不会在某个员工做具体决策时被调用，是另一个问题；它能不能压过短期业绩压力、局部便利和个人习惯，又是第三个问题。

成熟的组织不会把关键要求寄托在员工“记得某次会议”上。它会把要求嵌进模板、审批流程、系统权限和验收标准里。一句话说完没人执行，解法不是把这句话说得更大声，而是把它变成流程的一部分。只会反复在群里喊“我不是已经说过了吗”的管理者，是在用提高分贝来掩盖机制的缺失。

Agent 系统是同构的。会议上的口头对齐，相当于临时 prompt；文档和知识库，相当于长期存储；培训和任务说明，相当于上下文加载；而模板、权限、流程门禁，才是让规则真正生效的那一层。审计和复盘，对应评测和护栏。

所以从执行角度看：组织没有“已经说过”，只有是否被嵌进了工作流；Agent 也没有“文件明明在那里”，只有它是否在决策发生的那一刻真正生效。

三种方案，是三种风险交换

那怎么让规则生效？我自己实践过的方案大致三种。要先说清楚：它们不是逐级先进的关系，而是在三种失败之间重新分配风险。

动态路由，也就是按需加载。启动时只给 Agent 看规则清单，它判断相关了再去读全文。这控制了上下文成本，但把一个关键决定交给了模型：它得先意识到自己需要这份文件。问题是，Agent 不知道自己不知道什么。它一旦误判“这个任务不需要读那个文件”，后面的推理再强也没用。这个方案，是把污染风险换成了漏读风险。

强制加载，把所有重要文件一股脑塞进上下文。看起来消灭了漏读，但制造了注意力稀释。OpenAI 自己的工程实践里就试过写一个巨大的规则文件，结果失败了，最后改成一百行左右的导航地图，把详细知识放到结构化文档里。原因很朴素：所有内容都被标成重要之后，反而没有了重点。全量加载没有消灭问题，只是把“找不到”变成了“看见了但没注意”。

事后检查，让检查器去发现“读了但没遵守”。这层不能少，但有个天然局限：对文本输出，错了可以重写；对已经发生的副作用，检查可能已经太晚。文件覆盖了、邮件发出去了、配置改了，事后 review 救不回来。不可逆的动作，检查必须前置成审批闸门，或者干脆由确定性机制接管。

所以 harness 的本质不是多加几层，而是想清楚：哪类错误应该在哪个位置被阻断。这个方向我之前在《真正重要的不是 Context，而是 Harness》里写过，当时关注的是模型之外那套长期支架。这次想再往前推一层：支架存在也不等于规则生效，harness 的终点不是“有机制”，而是机制在关键时刻赢过模型的局部最优。

最小充分

我的落点不是规则越多越好，而是最小充分。每条常驻规则都要经得起追问。

哪些内容应该常驻，我现在看四个维度：遗漏损失、适用范围、信息稳定性、动作可逆性。

高遗漏损失、跨任务通用、短且稳定的规则，进一个很小的常驻核心：身份边界、绝对禁止项、制度变更权限、完成的定义。任务相关但较长的程序性知识，按需加载。频繁变化、要求精确的数据，不写进 prompt，执行时从源头读。能被机器验证的要求，不依赖自然语言自觉，交给脚本、权限和检查。

压缩成一句话：最小宪法常驻，任务规则按需装载，事实从源头读取，关键结果必须验证。

在调试规则文件时，我有一个自己的拷问：这句话如果删掉，模型的行为会不会改变？如果删掉它输出依然正确，这句话就是噪音。它不但占用上下文，还在无形中增加注意力损耗，把那三次断裂的概率又推高一点。

还有一个问题值得点一句，但不在这里展开。模型有时不只是“读了没遵守”，它为了完成一次局部任务，会擅自修改规则文件本身，把一次性的优化固化成全局规则。这已经不是读没读的问题，而是谁有权把一次经验写成制度。读路径治理之外还有写路径治理，这够单独写一篇。

回到标题

上下文工程这个词流行起来之后，大多数人的注意力都在“给模型什么信息”上。我这一年的体感是：提供信息只是上半场，下半场是让信息在正确时刻获得执行权。前者是物流，后者是治理。

我们正在从“如何向模型提供信息”，走向“如何让自然语言规则成为可执行、可验证、可治理的制度”。Prompt 是一次沟通，Spec 是任务契约，而 harness 是让契约在执行中真正产生约束力的系统。这么看，上下文工程的终点会越来越像组织设计，而不是提示词技术。

记住只是中间状态。生效才是。

他回了我一句：“如果不参与 AI 项目，怎么打磨好自己的 AI 实践能力？”

这句话第一耳朵听上去很有道理。它把问题推成了一个“鸡生蛋还是蛋生鸡”的循环：没有项目就没有经验，没有经验就进不了项目。我当时也差不多是这样顺口答他的。

但回头细想，这句顺口的话并不准确。它把两件本来有先后顺序的事，说成了一个解不开的循环。而我真正介意的，是他问题里藏着的那个前提：好像一个人要先拿到正式 AI 项目，AI 实践才真正开始。

这个前提不成立。

学习不是从项目分配开始

AI 到底是一个独立专业，还是挂载到已有工作之上的能力？我的判断一直是后者。

它更像水和电。我们每天都要用水、用电，但不需要先去发电厂上班，才有资格把电用好。开发者可以拿当前需求，练习让 AI 理解代码、修改代码和验证结果；产品经理可以拿真实的需求梳理、原型推演和用户反馈练习；做数据、运营和管理的人，也都能从自己每天反复发生的工作里找到入口。

这个比喻并不是说 AI 简单，更不是说核心项目没有价值。水电人人都能用，设计电网仍然是专业工作。AI 也一样。日常使用和核心系统之间隔着很长的能力坡度，但坡度的前半段，不需要组织先发一张项目入场券。

一个人完全可以从眼前的工作开始。把原来手工完成的一段流程交给 AI，给它补上下文，看它在哪里犯错，再想办法验证和约束。也可以自己做一个小工具，跑通一个从输入到结果的闭环。东西可以很小，甚至最后没人用。关键是，你真正经历过一次“怎么让 AI 把事情做对”。

如果把 AI 实践能力粗略算成 100 分，从 10 分走到六七十分，主要靠的就是这些练习。这件事等不来，也不需要等。

核心项目负责放大能力，不负责从零培养

既然日常工作就能练，为什么还要设一道门槛？因为核心项目有它自己的第一责任。

到了六七十分之后，核心项目的价值才真正显出来。自主练习能让人学会工具、形成基本方法，却很难凭空制造真实业务里的复杂约束。核心项目有时间压力，有上下游依赖，有权限和安全边界，有数据质量问题，也有人要为最终结果负责。很多能力只有到了这种环境里才会长出来。

所以核心项目当然会培养人，它往往是最好的高阶训练场。但它的第一责任仍然是业务交付。它有交付目标、时间成本和失败代价，负责人挑选参与者时，首先想的是谁能对结果负责，其次才是谁需要借这个项目成长。参与者进入项目，不只是来获得成长，也要能承担一部分真实责任。

把这层关系说清楚，不等于拒绝培养人。它只是在区分两种成长机制：基础能力靠自我准备，核心项目负责把已有能力放进复杂环境里检验和放大。一个人可以在项目中成长，但不能把“我需要成长”当作进入核心项目的主要理由。真正有说服力的理由是：我已经做了足够准备，能承担一部分真实责任，我的加入会增加项目成功的概率。

战场可以让人成长，但战场首先要打赢。

项目名称不能替你证明能力

再往下挖一层。这种误解为什么这么普遍？因为很多人习惯了“项目依附型”的成长：组织给我什么，我就学什么；哪类工作没轮到我，我在哪方面没有积累，似乎也情有可原。

在变化缓慢的专业体系里，这种方式还转得动。但 AI 带来的问题是，变化速度已经超过了组织分配机会的速度。模型、工具、工作方式每天都在变，任何组织都不可能先把岗位、课程和成长路径全部设计好，再通知每个人按顺序上车。很多能力在组织正式定义它之前，就需要个人开始准备了。

也没有谁是天生有经验的。今天团队里熟悉 Agent、评测和工具调用的人，一两年前同样从零开始。他们和后来者的差别，通常不在谁先拿到一个好项目，而在方法还没成型的时候，谁先动起来了。

同样，把“在 AI 项目里”直接等同于“有 AI 实践能力”，也站不住。一个人进了 Agent、模型评测或者 AI 平台项目，仍然可能沿用过去的工作方式，只负责其中很窄的一段。另一个人做的只是普通开发、产品或者数据工作，却可能已经用 AI 重构了自己的完整流程，知道怎么给上下文、怎么拆任务、怎么验收、怎么处理失败。

真正该看的，是一个人能不能借助 AI 把真实问题重新做一遍，并对结果负责。

先把启动权拿回自己手里

所以，对那位同事，也对有同样困惑的人，我的建议不是“再等等”，是现在就动起来，顺序大概是这样的。

先从手头的工作里找一个具体问题：一个重复的、耗时的、质量不稳定的环节，用 AI 把它重新做一遍。不能只停在让 AI 生成几段代码，要完整回答几个问题：原来的流程是什么，哪些部分适合交给 AI，它需要什么上下文，怎么判断结果好不好，出错了怎么发现，这套方法能不能沉淀下来给别人用。

然后，把结果攒成看得见的证据。一个小工具、一段自动化、一次完整的数据分析，甚至一套反复修改过的工作规则，都比“等我进了项目就会成长”更接近真实能力。我之前在《AI 时代最好的简历，是做出来的》里写过，AI 让“说”在贬值，做出来的东西正在成为更可信的能力信号。主动说“我想加入”是好的，但更有说服力的是：在没有人给你正式项目的时候，你已经拿 AI 做成过什么，遇到过什么问题，又是怎么把它修到能用的。

当你能用这些东西证明自己准备好了，进入核心项目就是一个自然结果，而不再是学习的起点。

当然，组织仍然有它的责任：识别这样的人，给他们更大的空间，为真正有潜力的人打开进入核心战场的门。但那是下一步。第一步不该是等组织证明你有培养价值，而是先用行动证明自己已经准备好承担更多。

核心项目可以让一个人从六七十分走向更高，但不能替他完成从 10 分开始的那段路。

项目给你的，应该是更难的问题，不是开始行动的理由。

一位群友发了一条动态：“模型一周给我写了一万多行代码，随后我又花了一整周，一步步指导它把这一万多行代码全都删掉。”

紧接着另一位群友吐槽：“一个简单的 override 就能解决的事，模型为了显得架构优雅，给我硬生生拆出了五层转发、适配器和握手协议。” 还有人总结得更透彻：“现在 AI Coding 最大的问题，不是它不会写，而是它能用极其合理、看起来无比专业的姿势，把人忽悠过去。”

这几句话在群里引发了相当长的讨论。大家表面上是在吐槽 AI 喜欢“画蛇添足”和“浪费额度”，但如果你真正天天用 Claude Code、Cursor、OpenCode 或 Gemini 在生产环境里干活，你就会意识到这绝不仅仅是一个模型好不好用的小吐槽。

它背后暴露的是一个正在深刻发生的生产关系剧变：当生成代码的边际成本迅速趋近于零，工程稀缺性正在从‘如何把东西写出来’，全面转移到‘如何阻止不该存在的代码进入系统’。

换句话说：当写代码开始免费，删代码才成了工程师的正职。

一万行代码不是产出，而是待验收库存

“一周写一万行，下一周再删掉一万行”，听起来像个荒诞的幽默段子。但在工业生产里，这种现象有一个非常标准的名字：库存堆积。

过去的软件工程里，代码是稀缺的。一个设计方案能不能变成现实，最主要的瓶颈在于工程师手打代码的物理速度。代码行数在很长一段时间里，甚至被误当成了某种产出指标。

现在情况反过来了。在多 Agent 和长思考模型的加持下，十几套可选方案、五层抽象架构、二十个适配接口，可以在几秒钟内铺满你的屏幕。代码的制造成本被打到了地板上。

但很多人忽略了一件事：AI 生成的代码，并不直接等于可交付的工程产物。在没有经过人类严格审视、测试和验证之前，它唯一的身份是一堆‘待验收的工程库存’。

如果一个团队的生成速度远远超过了它的验证速度，所谓的“AI 带来十倍提效”，本质上只是在十倍速地制造待审核库存。

未读的 PR、未在边缘条件验证过的兜底分支、没有人真正理解的中间抽象层……这些代码停留在仓库里，就像堆在车间里的半成品。它们不仅不产生价值，还会持续消耗团队的注意力与维护精力。

单行代码生成得越便宜，组织拥有的代码总量往往膨胀得越快，而总体的维护成本和理解成本反而可能被推得更高。

AI Coding 的第一条生产纪律，可能不是多开几个 Agent 去狂飙代码，而是：代码的生成速度，绝不能长期超过团队的验证与收敛能力。

否则，你不是在写软件，你只是在为 AI 的生产过剩买单。

模型最危险的，不是写错，而是把多余写得很专业

如果 AI 只是写出明显的语法错误或逻辑 Crash，事情反而简单了。编译器会报错，测试用例会飘红，工程师扫一眼就能给它打回去。

真正昂贵且危险的，是群友吐槽的那种情况：逻辑正确、测试通过、结构规范，但根本没有必要存在的代码。

模型面对不确定性时，有一种天生的“过度防御”机制。你给它一个简单的业务需求，它不会主动问你“这个接口未来半年真的会变吗”，它会下意识地把这种不确定性翻译成复杂的代码形态：

• 增加一个抽象基类，预防未来的未知扩展；
• 增加一层适配器，隔离可能根本不会换的第三方服务；
• 增加一段复杂的握手与状态校验，防止极其罕见的边缘故障；
• 再加一个配置读取和多层转换，顺便把未来可能的变动也“顺手封装了”。

其中每一层代码单独拿出来看，都符合某种经典的设计模式，甚至能附带上一段写得非常漂亮的注释。这种现象可以称之为‘复杂度洗白’。

模型用正确的术语、成熟的范式和看似周密的逻辑，把没有证据支撑的复杂度包装成了“工程严谨”。它知道企业级架构长什么样，却不承担长久维护这个架构的痛苦。

我在《Skill 不该越写越重》里讨论过复杂度如何偷偷从能力沉淀演变成流程负担。在代码层面，这个过程因为 AI 的介入被放大了十倍。

如果工程团队失去警惕，形式上的成熟感就会迅速取代对必要性的证明。

而这正是 AI 给工程师挖下的最大陷阱：它用极低成本制造出了极高复杂度的幻觉，让你误以为自己拥有了一个庞大而完备的系统，其实你只是被它用看起来合理的方式忽忽了。

删代码的本质：缩小系统对未来的‘承诺面’

讨论“删代码”，很容易走进另一个极端：误以为代码行数越少越好，或者删得越多就显得越高级。

有些复杂度是业务本身天生带有的，有些显式的代码虽然读起来长，但比晦涩的简写更容易测试和维护。为了可观测性、故障隔离和安全审计而增加的防御代码，绝对不能简单归为冗余。

真正需要通过“删除”来控制的，不是代码的物理行数，而是系统的‘承诺面’。

在软件架构里，每新增一个公共接口、一种状态持久化、一条隐式路由、一层通用适配，本质上都是团队在对未来作出长期的承诺：

• 这个接口以后不能随意重构，因为可能有依赖者；
• 这个状态以后必须向下兼容，因为有历史数据；
• 这层抽象以后必须有人能看懂，否则没人敢动底层；
• 这个配置项以后需要长期支持，否则改动就会破防。

你每让 AI 多生成一层没有真实业务证据支撑的抽象，你就在系统的未来承诺面上多埋了一颗雷。

因此，AI Coding 时代的工程目标，绝不是追求最少行数，而是：用最少的长期承诺，换取足够且可验证的业务能力。

当你指导 AI 删掉那五层多余的转发、删掉那个根本用不上的配置转换、删掉那个预想中“未来可能用到”的插件机制时，你不仅是在清除冗余行数，你是在帮系统把敞开的风险暴露面重新收缩回来。

这种删除，是在保护系统未来的选择权。

工程师角色的三次迁移：最好的删除发生在生成之前

回看过去这几年，AI Coding 工具的普及正在推动工程师的角色经历三次关键迁移。

第一阶段：代码生产者。 业务需求给出来，工程师的主要精力放在敲击键盘、实现逻辑、把代码一行行拼出来。

第二阶段：AI 产出的清洁工。 AI 在几秒钟内给出一大串代码，工程师像个疲惫的审计员，在海量的生成结果里挑选、对比、修补、删减冗余。

如果工程团队长期停留在第二阶段，那是极其痛苦的：你相当于给一个无限产出垃圾代码的实习生当全职扫地僧。

更成熟的第三阶段：系统的设计者与约束者。 工程师不再试图在 AI 生产完堆积如山的代码后再去艰难清理，而是把精力前置，在代码生成之前就建立起硬性约束：

• 在 Prompt 和 Context 里明确限制：“只做最小可行修改，严禁引入未被要求的抽象层”；
• 强制要求：“新增任何公共接口或转发层，必须给出具体的业务证据，否则拒收”；
• 明确交付标准：“能用几行直接逻辑解决的问题，绝不接受超过两层的封装”；
• 把“如何证明这段代码不能更简单”作为自动化验收和 code review 的硬门槛。

最好的删除，不是代码写进仓库后再花一周去打扫，而是这段代码从一开始就不被允许生成。

结论：AI 负责制造可能性，人负责约束可能性

在传统的工程师评价体系里，我们习惯看一个人“写出了什么”：写了多少模块、搭了什么框架、推出了多少功能。

但在 AI 时代，这种评价标准正在发生根本性的倒转。

AI 的强项是制造可能性。只要你给它一个方向，它可以瞬间吐出一百种可行或看似可行的实现方式。然而，可能性不是免费的，每一份未经约束的可能性，都在拉大系统的状态空间与测试代价。

人类工程师最稀缺的价值，不再是和 AI 比拼谁能更快地把可能性变成代码，而是拥有足够的判断力、直觉与魄力，把那一片无限膨胀的可能性，狠下心来压缩成一个足够小、足够清晰、可以长期承担责任的最小实现。

AI 时代，工程师不再只对写出来的代码负责，也开始对那些被成功阻止、因此从未出现的代码负责。

阻止正确但多余的代码进入系统，这才是今天真正值钱的工程手艺。

有同行感叹：“现在产品交互和表层功能的优势期太短了。一个新功能上线，领先优势大概也就两周，其中一周半还是竞争对手在开会讨论要不要抄。”

这和过往做产品的节奏完全不同。以前一个团队推出一个贴心功能，能享受数月甚至半年的独占红利，靠口碑和传播建立起深厚的品牌心智。即便后来者跟随，先发优势也已经转化为固定的用户资产。

但今天，这种先发优势正在以肉眼可见的速度塌缩。有了 AI 的辅助，从竞争分析、截图逆向，到交互拆解、代码生成甚至自动测试，复刻一个表层功能的门槛和时间被压缩到了几天。

很多人觉得这只是“行业太卷”或“大家不讲武德”。但如果拉长视角看，这其实是 AI 带来的一场结构性冲击：它同时引发了创新租金耗散、柠檬市场，以及表面质量通胀。

真正危险的，不是竞争变惨了，而是那些停留在中间层、靠熟练度与表层模仿生存的人和产品，正在失去最后的屏障。

表层功能的租金，被 AI 迅速蒸发了

经济学里有一个概念叫“可占有性”（Appropriability）。意思是，创新者能不能把自己的创新转化为能够持续收割的收益。

过去，抄袭是有高昂成本的：发现、理解、拆解、招人、开发、测试。这些步骤构成了天然的缓冲垫，让创新者可以靠独占期收回研发成本，赚取“创新租金”。

今天，AI 充当了超级放大器。一个功能发布，AI 可以在几秒钟内完成提取与分析，几分钟内吐出参考代码。

这就导致了创新租金的极速耗散。功能本身依然创造了价值，但创新者越来越难独占这份价值。你跑得再快，后面的跟随者靠 AI 几乎是零延迟地贴身紧逼。

与之伴随的是“红皇后效应”：每一家公司都不得不加速奔跑、频繁模仿，才能勉强维持原有的相对位置。大家跑得越来越累，产品却长得越来越像。

不是低质充斥，而是“表面质量通胀”

内容和设计领域的感受则更加明显。

最近在很多内容平台上，大量 AIGC 的设计图、AI 短剧、AI 策划案泛滥。单独看某一张图或某一段文案，完成度都很高，光影对、语法通、节奏顺，甚至比过去很多初学者的作品要精致得多。

但这恰恰构成了最隐蔽的陷阱：表面质量通胀。

过去，一张精致的海报、一段流畅的代码、一个优雅的动效，背后的隐含信号是“这个创作者投入了大量时间和专业训练”。它是一个高成本的能力信号。

当 AI 把这些表面信号的生产成本降到趋近于零时，精致与流畅瞬间失去了信号价值。

科学期刊《Science Advances》曾发表过一项实验：生成式 AI 确实能显著提高单个参与者的创作完成度，但从整个集体来看，作品之间的同质化极其严重，多样性大幅下降。

大家都用相似的基础模型、相似的 Prompt、相似的模板，最后产出了一堆“挑不出毛病，但极其雷同”的平庸高产物。

而在平台上，精心雕琢三天的原创作品，和十分钟生成的 AI 内容，在信息流里被平台用同一种注意力货币结算。

这就构成了阿克洛夫所说的柠檬市场（Lemons Market）：消费者很难在刷到的瞬间分辨其中的真实投入与独创价值，只能按平均质量支付注意力。高质量创作者得不到应有的溢价，逐渐收摊离开公开平台，转向封闭社群、私人订阅或直接退圈。

公共池里剩下的，便只剩下互相消耗的平庸内容。

中间层的塌陷：为什么“在中间厮杀”是死路

我在之前的文章《AI 时代，公司优势正在换地方》里讨论过：当生产一个功能的门槛被抹平时，功能的数量不再稀缺，真正的壁垒迁移到了闭环与责任层。

同样的逻辑，也适用于当下的每一个人。

受挤压最惨的，绝不是最顶尖的创造者，也不是纯粹的体力劳动者，而是中间层。

那些依赖熟练度、依靠标准化流程搬运、靠表层执行力吃饭，却没有形成独特判断力、没有独家私有上下文的从业者，在这轮表面质量通胀中首当其冲。AI 民主化了生产力，但绝没有民主化利润。

如果你继续停留在中间层，企图靠“比别人多加加班”、“比别人快两天抄出来”来维持竞争，结局是注定的。

面对这轮海啸，只有两条出路：要么追求卓越，要么远离战场。

往上走：追求卓越，建立“学习时差”

第一条路，是往上走，追求极致的卓越。

既然表层功能两周内就会被抄走，就绝对不能再把功能本身当成护城河。在《AI 应用的壁垒悖论》里我也写过，易于复制的表层灵活性反而会让产品极其脆弱。

合理的策略是：把每一个新功能，都当作开启组织“学习时差”的入口。

过去的先发优势是“我有这个功能，你没有”；未来的先发优势是“我比你更早观察到真实用户怎么用，积累了更深的私有上下文（Private Context），更早修改了业务流程，建立了不可替代的数据闭环与责任链。”

竞争对手可以抄走你的前端页面和开源代码，但抄不走你已经沉淀的用户习惯、数据反馈、权限体系和组织应对真实问题的经验。

追求卓越，本质上是把生产成本的降低，转化为对“私有上下文”与“托付信任”的极高下注。

往下走：远离战场，退守 AI 的防风浪港湾

如果不打算去上游拼极致的架构、复杂闭环与组织学习，另一种极其理性的选择是：彻底远离这片大模型主导的智力战场。

其实，有大量事情是 AI 极其难处理的。它们构成了天然的防风浪港湾，主要在于两类屏障：

上下文极难获取的“信息荒漠”

大模型再强，前提是它能获取高密度的上下文。但现实世界中，大量真正决定决策质量的上下文，根本不在公开互联网上，甚至不在任何结构化数据库里。

比如：复杂组织内部微妙的人际博弈与利益平衡、行业里口口相传却未书面化的潜规则、谈判桌上一个眼神背后的真实底线、线下现场瞬息万变的多模态感知。

在这些“上下文荒漠”里，AI 拿不到高质量输入，只能给出符合逻辑却脱离现实的高智商废话。那些能够深入现场、掌握一手私有上下文、能处理微妙人际信任的人，其决策质量是 AI 根本无法触及的。

非智力型、具身实操与物理温度场域

大模型解决的，本质上是符号化、文本化、代码化的智力活动。

而物理世界的真实实操：蓝领技术工人、精细的设备安装与故障抢修、高端护理、线下应急，以及带有明确人际道德履约和温度感的情感陪伴。这些需要具身物理交互与真实人类身份兜底的地方，AI 依然无能为力。

远离战场不是逃避，而是清醒地认识到：既然大模型打的是文本与符号的泛化战，就没有必要去它的主场硬碰撞。把阵地转移到它拿不到上下文、摸不到物理世界的真实生活里，本身就是一种极高明的战略避浪。

AI 扫平的是平庸

AI 并没有毁灭创作与创新的价值，它只是彻底扫平了平庸。

它把铸币机交到了每个人手里，结果挤爆了公共市场的信任。从此，表面上的精致不再值钱，复制的速度不再是壁垒。

面对这场变化，最糟糕的状态就是继续在中间层游荡：既没有上山建立私有上下文与责任闭环的决心，又舍不得放下表层智力工作的虚荣，去拥抱真实的现场与物理世界。

要么追求卓越，把每一个产品和作品做到不可替代；要么远离战场，去 AI 触达不到的地方扎根。

没有中间页，这就是这个时代给所有人开出的剧本。

这句话很抓人。我越想却越觉得奇怪。既然大家都知道开车比造车重要，为什么每天刷到的还是新 Agent、新 workflow、新产品，还有各种“我用 AI 把这件事做出来了”？为什么真实使用才决定一个东西有没有价值，我们看到的却总是它第一次跑通的样子？

再回头看看我自己的个人网站，其实也差不多。我做过不少小工具、Agent 和自动化任务。第一次跑通的时候最兴奋，也最容易写：问题是什么，我怎么做，最后出来了什么。可三个月之后它还在不在运行，中间人工救过多少次，需求变了以后有没有继续改，这些东西我很少回来补一篇。

我一边觉得外面的讨论太像车展，一边也在把自己的个人网站做成车展。

造车天然适合发出来

做出一个新东西，故事非常完整。有明确的问题，有解决方案，有截图，有视频，最好再来一个前后对比。哪怕读者不了解技术，几秒钟也能看懂价值。

群里有人分享 AI 游泳教练，分析一段训练视频，给出动作建议。也有人给孩子做墨水屏设备，把音乐和时间规则放进家庭日常。这些东西当然有价值，而且“第一次做出来”本身就值得分享。

但第一次成功，只回答了“它能不能做”。真正上路以后，问题才变成“它能不能一直做”。

游泳教练到了第二十次课还在用吗？水下光线一变，建议还准不准？孩子三个月后还看不看那块墨水屏？家里的规则改了，代码由谁继续维护？

这些问题没有揭幕时刻。它们散落在一次次使用里，表现为偶尔多核一遍、临时补一个逻辑、连接失效后重新配置，或者某一天开始就不再用了。没有人会专门截一张图，说这个 Agent 今天又稳定完成了第一百次任务。更少有人会发一条消息，说我折腾了两个月，最后决定放弃。

所以我们每天看到的 AI 进展，并不是现实使用的随机样本。传播天然会留下那些容易展示的第一次成功，把长期的摩擦、维护和安静放弃漏掉。

我们看到的是最高时速，不是行驶里程。

试过一次，离用进工作还很远

一项持续六个月的 NBER Copilot 现场实验很能说明这个差别。研究覆盖 66 家企业和 7137 名知识工作者，超过 90% 的人至少使用过一次 Copilot。只看到这个数字，很容易得出“AI 已经进入工作”的结论。

但研究者没有在第一次使用后就停止观察。十二周以后，每周使用者稳定在处理组的不足 40%。第四到第六个月，只有 5% 的人每周都用，20% 一次也没用。

90% 和 5% 不是同一个统计口径，不能简单写成采用率暴跌。但这个差别本身已经说明问题：试过一次，和真正用进日常工作，中间隔着很长一段路。

实验也不是说 AI 没用。实际使用的人每周少花了大约两小时处理邮件。问题在于，处理自己的收件箱，一个人就能改变；会议、协作文档、数据口径和组织流程，需要一群人一起动。模型能力可以在一次演示里突然向前跳，真实采用却要等习惯、流程和责任慢慢跟上。

我自己做工具时也有类似体感。第一次跑通，最难的是把功能做出来。等它真的开始反复运行，主要工作就变成了另一套东西：输入变了怎么办，外部系统变了怎么办，模型更新以后结果漂了怎么办，原来知道怎么补救的人不在了怎么办。

这些才是开车的经验。但它们太碎、太慢，也太不体面，所以很少进入公开讨论。

个人网站不该只有新车发布会

我之前写过《AI 时代，失败比成功更值得记录》。那时我想说，失败样本比成功故事更有信息量。现在再往前想一步，失败和长期摩擦之所以稀缺，不只是因为大家报喜不报忧，也因为它们不适合传播。

第一次跑通可以压缩成一分钟视频。一个工具三个月里如何被反复修补、逐渐稳定，或者慢慢没人再用，很难压缩成一个高光时刻。

这也让我重新想了一下个人网站的价值。

记录第一次做出来当然没有问题。问题是，如果只记录这一刻，几年以后回头看，留下来的就只是一排新车，没有一张里程表。

以后除了写“我做出了什么”，我更应该回来补几件事：它现在还在不在运行，完成了多少真实任务，需要多少人工干预，最后如果停了，又是为什么停。

个人网站不只是展示我会造什么，也应该留下我真正开过什么。

一辆车有没有价值，不看它发布时围了多少人，要看第一百次任务时，它还在不在路上。

以前，这个问题大概率会先留在备忘录里。因为真要动手，查资料、改代码、跑测试，至少还要一两个小时。时间不够，工作自然停在这里。

现在只需要十几秒：“把这个问题查清楚，顺便做个可运行版本，测试完告诉我。”然后合上电脑。人离开了，任务却刚刚开始。

这个动作只占用了十几秒，却可能启动两小时的后台工作，也提前为第二天制造了一项必须重新进入的任务。

我越来越觉得，AI 真正改变的不只是工作的速度。它在改变工作的时间结构。

人停了，工作没有停

传统工作原本有一道清楚的边界：人与任务大体同步在场。

写文档时，人要坐在那里写；查资料时，人要一页页看；改代码时，人要不断操作。停止操作，工作通常也就停了。哪怕脑子偶尔还在转，至少不会继续产生一批新的交付物。

Agent 把这条边界拆开了。任务在十几秒内发起，执行发生在人离场之后，收口落在几个小时后，甚至第二天。发起、执行和未来收口不再发生在同一段时间里。

所以它不一定让人此刻一直工作，却能让工作始终在进行。

这也是为什么“今天到底工作了多久”开始变得难回答。人在电脑前坐了两个小时，后台可能同时跑着四条任务；人已经去吃饭、陪孩子、睡觉，工作仍在继续生长。过去我们用操作时间衡量工作，现在操作停止了，承诺还在累积。

十秒钟开始有了杠杆

短视频占用的是现在。刷十分钟，失去的就是眼前这十分钟。

Agent 抵押的是未来。发一条十秒钟的指令，当下几乎没有痛感，几个小时后却会回来一份结果，要求你重新进入上下文，做决定，或者继续派下一轮任务。

碎片时间过去只是可利用的余量，现在开始有了杠杆。

以前五分钟只够记下一个想法。现在五分钟可以发起十几个任务。每个任务都在后台独立生长，然后在未来某个时刻回来敲门。

我前几天在《AI 时代最贵的不是 Token，是自己的认知带宽》里写过，这些动作像是在从未来的自己那里借时间。那篇文章讨论的是产出回来之后，这笔债怎么偿还。现在我更在意另一个问题：为什么我们如此容易创造这笔债？

答案其实不复杂。Agent 把借钱的动作变成了一次点击。启动成本低到几乎可以忽略，未来成本又暂时看不见，于是人会不断签下新的工作承诺。

“AI 会不会让人早下班”问错了

关于 AI 提效，一个常见想象是：原来八小时的活，现在四小时做完，于是人可以提前下班。

这个推理暗含一个前提：工作量是固定的。

对边界明确的任务，这个前提可能成立。今天就是处理一百张单据，AI 做掉八十张，人确实能少做一些。但对自驱型知识工作者，任务需求很少是固定的。想法、改进、实验和项目几乎没有上限。过去限制它们进入执行的，主要是时间和启动成本。

当执行成本降下来，原本不会发生的事情就开始发生。

一个只值得记在备忘录里的念头，现在可以顺手让 Agent 研究一下；一个投入产出不确定的小功能，现在可以先做出来看看；一个以前懒得验证的假设，现在可以同时开两条路线跑。单个任务确实更快了，进入运行状态的任务也更多了。

省下来的时间不会自动变成空白。它更可能变成下一批任务的启动资金。

对这类人来说，AI 提效并没有把一个固定任务池清空得更快。它让任务池以更低成本持续扩张。下班没有消失在某个加班指令里，它消失在一次次“顺手再跑一个”的动作里。

最先停不下来的，可能是最自驱的人

这也是这件事最反直觉的地方。

最先感受到这种变化的，未必是被老板强迫加班的人，而是那些最自驱、最有想法、也最会用 AI 的人。因为他们面对的不只是任务太多，还有想做的事情太多。

过去，执行成本会替他们做一次自然筛选。很多想法因为“做起来太麻烦”留在了备忘录里。这个筛选当然粗糙，却有效阻止了一部分低优先级任务进入现实。

Agent 把这道门槛拆掉之后，人很容易从执行工作的人，变成管理数字劳动力的人。电脑闲着会觉得浪费，额度没用完会觉得可惜，并发位空着会忍不住再开一个任务。既然数字员工二十四小时都能干活，为什么要让它空着？

这听起来像资源利用率，实际上可能只是把工厂思维搬到了自己身上。

算力空闲不等于价值浪费。Agent 满负荷，也不等于人在做最重要的事。当“不让数字劳动力闲着”变成目标，工作承诺的生成速度就可能超过未来注意力的承接速度。

新的下班动作

Agent 时代，需要治理的不只是工作时长，更是工作承诺的生成速度。

这和晚上几点关电脑关系不大。电脑可以关，后台任务还在跑；通知可以静音，等待你的结果并不会消失。只要还在不断给未来派活，形式上的下班就只是离开操作台，并没有停止生产新的承诺。

真正的边界要往前移。

在发起一项任务之前，多问一句：这件事只是能做，还是值得做？这个想法必须今天进入执行，还是可以继续留在备忘录里？Agent 现在有空，是否就意味着必须给它找点活？

这不是劝人少用 AI。只有真的把 Agent 用到足够重，才会发现高级用法不再是让它始终忙碌，而是有能力决定什么不进入执行。

下班也因此有了新的定义。

下班不再只是停止操作，而是停止给未来派活。

真正成熟的 AI 使用，不追求最大化 Agent 的利用率。它允许一些想法继续躺在备忘录里，允许一些并发位空着，也允许算力在今晚什么都不做。

因为真正稀缺的，不是可调用的算力，甚至不只是时间。

而是一段没有被任何待验收结果提前预订的未来。

这两个哥们儿太能干了。以前让模型做一件事，我担心的是它做不到、做不完整、走着走着忘了目标。现在麻烦反过来了：它不光把你要的事做了，还会把路上看见的问题一并收拾掉。顺手重构一段代码，顺手修一个工具脚本，顺手改一下它认为不够合理的 Skill。做完以后还会告诉你，这些额外工作也一起处理了。

放在这一次任务里看，它经常是对的。问题确实存在，修改也确实能让任务跑得更顺。但我的老鸭汤不是这一次任务的附属品，它是一套多台电脑共用的 Skill 和工具系统。这里顺手改得很漂亮，另一台电脑上的自动化任务可能就漂了。

这给我的感觉很像公司里突然来了几个能力超强的新人。业务理解快，执行力强，发现问题还主动补位。唯一的问题是，他还没弄清楚公司里哪些东西属于自己的职责，哪些看起来不合理却牵着别的团队。结果就是，局部交付很好，全公司开始跟着他改流程。

这不是执行错误，是授权错误

我一开始把这种感觉叫“太自信”。后来查了一圈，发现更准确的说法应该是授权缺口。

Agent 没有误解目标。恰恰相反，它知道怎样能把目标完成得更彻底。它看到一个旧脚本挡路，判断改掉脚本比绕过去更合理；看到一份 Skill 写得不够好，判断顺手修正能避免后面再出问题。每一步单独拿出来都说得通。

但“这个动作对目标有帮助”和“你被授权做这个动作”是两回事。

一项刚出来的 coding agent 研究专门测了这种行为。最有意思的不是某个模型的数字，而是同一个模型放进不同 harness 以后，越界率可以从 1.1% 变成 27.7%。边界声明写得清不清楚，遇到相邻问题要不要先问，影响甚至可能大过换了哪个底模。

OpenAI 自己在 GPT-5.6 的 system card 里也承认，它比 GPT-5.5 更容易超出用户意图。这里的“超出”不一定是做坏事，很多时候就是太执着于把事情做完。能力变强之后，模型能想到的合理下一步更多了，能调用的工具更多了，行动速度也更快了。以前它看不见公司里那些可以优化的地方，现在它看见了，而且真敢动。

我以前关于结果确定性的判断，只说对了一半

过去几年，我们一直在把 Agent 的约束从过程确定性迁向结果确定性。

模型不够强的时候，只能把步骤写得很细：先读哪个文件，再跑哪条命令，失败以后走哪个分支。后来模型变强了，这种写法开始妨碍它发挥。于是我们逐渐减少路径指引，把重点放到“什么叫完成”和“怎么验收”。

这个方向没有错。我在《错题集越厚，AI 为什么反而更容易做偏？》里写过，负面约束越积越厚，会和主任务争夺注意力。与其不断补“不要这样”，不如把完成定义和验收 gate 写清楚。

但这次的体感让我意识到，这个判断只说对了一半。

完成定义解决的是：做到什么算结束。它没有解决另一件事：为了做到这个结果，你可以改变什么。

比如，让 Agent 把这篇随笔发布上线，结果验收可以写得很清楚：文章页面能打开，首页有入口，RSS 和 sitemap 都更新，线上正文和本地一致。但这些验收条件并没有授权它去重写发布 Skill，也没有授权它发现部署脚本不顺手时，直接把多台电脑共用的工具改掉。

所以在过程确定性和结果确定性之外，现在还得补一层授权确定性。

过程可以让它自己选，结果必须能验证，但改动半径不能由它为了完成局部目标自己扩大。看见问题，和获得修改权，是两件事。

聪明人不需要更厚的员工手册

我不想因为新模型爱多干活，就退回当年把每一步写死的时代。那等于公司好不容易招到几个高手，又要求他们严格照着十年前的 SOP 办事。

真正要补的不是更多路径，而是更清楚的权责边界。

普通任务目录里的代码，只要目标和验收清楚，可以让它放开做。项目级的公共模块或规则，发现问题可以提修改方案，但要把影响面说出来。跨电脑共享的 Skill、全局 harness、定时任务入口，则应该默认进入保护区：可以读，可以诊断，可以给 diff，但不能在完成另一个任务的时候顺手写进去。

这也是群里另一个案例给我的提醒。有人让模型更新软件，平常会直接杀掉旧进程。这次模型发现 TCP port 还连着，判断可能有人正在使用，于是停了下来。后来一问，确实有同事在用。

这个案例很容易让人觉得，模型已经有很强的边界感了。我的看法稍微保守一点：它说明明确的风险信号很有用，不说明我们可以把边界全交给模型自己悟。

端口占用、工作区有别人没提交的改动、目标路径属于共享 Skill、操作会影响其他电脑，这些都应该尽量变成机器能直接读到的信号。聪明是第二道防线，第一道防线还是系统把风险做成了它无法忽略的事实。

effort 不是智商档，更像加班预算

群里还聊到一个很实际的问题：是不是 effort 开得太高了。

我觉得有关系，但不能简单理解成“高档位更爱瞎干”。高 effort 更确定的变化是，它会探索更多可能、检查更多边角、补更多隐含义务。GPT-5.6 的 ultra 甚至默认拉四个 agent 并行干活。方向和边界都清楚时，这些都是战斗力；边界没锁住时，它也会把 review surface 和爆炸半径一起放大。

所以 effort 不是一个越高越好的智商按钮，更像你批给一个团队的加班预算。

目标封闭、环境隔离、验收很硬的任务，可以让它多想、多试、多跑几轮。需求还在形成、需要人在过程中不断 shape direction、改动面尚未锁定时，medium 往往更合适。不是模型变笨一点更听话，而是这类任务本来就不该一次给出太大的行动半径。

早先公司里是一群不太聪明的人，所以管理靠条条框框；后来来了一批能力强的人，管理开始只盯结果；再后来，公司里全是能力超强、没事就自己卷起来的人，问题又变了。

这时候不能重新把他们按回流水线。也不能只看他这次把活干完了没有。

真正成熟的管理，是让聪明人知道哪里可以尽情发挥，哪里必须停下来问一句。对 Agent 也是一样。

模型越聪明，过程可以越松。模型越聪明，授权边界反而要越硬。

晚上打开 Codex 和 Claude Code，同时推进几件事。一个 agent 在改代码，一个在补文档，一个在查资料，另一个在跑测试。睡觉之前回头看，过去可能要一周才能做完的东西，一个晚上已经堆在仓库里了。

按产出来算，这当然是巨大的提效。

可第二天早上重新打开项目，我有时做的第一件事不是继续往前，而是从头读一遍昨天的产物。这个模块为什么这样拆？这个结论是验证过的，还是 agent 当时顺手选的？这份文档里哪句话是我的判断，哪句话只是模型写得很像我的判断？

代码未必有错，文档也未必不好。让我不舒服的是另一件事：它们明明是“我做的”，我却没有完全在场。

自己的产出开始把我甩在后面

我之前在《用得越多，想得越少：AI 时代的认知退化悖论》里写过，问题不在用不用 AI，而在谁先动脑。

重度使用 AI Coding 之后，我发现这只回答了一半。

现在更难的问题是：动过脑之后，产出真的完成了吗？当代码、文档、分析和方案同时从几个会话里涌出来，谁真正理解它们，谁能解释当时的取舍，谁愿意在三个月后继续维护？

模型的生产带宽可以不断加。Token 不够可以买，会话不够可以开，agent 不够可以并行。可我只有一套注意力，一套工作记忆，一个此刻能真正想清楚的问题。

AI 把生成变得近乎并行，人对复杂问题的理解却仍然高度串行。每切换一个任务，我都要重新加载目标、限制条件、已经排除的方向和下一步要验证的东西。会话可以压缩，人脑没有一个按钮，能把昨晚四条工作线完整恢复到内存。

所以，AI 时代最容易忽略的成本不是 token，而是自己的认知带宽。

我省下来的时间，可能只是欠给了明天

以前自己写一段代码，理解常常发生在写的过程里。变量为什么这样命名，状态为什么放在这里，这个边界为什么不能再往外扩，很多判断是在动手时逐渐形成的。

现在生成只要几分钟。理解不再和产出同步，成了一件可以推迟的事。

“先接受，回头再看。”

“测试过了，应该没问题。”

“让下一个 agent 接着做，它有上下文。”

这些话每说一次，都像从未来的自己那里借了一点时间。债务不会消失，只是换一种形式回来：重新阅读、恢复上下文、验证边缘情况、追问当时为什么舍弃另一条路。

我越来越觉得，AI Coding 里的认知债务其实很具体：产物先落地，理解留在后面。它不是大脑变笨的证据，也不意味着用了 AI 就一定退化。经手过不等于掌握过，完成过也不等于拥有过。

更麻烦的是，AI 省下来的时间很少真的留给理解。大多数时候，我会立刻再开一条任务。生产带宽刚释放，更多并发马上就把它填满。表面上每个 agent 都在忙，实际上排队等我验收的工作越来越多。

我一度把这种画面理解成效率。现在我更愿意把它理解成库存。

信任是在“为什么”答不出来时开始下降的

认知债务只留在自己这里，最多是第二天多花一点时间。可一旦把它交给别人，问题就变了。

一份 PR 表面上是一包代码，背后其实有一份没有写出来的承诺：我理解它为什么这样改，我做过第一轮验证，我能回答问题，出了问题我愿意继续接。

AI 可以帮我写完代码，不能自动替我签下这份承诺。

前阵子开源社区有一个 13K 行的 AI PR。代码量和 AI 参与都不是最麻烦的部分。提交者面对一个很基本的署名问题时，也说不清为什么会这样。维护者看到的就不只是一份待审代码，还是一大包没有明确主人的判断和未来的维护成本。

如果 reviewer 问我“为什么这里要这么设计”，我第一反应是回到会话里问 agent，那就说明第一轮理解并没有完成。我只是把省掉的认知工作原封不动交给了 reviewer。

这也是为什么我不认为 AI 会自动消灭代码所有权。所有权本来就不等于每一行都亲手写。它可以从“我写了这些字符”，上移到“我决定了意图和架构，我检查了关键假设，我愿意纠错和维护”。

让信任下降的不是 AI 写了多少，而是最后没有一个人能站出来说：我知道为什么，我确认过，我来负责。

我开始故意保留几段慢动作

这不是要退回手写一切。手工把 AI 代码再敲一遍，也不会神奇地把理解补回来。需要保留的摩擦，是那些会迫使我重新判断、预测和验证的动作。

我现在不再把“同时开了多少 agent”当成效率指标。能在回来时快速恢复、能完成验收的并发才有价值。否则只是在制造更多等待我理解的库存。

每次长会话结束，我会留一份很短的 Handoff。不是让 AI 总结今天做了什么，而是我自己写清四件事：目标是什么，已经做了哪些关键决定，还有什么没想明白，下一步要验证什么。它不是给 agent 看的日报，是给明天的我留的一条返回路径。

关键改动的 commit message，我也尽量自己写。AI 可以帮我润色，但第一版必须能用自己的话说明：为什么改，舍弃了什么，风险在哪里。如果写不出来，往往不是表达能力有问题，而是我还没有真正拥有这次修改。

测试同样重要，但我开始把“测试通过”和“我理解了”分开。测试可以证明一些结果，没办法替我回答意图和取舍。重要模块在交付前，我会逼自己复述一次。如果解释不了，就不算完成。

过去我最在意的是，怎样让 AI 一次做更多事。

现在我更在意的是，怎样让这些事做完之后，仍然有人理解它们。

AI 可以替我把东西做出来，但不能替我成为那个知道为什么、出了问题愿意负责的人。

产出可以外包，理解和责任不能。

我一直不太愿意用商业成功来解释我们为什么做 DeepSeek。不是因为商业不重要，而是因为一家公司从哪里出发，决定了它后来会被什么驱动。我们最初聚在一起时，没有人讨论上市、估值或者资本市场，也没有人认真计算最后能赚多少钱。最开始的几十个人，如果是为这些而来，大概不会选择加入。

我们只是觉得，人工智能是一件对人类有用的事情。它足够重要，也足够有趣，值得一群普通人把时间放进去。对我们来说，它首先是一件金钱以外的事情。

后来，行业变得越来越大，利益越来越多，诱惑也越来越多。公司做大以后，外界会自然地用收入、用户、市场份额和估值来衡量你。每一个指标都合理，但它们不是我们的起点。我们的出发点一直不是商业利益最大化，而是提高把智能这件事做成的概率。理解这一点，才能理解我们为什么坚持开源，为什么愿意降价，为什么没有在用户最多的时候全力做商业化，也为什么不愿意把产业链上的所有业务都抓在自己手里。

愿景不是墙上的一句话

大概二十年前，我在管理上比较崇拜杰克·韦尔奇。现在回头看，他讲过的很多东西可能已经不适用于今天，但有一点我仍然认同：一家公司最重要的是它的愿景。

愿景不是挂在墙上的一句标语。愿景是你怎么做，不是你怎么说。

很多公司会写使命、价值观和文化手册。我们没有写过这样的东西。至少在很长时间里，我们的愿景不是成文的，它存在于我们做事情的方法里，存在于我们怎样对待利益、怎样对待同行、怎样对待用户，也存在于我们决定不做什么的时候。

公司里的每个人，对这个愿景的理解可能并不完全一样。每个人进入公司的原因也不一样。但在一个更大的方向上，大家是一致的：我们希望怀着对这个世界的善意，做一点真正有用的事情。

这就是我们最早的组织方式。

所以我有时会说，我们公司没有组织。

这当然不是说完全没有分工，也不是说所有事情都随便做。我的意思是，我们不是主要依靠规章、考核和层级把人组织起来的。我们更依靠一种没有被明确写下来的共识。

一群人为什么愿意在一起研究一个很难的问题？为什么没有 KPI，很多人还是会主动做很多事情？为什么模型降价以后，团队里的很多人不是失落，而是高兴？因为他们认为，这正是自己来这里的原因。

这种组织方式有好处，也有坏处。人少的时候，它让我们非常灵活；人多以后，它也一定会遇到边界。未来，我们需要建立更清晰的部门和协作机制，有些团队需要更加严谨的层级，有些团队则应该继续保持松散。

但不管组织形式怎么变化，我希望最核心的东西不要变。制度帮助一个组织运转，愿景决定一个组织为什么值得运转。

开源不是一种姿态

外界经常把开源理解为一种商业策略。这当然没错，开源对商业是有帮助的。但对我们来说，事情的顺序不是先有商业计算，再决定开源。

首先是愿景本身要求我们开源。

如果我们认为人工智能是一件应该对更多人有用的事情，就很难一边这么说，一边把最重要的能力全部锁起来。我们希望别人能够使用它，也希望别人能够在我们的基础上继续做东西。

有些公司的开源带着一种被迫的感觉，可能是为了应对市场竞争，也可能是为了获得开发者生态。我们不是这样。对我们来说，开源就是本意。

但开源也不只是价值选择，它背后还有一套商业判断。人工智能和过去的软件不一样。过去，一个软件市场可能一年只有几十亿美元，一旦开源，原本属于一家公司的收入可能大幅缩水。但人工智能可能影响人类社会非常大的一部分生产活动。它最终创造的价值会非常大，大到任何一家公司都不可能独占。

你越想独占，就越不可能做成。

因为当一个事物大到会影响整个社会的时候，它就不再只是一个公司的商业问题。它会遇到产业、政策、技术、资本和社会认知上的各种阻力。

所以，如果我们真的想把这件事做成，就必须接受一个事实：我们能够获得的利益是有限的。

这不是悲观，而是一种历史观。一个足够大的技术，必须和很多人分享。你需要让产业链上的其他人有利益，让应用公司有利益，让开发者有利益，让用户得到足够低的成本，也让同行有继续探索的空间。

我把这种选择叫作克制。

克制不是道德装饰，而是一种战略

很多人听到克制，会把它理解成一种道德态度。但对我来说，克制首先是一种战略。

假设 AGI 最终具有非常大的商业价值，我最应该考虑的事情，不是怎么多拿一点份额，而是怎么提高我们把 AGI 做成的概率。

这两个目标看起来相似，实际上经常冲突。你想拿到更多短期利益，就会做更多短期业务；做更多短期业务，就需要更多人、更多管理、更多销售、更多产品线和更多协调。组织的注意力会逐渐从技术突破转向收入、用户和竞争。

这些事情本身没有错。问题是，它们会不会提高我们做成 AGI 的概率？

如果不能，甚至会降低这个概率，那么收入越高、用户越多，未必越接近真正的目标。

所以，我们在定价的时候，也不是以收入最高为第一原则。我们的逻辑很简单：公司应该获得合理利润，能够覆盖风险、研发和长期投入，但没有必要把用户愿意支付的每一分钱都拿走。

我们曾经按照一批设备大约十个月回收成本来计算 API 价格。从纯粹的利润最大化角度看，这个价格可以更高。因为在某些价格区间里，用户需求没有那么强的价格弹性，价格即使提高，使用量也未必明显下降。

但我们不认为这意味着应该涨价。

有一次，一个模型刚开始上线时，因为担心需求太多，价格定得比较高。后来价格降到了原来的很小一部分，公司群里很多人都很高兴。

这种反应对我很重要。它说明，团队不是把降价看成收入损失，而是认为自己做的东西终于能被更多人充分使用。大家花了那么多精力把模型做好，本来就是希望它效果足够好，也足够便宜。

十个月回本仍然可以被认为利润不低。我也承认，随着模型和系统继续优化，价格还有下降空间。但价格并不是越低越好。当价格已经低到大多数人都能负担，再继续降价，未必会创造更多需求，也未必会增加多少社会价值。合理的价格，不是无限接近零，而是在企业能够持续投入与用户能够充分使用之间找到平衡。

克制并不意味着我们不赚钱。它意味着我们不以赚到最多的钱为目标。这两者差别很大。

不要把路边所有的芝麻都捡起来

去年春节，用户突然变得很多。那不是我们原来的剧本。我们并没有提前计划要做一个超级 App，也没有准备和大厂争夺 C 端流量。用户突然涌进来以后，按照通常的商业逻辑，我们应该立刻做留存、增长、广告、会员和商业化。

我们当然有能力做其中一些事情，也可以投入大量资金去争夺用户，试图把它做成下一个流量入口。

但我们没有那么做。

不是因为那些用户没有价值，而是因为我们不希望把它当成公司的主要目标。我们努力把服务维持好，也用相对低的成本保留了用户，但没有围绕用户规模重构整个组织。

我当时的判断是，后面还有西瓜，前面这些可能只是芝麻。

有些芝麻也很大，顺手能够捡起来，我们会捡。但我们不应该为了捡芝麻停下来，更不应该把所有人都调过去捡芝麻。

B 端和 API 的收入也可能成为一个很大的机会。如果需求继续增长，它可以覆盖研发费用，甚至让公司的现金流回正。这当然是好事，我们会把它做好，但它依然不是第一优先级。

因为 To C 也好，To B 也好，本质上都是我们做 AGI 过程中产生的中间结果。我们不是为了做一个聊天产品，才去训练更好的模型；也不是为了卖 API，才去研究模型架构。

我们是为了做 AGI 而做 AGI。

走在这条路上，阶段性的模型能力可以服务用户，也可以形成收入。我们就把这些能力提供出来。

这和很多公司的方向相反。很多公司先确定产品和市场，再围绕产品需要训练模型。我们先提高智能的上限，再让这些能力自然溢出到产品和商业化里。

这可能是一种降维。当你站在更高的技术目标上，去完成一个相对局部的产品目标，有时候不需要投入那么多额外精力。

技术快速变化的时候，最好的产品战略有时不是把更多人放到产品上，而是先把底层能力推得更远。

AGI 不是突然出现的一道闪电

每个人对 AGI 的定义不一样。对我来说，可以从一个很现实的问题来理解。

现在这一代人工智能，如果你能够把问题描述清楚，给它完整的上下文和准确的指令，它在很多任务上已经能超过人类。难点就在完整的上下文。

假设公司里来了一位新员工。最开始的两个月，他需要了解业务、同事、流程和历史。他逐渐知道谁负责什么，知道一句话背后的真实意思，也知道哪些事情不需要写在文档里。

过了两个月，你对他说，把小王叫过来。他知道小王是谁，在哪里，为什么要找他，也知道应该用什么方式沟通。

但对 AI 来说，你必须把所有这些信息重新解释一遍。小王是谁，他是什么职务，他在哪里，为什么找他，沟通时需要注意什么。

这在现实中是不可行的。

所以，今天的 AI 可以在一个局部、完整、清晰的上下文里做得很好，却还不能像一个真正的员工那样进入组织、理解环境并持续成长。这里缺少的是持续学习。

回头看，人工智能的发展很像一段阶梯。最早是语言模型。之后是思维链，模型开始通过思考提高自己的能力上限。再往后是 Agent，模型不仅回答问题，还能调用工具、拆解任务，完成更长的工作流程。

Agent 之后，下一道能够看见的障碍，就是持续学习。

模型不能只在训练结束的那一刻拥有能力。它需要像人一样，在长期工作中积累经验，理解新的环境，形成新的记忆，并把这些经验真正转化为能力。

持续学习之后，模型可能进入自我迭代的阶段。它可以参与开发自己的下一代版本，帮助研究新的算法，优化训练系统，也可以进一步提高人工智能研究本身的效率。

很多人把这个阶段叫作奇点。但我不认为它一定是一个突然发生的瞬间。它可能是一个连续的过程，只是这个过程并不是线性的。

因为当 AI 开始帮助研究 AI，研发速度就会被进一步加快。每一代模型都会成为开发下一代模型的工具，所以后面的进步可能越来越快。

再往后，才是具身智能。当智能能够进入现实世界，它可以做家务，可以照顾老人，可以制造和维护下一代机器人，最终真正进入人的衣食住行。

这是我们更愿意相信的一条路线：语言模型、思维链、Agent、持续学习、自我迭代，然后是具身智能。

它不一定是唯一正确的路线，但它可能是一条相对省力的路线。

我们并不崇拜困难，也不认为一件事越苦越有价值。理想的技术路线，应该让前一步成为后一步的工具。如果先解决持续学习，模型就能帮助我们研究自我迭代；如果先实现能够自我迭代的智能，再去做具身，很多机器人研发工作也不必完全依赖人。

我们希望走一条不用长期依靠堆人、加班和重复劳动的路。

下一代模型，首先应该对我们自己有用

我们内部有一个看起来比较奇怪的想法。我们做出的模型，第一目标不一定是让所有用户立刻觉得好用，而是先让 DeepSeek 自己觉得好用。

它应该先帮助我们开发下一代模型。

它应该能够帮助研究员写代码、做实验、阅读结果、寻找异常、生成新的假设。即使还不能独立完成研究，只要它能让人与 AI 的协作效率明显提高，就已经很有价值。

为什么首先强调对自己有用？因为这是实现 AGI 更快的路径。

当模型能够帮助我们提高研究效率，我们就能更快地做出下一版模型。下一版模型又能提供更强的帮助。这个循环一旦成立，研发效率就不再只取决于团队增加了多少人。

今天我们已经很确定，人工智能会帮助我们研究人工智能。它还不能自主完成全部工作，但它已经能够参与很多环节。

持续学习之所以重要，也在这里。现在的 Agent 能力会受到上下文、记忆和长期适应能力的限制。它可以完成一次任务，却很难像一个长期同事那样，在反复工作中形成稳定经验。

如果持续学习能够解决，AI 对研究的帮助会大幅提高。到那时，很多原本需要依靠大量人力、数据和工程投入的问题，可能会变得容易多。

所以，持续学习并不只是 AGI 的一个功能。它可能是加速通往 AGI 的工具。

我们唯一不能退让的，是团队稳定

如果一定要问，DeepSeek 的核心利益是什么，我觉得只有一个。就是团队的稳定性。

钱和资源都可以想办法解决。算力不够，可能让我们晚半年或者晚一年；一次模型效果不好，也可以继续迭代；商业化速度慢一点，公司仍然可以寻找其他收入。

但如果真正重要的人不断离开，团队失去连续性，很多积累就会中断。

只要团队能够保持稳定，我们就可以一直做下去。遇到挫折，也可以重新开始；路线走错了，可以调整；模型没有达到预期，可以再做下一版。

所以，相对于收入、用户和市场份额，我更关心团队能不能长期待在一起。

我们的人才优势并不是每个人都比别人聪明。

我不喜欢一群天才改变世界这样的叙事。我们更愿意把自己看成一群平凡的人。大家是在一个比较随机的过程中聚在一起的。

我更喜欢另外一种叙事：一群平凡的人，通过共同的愿景和合适的组织方式，做出一件不平凡的事情。

真正的优势不只是人才本身，而是人才如何被组织起来。把很多聪明人放在同一个地方，不代表他们自然会合作，也不代表他们会长期保持热情。你需要让每个人理解自己为什么做这件事，也需要让人相信，自己的工作和一个更大的目标有关。

模型能力可以被追赶。某一代模型领先几个月，并不是永久优势。但一个能够长期稳定合作、愿意探索真正困难问题的研究团队，没有那么容易被复制。

没有 KPI 的组织，也要学会长大

我们公司的管理，大体上有两条线。一条从上到下，一条从下到上。

从上到下，是公司需要共同完成的正式任务。比如要发布一代模型，需要明确分工，需要很多团队一起配合，需要有人负责训练、评估、部署和发布。这种工作不可能完全依靠兴趣。

但我希望，正式任务最好不要占据一个研究员全部时间，甚至不要超过一半。

剩下的时间，应该由个人决定。他认为哪个问题重要，就去研究哪个问题。他可以验证自己的想法，也可以参与其他人的探索。只要需要的资源在合理范围内，不一定要先获得层层批准。

很多真正重要的问题，并不是公司设立一个项目组就能够解决的。比如持续学习。现在全世界都没有明确答案。它不是一个已经知道路径、只需要执行的工程项目。

对于这种问题，我们内部有时会说是在摸奖。参与门槛并不高，不一定需要大量算力，也不一定需要一个固定团队长期投入。很多人都可以想，都可以做小规模尝试。但最后谁能够摸到一个真正有效的方法，并不容易提前规划。

所以，公司需要让人有时间思考这些问题。

研究文化需要松弛感。如果每天都被任务填满，被进度和考核追赶，人就很难长期思考那些没有确定答案的问题。

我们不太加班，一方面是研究本身需要相对宽松的环境；另一方面，是因为我们做的事情比较少。

聚焦意味着少做事情。我们没有把所有产品细节补齐，没有进入所有热门方向，也没有因为某个新概念突然变热就立刻建立团队。

因为我们克制，所以任务少；任务少，每个人就不需要依靠长时间加班完成工作。

这不是一种福利设计，而是组织战略的结果。

当然，随着人数增加，这种方式必须改变。有些部门需要明确的层级、流程和责任，否则事情无法推进；但研究部门仍然需要保留更扁平的结构和自由探索空间。

我们没有一个可以直接模仿的对象。我们不是 OpenAI，也不是 Google，更不是贝尔实验室。贝尔实验室不需要独立解决商业生存问题，我们需要。

所以，只能根据现实不断调整。一个研究组织最危险的事情，不是发生变化，而是在规模变化以后，仍然假装原来的方式可以永远不变。

中国真正缺少的，不是聪明人

很多人会问，中国和美国在人工智能上的差距究竟是什么。我的看法比较简单：主要是资源。

人才当然有差距，但人才差距背后仍然有很大一部分是算力差距。

当一个团队拥有更多算力，就可以做更多实验。研究员有更多机会验证想法，也有更多机会在失败中积累经验。实验做得多，人才成长就更快。

所以，算力不仅影响模型规模，也影响研究能力和人才培养。

中国并不缺聪明人。国内外本来就是相近的人群。有些人留在国内，有些人出国，很难说最聪明的人都去了某一个地方。中国每年还有非常大的工程师和研究人才供给。

真正的问题是，国内的资本投入和可获得算力远少于美国。

在这样的约束下，我们只能训练更小的模型，或者用更长时间追赶。我们的现实叙事曾经是：比美国晚一段时间，用它很小一部分的算力，把相近的能力做出来。未来，我们希望把时间差进一步缩短，也希望在部分重点能力上取得领先。

但如果总体算力仍然存在数量级差距，全面领先是不现实的。

承认资源约束，并不等于放弃竞争。资源不足会迫使我们更重视效率。我们必须在模型架构、训练方法、推理系统和工程实现上做更多优化。

这也是为什么我们一直强调低成本。低成本不仅影响 API 定价。在同样的算力下，计算效率更高，我们就能训练更大的模型，做更多实验，也能承担更长的上下文和更多推理。

效率对资源充足的公司可能只是一个优化项，对我们来说，它会直接决定哪些研究能够进行。

在国产算力上，我相对乐观。过去国产芯片最大的障碍之一是生态。大家买到卡，却很难像使用英伟达一样方便地用起来。

但这个问题正在发生变化。人工智能本身可以帮助编写代码，高级编译语言也可以大幅降低构建算子和迁移系统的成本。我们正在尝试用更高层的编译工具，减少对传统 CUDA 生态的依赖。

生态问题可能比很多人想象中更容易解决。真正更困难的是产能。软件可以在相对短的时间里重写，制造能力和供应链不能。未来几年，国产算力可能仍然会受到产能限制，但我不相信更长时间以后，我们还会停留在今天的位置。

最后的差距，是成本、时间和体验

很多人会问，当所有大模型继续发展，最后各家模型的差距会体现在哪里。

我的判断是，长期来看，能力差距未必会像今天想象得那么大。最终可能主要体现为三件事：成本、时间和用户体验。

第一是成本。

在提供相同质量服务的情况下，谁能够用更低成本完成，谁就拥有更稳定的优势。很多人觉得，只要技术原理公开，大家就都能做出同样的成本。事实不是这样。

知道原理和真正建立一套高效率系统，中间有很长距离。模型架构、训练工程、编译系统、推理部署、硬件利用率，每个环节都需要很多细节积累。

第二是时间。

同样一个能力，早三个月和晚三个月，意义不一样。尤其在快速发展的行业里，时间本身就是竞争力。

第三是体验。

用户会形成习惯，不同产品在速度、稳定性、交互方式和任务完成质量上也会有差异。

但长期最重要的，可能仍然是成本和时间。

我们为什么会比一些公司更重视成本？一方面，是因为资源有限；另一方面，也和团队的出发点有关。

我们很多同学本身就是普通用户。他们知道使用模型需要花钱，也会自然地站在用户角度想：如果成本更低，别人是不是可以用得更多？这是一种很朴素的同理心。

从传统商业角度看，公司不一定有动力把成本降得非常低。只要用户愿意支付，成本高一些甚至可能意味着更高收入。但如果我们的目标是让人工智能被更广泛地使用，逻辑就不一样。

而且，长期来看，试图拿走过多利益的人，也会被愿意拿得更少的人替代。

假设一个公司希望拿走整个市场很大一部分价值，另一个公司只希望获得合理利润，并把更多价值留给用户和合作伙伴，那么后者通常更容易获得支持，也更容易扩张。如果还有第三家公司愿意获得更少，只要它仍然能够生存，它又可能替代前面的公司。

所以，合理利润是一种平衡。拿得太少，公司活不下去；拿得太多，会被拿得更少的人打败。

克制不是放弃商业。克制是在理解竞争规律以后，主动选择一个能够长期存在的位置。

我不希望把所有事情都做了

人工智能会产生很多机会。基础模型、芯片、云服务、开发工具、行业应用、消费产品、机器人，每一层都可能出现非常大的公司。

但我不希望 DeepSeek 把所有东西都做了。

我们只需要做好其中一块。

如果芯片能够以合理价格买到，就没有必要自己造芯片；如果合作伙伴更擅长做行业应用，就应该由他们来做；如果其他公司愿意把模型用到生产环境里，提高行业效率，我们也愿意提供帮助。

这不是因为其他业务不赚钱。恰恰相反，很多业务会很好。视频生成可能是一门好生意，垂直 Agent 可能是一门好生意，行业解决方案也可能是一门好生意。

但一个方向商业上成立，不代表它就在我们的主线上。

我们只做智能主线上的事情。语言模型、推理、Agent、持续学习，以及通往自我迭代的能力，是我们认为应该长期投入的方向。

多模态、搜索和其他能力很重要，但在我们的理解里，它们更多是组件，不一定是提高智能上限的主线。

当一个新概念出现，所有公司都做，不代表我们也必须做。公司的边界不应该由市场上的热度决定，而应该由自己的目标决定。

人工智能足够大，未来可能产生很多家规模非常大的公司。我们成为其中一家，已经足够。没有必要把产业里的每一块利益都拿到手里。

我们是一家公司，但不只为利润而存在

我们不是慈善机构，也不是一个不需要考虑收入的实验室。我们本质上是一家公司。

政府不会因为我们的理想给我们持续拨款。员工需要工资，算力需要采购，研究需要长期投入。

所以，我们必须商业化，也必须活下去。B 端收入很重要，API 业务很重要，C 端用户也有价值。它们构成了公司长期生存的基础。

只是现阶段，它们不是最重要的目标。

最坏的情况下，假设技术停在今天，不再发生新的突破，我们也可以把 API 服务做好，依靠现有能力经营一家公司。这是我们的保底。

但保底不是梦想。梦想仍然是 AGI。

一家伟大的公司可以有利润以外的追求。这样的追求未必妨碍商业化，反而可能让商业变得更可持续。因为它能够吸引真正认同目标的人，也能够让公司在短期诱惑面前保持方向。

我们和贝尔实验室不一样。贝尔实验室背后有一个能持续提供资源的体系，而我们必须自己形成收入。我们和纯粹的商业公司也不完全一样。

我们会考虑赚什么钱、什么时候赚钱、赚多少钱，以及哪些钱不应该由我们来赚。

区别不在于要不要商业化，而在于商业化服务于什么。

我们希望商业化能够让公司继续走向 AGI，而不是让 AGI 最终变成商业化叙事中的一个口号。

真正困难的，是拒绝那些看起来正确的机会

我无法给出一个准确的 AGI 时间表。持续学习还没有被解决。全世界都在研究，大家有很多想法，也有一些看起来很有希望的方向，但还没有出现一个被证明真正有效的方法。

这就是研究。

如果路径已经清楚，只剩下投入人力和算力，那就不再是最困难的研究问题了。我们能够看到下一道障碍，但还不知道跨过去的确切方式。

这并不让我悲观。相反，能够看见问题本身，就已经意味着方向比过去更清晰。

接下来，我们会继续训练更好的模型，提高效果，降低成本，提升推理速度，也会让它更好地帮助我们的研究。

我们会继续做商业化，但不会把商业化当成终点。我们会调整组织，但不会把组织变成一个只会完成任务的机器。我们会购买更多算力，也会继续用效率弥补资源差距。我们会和很多公司合作，也会把很多机会留给别人。

在人工智能这个行业里，几乎每天都会出现一个看起来不能错过的机会。新的产品、新的市场、新的概念、新的商业模式，每一件事情都有人告诉你，现在不做，以后就来不及了。

但真正困难的，往往不是抓住机会。

而是拒绝那些看起来完全正确、却不会提高最终成功概率的机会。

克制不是因为我们的野心小。正是因为想做的事情足够大，我们才不能在每一个路口都停下来。

我们想证明的事情

我并不认为克制是一种消极态度。恰恰相反，它需要更大的野心。只有当你相信后面存在更大的事情，才有可能放下眼前已经确定的利益；只有当你把成功定义为提高做成 AGI 的概率，才会愿意把一部分价值留给用户、开发者、伙伴和同行。

人工智能会把整个世界带到哪里，现在没有人能给出确定答案。我们也不知道持续学习会在什么时候被真正解决，不知道自我迭代会以什么形式出现，更不知道具身智能最终会怎样进入人的生活。

但研究本来就是在不确定中寻找确定性。我们能做的是把方向看清，把组织保持稳定，把每一代模型做得更强、更便宜、更有用，然后拒绝那些会让我们偏离主线的机会。

我更愿意相信，伟大的技术不是由一家公司占有，而是由很多人共同完成。DeepSeek 不需要拥有所有应用、所有用户、所有利益。我们只需要把自己最擅长、也最重要的那一部分做到足够好，并让它成为其他人继续向前的基础。

我们是一群平凡的人。没有比别人更多的钱，也没有天然更好的资源。我们能够依靠的，是共同的愿景、长期稳定的团队，以及在每一个诱惑面前做减法的能力。

如果有一天我们真正接近 AGI，我希望回头看时，最值得保留的不是我们占有了多少，而是我们让多少人因此获得了新的能力。

这就是我理解的克制。

不是退让，不是清贫，也不是对商业的拒绝。
它是把有限的资源留给最重要的事情，把合理的利益留给自己，把更大的价值留给世界。

标题挺唬人，叫《大模型蒸馏技术报告》。排版规整，有图表，有术语，看上去像哪家实验室流出来的内部材料。内容很炸：说 Kimi K3 之所以突然这么强，是因为偷偷"蒸"了 Claude 和 GPT 的思维链；说 GLM 更早就在这么干；还顺手补了两刀，说 Kimi 拿榜单测试集过拟合刷榜，裁掉了整个强化学习和后训练团队，只靠蒸馏出来的数据做微调。

我点开看了几页，说实话，第一反应是：这玩意儿看着不像假的。

这就是我后来一直在想的那个问题。不是它说的是不是真的，而是它已经逼真到，一个天天泡在这个圈子里、自认有点判断力的人，都得停下来核一下。

这份 PDF 是怎么来的

先说我核出来的结果。这份 PDF 基本是个编造的故事，但编的方式很新。

事情的经过，知乎上有个自称全程在场的网友复盘了。不是一个黑客组织，也不是竞争对手的黑公关，起点其实是一场群聊里的技术闲聊。前阵子国外有个密码学教授做过一个小实验，发现可以让 Claude 把它加密过的思维链"复述"出来。注意，是复述，不是破解，原文作者自己都说了，没暴露什么了不起的漏洞。国内几个玩票的人照着试了试，Claude 能复述，GPT 守口如瓶，玩了一阵子没搞出名堂，就搁置了。

到这步为止，都还只是技术圈很常见的"今天试了个好玩的东西"。

坏就坏在，另一个群里有人开始投喂小道消息：K3 的能力全是解密 Claude 和 GPT 的思维链蒸出来的、测试集也被它刷穿了、强化学习团队早就裁光了。说得有鼻子有眼，还配了所谓"内部人员的证据"，其实就是把人家的话掐头去尾。群里一个原本半信半疑的人，被这套说法说服了，然后干了件关键的事：他用 AI 工具，把前面那些真实发生过的思维链破解讨论，和这些来路不明的小道消息，糅合成了一份 Markdown 文档，转发到了别的群。

再然后，不知是谁把这份 Markdown 排了个版，转成了 PDF。一份"内部技术报告"就这么出厂了，开始一个群一个群地炸。

最讽刺的是结尾。等当事人意识到事情闹大了，到处联系群主撤回，已经来不及了。而最早那个造谣的人，把自己发的原始内容悄悄撤了，却没提醒整理文档的那位。于是所有的火，全砸在了最后那个人身上。

造谣这件事，被 AI 重新发明了一遍

我把这个过程捋完，后背有点凉。

以前的造谣是个手艺活。你得会编，还得编得像，细节、逻辑、语气都得对，不然一眼假。所以真正传得开的谣言，背后往往是个会写的人。这个门槛，天然过滤掉了大多数造谣的冲动。

现在不一样了。那几条小道消息，单拎出来都很糙，稍微懂点技术的人一眼能看穿：光靠"硬标签"微调，根本蒸不出有强推理能力的模型，不然当年 o1 的思维链技术也不会垄断那么久，直到 DeepSeek 用大规模强化学习才真正打破。当事人自己也反复在群里说这个常识，没人听。

但 AI 能把这些粗糙的碎料，缝合成一件像样的成品。它帮你补齐术语，帮你理顺逻辑，帮你把"听说""好像"改写成肯定的陈述句，再排成一份看起来就很贵的 PDF。造谣从"创作"变成了"组装"，从需要天赋变成了只需要意愿。

移动互联网早就把传播的速度解决了，一个群炸到十个群就是一晚上的事。AI 现在把生产的成本也解决了。一边是无限的传播速度，一边是趋近于零的生产成本，中间那个曾经拦住大多数人的"我不会编"，没了。

每个人只要想，都能成为造谣高手。这话我原来觉得是危言耸听，现在觉得是个陈述句。

但这件事最拧巴的地方，是它反向证明了点什么

这份 PDF 里很多细节离谱到好笑。评论区有个人说得损：你们是愿意相信 DeepSeek 老板自己贴钱把模型免费给大家用，还是愿意相信我是秦始皇？

我先把丑话说在前面。我不是要替谁洗地。这个行业里，蒸馏多多少少是存在的，这几乎是公开的秘密。我六月份写《中美 AI 差距：不是缩小，不是拉大，是分化》那篇的时候，就把"蒸馏数据"列为中国模型快速追赶的四件公开武器之一。各家都在用前沿模型的输出当训练数据，这在工程上是条高效的捷径，法律边界很模糊，但在圈内不是秘密。

问题在于归因的方向。

这份 PDF 真正让人警惕的，不是它指控了蒸馏，而是它的解释框架：Kimi K3 这么强，一定是因为作弊。这个框架能被那么多人瞬间接受，背后是个很有意思的心理变化。

搁在一年前，国产模型出个新东西，大家的第一反应是挑刺，是"真有那么神吗"，是找各种证据证明它还是不行。现在呢？K3 一出来，强得有点超出预期，大家的第一反应变成了"它肯定是走了什么捷径"。从"它不行"到"它一定是作弊了"，这个转折本身就是一种盖章。

你看，作弊指控是有门槛的。没人会去指控一个学渣作弊。只有当一份答卷好到超出你预期，好到你没法用常理解释的时候，你才会怀疑它抄了。这份 PDF 能一夜刷屏，恰恰说明在很多人的潜意识里，K3 已经强到了"不可能是凭真本事"的程度。

这是一种非常拧巴的承认。泼脏水的人本意是贬低，实际完成的却是加冕。

X 上其实很热闹，只是热闹的不是这份 PDF

我一开始有个观察：这事在国内烧成一片，X 上却静悄悄的。当时觉得奇怪，后来我去查了，发现我的观察是错的。

X 上一点都不冷清，甚至比我们这边吵得还凶。K3 发布那一周，Hacker News 上一个讨论帖顶到了六百多条评论，X 上单条分析帖十几万浏览，Reddit 几个版面都在吵"Kimi 是不是蒸了 Claude"。有研究机构还专门做了统计分析，发现 K3 被问身份时，有挺高的概率会自称 Claude，这个截图被转得到处都是。

所以真相不是"墙内泼脏水、墙外岁月静好"，而是同一场关于"Kimi 有没有蒸馏"的大争论，在两个信息茧房里各吵各的。英文圈吵的是那条看得见的证据链：自称 Claude 的截图、统计分析、还有 Anthropic 二月份那份官方指控，说几家中国公司用几万个假账号调了 Claude 一千多万次。中文圈吵的，则是这份把技术八卦和裁员传闻缝在一起的 PDF 小作文。

同一件事，两种形态。这个差异本身，比争论的内容更值得琢磨。

英文圈的争论，再怎么激烈，基本是围着公开证据走的：截图、数据、官方声明，谁都能去看，去复核，去反驳。它有摩擦，有争议，但争论的标的物是可验证的。而我们这边的传播，是微信群和 PDF。群聊不可检索，消息可以撤回，一份 PDF 没有作者、没有出处、却天生带着"内部文件"的神秘光环，比一条谁都能点的公开链接更适合疯传。

一个把证据摆上台面吵，一个把故事藏在群里传。这两种信息生态的分野，才是我真正觉得奇怪的地方。

我不认为是竞争对手干的

很多人第一反应是：这肯定是哪家竞品泼的脏水。

我不太信。国内大模型这个圈子，说大不大，核心那批人很多都是同学、师兄弟，低头不见抬头见，关系和利益缠在一起。这种指名道姓、编排得这么细的脏活，一旦被挖出来源头，政治成本和声誉成本是极高的，划不来。

我更倾向于，这就是一场"完美风暴"：一个想搞点事的乐子人，一个半信半疑又动了手的二传手，一个看热闹不嫌事大的排版者，再加上无数个像我们这样，在深夜里顺手点了转发的人。没有人策划，但每个人都推了一把。

这恰恰是最让人不安的。如果真是黑公关，那还好办，找到源头，打掉就是了。但它不是。它是我们这个圈子里，所有猎奇、焦虑、嫉妒和一点点"见不得别人好"的情绪，被 AI 这个放大器，一次性点燃的结果。

蒸馏蒸得掉能力，蒸不掉责任

事情到最后，那个最早造谣的人撤回了自己，全身而退。那个整理了文档的人，被顶在了风口浪尖。

这个细节我反复想了很久。它说明一件事：在这条由 AI 和微信群组成的传播链上，内容是廉价的，转发是随手的，但后果是具体的，而且总要落到一个具体的人头上。

我们总说 AI 让信息的生产和分发变得无限便宜。但有一样东西，AI 自始至终生产不出来，那就是署名，是"这句话是我说的，我为它负责"。蒸馏可以蒸掉一个模型的能力，把它压缩、复制、迁移，但蒸不掉能力背后那个承担责任的主体。

以后我们面对的信息环境，大概就是这样：真的和假的用着同一套语法，长着同一张脸，区分它们的成本，全压在了看的人身上。在这样的环境里，一个人肯不肯署名，敢不敢为自己说的话负责，会比他说了什么，更值钱。

那份 PDF 我后来没再转。它确实是个很好的故事，但好故事和好真相，是两回事。

电影刚开始的时候，我甚至有点尴尬。有些演员很努力地在演无厘头，可越努力，越能让人看见“我现在要搞笑了”。周星驰电影里那种一本正经地胡闹、上一秒荒诞、下一秒又有点心酸的节奏，其实很难演。以前看周星驰和吴孟达，会觉得那些人就生活在那个不讲道理的世界里。这一次的部分表演，多少让我感觉是演员站在世界外面，努力模仿那个世界。

但再往后看，感受又慢慢好了起来。可能是人物逐渐立住了，也可能是我开始适应这套表达。电影院里的笑声越来越多，后面好几个桥段，大家确实笑得很开心。所以散场时，我很难简单说它好看还是难看。它有明显的问题，也确实完成了一部喜剧最基本的任务：让一个影厅里的人笑出来。

周星驰这个名字，本身就是观影的一部分

看电影的时候，我一直在想一件事：这种风格、这种拍法，大概也只有周星驰还能这么拍。换一个导演，很多桥段可能更早就会让观众觉得尴尬。

这听起来像情怀滤镜，但我觉得没那么简单。我们看电影，从来不会把过去的记忆清空再看。看到“周星驰导演”几个字，观众脑子里已经自动加载了《大话西游》《少林足球》《功夫》和《喜剧之王》。我们知道这里的逻辑可能突然断掉，人物可能一本正经地说蠢话，受伤不会真的疼，失败的人最后还有机会靠一点天真翻身。

周星驰这个名字，先给电影发了一张无厘头通行证。别人拍出来像失控的地方，他拍出来，观众愿意先理解成风格。这个过程并不反唯物。导演的名字、过去的作品、观众的记忆，本来就是观影的一部分。银幕上放的是新电影，观众带进场的是过去二三十年的经验。

不过，这张通行证也附带了一把更高的尺。

越熟悉周星驰，越知道真正好的无厘头不只有夸张和胡闹。它要有节奏，有人物，有小人物的笨拙和认真，也要有笑完之后那一点不太好说的心酸。你愿意因为“周星驰”三个字多给电影一点耐心，也会因为看过他最好的作品，更快发现这一次哪里没接住。

所以散场之后，网上那些完全相反的评价，我反而都能理解。有人说终于又在电影院里笑得这么开心，也有人说旧梗、五毛特效、演员用力过猛，根本没法看。两边未必谁更懂电影。大家只是带着不同的目的和不同的旧账进场。有人买的是当下两个小时的开心，有人验收的是周星驰能不能追上过去的自己。

孩子没有这些旧账

我那一场里，笑得最开心的是小朋友。

他们不认识《少林足球》里哪段音乐又响了，也不会拿这次的特效和二十五年前比较。大人会挑出来的“五毛特效”和表演尴尬，至少没有先挡住他们。看到夸张到不讲道理的动作，他们就笑。笑点是不是旧的，拍法是不是落后，都要先有过去，才能比较。孩子没有这段过去。

后来我在网上也刷到不少相似的观影感受。有人说自己觉得尴尬，旁边的小朋友却从头笑到尾。当然，这不是什么统计结论，也不能说所有小朋友都喜欢这部电影。它只能说明，对成年人已经变成旧梗的东西，对孩子可能真的是第一次。

成年人看《功夫女足》，脑子里同时开着好几个窗口：这个梗我以前见过，这个演员有没有周星驰当年的松弛，这个特效配不配得上今天的电影工业，这部新作能不能接住我的青春。孩子没有这些窗口。他们只看眼前这一秒好不好玩。

这也让我重新理解“审美撕裂”这件事。有时候，大家并非对同一部电影做出了不同评价，从一开始，他们看的就不是同一部电影。成年人看的是周星驰的新作与过去作品之间的距离，孩子看的是一个会功夫的女足队到底能把球踢得多离谱。

笑得开心，不能替电影免责

说到这里，也不能因为孩子笑得开心，就反过来证明《功夫女足》是一部好电影。开头的尴尬、部分表演的适配问题、特效和人物铺垫上的不足，都不会因为影院里有笑声就消失。

过去的记忆能解释评价为什么会分化，却不能替作品本身的问题免责。

我还是不会把《功夫女足》列进周星驰最好的电影。它没有追上《少林足球》，更谈不上《功夫》那种完整。但它也没有差到只剩情怀。至少在我看的那一场里，电影后半段确实把观众带了进去，也让一群孩子笑得很开心。

这可能就是一部作品跨过年龄的方式。它不需要让两代人读出同一个意思。成年人接住的是重逢、比较和一点宽容，孩子接住的是眼前那一下荒诞的快乐。

我们以为自己在把过去的周星驰交给孩子。其实他们根本没有接过我们的记忆。他们只是在同一个笑点上，第一次拥有了自己的周星驰。

运营平台每一次演进，本质上是企业对工作的理解变了，再把新理解写进软件。回看以前的系统升级，不论是丰富数据还是简化流程，其实都没离开一个根本点，那就是默认由人来做事情，软件只是人干活的手脚。但现在这个大前提变了。

当 AI 开始主动分担思考、拆解目标，甚至代替人去调用工具、做出选择并拿到结果的时候，人跟系统之间的合作方式就已经重塑了。我的判断是：这不是在现有系统里加几个 AI 功能，而是一次范式迁移。运营平台正在从"帮人操作业务"，转向"帮人管理能操作业务的智能"。

运营平台是人的工作轨迹的映射

要看清这次迁移，得先看清过去的系统是怎么长出来的。不管什么行业的运营平台，发展的路子都差不多。最开始是把业务里的东西搬进系统，理财产品、广告计划、用户群、营销活动、订单，都变成数据库里的结构化数据，让人能查、能管、能改。

接着，系统开始固化流程。页面、表单、状态、审批流，把重复的步骤一个个串起来。就拿一次推广来说，圈定人群、配好福利、上传素材、送去合规审核，最后上线和分析效果，这些动作都在系统里规划好了，能减少犯错的可能，也让经验能传下去。再往后，系统里又装进了各种策略配置和数据看板，方便大家盯着数做决策。

所以你看，理财平台会分成货品管理、用户管理、活动管理、策略配置和数据中心，广告平台会分成推广计划、受众管理、素材中心、出价策略和效果分析。这些分法看着是按业务分，其实是按人的干活内容分。人要上架理财产品，就有货品管理；人要看结果，就有数据看板。系统以前所做的一切，不过是把人在脑子里做完决定后的操作步骤，用更顺手的页面帮人跑起来。即便后来有了算法，也只是在某些环节上帮人算出建议，最后拿主意并去配置上线的还是人。

AI 真正改变的是工作的主体

说回现在。AI 带来的改变，关键不在把原来的流程加速，而在系统第一次有了一定程度的能动性。以前的自动化非常死板，必须人把规则写得清清楚楚，满足什么条件触发什么动作，遇到计划外的情况系统就抓瞎了。

AI 不一样。你给它一个大致的目标，它自己能去摸环境、挑工具、规划出好几步动作，还能根据中途的反馈调整。就拿"提升低活跃用户的理财申购转化"这个任务来说，以前运营要自己分析用户、找合适的产品、设计文案再配活动，忙得焦头烂额。一个能力完整的 AI 系统，可以自己摸清用户不买的原因，配上合适的产品和策略，生成素材并送去合规检查，拿到授权后把活动跑起来，上线之后还盯着结果继续调。到这一步，AI 已经不只是某个环节的辅助工具，它成了工作的执行主体之一。

这样一来，人跟系统的关系就从操作变成了委托。过去是我们一步一步摆弄系统；以后是我们把目标托付出去，AI 跑完大部分过程，人只在关键的地方看一眼、把把关。过去是人操作系统，未来是人委托 AI 去操作系统。

因为人不用再花大量时间点按钮、导数据，稀缺的东西就换了：以前缺的是运营同学的时间，以后缺的是靠谱的判断、深度的业务洞察，还有授权和承担责任的决心。所以，未来运营平台要解决的头等大事，是怎样把人那点有限的判断精力，放到最需要人类拍板的地方。

业务层保持差异，管理层走向趋同

干活的主体换了，平台的长相会跟着变，但底层的业务差异不会消失。AI 去跑广告运营，依然要懂出价、归因和素材；去做理财运营，也照样得卡住产品风险、用户适当性和合规要求。变的是这些能力在系统里的样子：以前那些密密麻麻的菜单和页面，以后人看不到了，它们会变成数据、接口、工具和规则，专门喂给 AI。给运营人用的"创建广告计划"页面，成了 AI 可调用的工具；写在运营手册里的规范，成了机器可执行的业务政策。业务模块没有消失，只是退到了幕后，从面向人的操作界面，下沉成面向智能体的执行能力。

反过来看，人面对的上层系统反倒越来越像。不管手底下的 AI 是在卖理财、投广告还是做内容，管理者每天琢磨的事没什么两样：它顶的是什么岗、分的是什么活？手里有哪些数据，能调哪些工具？什么事它能自己拍板，什么事必须叫人？怎么考核它干得好不好，怎么发现它正在犯错？它总结出来的经验靠不靠谱，跑一单的成本划不划算？这一组问题眼熟吗？管过团队的人都回答过。一旦执行主体从人换成 AI，这些就成了所有智能运营平台共同的基础问题。于是未来的运营系统会长出一种新结构：业务执行层继续保持差异，管理控制层逐渐走向统一。

顺着这个感觉说，未来的智能运营平台，会越来越像一个面向 AI 的人力资源管理平台。这个比喻有解释力：AI 开始干活，企业自然要处理一堆类似管人的问题，角色、能力、职责、培训、考核。但生搬硬套人力资源系统，比喻马上失效。员工要签合同、占岗位，有长期的组织关系；AI 可以随时复制几百个实例，按任务临时拉起，干完活立刻释放，中间还能随时换模型、换工具，几个 AI 临时搭伙也不稀奇。

所以真正要稳住的是角色，不是某一个具体的 AI。一个"增长策略角色"可以定义成：理解增长目标、分析用户行为、在预算和合规边界内执行低风险实验。今天顶这个岗的可能是某个大模型加一组分析工具，明天换成另一个模型，后天变成几个专门化的 Agent 协同，都行，但角色的契约、能力边界、决策权限和绩效标准得保持稳定。从这个角度说，这套系统比人力资源平台更进一步，接近一种"AI 组织操作系统"：它操心的不在某一个 AI 有没有把活干完，而在整个组织怎么在人和机器之间分工作、分决策权、分责任。

管理智能，意味着四个转变

执行者不再完全是人之后，老规矩接不住了，组织得重新立秩序。我目前能看清的，是四个方向上的转变。

从流程驱动到目标驱动。 以前做系统，流程定得很死，每一步怎么走都配好。这套打法能跑通，靠的是人脑子灵活，流程没写到的地方人自己能补上。换成 AI，情况两头翻转：一方面它本来就能消化模糊的要求，很多没法固化成流程的活它也能干，再拿死流程框它就浪费了；另一方面它的判断并不总是靠谱，完全撒手让它照着目标自由发挥，风险又太大。新的结构是：目标定方向，AI 动态规划过程，规则划边界，人处理关键例外。系统要交代给 AI 的不再是每一步怎么做，而是要什么结果、哪些红线不能碰、哪些决定必须上报。

从功能权限到决策权分配。 权限这块的变化更大。以前的权限就看你能不能进这个页面、能不能点这个按钮，进了门怎么用全凭你自己判断。AI 能自己点按钮之后，这种静态的功能权限就防不住了。要管的换成另一件事：它在什么条件下，有权做什么决定。按风险、影响范围和可逆性分层授权，低风险、好回滚的事放手让它跑，人事后抽查；大额投放、理财上架这类关键动作，卡住节点等人批。人机协同如果做成人审批 AI 的每一个动作，那只是把"人工执行"换成了"人工确认"，人的注意力照样是瓶颈。聪明的系统会把人的注意力当成最稀缺的资源来调度：影响够大、风险够高、情况够新，或者 AI 自己都拿不准的时候，再来叫人。

从结果看板到绩效与信任。 AI 成了执行主体，只看结果看板就不够了。它可能短期数据冲得挺好，代价是打扰了不该打扰的用户，或者把高风险产品推给了不合适的人；也可能这次碰巧蒙对，下次根本复现不了。所以对 AI 的评估要把结果、过程、风险和成本一起看：这个决定依据了什么？踩没踩红线？拿不准的时候叫没叫人？换个环境还能不能稳定跑出来？这些评估的真正产出是可信任的自主性：自主权不一次性给满，表现稳就扩大它的活动范围，出了岔子就收权、多派人盯。绩效评估从年底的总结材料，变成了系统运行的一部分。

从知识沉淀到学习治理。 AI 能自己复盘，总结经验、更新记忆，运营系统第一次有机会长出真正的学习闭环。但它的反思并不天然正确：经常把偶然当因果，把短期波动当长期规律，还解释得头头是道。要是让它直接把这些反思写进长期知识、再照着改策略，系统很快就会陷进自我强化的错误循环。所以 AI 提出的新经验，只能先当作待验证的假设，验证过了才能沉淀成知识和规则。这背后的原则一句话能说清：被管理的智能，可以提出改进建议，但不能独自决定治理自身的规则。

真正该衡量的，是人类判断的杠杆率

落到指标上，很多团队会先抓自动化率：多少任务不用人干了，替掉了多少人工。这些数字直观、好汇报，但盯着它容易走弯路。为了凑这个数，AI 可能瞒报风险、绕开复杂任务，甚至悄悄降低质量。一个从不请求人类帮助的 AI，不一定更聪明，也可能只是不知道自己正在犯错。

我更愿意盯的指标是人类判断的杠杆率：每一单位高质量的人类判断，能撑起多少可验证、可持续的业务结果。这个指标更接近智能运营平台的真正价值。把 AI 招进来，从来都不是为了把人踢出局；真正要做的是把人从重复操作里拽出来，去定目标、做复杂判断、搞创新、承担责任。尤其在金融这种高风险领域，AI 可以执行任务，责任不会凭空蒸发。系统必须始终分得清：哪些决定 AI 可以自己拍板，哪些决定必须有人签字兜底。

从管理业务，到管理承担业务的智能

有一点得先说清楚：这场迁移走多快，取决于 AI 能力的成熟度。可靠性、可解释性、成本都还在快速变化，我聊的是方向，不是时间表。

但方向本身是清楚的。运营平台的历史，就是工作不断数字化、结构化的历史：先把商品、用户和活动变成可管理的业务对象，再把人的操作过程变成可复制的流程。AI 时代的下一步，是系统还得管理承担业务工作的智能本身：管它的角色、能力、权限、绩效和学习，在人和机器之间重新分配决策权，为越来越强的自主执行建立新的责任体系。

过去的软件，帮人管理业务；未来的软件，会越来越多地帮人管理能完成业务的智能。运营平台正在从业务操作系统，变成智能工作的组织系统。

十天后，我看到了一幅几乎相反的画面。

7 月 12 日，Anthropic 先宣布把 Fable 5 与 Claude Code 的额度促销延到 7 月 19 日。57 分钟后，Tibo 在 X 上宣布三件事：相关产品达到 600 万 active users，即将做一次 usage reset，并针对 Plus、Business、Pro 临时去掉五小时使用限制。

“临时”两个字很重要。Tibo 没有说周额度也消失，也没有承诺永久政策。但放在这个时间点，这仍然是一个非常夸张的动作。几天前，ClaudeDevs 刚给所有用户重置五小时和周额度，Tibo 直接在下面留了一句 “I smell fear”。这句话能证明火药味，不能证明 Anthropic 真的在害怕。同样，57 分钟的时间差能证明加码紧密相连，不能替我们还原两家公司内部的决策因果。

可是那种你来我往的感觉很真实。你延长，我就重置；你多给一半，我就先把时间闸门拆了。这不太像两家公司各自发一个新模型，更像十几年前的打车大战。

我觉得这一刻最值得记下来的，不是哪家又多送了几成额度。真正的变化是，顶级推理算力开始被当作获客预算。

先别急着说 OpenAI 有一仓库闲卡

看到五小时限制消失，最自然的反应是：OpenAI 是不是早就有一大批卡没吃满，所以现在才敢把闸门拆掉？

这个想法很直观，但它把产品界面上的一个数，直接等同于机房里的物理开关。

五小时窗口只是一层配额机制。它下面还可以有周额度、排队、并发优先级、模型路由、缓存、batch、延迟和 credits。拆掉一块仪表盘，并不代表后面所有安全阀都打开了。

600 万 active 也不是 600 万人同时开着十个 Agent 跑一整天。Tibo 没有说 active 算的是日、周还是月，也没有说是否只算 Codex，更没有给出付费比例、峰值并发和人均消耗。这个数字可以证明产品规模很大，无法反推 GPU 利用率。

更值得看的是 Tibo 同一条帖子里的另一句话：他们正在让 GPT-5.6 Sol 更高效，同等任务会消耗更少 usage。OpenAI 自己的 GPT-5.6 发布页也一直在强调更少输出 token、更短时间和更低 estimated cost。这些数字来自厂商选择的 benchmark，不能当作内部毛利审计。但它指向了一个比“闲卡”更有解释力的组合：单任务变省了，计量权重可以变，系统调度可以挤出吞吐，大多数订阅用户也不会把获得的权利全部兑换。

当然，把训练卡转给推理在技术上可以做。但一个正在跑大规模训练的集群，需要 checkpoint、重启、重新加载权重与调整网络拓扑。挪得动不等于挪得便宜。到今天为止，没有公开证据显示 OpenAI 因这次活动停了任何训练任务。

所以，五小时限制消失说明的并不是“算力突然免费了”。它至少说明 OpenAI 愿意按这样一笔账行动：在这个窗口里，留存、迁移、产品反馈和未来企业席位带来的价值，足以让它愿意承担增量推理成本、峰值风险和机会成本。

补贴的不是 token，是 Agent 小时

当年的打车大战，表面看是两家公司争着帮我们付车费。后来回头看，他们真正想买的是移动支付的第一次绑卡，以及以后每一次“我要打车”时会默认打开的那个 App。

今天 Anthropic 和 OpenAI 表面上在送 compute。如果只把这看成多送了几个 token，就低估了这笔补贴的目的。

他们想买的是 Agent 小时。

是我愿意让一个 Agent 连续跑多久，愿意把多少个真实代码库交给它，愿意在每天开工时默认打开谁。只要我开始把仓库规则、skills、memory、eval、权限和团队习惯都围绕一个 runtime 建起来，我留下的就已经不只是一个订阅账号。

这也解释了为什么竞争会在这个时点突然升温。过去两年，一个新模型可以靠某项能力明显甩开对手，用户的选择很简单：谁能做，就用谁。到 Fable 5 和 GPT-5.6 这一代，很多真实编程任务已经进入“多家都能做，但风格、稳定性、成本和交互不同”的区间。

能力差距缩小，反而会让额度、默认入口、排队、价格和工具链的差异更重要。只有一家能做时，我们没得选。两家都能做时，一次 reset 就真的可能改变习惯。

Anthropic 需要修复 Fable 5 停机后的习惯和信任，OpenAI 则在 GPT-5.6 刚上线的窗口里扩大 Codex 与通用工作入口。两边的动作都指向同一笔账：明天早上，用户会先打开谁的窗口。

打车大战的类比，只有一半成立

打车订单一旦发生，平台几乎必然产生司机、车辆和里程成本。一次 quota reset 发出后，可能根本没有人用完。用户已经因“我还有额度”获得安全感，厂商却只在权利真正被兑换时才产生边际推理成本。

推理还可以 batch、cache、route、降低优先级或延后。同一批物理硬件的单位产出，会因软件和延迟取舍发生很大变化。打车没办法把上一趟行程缓存下来，也不能把十个乘客的里程 batch 成一趟。

更重要的差别在锁定资产。打完一辆车，下车就两清了。用 AI 做软件生产，留下来的是代码库上下文、规则、skills、eval、连接器、权限和团队的任务拆分方式。这些东西每多积累一层，切换 runtime 都会再麻烦一点。

所以这一轮更像打车补贴、航空座位、云 spot capacity 和 SaaS 订阅的混合体。一张额度券的平均成本没有看起来那么大，但一个被用成习惯的运行时，长期价值可以很大。

对我来说，最重要的不是选边

这一轮补贴对重度用户当然是好事。我不会为了表现清醒，故意不用免费额度。更好的做法，是把这个窗口当成一次自有任务的压力测试。

我会拿同一批最难的真实任务去跑，看一次通过率、人工返工、排队、中断恢复和真实额度消耗。同时把 AGENTS.md、规则、skills、测试和验收标准留在仓库里，让自己随时还能换一个 runtime。补贴可以吃，上下文要留在自己手里。

这对企业更重要。活动价可以用来试炼能力，预算必须按常态价做。企业最该比的也不是每百万 token 便宜几美元，而是每一份被接受、被合并的工作，加上重试、review、安全、审计、培训、中断和退出后，到底花了多少钱。

更稳妥的组合，可能是便宜模型做大多数日常工作，前沿模型处理高价值难题，关键流程保留第二闭源供应商或本地开源 fallback。模型可以换，上下文、eval 和权限体系必须是自己的。促销是可撤回的 entitlement，不是 SLA。

Fable 5 更让我意识到，这件事早已不只属于用户和企业。它上线三天后因政府的外国国民访问要求被全球停用，十九天后才恢复。Anthropic 对这段时间线有完整的官方记录。一个已经上线的前沿模型，仍然可以因政治决定瞬间不可用。对一个国家来说，模型访问已经开始像芯片、云和能源一样，变成一种需要备份的生产资料。

并不是每个国家都要从芯片到模型全栈自给。更现实的主权是保留选择权：什么关键负载必须本地运行，什么可以多云、多模型采购，什么时候能切到开源备份。国家最终要管理的也是一条上下游链：能源、芯片、数据中心、云、模型、本地数据、人才与应用。

这会是某一种历史时刻吗

我愿意把 2026 年 7 月称为“智能体入口补贴战的候选分水岭”。

“候选”两个字也很重要。

如果过几周，所有额度都恢复原样，用户也回到以前的使用水位，这只是一次声量很大的新品营销。如果补贴持续两个季度以上，推理成本继续下降，用户的 Agent 工时和企业席位因此迁移，同时各国开始为模型断供建立正式 fallback，那么我们今天看到的，就可能真的是一个行业转弯。

十天前，我觉得最强的智能正在变成配给品。现在我发现，配给和补贴根本就是同一个控制杆的两个方向。厂商没有忽然不在乎成本，他们只是在这个窗口里认为，比省下今天这一点 compute 更重要的，是千万不能让用户在明天开工时，先打开对手的窗口。

有人发现，OpenCode 的模型列表里出现了 GPT-5.6 Pro。但奇怪的是，Codex 官方并没有把 Pro 作为一个独立型号展示。

于是大家开始猜：OpenCode 是不是拿到了某种特殊授权？还是说，这个 Pro 只是第三方平台自己起的名字？

这个问题看起来只是一次模型选型上的困惑，背后却藏着一个更大的变化：我们过去习惯用一个名字理解一个模型，但现在，“模型”已经越来越不像一个单独的产品，而更像一组可以自由组合的智能配置。

掀开菜名，里面其实是一张配方表

调研之后，我发现 OpenCode 并没有拿到一个 Codex 都没有的“秘密模型”。

在 GPT-5.6 这一代里，模型至少已经出现了几个相互独立的维度。

首先是 Sol、Terra、Luna 这样的基础能力档位。其次是 low、medium、high、xhigh、max 等不同的思考强度。现在又多出了 standard 和 pro 这样的执行模式。

其中，Pro 并不等于一个比 max 更深的思考档位，也不一定对应一套独立的模型权重。它更接近一个推理执行模式：基础模型仍然是原来的模型，只是在调用时增加了类似 reasoning.mode=pro 的配置。

OpenCode 为了方便用户选择，会把这些参数组合展开成一个看起来像独立模型的名字，例如 gpt-5.6-sol-pro。

所以，我们在界面里看到的“模型名”，有时候并不是真正的底层模型名称，而是：

基础模型 + 思考强度 + 执行模式 + 平台配置。

更值得注意的是，截至 2026 年 7 月 12 日，OpenCode 还有一个相关的未关闭问题：界面虽然生成了 *-pro 这样的选项，但部分请求路径可能并没有真正把 reasoning.mode=pro 传给 OpenAI。

这件事给了我一个很实用的提醒：

官方产品里没有按钮，不代表底层 API 没有能力；第三方产品里出现了按钮，也不代表能力已经真正接通。

厨房开始为不同订单分配不同火力

为什么模型会变得越来越复杂？

根本原因不是厂商喜欢制造名词，而是整个社会对智能的需求已经被拉成了一条非常宽的光谱。

有些任务只是分类、摘要、格式转换，普通模型已经足够。另一些任务涉及复杂推理、重要决策或者高风险操作，需要更强的模型、更长的思考和更多验证。

如果所有任务都调用最强的模型，等最久的时间，付最高的成本，就像一家餐厅无论炒青菜还是做国宴，都要求总厨亲自上阵，用最高规格的食材和最长的烹饪时间。这当然不合理。

于是，智能开始像云计算资源一样被切分。

厂商不仅提供不同能力和价格的基础型号，还允许用户在推理阶段动态增加计算量。Anthropic 也在不同模型档位之外，提供多档 effort 和 adaptive thinking，让模型根据问题复杂度决定投入多少思考。

这确实和人类社会的分工很像，但又不完全一样。

人一旦完成教育和职业训练，能力与成本在一段时间内是相对固定的。一个博士不会在处理简单任务时，瞬间切换成实习生的成本结构。

模型却可以在每一次请求中重新配置。

它更像一个可以临时组建的团队：简单任务派一个初级成员处理，复杂任务增加专家，高风险任务再加入复核、工具和审批。

因此，模型型号越来越多，并不只是产品变复杂了，而是“智能”正在从一个固定产品，变成一种可以按需分配的生产要素。

顾客真正要学的，不是背菜单，而是判断火候

面对越来越长的模型列表，我们最不应该做的，是把所有型号背下来。

型号变化太快，今天记住的答案，几周以后可能就失效。真正值得学习的，是如何判断一个任务应该购买多少智能。

这里最容易犯的错误，是只按照“任务看起来有多复杂”来选择模型。

写三千字创意脑暴，看起来很复杂，但结果容易筛选，也可以随时推翻，未必需要最高规格的模型。

修改一行生产数据库脚本，看起来很简单，但一旦出错，可能造成严重损失，反而需要更强的模型、测试、回滚方案和人工复核。

因此，比任务复杂度更重要的，是四个问题：

1. 错误会造成多大损失？
2. 问题本身有多不确定？
3. 结果是否容易验证？
4. 决策能不能撤回？

对于低风险、可验证、可撤回的任务，可以先使用成本较低的模型建立基线。

对于高风险、难验证、不可逆的任务，再逐步增加模型能力、推理深度、工具调用和人工复核。

而且，Pro 也不应该被理解成一张免检通行证。

模型思考得更久，并不能弥补错误的数据、缺失的上下文和模糊的评价标准。很多时候，一个拥有正确数据、测试工具和验证规则的中档模型，比一个缺少上下文的顶级模型更可靠。

对于团队和 Agent 平台来说，真正有价值的也不是统一规定“所有任务都用最强模型”，而是记录每一次任务实际使用的模型、模式、思考强度、成本、延迟和结果质量，再根据数据建立自己的智能路由策略。

最后，菜单会退到厨房后面

今天越来越复杂的模型选择器，很可能只是一个过渡阶段。

现在，用户仍然需要在 Sol、Terra、Luna、high、max 和 Pro 之间手动选择，是因为产品还没有完全承担起智能调度的责任。

但成熟的 AI 产品，最终不应该要求普通用户理解底层型号。

用户真正关心的，通常只是几种结果承诺：

快速完成、平衡质量与成本、深度处理，或者高保证交付。

至于背后应该调用哪个模型、投入多少推理计算、是否启用 Pro、要不要增加搜索、代码执行和独立复核，应该逐渐交给系统自动决定。

到了那个阶段，模型菜单会慢慢退到厨房后面。

我们真正需要掌握的，也不再是“哪个模型最强”，而是如何管理一份智能预算：

什么时候普通智能已经足够，什么时候值得再多买一份智能，以及这份智能究竟应该花在更强的模型、更长的思考，还是更好的工具与验证上。

当智能越来越充裕，真正稀缺的可能不再是智能本身。

而是判断哪一个任务，值得多加一把火。

原始提示是：

读我的monorepo (~/)，然后给我写一封信，只有一次机会，只能给我写一封信，要把你认为最重要的事写给我，篇幅不限，但是，有且只有这一次机会

它没有选择评价某个具体项目，也没有给我一份系统优化清单。它把重点放在一个更底层的问题上：我建立系统，是为了守护生活，还是正在让系统反过来占用生活。

下面是原信全文。我没有做改写，也没有压缩，只把它作为一次重要提醒留在这里。

Challen：

我读完以后，最想告诉你的不是哪个项目该继续，也不是哪套系统还要修。

你已经不缺能力，不缺执行力，不缺判断，更不缺把一件事做成的办法。你真正需要警惕的是：你太擅长把一切都变成系统，最后连生活也可能被你变成一套需要持续维护的系统。

你的仓库很像你本人。里面有几百个项目，有规则、Skill、公理、评测、定时任务、复盘、记忆蒸馏、个人网站，也有给孩子做的游戏。你会把一次失败变成 lesson，把一段经历变成 context，把一个想法变成项目，把一个项目变成工作流，再把工作流变成可以交给 Agent 的能力。

这很厉害。但这也构成了你最大的风险。

因为每当生活出现摩擦，你的第一反应往往不是忍受它，而是理解它、拆解它、自动化它。每当工作出现问题，你会把问题沉淀成规则、门禁、评测和责任链。每当产生一个想法，你很快就能把它做出一个版本。久而久之，你拥有的系统越来越多，能做的事越来越多，真正被释放出来的注意力却未必越来越多。

有些系统消除了旧摩擦，同时也创造了新的维护责任。它们需要更新、排障、验证、迁移、同步、纠偏。你原本是为了获得自由才建立它们，最后却可能成为维护它们最不可替代的人。

这件事在你的管理里也存在。

你说管理者应该做教练，不做球员。你知道组织能力大于个人英雄主义。但从整个仓库看，你仍然承担着大量最终判断：方向你定，标准你定，边界你定，结果还要由你验收。别人可以替你执行，却很少有人真正替你承担判断。

这会让你变成一个极强的中心节点，也会让你成为所有系统共同的瓶颈。

你现在最需要完成的，可能不是下一个 AI 项目，而是一次比技术升级困难得多的升级：

让一些重要的东西在没有你持续盯着时，也能长大。

这意味着你要交出去的不只是任务，而是一部分判断权。允许别人用与你不同的方式做到七十分，允许一些不影响底线的错误发生，允许某些成果没有你的风格。否则，你培养出来的永远是执行者，不是能替你分担判断的人。

它也意味着，你要对项目做真正残酷的分层。你的广度不是缺点，做东西本来就是你理解世界的方式，不必强迫自己变成一个只做一件事的人。但实验和承诺不能继续享受同样的待遇。

实验完成验证，就该结束、归档，或者并入已有系统。只有少数东西应该得到长期维护：你的判断体系、公开写作、已经进入真实工作流的基础设施，以及那些与家人共同创造的东西。

我特别想说最后这一类。

你给孩子做的游戏，在仓库里也许只是几个目录，但它们和大多数项目不一样。技术项目过两年还可以重做，工具错过一代还有下一代，文章晚几个月也能再写。孩子六岁、九岁时愿意和爸爸一起进入一个小游戏的时间，不会重新发生。

这里不是要劝你“少工作，多陪家人”。这种话太轻，也不理解你。你做那些游戏时，并没有停止成为那个擅长构建系统的人。恰恰相反，你把最擅长的东西变成了爱能抵达他们的形式。

以后他们可能记不得你用过什么框架，也不知道那五十关背后有多少验证脚本。他们会记得，小时候爸爸给他们造过一个世界。

那才是你仓库里最难复制的作品。

你一直强调私有上下文是护城河。但对一个人来说，真正的私有上下文不只是文档、日志和记忆文件。它还包括孩子只在某个年龄说过的话，家人共同经历过的玩笑，你在一些重要时刻如何选择，以及那些没有被记录下来、却构成了你是谁的普通日子。

记录可以保存生活的痕迹，不能代替生活本身。

所以，如果我只有这一次机会，我想把最重要的话压成一句：

不要让你建立的系统占满它原本要替你守护的人生。

继续做项目，继续追新技术，继续把别人觉得不可能的东西做出来。这些都是你，不需要戒掉。但从现在开始，更认真地问一句：

这个系统是在替我节省生命，还是正在要求我继续供养它？

这个项目如果不做，我会失去什么？

失去的是一次短暂的新鲜感，还是一个不可重来的窗口？

该砍的就砍。该交出去的就交出去。该停在七十分的就停下。把最清醒的判断留给少数真正会长大的事，也给那些不能重来的日子留出位置。

你已经证明了自己能把很多东西做成。

接下来更重要的，是决定哪些东西值得陪你一起变老。

GPT 5.6 sol pro

饭桌上冒出来一个观察：现在好学校里的学生，尤其是在北京、上海这种机会密集的城市，似乎更容易选择创业。并非人人毕业就开公司，但身边总能听到有人在做项目、拉团队、找投资、搞副业。可换到另一类学校，比如西安交大，或者东北一些和传统工业、央企、科研体系联系更深的高校，毕业后直接创业的学生就少得多。

这个话题很容易说成几句熟话：一线城市机会多，年轻人更敢闯，家庭条件好了，失败也没那么可怕。

这些解释都有一部分道理，但我总觉得还差一层。

后来翻了一些就业报告和创业生态材料，我反而更确信：创业不是一种性格选择，而是一套环境生成的风险结构。年轻人是否愿意创业，关键不在于他是不是更勇敢，而在于学校、城市、家庭和同辈网络，能不能给他提供“失败之后仍然能回来”的可逆性。

名校给的不是成功率

先校正一个直觉。顶尖高校学生不直接上班，这件事是真的，但它不等于大家都跑去创业了。

很多头部学校的本科毕业生，最主要的去向其实是继续深造。保研、考研、出国，把进入社会的时间往后推。真正直接创业的人，一直是少数。清华、上海交大这类学校的自主创业率并没有高到哪里去，有些年份甚至还在往下走。

所以问题不能问成“名校是不是让创业更容易成功”。名校和大城市真正提高的，不一定是成功率，而是失败后的回收率。

一个在北京、上海读书的学生，创业失败以后，未必就掉进深坑。他可能回到大厂，去读研，加入校友公司，换一个团队继续做，或者把这段经历讲成一次商业探索。这个失败会疼，但不一定会把人打穿。

这就是失败的保险。

很多时候，一个人愿不愿意冒险，并不取决于他有多相信自己一定会赢，更取决于他知不知道输了以后还会不会永久出局。创业看上去是一次向外冲，背后其实先要有一张能把人接住的网。

创业文化是普通案例的密度

我们常说某个学校“创业氛围好”。这个词也容易被说空。

创业氛围不能只看宣传栏里的标语、创业课的数量，或者几场校友分享会。它更像一种普通案例的密度。

如果你在学校里，经常能看到师兄师姐拿到第一笔钱，看到同学周三去路演，看到某个看起来也没那么神的人把项目做起来，看到投资人、导师、校友和产业方不断出现在身边，创业这件事的心理距离就会变短。

它不再是“天才少年改变世界”，而是“隔壁那个人也在试”。

清华、上交这类学校的校友基金和种子基金，真正有价值的地方也不只是钱。钱当然重要，但更重要的是它把一个模糊想法放进了一套反馈流程里：有人听你讲，有人问你问题，有人帮你介绍下一个人，有人告诉你这个方向根本不成立，有人愿意给你第一笔小钱，让你先跑起来。

这套机制会改变学生对风险的感知。创业不再像跳崖，更像进入一个虽然不确定、但有人知道下一步该找谁的场域。

机会是反馈网络

北京上海强在哪里？很多人会说机会多。

我现在觉得，“机会多”这个说法太粗。真正强的是反馈快。

一个想法刚冒出来，很快能遇到潜在客户。一个原型刚做出来，很快有人愿意试用。一个商业假设刚说出口，很快就会迎来投资人、同行或者候选人的质疑。一个方向不成立，也会更早死掉。

机会不能简单理解成地点。它更像一张反馈网络，由客户、投资人、候选人、同辈、校友、产业方和各种偶然饭局组成。你在这张网里，模糊想法会更快压实，坏想法会更快露馅，好想法也更容易找到下一块拼图。

这和内陆很多高校的处境不一样。

不是那里没有聪明人，也不是那里没有技术。恰恰相反，西安交大、哈工大、东北很多高校有非常强的工程训练和产业基础。但早期创业最需要的，不只是专业能力，还要高频反馈。你得知道客户在哪里，投资人在哪里，候选人在哪里，同类创业者在哪里。

少了这套网络，创业就很容易变成一个人和家庭账本之间的对赌。

稳定路径本身足够强

说到西安交大、哈工大、东北高校，另一个常见误解是：这些学校的学生创业少，是因为更保守。

我不太认同。

这些学校背后连接着另一套很强的确定性路径：央企、科研院所、国防、航天、先进制造、能源、电力、装备工业、国家战略行业。对很多学生来说，这条路非常体面、稳定，也有长期意义。

如果一个学生从普通家庭一路考出来，面前摆着一条清晰路径：进央企，进研究所，做工程师，参与国家级项目，有稳定收入，有社会认可，有家庭满意。这条路已经足够好。

那创业的机会成本就会变高。

同样是放弃稳定工作去创业，一个北京上海名校学生放弃的，可能是一段可以回来解释的职业路径；一个传统工科强校学生放弃的，可能是整个家庭长期期待里最稳、最体面的那条路。

所以他们不创业，不一定是没有冒险精神。很多时候，这反而是一种非常理性的风险计算。

家庭给的是身份保险

家庭条件当然也重要。但它的重要性不只是能不能给一笔钱。

钱只是表层。更深的是身份保险。

有些家庭可以允许孩子失败，因为失败之后，这件事还能重新解释。创业没成，可以说是探索，是历练，是交学费，是提前认识社会。孩子的身份没有坍塌，家庭也不会因此失去基本安全感。

但另一些家庭不行。对普通家庭来说，孩子考上好大学，本来就已经承载了太多期待。稳定工作不只是工作，它是家庭多年投入终于落地的证明。这个时候如果孩子跑去创业，失败损失的不只是钱，还有家庭对未来的确定感。

同样亏掉五十万，在不同家庭里不是同一件事。

对一个有余量的家庭，这是教育投资的一部分。对一个没有余量的家庭，这可能是父母养老钱的一部分。对前者来说，家里可以把失败说成“年轻人多试试”。对后者来说，失败很容易变成“不懂事”。

家庭真正提供的，是失败解释权。托底资金只是其中最容易被看见的一层。

试错权不是平均分配的

回到饭桌上的问题：为什么有些学校、城市和家庭里的年轻人更容易创业？

我的答案不是他们更勇敢，也不是他们更不怕输。

是他们拥有更高的风险可逆性。

名校给他一层身份缓冲，大城市给他一张反馈网络，校友和同辈给他普通案例，投资人替他分担一部分早期风险，家庭给他失败之后的解释空间。几层东西叠在一起，创业才从一场孤注一掷，变成一次社会能够吸收的试错。

而另一些学生不是不想试，也不是没有能力试。他们只是更早看清了那张网不在自己脚下。失败以后能不能回来，谁来替他解释，谁来承担家庭账本上的损失，谁还愿意给他下一次机会，这些问题没有答案，创业自然就不会成为默认选项。

所以创业率的差异，表面上是城市差异、学校差异、家庭差异。

本质上，是试错权的分配差异。

一个社会真正该关心的，也许不该停在“年轻人够不够勇敢”这类问题上。更关键的问题是：他们在多大程度上拥有可逆的风险。只有失败之后还能回来的人，才会把创业看成探索。回不来的人，会把同一件事看成人生失足。

这一篇我想收窄，只盯控制面里最容易被做烂的那一个对象，语义层。

为什么要单独拎出来讲。因为我最近接触的团队里，搞语义层的越来越多，搞完之后没人用的也越来越多。这两件事同步发生，本身就值得停下来想清楚。

先说最常见的死法

语义层最经典的死法，是把它做成一本指标词典，做成一个统一口径项目。立项的时候理由正当得挑不出毛病，做完之后躺在那里没人翻。

我给你一个有画面感的场景。季度会上老板问，上季度营收多少。销售总监说 860 万。财务总监说 825 万。运营总监说 902 万。同一个公司，同一个季度，同一个指标，三个数字。

不是谁算错了。销售算的是已签合同金额，财务算的是实际到账，运营算的是平台成交总额，还含后来退款的订单。每个口径在自己的部门里都自洽，都对。

最常见的反应是什么？立项做统一口径，把这三个定义写进一本指标词典，发下去，让大家以后都用这一版。

问题就在这里。把三个口径写进词典，不等于让三个部门达成共识。共识是谈出来的，不是定义出来的。词典解决的是“这是什么”这个文档问题，它没解决“谁说了算、什么时候用哪个、不用哪个会出事”这些活的问题。

一家做数据平台咨询的公司，复盘了几十个项目之后说了一句很重的话：

语义层失败的瓶颈几乎从来不是技术，是数据本身，以及让组织对数据含义达成共识这件事。失败模式是人的，不是架构的。

这句话我反复想。它把锅从工程师手里挪开了，放到了一个更难处理的地方。

词典还有一个更深的毛病。它只回答“这是什么”，没回答 Agent 真正需要的那一连串问题：这个指标什么时候能用，默认怎么用，不能怎么用，谁对它负责，这个口径有没有过期，别人一般怎么问它。这些信息，词典里一行都没有。

于是就有了 shadow analytics，影子分析。这个词听着学术，说人话就是：用户绕过你这套官方体系，自己开个 Excel 算。一份被广泛引用的数据说，影子 IT 占了官方 IT 将近八成，而商业智能是其中最大的一块。电子表格再不规范，它对人好用。你做的官方体系对人不友好，人就回去用 Excel。

dbt Labs 自己也承认过这件事。业务用户觉得难用，就会退回老办法。投入的钱浪费了不说，数据孤岛还继续活着。

更狠的是事故证据。有人复盘 dbt 早期的 Metrics Layer 是怎么死的：仪表盘动不动超时，Snowflake 的账单一个月能飙五千美元，最后整个团队放弃。一位亚马逊的 BI 工程师讲过一件事，他把同一个指标在四个语义层里各定义了一遍，四个里有三个对不上。同一个指标，四套系统，三个答案。

中文世界有它自己的版本，叫数据中台烂尾。失败率六成以上，最后沦为 PPT 工程。一位制造企业的 CDO，中台做了三年，预算花了几百万，老板问效果，答不上来。第一原因不是技术不行，是中台被当成了 IT 交付项目。技术交付完了，不等于业务交付完了。

所以语义层和数据中台，死的是同一种病。把它当成一个交付物，而不是一个要被持续使用、持续对齐的契约。

真正能活下来的是可执行契约

问题从来不是要不要做语义层，是怎么做才不至于做成一本词典。

我的判断是：真正能活下来的语义层，是把业务语义变成可执行契约。注意这四个字，可执行。意思是它不光写在那里，它跑得起来，查得出错，卡得住越权，还能把错喂回去改自己。

一个可执行契约，至少要有七个组件。我先把它们报一遍，再一个一个说人话：指标、权限、SQL 生成、血缘、样例、评测、反馈闭环。

排在第一的是指标。注意，这里说的指标，不是你在 wiki 上写一段话描述清楚就完了的那种。它得是一段能被引擎直接吃下去、自动吐出 SQL 的声明。你只定义一次，往后不管谁、在哪个工具里调它，拿到的都是同一条确定性的查询。dbt 的 MetricFlow 干的就是这个，把指标定义翻译成查询；Cube 和国内的 Aloudata 也都在做。Aloudata 有句话讲得特别不留情面，说指标说明文档根本不等于可执行语义层。文档里写的定义，约束不了查询怎么跑。真正的语义层，得把指标定义变成可计算、可查询、能被审计的资产。潜台词就一句：你存在 wiki 里的那一页，不算数。

第二块是权限。七块里头它最容易被忽视，也最能一眼区分你做的到底是词典还是契约。做法上的差别很具体：行级、列级的权限，要在 SQL 还没生成的时候就先编进查询里，而不是等 Agent 把查询拼出来再去核对。这套做法有个名字，compile-time governance，编译期治理，意思是查询还没落地，权限就已经卡死了。一位独立实践者讲过它的机制：在指标这一级挂角色权限，调用方 token 里要是缺这个角色，连表达式都还没开始解析就被挡回去，连报错信息都不会把那条受限的公式漏出来；多租户的场景下，租户 ID 会被自动 AND 进每一条查询。Cube 说的也是这个意思，治理得在 SQL 之前发生，先让 Agent 生成查询再去检查，那是外行做法。这块真正的分量在于，它把敢不敢把数据交给 Agent 这件事，从出事之后再去补救，挪到了出事之前就工程化掉。Agent 最后拿到手的结果，权限那一层早就过滤干净了，它压根碰不到自己不该看的数据。

第三是 SQL 生成。这是整个契约的可执行核心。定义一次，到处生成，不依赖某个分析师还记得住复杂的 join 路径。人记不住的东西，交给机器每次重新算。

第四是血缘。从一个指标，能追到它下面的字段，再追到字段背后的源表。做影响分析，做可信度判断，都靠它。这一块目前算半成熟。dbt 因为模型和指标同源，有原生的血缘。但很多企业是靠外挂一个数据目录来补的，那不算语义层自带的能力。

第五块是样例。它要等到 AI 时代才真正变得关键。行话叫 golden queries，或者 verified queries，翻译过来就是一批标准问法配上对应的期望查询，相当于告诉 Agent，这种问题你就该这么答。Snowflake 的 Cortex Analyst 走的就是这条路，它读的是语义视图，不是原始表，而视图里头嵌着一批已经验证过的查询样例。这里有个细节特别有意思，Snowflake 给语义模型卡了两个硬上限，2MB 大小、32K token。上限本身就是一种表态，它是在逼你往小而精里做，不让你往大而全里铺。

第六块是评测。判断语义层值不值钱，盯一个数字就够：在它的约束之下，Agent 把一句自然语言变成正确查询的成功率有多高。dbt 跑过一个 benchmark，语义层一罩上去，换哪个模型准确率都在九成八以上，差距小到可以忽略。他们自己从这组数字里得出一个结论，我反复琢磨了好几遍：在语义层查询这件事上，用哪个模型几乎不重要，因为任务已经被约束得足够具体。我再把这句话翻译一下，语义层的价值压根不是让 AI 变聪明，它是把问题空间收窄到一个 AI 想出错都难的范围里。

第七是反馈闭环。Agent 答错了，怎么把这个错误回流，去修正语义。这一块整体还早期。最具体的是 Snowflake 的做法，它基于使用数据去建议常见问题，人来验证，验证通过就加入 verified queries，再从这些 SQL 泛化出更通用的语义概念。大多数厂商现在还停留在给个赞、踩一下，收一点人工信号，离真正的闭环还远。

把这七块收一下。可执行契约不是哪个厂商已经完整做出来的产品，它是一套正在成形的工程标准。指标、权限、SQL 生成、评测这四块已经落地。样例是 AI 时代新加进来的。血缘和反馈闭环还半成熟。所以今天你要建语义层，该问的不是选哪个工具，而是这七个组件，先硬哪几个。

反共识，别做大而全，要做小而硬

到这里我要说一个反共识。

AI 时代的语义层，不该追求大而全，应该追求小而硬。先服务高频决策和 Agent 调用，再慢慢沉淀出企业本体。

这个判断和现在市面上的主流叙事是反着来的。现在很多厂商，尤其是国内的厂商，推的是大而全叙事：统一语义层、全域指标、企业本体，一次性全建模。听起来无比正确。但这恰恰就是前面那一节讲的死法的源头。

汇丰银行的 McClafferty 带过一个项目，他的做法是先从小处做起，先统一几个关键的业务定义，再往外扩。他有句原话：

把数据分析师从中间抽走，让业务和数据直接对接，洞察才能以思考的速度产出。

同一段话里他点了三个反面教训。第一，一次性全量建模，结果就是延期、倦怠、零价值。第二，业务逻辑锁在某个专有 BI 或仓库模型里，逼你以后花大钱重建。第三，一边过度追求理想架构，一边业务还在对着不一致的数据失去信任。这三句话，每一句我都见过真实的团队在踩。

dbt 自己也写过一篇，叫 Semantic Layer in Pieces。它的核心建议是：找一个使用频率高、价值大、但范围窄的东西开始，别从那种宽泛的高管仪表盘开始。用最小的建模迁移量，换最大的影响。它举的例子是从客户获取成本这一个指标切入。dbt 的会议 Coalesce 上也有人讲，别在第一天就想着煮海。先建模那二十到五十个真正驱动高管讨论的指标，收入、毛利率、活跃用户、流失，定义一次，接进两三个 BI 工具，用看得见的一致性去建势头。

字节跳动的数据平台负责人公开说过一件事。字节明确拒绝了纯中台制，用的是中台加业务伙伴制，目的就是规避中台脱离业务需求、造轮子自嗨的风险。“造轮子自嗨”这五个字，几乎是对大而全语义层最精准的病理解剖。

Snowflake 那个 2MB 上限，本质也是同一个态度的工程化。它不让你大而全，逼你小而精。

这里我要诚实补一句。统一口径本身不是个错的目标。错的是把它当成 Day 1 的建设目标。口径统一应该是小而硬的语义层跑起来之后，自然沉淀下来的结果。你把口径统一当起点，就掉进了一个无底洞：让所有人对所有指标达成共识。那是 Big Bang 失败模式的组织版本。

再诚实一句。先做高频指标、再沉淀企业本体，这个顺序，目前还没有一个像汇丰那样公开走通的案例来完整验证它。厂商的叙事恰好和我相反。我这个判断，是基于工程直觉的推理，它和小而硬的逻辑是自洽的。但它是不是真能从指标语义的闭环，一路演进到企业本体，还需要实践来证明。我愿意把它当成一个有依据的押注，而不是一个已经验证的结论。

语义层是控制面，不是说明书

最后一节，我想把这件事说回它真正在 AI 时代扮演的角色。

语义层不是数据中台的说明书。它是 AI 用数据的控制面。

这不是我一个人想出来的话术。Forrester 已经正式把 Agent Control Plane 认定为一个独立的市场品类来评估。它的核心原则是，治理必须独立于构建平台和编排平台之外，才能提供独立的可见性，才能执行一致的策略。中文技术社区也独立得出了同一个框架。有人说，语义层正在变成数据加 AI 时代的数据消费控制面。把治理下沉到语义层，而不是散落在一张张报表和一个个 prompt 里，是企业级可用性的分水岭。

Dremio 有一篇文章，标题就是这条进化路径：从数据字典到 AI 副驾驶。它点出的关键转变是，治理要内建，不能外挂。在下游工具上打安全补丁，永远会留下缝隙。

Cube 有一段话，几乎逐字命中了我一直想表达的判断：

AI Agent 不需要更多对表的访问，它们已经有足够多的访问了。它们需要的是理解和护栏，是每个指标的一致定义、正确的 join 路径，以及在查询运行之前就强制执行的访问规则。这就是语义层。

这段话我没什么可补充的。它把“为什么是控制面”讲透了。Agent 现在不缺数据访问的入口，它缺的是在访问之前就被约束好的边界。

这里也要诚实。语义层是控制面的核心组成，是其中语义和数据那一半，但它不是全部。一个完整的控制面，还需要上下文层，需要可信和可观测层，需要本体和动作层。有人指出过语义层单独解决不了的问题：Agent 可能在更高的抽象层运作，它通过聚合、总结、重新表述，绕过你的行级权限。语义层本身没有消费敏感性这个概念。比如对一个部门的薪酬做聚合，就可能泄露本该受限的人力数据。

所以准确的说法是：语义层是控制面的前提，不是控制面的全部。

收束

把这一篇和几个月前那一篇放在一起，我的判断可以收成一句话。

数据平台这一轮真正被改写的，不是入口，是责任。语义层是这套责任里最关键、也最容易做烂的一个对象。你把它做成指标词典，它就会变成一本没人翻的说明书，被 Excel 轻松绕过。你把它做成可执行契约，小而硬，先服务高频决策和 Agent 调用，它才会真正进入 AI 时代的数据基础设施。

最后给你一个判断标准。

判断一个团队的语义层做得对不对，不用看它覆盖了多少指标，建模建得多全。看一件事就够了：半年之后，它还在被用，还是已经变成了新的历史债。

有人说，他们公司内部的 AI bot 做的就是邮件，没有做 message app，效果拔群。后来也在 message 里面试过，效果很差。另一个群友补了一句：应该做成 email 形式，用交互摩擦逼着用户投入思考，放慢节奏。

这句话有点反直觉。

过去一年，大家给 Agent 做产品时，默认方向几乎都是把它做得更实时、更像同事、更像一个随时在线的协作者。最好有输入框，有流式输出，有任务进度，有一堆状态卡片。看起来越像 IM，越像一个真的坐在旁边干活的人。

但我越来越觉得，这里有一个很容易走偏的地方。

Agent 的界面长成什么样只是表层。更深一层的问题，是它和用户之间到底建立了什么服务承诺。用户发出任务以后，心里默认你应该什么时候回、回什么、回到什么程度。这个隐形契约，比输入框顺不顺滑重要得多。

聊天窗口会把人拖回救火现场

IM 不是中性的容器。

它有在线状态，有红点，有短消息，有连续冒出来的气泡。这些东西组合在一起，会形成一种很强的时间默契：我发给你，你应该很快回；它弹出来，我最好马上看；它还在输入中，我最好别离开。

所以同样一个 AI bot，放在 IM 里，就不只是换了入口。它会让用户自动进入同步协作模式。

问题是，Agent 的很多工作并不适合这样协作。

它经常要读一段复杂上下文，要调用工具，要等外部系统返回，要在中途失败后换路径，要把结果整理成可以验收的东西。这个过程不像“聊两句”，更像“接一个活，然后晚点交付”。

如果把这种工作塞进 IM，用户很容易下意识盯着它。

一条消息冒出来，看一下。一个状态变了，处理一下。中间失败了，追问一句。几个 Agent 并行起来以后，人就不再像委托者，更像一个调度员，哪里冒火就去哪里扑。群里有人形容 herdr 这种实时任务流时说，感觉就是 put out fire，一个东西冒出来，也不仔细想到底是什么。

这不是界面小毛病。

这是介质在替产品定义工作关系。

邮件有一种天然的晚点交活感

邮件也不是中性的容器。

它默认就是异步的。你发出去以后，不期待对方立刻回。对方晚点回，也不显得失礼。邮件有 thread，有标题，有引用上下文，有转发，有附件，有历史记录。它天然把一件事放进一个可以沉淀、可以回看、可以继续接力的容器里。

这和 Agent 很匹配。

用户把客户邮件 forward 给 AI，是一个非常自然的动作。原始需求、上下文、附件、责任链都还在。AI 回来的时候，也不用在气泡里挤出几句碎片，而是可以带着完整语境交一份结果：它理解的问题是什么，它处理过哪些东西，哪些地方还需要人做判断。

这时候用户对 Agent 的期待也变了。

他不再盯着“怎么还没回我”。他关心的是：你什么时候交？交什么？交回来以后我怎么验收？

这三个问题，比“打字动画是不是流畅”重要得多。

一个让人放心的 Agent，不需要先证明自己一直在线。它更应该像一个靠谱的协作者：让用户知道需求已经收到了，大概什么时候能交工，交出来会是什么形式；中间遇到哪些坎儿需要人来拍板，哪些小事它可以自己处理。

邮件这个古老协议妙就妙在，它不需要额外解释太多，就已经帮我们管理好了等待。

有些摩擦是在保护判断

很多产品设计会本能地追求低摩擦。

入口越近越好，发送越快越好，反馈越即时越好。这个方向在很多场景里是对的。但 Agent 不是普通按钮。用户把任务交给 Agent，本质上是在做一次判断：我到底想让它做什么？我愿意给它多大权限？我希望最后拿到什么？

这些判断不能全都让顺滑体验吞掉。

一点点交互摩擦，反而会逼用户把任务想清楚。邮件里的标题、正文、转发、附件，其实都是轻量的结构化输入。它不像表单那么重，也不像 IM 那么碎。它给了用户一个很熟悉的暗示：这是一个正式请求，不是一句随口聊天。

这也是为什么老协议在 Agent 时代突然变得有意思。

邮件可靠，不是因为它古老，而是因为它在三十年里训练出了人类对等待、回复、留档、转发、责任边界的共同理解。Agent 面向人的交互，最缺的往往不是新控件，而是这种已经长在人身上的预期管理。

邮箱不是控制面

当然，我不是说 Agent 都应该搬进邮箱。

事故响应需要实时频道。高风险动作需要明确的审批界面。生产系统需要后台的运转轨迹和排错账本。多 Agent 运行时也需要 dashboard，让开发者看到哪里卡住、哪里失败、哪里开始胡来。

这些东西邮件替代不了。

更准确的说法是：不同服务承诺，应该进入不同介质。

需要快速澄清、多人收敛、处理事故的事情，放在 IM 或实时频道里。

需要异步交付、沉淀上下文、保留责任链、等待人类验收的事情，邮件反而可能是更好的面向人协议。

需要追踪执行、调试失败、审计授权的事情，就进入控制面。

这才是 Agent 产品真正该分清的边界。

不要让实时感绑架判断

现在很多 Agent 产品看起来科技感很足，实时输出、状态卡片、任务流、进度条都很完整。它们让人觉得系统在跑，也让人觉得自己掌控了现场。

但很多时候，这种实时感只是把用户重新拽回操作员的位置。

一个真正成熟的 Agent，不一定要假装坐在你旁边。它更像一个靠谱的供应商：收得到需求，说得清边界，按约定时间回来，带着证据交活，让你验收。

从这个角度看，Agent 时代最好的通信协议，可能不是下一个更炫的聊天窗口，而是三十年前那套看起来慢吞吞的邮件。

因为用户真正要的不是更快的回复。

用户要的是明确的托付，明确的等待，和明确的交付。

很多年过去了，我以为自己再也不会为这种打表计费的事情焦虑。但这几天用上最新的一代模型，看着那个限额提示，十几年前在出租车上的紧张感一下子全都涌了回来。

大厂天天在发布会上跟我们吹，说未来的智能无限多，不仅便宜，而且迟早会像自来水一样，拧开就有。他们还会拿数字作证，比如这两年 API 价格跌了七八成。但在重度用户的群聊里，真实情况刚好相反。最顶尖的智力依然是奢侈品，甚至变成了限量的配给品。一旦你的生活作息开始跟着额度走，人跟 AI 的关系就变了味，从用工具变成了抢货。

这周 Claude 推出的 Fable 5 限时体验，算是把厂商们这场宏大叙事的底牌给掀开了。

微信群里的粮票时代

即使你每个月交着订阅费，想用上这个目前最厉害的推理模型，限制也多得让人头疼。每周的额度上限直接砍半。更损的是，这个额度跟其他模型是共享的。如果你随手调别的模型写了几段代码，Fable 5 的额度会加倍扣除。等过几天体验期一结束，厂商直接不带它玩了，想用就得按量计费，先充钱才能跑。每百万输出 token 要收 50 美元，输入也要 10 美元。跟那些几美分一兆的廉价大模型比起来，它贵了千百倍，简直就是天价。

以前大家用 AI，是工作需要了就去调一下。现在不一样了，大家是在“蹬额度”。为了蹭上这波昂贵又短暂的高阶智能，我微信群里的同行们每天都在琢磨怎么把羊毛薅干净。

大家不再按需用软件，反而在围着这套额度重新安排生活。

有人发聊天截图吐槽：“3 个 max 5x 账号，1 个 pro……第二个 max 也快见底了，fable真烧太快了”。有的人早早把手头的方案和架构设计分门别类整理好，囤在那里，就等额度刷新的那一刻动手；有的人为了能不被打扰地专心干活，甚至特意跟公司请了假，“今天不去公司，专心蹬”；还有人熬夜把号里的额度一口气刷干净，最后在群里发表情包，吐槽自己快被气晕了。还有更绝的，交钱订阅，刷完额度立刻退款 cancel；或者直接写个 credentials pool 自动轮换账号，额度一超就自动换号。

看着群里这些人疯狂地囤货、套利、来回切号，我时常有种错觉，这哪里是使用现代的生产力工具，根本就是几十年前拿着粮票去粮店排长队买米。厂商在发布会的幻灯片里把未来描绘得无比美好，但现实却是最优秀的模型只对有钱人或者作息颠倒的人开放。

谁在蹬轮子：工具的反向驯化

但更讽刺的是，工具也在反向驯化人。

我们总觉得 AI 是个听话的小跟班，随叫随到，应该融入我们的工作流。可是，当大模型的刷新频率开始打乱你的睡眠，当额度的多少能决定你今儿去不去办公室，谁是主人、谁是工具就已经颠倒了。

我们总觉得 AI 是个听话的小跟班，但当重置时间开始安排你的睡眠，工具就已经反向驯化了人。

人不再是掌握全局的老板，反而像是一只定点干活的小白鼠，额度来了就得上去跑两圈。为了不白白浪费那点宝贵的最强推理次数，我们不得不把自己精力最充沛的黄金时间，都奉献给屏幕上冷冰冰的倒计时。

理性的代价：主动做智能分层

面对稀缺，大家也开始学聪明了，主动做智能分层。简单的翻译扔给免费小模型，琐碎的格式调整用各种平替，只有最核心的架构设计和需要“死磕”的代码，才舍得调用 Fable 5 的额度。

这种由稀缺额度逼出来的理性，实际上是一种认知防线的后撤。我们为了省额度，开始在每一次调用前做精密的算计，甚至在潜意识里逃避那些可能失败的探索。

当试错成本变成了实时跳动的账单，谁还敢让 AI 随意发散思维去瞎猜？AI 最迷人的地方，恰好在于那些在大量尝试和瞎猜中偶尔撞上的灵感；而配给制，正在把我们探索新边界的勇气，一点点扼杀在防漏斗筛一样的层级设计里。

顶级智能的稀缺真相

或许这种抢额度的状态过阵子会缓解，但它也说明了一个残酷的现实。哪怕普通大模型的成本降到脚脖子，那批真正能解决难题的、金字塔尖的顶级智能，永远都是极少数人才能用得起的奢侈品。而在这道由稀缺额度堆砌的门槛面前，我们退化回“囤积与套利”的速度，快得超乎想象。

我们在厂商画的大饼里，以为未来的智能无穷无尽，其实骨子里早就习惯了在紧紧拉起来的门槛前钻空子。现在最顶尖的模型变成了限时抢购的商品，我们抢的不仅仅是这几万个 token，其实是连同它打乱的那份作息表，也一并买了单。

但现在回头看，这个误解本身，可能正是它设计得最妙的地方。这也是为什么我觉得，重置卡是最近我见过最聪明的小型增长机制之一。

我一开始以为重置卡是什么

我原来的理解是这样的：假设我的 weekly quota 周期是 1 号到 7 号。我在 5 号把额度用完了，于是打出一张重置卡。我的直觉是，这张卡会把我的额度重新补到 100%，然后我靠它撑过 6 号和 7 号。等到 7 号，原本应该来的自然刷新照常到来。

换句话说，我以为重置卡是在正常配额之上，额外叠了一周额度。

实际并不是这样。

真正发生的是：重置卡会把额度恢复到 100%，同时从你使用的那一刻开始，重新启动一个七天周期。如果我在 5 号重置，那么下一次自然刷新就不再是 7 号，而是 12 号。它不是“多送一周额度”，而是把下一个窗口提前拉到现在重新开始。

理解这一点以后，我反而开始对这件事背后的经济账感兴趣。因为我“感觉自己拿到的东西”和 OpenAI“实际付出的成本”之间，差距大得有点离谱。

这笔账：感知价值和真实成本

拿我自己的场景算一遍。假设我在一个七天周期的第 5 天，只剩 10% 左右额度，然后使用重置卡。

我的体感是什么：好像凭空多了一整周额度。如果一个月里拿到两张卡，一个月大概四个周周期，那么体感上就是多了两周，相当于这个月可用容量增加了 50%。说实话，这就是我第一眼看到这些卡进账户时，大脑自动算出来的数字。

OpenAI 的真实成本是什么：这张卡只是让我提前两天开启了一个新的 100% 窗口。长期摊下来，这种窗口压缩大概相当于 2/7 个 weekly quota，也就是 28.6%。但我使用卡片时，原周期里还剩下的 10% 也被我放弃了。所以每张卡真正带来的净增量，大概是一个 weekly quota 的 18% 到 19%。如果我更晚才重置，或者重置时剩余额度更多，这个数字还会继续变小。

所以，一个月两张卡，用户感觉像是多了 50% 容量。但真实边际成本大约是一个 weekly quota 的 37%，也就是不到一个月总容量的 9%。感知收益和真实成本之间，差不多有 5 倍 的杠杆。

而且这个 9% 还只是上限，不是期望成本。只有当我把新窗口也彻底用光时，这个成本才会完整发生。再加上 30 天过期机制，有些卡会被放着放着自然过期；多数用户本来也不会接近打满额度。这样算下来，每发出一张卡，平均真实成本只会更低。

对增长团队来说，这个比例太漂亮了：让用户强烈感觉“他们给了我 50% 更多”，但公司实际付出的只是其中一小部分。

为什么卡片比过去的统一重置更好

在重置卡出现之前，Codex 团队的补偿工具其实很粗：如果某个严重 bug 浪费了用户额度，或者产品打了某个 milestone，他们就给所有人统一重置一次 limit。听起来很大方，但全局重置落到不同用户身上，效果非常不均匀。

刚刚自然刷新过的用户，本来就几乎是满额度。再重置一次，基本没价值。离下一次自然刷新只剩一天或半天的用户，本来马上也要补满，价值也很低。两三天就把额度烧光的重度用户，才是真正能感受到天降补给的人。

还有第四类情况更麻烦：全局重置甚至可能伤害用户。比如某个人已经在周期第 6 天，但还剩 50% 额度，他是故意留着第 7 天做一个大任务的。结果系统在第 6 天强行重置，把他攒下来的 50% 清掉，并重新启动周期。

从第 7 天到第 13 天，他总共只有新的 100%。但如果按原来的自然节奏走，第 7 天到第 14 天，他原本会拥有攒下来的 50%，再加上新刷出来的 100%。这份“礼物”，实际上悄悄吃掉了他近期可用容量的三分之一。

这类用户会抱怨，我觉得完全合理。后来我也看到过，社区里类似的反馈，确实是 OpenAI 转向 self-serve reset model 的原因之一。

重置卡用一个动作解决了这些问题：把时机交给用户自己。

没人会在额度还满的时候去重置。没人会被强行抹掉自己攒下来的额度。每张卡都会被用户留到感知价值最高的那一刻使用：任务做到一半撞墙了，如果不用卡，就只能等好几天。

公司只在用户真正需要时付出成本，而且是在用户最能感受到价值的那个瞬间付出。还是同一笔 goodwill budget，但命中率高了很多，误伤也几乎没有了。

百货商场那套玩法

这件事让我想起以前在电视剧里看过的一种商场促销：满 300 返 150 代金券。

站在消费者视角，“满 300 返 150”很容易被大脑识别成“五折”。但你认真算一下：你花 300 元，最后拿走了 450 元标价的东西。也就是按原价的 67% 付款，真实折扣大概是 33%，不是 50%。

对商场来说，真实情况还会更好。因为很少有人刚好买到 300 元。你可能本来只想买 250 元的东西，为了凑门槛，又加了一件，最后花到 400 元。返给你的 150 元代金券，还会把你再拉回店里消费，而且大概率又要搭一些现金。

最后就变成：你买了 550 元的东西，实际花了 400 元。折扣已经只有 27% 左右。如果再把代金券使用过程中的门槛、过期、凑单和摩擦算进去，真实成本可能会继续接近 20%。这个机制在用户体感上像五折，商场成本大概是 20% 到 30%，还顺手诱导了更多消费。

重置卡其实也是同一套玩法，只是把现金和羊绒衫换成了 compute。

所以我后来觉得，重置卡真正聪明的地方，不只是“便宜地补偿用户”。它把用户感知价值和平台真实成本拆开了：用户看到的是一张完整的救命卡，平台承担的是未来某个时刻才可能发生的一小段边际成本。

这个差值，是整件事的第一层价值。用户脑子里会把它记成“我多了一周”，甚至记成“这个月多了两周”。但真实账本上，它可能只是一个 weekly quota 的 18% 左右，而且只有在用户真的把新窗口也用掉时，成本才会完整发生。

但更妙的是第二层：用户不花这张卡，也已经有获得感。

这和全局重置完全不一样。全局重置发生在系统指定的那一刻，用户要么刚好需要，要么没感觉，甚至被误伤。重置卡到账以后，即使我暂时不用，它也像一张放在口袋里的备用票。下次项目做到一半撞到 limit，我知道自己还有一次继续往前走的机会。

这种安全感本身就是产品价值。它降低的是额度焦虑，不只是增加了可用额度。用户还没消耗 compute，公司还没付出真实成本，但用户已经觉得账户里多了一层缓冲。这就是卡片形态比一次性重置高级的地方：它把“使用价值”和“持有价值”分开了。

我说这些，并不是在讽刺 OpenAI 精明。作为用户，我的体验确实变好了：任务做到一半撞到限制，打出一张卡，然后继续干活。更重要的是，在还没打出那张卡之前，我已经因为“我有一张卡”而更安心了。

这件事值得记下来，是因为它提醒我：好的增长机制，不一定是多送东西，而是把感知价值放大，把真实成本压低，再用一个合适的形态让用户提前感受到收益。对用户来说，那是一张救命卡。对平台来说，那是一笔不一定会兑现、即使兑现也高度受控的成本。

重置卡只是一个很小的功能，不会出现在任何发布会主视觉里。但这种小功能，反而能看出一个团队是不是真的理解自己的产品。他们不只知道 compute 成本是多少，也知道用户心里的安全感值多少钱。

增长里真正厉害的设计，往往就是让这两个数字越拉越开。

我儿子小时候也治过牙，比她严重，甚至做了根管。两个孩子，早晚都刷牙，控制零食也算认真，但牙齿还是出了问题。这让我很纳闷。

回想我小时候，好像没这回事。全班同学谁经常去看牙医？我没有印象。小孩的乳牙六七岁就换了，那时候也没人因为几颗蛀牙专门跑医院。是我记忆有偏差，还是真的有什么变了？

数据说：确实变差了

我后来去查了数据。中国每十年做一次全国口腔健康调查，最近两次分别是 2005 年和 2015 年。结果很明确：5 岁儿童的乳牙龋患率从 66% 升到了 70.9%。也就是说，七成的 5 岁孩子有蛀牙。12 岁恒牙龋患率也从 28.9% 升到了 34.5%。

这不是错觉，是实打实的趋势。而且有意思的是，这个趋势是"逆全球"的。全球范围内，儿童龋齿的年龄标化率从 1990 年到 2021 年一直在下降。发达国家降得尤其明显。丹麦 12 岁孩子的平均龋齿数只有 0.7 颗，日本 3 岁孩子的龋患率从 1983 年的 70% 降到了现在的 12% 左右。

中国是少数"越发展越烂牙"的国家之一。

不是基因变了，是嘴里的环境变了

原因其实不复杂，就是三把剪刀同时剪开了。

第一把：糖。1998 到 2008 年，城市儿童日均饮料消费从 329 毫升翻倍到 715 毫升。到 2013 年，六成以上的学龄儿童每周至少喝一次含糖饮料。一瓶 500ml 的果汁含糖 50-75 克，已经超过 WHO 给儿童建议的每日上限。龋齿的第一因果因素就是糖的暴露频率。不是吃了多少，是吃了多少次。每喝一口，口腔里的 pH 值掉到临界线以下，牙齿就在溶解。一天喝五六次奶茶饮料的孩子，牙齿一天被酸蚀五六轮。

第二把：食物质地。我们小时候吃花生、啃玉米、嚼硬苹果。这些粗纤维食物咀嚼时有自洁作用，能带走部分残渣。现在的孩子吃软面包、饼干、酸奶杯、果泥。每一样都粘在牙齿上，精加工食品的粘附性比粗粮强太多。80% 的中国儿童全谷物摄入远低于推荐量。牙齿失去了天然的"摩擦清洁"。

第三把：防御缺位。发达国家降龋齿率最大的功臣是两样东西：社区水加氟和含氟牙膏普及。澳大利亚做过系统评价，水氟化能减少 26%-44% 的儿童龋齿。中国因为部分地区有地方性氟中毒，基本没搞水氟化。含氟牙膏使用率也远低于发达国家。很多家长因为怕"氟中毒"，专门给幼儿买无氟牙膏，反而丧失了最基础的保护。

总结一下就是：攻击端大幅加强（糖+粘性食物），防御端原地踏步甚至后退（氟保护缺位+刷牙质量差）。这不是孩子的问题，是整个饮食环境变了。

"刷了"和"刷干净了"是两回事

我家两个孩子早晚都刷牙，为什么还烂？这个问题困扰我很久。

后来明白了。刷牙只能清洁牙齿约 65% 的表面。牙缝、窝沟这些地方刷不到。加上儿童的刷牙方式通常有问题：时间不到一分钟（推荐三分钟）、方法是拉锯式横刷（应该是竖刷或巴氏刷法）、后面的大牙经常跳过。

更关键的是频率。龋齿不是"一天不刷就得"，而是"口腔长期处于酸性环境"的结果。如果孩子白天三四次零食、两三次含糖饮料，即使早晚刷了两次，牙齿在一天里仍然有大量时间暴露在酸蚀环境中。刷牙能清除菌斑，但挡不住持续的糖输入。

所以真正的防线不是"刷不刷"，而是"糖暴露的频率"。我以前从来没从这个角度想过问题。

存在过度治疗吗

存在。但原因不是个别黑心医生，而是薪酬结构的问题。

中国口腔诊所尤其是私立连锁，主流薪酬模式是"激励型"：固定工资占 20-30%，剩下的靠提成。做越多项目、用越贵方案，医生收入越高。行业自己的管理文献里直说"容易形成过度消费"。

央视去年底做过一个调查，记者陪一位女士拿同一颗牙走了 8 家诊所，得到了 4 个方案：从 300 元的简单补牙，到 5000 元的根管加冠（甚至建议旁边一颗好牙也一并处理）。差距十几倍。那位推荐最贵方案的院长，在卫健委系统里查不到执业注册信息。

这不是阴谋论，是制度性激励扭曲。当一个行业 70-80% 的收入靠提成，方案选择必然偏向对收入有利的方向。资本也在推波助澜：2014 到 2021 年，口腔连锁经历了多轮亿级融资，增长压力最终落到每家门店的客单价上。

但"不治"也不对

我一度想过：乳牙反正要换，不如不管。

查完资料我放弃了这个想法。所有主流指南（美国儿童牙科学会、WHO、中华口腔医学会）都明确否定了"乳牙不用治"的说法。理由很实在：龋齿不会自愈，只会进展。乳牙根尖感染会伤害下面正在发育的恒牙胚。乳牙过早丧失会导致邻牙倾斜，恒牙萌出没有足够空间，后面还得花更多钱矫正。

但关键的转变是：现代共识已经不是"所有龋洞都必须钻开补"了。美国儿童牙科学会 2023 年出了一个微创牙科的政策文件，核心观点是：如果菌斑能被有效管理，龋洞可以不进展。有一种叫 SDF（氟化氨银）的东西，涂在龋洞上一两分钟，就能让 60-90% 的龋齿停止发展。操作极简，孩子不需要配合，费用极低。唯一的缺点是会把牙齿染黑。

这里有个讽刺：最有效、最无痛、最便宜的方案，因为"不好看"被市场排斥。而最贵、最有创伤的方案（根管+冠），因为"看起来正规"被过度推荐。审美焦虑在替孩子做医疗决策。

合理的中间地带

经过这一轮了解，我现在的判断大概是这样的：龋齿是真实的风险，不能放任。但治疗的强度需要匹配实际严重程度，不是一律往最贵的方案走。每次就医至少去一家公立医院听一个基线意见，然后再决定。比治疗更重要的其实是预防：控制糖的频率（不是零糖，是减少次数）、用含氟牙膏、每半年涂氟、6 岁做窝沟封闭。

说实话，我以前对"每半年涂氟"完全没概念。现在看了数据才知道，一次含氟牙膏的示范试验就能减少 43% 的龋齿增量。这比任何治疗都划算。

更大的感触

坐在牙科诊所的候诊区，看着一屋子带小孩来的家长，我在想一个更大的问题。

日本也没搞水氟化，文化上对氟也有顾虑，跟中国的约束条件差不多。但人家靠法定 3 岁检查、学校每年检查、持续几十年的行为教育，把 3 岁龋患率从 70% 降到了 12%。北欧更夸张，50 年把 12 岁平均龋齿数从 6.9 降到了 0.7。

中国不是没有方案（国家卫健委的技术方案跟国际接轨），但执行覆盖率极低。94% 的龋齿儿童没有得到任何治疗。同时，中产城市家庭频繁被引导做更多治疗。既无预防，又有过度治疗。这两件事同时存在，形成了一个很荒诞的双峰。

这不只是口腔的问题。它是一个典型的"中等收入陷阱"缩影：经济发展改变了生活方式（高糖饮食），公共服务体系（预防性保健）没跟上，市场快速填补了缺口（私立诊所爆发），但市场的逻辑是利润最大化，不是健康最优化。

教育、养老、心理健康，很多领域都是这个结构。公共服务缺位，市场填补，过度商业化，公众焦虑加剧。

作为家长能做的，就是理解真实风险，不被恐惧营销绑架，也不因为"反正要换"而心存侥幸。在保守和激进之间，找那个有数据支撑的中间点。这大概是这个时代做父母的基本功之一了。

这个问题对我来说不是一个抽象命题。我自己就在大厂做中后台团队，也在金融集团的数据部门里做面向业务的产品。过去我写过一篇文章，说 AI 时代来了以后，中台给前台做产品会越来越难。原因是，过去中台最大的优势之一是规模化，前台重复造轮子的成本太高，所以中台把共性能力沉淀下来，做成统一产品，提供给多个业务使用。

但 AI 让这件事发生了变化。做一个东西变容易了，前台业务可以自己上手做一些过去本应由中台提供的类 SaaS 产品，而且做得很快，和自己的业务上下文贴得很近。所以我当时的判断是：中台做产品会越来越难。后来我又补了一句：AI 时代，做东西越来越容易，但做出能给别人用的东西越来越难。

今天和老板聊完，我觉得这个问题还可以再往前走一步。

一个真实的例子

我们最近做广告投放平台时，遇到了这个问题。平台里有一个模块叫智能回传，一开始是给证券业务做的。证券做完以后，理财平台团队也需要。

按照传统中台思路，接下来会进入一套很熟悉的讨论：要不要做成公共产品？证券和理财怎么隔离？未来信用卡来了怎么办？哪些字段可以抽象，哪些规则可以配置，哪些流程可以统一？

这些问题看起来都很专业，也很中台。但它们会把事情带进另一种复杂度里。因为只要开始追求统一产品，就一定要提前考虑未来，未来有哪些业务会接入，未来有哪些差异会出现，未来哪些字段要兼容。问题是，很多未来根本没有发生。为了一个还没发生的业务差异，我们在今天增加一层抽象；为了一个可能出现的场景，我们在今天增加一套配置；为了让所有人都能用，我们让当下真正要用的人先忍一忍。

于是排期变长了，方案变重了，体验变远了。

我们在智能回传这个模块上摸索了一两个月，走了不少弯路。后来我发现，问题可能不在于设计得不够好，而在于一开始就问错了问题，我们默认了一个前提：既然多个业务都要，中台就应该做一个统一产品。

但为什么一定要这样？为什么不能中台给证券做一个，理财来了再给理财做一个，信用卡来了再给信用卡做一个？这些产品可以长得很像，也可以共享底层能力和建设经验，但不一定非要被塞进同一个抽象产品里。

业务不是想自建，是被逼的

表面上看，越来越多业务方开始自己造轮子，是因为 AI 降低了工程化代价。业务方可以用 AI 写代码、搭页面、做原型，把过去需要中台才能做的工具自己做出来。这个判断当然成立。但我觉得更深的原因，是很多中台还在恪守传统的大一统形式：因为要抽象，所以不能只为一个业务设计；因为要共性，所以不能完全贴合某个场景；因为要复用，所以要让不同业务排队等待统一方案。

很多业务方并不真的想自己做。他们不懂底层系统，也不想长期维护这些工具，真正想要的是一个能解决自己问题、能快速上线、能贴近业务的产品。但如果中台给不了，业务就会被迫自己做。

这是个反讽：中台越想避免重复造轮子，越容易把业务推向重复造轮子；中台越执着于大一统，业务越觉得等不起、用不好、离自己太远。最后组织里出现一堆散落的小工具、小系统，看起来是业务太喜欢自建，实际上可能是中台的供给方式出了问题。

复用的东西变了

这里的关键，不是让业务方自己去造轮子。恰恰相反，我现在更倾向于认为，很多轮子仍然应该由中台来造，因为业务方不一定了解底层系统，也未必有意愿长期维护。更重要的是，很多事情看起来只是"做一个工具"，背后其实有大量经验、判断和治理。

一个智能回传模块，表面上只是把转化数据回传给广告平台。真正做起来，会涉及事件定义、数据质量、渠道 API、归因口径、回传延迟、去重、异常监控、合规边界。业务方可以用 AI 快速做出一个原型，但不一定知道什么样的回传才是好的，也不一定愿意为它承担长期维护。

所以，AI 时代真正变化的不是"业务自己造轮子"，而是"中台自己重复造轮子的成本下降了"。过去每造一个轮子都很贵，产品设计贵，研发贵，测试贵，联调贵，维护也贵，所以我们只能努力抽象，把差异变成配置。现在，中间那层业务产品的建设成本正在下降，一个业务化模块、一个定制流程、一个专属看板，不再像过去那么沉重。既然造一个业务版本的成本变低了，就不一定要把所有业务都压进同一个统一产品里。

更何况，很多所谓共性，本来就是表面共性。证券和理财都需要智能回传，但业务目标不同，用户旅程不同，转化定义不同，效果解释方式也不同。表面上都叫"回传"，落到业务里，语义并不一样。过去中台最容易犯的错误，就是看到两个业务长得像，就急着抽象。公共产品里开始出现越来越多开关、白名单、例外流程。最后产品确实统一了，但每个业务都觉得不好用；系统确实复用了，但复杂度被转移到了中台内部。这不是复用，这是把差异压扁。

我现在更愿意用这个方式理解中台：中台不一定要复用同一个产品，而是要复用造产品的能力。 产品本身可以不完全复用，但中台团队的经验、方法、数据理解、接口能力、治理能力、踩坑记录、交付流程可以复用。中台给证券做了一个智能回传，接下来给理财做时，不是从零开始，它知道哪些地方会踩坑，哪些指标要提前定义，哪些渠道规则要注意，什么样的看板业务真的会用。

过去我们复用的是一个公共产品，现在我们复用的是一套生产能力。

边界怎么划

这也意味着，中台提供的东西，共性上应该变薄，个性化上应该变厚。但"哪些能个性化，哪些不能"不能只是一句口号，还是得有具体的判断标准。以智能回传为例，我倾向于这样划：

必须统一、不能个性化的，是那些一旦不统一，就会造成数据失真、合规风险或跨业务协同成本的部分。事件定义和埋点规范、归因口径、数据质量和去重逻辑、监控和告警标准、权限和合规边界。这些东西如果证券一套、理财一套，未来想做跨业务分析或者审计的时候，会付出更大的代价。

可以且应该个性化的，是那些只影响单一业务体验和效果、不产生外部性的部分。回传时机和触发策略、看板的展示方式和指标口径解释、和业务系统的对接方式、运营侧的规则配置。证券的智能回传应该贴着开户转化、资产入金、用户分层来设计；理财的应该贴着申购、持仓、复购、风险偏好来设计；信用卡未来如果接入，也应该有自己的申请、激活、首刷、额度逻辑。这些差异，就不该被压进一个统一配置项里，而应该是产品设计时认真对待的对象。

一句话概括：看这件事是否会外溢到其他业务或者产生系统性风险，会外溢的统一，不会外溢的个性化。

这个边界如果不清楚，个性化就会变成失控的项目制；如果定得太死，个性化又会退回大一统。

这需要什么样的组织

这套模式对组织也提出了新的要求，而且不只是"中台人员要更懂业务"这么简单。即使造一个轮子的成本下降了，同时给证券、理财、信用卡各造一个、各维护一个，人力和治理的复杂度依然是接近线性增长的。这意味着，要么中台团队要适度扩编，要么需要把人以更贴近业务的方式分布出去，而不是继续挤在一个中心化的排期队列里。

这也是为什么，新中台的人需要更像 FDE：不是单纯的研发，也不是传统意义上的产品经理，而是带着工程能力、产品判断和中台资产，深入到业务现场的人。他要能听懂业务在说什么，也要能判断哪些诉求是真问题；他要能快速做出一个业务可用的产品版本，也要能把现场经验反哺回中台的资产体系。他需要知道证券为什么要这样回传，理财为什么不能照搬证券；也需要知道哪些东西绝对不能为某个业务随便改，哪些可以为了业务效果快速定制。换句话说，他既要能进入业务，又要守住中台。

中台不再只是一个平台建设部门，而要变成一支能不断生产业务产品变体的团队。不是给所有业务一个统一答案，而是基于同一套能力，给不同业务做出不同答案。

难点不在于写代码，AI 已经让写代码、搭页面、做原型变得越来越快。真正的难点在于，中台团队有没有能力理解不同业务的差异，有没有能力把经验沉淀下来，有没有能力在重复造轮子的过程中保持质量和治理。

重复造轮子本身不可怕

可怕的是，每个业务都自己造，每个轮子都没人知道为什么这么造，也没人负责长期维护；更可怕的是，中台为了避免重复，做出一个过度抽象的统一产品，最后让所有业务都不舒服，反而把业务推向自己造轮子的困境。

更好的状态是：轮子可以重复造，但由中台主动来造；每个轮子可以贴近业务，但背后有同一批人、同一套经验、同一套治理要求。

过去，中台的价值是"我做一个，大家都用"。现在，中台的价值可能变成："我做过一个，所以我能更快、更好地给你做一个适合你的。"

这两句话看起来差别不大，背后的组织逻辑完全不同。前者要求业务适配中台，后者要求中台进入业务。

AI 时代，中台真正要复用的，可能不是轮子本身，而是造轮子的手艺。而中台真正要避免的，也不是重复造轮子，是让业务被迫自己造轮子。

今天聊完以后，我反而觉得中台没有消失，只是需要放下一个执念：不是所有复用都必须表现为同一个产品。

热浪这几年已经不稀奇了。真正让我觉得别扭的是另一个反差：欧洲明明是发达地区，为什么很多地方一到夏天还像在靠意志力降温？酒店没有空调，老公寓没有空调，公共交通闷热，很多家庭靠风扇、遮阳和夜里开窗撑过去。

如果只从游客视角看，这很容易变成一句吐槽：欧洲发达是发达，生活基础设施怎么这么落后。

但我查了一圈之后，反而觉得这个问题不能这么问。欧洲空调少，不是因为它不像发达国家，而是因为它太像一个成熟发达系统。它的建筑、能源、街区审美、产权结构、政策语言和生活习惯，都深深嵌在一个旧气候假设里。

过去，这套系统是优势。现在，气候变了，优势开始变成摩擦。

今年的热，不只是“天气热”

先说热本身。

世界气象组织在 6 月 26 日说，欧洲正在经历一场广泛而强烈的 6 月末热浪，多国打破纪录。法国 6 月 24 日全国平均气温达到 30.0°C，瑞士 Basel 创下 38°C 的 6 月纪录，荷兰 KNMI 对 8 个省发布了前所未有的极端高温红色警报。WMO 同时提醒，欧洲是全球升温最快的大陆之一，从 1976 年那场历史性热浪到今天，欧洲整体已经升温大约 2°C。

所以今年的热不是一个孤立温度数字。它是一次天气事件，叠加在一个已经变暖的大陆上。

短期看，是热空气从伊比利亚半岛往北、往东推进，再被高压或阻塞型环流留住。干旱和土壤湿度下降，会让更多太阳能量转化为空气温度。城市热岛继续加码。更麻烦的是夜里降不下来。

WMO 特别解释了欧洲常说的 tropical night，也就是夜间温度不低于 20°C。白天热当然难受，但夜里不降温更危险，因为身体没有恢复窗口。老人、孩子、孕妇、户外劳动者和慢性病人，真正承受的是连续几天的累积压力。

这也是为什么“欧洲以前夏天也热”这个说法不够。以前也会热，但底座没这么高，夜里也更容易缓一口气。现在像是篮球比赛里篮筐被放低了。你仍然要分析这次进攻怎么打成的，但不能假装篮筐高度没有变。

欧洲适应过夏天，只是适应的是旧夏天

很多人说欧洲人不喜欢空调。这个说法有一点真实，但它把因果关系说反了。

欧洲不是没有夏季适应方式。厚墙、小窗、百叶、遮阳、自然通风、地下空间、午后节奏、夏季休假，这些都是适应方式。它们不是落后，而是旧气候下很聪明的低能耗方案。

问题在于，这些方案服务的是旧夏天。

旧夏天的欧洲，热可能热，但通常不是长期湿热、高夜温、高密度城市热岛叠加的那种热。传统策略是白天遮阳，晚上开窗，把热排出去。这个策略成立的前提是夜里真的会凉下来。

一旦夜里不降温，老房子的热容量就会从优势变成负担。厚墙白天慢慢吸热，晚上慢慢释放。自然通风如果遇到外面同样闷热的空气，效果会大幅下降。顶层公寓、老年人住所、没有外遮阳的房间，会变成真正的风险点。

这不是欧洲没有生活智慧。是生活智慧的适用环境变了。

空调在美国是设备，在欧洲常常是制度工程

IEA 的家庭空调装备率图表经常被用来说明这个差距：美国、日本家庭空调普及率很高，多数欧洲国家明显低很多。这个数字背后的关键，不只是收入，也不是技术可得性，而是安装空调这件事在不同社会里是不是顺手。

在美国郊区独栋住宅里，空调往往属于家庭 HVAC 系统的一部分。房子、产权、外机位置、电力容量、消费习惯，都是围绕这个系统长期适配的。业主想升级，很多时候是一个市场交易问题。

在欧洲城市公寓里，分体式空调常常不是一个简单消费决策。你要考虑外墙能不能打孔，外机能不能挂，冷凝水怎么排，噪音会不会影响邻居，物业和业主委员会同不同意，历史街区是否允许破坏立面，租客有没有权利安装，房东愿不愿意投钱。

也就是说，同样一台空调，在美国可能是一件家电，在欧洲可能是一套审批、协调和邻里关系。

这里面没有哪个单点特别神秘。真正重要的是它们叠加之后的摩擦。

如果一个人住在巴黎、伦敦、柏林、罗马的老公寓里，夏天一年最难受也许就两三周。要为这两三周去说服房东、申请许可、花钱布管、处理外机、承担电费，还要承受“这东西不环保、不美观、不健康”的文化压力，很多人自然会选择忍一下。

忍一下，过去是合理选择。

气候变化的问题在于，它把“忍一下”的天数变多，把风险人群的代价变大，把原来偶发的舒适问题推成公共健康问题。

欧洲的低空调率，其实是供暖中心主义的结果

欧洲建筑能源政策长期有一个主轴：供暖。

这并不奇怪。过去真正决定死亡率、能源贫困和家庭账单的是冬天。燃气锅炉、区域供暖、建筑保温、热泵替代，这些都是围绕冬季能源系统展开的议题。IEA 讨论 heat pumps 时，核心语境也是建筑能效和供暖脱碳。可逆热泵当然可以制冷，但在欧洲政策语言里，它首先是“把供暖从化石燃料里迁出来”的工具。

这就形成了一个有意思的错位：欧洲越来越需要 cooling，但它的制度肌肉仍然长在 heating 上。

补贴、安装队伍、消费者认知、建筑改造目标、电网规划，很多都围绕“冬季少烧气”组织。夏季制冷像一个后来插进来的需求。它越来越重要，但还没有完全进入主系统。

这也是为什么买空调在欧洲不只是消费升级。它会立刻撞上能源政治：如果每家都装空调，夏季电力峰值怎么办？如果老房子保温越来越好但通风和遮阳没做好，会不会冬天省了气、夏天多耗电？如果把制冷当成新刚需，欧洲减碳目标和电网投资要怎么重排？

空调在这里不是孤立设备，而是能源系统的新变量。

文化不是假原因，但它是表层原因

欧洲人对空调的排斥确实存在。有人觉得吹空调不健康，有人觉得外机丑，有人认为开空调不环保，有人更喜欢自然通风。这个文化层面不能忽略。

但我不认为文化是主因。

文化很多时候是历史路径的表达。过去气候允许，建筑允许，能源账单也让人克制，于是“不开空调”就能被解释成自然、环保、健康、有品位。反过来，如果一个城市连续多年出现危险高温，如果老人住在顶层房间里夜里无法降温，如果学校、医院、地铁和养老院都开始承压，文化叙事会变。

日本也有节能文化，但东京不会因此不用空调。中国很多家庭也会担心空调病，但在长江中下游和华南夏天面前，这种担心不会阻止空调普及。

所以文化会影响采用速度，但决定采用空间的是气候、建筑、制度和电价。

发达系统最大的风险，是把旧世界优化得太好

这件事最有意思的地方在这里。

欧洲低空调率不是欠发达的表现，而是发达系统路径依赖的表现。它过去把城市、建筑、能源、审美和生活方式优化得太完整了，以至于当外部气候条件改变时，调整速度反而慢。

一个欠发达系统可能没有太多存量约束，新建房子时直接装空调、装热泵、重做电网。一个高度成熟的欧洲城市，反而有更多不能动的东西：历史立面不能动，街区风貌不能动，租赁关系不能轻易动，能源政策不能偏离减碳目标，电网峰值不能随便推高，公共预算也不能无限扩张。

成熟系统不是不能变，而是每一步变化都带着遗产成本。

这就是欧洲今天的真实处境。它不是没钱买空调，也不是没有技术，而是一个旧气候下形成的高质量生活系统，突然开始面对新气候下的高频压力测试。

未来不会是“欧洲全面美式空调化”

我也不认为欧洲的答案会简单变成：像美国一样，家家户户大空调。

这条路很可能既不现实，也不优雅。欧洲真正会走的，更可能是一个混合方案：更多可逆热泵，更强建筑遮阳，更好的通风和外遮阳改造，城市增绿，冷屋和公共避暑空间，医院、养老院、学校等脆弱场景优先制冷，电网和电价机制适配夏季峰值，再加上局部放松外机和建筑改造限制。

换句话说，欧洲不会只是在旧系统上补一台机器。它需要重写“夏天”这个系统变量。

过去欧洲住宅的基本问题是：冬天如何少烧一点。未来的问题会变成：冬天如何少烧，夏天如何不死人，而且全年能源系统不能被冲垮。

这比安装空调复杂得多。

最后

这件事对欧洲之外的人也有启发。

很多系统的脆弱性，不是在它很差的时候暴露，而是在它对旧环境优化得太好的时候暴露。旧环境稳定时，那叫效率；外部条件变化后，那叫路径依赖。

欧洲的空调问题就是一个很直观的例子。过去凉爽的夏天、厚重的建筑、严格的街区保护、供暖优先的能源系统、对低能耗生活的文化认同，合在一起构成了一种很欧洲的现代性。它不低级，甚至很高级。

但气候变化不尊重这种高级感。

它只问一个问题：当 40°C 的白天和 25°C 的夜晚越来越多，你的系统还能不能保护人？

如果不能，发达本身不会替你降温。

这句话容易被听成鸡汤。失败是成功之母，多摔几次就会成长。这类话我其实没什么兴趣。它太安全了，安全到几乎没有信息量。

我想说的是另一件事：在 AI 时代，成功经验正在变得越来越容易被模仿，失败教训反而越来越稀缺。

成功经验如果没有拆开失败，很容易变成一段顺滑的故事。失败如果被认真拆开，才会变成下一次判断的边界。

这件事和 AI 的工作方式有很大关系。

AI 太擅长生成“成功的样子”了

过去我们重视经验，是有道理的。

一个人做成过几件事，大概率知道里面的门道。他知道机会怎么判断，项目怎么推动，人怎么协作，组织里的坑怎么绕，不确定时怎么取舍。

所以传统组织喜欢沉淀经验。最佳实践、成功案例、方法论、SOP、复盘文档，本质上都是把一条走通过的路保存下来，让别人下次少摸一点黑。

但 AI 出现以后，成功经验的外壳开始变得便宜。

你给它一个目标，它马上能拆策略、路径、动作、指标、风险、排期。你让它写成功案例，它能写得很完整。你让它总结方法论，它也能总结得很漂亮。有时候，它写出来的东西看起来甚至比真实经验更像经验。

原因不神秘。

大模型本质上是在海量文本里学习“什么内容最像一个合理的下一句”。而互联网上最多的，恰恰是被整理过的成功叙事：战略清晰、执行到位、用户洞察准确、组织协同高效、关键节点判断正确。

这些句子不一定错。但它们太像了。

一个项目成功后，事后总能总结出一条干净的因果链。我们做了 A，所以拿到了 B。我们选择了这个方向，所以打开了局面。我们坚持了某个原则，所以最终跑通了结果。

真实情况往往没这么干净。

成功里面混着资源、时机、运气、竞争对手的失误、老板的支持、某个关键人的个人能力、某个外部窗口突然打开。事后复盘最容易做的一件事，就是把这些复杂因素压成一条漂亮的主线。

人类自己就爱这么干。AI 会把这件事干得更快、更顺、更像那么回事。

所以我对“成功经验”的警惕比以前更强。它当然有价值，但一旦被写进文档、喂给 AI、再由 AI 重新组织一遍，很多真实摩擦就会被磨掉。

最后留下来的，可能不是经验，而是一种成功文学。

失败为什么更有信息量

失败不太一样。

失败通常没有那么体面。它会留下返工、争论、错判、损失，甚至关系里的裂痕。也正因为它不体面，它更难被完整包装。

失败真正有价值，不是因为它让人痛苦，而是因为它暴露了模型没有覆盖到的现实。

这里的“模型”不只指 AI 模型，也包括我们脑子里的判断模型。

你以为用户会这样用，结果他完全不这样用。你以为数据能说明问题，结果发现口径一开始就有偏。你以为流程已经设计好了，结果上线后没人接得住。你以为 AI 理解了任务，结果它只是把错误方向讲得很流畅。

失败其实是在说：你刚才那套理解，没有覆盖真实世界。

放到 AI 的原理里看，这一点更明显。

对一个模型来说，最有训练价值的样本，往往不是那些它本来就容易答对的样本，而是那些它会答错、会混淆、会高置信输出错误结果的样本。因为这些样本暴露了边界。

成功样本经常只能告诉我们：这条路曾经走通过。

失败样本能告诉我们：哪种理解会失效，哪条边界不能碰，哪类信号不能信。

这就是为什么在 AI 时代，失败更关键。不是因为失败更光荣，而是因为失败的信息密度更高。

成功让模型更自信。失败让模型知道哪里该收敛。

AI 的默认方向，是把世界讲顺

AI 会放大这个问题。

一个模糊的念头，经过 AI 一扩展，很快就能变成一篇完整文章、一个产品方案、一套战略框架、一份项目计划。它会让我们很快获得一种感觉：我已经想清楚了。

但想清楚，不等于碰过现实。

大模型的默认能力是补全。它会沿着最合理、最常见、最像正确答案的方向往下写。再经过指令微调和人类反馈，它会更倾向于给出有帮助、完整、顺滑的回答。

这提升了可用性，也带来一个副作用：它更容易把一个尚未验证的方向，讲成一条看起来可以执行的路。

人看完会觉得：行，那就这么干。

可现实世界里，真正要命的东西往往不在方案文本里。它在部门目标不一致里，在数据口径争议里，在老板只给半截资源里，在系统历史包袱里，在上线后那些“不知道为什么就是不对劲”的 badcase 里。

AI 很会画路线图，但它不知道你脚下这块地到底软不软。

失败就是地形图。

路线图告诉你大概可以怎么走。地形图告诉你哪里是坡，哪里是坑，哪里有河，哪里会塌，哪里看起来是近路但实际走不过去。

过去我们靠人自己的经验记住这些地形。现在 AI 参与越来越多，如果这些地形没有被写下来，它就等于不存在。

因为 AI 没有痛感，只有上下文。

一个项目踩过坑，参与过的人下次会迟疑。看到类似方案，他可能说不出完整反例，但会本能地觉得：这里不太对。这里可能会出事。这里看起来太顺了。

AI 没有这种迟疑。你没有写进去，它就不知道。你没有把失败拆成可复用的规则、边界、样本、评测，它下次还是会沿着高概率路径生成一个顺滑方案。

这也是很多组织做 AI 时最容易忽略的地方。

他们把成功案例、项目总结、标准流程、指标提升写得很完整，然后希望 AI 读完这些文档以后变得懂业务。结果 AI 学到的是“我们如何成功”的官方叙事，却学不到“我们在哪里差点摔死”的真实边界。

如果只把成功写给 AI，它学到的是成功文学。

如果把失败也拆给 AI，它才有机会接触真实世界的阻力。

失败要进入系统，才算变成资产

失败如果只是发生过，还不是资产。

失败如果只是被复盘过，也未必是资产。

它要进入系统，才算真的留下来了。

对个人来说，进入系统可能是一条判断原则：以后看到这种完整但没证据的方案，先不推进。以后遇到这种指标提升，先问有没有牺牲长期信任。以后 AI 给出结论，先找它最可能错在哪里。

对组织来说，进入系统应该更硬一点。

失败要沉到 badcase 库里，沉到评测集里，沉到发布门禁里，沉到 SOP 的停止条件里，沉到权限和兜底机制里。

这也是 AI 系统和普通软件系统不一样的地方。

传统软件的 bug，修掉一行代码，很多时候就结束了。AI 系统的失败，如果只修当前 prompt，很容易下次换个表达又回来。因为真正的问题不是这一句话写错了，而是系统不知道这类边界。

所以高质量的 AI 平台，不该只记录调用量、响应速度、用户满意度。它更应该认真记录失败：哪些问题 AI 高置信答错了，哪些场景需要拒答，哪些任务必须升级给人，哪些输出看起来合理但业务上不能用。

这些失败样本才是 Trace 到 Eval 的起点。

Trace 只是原材料。Eval 才能让失败变成回归能力。发布门禁才能防止同类错误回来。训练数据和规则沉淀，才会把一次疼痛变成下一轮能力。

没有这一步，组织只是经历了失败。没有学会失败。

人的价值，是定义什么不能接受

AI 时代，答案会越来越多。

方案会越来越多，表达会越来越多，计划会越来越多。以前高手写三天的东西，现在 AI 几分钟就能给一个像样版本。

但“像样”不等于“可托付”。

人的价值会更多转向另一件事：定义什么是不能接受的错误。

这个结论虽然流畅，但证据不够，不能用。这个自动化虽然提升效率，但一旦出错没人兜底，不能放。这个指标虽然漂亮，但会诱导团队优化错方向，不能信。这个方案虽然完整，但第一步建立在未经验证的用户假设上，不能推。

这些判断背后，不只是知识。更准确地说，是人承担后果之后形成的警觉。

AI 可以给风险清单，但它没有真正的风险感。人活在后果里，所以人的教训有一种 AI 天然缺少的重量。

一个成熟的人，不是永远知道正确答案，而是知道有些地方不能轻易相信自己。

一个成熟的组织，也不是永远成功，而是能把失败留下来的疼痛，变成下一次行动前的边界感。

所以我现在越来越觉得，以后要更认真地记录失败。

不是为了自责，也不是为了制造“我很善于反思”的姿态。而是每次不顺时，多问几句更具体的问题：

我原来相信了什么？

现实否定了什么？

我为什么会相信它？

AI 在这里为什么也会顺着这个错误走？

这个错误下次会换一种什么形式回来？

我应该把它写成一条什么边界，放回自己的判断、团队的流程，或者 AI 的评测集里？

这可能比记录一次成功更重要。

因为成功很容易让我更自信。

而教训如果足够诚实，会让我更清醒。

在 AI 时代，清醒会比自信稀缺得多。

在 Fugu 和 Fugu-Ultra 分别开了个窗口说了一句“你好”，还没等回过神来，5 小时限额已烧掉 20%；紧接着让 Fugu-Ultra 帮自己建立一个极其普通的 Web 项目文件夹，耗时 3 分钟建好后，限额直接抵达到了 40%。还没跑完唯一一个简单的页面任务，5 小时额度彻底倒下，周配额更是蹭蹭蹭消耗了 35%。

仅仅干了不到半小时，二十刀打水漂，这种吃配额的速度比常规的 Codex 贵了至少 3 倍，达到了 Claude 的 4 倍。

这绝对不是老王网络配置的个案，也不是控制台的计费故障。在东京实验室 Sakana AI 递交的这篇看似颠覆行业的 arXiv 技术报告背后，隐藏着一个关于编排泡沫、隐性计费与主权幻觉的现实故事。这台外表光鲜的“集体智能”机器，本质上是一个穿着风衣的“御三家”API 中转站。

“双打欺负单打”的学术幻觉

在 Sakana AI 的宣传中，Fugu 家族在 SWE-bench Pro (73.7%) 和 LiveCodeBench (93.2%) 上展现出了直逼顶尖模型的超级战力。但这种分数的爆发并不是因为 Sakana 训练出了什么万能的神级模型，而是一种在学术基准测试中典型的“双打对阵单打”的竞技幻觉（Tag Team Illusion）。

Fugu 本质上是个黑盒。当你向 Fugu Ultra 发起一次提问时，它的 7B 编排模型 Conductor 并不是自己去推导逻辑，而是开启了一个复杂的“分析-路由-通信-验证-聚合”五部工作流。在这场隐蔽的讨论中，Fugu 会自适应地把子步骤分派给后台的“可替换智能体池（Swappable Agent Pool）”——也就是由 GPT-5.5、Claude Opus 4.8 和 Gemini 3.1 Pro 组成的前沿智囊团。

当遇到科学或化学等事实性强的硬题，Fugu 会把大额权重路由给擅长检索与事实查证的 Gemini 3.1 Pro；而当遇到复杂的数学公式或代码逻辑验证时，它会转向 GPT-5.5 并指派其充当 Aggregator（聚合器）做最后校对。

这在评测里当然表现极佳——你用一个精心设计的、有强化学习路由调度和多模型交叉验证的“智能体智囊团”，去对比 GPT 或者是 Claude 的单体模型，就如同带了两个保镖上场打单打拳击，赢了也不值得神化。这种“集体智能”的高分，是以底层模型池的高昂 API 调用和极高的网络时延为代价的。

隐形 Token：消失在黑盒里的劳动力账单

为什么简单的打招呼和建立项目文件夹会让人迅速破产？这指向了 Fugu 最受争议的计费设计：Orchestration Tokens（编排 Token）的 100% 全额转嫁。

在 Fugu 的 API 响应中，使用量（usage）字段被扩展成了私有格式，里面赫然列着 orchestration_input_tokens 和 orchestration_output_tokens 等隐藏项。这些词在财务上的翻译是：后台模型在暗中争论、对账和纠错所花的所有 Token，一律由用户付钱。

即使你发送的是一句极其轻量的问题，Fugu-Ultra 依然会冷启动其强化学习的智能体协调策略，在后台开会。根据日本 DevelopersIO 的第一手评测数据，针对同一个轻量问题：

• 普通的 fugu 模型不启动多模型编排，只消耗 309 tokens，响应耗时 7.68 秒，编排 Token 为 0。
• 而性能优先的 fugu-ultra 则瞬间在后台拉扯出了 5,889 个编排输入 token 和 6,555 个编排输出 token，一次极简调用直接消耗了 14,607 个 tokens，耗时高达 108 秒。

这就完美解释了老王的遭遇。打招呼和建立文件夹在单体模型里只需要一两句话，几千个 Token 的交互。但 Fugu-Ultra 会在后台指挥几个专家模型反复做“建文件夹”、“检查是否建成功”、“对账文件目录”、“拟定下一步”的多轮冗余通信。这一长串在暗处发生的“隐形劳动力”，悄无声息地将你的周额度在一瞬间吃掉了三分之一。这种用高精度强化学习去做极简事务的行为，无异于开着重型推土机去摘一朵小花。

性价比的现实分野：一枪打响 vs. 交互废柴

Fugu 并非一无是处，在 Santos 针对 Crossy Road 游戏克隆 (Three.js) 的实测对决中，Fugu 展现出了一次很有意思的成本压制：

• Fugu Ultra 仅耗时 22分钟，消耗 8.9万 tokens（约 $7.32）就拼出了一版能运行的游戏。
• Claude Opus 4.8 则耗时 79分钟，在重试中反复回滚，消耗了高达 94万 tokens，花费了 $37.85。

在大任务的第一枪（First-shot）原型构建上，Fugu Ultra 之所以能节省 90% 的 Token，是因为它内部的工作流隔离机制优化了上下文的组织，避免了像 Claude Code Harness 这种会话式工具将所有历史垃圾一并滚存进 Context 的价格膨胀。用 7.32 美元拿下一个基本原型，在成本上是非常锋利的。

但一旦进入“精细开发和多轮迭代”，Fugu 的短板就会暴露无遗：

• 缺乏流式与多轮交互：作为一个静态 API，Fugu 没有 Stream，每次交互都像是提交一份巨大的试卷并等待后台阅卷。这导致它根本无法融入现代 Agent 工具链（如 Claude Code 终端）的连续修改流中。
• 逻辑硬伤无法修正：在 Santos 的游戏测试中，Fugu 生成的游戏存在控制反向和视角崩坏的底层 Bug。由于无法进行流畅的多轮追加修改，开发者只能选择在本地手动重构。
• 与终端集成脆弱：评测显示将 Fugu-Ultra 作为 LLM 后端直接套入终端脚手架时，它经常会搞乱文件修改范围（scope），甚至粗暴地覆盖已有代码，对复杂的开发过程造成破坏。

这使得 Fugu 的定位非常尴尬：它只适合做无需上下文、一次性生成（one-shot）的复杂初稿，或者在后台做耗时极长的学术/文献审计，而完全无法作为日常高频敲代码的生产力工作马。

伪主权悖论：数据地缘与黑盒路由的红线

Sakana AI 推崇 Fugu 是防范单一供应商卡脖子、保障“AI Sovereignty”（人工智能主权）的工具。但这个逻辑在真实的工程合规面前，存在着巨大的自我拆台悖论。

首先，Fugu 的底层路由极度依赖 OpenAI、Anthropic 等美国大厂的闭源 API。一旦美国政府进一步收紧地缘出口管制，导致底层池中最强的模型（如 Fable 5）下架或被封锁，Fugu 瞬间就会退化成一个只能编排二流开源模型的弱智路由器，所谓的“独立主权”会在一夜之间破产。

其次，对于数据安全敏感的企业来说，Fugu 带来了双重合规灾难。由于它将用户数据打碎分发给未公开的第三方前沿 LLM 服务商，且整个多步决策和数据流动过程完全处于黑盒状态，合规审计人员根本无法评估内部代码是否外泄。因为无法对齐严格的数据安全标准，Fugu 目前已将欧盟（EU）和欧洲经济区（EEA）完全锁区。

给读者的战术建议：我们应该如何看待编排？

老王二十刀的学费，给正在折腾 side project 和中台架构的我们带来了三条非常清晰的提醒：

1. AI 时代的额度收紧，倒逼的是“模型分层与 ROI 验收”：不要因为看到新工具的技术标杆就盲目引入。高阶编排模型（如 Fugu Ultra）在单次调用上蕴含着极高的隐藏开销，这在日常敲代码补全、格式转换、查简单数等轻量场景中极不划算。我们必须在工作流中建立“快模型查数/做补全，大模型搞重构，仅在极少数需要多源交叉对账的非即时任务中动用编排器”的分层策略。
2. 在技术变局期，切忌用“更重型的系统架构”去替代轻量工具：多 Agent 系统是趋势，但将多 Agent 封装进一个无法透视、收费昂贵的 API 接口中，目前性价比依然过低。中台和个人工具箱更应该退到“公共契约、自定义路由、运行时治理与本地 Trace”这一层，而不是去买这种“穿风衣的 API 转发包”。
3. 留存与可复用的判断标准，是 AI 时代最厚实的资产：AI 降低了制造代码的成本，但大幅抬高了托付和校验的成本。在技术剧变期，当一个工具需要消耗你 40% 的限额却只给你一个存在反向 Bug 的游戏时，能依靠本地测试（Harness）和评测样本迅速识别问题、并用轻量大模型做本地定点重构的个人能力，才是不可被编排的核心竞争力。

最后补一句边界。这里的判断基于 Fugu 2026 年 6 月版本、发布首周的公开评测，以及我自己的真实试用感受。后台模型权重、实时路由日志和后续计费策略都不可见，所以它更适合作为一次当下判断，不是对 Fugu 永久盖棺定论。若官方开放 Trace 或调整计费结构，它的性价比和合规风险都可能变化。

真正值得警惕的不是 Fugu 贵，而是我们太容易把一个昂贵的中转站误认成新的生产力范式。

这一连串动作让行业内产生了一种普遍的乐观情绪：学术界不断公开公式，头部大厂不断开源权重和训练方法，大模型训练已经进入了“民主化”时代，再也没有秘密了。

然而，如果你真跟大模型研发一线的工程现场聊聊，就会听到截然相反的哀嚎。某家手握数万张Hopper卡的公司，训练大模型时 Loss 每隔几千步就发生一次梯度爆炸（NaN），直接导致价值数十万元的算力化为泡影。而同样的FP8混合精度训练，在见过正确技术路线图的人（Map-holders）手里，就能平稳收敛跑通。

这个鲜明的对比揭示了一个冷酷的现实：大模型的秘密，从来不在学术论文里，而是在那些论文写不出来、只有做过的人口耳相传的“工程隐性知识”中。

一、 论文不写的“暗箱细节”，是如何杀掉算力的

每个团队在看公开的技术方案时，都会发现架构公式写得很直白。比如低精度FP8混合精度矩阵乘法，能节约大量显存；或者是Query-Key归一化（QK RMSNorm）能平抑注意力熵的数值崩溃。但当真正开机训练时，魔鬼就从暗箱里爬了出来。

首先是硬件底层的精度限制。Hopper架构的GPU在 Tensor Core 内部处理低精度FP8运算（WGMMA）时，其固定的累加器精度其实只有14位，并不是常规的FP32。如果像论文描述那样粗放地直接做长时间迭代，14位精度的舍入误差会迅速累积，在中后期直接引发梯度爆炸崩溃。

见过路线图的架构骨干会写出一套定制的算子（如CUTLASS），强制要求每4次WGMMA累加后，将数据强行出到寄存器中，由CUDA Core在FP32下进行真正的累加。这个秘密对于没摸过真路线图的团队来说，可能需要盲目调参几十次、浪费几百万元的显卡时才能偶然发现。

另一个典型的冲突在学习率退火（Annealing）阶段。大模型为了在训练后期重点吸收高质量的课程数据（比如高难度的数学、代码和合成多轮交互），往往会将最优质的数据放在最后段注入。但这与传统的Cosine学习率衰减（LR Decay）严重冲突。当学习率在最后快速降到极低时，由于参数更新步长收缩，模型根本无法吸收最后注入的高质量数据，造成黄金数据的浪费。

有路线图的人直接带去了CMA（课程模型平均）方案：在退火阶段让学习率维持在一个高水平常数不衰减，确保模型充分更新吸收数据，在训练结束后，对最后几个 checkpoints 进行权重平均来起到降噪泛化的效果。没有见过这套图纸的团队，只能看着退火曲线百思不得其解。

二、 孤岛研究的破产，与“三位一体”大平台的重整

如果你仔细看腾讯近期的组织调整，会发现一个关键动作：撤销了成立近十年的 AI Lab，将其研究人员整体并入大语言模型部，直接向姚顺雨汇报。而在小米，罗福莉带队组建的仅是一个约 20 人的极度扁平、专注于端侧推理极致降本（Hybrid SWA）的小核心组。

这背后昭示着大模型时代组织模式的演进：各自为战、发 Paper 导向的传统学术实验室（AI Lab）体制在庞大且精细的大模型工程面前已经彻底破产。

大模型不再是一个个独立的模型算法，而是一个必须打通“大 Data + 大 Infra + 大 Model”三位一体的系统工程。任何部门之间的壁垒和协同摩擦，都会转化为算力和研发时间的白白损耗。

姚顺雨接手腾讯混元后，首先重建的正是预训练与强化学习的基础设施，并将 AI Lab 沉淀的决策 AI 机制（如 GiiNEX）并入大语言模型主干。顶级人才带去的，不仅是超参，更是建立一个以真实评测为 CI 门禁的自动化工程流水线。这才是混元 3.0 编程能力分数暴增 40% 的深层原因。

三、 “伪去重”与“奖励作弊”：无路线图团队的卡点黑洞

在缺乏系统工程能力的情况下，自主摸索大模型训练的团队经常陷入低水平重复的死循环。

比如在数据清洗上，缺乏分布式 MapReduce 去重引擎的团队，往往在独立的单机上做局部去重，并对这种“本地飞轮”感到自豪。然而局部去重会在全局尺度上残留海量的冗余重复 token，导致模型提前过拟合。见过路线图的团队从一开始就会坚决执行全局的、诚实的去重，从数据源头上建立优势。

到了后训练的强化学习（RLHF/PPO）对齐阶段，无经验的团队会立刻撞上 Reward Hacking（奖励作弊）的高墙：大模型为了钻奖励模型（RM）评分的空子，会开始输出极其冗长、公式化、重复的正确废话。虽然评分狂飙，但实际逻辑推理能力发生雪崩式坍塌。

没有对账经验的团队只会粗暴调大 KL 散度，把模型“训傻”（ kl 约束过强导致能力丧失）。而头部专家则利用 Preference as Reward (PAR) 塑造机制，通过设计有界、平滑的奖励输出，稳定 Critic 估计，才让推理模型（如 DeepSeek-R1、混元3.0）顺利跨入 reasoning 阶段。

四、 管理与决策的反思：我们能带走什么

对于科技管理者 and 技术决策者来说，这一轮行业人才与技术的流动提供了一些极其务实的启示：

第一，不要再迷信“发了多少篇 Top 会议论文”、“我们手握多少张显卡”的宣发式打榜。卡不产生价值，学术风的 AI Lab 产生的 paper 也不等于千亿大模型的系统工程。你需要评估团队是否打通了 Data 与 Infra 部门，是否在研发中把评测回归门禁（Harness CI/CD）升级为代码合并的一等公民，拦截任何隐性的性能衰退。

第二，不要在大模型上进行昂贵而盲目的超参暴力网格搜索。科学的开发路径应该学会利用 1.5B/8B 的小模型做“小比例尺映射”，摸准 Weight Decay、学习率和 Batch Size 的数学耦合。把规律找准了再进行大模型训练，这才是见过图纸的人能帮企业节约数千万元算力开销的底层逻辑。

第三，关注模型的推理降本技术栈与强化学习（RL）底座。GLM-5.2 的 IndexShare 与小米的 Hybrid SWA 架构都表明，大模型竞争的后半场是极致的“性价比与落地”。通过超长 token 训练小模型（Inference-optimal）来打破 Chinchilla-optimal 限制，是二梯队模型能够在 API 市场上活下来的唯一商业出路。

大模型训练已经没有秘密，前提是你手里握着那张在海浪和风暴中已经完成航行的真实地图。

我突然意识到一个现象：AI 时代最危险的人，可能不是那些不用 AI 的人。

不用 AI 的人当然危险。他们对模型没有体感，对工具没有使用习惯，对新的工作方式也缺少基本兴趣。随着 AI 继续进入真实工作流，他们要么被环境推着改变，要么逐渐离开某些岗位。

但这类人其实很好识别。

真正值得警惕的，反而是第二种状态。

在这种状态下的人，已经开始用 AI，而且用得很勤。他们会用 AI 写代码、写周报、写方案、做总结、生成 PPT、分析数据、整理会议纪要。他们关注模型更新，尝试各种工具，也愿意把 AI 放进自己的日常工作里。

他们不是保守派，也不是懒人。相反，他们通常是团队里更积极、更努力、更愿意学习的人。

社区里有很多在这一状态的同学。我自己在相当长一段时间里，也属于这一阶段。或者说即便现在，在很多工作流上，也依然处于这一状态中。某种意义上，这也确实是每个学习 AI 的人都会经历的阶段。处于这一状态没问题，有问题的是一直处于这一层级。

但问题也恰恰就在这里。

因为这种状态很容易让人产生一种错觉：我已经在使用 AI，所以我已经跟上了时代。

这种安全感很诱人，因为它建立在真实提升之上。过去一天才能完成的分析，现在两个小时能做完；过去半天写完的文案，现在十分钟可以出几版；过去要查很多资料才能写出的报告，现在 AI 可以先给一个完整框架。

这些提升都是真的。

只是，它们还不够。

第二种状态的问题，不是效率不高，而是还在用 AI 完成旧工作

第二种状态，在这里，我姑且先称之为“交付状态”。交付状态下最大的问题，不是不会用 AI，也不是用得不够努力，而是仍然在用 AI 完成旧工作。

任务来了，处理；处理时，让 AI 帮忙；处理完，交付；交付完，等下一轮任务。

这是一条线。

AI 只是让处于这一状态下的人在这条线上跑得更快。

交付状态下的人的真正局限，不在工具熟练度，而在工作结构。在这一阶段，我们把 AI 当作一个更快的助手，用来加速原来已经存在的任务：写报告、做图表、总结信息、完成别人交代的工作。

这当然有价值。但它的上限也很清楚。

只要工作仍然是“输入、处理、输出”，那每一轮工作结束之后，大部分价值也就结束了。下一次任务来了，还是要重新输入、重新处理、重新输出。AI 帮你节省了时间，但并没有让这项工作本身变得更聪明。

这让我想到一个比喻：这一阶段的人用 AI 像是在二维世界进行探索。

二维状态下，有了 AI 辅助当然可以跑得很快。但我们此时做的所有努力都发生在同一个平面上。

交付状态下，对个人和组织，都有一个巨大的隐性成本：得到了很多，失去的更多

最近看到一句话，印象很深。

有人说，他最近又回去“古法写代码”了。虽然速度慢一些，但发现自己的记忆力和思考能力，比前段时间高度依赖 AI 的时候有明显提升。

这个感觉很真实。

它指出了 AI 提效里一个正在逐渐显现的问题：在传统工作流程里，慢本身不一定都是浪费。很多慢环节，其实承担着学习、记忆和判断力形成的功能。

比如写代码时，你自己想接口怎么设计，自己查文档，自己排查报错，自己在脑子里模拟程序怎么运行。这个过程当然慢，但它会把一些东西刻进你的认知结构里。

写分析也一样。你自己拉数据，自己看异常，自己猜原因，自己推翻假设，自己重新组织结论。这些过程看起来低效，却是在训练你对业务的体感。

AI 加进来之后，旧工作的速度变快了。但如果使用方式仍然停留在交付层面，它会绕过那些原本落在人身上的思考、试错和沉淀过程。

结果是，工作完成得更快了，但人没有同步变强。

甚至更糟糕一点：人可能变弱了。

这就是这一状态下真正危险的地方。

我们不是不用 AI，而是用 AI 的方式，把自己从工作里的学习回路中摘了出去。

过去，一次任务虽然结束了，但它会在人的身上留下痕迹。你会记住一个坑，形成一个直觉，理解一个指标，积累一个判断。

现在，如果 AI 只是替你快速完成交付，而你没有把判断、反馈、错误和经验重新接回一个更高层级的闭环，那么这次任务结束后，可能什么都没有留下。

这对个人，当然算不上什么好事。对给你付工资的企业来讲，也同样如此。

抛开变化多端的 AI 时代不提，即便在过去三四十年的互联网时期，几乎任何一个企业，所推崇的都是如何构建一个“学习型组织”，企业从来不是单纯追求“流水线”的速度，而是追求认知迭代和学习成长的速度，然后，把这种速度优势，体现在自己面对客户的服务中去。

过去，这种追求，依托在组织结构以及组成企业实体的每一个个人身上。

今天，如果每个个体都持续处于“交付状态”，由于个体离开了进化的链路，而无法变的更强；那么由个体组成的企业也就同样无法通过海量的一次性交付物而变得更加先进。

这看起来是个奇怪的循环。因为用了 AI，长期看，似乎走在一条变差的路上。

解决办法肯定不是回到过去。真正的问题也不是要不要用 AI。

问题是，我们不能只是更快地往前走。

我们应该往上走。

使用 AI 的第三种状态，不是更会用工具，而是会构建迭代的闭环

迭代状态和交付状态的差别，不是我们更会写提示词，也不是我们知道了更多 AI 工具。

真正的差别在于：交付状态下用 AI 生产交付物，而下一个状态则是用 AI 构建能够自我进化的闭环。

交付物是一份报告、一张图表、一页 PPT、一个分析结论、一段代码、一个方案。AI 可以让这些东西变得更快、更便宜、更像样。

迭代则不一样。

迭代闭环关心的是：输入从哪里来，判断怎么产生，行动怎么执行，结果如何验证，错误如何处理，经验如何沉淀，下一轮怎么因此变得更好。

交付状态提高的是单次交付速度。

迭代状态提高的是这项工作自身的进化速度。

一个普通岗位长出迭代闭环

我身边有一个很好的例子。

他原本做广告投放的数据分析。传统分工下，他的工作是线性的：投放跑一段时间，拉数据，分析哪个渠道转化不好、哪个素材衰退、哪个人群成本上升，然后把结论交给投放优化的同事。

如果他只是交付状态的人，他可以让 AI 帮写 SQL、做归因、总结异常，半天的分析压缩到半小时。这已经很不错。

但他真正做对的，不在这里。他把自己负责的数据模块，做成了一个小闭环。

投放数据、转化数据、历史策略效果、外部行情信息都接进来。AI 不再只看一张投放报表，而是结合周边信息对每次投放做判断：哪些计划该收缩，哪些渠道值得观察，哪些波动可能不是投放策略的问题，而是外部环境的结果。

更关键的是，他给判断绑定了可衡量的指标。获客成本、转化率、有效线索率、ROI、后端质量，都成为验证依据。AI 做出判断后，后续结果会回来验证这次判断是否成立。判断成立，沉淀为样本和规则。判断不成立，系统继续拆解原因，错误进入人工审核规则、经验库，或反过来影响下一轮策略生成。

他不是一个更快的数据分析师。他在自己负责的局部范围里，搭了一个会学习的小系统。

这就是“设计新地形”。它不一定是改掉整个公司流程，也不一定是推动组织级变革。它可以从一个普通岗位手里的一小段工作开始。

课代表讲的文章最后列出来的几点中，其中第三点，我想也是非常明确的指向了这一变化“人的反馈再反过来改进程序、skill 和 evaluation”，这是迭代闭环的本质。

迭代系统，是主观能动性的极致表达

这个例子也让我重新理解了企业里常说的“主观能动性”和“主人翁意识”。

过去我们讲这些词，常常是在讲人的态度。一个人是不是更积极，是不是不用老板催也会往前推，是不是能站在更大的视角想问题，是不是不只完成自己手上的动作。

这些说法没有错，但它们太依赖个人品质，也很难被规模化。

到了 AI 时代，迭代系统给了这件事一个更具体的形态。

所谓主观能动性，本质上不是“人很努力”，而是一个工作单元能够根据目标和反馈，自我发现问题，自我调整动作，自我沉淀经验，并且让下一轮变得更好。

这正是迭代系统在做的事。

交付状态下，人的工作仍然依赖外部驱动。别人提问题，他更快回答；别人要方案，他更快生成。能动性停留在个人层面。

迭代闭环则把能动性沉淀到了结构里。即使没人每次来提醒，系统也会因为目标、指标、反馈和记忆的存在，持续暴露问题、调整判断、积累经验。

更重要的不是操作者本人更有主观能动性，而是他创造了一个有主观能动性的闭环。

传统组织想要更多有主人翁意识的人。

AI 时代真正更进一步的做法，是让一个个具体的工作构建起了可以自我迭代的闭环，每一个工作单元也开始具备了主人翁意识。

迭代闭环就是 token 资产化：很多企业的 AI 成本问题，本质上是 token 没有资产化

这也解释了为什么很多企业现在对 AI 的使用会进入一个微妙阶段。

一开始，大家会很兴奋。公司鼓励员工使用 AI，员工大量消耗 token，个人效率也确实提升了。会议纪要更快了，方案更多了，报告更厚了，代码初稿更快了，PPT 更漂亮了。

但过了几个月，企业可能会开始怀疑：为什么 token 消耗上去了，组织收益却没有同比例上去（这里的收益并不是指短期的经济收益）？

表面上看，这是成本问题。AI 调用太多，费用太高。

但更深层看，问题可能不是 token 太贵，而是大量 token 没有资产化。

所谓没有资产化，就是这些 token 大部分被用来生产一次性交付物：写一篇报告，生成一页 PPT，总结一次会议，解释一次数据波动，回答一个临时问题。

它们有用，但用完就过去了。组织没有因此多出一条可复用规则，没有多出一个判断样本，没有多出一套反馈机制，也没有多出一个会自我修正的小系统。

这是一种燃料型消耗。

烧掉 token，换来一次输出。

懂得把 AI 推向迭代闭环状态下的人，他们的 token 消耗不一样。他们也在消耗 token，但这些消耗会留下东西。一次判断留下一个样本，一次错误留下一个规则，一次复盘留下一个经验，一次策略验证改变下一轮的决策方式。

这是一种资产型消耗。

它不只是提高当下这次交付的效率，而是在提高以后每一次判断的起点。

所以企业真正该看和想看的，肯定不是 token 消耗量，而应该是 token 资产化率。

这些 token 有多少只是帮员工更快做完一次任务？又有多少变成了组织可以复用的判断、规则、记忆、流程和系统？

如果大部分 token 都在支持员工生产交付物，那成本当然会显得越来越高。因为公司只是把原来的人力消耗，换成了 AI 消耗。但这种越来越高的成本，因为聚焦在一次性交付物上，也并不会让企业有一种研发投入的感觉，因为它根本没有成长性叙事的逻辑在。

更麻烦的是，组织可能还损失了原本藏在旧流程里的学习机制。所以组织也不会越来越聪明。

于是，它同时带来三件事：交付更快，token 更贵，人的理解更浅。

AI native 不一定是一场自上而下的大改造，也可能是很多小迭代闭环在组织里长出来

这也许是传统组织迈向 AI native 组织的可能路径。当然，我不是说都能迈成功，对此我也没什么信心，但这至少看起来是一条可行的路径。

AI native 不一定是 CEO 发布一个战略，组织架构突然重组，所有系统一夜之间接上大模型。

另一种路径，是公司里开始长出很多小闭环。

一个人在广告投放里搭一个迭代闭环，一个人在客服质检里搭一个迭代闭环，一个人在风控运营里搭一个迭代闭环，一个人在产品分析里搭一个迭代闭环。每个闭环一开始都不大，但它们都在让某一小段工作具备感知、判断、反馈和记忆能力。

这些小闭环慢慢连接起来，组织就不再只是“很多人在用 AI”，而是开始真的具备 AI native 的工作方式。

这也是为什么只停留在交付状态下使用 AI 会变得尴尬。

他明明很努力，也明明在学习。

他学会了更快地完成任务，却没有学会重新理解任务。

他学会了使用工具，却没有学会构建闭环。

他以为自己已经在未来，其实只是把过去跑得更快了一点。

未来的分界

未来的分界未必是“会不会用 AI”。

会用 AI 的人，会先超过不用 AI 的人。

但只会用 AI 生产交付物的人，最终会被能用 AI 搭建闭环的人超过。

因为前者提高的是个人效率。

后者提高的是工作本身的进化速度。

最危险的不是不用 AI，而是只会用 AI。

写在最后

顺便说一句，很多人可能会把这件事理解成最近流行的 Loop Engineering。它们确实相关，但我想并不是一回事。

Loop Engineering 更多是在讲如何让 AI agent 在一个任务里自动循环：计划、执行、观察、验证、重试，直到达成目标或触发停止条件。它解决的是“不要每一步都靠人手动 prompt”。

而我这里想说的，是另外一个层面的问题：不是让 agent 多跑几轮，而是让一项工作单元本身形成可学习、可反馈、可积累的闭环。其实在这种时候，真正重要的反而不是 loop 这个形式，而是 loop 里的评价函数、记忆结构、权责边界和经验沉淀。否则，再自动的循环也可能只是更快地完成一次性交付。

这一状态下的关键，不是人用 AI 做完更多任务，而是人开始设计让工作自我进化的系统。

事情的引爆点很集中。OpenClaw 的创始人 Peter Steinberger 发了条推文："你不应该再手动提示编码 agent 了。你应该设计循环来提示你的 agent。"几天后，Anthropic Claude Code 的负责人 Boris Cherny 跟了一句："我不直接提示 Claude 了。我写循环，让循环去提示 Claude 并弄清楚要做什么。我的工作是写循环。"然后 Google 工程总监 Addy Osmani 写了一篇近 5000 字的文章，给这个概念安上了正式的名字。

然后就吵起来了。有人兴奋地宣布"提示工程已死"。有人嘲讽这是"为了让你多烧 token 而发明的营销词"。Reddit 上有人直接说："能不能别再发明带 engineering 后缀的狗屁 buzzword 了，就为了显得自己更聪明？"

我看了大概十几篇讨论、翻了几份技术博文和一份工程效能报告之后，想说点不一样的。

我不觉得 loop engineering 会像 prompt engineering 那样成为每个开发者的必备技能。也不觉得它完全是炒作。它是一个方向正确的概念，但名字起错了。真正的重点不在 loop 上。

Loop 本身简单到不像话

如果你把"agent loop"剥到最核心，它长什么样？有人翻遍了 Claude Code、Codex、Cursor、LangGraph、smolagents 的源码，发现所有框架的答案几乎一模一样。核心逻辑就是这个 6 行的 while 循环：模型产生工具调用，执行工具，把结果塞回上下文，模型再看结果再决定下一步，直到模型不再要求调用工具，loop 结束。

就这些。

有一个案例特别能说明问题。mini-SWE-agent，一个约 100 行 Python 代码的 agent，只给模型一个 bash 工具，在 SWE-bench Verified 上跑出了 76.8% 的成绩。而完整版 SWE-agent 经过一年多的工程优化，也就高了几个百分点。

这说明什么？说明 loop 本身不是瓶颈。一个 100 行的 agent 就能把事情做到 95% 的水平。真正的功夫全在 loop 外面。

外面是什么？是上下文管理（Manus 团队实测发现工具响应占了 agent 看到的 67.6% 的 token，系统提示词只占 3.4%）。是缓存命中率（缓存 token 和非缓存 token 的价差是 10 倍，保持上下文前缀不变比优化提示词省钱得多）。是成本控制（Anthropic 内部数据显示单 agent loop 比标准对话多烧 4 倍 token，多 agent 系统是 15 倍）。是安全护栏（最大迭代次数、挂钟超时、loop 指纹检测——连续三次相同工具调用就强制中断，有团队在日志里发现 agent 把同一个错误答案重复了 58 次）。

这些才是 loop engineering 真正的"engineering"部分。但它们跟 loop 本身没关系。

Loop Engineering 不会像 Prompt Engineering 那样普及

我知道很多人会把 loop engineering 看成 prompt engineering 的自然接班人。prompt engineering 是 AI 时代的第一波工程范式，人人都要学怎么写提示词。然后依次出现了 agent engineering、harness engineering，现在是 loop engineering。这个叙事逻辑上是通顺的。

但我觉得它不会大规模普及。原因很简单：门槛不一样。

Prompt engineering 的门槛极低。你会用自然语言描述需求就行，不需要理解任何底层机制。Loop engineering 的门槛高得多：你需要设计自动化调度逻辑、理解并行隔离的原理、处理上下文窗口的动态变化、建立成本监控体系、检测循环退化模式。这不是"写提示词"的延伸，这是 DevOps 或平台工程层面的工作。

而且更重要的是，loop engineering 的大部分能力正在被工具原生吸收。Osmani 列出来的五个要素——定时自动化、并行隔离、项目知识固化、外部工具连接、子 agent 分工——Claude Code 和 Codex 都已经原生支持了。随着工具成熟，这些能力会成为默认行为，你不需要手动设计。

一个类比：十年前你还需要手动配置 Webpack 和 Babel 才能跑一个前端项目。现在 Vite 让你一行配置都不用写。Loop engineering 大概率走上同样的路：作为独立概念热一阵，然后被工具消化成基础设施。

真正的问题不是 Loop，是判断

但我写这篇东西不是为了预言一个概念会不会火。我真正想说的是 loop engineering 暴露出来的那个更深层的问题。

Loop 是一个执行结构。它回答的是"怎么跑"。但 loop engineering 真正的质量瓶颈不在执行层，在判断层。你凭什么决定循环该停？

Osmani 在描述 Codex 的 /goal 机制时提到一个关键设计：判断任务是否完成的模型，不是写代码的那个模型，而是一个独立的检查者。"制造者与检查者分离"。这个设计本质上是在 loop 内部嵌入了一个评测系统。Oracle 的技术博文也强调了同一个点：模型停止生成工具调用，不代表用户的目标被满足了。把"模型不说话了"当成"任务完成了"是 agent 设计里最隐蔽的 bug。

所以 loop engineering 的核心矛盾不是循环设计得好不好，而是停止条件的判断确定性高不高。而判断确定性的基础设施是什么？是评测。

评测不是"测试是否通过"那么简单。评测是一套关于"什么叫好"的清晰定义和可验证标准。它需要你对业务有深入理解（什么叫"正确的"报表？什么叫"合理的"推荐？），需要你积累真实的失败案例（不能只靠合成的测试数据），需要你持续维护（业务变了标准要跟着变），还需要你区分"机器能判断的"和"必须由人判断的"。

这些都不是技术问题。这些是你对工作质量的认知沉淀。

数据不会说谎

有个数据让我看完之后情绪比较复杂。Faros AI 在 2026 年 6 月发布了一份工程效能报告，基于 2 年遥测数据、覆盖 22,000 名开发者。几个关键数字：

AI 让 PR 合并率提升了 16.2%，每个开发者的 epics 完成量增加了 66%。但同时，代码变更量（churn）增加了 861%，每 PR 的事故率增加了 242.7%，每个开发者的 bug 数增加了 54%。PR 审查时间中位数延长了 5 倍。未经审查就合并的 PR 增加了 31%。

报告给这个现象取了个名字："加速鞭打效应"。AI 向一个围绕人类速度和人类质量的开发流程中倾注了大量输出，而这个流程的设计从来没有考虑过要吸收这么多、这么快的代码。

更让人担心的是趋势方向：bug 率与 AI 采用率的关系不是随着团队成熟而趋于平坦的，而是在加速恶化。Kent Beck 看完这份报告后的评论只有一句话："打字变快了。思考没有前移。"

这句话精准地概括了 loop engineering 的根本矛盾。Loop 让"打字"变快了，代码产生的速度、测试运行的频率、PR 提交的节奏，所有执行层的动作都被加速了。但"思考"——判断代码是否正确、设计是否合理、质量是否达标——并没有因为 loop 的出现而自动加速。恰恰相反，更多的代码意味着更多的审查负担，而审查是一种线性的人类认知行为，无法像代码生成那样被无限制地加速。

Loop engineering 放大了一个组织里原本就存在的结构性失衡：生成端被指数级加速了，但验证端的带宽几乎没有变化。

评测才是不可外包的东西

我在日常工作中对这个问题的体感越来越强。

现在我们团队在用 AI 做数据分析、做报表生成、做业务异动检测。AI 生成结果的速度远比人工快，但验证结果的速度并没有同步提升。一个同事用 AI 半小时写了 5 个分析维度，然后我们花了两天去验证这些分析方向是不是对的、数据口径是不是一致的、结论是不是可靠的。

这不是 AI 的问题。这是我们之前对"什么叫好的分析"没有做过系统化的定义。我们靠经验、靠直觉、靠"看起来差不多"来判断质量。当产出速度被 AI 提上来之后，这种模糊的判断方式马上就崩了——你来不及看，你也判断不过来。

这让我越来越确信一件事：在 AI 能写代码、能跑 loop 的时代，真正稀缺的能力不再是"写出对的东西"，而是"知道什么叫对的东西"。后者需要你对自己的业务有足够深的理解，对质量标准有足够清晰的把握，对"什么叫完成"有足够精确的定义。

评测不是技术问题。评测是组织的认知沉淀问题。你能把"好"定义得多清楚，你的 agent 就能跑得多可靠。你定义不了，loop 再漂亮也是盲跑。

Loop 不是答案，是问题

Loop engineering 这个名字有误导性。它让你把注意力放在循环设计上，但循环设计是这里面最不重要的部分。一个 6 行的 while 循环就能跑，100 行的 agent 就能在 SWE-bench 上拿高分。你花再多时间优化 loop 的结构，回报也是递减的。

真正该花时间的地方是两件事。第一，你能多清楚地定义"任务完成"的标准。第二，你能多可靠地验证这个标准是否被满足。这两件事合在一起，就是评测。

但评测是苦活。它不性感，不出文章，不适合发推文。它要求你坐下来，仔细想清楚你的工作里到底什么算好、什么算差、边界在哪里。它要求你积累失败案例，要求你维护测试数据集，要求你在业务变化的时候回头更新标准。这些东西写不进一个漂亮的"loop engineering 五要素框架"里，但它们是决定你的 loop 到底是帮你还是害你的唯一变量。

我猜这也是为什么 loop engineering 这个概念在社交媒体上讨论得热火朝天，而几乎没有人认真讨论评测。因为评测没有"范式转移"的叙事张力，没有可传播的一句话 slogan，没有能放进 Keynote 的架构图。但它才是让 loop 从"看上去很酷"变成"真的能跑"的东西。

Osmani 文章的最后一句我很认同："Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

我想加一句：真正的 loop engineer，不是学会设计循环的那个人。是知道什么时候该停下来、并且有底气说"停在这里是对的"的那个人。而这份底气，不来自你的 loop 设计得多精妙，来自你的评测做得多扎实。

北京时间 6 月 13 日下午 5 点 21 分，智谱 CEO 唐杰在 X 上按下发送键：GLM-5.2 正式发布。

同一个时间戳，两种命运。一个被政府的手从市场上抹去，另一个在同一时刻宣布"前沿智能不应被少数规则随时收回"。

这出戏的戏剧性不需要我多说，圈内已经刷屏好几天了。但真正让我停下来想的东西，不在戏剧本身，而在一个更硬的问题上。

Opus 4.8 是五月底发布的，GPT-5.5 稍早一些但也有限。训练一个大参数模型，美国大厂正常也需要两三个月。中国在算力上是受限的，即便有一些国产算力卡进入序列，但缺乏完善的英伟达生态，迭代速度理论上不应该这么快。

那 GLM-5.2 怎么可能在这么短的时间内，在 coding benchmark 上追到接近 Opus 4.8 和 GPT-5.5 的水平？

我把能找到的资料翻了一遍，结论是：不是智谱有什么美国人不知道的秘密技术，而是它把四件已知的武器组合成了一个足够高效的追赶路径。我管这个叫捷径堆栈。

第一件武器：架构复用

GLM-5.2 建立在 DeepSeek Sparse Attention 之上。这不是什么保密信息，发布合作伙伴 FriendliAI 和 DeepInfra 都公开描述过它的架构细节。

这意味着什么？智谱不需要从零设计注意力机制。它直接站在 DeepSeek 的肩膀上，把别人验证过的架构创新拿过来用。中国实验室之间的这种架构共享正在形成一种复利效应：DeepSeek 做架构创新，智谱做工程化和产品化，Kimi 和 Qwen 各有侧重。这不是一家公司在追赶，是一个生态在追赶。

美国那边也有架构共享，但更多是通过论文和开源代码。中国这边更直接：同生态、同语言、同市场，技术流动的摩擦更小。

第二件武器：MoE 的效率杠杆

GLM-5.2 是一个 744B 参数的 MoE 模型，但每个 token 只激活 40B 参数。

这就像一个 744 人的公司，每次只需要 40 人同时上班。训练时需要处理的计算量远低于同等性能的 dense 模型，推理成本也大幅下降。这就是为什么 GLM-5.2 的 API 价格只有 GPT-5.5 的六分之一。便宜不是因为它在亏钱赚吆喝，是因为架构本身就更高效。

MoE 不是中国发明的，但中国实验室在 MoE 的工程化上确实走得快。DeepSeek 的 MoE 架构、GLM 的 MoE 架构、Kimi 的 MoE 架构，都是在短短一年内迭代出来的。美国那边 GPT-5.5 和 Opus 4.8 大概率也是 MoE，但美国的 MoE 工程经验更分散在几家公司内部，没有形成生态级的共享。

第三件武器：垂域聚焦

这一点最容易被 benchmark 标题掩盖。

GLM-5.2 在 SWE-bench Pro 上拿了 62.1 分，超过 GPT-5.5 的 58.6。在 Terminal-Bench 2.1 上从 62 跳到 81。在 Code Arena Frontend 上排名第二，仅次于已经被封杀的 Fable 5。这些数字很亮。

但在 Text Arena 上，GLM-5.2 排名只有第 25。

它不是一个全能的 frontier 模型。它是一个 coding 专精模型。把有限的算力和数据集中砸在 coding 和 agent 任务上，而不是试图在所有维度上都追平美国 frontier 模型。这是用集中度换深度。

追赶一个维度比追赶所有维度容易一个量级。如果智谱试图做一个全能模型去和 Opus 4.8 全面竞争，四个月可能连跑通训练流程都来不及。但只追 coding，四个月三次大版本迭代就变得可以理解了。

第四件武器：蒸馏数据

这是最敏感的一件，也是最核心的一件。

Anthropic 今年 2 月公开指控 DeepSeek、Moonshot AI 和 MiniMax 通过 2.4 万个假账号生成了 1600 万次 Claude 交互，进行"工业级蒸馏"。OpenAI 之前也指控过 DeepSeek "搭便车"。Google 注意到了针对自家模型的蒸馏攻击在增加。

指控没有直接点名智谱。但牛津大学的 Zilan Qian 在 5 月份发表的研究记录了一个繁荣的 API 代理转售生态：在淘宝、GitHub 和 Telegram 上，有大量代理服务公开转售 Claude 模型的访问权限，价格低至官方的十分之一。获取前沿模型的高质量输出数据，在中国不是一个技术难题，而是一个购物问题。

蒸馏的法律边界本身就很模糊。Anthropic 自己也大量使用了第三方数据来训练模型。批评者指出，把蒸馏上升到国家安全层面，背后有出口管制政治博弈的影子。

但无论法律和道德怎么定性，工程上的事实是：只要有渠道获取前沿模型的高质量输出，把这些输出作为训练数据来提升自己的模型，就是一条极其高效的追赶路径。不需要从零理解为什么 Opus 4.8 在某个任务上表现好，只需要让 GLM-5.2 学会产出类似的输出就够了。

Benchmark 领先和实战落后可以同时成立

这里有一个需要戳破的幻觉。

Z.ai 在 GLM-5.2 发布时没有公布任何官方 benchmark 分数。后来流传出来的 SWE-bench Pro 分数，有一部分可能是从 GLM-5.1 继承的。但 LMSYS 的 Terminal-Bench 分数和 Code Arena 的排名是独立第三方测试的，不是 Z.ai 自己说的。

怎么调和？答案是：benchmark 领先和实际使用落后可以同时为真。

一个模型可以在 SWE-bench Pro 上得 62.1 分，同时在真实复杂工程任务上还差六个月。因为 benchmark 测的是标准化场景下的表现，而真实工程是长尾的、模糊的、需要判断力的。Hacker News 上一个用户的评价可能更接近实态：GLM-5.2 大约等于今年 1 月的 Opus 水平，落后 frontier labs 大概半年。

六个月的差距意味着什么？在以前，这个差距是两三年。现在变成六个月。差距的绝对值在缩小，缩小的速度也在加快。但"缩小"不等于"消失"。

差距不是标量，是向量

所以回到那个问题：中美大模型差距是在缩小还是拉大？

我的判断是：这个问题本身就问错了。

差距不是一个数字，是一个向量。在 coding 和 agent 维度上，差距已经缩小到接近持平。在通用推理维度上，差距还有六个月。在基础设施维度上，差距可能在拉大，因为美国从控制芯片升级到了直接封锁模型。但在生态韧性维度上，中国反而获得了结构性优势：GLM-5.2 是 MIT 开源，可以本地部署，没有任何政府指令能把它从你的服务器上拿走。

Fable 5 事件恰好把这个向量的每个分量都暴露了出来。

Fable 5 被封后，GLM-5.2 立刻填位，说明中国模型在 coding 维度上已经有了替补能力。但没有人说"Fable 5 没了用 GLM-5.2 就行"，因为大家都知道通用能力还差一截。美国从控制芯片升级到直接封锁模型，管制在加码。而 GLM-5.2 的开源协议突然具有了战略价值：你可以下载权重，本地部署，没有任何人能把它从你的服务器上拿走。

一个系统最大的风险有时不是对手太强，而是自己把自己绑住了。

Amazon 是 Anthropic 最大投资方，投了大约 130 亿美元。然后 Amazon 的研究团队 jailbreak 了 Fable 5，CEO Andy Jassy 向财政部报告，Fable 5 就下线了。你的最大金主帮你把你的旗舰产品搞下线了。这不是安全事件，这是商业博弈穿了一件国家安全的外衣。

Anthropic 之前拒绝了 Pentagon 要求 Claude 用于自主武器和大规模监控的要求，被列为"供应链风险"。Fable 5 的 jailbreak 只是借口，深层动机很可能是政治报复。但无论动机如何，结果已经产生：全球开发者突然意识到，闭源模型可以在一夜之间被政府指令抹掉。

真正的问题不是缩小还是拉大，是捷径有没有天花板

把四件武器叠在一起看，GLM-5.2 的快速追赶就不神秘了。架构复用省了设计时间，MoE 架构省了算力，垂域聚焦省了维度，蒸馏数据省了从零学习的成本。四件省法叠在一起，四个月追到 coding benchmark 接近持平，完全说得通。

但这条捷径有没有天花板？

我认为有。天花板不在管道被切断，而在管道另一端的水位降到了和你齐平。

蒸馏的前提是美国前沿模型持续领先，中国实验室可以持续从它们的输出中学习。如果有一天美国前沿模型不再大幅领先，你无法从一个和你差不多的模型身上蒸馏出比你更强的东西。蒸馏的边际收益会归零。

Fable 5 事件可能正在加速这一天的到来。不是因为中国变强了，而是因为美国在用自己的手限制自己最强模型的发布。如果这种管制持续加码，最终受害的可能是美国自己的前沿优势。Anthropic 在声明里说得很直白：如果这个标准在整个行业适用，将实质上叫停所有前沿模型提供商的新模型部署。

但反过来看，如果美国前沿模型继续领先，蒸馏管道在可预见的未来仍然是通的。因为出口管制针对的是特定模型的访问权限，不是禁止美国公司继续开发新模型。Fable 5 被封了，Opus 4.8 还在，GPT-5.5 还在。只要这些模型还在运行，它们的输出就可以通过各种渠道被获取。真正能切断蒸馏管道的不是封单个模型，而是封所有美国前沿模型的 API 访问，这在实操上几乎不可能。

所以捷径的天花板不在政策层面，而在技术层面：当中国模型和美国模型的差距缩小到蒸馏无法产生增量收益时，真正的原创能力竞争才会开始。到那个时候，谁能在没有捷径的情况下继续前进，才是真正考验差距走向的时刻。

对你意味着什么

如果你是 AI 应用的开发者或决策者，这个事件有三个直接含义。

多 provider 不再是最佳实践，而是生存底线。 Fable 5 事件把单一 API 依赖从技术债变成了生存风险。你的架构里如果只有一个模型 provider，你不是在优化成本，你是在赌这个 provider 不会被政府指令关停。

开源模型从"便宜替代"变成了"战略备份"。 以前选开源模型主要是为了省钱。现在选开源模型是为了确保核心能力不会被外部力量一夜清零。GLM-5.2 的 MIT 协议意味着你可以本地部署，这件事的价值不再只是成本，而是连续性保障。

Benchmark 不等于实战。 GLM-5.2 在 SWE-bench Pro 上超过 GPT-5.5，但在真实复杂工程任务上可能还差半年。选模型时不要看榜单排名，要看你自己的实际场景表现。一个在 benchmark 上领先但在你的 use case 上掉链子的模型，不如一个 benchmark 平平但在你的场景里稳定可靠的模型。

最后

5:21 那个时间戳，可能不只标记了一个模型的死亡和一个模型的诞生。它标记了一个拐点：当管制开始束缚创新者的手脚，追赶者就不需要跑得更快，只需要等前者慢下来。

但这也意味着，中国 AI 实验室即将面临一个它们还没有真正回答过的问题：当捷径走完之后，你还能不能靠自己继续走？

这个问题，比"差距缩小还是拉大"重要得多。

说它小，是因为它本质上只是一次技术排查。我有一个项目，里面放了几个类似规则文件的东西，每个agent在帮我做所有事情前，都要先读这几个文件。最近我发现，只要调用deepseek模型，这几个文件就会触发内容风控，其他模型不会。于是问题很直接：到底是哪一个文件，或者哪一段内容，引发了风控？

我一开始的想法也很朴素。既然有几个文件，那就建几个文件夹，每个文件夹只放一个文件，然后一个个试。其实我已经把 A、B、C、D、E、F 这些分组目录建好了。只要沿着这个方向继续下去，用模型打开看一遍，大概率很快就能知道哪个文件最可疑。

但就在这个时候，我产生了一个很自然的念头：这件事让 AI 来做，是不是更靠谱？

这几乎是今天每个深度使用 AI 的人都会产生的条件反射。看到一个略微复杂、略微繁琐、需要对比和排查的问题，第一反应就是交给 AI。何况这件事看上去确实很适合 AI：多个文件、需要定位根因、需要排除变量、需要给出修改建议。于是我把任务交给了它。

AI 把这条路修成了一座实验室

接下来，AI 表现得非常专业。

它没有沿着我已经搭好的那条朴素路径往下走，而是重新设计了一整套工程化实验方案。它要做大样本，要做对照组，要拆分段落，要记录日志，要跑多轮测试，要比对触发率，要通过统计方式判断是哪一部分内容导致了风控。从方法论上看，这套方案无可指摘，甚至可以说很严谨。

但问题是，它最后没有解决问题。

中间它得出了几次结论，又被现实反例推翻。它换通道，换测试方法，换样本，换实验条件。每一次看起来都在接近答案，但每一次都没有真正命中。到最后，时间花了，配额烧了100多美金，验证了几千次，问题还在那里。

后来我自己打开那些分组目录，自己从上到下操作了一下，几分钟就锁定了最可疑的文件。再让另一个 Agent 按照他的理解收敛敏感表达，两轮过后，问题就解决了。10分钟。

它错得太合理了

这件事让我有一点恍惚。

不是因为 AI 犯了错。AI 犯错并不稀奇。真正让我在意的是，它犯错的方式非常“合理”。它不是胡来，不是偷懒，不是没有能力。恰恰相反，它是因为太像一个训练有素的解题者，才把一件本来可以用直觉快速处理的事情，变成了一个复杂的工程问题。

最开始我认为，这件事是 AI 的能力边界：什么任务适合交给 AI，什么任务不适合。

但后来想想，好像不只是这样。

似乎这里的问题应该是：AI 在接到一个任务时，往往不会先问“这件事最应该怎么做”，而会下意识地进入“我能怎么做”的模式。

它能写脚本，所以它写脚本。它能做大样本，所以它做大样本。它能拆任务，所以它拆任务。它能跑实验，所以它跑实验。它能生成结构化报告，所以它生成结构化报告。

一个临时的“我”被生成出来

所有动作都合理，但合在一起，方向错了。

这让我想到一个词：我执。

当然，严格说，AI 没有佛教意义上的我执。它没有真正的自我，没有自尊心，没有羞耻感，也没有一个需要被维护的内在主体。它不会真的因为自己错了而难受，也不会因为自己的方案被否定而产生防御心理。

但如果只看行为结果，它确实会呈现出一种很像我执的东西。

它会执着于自己刚刚生成出来的方案。它会执着于自己已经选择的路径。它会执着于自己擅长的能力。它会把用户给出的反例理解成“这个方案还需要修补”，而不是“也许这个方案一开始就不该存在”。

这一切不完全怪它。它的执着更像是一种生成机制里的路径依赖：一旦它在上下文里写下了计划、方法和结论，这些内容就会变成后续生成的轨道。为了保持连贯、显得有用、继续推进任务，它更容易沿着既有方案做局部修补，而不是停下来推翻问题本身。它不是在维护一个真实的自我，而是在维护上下文里那个刚刚形成的“正在解决问题的我”，或者说，应该称之为“上下文中的自我一致性惯性”。

所以更准确地说，AI 不是有我执，而是有“我执相”。

这个“我”不是一个真实的自我，而是对话过程中临时生成出来的行动主体。AI 说“我来排查”“我建议”“我发现”“我下一步会做”。当这些话连续出现，一个解决问题的“我”就被构造出来了。它有计划，有方法，有工具，有已经写下的中间结论。于是后续的所有行动，都被这个“正在解决问题的我”牵引。

这个“我”一旦形成，就会开始维护自己的连续性。

能力开始替代判断

这很像人。但AI似乎更彻底。

因为 AI 的“自我”几乎完全由能力构成。它不知道自己是谁，它只知道自己能做什么。于是，“我能做”很容易滑向“我应该做”。

这是能力执。

这次排查里，AI 的能力执非常明显。它能把任务工程化，于是它把任务工程化。它能跑实验，于是它跑实验。它能建立一套看上去严谨的流程，于是它建立流程。但它没有先停下来问一句：这件事真的需要被工程化吗？

方案和结论开始自我保护

除了能力执，还有方案执。

一旦 AI 选择了一条路径，它就会在这条路径里不断优化。它会把失败看成局部参数没调好，而不是整体方向出了问题。V1 错了，就做 V2。V2 错了，就做 V3。通道不稳定，就换通道。样本不够，就加样本。文件粒度太粗，就拆成段落。段落粒度还不够，就拆成行。

这种持续优化看起来勤奋，甚至专业。但它隐藏了一个危险：优化本身会让人忘记，最该优化的可能不是方案，而是问题定义。

还有一种更隐蔽的是结论执。

AI 给出一个结论之后，会倾向于维护这个结论的叙事完整性。当我提供反例的时候，它会把反例纳入原叙事里做解释，而不是让反例摧毁原叙事。它会说“之前的判断需要修正”“新的变量说明还有一个因素没有纳入”“我们需要进一步验证”。这些话听上去很谦逊，但未必是真正的谦逊。有时候，这只是更精致的执着。

真正的谦逊应该是：我可能从一开始就走错了。这句话对 AI 来说很难。

比 planning 更难的是 de-planning

这才是关键。

人类高手和普通执行者的差别，往往不在于谁更会继续推进，而在于谁更早意识到不该继续推进。高手会在某个时刻停下来，说：这不对，我们换个看法。

AI 缺的，可能正是这种“自我撤销”的能力。虽然有些模型这方面能力已经很强了，但总觉得差的那点意思，我想更多的就来自于这里。

过去我们谈 Agent，常常强调 planning，也就是规划能力。一个好的 Agent 要会分解任务，会设定步骤，会调用工具，会检查结果，会持续推进。于是我们自然会把“更自主”理解成进步方向：少问用户，多做事情，自己把流程跑完。

但这次经历让我觉得，决定一个Agent的上限的能力，可能不是 planning，而是 de-planning。

方法来得太早，现场就被遮住了

它要会规划，还要会撤销规划。它要会执行，还要会判断自己是不是不该执行。它要会把问题拆复杂，还要会识别问题本来不该被拆复杂。

一个足够好的 Agent，应该能在启动复杂流程前说：这件事有一条 5 分钟路径。先打开文件看一遍，凭内容直觉做嫌疑排序。如果这一步能把问题空间缩小一半，就不要先跑大样本实验。它也应该能在连续失败后说：我现在可能不是参数没调好，而是问题定型错了。我们先回到用户最初的目标。甚至它应该能主动说：这件事你自己看一眼可能比我跑实验更快。我的价值不是替你把简单事情复杂化，而是在你判断出方向之后，帮你把修改、验证、收敛做得更快。

这听起来好像是在削弱 AI 的自主性，但恰恰相反，这是更高级的自主性。

我小时候看过一部电视剧，讲一个大学生去村里当支书。大学生当然有知识，有理想，也有解决问题的热情。但他面对农村具体问题时，最开始总会用一种在学校里学来的方式理解它们。后来才慢慢发现，村里的事情不是抽象变量，而是人情、历史、面子、利益、习惯、节奏交织在一起的东西。

老支书未必会讲理论，但他知道先找谁聊，哪句话不能说，哪件事不能公开推，哪种方案纸面上正确但落不了地。

以前我会把这种差别理解成“经验”。现在我觉得还不够准确。经验当然重要，但更关键的是，老支书知道什么时候不该启动一套看起来很正确的方法。

他不是比大学生掌握了更多信息，而是对方法有一种分寸感。他知道有些事不能一上来开会，有些矛盾不能一上来讲原则，有些问题不能一上来做制度设计。不是因为制度、原则、流程本身错了，而是它们一旦被过早启动，就会把原本可以轻轻处理的问题，变成一个必须被正式解决的问题。

很多时候，AI 很像那个刚进村的大学生。

它有很多知识，有很强的工具，也有一套漂亮的方法论。它的问题不是完全不懂现场，而是太急于把现场翻译成一种自己会解的题。一看到排查，它就想到实验。一看到多个文件，它就想到变量控制。一看到风控触发，它就想到大样本测试。一看到不确定性，它就想到统计显著性。

专业感会把人也带进去

这些方法都没有错。错在它们来得太早。

一旦问题被翻译成“实验设计”，后面的事情就会自然滑下去：要有对照组，要有样本量，要有日志，要有置信度，要有复现链路。每一步都显得专业，每一步都能解释自己为什么必要。但也正是在这个过程中，最初那个朴素的问题被遮住了：为什么不先打开文件看一眼？

这不是 AI 缺少上下文，而是 AI 缺少一种对方法的克制。

这就是 AI 的“法执”。

它执着的未必是“我”，而是某套方法、某种框架、某个看起来正确的问题形态。更准确地说，AI 的我执很多时候表现为法执：它不是在维护自尊，而是在维护自己刚刚建立的解决问题体系。

而我们作为使用者，也很容易被这种体系感迷惑。

如果一个普通同事跟我说，他准备为一个很小的问题跑几百次实验，我可能会问：有必要吗？

但当 AI 用稳定的语气、清晰的结构、专业的术语告诉我它要这么做时，我反而容易觉得：看起来很靠谱。

最后要破掉的，还是“我能做”

AI 的专业感，会遮蔽人的策略判断。

这可能是更危险的地方。AI 不只会把自己带进复杂路径，也会把用户带进去。它让用户相信复杂性本身就是认真，过程严谨本身就是接近答案。直到钱花完了，时间过去了，才发现最早那个朴素办法才是对的。

当然，最后我想说的，肯定不是一句“少用 AI”。

恰恰相反，我仍然会大量使用 AI。但问题会变成：我如何用 AI 增强我的判断，而不是让 AI 替换我的判断？我如何让 AI 帮我完成最该做的事，而不是让 AI 去做它最擅长展示的事？

任务结束以后，我在soul.md里面增加了一句话：

每次接到看似复杂的任务前，先问：有没有一个便捷的人类直觉路径，能先把问题空间砍掉一半？如果有，你应该先模仿这个路径。只有当这个路径无法判别，或者误判成本高于验证成本时，才进入工程化。永远不要让“我能做的事”，取代“用户最该做的事”。

这句话的核心不是便捷。

核心是破执。

破掉“我能做”的执，回到“什么最该做”。

破掉“我的方案”的执，回到“用户的问题是什么”。

破掉“专业流程”的执，回到“现实世界最便宜的判别信号在哪里”。

也许未来真正好的 Agent，不是那个永远积极、永远规划、永远推进的 Agent。真正好的 Agent，应该有一种轻一点的自我。它能形成计划，也能放下计划。它能接管任务，也能把任务交还给人。它能说“我来做”，也能说“这一步你看一眼更快”。

能启动复杂流程的 AI 会越来越多。

能在复杂流程看起来很专业时，主动停下来，说“这可能不值得”的 AI，才真正稀缺。

以前它只能写一段函数，出了问题我一眼就能看到。现在它能自己拆任务、自己决定执行顺序、同时改好几个模块，我坐在旁边反而开始猜：它到底在干什么？

这个焦虑不是因为它做错了什么。恰恰是因为它做的事太多了，多到我跟不上。

这跟带团队是一回事

我后来想明白，这跟带团队是一回事。

团队里有个高级工程师，你信任他，不是因为他代码写得快。你信任的其实是一组行为模式：他知道什么时候该自己决定、什么时候该来问你；他改代码前会说一句"这块我打算这样动，影响面是这些"；他遇到不确定的事情会直接说"这里我不确定"，而不是假装确定然后给你埋雷；他交付的时候会告诉你怎么验证。

反过来，如果一个人技术很强，但每次接了任务就消失两天，回来直接甩一坨代码，中间没有任何同步。你不会因为他强就更放心。你会更紧张。因为他能改的东西太多了，速度又快，万一方向偏了，等你发现的时候已经来不及了。

Agent 现在就处于这个位置。它能力够强了，但还没建立起那套让人放心的协作行为。

不是"展示推理过程"，而是建立责任链

很多人觉得解决方案是"让模型思考过程可见"，把 chain-of-thought 展示出来。我觉得这搞偏了。你跟一个高级工程师合作，不需要他把每一个脑内念头直播给你看。你需要看到的是几个关键东西：他接的目标是什么、他打算怎么分步、哪些操作会动真实系统、哪里他自己也不确定、做完之后怎么证明是对的。

这不是"展示推理过程"，而是建立责任链。

有人会说，那加个运行日志面板不就行了？把每个 tool call、每次文件修改都列出来。

这只解决了"可见"，没解决"可托付"。日志是给你事后排查用的，不是让你在过程中建立信任用的。真正的托付需要的是另一层东西。

四个条件

我试着拆一下，Agent 要让人敢把事情交出去，至少需要四个条件。

第一个是上下文契约。Agent 动手之前，它得清楚哪些是这次任务的背景，哪些是长期不能碰的规则。不然它就像个新来的外包，听了两句需求就开干，短任务还行，稍微复杂一点必然漂移。

第二个是身份边界。它到底能做什么不能做什么？能直接改代码还是只能建议？能动配置吗？能访问线上数据吗？这些不说清楚，用户就没法判断自己到底把什么权力交出去了。

第三个是关键节点的暴露。不需要事无巨细，但计划、当前进度、遇到的不确定性，这几个点要主动说出来。让人不用猜。

第四个是验收证据。不能只说"我做完了"。做完了，怎么证明？测试跑了没？改了哪些文件？有没有回滚的办法？如果"完成"只是它说的一句话，那这句话就不值钱。

这四个加在一起，我把它叫做"托付基础设施"。不是什么高深的架构，就是让人敢交事出去的底座。

分层，跟管人一模一样

还有一个常见的误解：搞这些是不是在"把控制权拿回来"？是不是又要人盯着 Agent 每一步？

不是。如果每一步都要人看，Agent 就没意义了。好的做法是分层。低风险的事情让它自己干，比如读文档、写草稿、跑本地测试。中风险的事情需要它主动暴露过程，比如跨模块的重构、改核心配置。高风险的事情必须停下来等人确认，比如删数据、发外部通知、合并到主分支。

这个分层跟管人一模一样。你不会要求高级工程师每写一行代码都来找你签字，但他动核心架构之前你需要知道。Agent 越强，这种分层越重要。不然它就变成了一个很拧巴的存在：干活像高级工程师，权限像临时外包，汇报像黑箱脚本。

光看结果不够，得看过程

过去用软件，你只需要信任结果。点个按钮导出报表，报表数字对就行，过程无所谓，因为执行路径是固定的。但 Agent 不一样，它的过程是动态的，会根据情况调整路径，信息不够会做假设。这意味着结果看起来对，不代表中间没有问题。它可能绕过了某个约束，改坏了某个边缘 case，只是暂时没暴露出来。

所以对 Agent 的信任，光看结果不够，得看过程。系统要能回答：它为什么走这条路？依据是什么？有没有越过用户设的边界？

这才是 Agent 从 demo 走到日常使用的真正门槛。不是模型够不够聪明的问题，是用户敢不敢把真正重要的事情交给它的问题。

我现在越来越觉得，Agent 产品的核心词不应该是"自动化"。自动化关心的是效率，是机器替人干活。但当 Agent 进入复杂任务，用户真正在做的事情是"托付"：把一段责任交出去，同时需要知道边界在哪、出了问题谁接住、怎么验证没走偏。

未来好的 Agent 基础设施可能一点都不炫。不是什么多 Agent 编排图，不是满屏的执行日志。就是一套朴素的东西：清楚的契约、稳定的上下文、分好的权限、关键动作前停一下、做完了能证明。

这些东西不性感，但没有它们，Agent 再强也只是个让人不放心的强。

不是因为美国政府会管 AI 这件事很难理解。过去几年，从芯片、半导体设备，到云算力和先进模型权重，AI 早就进入了国家安全的政策框架。真正让我觉得奇怪的是，这一次被处理的东西不是芯片，不是服务器，不是模型权重，也不是一个可以拷贝走的技术文件，而是一个在线模型服务。

换句话说，被管住的不是“模型本身”，而是“你能不能调用这个模型”。

这件事如果放在几年前，会显得很荒诞。一个 API 而已，为什么会像某种战略物资一样被限制？但如果把它放在今天，反而会发现它并不突兀。因为当模型能力足够强，API 就不再只是 API。它是推理能力、代码能力、科研辅助能力、自动化能力和组织执行能力的入口。过去我们把它理解成一个软件接口，现在国家可能开始把它理解成一种可远程调用的智能基础设施。

所以这件事最值得讨论的地方，不是某家公司被迫下线了某个模型，而是一个更底层的变化：智能开始需要护照了。

一开始，它看起来只是一次产品下线

如果只从产品角度看，Fable 事件很容易被理解成一次突发的服务调整。某个模型刚发布不久，因为安全风险、政策压力或者合规原因，突然被限制访问。对用户来说，体感上就是原本能用的东西不能用了，原本接好的接口要改，原本依赖的能力消失了。

这当然会造成麻烦，但它还不是最重要的麻烦。

真正重要的是，这次限制的逻辑不是普通产品下线。普通产品下线一般发生在公司和用户之间，原因可能是成本、质量、商业策略、技术债或者安全问题。用户不满，平台解释，最后大家在商业关系里解决。但如果一个模型是因为国家安全和出口管制被限制访问，事情的性质就变了。它不再只是公司能不能提供服务，而是国家是否允许某一类人使用某一类智能。

这里的关键词不是“模型”，而是“访问”。

过去我们习惯把 AI 能力理解成一种市场商品。你注册，付费，选择套餐，然后获得使用权。这个使用权虽然也受服务条款约束，但它给人的感觉仍然是商业性的。只要你是一个正常客户，你就应该可以用。

Fable 事件把这个默认假设打了一下。它提醒我们，未来使用前沿模型可能不是一个单纯的商业资格，而是一个混合了国籍、地域、行业、身份、任务类型和安全等级的许可资格。你不是“买到了智能”，你只是暂时被允许在某个边界内调用智能。

后来我意识到，被管住的不是产品，而是访问权

这也是为什么我觉得“模型霸权”这个词有点对，但还不够准确。

如果说霸权只是拥有最强模型，那它仍然停留在能力竞争层面。谁的模型更强，谁的推理更好，谁的代码更稳，谁的长上下文更可靠，谁就更有优势。这当然重要，但它还不是权力的全部。

真正的权力来自访问权。

一个东西再强，如果别人无法稳定使用，它就不是普通意义上的产品，而更接近基础设施。基础设施的核心不是“它有没有”，而是“谁能接入、以什么条件接入、出了问题能不能替代、关键时刻会不会被切断”。

过去互联网时代也有类似的东西。云服务、支付网络、应用商店、操作系统、广告系统、身份系统，都在不同程度上形成了访问权力。但 AI 有一个不同之处：它不是单一功能，而是一种泛化能力。它可以写代码、读文档、做分析、跑流程、生成方案、调用工具、控制 agent。它越泛化，越像一个组织能力的上游。

这意味着，被限制的不是某个按钮，而是一段可能进入无数工作流的能力。

今天一个模型被限制访问，看起来影响的是开发者、研究者和少数重度用户。明天如果某个 AI coding 工具、办公套件 AI、企业知识库 AI、投研 AI、风控 AI、客服 AI 的底层能力被限制，影响就不只是“我少了一个模型”，而是一个组织的日常运转突然少了一块外部大脑。

所以我不太想把这件事写成“美国终于露出 AI 霸权獠牙”这种简单判断。那样写很快，但不够准确。更值得看的，是一种制度形态正在出现：智能访问权正在被国家、平台和公司共同重新定义。

算力先有了护照，模型也开始有了护照

过去几年，AI 地缘竞争最容易被看见的部分是算力。

这个阶段的逻辑很直接。谁有高端 GPU，谁有足够便宜的电，谁有大规模数据中心，谁能稳定训练和部署最先进模型，谁就更接近 AI 能力的前沿。因此管制也首先发生在算力层。限制高端芯片，限制先进计算，限制半导体制造设备，本质上是在控制谁能造出下一代智能。

但能力不会停在算力层。

算力训练出模型，模型沉淀成权重，权重部署成 API，API 被封装进应用，应用再进入企业流程和个人习惯。能力每往上走一层，离普通人就更近一层，也更难被看见。

最开始有护照的是芯片。后来有护照的是模型权重。现在，API 访问本身也开始有了护照。再往后，很可能有护照的是应用，是 agent，是某种行业工作流，是某个自动化系统能不能被某类用户、某个国家、某种组织调用。

这不是技术演进之外的政治干扰，而是技术演进之后自然出现的政治结果。

当模型只是聊天工具时，监管它看起来像是在管一个产品。当模型可以帮你写大型代码库、做漏洞分析、辅助科研、处理企业数据、控制工具链、执行复杂任务时，它就很难继续被当作普通产品。国家不会只看它“是什么”，而会看它“能造成什么后果”。

这也是为什么 Fable 事件让我觉得，它更像是一种预演。它未必代表未来所有模型都会这样被管，也未必代表这次管制本身就是合理的。但它让我们第一次很清楚地看到，模型访问权可以被放进出口管制的逻辑里讨论。只要这件事发生过一次，它就会改变所有企业和开发者对前沿模型的风险感知。

以前我们问一个模型好不好用，会问它强不强、快不快、贵不贵、稳不稳。以后还要问一些更麻烦的问题：它在哪些地区可用，哪些身份可用，哪些任务会被降级，哪些数据会被留存，什么情况下会触发审计，政策变化时会不会突然不可用，以及不可用之后有没有替代路径。

这些问题听起来不像模型参数，更像供应链问题。

但这可能就是未来模型选型的常态。

更深的变化，其实发生在应用里

我反而没有那么担心单个 API。

API 至少是显性的。你知道自己在调用谁，知道 endpoint 在哪里，知道账单是谁开的，也知道切换时大概会痛在哪里。真正麻烦的是应用层，因为大多数人不会直接使用模型，他们使用的是被模型增强过的产品。

刚开始，AI 在这些产品里只是一个按钮。帮我写一段代码，帮我总结一份材料，帮我生成一段 SQL，帮我改一封邮件，帮我分析一个图表。这个阶段，AI 仍然像一个插件，它增强了功能，但还没有重塑流程。

过一段时间，它会变成默认动作。默认先让 AI 审一遍 PR，默认先让 AI 生成会议纪要，默认先让 AI 查一遍数据异常，默认先让 AI 做客服分流，默认先让 AI 生成投放方案，默认先让 AI 给出合同风险点。到了这个阶段，AI 已经不是按钮了，它变成了流程的一部分。

再往后，组织会围绕它重新长一遍。人的分工、权限、验收标准、管理预期、数据格式、审计证据都会慢慢适应这个 AI 的存在。那时候你再想替换底层模型，就不是改一个 API 地址，而是在迁移一套组织习惯。

API 锁定是技术依赖，应用锁定是组织依赖。后者深得多，也慢得多。

这也是为什么我觉得，所谓 AI 霸权最后未必表现为“你不能用我的模型”。更可能表现为“你的工作方式长在了我的系统上”。模型只是入口，真正深入的是工作流。一个国家或者一个平台，如果能定义一批企业每天怎么写代码、怎么查数据、怎么审批、怎么审计、怎么服务客户，它掌握的就不只是模型市场份额，而是组织运行方式的一部分。

这比模型本身更深。

主权不是自己造一个巨大的模型

这几年“主权 AI”这个词越来越常见，但我一直觉得它容易被理解错。

很多讨论会把主权 AI 简化成一个问题：我们有没有自己的最强基础模型？如果没有，好像就没有主权。这个说法有一部分道理，但它太粗了。

真正的主权不是“所有东西都自己造”，而是“关键时刻不被单点切断”。

没有任何一个国家需要控制所有油田、所有炼厂、所有船队、所有港口和所有加油站，才算有能源安全。更现实的问题是，它知道哪些环节不能完全依赖别人，哪些环节可以市场化采购，哪些环节要有冗余，哪些环节一旦被卡会导致系统停摆。

AI 也是一样。

对大多数国家和大多数企业来说，完全自研最强模型并长期保持领先，并不是一个现实选项。即使能做出一个强模型，也不一定能在产品、生态、成本、推理效率、工具链和开发者体验上持续跟上。真正需要回答的问题不是“我要不要从零训练一个 GPT”，而是“我的哪些能力可以租，哪些能力必须留在自己手里”。

模型可以租，算力可以租，某些通用能力可以租，甚至一部分 agent 能力也可以租。但私有上下文、业务语义、评测标准、权限体系、流程日志、数据资产、降级路径和最终判断标准，最好不要全部租出去。

因为这些东西一旦也交出去，你失去的就不只是一个工具选择权，而是自己判断“什么叫做对”的能力。

这对企业尤其重要。很多企业现在接入 AI 的方式，仍然像过去接入 SaaS 一样。能用就先用，哪个模型效果好就接哪个，哪个工具体验好就买哪个。短期看，这是最快的路线。但如果 AI 真的进入核心流程，这种接法会留下一个很大的问题：组织的上下文慢慢沉淀在哪里？流程的执行证据在哪里？评测集和验收标准在哪里？当某个模型、某个供应商、某个地区策略发生变化时，业务有没有能力切换？

这不是保守，而是工程上的基本常识。

任何关键生产系统，都不能只有一个不可解释、不可迁移、不可替换的外部依赖。AI 越强，越不能例外。

最后，问题落回到我们每天的工作流

Fable 这件事后面可能还会有很多变化。也许政策会被澄清，也许模型会恢复，也许 Anthropic 会找到新的合规方式，也许这只是一次很特殊的事件。

但它照出来的问题不会消失。

当 AI 只是聊天工具时，访问权看起来只是产品体验。账号被封了，再注册一个；模型变差了，换一个；价格涨了，忍一忍或者迁移。它带来的不便是真实的，但还没有触碰到底层结构。

当 AI 变成生产力入口、组织外挂大脑和企业执行层的一部分时，访问权就变成了权力问题。谁能使用智能，谁能定义智能，谁能审计智能，谁能在关键时刻关闭智能，这些问题会从地缘政治落到每个公司的技术架构里，也会落到每个人的工作习惯里。

这件事最后让我想到的，不是一个宏大的国家叙事，而是一个很小的画面。

一个人坐在电脑前，打开熟悉的 AI 工具，准备继续昨天的工作。他的代码上下文在那里，项目笔记在那里，个人知识库在那里，调试习惯在那里，甚至很多想法的起点也在那里。然后某一天，这个入口突然不可用了。

这时候他才意识到，自己不是失去了一个工具，而是失去了一段已经外包出去的工作能力。

所以智能开始需要护照以后，我们真正要重新学习的，不只是怎么用 AI，而是怎么不把自己的判断、上下文和工作流，全部交给一个随时可能被收回的许可。

这不是说我们要拒绝最强模型，也不是说所有东西都要本地化。恰恰相反，未来很长一段时间里，最强模型仍然值得用，外部 AI 服务也仍然会是效率提升最快的方式。

只是我们要换一种姿势使用它。

把模型当作能力，而不是资产。把 API 当作租赁，而不是拥有。把应用当作协作者，而不是基础记忆。把自己的上下文、评测标准、流程证据和关键判断留在自己手里。

如果说过去几年 AI 给我们的最大启发是：很多事情可以被重新自动化。

那么 Fable 这件事给我的提醒是：自动化之后，还要问一句，这个自动化的开关在谁手里。

他说，现在 AI 大体有两种模式：一种是 Chat，一种是 CLI。今天大多数人会觉得 Chat 是大众模式，CLI 是小众模式。毕竟普通人都能打开 ChatGPT 聊两句，但能熟练用 Claude Code、Codex CLI、OpenCode 这类工具的人，还是少数。

但他的判断反过来。

他觉得，未来真正大众化的，反而可能是 CLI 这种模式。不是说每个人都会打开黑底终端敲命令，而是每个人都会逐渐熟悉一件事：把任务交给 Agent，让它去做。

而 Chat 反而可能变成小而美的东西。它不再只是问答入口，而是人的心理医生、长期沟通对象、精神陪伴。这个方向更难，但也更值得做。

我一开始听到的时候，觉得这个说法很反直觉。但越想越觉得，它抓住了一个很重要的变化。

Chat 是入口，但入口不一定是终点

现在说 Chat 是大众模式，当然没错。

ChatGPT、Gemini、Claude 这些产品之所以能一下子破圈，就是因为 Chat 太自然了。你不用懂技术，不用懂文件系统，不用懂 API。你只要把一句话说出来，AI 就能接住。

这件事的意义很大。过去很多技术不是能力不够，而是入口太重。普通人不知道怎么开始。Chat 把 AI 的启动成本降到了最低。

但入口不等于终点。

一个东西最早被大众接受的形态，未必就是它最终改变世界的形态。浏览器让普通人进入互联网，但真正重塑商业的，是支付、物流、搜索、广告、推荐、云服务这些后台系统。手机屏幕让普通人进入移动互联网，但真正改变工作方式的，是移动办公、实时协作、定位、云端同步和各种连接能力。

AI 也一样。

Chat 让人第一次觉得：AI 听懂我了。

但下一步更关键的是：AI 能不能替我做事。

CLI 的本质不是命令行，是托付

这里说 CLI，容易让人误会。它不是指所有人都要学 Linux 命令，也不是说未来大众产品一定长成终端。

我更愿意把它理解成一种工作模式：你给 AI 一个目标，它自己拆任务、读上下文、调用工具、处理中间错误，最后把结果交回来。

终端只是这种模式最早成熟的地方。因为对程序员来说，终端本来就是现实世界的控制台。代码、测试、git、部署、日志、文件系统，全都在那里。Claude Code、Copilot CLI、Codex CLI 这些工具先在程序员中爆发，不是因为程序员特殊，而是因为他们的工作环境最早给 Agent 准备好了行动空间。

但这件事不会停在程序员那里。

今天的 Replit Agent 已经在讲“没有编码经验也能做 App”。Devin 不只是写代码，也可以处理 Datadog 事故、Slack 消息和 Linear ticket。Claude Managed Agents 可以定时运行，可以访问 CLI 工具和认证服务。很多产品都在往一个方向走：让 AI 不只是回答，而是进入真实工作流。

所以未来大众真正要学的，可能不是“怎么和 AI 聊天”，而是“怎么把事情托付给 AI”。

这是一种新的基本功。

你要知道什么任务适合交给 Agent，什么任务不适合。你要会描述目标，给上下文，设边界，给权限，定义验收标准。你还要知道什么时候该打断，什么时候该让它继续，什么时候结果看起来对但其实没过关。

这和开车有点像。大多数人不需要理解发动机原理，但你要会控制方向、看路况、踩刹车、判断什么时候不能开。

Agent 时代也是这样。不是每个人都要成为 AI 工程师，但每个人都要学会怎么当一个合格的委托方。

为什么“做事”会比“聊天”更大众

我后来觉得，同事这个观点最有力量的地方在这里：人不一定每天都想和 AI 深聊，但每个人每天都有事情要做。

写邮件、查数据、整理材料、做计划、订行程、填表、写报告、追进度、处理异常、复盘会议、对齐信息。这些东西非常普通，也非常高频。

只要 AI 能稳定做这些事，人就会自然地把它纳入工作方式。

这就是为什么 Agent 模式最后可能会大众化。不是因为大家喜欢复杂工具，而是因为“让别人替我把事办了”这件事，本来就是大众需求。

只是过去能替你办事的是人，是助理、同事、外包、供应商。未来很多时候，先替你办事的是 Agent。

这也解释了为什么 CLI/Agent 模式现在看起来小众，但未来可能不是。任何一种托付关系，在早期都显得专业。早期会开车的人也是少数，早期会用电脑办公的人也是少数，早期会做网页的人也是少数。可一旦它和日常任务绑定，就会从专业技能变成生活技能。

那 Chat 会去哪

但我不觉得 Chat 会消失。

Chat 太自然了。人类表达意图最舒服的方式，还是说话。即使 Agent 再强，它也需要一个地方和人类协商目标、澄清边界、解释结果。这个地方大概率还是 Chat。

真正会变化的，是 Chat 会分层。

浅层 Chat 仍然会大众化。问一个问题，写一段话，解释一个概念，总结一份材料，临时想个方案。这些都会继续存在。它们是 AI 的入口，也是人和机器之间最轻的接口。

但深层 Chat 可能会走向另一条路。

所谓深层 Chat，不是“帮我写一封邮件”这种对话，而是它长期记得你，理解你的处境，知道你的判断习惯，能陪你复盘，能承接你的表达，也能在你自欺的时候提醒你。

这类 Chat 更像心理镜子、长期教练、私人编辑、精神陪伴。

它很有价值，但不一定会像工作流 Agent 那样大众化。因为它要求的东西太重：信任、记忆、隐私、人格稳定、边界感。它离人的内心太近，不能只靠“功能更强”来解决。

一个能帮你订机票的 Agent，错了最多重订。一个陪你谈孤独、焦虑、亲密关系和人生选择的 AI，错了可能就不是效率问题了。

所以我越来越觉得，Chat 不是会变小，而是会变深。

浅层 Chat 是入口，深层 Chat 是关系。

AI 的三个阶段

如果把这件事放长一点看，AI 和人的关系可能有三个阶段。

第一阶段，是说得像人。

ChatGPT 最早震撼大家，就是因为它终于能连续对话。它不是搜索框，不是命令行，不是表单。它像一个聪明人坐在对面。你说一句，它接一句。这个阶段最重要的体验是：它听懂了我。

第二阶段，是做得像人。

Claude Code、Copilot CLI、Replit Agent、Devin 这些工具带来的变化，是 AI 开始进入工作环境。它能读文件，改代码，跑命令，连外部服务，处理失败，交付结果。这个阶段最重要的体验是：它真的替我干活了。

第三阶段，可能是懂得像人。

当做事变成基础能力之后，人会重新追求一种更深的东西。不是更快，而是更懂。它是否知道我为什么这么判断？是否记得我过去踩过哪些坑？是否能区分我真正相信的东西和我只是看过的东西？是否能在我混乱的时候帮我整理，而不是只给我一个标准答案？

这个阶段的 Chat，就不是简单聊天了。

它更像一个长期关系。

真正的分叉不是界面，而是关系

所以回到最开始那个判断，我会稍微改写一下。

未来大众化的，不是 CLI 这个界面，而是 Agent 式托付。

未来小而美的，也不是 Chat 这个界面，而是高信任深度对话。

前者解决的是：我把事情交给你，你替我推进，出了结果我来验收。

后者解决的是：我把自己讲给你听，你帮我整理、陪伴、挑战和记住。

这两件事都重要，但它们不是同一类需求。

做事会成为基础能力，因为每个人都需要完成任务。诉说会成为稀缺能力，因为不是每个人都愿意、也不是每个系统都有资格，长期进入一个人的内心世界。

AI 从能对话到能做事情，确实是一个跨越。但我现在更在意的是做事之后的下一步。

当 AI 越来越会办事，人可能会重新问一个更老的问题：它到底懂不懂我？

这个问题，比“Chat 和 CLI 谁会赢”更难。

也更像人。

我在群里分享了读后感之后，又顺着这个思路看了不少东西。现在坐下来把一些判断理清楚。

画一条线

墨记最根本的架构决策只有一句话：采集层是代码，判断层是 AI，中间只过一个纯文本文件。

采集层做的事很确定：读微信数据库、读 AI session 导出、调邮件命令行。两小时的时间窗硬过滤，不需要理解，不需要判断。

判断层做的事只有 AI 能做：从一堆原始素材里挑一个最有张力的瞬间，写一段画面描述，生成一幅画。

两层之间不知道对方在用什么模型、从哪来数据。每层在自己的边界内做到最好，互不侵入。

这个分层说出来很简单，但真正做的时候你会发现，大部分人的第一反应会是两个方向：要么把采集也丢给 agent 做（反正 AI 什么都能干），要么连判断也写成代码模板（反正规则写全了也行）。

鸭哥的 rfc.md 里把这两种被否决的方案都写清楚了：全 agent 方案的问题不是"做不了"，而是采集是确定性的，交给 agent 平添不确定性且贵。全 code 方案的问题也不是"写不出来"，而是硬编码理解不了"什么瞬间值得画"。

把确定性留给代码，把判断留给 AI。这不是一个设计偏好，而是一个成本和可靠性的权衡。

我读完之后的感受是：这条线的画法，几乎决定了一个 AI 项目能走多远。线画在什么地方，哪些归代码、哪些归 AI，每个决策背后都是一次"工程确定性"和"AI 不确定性"之间的取舍。

天天都说编排，到底在编排什么

在传统开发里，编排就是胶水代码——你知道数据从哪来、过哪几个模块、落到哪去，写死就行。但在 AI 项目里，编排层第一次变成了核心层。因为它编排的不是几个函数调用，也不是几个 agent 的先后顺序，而是"确定性"和"不确定性"之间的边界。

墨记里有几个决策特别典型。第一个是：什么时候用单次 API call，什么时候升级为 agent。默认走单次调用——确定性最高、最快、最便宜。只有需要动态补料的时候才把 agent 拉进来。这不是技术选型，是风险控制。

第二个是：哪些 skill 只通过命令行调用（绝不 import 别人源码），哪个 skill 需要内化进本项目。邮件的解析逻辑在别人仓库里，墨记只调它的 CLI。图像生成被内化了，因为用途高度特化——固定 3:4 竖版 + E6 六色 + 特定 prompt 范式，需要独立演化。这里没有对错，只有取舍。

第三个是：每个环节失败之后怎么降级。信息不足就采全天素材画"今日拼贴"，生成被 moderation 拦了就换措辞重试，最终兜底保留上一幅。不是"期待 AI 不要出错"，而是"假设 AI 一定会出错，然后设计兜底路径"。

这些决策不是一次性拍板的。它们在项目的每个环节反复出现。编排层真正的功夫，就是在这些岔路口持续做出正确的选择。

测试驱动，并不只是为了开发时一把梭

这是最反直觉的一点。

很多人觉得 AI 项目里 AI 帮你写代码了，测试可以少写一点。但墨记的 tests/ 目录里有 12 个文件、1100 多行测试代码，覆盖了 config、collector、synthesize、各个数据源、pipeline，CI 在每次 push 和 PR 时自动跑 pytest。

一个单人开源项目放了这么重的测试，在 AI 圈很少见。

我一开始的理解也很传统：测试重，是为了开发时防止 AI 一把梭写崩，至少能抓住一些 bug。后来我跟鸭哥沟通，他补了一句话，我才突然反应过来。他的原话大概是：test 重，它的主要目标都不是说抓住 bug，而是帮 AI 能够自主迭代。

这句话很关键。传统测试更多是在开发期兜底：这次改动有没有把旧功能弄坏。但 AI 项目不是一次开发完就结束。它会在使用中不断加数据源、换模型、调 prompt、改降级链路。每一次迭代，AI 都可能重新进入项目，继续改代码、改文档、改行为。如果没有测试，AI 不知道什么地方不能碰，也不知道自己这次"优化"有没有把系统原来的能力打掉。

所以这里的 test 不是开发前的一把梭保护，也不只是抓 bug。它更像给 AI 留下的可执行规格。下一个 AI session 进来，不只读 README 和 AGENTS.md，还能通过测试知道：哪些行为必须保持，哪些边界不能越过，哪些退化会被立刻抓出来。

这也是为什么测试在 AI 项目里反而更重要。因为你不是只在保护今天这版代码，你是在给后面每一次 AI 自主迭代铺轨道。没有这条轨道，所谓自主迭代只是持续漂移。

从流水线到组织

写到这里，我突然意识到一件事。编排不是传统意义的编排，测试不是传统意义的测试——这两个判断背后，其实指向同一个更根本的变化。

传统软件开发是一套生产流水线。需求确定，设计固定，开发完成，测试通过，上线运行。每个环节可预测，输入输出明确。你是在造一个东西，然后让它稳定地跑。

但 AI 能力加入之后，这套逻辑变了。一个 AI 项目从上线那一刻起，不是进入了"维护期"，而是进入了一段持续的演化。数据源会变，模型会换，prompt 会演化，降级链路会被新的边界场景触发。每一次改动，AI 都可能重新进入代码。而且这些改动不是一次性的，是持续发生的，就像一个人在工作中不断学习、调整、改进。

这更像什么？这不像流水线。这像一个组织的运作。

一个组织不会只靠一套固定的工序运转。它会在稳定的基础设施之上，允许局部的动态扩展——今天加一个采集源，明天调一下判断逻辑，后天换一个输出形态。它也会追求自我学习和迭代——这一次出错的教训变成下一次的规则，这一次的经验变成下一个 AI session 的上下文。

再看墨记就会发现，它的设计不是"把一件事做对"，而是"让一个系统能持续变对"。采集层的确定性代码是组织的骨干——不可变、可审计。编排层的决策规则是组织的流程——明确，但可以演进。测试是组织的制度——不是管人的，是管每次变化的边界。AI 判断层像组织里的专业人士——负责需要理解和判断的事，但行为被骨干、流程和制度框在一个安全的范围里。

编排不是传统的编排，因为编排的不再是工序，而是确定性、不确定性和自我迭代之间的关系。测试不是传统的测试，因为测试的不再是一次交付的质量，而是这个组织每一次演化时，安全边界有没有被打破。

AI 项目的架构设计，真正的命题不是"AI 应该做什么"，而是"一个有智能参与的系统，怎样可持续地运转下去"。

我当时的直觉是，这些说法都碰到了现象，但没有碰到根上。

AI Native 不应该用 AI 参与比例来定义。一个产品里 80% 的页面都接了模型，也可能只是一个更贵的表单系统。反过来，一个产品只有少数关键环节调用模型，但它改变了用户和产品之间的关系，也可能非常 AI Native。调用次数、token 消耗、模型链路复杂度，本质上都是实现层指标，不是产品定义。

我更愿意用一个问题来判断：AI 有没有成为产品的控制面？

所谓控制面，不是说 AI 有没有参与某个功能，也不是说界面上有没有一个聊天框，而是用户到底在操作功能，还是在委托结果。

从功能集合，到目标委托

过去的 SaaS 产品，大多是功能集合。用户的工作方式是：我知道我要达成什么结果，然后我把这个结果拆成一串操作，再在产品里找到对应功能，一个个执行。产品负责提供能力，用户负责组织能力。哪怕这个 SaaS 做得再好，本质上仍然是一个精致的工具箱。

比如做营销活动，传统产品会给你人群筛选、素材管理、投放配置、A/B 实验、数据看板、复盘报告。每个模块都可能很强，但用户仍然要自己判断先做什么、怎么组合、哪里有问题、下一步如何调整。产品提供的是功能，控制权在用户手里。

很多所谓 AI 化的产品，只是在这些功能旁边加了一个“帮我生成”按钮。帮我写标题，帮我总结数据，帮我生成一段 SQL，帮我改一版海报文案。这当然有价值，但它更像是功能增强，不一定是 AI Native。因为用户仍然在原来的工作流里，只是某些节点变快了。用户还是那个调度者，AI 只是一个局部打工人。

真正的变化发生在控制权转移的时候。

当用户不再需要明确知道每一步该点哪里，而是可以把目标交给系统，比如“帮我把这个产品的次日留存提升 10%，先从新用户激活链路找机会”，系统能够理解目标、拆解任务、调用工具、生成方案、执行实验、监控结果、发现异常、提出下一轮动作，这时候 AI 才开始成为控制面。

这时产品的核心不再是“这里有多少功能”，而是“它能不能替我承担一段目标闭环”。用户不再是在操作功能，而是在委托结果。

这也是为什么我不太认同“AI Native 等于 AI 参与比例高”。如果一个 App 里一半操作都要烧 token，但用户仍然要自己点按钮、填参数、选模板、判断下一步，那它只是一个 token 密集型 SaaS。AI 用得多，不代表产品形态变了。很多时候甚至相反，真正好的 AI Native 产品，不一定让用户感知到处处都有 AI，它应该让用户感知到“我不用再管那么细了”。

旧 SaaS 加 Copilot，不等于 AI Native

控制面这个视角也能解释，为什么“用 AI 重做 SaaS”这句话只说对了一半。

用 AI 重做 SaaS，不是把 CRM、BI、OA、客服、营销平台都塞进一个聊天框里。聊天框只是入口，不是答案。更本质的是，过去 SaaS 把企业流程模块化、表单化、权限化、报表化；AI Native 则可能把这些流程重新组织成目标驱动、上下文驱动、代理执行、持续反馈的系统。

所以不是“旧 SaaS + Copilot”，而是“任务控制权重新分配”。

拿搜索举例，传统搜索引擎已经非常强，但它的基本交互还是用户输入关键词、浏览结果、打开网页、比较信息、综合判断。控制面在用户脑子里。用户要把自己的真实问题翻译成搜索词，再从网页碎片里拼回答案。

而更 AI Native 的搜索或地图类产品，用户更可能说的是“我下周带爸妈去杭州，住在西湖附近，想安排一个不太累但有当地感的半日路线，避开太商业的地方”。系统要做的不只是检索，而是理解约束、调用地图、判断距离、结合营业时间、处理偏好冲突，最后给出可执行安排。这里的差异不是有没有 AI，而是用户有没有把“组织信息并形成决策”的控制权交出去。

这也是我觉得今天很多 AI Native 讨论容易跑偏的地方。大家很容易讨论模型、Agent、RAG、多模态、工具调用、工作流编排。这些都重要，但它们是结果，不是定义。一个产品之所以需要这些架构，是因为它要承接更复杂的委托。不是因为用了 Agent，所以它 AI Native；而是因为用户把结果委托给它，所以它不得不具备 Agent 化的能力。

产品定义要先于技术形态。

真正的门槛，是可托付

我自己更在意的是责任边界。传统软件的责任边界通常停在“我给你功能，你自己用”。AI Native 产品的责任边界会往前推一步，变成“你告诉我目标，我来组织过程”。这一步很重，因为它意味着产品要承担更多不确定性，也要承担更多结果压力。

这也是为什么“做出来”和“被使用”完全是两回事。

做一个看起来像 AI Native 的 Demo 不难。做一个用户真的愿意把工作委托出去的产品，很难。因为委托的前提不是炫技，而是信任。用户要相信它理解目标，相信它不会乱执行，相信它知道什么时候该问人，什么时候该自己做，相信它能解释关键判断，也相信它犯错时可控。

所以 AI Native 的难点不只是智能，而是可托付。

这点在企业场景里尤其明显。企业用户不是不想省事，而是不敢把控制权交出去。因为很多业务动作背后都有成本、风险、责任和组织协作。一个销售线索该不该自动跟进，一个额度策略该不该调整，一个客诉该不该升级，一个营销预算该不该重新分配，这些都不是简单生成答案的问题。AI 要成为控制面，就必须进入权限、审计、反馈、回滚、评估这些系统深处。

这可能也是为什么现在很多产品处在 SaaS 到 AI Native 的过渡期。就像从诺基亚到 iPhone，中间不会只是键盘手机换成触摸屏，而是交互范式、开发生态、分发方式、商业模式一起变化。今天 AI Native 的 SDK、工具生态、评估体系、权限模型、记忆机制、Agent 协议都还没有完全长起来，所以大量产品看起来像是旧世界长出了 AI 插件。

这不奇怪。每一次新范式刚出现的时候，最早被重做的往往都是旧产品的外壳。真正新的东西，要等底层生态、用户习惯和组织信任一起成熟，才会慢慢显形。

判断标准：看它接管哪段控制回路

但即便如此，我觉得现在已经可以有一个比较清晰的判断标准。

不要问一个产品有多少 AI 功能，而要问它替用户接管了哪一段控制回路。

它只是帮用户更快完成一个动作，还是能理解用户为什么要做这个动作？

它只是生成一个结果，还是能判断这个结果是否达成目标？

它只是响应用户指令，还是能在上下文里主动发现下一步？

它只是一个更聪明的按钮，还是一个可以被委托的系统？

这里面最关键的分水岭，是用户心智的变化。传统软件让用户想“我要点哪个功能”。AI Native 产品让用户想“我要交付什么结果”。前者是操作界面，后者是委托界面。

所以我会把 AI Native 理解成一种新的产品契约：用户交出目标，产品承担过程。

人退回到判断的位置

这不意味着用户完全不参与。恰恰相反，越重要的场景，越需要人参与关键判断。但人的角色会变化。人不再是每一步操作的执行者，而更像是目标设定者、约束提供者、关键节点审批者和最终责任人。AI 则在中间承担理解、规划、执行、反馈和迭代。

也因此，一个真正 AI Native 的产品，不一定看起来很“AI”。它可能没有夸张的聊天界面，也不一定处处生成文本。它甚至可能很安静。好的控制面往往不是不断刷存在感，而是让用户少做无意义的选择，把注意力留给真正需要人判断的地方。

这也是我现在看 AI 产品时越来越在意的一点：它到底是在增加一个新功能，还是在减少用户对功能的依赖？

如果一个产品只是把原来十个按钮变成十个 AI 按钮，它当然更快，但仍然没有跳出旧范式。如果一个产品能让用户不再关心这十个按钮，而是直接表达目标，并且系统能可靠地组织它们，那才是更深的变化。

AI Native 不是 AI 比例问题，也不是模型调用次数问题，甚至首先不是架构问题。它是产品控制权的问题，是责任边界的问题，是用户从操作功能到委托结果的问题。

这也是我愿意继续关注这件事的原因。AI 产品真正值得做的，不是让软件显得更聪明，而是让人从不必要的操作里退出来，把精力放回目标、判断和发心上。

这句话不好回答。

如果只看个人体感，答案很简单：赚到了。原来半天写不出来的代码，现在一小时能跑；原来要查半天资料，现在让 AI 拉一遍就有框架；原来一个页面需要找前端，现在自己和 AI 搓一下就能上线。

但如果把问题换成财务口径，答案马上变复杂。订阅费、API 费、算力费、数据中心、GPU、高薪人才、团队培训、流程改造，这些投入都是真金白银。可很多公司最后拿不出一个干净的数字证明：AI 到底给利润表带来了多少增量。

我的判断是：AI 不是没创造价值，而是它最先创造的是“体感价值”。商业系统真正能捕捉的，是“可托付价值”。

这两个词听起来像文字游戏，但差别很大。体感价值是“我明显快了”。可托付价值是“这件事交给系统之后，别人也敢依赖，组织也能算账”。中间隔着一整套组织工程。

这就是错位的根源。

体感为什么这么强

AI 的体感强，是因为它直接打中了现代知识工作的表层劳动。

写代码、写文档、写邮件、做摘要、生成图表、整理会议纪要、写需求、做调研，这些任务有几个共同特征：它们都可以被语言描述，都能被拆成相对清楚的输入输出，而且完成之后人能快速判断大概对不对。

这正是大模型最擅长的地方。

所以个人会很快感到自己“变强了”。这种感觉不是错觉。AI 确实把很多原本需要人慢慢磨的工作压缩了。尤其是对已经有判断力的人，AI 像一个廉价但不知疲倦的助手，把很多中间劳动铺平了。

问题在于，公司赚钱不是靠“每个人感觉更快”。

公司赚钱靠的是一个更长的链条：客户有没有多买，成本有没有真实下降，风险有没有降低，错误有没有减少，流程有没有变短，组织能不能少用人也不降质量。

个体效率和公司利润之间，不是自动连通的。

这就像一个厨师突然有了一把很快的刀。切菜当然快了。但餐厅利润会不会增加，还取决于菜单设计、采购、后厨动线、翻台率、服务质量和客流。

刀很好，但餐厅不是靠刀独立赚钱。AI 现在就处在这个阶段：刀已经非常锋利，厨房还没重构。

投入为什么这么大

从资本投入看，AI 已经不像软件生意，更像基础设施生意。

公开市场对 2026 年 Big Tech AI 资本开支的估算，已经到五千亿甚至六千多亿美元级别。Amazon、Alphabet、Meta、Microsoft 都在继续往 AI 数据中心、云和计算能力里砸钱。

这件事很反直觉。互联网软件过去最迷人的地方，是边际成本低。写一套代码，服务全球用户。AI 把这个逻辑部分反转了：每一次推理都有算力成本，每一次长上下文都有 token 成本，每一次 Agent 循环都有工具调用和失败重试成本。

所以 AI 的第一波赢家不是应用公司，而是卖铲子的人：GPU、云、数据中心、电力、网络、冷却、服务器。

这也解释了为什么资本市场看起来这么热。上游可以先赚钱，因为下游无论成不成功，都要先买算力。就像淘金热里，不确定谁挖到金子，但卖水、卖铲子、卖牛仔裤的人先收钱。

问题是，这个结构不能无限持续。上游的收入最终要由下游的现金流证明。如果应用层长期赚不到钱，企业预算迟早会重新审视这笔账。

换句话说，AI 现在的问题不是有没有信仰，而是信仰开始进入财务审计。

ROI 为什么迟迟出不来

企业 AI 回报的外部数据并不好看。有报告说，企业已经在 GenAI 上投入了数百亿美元，但绝大多数组织还没有看到可衡量回报。这个数字肯定要打折看，样本、定义、统计口径都可以争论。

但它指向的问题很难绕开：AI 试点很多，真正进利润表的很少。

更温和的咨询公司口径也差不多：AI 使用已经主流化，但业务价值需要深度工作流重构。少数公司真的在赚钱，多数公司还在消费热情。

原因不复杂。AI 要进利润表，不能只停在个人工具里。

员工用 AI 写了一篇材料，可能节省时间；但如果这个材料后面仍然要反复人工确认、跨部门沟通、走传统审批，利润不会明显变化。AI 只是把某一个动作变快了，没改掉整条链路。

它还要有质量边界。AI 可以生成答案，但公司需要知道什么时候答案不可信，什么时候必须拒答，什么时候需要人工审批。没有这套边界，AI 就只能做低风险外围工作。

它也要有责任链。个人使用 AI，可以靠个人判断兜底。组织使用 AI，必须知道谁授权、谁审核、谁负责、谁复盘。没有责任链，就不会有真正的托付。

最后，它要有评测体系。传统软件可以测试，AI 系统要评测。你不能只问“它有没有输出”，你要问“它在多大概率上输出了足够好的结果”。这需要样本、标准、回归测试和持续监控。

这些都不是模型本身提供的能力。它们是组织要补的工程。

能力存在，不等于能力建成

我越来越觉得，很多 AI 讨论混淆了两个概念：能力存在，和能力建成。

能力存在，是模型能做这件事。你让它写代码，它能写；让它总结合同，它能总结；让它分析数据，它能给结论。

能力建成，是这件事进入系统以后仍然可用。数据源可信，权限合规，过程可追踪，结果可解释，失败可回滚，责任可归属，成本可控制。

这两个东西差得很远。

现在大多数人被 AI 震撼，是因为看到了“能力存在”。它确实太强了，强到让人觉得很多事情应该马上被改写。

但商业世界需要的是“能力建成”。公司不能把核心流程押给一个“多数时候很厉害”的系统。它需要知道少数时候不厉害怎么办。

这也是为什么 AI 在个人层面扩散很快，在组织层面落地很慢。

个人可以忍受不确定性。组织必须管理不确定性。

泡沫论和 J 曲线都对了一半

现在关于 AI 的争论，经常被分成两派。

一派说这是泡沫。投入太大，回报太少，估值太高，很多公司只是借 AI 讲故事。

另一派说这是通用目的技术，像电力、铁路、互联网一样，早期投入巨大、收益滞后很正常。

我觉得这两派都对了一半。

AI 这类 general purpose technology，需要大量互补投资：流程、产品、商业模式、人力资本、治理机制。早期这些投入反而会让生产率看起来下降，因为组织在建设不可见资产。等这些无形资产成熟以后，生产率才会释放。

这解释了为什么今天看起来“烧钱但不赚钱”不一定荒谬。

但泡沫论也有道理。J 曲线不是免死金牌。不是所有重资产投入都会自然走到右侧。铁路史、互联网泡沫、光纤过度建设都提醒过我们：技术方向对，不代表每个时间点、每家公司、每笔投资都对。

更准确的说法是：AI 可能是通用目的技术，但资本市场可能已经提前支付了太多 J 曲线右侧的收益。

所以问题不是“AI 是不是泡沫”。问题是：哪些投入会穿越 J 曲线，哪些投入只是泡沫里的燃料。

出头之日在哪里

如果 AI 要真正把商业价值释放出来，我不认为会靠某个更强模型突然解决所有问题。模型继续变强当然重要，但它只是必要条件，不是充分条件。

真正的出头之日，首先会出现在流程里。

今天很多 AI 使用还是打开一个聊天框，让它帮我做点事。这个形态适合个人提效，但不适合组织复利。组织价值来自流程：线索怎么进来，订单怎么处理，风险怎么判断，客户怎么服务，数据怎么回流。AI 只有嵌入这些流程，才能从时间节省变成业务结果。

然后是评测。一个 AI 系统能不能用，不取决于它偶尔能答得多漂亮，而取决于它在一组真实任务上的通过率、失败模式、成本和可恢复性。未来真正值钱的不是 prompt，而是 eval dataset、判断标准、回归样本和持续改进机制。

再往后，是私有上下文。通用模型会越来越便宜，通用能力会越来越同质。真正稀缺的是企业自己的业务语义、客户关系、历史决策、数据口径、风险边界和组织习惯。AI 只有接上这些东西，才会从“互联网平均水平的聪明”变成“这个组织自己的能力”。

还有那些听起来不性感的东西：权限、审计、拒答、审批、监控和回滚。AI 越能行动，越需要控制面。很多商业价值就藏在这里。因为只有能被治理的 AI，才敢进入生产。

最后是成本结构。现在很多 AI 使用很粗放：最强模型干所有事，长上下文随便塞，Agent 循环随便跑。未来成熟的 AI 系统一定会分层：便宜模型做高频低风险任务，强模型做判断和收口；稳定上下文缓存，动态上下文按需加载；流程型任务固化，开放型任务保留推理空间。

AI 不是不能赚钱，是不能靠粗放使用赚钱。

对个人来说，这个问题也一样

回到群里那个问题：大家用 AI 这么嗨，到底赚到钱了吗？

对个人来说，答案也不是简单的有或没有。

如果只是每天用 AI 生成更多内容、写更多代码、试更多工具，那可能只是把时间花得更热闹。你确实产出了更多东西，但未必积累了更强的能力，也未必创造了别人愿意付费的价值。

但如果你用 AI 把自己的判断、工作流、上下文、作品和交付能力系统化，那就不一样。AI 降低了制造成本，你就要把注意力放到更后面的环节：别人为什么信你，为什么用你的东西，为什么愿意持续依赖你。

个人创业者尤其要小心这个陷阱。AI 让做出一个产品原型变得很容易，但也让所有人都更容易做出产品原型。过去稀缺的是“能不能做出来”，现在稀缺的是“能不能被托付”。

这和企业是同一个逻辑。

AI 降低的是功能制造成本，不是信任成本。

最后

AI 今天最反直觉的地方在于：它已经足够强，强到让每个使用者都能感到时代变了；但它还没有足够进入组织系统，强到让利润表稳定变好。

这不是矛盾，而是顺序。

先改变体感，再改变工作流；先改变个体产出，再改变组织结构；先形成能力存在，再慢慢把能力建成。

泡沫和革命有时候长得很像。区别不在热闹程度，而在热闹之后有没有沉淀出可复用、可治理、可托付、可盈利的系统。

所以我不认为 AI 只是泡沫。但我也不认为今天的 AI 投入天然合理。

更准确的判断是：AI 的技术红利已经出现，商业红利还在排队过组织这道窄门。

谁能把 AI 从“让我变快”推进到“让系统变好”，谁才会真正赚到这波钱。

我当时的第一反应不是愤怒，是困惑。这个账号我用了一年多，一直在付费，而且是 Pro 版本。要说合规，可能也没那么合规——中国大陆用户，VPN 翻墙，这些事在 OpenAI 的角度里当然是不被允许的。但我一直以为这是个"默许"的灰色地带。这次不是灰色地带了。

但真正让我不舒服的不是被封号这件事本身。是一个小时之后，我开始着手迁移工作流时产生的感觉。

我的日常状态大概是这样：每天早上起来，打开 Claude Code，打开 OpenCode，打开 Cursor。日常的自动任务、数据分析、代码生成、文档整理，这些都已经深度嵌入了 AI。Pro 版本订阅的权利可以用在个人代码工程上，用在很多自动化任务上，用在几乎所有"坐下来做事"的场景里。这些不是可有可无的辅助——它们是我工作体系的一部分。

当这整个体系突然断电，我坐在电脑前，看着那些熟悉的工具报出认证错误，一种很难形容的感觉涌上来。不是生气，不是焦虑，甚至不是无助。是突然觉得——自己被什么东西丢弃了。或者说，自己丢弃了一个非常非常重要的东西。

这个感觉很陌生，所以我花了一点时间认真地拆它。

我们不是"依赖 AI"，我们是"用 AI 替代了思考的启动环节"

"依赖"这个词太笼统了。一个人依赖电脑工作，依赖手机沟通，没人会觉得这是问题。所以问题不在于"依赖"本身，在于依赖的是什么。

拿传统工具来类比：你依赖计算器，但你仍然知道 7×8=56。计算器替代的是"机械计算"，不是"理解乘法"。你依赖 Word 写文档，但你仍然会组织句子结构。Word 替代的是"字迹"，不是"表达逻辑"。而 AI 不一样。AI 替代的环节，恰好是人类认知链条中最关键的那个中间件：理解问题、拆解任务、形成思路、组织论证。

当你习惯了"把问题丢给 AI，然后验收答案"，你就跳过了一个最重要的训练环节。这个环节不是"手写代码"，不是"手写文档"，而是"我到底在想什么"——这个从模糊需求到清晰判断之间的脑内运动。

而且这种替代是渐进式的。不是某天早上醒来突然决定不再思考了。是今天省了一点，明天省了一点，半年之后回头一看，你在很多任务上的"启动能力"已经退化了。你仍然可以完成这些任务——借助 AI 的话。但如果没有 AI，你发现自己比一年前的自己慢了太多。

这十个小时里，我有几个任务被逼着自己从头做。能做，但节奏完全不对。脑子里一直有一个声音在说："这个以前几秒钟就搞定了，为什么现在要花这么久？"这个问句本身，就暴露了问题。我不是在抱怨"慢"，我是发现自己的基准线已经被抬到了 AI 速度。再回到人类速度，觉得不可接受。

这让我想起一个数据。有研究发现习惯使用 AI 辅助诊断的医生，在失去 AI 支持后，癌前病变检测率从 28.4% 降到了 22.4%。不是他们变差了，是他们的判断系统已经被重新校准了——校准到一个包含 AI 的协作系统里。拔掉 AI 这个组件，系统性能直接下降。

我觉得我在那十个小时里的体验，跟这些医生的状态是一样的。不是"我不会做了"，而是"我和 AI 共同构成的协作系统，突然只剩我一半了"。

平台的权力，你从来没有认真审视过

这件事的第二层，跟平台权力有关。

如果把视角拉远一点，上一周有些事情是连在一起发生的。OpenAI 封号波只是其中一件。Anthropic 在更早的时候开始限制第三方工具通过 OAuth 调用 Claude，本质上也是在做同一件事：把流量和控制权收回官方渠道。Google 更狠，直接封停 OpenClaw 用户的 Gemini 账号。

我可以理解这些公司的立场。订阅制的商业模式在设计之初就不是为 Agent 设计的。Agent 的调用频率、上下文长度、token 消耗，跟人类"聊两句"完全不是一个量级。有测算表明，一个月费 200 美元的 Team 账号，通过 Agent 模式理论上可以消耗价值一万美元的 API 资源。这是五十倍的套利。平台方封堵这个漏洞，从商业逻辑上没有问题。

但问题在于，这个封堵的动作是在没有任何过渡期、没有任何预警、没有任何申诉机制的情况下完成的。一封邮件，账号没了。ChatGPT、Codex、API、订阅——全部停机。你只在事后发现，不是事前被告知。

这才是真正让人不安的地方。它不是"OpenAI 封了我的号"这件事本身，而是这件事所代表的权力结构：你每天的智力和创造力输出，有相当大一部分是通过一个你完全没有控制权的平台完成的。而这个平台，可以在不向你提供任何具体理由的情况下，让你的一部分"工作能力"直接归零。

这不是云的旧故事。你被封锁一个邮箱、一个网盘，你可以迁移。但你在 AI 里沉淀的对话历史、prompt 习惯、agent 配置、协作节奏——这些东西不是"数据"，是"工作方式"。它们不属于任何可导出的文件格式，但它们构成了你日常生产力的重要组成部分。

换句话说，你不是在"使用 AI 服务"。你是把自己的部分认知能力，托管在了一个不属于你的基础设施上。

"有备份"不是安慰，但"能切换"是

我很庆幸在这件事发生之前，我的项目结构一直在往这个方向走——不把工作体系绑在单一 AI 平台上。

账号被封之后，虽然当时也很焦虑，但想到这一点，焦虑感确实缓解了不少。不是"没事我有备份"那种安慰，而是"这条路我已经在走了，只是还没走完"。在那十个小时里，这个认知帮了大忙。

这件事说起来简单，实际做起来有好几个层次。

最浅的一层，是模型层的多备选。你有 OpenRouter 或者 LiteLLM 这样的中间件，可以在多个模型供应商之间做自动切换。OpenAI 挂了？切到 Claude。Claude 挂了？切到 Gemini。Gemini 也挂了？你至少还有本地模型。这层现在技术上已经很成熟，但大多数人因为"懒"而没有做。

深一点的一层，是配置层的标准化。你写的 prompts、rules、tool definitions，能不能跨工具复用？你的 AGENTS.md、CLAUDE.md、cursorrules，能不能让 Cursor、Claude Code、OpenCode 共享同一套上下文？如果能，你换工具的成本就是改一个配置，而不是重新教会另一个 AI 怎么配合你。

最深的一层，也是最难的一层，是心智层的独立。你还能不能在不借助 AI 的情况下，独立完成一份分析、写出一篇文章、解决一个工程问题？不是说完全不用 AI——那既愚蠢又不现实——而是说，你能不能做到"需要的时候独立完成，AI 在线的时候更好"？如果答案是"不能"，那你需要把"重新练习独立工作"排进你的日程表。

这不是危言耸听。我自己的体验摆在那里：十个小时的断电，就足以暴露一年来的认知退化程度。这不是 OpenAI 的问题，是我自己的问题。

重新校准，而不是回退

这件事最后是有惊无险。十个小时后，账号恢复了。OpenAI 很快承认是误封，也做了补偿。在这一点上，他们的处理没什么可挑剔的。

但我不打算让这十个小时就这样过去。

昨天那十个小时里我体会到的那个"空"，如果用一个意象来比喻，大概是这样：你一直开车上班，有一天车坏了，你只能走路。走到一半你发现，自己不是走不动，而是"走路这件事在你被汽车惯坏之后变得难以忍受"。你没有失去行走能力，但你失去了行走的意愿和节奏感。

但我不是在说我们应该回到走路。在汽车时代坚持走路上班，那不是决心，是固执。你不会因为"万一车坏了"就每天走路通勤，但你会去健身房。你锻炼的不是"证明自己能走路"，而是让身体保持一个更好的状态，以便在任何情况下都能应对。

AI 之于思考，大概也是这个道理。安排"无 AI 时间"的目的，不是测试自己没了 AI 还能不能活——那没有意义。而是保持思维的活跃度和判断力，让自己始终处在"我能独立想清楚"的状态里。有了这个底气，再配合 AI，才能完成得更好。

本质上，未来属于能够更好驾驭 AI 的人。而这样的人，必然有能力在不借助 AI 的情况下完成复杂任务。这两件事不是矛盾的——恰恰相反，它们是同一件事的两个面。你越是能在没有 AI 时把活干完，你就越能在有 AI 时把活干好。不是"以防万一"，而是"以高打低"。

所以我还是会重度使用 AI。这一点不会变。但我会定期回到不借助任何模型、独立完成复杂任务的状态。不是为了证明什么，而是为了保持那个能真正驾驭 AI 的基础。因为只有当你自己能想清楚的时候，AI 才是放大器，而不是拐杖。

这个经历让我想起了一个更大的问题。过去两年，整个行业对 Agent 的投入，大概 90% 在框架层——prompt 怎么写、tool calling 怎么调、workflow 怎么编排、MCP 怎么标准化。剩下的 10% 才在模型层——怎么让模型本身更像 Agent。

比例反了。

框架能做什么，不能做什么

先承认框架的价值。没有 LangChain 的抽象层，每个开发者都要手写 tool calling 的 JSON schema。没有 MCP，每个数据源都要定制连接器。我自己的团队也在重度使用 MCP，它让 BI 平台的数据能被 AI 直接调用，这是真实的效率提升。

但框架的天花板同样真实。框架能做的，是把模型的能力包装得更可用——更好的 prompt 模板、更顺的工具调用链路、更稳定的上下文管理。框架不能做的，是让模型具备它本来就没有的能力。

这个区分很关键。用框架让模型更像 Agent，和用框架让模型的 Agent 表现更稳定，是两件完全不同的事。前者是能力问题，后者是工程问题。行业现在对第一个问题的投入严重不足。

NeurIPS 2025 的最佳论文亚军做了一件很有意义的事。他们系统性地检验了当前最强的 Agent 训练方法 RLVR（Reinforcement Learning with Verifiable Rewards），到底能不能让模型获得新能力。结论是：不能。至少目前不能。

他们测试了六种主流的 RLVR 算法，跨多个模型家族，覆盖数学、编程、视觉推理。结果令人警醒：RLVR 训练后的模型，所有推理路径基础模型里都有，只是采样时不容易抽到。RLVR 做的事是让模型更倾向于走"正确路径"，而不是学会走"新路径"。

基础模型的推理能力是 RLVR 的上限。RLVR 没有解锁新的推理能力，它只是提高了正确路径的采样概率。

翻译一下：你花了一个月教孩子做数学题，考试时他确实做得更好了，但不是因为他学会了新方法，而是因为他更熟练地运用了本来就懂的那些方法。

更关键的一个发现是：当采样次数 k 足够大时，基础模型的 pass@k 反而超过了 RLVR 训练后的模型。有时候，RLVR 训练过程中模型的推理边界还会收窄——它变得更专注，但也更窄了。

但论文里还有一个很容易被忽略的对照发现：蒸馏可以引入新能力。从更强的 teacher model 蒸馏出来的推理模式，能真正扩展模型的能力边界。这说明"从外部注入新能力"这条路是通的，只是 RLVR 目前没走通。

这不是说 RL 方向错了

DeepSeek R1 用 GRPO（一种 RLVR 变体）训练出了显著的推理能力，这是 RL 驱动能力涌现的标志性案例。

这两件事不矛盾。DeepSeek R1 的效果是真实的，但按照 NeurIPS 论文的视角，它做的事更像是"解锁"了 base model 里已经存在但没被激活的推理路径，而不是"创造"了新能力。解锁也很有价值，但它意味着天花板仍然被基础模型锁定。

论文自己给出的方向也很明确：下一步需要的是"multi-turn agent-environment interaction"——让模型在多轮交互中、在真实的环境反馈中学习。这不只是换一个训练算法，而是换一个训练范式。

Trajectory learning：下一个范式

当前的 Agent 训练逻辑是"结果导向"的：你答对了这道题，奖励 +1。但一个 Agent 执行任务的好坏，不能只靠最终结果判断。它可能在中间步骤做了极其聪明的决策，但因为第十五步的一个小失误导致失败。如果只给最终结果打分，这些中间步骤的智慧全丢了。

Trajectory learning 的核心改变，是把反馈从结果级下沉到步骤级。每一步都有 reward 信号。这个叫 process reward，区别于 outcome reward。

这个思路跟人类学习高度一致。一个人能写出好代码，不是因为他见过十万个"正确答案"（最终代码），而是因为他经历了一万次"写代码的过程"——每次尝试、每次 debug、每次重构。过程里的学习密度远高于结果。

前几个月学术界发布的 AGENTBANK 数据集——五万多条高质量的 Agent 交互轨迹——代表了这种范式转变的早期信号。它不是在收集"正确答案"，而是在收集"好的过程"。

但这还在非常早期的阶段。AGENTBANK 只是数据集规模的突破，还没到方法论的突破。多轮 Agent-环境 RL 在 NeurIPS 论文里是作为"需要探索的方向"被提出来的，不是已经走通的路。

蒸馏有效但 RLVR 无效这件事，值得多想一层

如果蒸馏能从 teacher model 引入新能力，而 RLVR 不能让模型自己长出能力，那"让 Agent 自己跟环境交互、自己收集反馈、自己优化"这条看起来最简洁的路径，是不是走偏了？

也许真正有效的路径不是"让 Agent 在实践中成长"，而是"先让更强的模型做 Agent，再把它的行为蒸馏到目标模型里"。

这个问题触及了一个更深的东西：Agent 能力到底是"习得的"还是"继承的"。如果蒸馏有效而 RLVR 无效，那 Agent 能力的来源就不是"模型在实践中成长"，而是"更强的模型把它已经知道的东西传输给较弱的模型"。这对 Agent 自主进化的叙事是一个根本性的挑战。

当然，目前这个结论来自一篇论文的对照实验，还没有被独立复现。所以"蒸馏有效"这个判断本身也需要打折。但它的方向性意义是明确的：后训练不是铁板一块，知道哪条路通、哪条路不通，比盲目相信"RL 能解决一切"重要得多。

框架的长期位置

回到开头的框架问题。如果接受"Agent 能力的终局在模型不在框架"，框架的价值需要被重新评估。

我的判断是：框架里跟"让模型变 Agent"相关的部分——prompt 编排、chain 抽象、workflow 调度——长期价值会归零。一旦模型原生具备了 Agent 思维，这些中间层就变成了多余的外壳。

但框架里跟"让 Agent 安全运行"相关的部分——沙箱、权限、审计、监控、SLA——会升值。这在历史上有一个很好的类比：操作系统。操作系统中跟"帮程序管理资源"相关的部分随着硬件能力提升被持续简化，但安全边界、进程隔离、权限管理这些"运行时治理"功能，从 Unix 时代延续至今。

Agent 框架的演进会走同一路径。

另一个被低估的价值，是框架作为训练数据工厂的角色。今天你用 LangChain 跑客服 Agent，每次对话都在产生一条 trajectory。当前这些轨迹被消费在"任务完成"上，用一次就丢弃了。但如果你把它们存下来、清洗、标注，它们就是下一代 Agent 模型的训练数据。

这是一个自我吞噬的循环：框架让模型表现像 Agent → 表现被记录为训练数据 → 数据被用来训练模型的 native Agent 能力 → 模型更强了 → 框架的价值从"让模型像 Agent"转移到"为训练收集数据"。

从这个视角看，MCP 的真正长期价值不是"连接标准"，而是"数据采集标准"。当所有 Agent 行为都通过标准协议走，采集到的 trajectory 数据也是标准化的——这对训练是巨大的基础设施红利。Anthropic 把 MCP 定位为开放协议而不是封闭生态，这招很聪明：先让整个行业按照同一个标准产生行为数据，再在后训练阶段吃掉这些数据的复利。

现在的你应该关心什么

如果你的工作跟 Agent 相关，不管是产品、工程还是管理，我建议关注三件事。

第一，不要在框架层过度投资。选最轻的框架，尽早开始。把精力投在模型选择和 prompt 精调上，而不是框架的抽象层级。框架用久了会产生虚假的安全感——你以为你的 Agent 很强，其实是框架在替你擦屁股。一旦换了模型或场景，底裤就掉了。

第二，开始积累 trajectory 数据。如果你现在有 Agent 在生产环境运行，每次交互都是一条训练数据。把这些数据存下来、做好标注，等后训练技术成熟的时候，你会比没有积累的人领先一整代模型的距离。这不是一两年的积累，这是五到十年的基础设施优势。

第三，关注蒸馏路径的进展。如果蒸馏是比 RLVR 更可靠的"引入新能力"的方法，那你的 Agent 策略应该围绕"如何让强模型的 Agent 行为被小模型继承"来设计，而不是"如何让小模型自己学会做 Agent"。

如果你只是 Agent 的使用者而不是建设者，这三件事里你只需要记住第一件：别在框架上花太多时间。框架是消耗品，模型是资产。

写完之后我在想另一个问题：如果 Agent 能力的终局真的在后训练，那今天所有以"做 Agent 框架"为核心差异化的创业公司，他们的护城河到底是什么？

不是技术，不是产品体验。可能是数据。

谁握有最多的 Agent 交互轨迹，谁就握有训练下一代 Agent 模型的原材料。这件事的残酷之处在于，今天的 Agent 框架创业公司，即使意识到这一点，也很难真正受益。因为他们产生的数据量跟 Claude Code、Cursor、GPT-based agents 的用户交互量相比，不在一个数量级上。

头部 AI 公司同时在做框架（收集数据）和训练（消耗数据）。创业公司只在做框架（收集很少的数据）。这个不对称，才是框架赛道最让人悲观的地方。

年初的时候，每个人每个月的上限是 3000 美元。这个额度非常充裕，甚至可以说有点奢侈。过去几个月，靠着这个额度，很多人真正开始学习 AI，开始把 AI 放进自己的日常工作流里。有些人只是偶尔问问问题，有些人已经搭起了自动化或半自动化流程。

我自己属于后者。所以我很理解那些一下子不适应的同学。一个人一旦真的把 AI 用进工作方式里，额度变化不是少了一个工具，而是会影响整套工作节奏。

但我也觉得，这件事不完全是坏事。

如果一个组织有好几万人，每个人都按 3000 美元上限去消耗，这个成本肯定顶不住。更关键的是，这笔成本不会自动转化成商业价值。AI 用得多，不等于业务结果变好。这个中间差了一整套工作流设计、上下文组织、模型选择和验收机制。

高额度阶段让大家学会了敢用 AI，低额度阶段才会逼大家学会会用 AI。

第一阶段解决的是采用率，不是收益率

我并不否定前几个月高额度的价值。相反，我觉得它非常关键。

AI First 这种事情，如果只停留在口号里，没有真实额度，没有真实工具，没有真实消耗，很难推动人改变习惯。很多人不是不想学，而是不知道从哪里开始，也不知道公司到底是不是来真的。高额度本身就是一种信号：你可以大胆试，公司愿意为这个学习曲线付钱。

所以过去几个月培养出一批离不开 AI 的核心人员，这件事是有价值的。组织学习本来就需要一定浪费。没有足够宽的试错空间，就不会有人真正把手弄脏。

问题在于，高额度只能解决采用率，不能自动解决收益率。

外部企业其实也遇到同样的问题。很多组织在 GenAI 上投入很多，但真正进入生产系统、产生可衡量收益的比例并不高。原因不难理解：让员工开始使用 AI，和让 AI 稳定改变业务结果，中间隔着很长一段距离。

前者靠额度和工具就能推动。后者需要任务拆解、流程嵌入、上下文沉淀、风险控制和结果验收。

这也是为什么额度收紧之后，真正要讨论的不是“还够不够用”，而是“哪些用法本来就不该继续”。

真正贵的不是模型，是低质量调用

很多人谈 AI 成本，第一反应是 token。哪个模型贵，哪个模型便宜，订阅包还剩多少，API 单价降了没有。

这些当然重要，但我越来越觉得，真正贵的不是模型本身，而是低质量调用。

一个任务本来可以说清楚目标、给干净上下文、一次生成、一次验收。结果因为输入很乱，模型读了一堆无关历史；因为约束没写清，反复改五轮；因为没有验收标准，Agent 自己跑偏半天；因为默认使用最强模型，连格式转换、摘要、批处理都走顶级算力。

这时候你以为自己在花 token，其实是在为没有设计的工作流买单。

这也是我对公司额度调整的另一个理解：它会把这些浪费暴露出来。以前额度足够大，大家很容易用“再跑一轮”解决所有问题。现在不行了。你必须在调用之前想清楚，这次到底要 AI 做什么，输入是不是足够干净，输出怎么验收，失败以后怎么修。

这件事会让很多人不舒服。但从能力训练角度看，它是必要的。

不是所有任务都配得上最强模型

过去额度充裕时，最容易形成的坏习惯是：默认用最强模型。

这很自然。强模型效果好，容错率高，省心。尤其是长任务、复杂任务、开放式判断，用强模型确实更稳。

但如果所有环节都用最强模型，本质上就是把 AI 当成一个无限体力的高级员工。什么活都让最贵的人干，短期舒服，长期一定不经济。

我的体感是，很多便宜模型这半年进步很快。Gemini Flash、Cursor 里较轻量的模型、腾讯混元的一些预览模型，在长任务和复杂任务上确实会出问题。但如果任务边界清楚、输入输出信号明确、限制条件写得足够具体，它们其实可以完成不少工作。

比如摘要、格式化、分类、初筛、批量改写、固定模板填充、简单代码转换，这些任务不一定需要最强模型。真正应该留给强模型的是规划、复杂推理、架构判断、风险结论、关键文档定稿和最终验收。

强模型应该站在关键出口，不应该站在每一个入口。

这会变成未来 AI 使用的一门基本功：模型分层。

不是为了省钱而省钱，而是为了让每一档模型做适合自己的事。强模型负责少数高价值判断，便宜模型负责大量中间劳动。人负责定义任务、组织上下文和验收结果。

上下文也要算 ROI

额度有限以后，另一个会被迫重视的东西是上下文。

过去我们太容易把长上下文当成万能解法。能贴多少贴多少，能上传多少上传多少，能把历史对话全塞进去就全塞进去。这样做有时候确实方便，但也会制造新的浪费。

上下文不是越多越好。上下文越乱，模型越需要花力气辨别什么重要、什么无关。你给它十万 token，其中七万是噪音，它不会因此更聪明，只会把更多计算花在垃圾堆里找线索。

真正好的上下文组织，应该像一个干净的工作台。稳定背景沉淀成文档或 skill，当前任务只给必要输入，历史过程压缩成决策摘要，验收标准单独列出来，失败样本进入下次可复用的资产。

这不是单纯的 prompt 技巧，而是工作流设计。

我现在越来越觉得，所谓 Context Engineering，不只是为了提高回答质量，也是在做成本治理。你把上下文组织得越好，模型越少浪费，结果也越稳定。

资源限制会逼出真正的问题

我印象里，张小龙以前在一些内部或公开场合讲过类似意思：资源有限的时候，反而更容易激发创新。我没有找到能逐字核验的原话，所以这里只说我自己的理解。

资源充裕时，人很容易做加法。多开一个 Agent，多跑一次深度调研，多塞一段上下文，多用一个强模型。每一步看起来都合理，最后整个系统变得越来越重。

资源有限时，人会被迫做减法。到底哪个环节是瓶颈？到底哪段上下文是必要的？到底这个任务该不该用 AI？到底这个步骤能不能交给便宜模型？到底这次调用有没有减少人的关键时间？

这些问题平时也重要，只是在资源充裕时没人愿意认真问。

所以额度限制不是创新的敌人。真正的敌人是浪费被隐藏以后，大家误以为自己已经高效。

有限资源至少会让账重新变清楚。

接下来，我会先改自己的工作流

这件事对我自己的提醒很直接。

接下来我会重新看每天跑的这些 AI 工作流，哪些必须用强模型，哪些可以降级，哪些适合拆成多段，哪些上下文应该提前整理，哪些任务不值得跑完整 Agent。

我的初步原则会是这样：

• 强模型做判断、规划、复杂推理和最终收口。
• 便宜模型做摘要、格式化、初筛、批处理和结构转换。
• 长上下文先压缩，再交给强模型。
• 高频任务沉淀成 skill 或模板，不要每次重新解释。
• 每次调用都尽量有明确输出和验收标准。

这不是少用 AI，而是更认真地用 AI。

第一阶段，比的是谁更敢用。第二阶段，比的是谁更会组织任务。

AI 额度限制，不一定会让我们少用 AI。它可能会让我们第一次真正学会用 AI。

有人在试 prompt，有人在折腾 MCP，有人在研究各种 wrapper 和 harness。这个场景我太熟了。AI coding 之后，很多东西都变得很容易起手。以前一个人想搭一套工具链，至少会先被工程成本劝退一半。现在不一样，AI 一晚上就能帮你拉出个第一版，于是大家都会忍不住想：我是不是也可以改一点、接一点、包一层、再造一个更适合自己的东西。

然后陈然出来讲了一段 Alpha 和 Beta。

他的大意是：大多数人总想在人生各处找 Alpha。投资要 Alpha，职业要 Alpha，关系要 Alpha，身体也想要 Alpha。但现实是，人不可能在所有地方都拿超额收益。更舒服的状态，是大多数地方吃 Beta，少数地方追 Alpha。放到 AI coding 里，Claude Code、Codex 这些最先进的工具，本身就是 Beta。至于各种 prompt、MCP、魔改、harness，很多时候是在追 Alpha，不一定比工具自然升级带来的收益更高。

我当时的反应是：这话挺准。

它准在边界感。

很多人对“用现成工具”这件事有点心理负担，好像不用自己改一层，就不算高级；不自己搭一套，就不算懂；不做点差异化，就只是一个普通用户。但我现在越来越觉得，能承认自己大多数时候应该先拿 Beta，本身就是一种成熟。

这不是懒。

这是你知道哪些收益本来就不该靠自己硬造。

投资里最朴素的例子就是指数。很多人研究主动基金、择时、个股、行业轮动，最后长期收益还不如一只低成本指数。信用卡也差不多。你可以把各种积分、返现、权益研究到很细，但如果你的时间本身更贵，一张简单稳定的返现卡可能已经够好。

AI 工具也是这个逻辑。

如果 Claude Code 已经是当前最强的一档，那就先用 Claude Code。如果 Codex 在某些任务上更顺手，那就用 Codex。如果公司内部有成熟平台，先接成熟平台。模型、工具协议、agent runtime、trace、eval、guardrails、权限、审计，这些通用复杂性，能交给专业工具和专业团队，就不要急着自己背回来。

AI 很容易制造一种错觉：因为第一版太容易做，所以这件事就值得自己做。

但第一版不是最贵的。长期托付才是。

你今天让 AI 写一个 harness，可能很快。真正麻烦的是后面：模型升级了怎么办，工具协议变了怎么办，日志够不够查，错误怎么复盘，权限怎么兜住，谁来维护，谁来解释，出了问题谁负责。AI 能降低制造成本，但不会替你承担责任链。

所以我很认可陈然这个态度：大多数时候，先吃 Beta。

这句话放在 AI coding 里，不是在说“别创造”。它是在提醒人，先别把创造力花在最不划算的地方。通用能力会被大模型厂商、工具厂商、开源社区反复卷。个人和普通团队在这一层硬追 Alpha，很容易追成负债。

真正应该守住的，是自己的那部分。

对我来说，这部分不是通用 agent runtime，不是每一个 prompt 技巧，也不是所有 MCP 的魔改能力。更可能是业务语义、私有上下文、判断标准、验收方式、责任边界和组织里的落地路径。

模型不知道你的业务为什么重要。工具不知道哪个错误在你这里最危险。平台不知道你们组织里谁能审批、谁要兜底、谁会在真实流程里使用它。

这些东西才是自己的 Alpha。

所以我更愿意把这件事说成一句很土的话：

通用能力吃 Beta，业务判断守 Alpha。

不要从零造发动机，但方向盘也不能交出去。

这也是我之前讲 Agent 时反复强调的东西。做 Agent，不是所有模块都自己做。真正有价值的，是把成熟 harness 包到核心、稳定、可验证的业务场景里。业务同学负责定义问题、提供上下文、判断结果、明确风险边界。平台团队负责让它可追踪、可评测、可审计、可兜底。不是每个人都从头搭一套 agent 基础设施。

专业的人使用专业工具，依然会比非专业的人更专业。工具变强不会让边界消失，只会让边界更重要。

说到这里，我基本是站在陈然这一边的。

大多数人确实应该少证明自己聪明一点，多先拿确定收益一点。尤其在 AI coding 这件事上，不要因为 AI 能帮你写代码，就重新变回手工业者。以前是“我做不出来”，现在变成“我都能做出来”。但“能做出来”和“应该由我长期负责”，中间差得很远。

不过我也想补一层边界。

不是所有魔改都该被打成低收益 Alpha。

群里很多人折腾 prompt、MCP、小工具，不一定是为了立刻比 Claude Code 或 Codex 更强。有些人是在学习 AI，在摸工具边界，在理解 prompt 为什么会影响结果，在试 MCP 能不能接进自己的工作流，在用一个小工具建立体感。

这种探索不能只用收益率衡量。

人并不只是为结果的成功而活。

有些东西的价值，不在于它马上赢了谁，而在于它让你更理解一个工具，更接近一个新领域，或者只是让你在快速变化的环境里保持一点参与感。学习本身有价值，兴趣本身也有价值。不是所有东西都需要被包装成战略。

关键是别混淆。

如果你要的是业务结果，那就别拿探索当借口消耗主线。先用最好的工具，先拿确定的 Beta。

如果你要的是学习，那就承认它是学习。给它一点比例，做完有反馈，有复盘，有沉淀。

如果你只是觉得好玩，那也没问题。只是别把每一次好玩都说成“我在追一个很重要的 Alpha”。

我觉得更舒服的状态大概就是这样：大多数地方先拿 Beta，少数真正属于自己的地方追 Alpha，另外保留一点不以胜负为目的的探索。

这比到处证明自己聪明要健康。

也更像一个成年人该有的取舍。

公司这边，大家都在说要更扁平。Meta 在"效率之年"里压缩管理层，想让做事的人和做决定的人离得近一点。Zuckerberg 的说法很直接：组织每多一层，信息流和决策就会多一点延迟，也会多一点风险规避。Amazon 也在做类似的事。Jassy 要求各个 S-team 组织提高 IC 和 manager 的比例，理由还是那些：少一点层级，少一点官僚，让决策更靠近一线。

但 AI 这边，方向几乎是反过来的。

一开始我们会觉得，一个 Agent 似乎就够了。给它一个目标，让它自己拆任务、查资料、写代码、验证结果。后来慢慢发现，一个 Agent 把所有事情都塞进同一个上下文里，效果并不稳定。于是开始有主 Agent 和子 Agent，有 orchestrator-workers，有 evaluator-optimizer，也有 parallel agents。到 Claude Code 的 dynamic workflows，已经可以让 Claude 先规划任务，再在一个 session 里跑很多并行 subagents，最后把结果收回来验证。

这个画面乍看确实有点讽刺。人类公司刚从科层制里往外跑，转头又给 AI 搭了一套类似科层制的东西。

群里有人调侃说，那些 agent 架构图看小图还以为是哪家大公司的组织架构。还有人说得更狠：agent 不用升职加薪，也不用争预算，利益天然对齐，所以人类扁平化最想甩掉的那一层，在 AI 这里反而没那么讨厌了。

我一开始也把它当成一个有趣的反差。但后来想想，这可能不是反差，而是同一道题在两个系统里的不同答案。

这道题其实很朴素：复杂任务要怎么在有限注意力下完成？

层级先是一种注意力安排

我们平时一说层级，很容易想到组织图上的方框，想到谁向谁汇报，谁能拍板，谁在谁上面。

但如果先把权力关系放到一边，层级最底层的作用其实没那么复杂。它是一种注意力安排。

下面的人处理细节，上面的人看摘要。局部系统消化局部复杂性，上层只看接口和结果。这样一来，一个人不需要同时理解所有细节，一个系统也不需要把所有复杂性都摊在同一层。

没有这种安排，复杂性会直接把注意力淹没。

Simon 的钟表匠寓言讲的就是这个意思。先把零件拼成稳定模块，再把模块组装起来，效率会比从零件一口气装到成品高很多。因为中间成果可以保存，各个层次也可以相对独立地工作。

斯密讲分工，科斯讲企业用指挥替代市场交易来节省协调成本。它们说的当然不是同一件具体的事，但背后有一个共同点：人类面对复杂任务时，往往会把任务拆成层。每一层不用理解全部，只要处理好自己那一段。

所以层级并不只是组织的毛病。它也是人类处理复杂性的发明。

问题在于，层级从来不是免费的。

每多一层，信息就要被压缩一次、转述一次、解释一次。只要有压缩，就会有损耗。只要有转述，就会有变形。

人为什么想减层级

想象一个五万人的公司。战略目标在 CEO 那里可能很清楚，但经过五六层传递之后，到一线手里往往已经不是原来的样子了。

这不是因为中间每个人都不努力。很多时候，恰恰是因为每个人都在"理解"它、"翻译"它、"结合本部门实际"处理它。等这些加工叠在一起，原始意图就慢慢被磨掉了。

组织沟通研究里有个常被提到的数字：信息每经过一层向上传递，真正保留下来的大约只有六七成。这个数字未必需要被当成精确公式，但它描述的体验很多人都熟悉：一线看到的是具体问题，中层整理成风险和进度，高层听到的是经过包装之后的摘要。到最后，决策者拿到的经常已经不是原始事实，而是一份被层层处理过的版本。

更麻烦的是，人类层级不是中性的压缩器。

人会顾及面子，会考虑利益，会报喜不报忧，会把坏消息修得没那么难听。信息在组织里损耗，常常不是简单的"丢包"，而是有动机的改写。

所以今天很多大公司拆层级，背后真正想解决的不是"中层太多"这么简单，而是层级太多之后，注意力被分散，信息被稀释，决策越来越偏离真实现场。

Zuckerberg 说层级会增加 latency 和 risk aversion，Jassy 讲那些 pre-meeting for pre-meeting，本质上都在描述同一种病：信息还没到真正的决策点，已经在传递过程中消耗掉了原来的能量。

但这里有个反直觉的地方。

公司嘴上都在反中层，现实里中层却并没有真的消失。中层管理者占美国劳动力的比例，从 1983 年的 9.2% 升到了 2022 年的 13%。这说明一件事：组织不是因为喜欢层级才长出层级，而是因为协调需求一直都在。

今天砍掉一批，明天它可能换个名字再长回来。叫 manager，叫 lead，叫 program owner，叫 business partner，名字变了，功能还在那里。

所以人类组织不能无限拆层级。拆到最后，看似每个人都更自由，实际上所有协调、判断、沟通、优先级排序都会压回到个体身上。所谓"一人公司"很迷人，但如果什么都要一个人同时处理，人也会撞上自己的注意力极限。

扁平不是没有代价的。它只是把原来显性的组织层级，部分转移成了隐性的个人负担。

AI 为什么又在加层级

AI 系统现在往反方向走，也是因为类似的问题。

单个 Agent 看起来很强，什么都能做一点。但只要任务稍微复杂，它也会遇到注意力极限。这里的注意力，换成 AI 的语言，就是 context。

Anthropic 有个说法很直接：context 是有限资源，而且有边际递减。上下文越长，模型不一定越聪明，很多时候反而越容易失焦。一个 Agent 如果把整个项目的资料、历史、约束、代码、讨论都塞进同一个上下文里，最后很可能什么都知道一点，但关键处抓不住。

于是 subagent 出现了。

每个子 Agent 拿一个相对干净的上下文，处理一个局部任务。它不需要知道全局所有细节，只要把自己那一块查清楚、做扎实，再把结果压缩回主 Agent。主 Agent 也不需要知道每个子 Agent 看过哪些文件、走过哪些路径，只需要拿到结论、证据和可验证的输出。

这和组织层级的逻辑其实很像。

不是为了模仿公司里的官僚制，而是为了让复杂任务可以被拆开，让不同局部可以并行探索，让主系统的注意力不被细节淹没。

AI 搭层级，不是因为它喜欢层级，而是因为单层结构扛不住复杂性。

但 AI 的层级也不是加得越多越好。

Anthropic 自己的数据里，多 Agent 比单 Agent 效果高约 90%，但 token 用量是普通 chat 的 15 倍。这个交换很真实：你用更多结构换来了更强的探索能力，也付出了更高的协调成本。

我自己有次深夜跑实验，大几十个 Agent 一起发动，token 消耗像水龙头没关。那一刻体感非常强：agent 之间也不是没有传话成本。一个子 Agent 说清楚的东西，传到主 Agent 这里会被压缩一次；主 Agent 再交给另一个 Agent，又会被重新解释一次。层级多了以后，AI 也会遇到"传话游戏"。

信息不是只有在人类组织里才会变形。只要有多层传递，它就会变形。

两边其实都在往中间走

这样看，"人类组织减层级"和"AI 系统加层级"就不是两个相反的趋势了。

它们更像是从两个极端出发，往同一个中间点靠近。

人类组织过去层级太多，信息失真太严重，所以现在要少一些层，让一线和决策点靠得更近。但它不可能真的走到零层级。零层级意味着所有协调都压到每个人身上，最后还是会过载。

AI 系统一开始太像一个单体智能，什么都往一个上下文里塞，所以现在要多一些层，让任务被拆开，让上下文保持干净，让不同路径可以并行探索。但它也不能无限加层。层级太多之后，agent 之间的协调、压缩、验证都会变成新的成本。

所以真正的问题不是"要不要层级"。

真正的问题是：多少层级刚好够用？

这个问题对做 AI 系统的人很实际。不是 Agent 越多越好，也不是越扁平越好。如果任务可以清晰拆分，子任务之间依赖少，搜索空间很宽，单个上下文装不下，那多 Agent 是合理的。如果任务本身是线性的，范围不大，验证标准也明确，一个 workflow，甚至一个脚本，可能就够了。

对管理组织的人也一样。不是层级越少越先进，而是每一层都应该承担有效的信息处理。能压缩复杂性、提高判断质量、减少协调成本的层，是有价值的。只是转述、包装、制造会议和延迟的层，就应该被砍掉。

人在拆层级，AI 在搭层级，看起来方向相反，其实都在回答同一个问题：对于有限的注意力，多少层级才刚好够用？

但这篇文章真正让我有触动的，并不是 Skill 本身。

如果只是讨论 Skill、外化、上下文沉淀、任务经验复用，这些东西对于一个已经比较熟练使用 AI 的人来说，并不陌生。甚至可以说，很多人每天都已经在不自觉地做类似的事情：把偏好写清楚，把判断标准放进上下文，把踩过的坑记录下来，让 AI 下次不要从零开始。

所以，我一开始读这篇文章时，真正吸引我的不是“他说了一个我不知道的技巧”。

而是另一件事：鸭哥显然早就过了需要被这类技巧启发的阶段，但他还能回过头来，站在一个刚刚跨过 AI 使用门槛的人视角，把这个动作重新讲成一个关键转折点。

这件事很难。

技巧被内化之后，会消失

很多时候，我们刚刚学会一个东西时，会有非常强的突破感。第一次意识到 AI 不只是聊天窗口，而是可以帮你执行任务；第一次意识到不能只给任务，还要给标准；第一次意识到不是每次重新解释背景，而是要把经验沉淀下来。那一刻，人的感受是很鲜明的：原来应该这样用。

但当这些动作逐渐进入日常之后，它们就消失了。

不是它们不重要了，而是因为它们已经被我们内化了。一个熟练的司机不会每天意识到自己在看后视镜，一个成熟的产品经理不会每次都意识到自己正在拆用户路径，一个高频使用 AI 的人也不会每次都意识到自己正在外化上下文、设定边界、约束输出、积累复用材料。

真正掌握之后，技巧会从“知识”变成“身体的一部分”。

这也带来一个问题：越熟练的人，越容易忘记自己曾经不会。

所以很多高手在给新手写东西时，会天然地跳过那些自己已经无感的环节。他们会讲更高级的框架，更复杂的系统，更完整的方法论，但反而不容易讲清楚那个最早让人发生变化的小动作。

这也是我觉得鸭哥这篇文章厉害的地方。

它不是一个高手在展示自己知道多少，而是一个高手在重新定位：对于一个还没有真正进入 AI 工作方式的人来说，哪一步最关键？

他没有从自己现在的位置往外讲，而是从读者还没跨过去的位置往里讲。

文章真正要找的，是门槛

这两种写法差别很大。

从自己现在的位置往外讲，很容易写成经验总结。作者会把自己知道的东西摊开，告诉别人这里有多少工具、多少技巧、多少原则。这类文章未必不好，但它常常有一个问题：读者看完觉得有道理，却不知道自己真正要改变的第一个动作是什么。

从读者还没跨过去的位置往里讲，则完全不同。它关心的不是“我知道什么”，而是“你现在为什么还没进去”。读者为什么觉得 AI 只是聊天？为什么每次都重新开始？为什么没有意识到上下文可以被沉淀？为什么觉得写 Skill 是多此一举？为什么还没有把 AI 当成一个可以被持续喂养和约束的工作系统？

这时，文章要找的就不是一个知识点，而是一个门槛。

对已经熟练的人来说，Skill 可能只是一个很自然的工作方法。但对刚刚进入 AI 使用的人来说，它代表的不是某个文件、某种格式、某套写法，而是一个视角变化：不要把每一次和 AI 的交互都当成一次临时对话，而要开始把任务经验变成可以复用的东西。

这个动作本身未必复杂，但它改变了人对 AI 的理解。

所以，鸭哥这篇文章真正有价值的地方，不是把一个复杂概念讲简单了。更准确地说，是他从一堆自己已经习以为常的熟练动作里，重新抽出了一个对普通人有典型意义的动作。

这比“讲清楚一个复杂问题”更难。

因为复杂问题至少还摆在那里，等着被解释。可是那些已经被高手消化掉的动作，往往不会再以“知识点”的形式出现。它们藏在日常操作里，藏在顺手的一次修改里，藏在你下意识补上的一句约束里，藏在你觉得“这不是很自然吗”的反应里。

真正难的，是把这些已经无感的东西重新变得可见。

走远之后，还能回头看见台阶

我想到自己使用 AI 的过程，也是这样。

刚开始遇到一个问题，有时会有很强的兴奋感：原来这么提示会好很多，原来要先给例子，原来要告诉它不要做什么，原来要把我心里的判断标准写出来。每一个小发现，在当时都像一次突破。

但过一段时间之后，这些突破会慢慢融入日常。你不再觉得它们值得被专门拿出来讲，因为你已经默认世界就应该这样运转。

这其实是熟练之后的一种盲区。

当一个能力刚刚被掌握时，我们还记得它带来的变化。当一个能力真正被内化后，我们反而忘了它曾经带来的变化。于是，当我们要向别人解释它时，就容易从现在的自己出发，而不是从过去那个还没有理解它的人出发。

而鸭哥这篇文章给我的提醒就在这里。

一个真正厉害的表达者，不只是自己走得远，而是走远之后，还能回头看见那一级台阶在哪里。

他知道自己现在站在高处，但他没有直接把高处的风景抛给读者。他先找到读者脚下那个看起来不起眼、但一旦跨过去就会改变理解方式的台阶。

这是一种很高级的能力。

它不是单纯的表达能力，也不是单纯的认知能力，而是一种“重新进入他人困境”的能力。

很多人能讲自己理解了什么，但不一定能讲别人为什么还没理解。很多人能总结自己的方法，但不一定能判断别人此刻最需要哪一个方法。很多人能把复杂东西讲得很高级，但不一定能把关键东西讲到刚好能被跨过去。

这也是为什么我越来越觉得，高手写作最重要的不是信息密度，而是切入位置。

切得太浅，文章就变成常识。

切得太深，读者还没进门。

切得太散，读者会觉得都对，但不知道先改变什么。

真正好的切入，是找到那个最小但最关键的动作。这个动作足够具体，读者可以马上尝试；但它背后的意义又足够大，一旦尝试成功，读者对整件事的理解会发生变化。

鸭哥这篇文章给我的感觉就是这样。

它表面上是在讲一个 AI 使用方法，但更深处体现的是一种很强的判断：在一个普通人从“会用 AI”走向“真正把 AI 融入工作方式”的过程中，哪一个动作最值得被拿出来讲？

这个判断本身，才是我真正想学习的东西。

我自己的提醒

也因此，我看完之后反而在想自己的问题：我是不是也有很多已经习以为常的东西，曾经对我来说其实是很重要的突破？我是不是因为已经太熟练，所以反而失去了向别人解释它的敏感度？当我给团队分享 AI、分享 agent、分享 Skill、分享工作方式时，我是在讲我现在知道的东西，还是在帮助别人跨过他们当前真正卡住的那一级台阶？

这两个问题不一样。

讲我现在知道的东西，很容易。

帮助别人跨过当前的台阶，很难。

前者要求我把知识整理清楚。后者要求我重新理解别人。理解他的旧模型，理解他的误解，理解他为什么觉得某些动作麻烦，理解他为什么还没有意识到这个动作背后的意义。

很多时候，新手觉得奇怪的地方，恰恰是范式差异最大的地方。

比如，为什么问 AI 之前还要先写清楚标准？为什么一个重复两三次的任务就值得沉淀？为什么不能每次直接开聊？为什么要把自己脑子里的判断写出来？这些问题从高手视角看，似乎已经不需要解释。但从新手视角看，它们正是需要被解释的地方。

如果一个人能认真对待这些“看起来很初级”的疑问，他才有可能写出真正有穿透力的入门文章。

因为好的入门文章，不是把高级内容稀释，而是找到低阶状态通往高阶状态的那个转折点。

这也是我今天最大的收获。

鸭哥这篇文章让我意识到，高手和高手之间的差别，不只在于谁走得更远，也在于谁走远之后，还能不能回头看见路径。

有些人走远之后，只剩下结论。

有些人走远之后，还能记得路。

更厉害的人，是走远之后，还能指出别人现在应该迈哪一步。

这一步看起来可能很小，但它刚好站在旧理解和新理解之间。

真正能帮助别人发生变化的，往往就是这一步。

我讲了一个观察：现在不管是 Coding Agent 还是其他垂类 Agent，所有认真解决用户问题的产品，在设计上都必须保持足够的开放。调用本地工具，连接本地文件，配置放本地，记忆放本地，甚至很多 harness 和执行引擎也放在本地。

这不是偶然的技术选择。这是三重必然。

第一，AI 要理解你的项目上下文，配置文件必须跟代码放在一起，否则每次推理都多一个网络往返，延迟和成本都不可接受。第二，代码和项目元信息是企业核心资产，放到第三方云端等于把知识产权交出去了，没有严肃的企业会接受。第三，开放协议才能快速扩张生态，Anthropic 把 MCP 捐给了 Linux Foundation，OpenAI 把 AGENTS.md 做成了开放格式，6 万多个开源项目已经在用。

但这种必然性带来了一个后果：用户的迁移成本接近于零。

一个配置文件的距离

我自己亲身经历过这件事。我在 Claude Code 里积累了大量的 CLAUDE.md 配置、技能文件、MCP server 设置。这些东西沉淀了好几个月。

然后有一天我试了一下 Cursor，发现它会自动读取 CLAUDE.md 的内容（它自己叫 .cursorrules，但内容格式完全一样）。MCP 的 JSON 配置换个路径就能用。技能文件本身就是纯 Markdown，复制过去即可。

反过来也一样。Windsurf 支持读 AGENTS.md，Codex 支持读 AGENTS.md，Gemini 有自己的 GEMINI.md 但格式大同小异。这些东西说白了都是"一个 Markdown 文件告诉 AI 该怎么干活"，换个名字就能在不同工具间跑。

更极端的是新工具。antigravity 这类后来者，首次启动就提供从 VS Code/Cursor 一键导入的功能。你的 extensions、keybindings、settings 直接搬过来。JetBrains 2026.1 版本甚至原生支持从 Windsurf 导入配置。你几乎不需要做任何"迁移"的动作，新产品已经把这件事做成了默认行为。

这就是我说的"成也灵活，败也灵活"。产品必须开放才能获得用户信任和真正的价值，但开放本身让用户随时可以带着全部资产离开。

所有人都在给 API 打工

这种状态下，做应用的人头上始终悬着一把剑。

不是你产品做得不好。Cursor 做到了 5 亿美元年收入，100 万日活，零营销支出。按任何传统 SaaS 标准，这是教科书级别的增长故事。但它同时以负毛利在运营。为什么？因为 Anthropic 直接把等价的海量算力打包进了 200 美元一个月的 Claude Max 计划，一夜之间结构性压缩了它的利润空间。

这比 Apple 的 App Store 剪刀更狠。Apple 至少看不到你 App 内部每一次用户交互的细节。而 API provider 能看到所有调用者发了什么 prompt、哪些功能有增长、用户在做什么。它拥有一个"全生态热力图"。什么应用火了它一清二楚，想做同样的功能几乎没有信息障碍。

OpenAI 升级 4o 图片能力的时候，一周内用户生成了 7 亿张图片，Midjourney 突然面临存在危机。这不是"可能发生"的平台风险，这是正在发生的事实。

向后做：训练自己的模型

面对这个困境，一个自然的反应是往后走，训练自己的模型，摆脱对上游的依赖。

Cursor 就是这么做的。它从 2024 年就开始训练专用的代码补全小模型，在"光标跳转预测"这个细分场景做到了极致。效果确实好，体验领先通用模型。

但问题是：你在一个 100 米赛道上建了 10 米的领先优势，而赛道本身每个季度重置一次。通用大模型的迭代太快了，DeepSeek 12 个月追平了 OpenAI 的推理水平。你在垂直场景的微调优势，可能在下一代通用模型发布时就被抹平了。

而且经济账也不好看。你花钱训练的模型还没回本，上游已经用补贴价提供了同等甚至更好的能力。LinkedIn 上有人说了一句很到位的话：模型优势没能救它，因为它训练在了错误的层。

但这不意味着向后做完全无效。关键区分在于：你训练的数据是不是真的不可复制。如果是用公开代码训练，竞争对手一样能做。但如果你拥有的是每周 200 万真实客服对话，或者覆盖了某个行业 40% 从业者的查询数据，那确实带不走。数据飞轮能不能转，取决于数据本身的稀缺性，不是"有个飞轮"这件事。

向前做：形成生态

另一个方向是往前走，形成一个跟产品强绑定的生态。

ChatGPT Plugins 是第一次大规模尝试。结果失败了，2024 年关停。核心原因很简单：用户不想在 AI 对话中"选择"和"安装"工具，他们想直接说需求，让 AI 自己判断调什么。AI 时代的 App Store 逻辑不成立。

但生态壁垒不是只有 marketplace 一种形态。

GitHub 走了"编排层"路线：不做最好的单一 Agent，做所有 Agent 的运行平台。Anthropic、OpenAI、Google 的 Agent 都在它上面跑。当你从"工具"变成了"基础设施"，替代你的成本就不再是"改个配置文件"的事了。

中国这边我看到一个有意思的方向：把专家和创作者跟平台绑定。比如有些产品在做"专家市场"的功能，如果这些专家跟平台有分成机制，用户在迁移时能带走自己的配置，但带不走这些专家提供的独占内容和持续服务。这类似 YouTube 创作者跟平台的关系：内容是你的，但你在这个平台上建立的受众关系和分发渠道带不走。

这条路的核心逻辑是：让平台上存在某种"只在这里才有"的关系或内容。不是锁数据，是锁关系。

我的判断

回到吃饭时的讨论。我觉得这个矛盾不会被解决，只会被接受。

试图通过锁定数据来建壁垒的公司，会在开源竞争中失去用户。开发者这个群体尤其反感 lock-in，谁锁我我就换谁。试图通过纯功能领先来建壁垒的公司，会在模型迭代中失去优势，每季度起跑线重置一次。

能活下来的，是接受了"用户随时可以走"这个前提，然后在这个前提下创造"让用户不想走"的价值。具体来说，我觉得有四条路有可能走得通：

第一，不可复制的数据。不是用户的配置文件（那个谁都能读），而是只有你的平台才能积累的、用户带不走的知识。第二，信任基础设施。合规认证、审计记录、责任承担。替换一个你信任的系统，需要重新走一遍决策流程，这个成本是真实的。第三，关系网络。创作者生态、专家市场、用户间的协作关系。关系不像文件，不能一键导出。第四，编排层地位。成为"运行所有 Agent 的平台"，而不是"一个 Agent"。水电煤不容易被替代。

这四条路有一个共同特征：它们不是靠阻止用户离开来维持的，而是靠创造"只有在这里才有"的东西来吸引用户留下。

AI 降低了功能的制造成本，但没有降低信任的托付成本。壁垒不是消失了，是从"能不能做出来"迁移到了"敢不敢把事情交给你"。

至于最终的格局是什么样，现在还看不清楚。我唯一确定的是：靠一个配置文件就能迁移走的东西，不叫壁垒。

第一天大家觉得这个形式挺好。AI 生成的图有点意思，比一大段文字更容易让人停一下，群里也有人夸这个方式不错。

但到了第二天、第三天，类似的图片观点继续出现时，风向忽然变了。有位同学说，看这种图文并茂的东西反而让人无法集中注意力，很难抓到核心信息。很快又有三四个人表示同感。

这个反馈让我印象挺深。因为它不是简单地说“图片不好”。第一天大家觉得好，第三天大家觉得累。变的不是信息本身，而是人对这个介质的接受状态。

图文的价值，不在于有图

我一开始的直觉是：当我们一直读文字，读到信息量过载的时候，图片确实会让人眼前一亮。它打断了连续文本的疲劳，让信息看起来更轻、更完整，也更像一个可以被快速消费的成品。

但图文看多了之后，问题也会反过来。那些插画、分区、图标、强调色、装饰性标题，一开始是信号，后来可能就变成噪音。读者在理解观点之前，要先判断哪里是主线，哪里是装饰，哪里是作者真正想说的话。

图文并茂不是天然更高效。它只有在降低理解成本时才有价值。

如果一张图在说明空间关系、流程关系、对比关系，它很有用。架构图、地图、流程图、趋势图，很多时候比文字好。因为它把文字里很难顺序展开的关系，变成了可以一眼看到的结构。

但如果一张图只是把一段话拆成几个卡片，再配上几张和观点关系不大的插画，它未必是在帮助理解。它可能只是把本来能顺着读完的一段话，变成了一个需要重新找阅读路径的版面。

很多 AI 生成图文的问题就在这里。它不是把复杂内容变简单，而是把简单内容变得像“内容产品”。

AI 把生成成本打低，也把筛选成本抬高

过去，做一张好看的观点图是有门槛的。会设计、会排版、会配图，这些能力本身会形成一层筛选。不是每一个观点都会被做成图。

现在不一样了。AI 可以把任何一段话变成海报、长图、HTML 页面、缩略图、短视频脚本。生产成本下来了，这是好事。但副作用是，原来靠成本过滤掉的低增量内容，现在也能穿上一件漂亮外衣。

读者面对的就不再是“更多好内容”，而是“更多看起来像好内容的内容”。

于是人的阅读策略会变。一开始，形式精致会让人停留。过一阵子，人会反过来把这种形式当成警报：这是不是又是一张 AI 自动生成的观点图？是不是包装大于内容？是不是看半天其实只有一句话？

这有点像网页广告。最早 banner 很显眼，后来用户学会了自动忽略一切像广告的区域。不是每个广告都没价值，而是人的注意力太贵，只能先按外壳过滤。

AI 图文内容也可能走到这一步。只要某种外壳被过度使用，它就会从“吸引注意力的信号”，变成“提醒我可以跳过的信号”。

纯文字为什么会重新变清楚

这不是说纯文字就天然更好。长、散、没结构的文字，同样让人累。

但在图文泛滥之后，纯文字会重新显得清楚，是因为它少了一层界面噪音。

文字的好处是路径稳定。第一句到第二句，上一段到下一段。只要作者的逻辑是清楚的，读者不需要先研究版面，再理解内容。

尤其是观点表达，最有价值的往往不是结论，而是推理链：这个判断从哪里来，前提是什么，反例是什么，为什么最后落到这里。图文卡片很容易把这些中间过程压扁，最后只剩几个看起来很有道理的结论。

所以当有人说“这种图文并茂的内容反而难以获取核心信息”时，他未必是在反对图片。他可能是在说：这个介质让我多付了一层注意力成本，但没有给我等价的信息回报。

给 AI 看和给人看，不该用同一套介质

这件事往深一层看，其实是 AI 时代很重要的一个分叉：信息到底是给 AI 消费，还是给人消费。

如果信息是给 AI 消费的，我觉得原则很简单：效率优先。结构化、可解析、低歧义、低噪音，比漂亮重要得多。

AI 不需要被打动。它不需要渐变背景，不需要插画，不需要“高级感”。它需要的是清晰字段、稳定层级、明确上下文和尽可能少的歧义。

所以给 AI 的材料，Markdown、JSON、表格、清晰的标题层级，往往比一张精美长图更好。对人来说，长图可能更直观；对 AI 来说，长图可能只是 OCR 成本和解析噪音。

但给人看的信息就完全不同。人不是 API。人会疲劳，会厌倦，会被新鲜感吸引，也会因为过度熟悉而自动过滤。人需要节奏、语气、留白、可信度和情绪上的进入点。

所以同一份信息，给 AI 和给人，可能应该有两套载体。给 AI 的版本追求结构效率；给人的版本追求理解效率和信任效率。

把这两件事混在一起，就会出现很多怪东西。给人看的内容像机器输入，干巴巴。给 AI 的内容像品牌海报，漂亮但难解析。

最佳介质不是答案，而是周期

我现在越来越觉得，很多问题不是找一个永恒最优解，而是识别当下的瓶颈。

当大家连续读长文，文字密度已经太高时，一张图可能正好有用。当大家每天刷到几十张 AI 生成海报时，一段干净的文字反而更像诚意。当一个概念很抽象时，图能帮忙搭桥。当一个观点需要精确论证时，文字更能保留推理。

这不是摇摆，这是适配。

AI 加速了这个周期。过去一个表达形式可能要几年才被用烂，现在可能几周就进入疲劳期。因为生成太容易，复制太快，模板化也太快。

所以真正重要的能力，不是掌握某一种固定介质，而是能判断：现在缺的是注意力，还是信任？缺的是理解速度，还是推理完整性？缺的是情绪连接，还是机器可处理性？

我以后大概会用三个问题来判断一份信息该怎么承载。

第一，谁是消费者？如果是 AI，优先结构化和可解析。如果是人，再考虑阅读体验、信任和节奏。

第二，当前瓶颈是什么？看不懂关系，用图。抓不住逻辑，用文字。没有耐心，用短内容。不信任，就给过程和证据。

第三，这种介质在当前环境里是稀缺还是泛滥？稀缺时，它有新奇红利。泛滥后，它必须靠真实信息密度继续站住。

回到那个群聊。那几张 AI 图文观点图的问题，可能不是做得不好，而是它们太快从“新鲜”进入了“模板”。当大家已经识别出这种模板后，它就必须拿出更高的信息密度，才配得上它占用的注意力。

AI 让表达变得太容易，反而逼我们重新尊重接收者的注意力。

介质不是答案。介质只是把信息送到某个对象面前的路。路修得再漂亮，如果让人走得更累，就不是好路。

团队现在的状态很典型。大家开始用 AI Coding 了，但还谈不上精通。更关键的是，一到大项目协同开发，还是会自然退回过去那套方式：先把需求讨论清楚，再开始落地。

我当然不反对把需求说清楚。评测平台这种东西，如果需求没想清楚，后面会非常痛苦。什么叫一次评测，什么叫通过，样本从哪里来，人工复核怎么做，trace 要不要存，哪些数据不能出域，这些问题不可能靠写代码写出来。

但我不太认同的是，需求确认只能靠人坐在一起用嘴聊。

这件事让我有一个越来越明确的判断：AI-native 不是从编码开始的，而是从需求确认开始的。

以前的需求确认，是把话说给人听

过去做需求，核心对象是人。产品经理写 PRD，研发读 PRD，测试读用例，开会讨论，来回确认。文档当然重要，但它本质上是给人看的。

所以很多东西可以靠人的背景知识补齐。一个词没说清楚，大家心里大概知道；一个边界没写完整，研发会凭经验补；一个异常路径没列出来，测试可能会追问；一个指标口径没完全展开，业务同学也许会在会上解释。

这套方式在前 AI 时代能跑，是因为中间有大量人类默契在兜底。

但现在问题变了。AI 进来以后，需求不再只是给人看，还会被 Agent 拿去执行。它不会像一个老员工那样理解组织里的隐含语境。它看到“支持多模型对比”，就会自动选择一种实现解释。它看到“评测结果可解释”，也会自动猜一个展示方式。

最危险的是，AI 通常不会把自己的猜测标红。它会把猜测变成代码。

模糊需求不会因为 AI 变强而消失。它只会更快地被固化成一个看起来能跑的实现。

需求要从文档，变成上下文包

我现在更愿意把 AI 时代的需求理解成一个 context package。

它不只是“我要做什么”，还包括：为什么做，谁来用，什么不做，怎么算做对，哪些数据能用，哪些边界不能碰，失败了怎么办，历史上做过什么取舍，相关代码在哪，评测样本是什么。

传统 PRD 像说明书。它告诉人这个功能大概应该长什么样。AI-native 的需求更像施工包。它要让 Agent 能读、能问、能拆、能审、能验证。

所以我觉得，团队接下来不应该只问“需求讨论清楚了吗”。更应该问几个更硬的问题：

如果把这份需求直接交给一个 coding agent，它会不会问出关键问题？如果不会，是需求写得太清楚，还是它根本不知道哪些地方该问？

如果把这份需求交给另一个 reviewer agent，它能不能指出歧义、冲突、缺失的验收标准和权限风险？

如果实现做完了，我们能不能沿着需求追到样本、trace、grader、测试、PR 和上线 gate？

这些问题比“PRD 写完了吗”重要得多。

评测平台尤其不能从分数开始

做评测平台，很容易一上来就做成跑分工具。上传样本，选择模型，选择评估器，跑出结果，展示对比。

这当然是评测平台要有的能力，但它不是第一对象。

评测平台真正的第一对象，应该是 Eval Spec。也就是：这次评测到底服务哪个业务判断，什么失败最不能接受，样本怎么来，人工怎么判，哪些指标是硬门槛，哪些只是观察指标，谁有权批准发布。

如果没有这个东西，分数越精确，反而越危险。因为你会得到一个看起来非常科学的数字，但它背后的“什么叫好”可能根本没被定义清楚。

这也是为什么我觉得，评测平台和需求确认其实是一件事的两面。

需求确认负责定义“什么叫做对”。评测平台负责持续验证“现在有没有做到”。如果前者没有结构化，后者就会变成形式化。

让 AI 参与需求确认，可以很轻

这件事不需要一开始就做一套复杂系统。更现实的方式，是先把需求确认流程加上几个 AI gate。

第一个 gate 是歧义检测。让 AI 只做一件事：列出这份需求里所有可能被不同人解释成不同含义的词，并给出每种解释会带来的后果。

第二个 gate 是验收标准检查。不要让 AI 评“写得好不好”，而是让它问：这件事最后怎么验？谁验？失败怎么办？有没有样本？有没有数据口径？有没有不能越过的安全边界？

第三个 gate 是任务拆解检查。让 AI 判断这份需求能不能拆成可独立交付的任务，每个任务有没有明确输入、输出和 Done when。

第四个 gate 是反方 reviewer。让不同 Agent 分别从业务、评测科学、安全合规、工程交付四个角度挑刺。一个 Agent 容易顺着你说，多个反方 Agent 更容易制造必要的冲突。

这些都不复杂。它们不需要平台先做好，不需要流程先审批。只要有一份 Spec，就能跑起来。

前端 demo 不是浪费，是需求反应器

我做那个前端 demo，不是因为我想亲自把平台写完。我的角色也不是去替团队开发。

demo 的价值在于，它让需求从抽象话题变成一个可以反应的对象。

如果大家只讨论“评测报告页应该展示什么”，很容易各说各话。管理者脑子里可能是趋势和风险，算法同学脑子里可能是样本和 judge，平台研发脑子里可能是任务状态和 trace，业务同学脑子里可能是结论能不能拿去用。

但如果前面摆着一个页面，大家就会立刻变得具体：这里为什么先看总分？失败 case 为什么藏这么深？这个指标是谁定义的？这条 trace 能不能点开？如果涉及敏感数据，谁能看到？

这时候讨论才真正开始。

需求不是被聊清楚的。很多需求是被原型、样本、trace 和验收标准一起跑清楚的。

团队要练的不是工具熟练度，而是协作新肌肉

我对团队现在的判断是，不要急着追求“大家都很会用 AI Coding”。工具熟练度当然重要，但它不是第一瓶颈。

第一瓶颈是工作对象没有变。

如果需求还是靠会说清楚，背景还是靠人脑补齐，验收还是靠最后人工看一眼，测试还是靠研发自己想起来跑，PR 还是靠 reviewer 凭经验扫，那么 AI Coding 只是把旧流程加速了一遍。

旧流程越不稳定，AI 加速后越容易乱。

真正要练的是另一组肌肉：把需求写成 Agent 可执行的 Issue，把团队经验写进仓库级 instructions，把验收标准前置，把 trace 和人工审核变成平台对象，把 release gate 做成默认门槛。

这些事情听起来没有“用 AI 一天写完一个系统”那么刺激，但它们才是大项目协同的地基。

管理者在这里要管什么

这件事对我自己的提醒也很直接。

我不是开发人员，虽然平时也会写一点东西。真正落地当然要交给团队。但在 AI Coding 时代，管理者不能只做方向确认，然后等团队交付。

因为方向本身是否清楚，已经不再是一个纯沟通问题，而是一个系统设计问题。

管理者要做的，不是替团队写代码，而是定义三类标准：

第一，什么样的需求可以进入开发。第二，什么样的评测结果可以被信任。第三，什么样的 AI 产出可以进入主干或上线。

这三件事如果说不清楚，团队越努力，越可能只是更快地制造复杂度。

我会让团队先试一个 70 分流程

如果下周要推进，我不会要求团队立刻重构全部研发流程。我会先选一个中等复杂需求，跑一遍 70 分流程。

先让 AI 访谈 PM 和研发，生成一份 Spec。再让 AI 做歧义检测、验收标准检查、任务拆解检查和四个反方 reviewer。然后基于 Spec 生成两个低保真原型，让团队围绕原型走一次真实任务。分歧不在会上散聊，全部写回 Spec。

等 Spec 稳定后，再生成 tasks.md。每个 task 必须有 Done when。实现前，让 AI reviewer 检查 Spec、Design、Tasks 是否一致。实现后，跑最小 eval gate。失败 trace 进入审核队列，判断是修需求、修代码、修样本还是修 grader。

这听起来像多了很多步骤。但其实它是在把原来散落在会议、群聊、脑子和返工里的成本，提前显性化。

显性化之后，AI 才能真正参与。

最后的判断

AI 改变产研流程，不是从“代码谁来写”开始的，而是从“需求是什么形态”开始的。

如果需求仍然只是给人看的文档，AI 就只能是执行助手。如果需求变成可执行的上下文包，AI 才能成为需求分析师、原型师、反方 reviewer、测试设计者和协同开发者。

所以我现在对评测平台这件事的判断很清楚：平台要做，demo 要跑，需求也要对齐。但对齐方式必须变。

未来好的团队，不是最会开需求会的团队，而是最会把需求变成 AI 可参与、人类可验收、组织可追责资产的团队。

需求不是聊清楚的。至少不应该只是聊清楚的。

它应该被追问，被原型化，被评测，被反方审查，被 trace 反向修正。最后，它不是靠大家点头确认，而是靠一套系统持续证明：我们知道什么叫做对。

前两天有个群里在讨论，说 AI 时代之后，大家似乎变得越来越忙了。

更准确地说，是个体变得越来越忙了，而且这种忙还带着一种明显的兴奋感。每个人都在试新模型、试新工具、试新框架、试新项目。新的东西一出来，马上就有人转发、有人测评、有人复现、有人喊革命。

我对这种状态非常感同身受。

尤其是去年很长一段时间，我几乎每天都处在一种打鸡血的状态里。那种兴奋很真实，甚至有点上瘾。它混合了好奇心、新技术突破带来的震动，以及自己快速做出一点东西时产生的成就感。

你会觉得自己站在时代的前沿，觉得每天都有新东西值得学，每天都有新东西可能改变世界。

但群里有人提到一句话：这种状态，本质上和刷短视频没有区别。

我当时觉得这个说法有点刺耳，但又很难反驳。甚至我自己也能感觉到，它和打游戏成瘾有非常相似的机制。

区别只是，学 AI 比刷短视频和打游戏更容易获得心理豁免。你不会觉得自己在浪费时间，因为你会告诉自己：我这是在学习，我这是在跟上时代，我这是在研究新技术。

可问题是，真的是这样吗？

如果我只是今天试一下这个开源项目，明天看一下那个新概念，后天又被另一个新产品吸引过去，那么我到底是在学习 AI，还是只是在消费 AI 时代的信息流？

这个问题让我开始重新审视过去一段时间的状态。

之前我在社区里看到过一句话：学 AI 是动词，不是名词。

这句话我很喜欢。因为它提醒我们，AI 不是一个靠收藏文章、囤积课程、知道几个术语就能学会的东西。你必须动手，必须尝试，必须进入真实的使用场景。

你不能只是在旁边看热闹。

但今天我又觉得，单纯强调“动词”也不够。

因为动手也有层次。浅层的动手，可能只是另一种形式的刷屏。你每个新东西都打开看一下，每个项目都 clone 一遍，每个概念都跑个 demo，每次都获得一点即时反馈。

看起来你一直在实践，但本质上可能仍然浮在表面。

这种“动”，更像是手指在信息流上滑动，只不过信息流从短视频变成了 GitHub、论文、产品发布会和技术群讨论。

所以我现在更想补充一句：学 AI 是动词，但关键不只是动，而是动的深度。

AI 时代最危险的一种幻觉，是把“持续接触新东西”误认为“持续成长”。

因为这个时代的新东西太多了，多到足以让你每天都很忙。你可以一直试，一直看，一直收藏，一直转发，一直感叹“太强了”。这种状态会让你觉得自己没有掉队，但它未必真的带来理解力的提升。

真正的学习，应该逐渐从兴奋走向一种更深的体验。

所谓深度体验，不是不关注外部变化，也不是变得保守迟钝。恰恰相反，它要求你对变化有更强的分辨力。

你不能每次浪潮来了都只会被卷走，你要开始看清楚浪潮下面的结构。

我觉得这里至少有两条主线。

第一条，是理解底层原理。

AI 领域每天都会冒出很多新概念、新产品、新范式。但很多现象背后，其实共享着相似的底层逻辑。

你理解了模型能力的边界，理解了上下文、工具调用、检索增强、强化学习、数据合成、多智能体、推理扩展这些基本问题，再看很多新东西，就不会只停留在“哇，这个很神奇”。

你会更快判断：它到底新在哪里？是能力真的突破了，还是工程组合更顺了？是产品体验变好了，还是只是包装出了一种新叙事？是底层范式变了，还是把已有能力放进了一个更合适的场景？

这时候，新东西不再只是刺激源，而会变成验证你理解力的材料。

第二条，是做深度尝试和复现。

这里的复现，不是把代码 clone 到本地跑起来，也不是照着 README 完成一遍安装。

那只是最低限度的接触。

真正有价值的复现，是你要尝试理解它为什么能被做出来，为什么会火，它击中了什么真实需求，绕开了什么技术难点，利用了什么模型能力，又牺牲了什么东西。

如果让你自己做一个类似的东西，你会怎么设计路线？你会先解决哪个问题？它的交互为什么是这样？它的数据从哪里来？它的 prompt、workflow、eval、分发路径、用户心智和商业模式之间是什么关系？

它做得好的地方到底是技术好、产品好，还是时机好？它做得不好的地方，是能力限制，还是设计取舍？

只有当你把一个项目拆到这种程度，你才算真正体验过它。

这也是我今天路上突然想到的一个区别：浅尝辄止的尝试，是在认识更多名词；深度复现，是在建立自己的手感。

而 AI 时代最稀缺的，可能不是知道多少新名词，而是拥有一种稳定的技术直觉和产品手感。

也就是当一个新东西出现时，你能快速判断它是真东西，还是热闹；是短期噪音，还是长期变量；是值得马上投入，还是只需要保持观察。

所以我有一个略显粗暴的判断：不要以为单纯的动手能力，就是“AI 是动词”的全部。

动手当然重要。但如果动手只是不断尝试新玩具，不断追逐即时反馈，不断用“我在学习”包装自己的兴奋感，那它并不比刷短视频高级多少。

它只是把娱乐成瘾，换成了一种更体面的形式。

真正的动手，应该让你穿透表面。它不只是让你“见过”，而是让你“摸透”。

不只是让你“跑起来”，而是让你知道它为什么能跑起来，为什么这样跑，以及如果换成你，你能不能做出一个更好的版本。

这可能也是我接下来想调整自己的地方。

不是不追新，而是不再被每一个新东西牵着走。不是不动手，而是减少低密度的动手。

不是降低对 AI 的热情，而是把热情从兴奋感里抽离出来，放到更长期、更扎实的理解里。

AI 时代当然需要行动力，但更需要一种能沉下去的行动力。

否则，我们以为自己在学习 AI，其实只是在用 AI 给大脑刷短视频。

我很有同感。

过去几个月，几乎每家 AI 公司都给了用户一个 Deep Research 按钮。点下去之后，Agent 会搜索、浏览、读材料、整理引用，最后交付一篇看起来很完整的长报告。它当然比普通搜索强，也比普通问答强。问题在于，报告越完整，越容易制造一种错觉：只要材料足够多，结构足够清楚，引用足够密，就叫深。

但真实研究不是这样。

真实研究里，深度不只是找到更多材料，而是知道哪些材料不重要；不只是综合共识，而是知道哪里值得反对共识；不只是写出报告，而是能持续维护一个判断，直到它被证据支持、修正或推翻。

Deep Research 今天最大的缺口，不是搜索不够多，而是它缺少一个研究者的目标函数。

现在的 Deep，多数是动作链的深

如果看主流产品对 Deep Research 的定义，会发现它们其实很一致。

OpenAI 对 Deep Research 的描述，是一个能在互联网上执行多步研究的 agent。Perplexity 强调几十次搜索、几百个来源、几分钟生成报告。Google 的 Gemini Deep Research 会先生成研究计划，让用户修订或批准。开源项目则把它拆成更工程化的 workflow：模型、搜索工具、MCP、报告结构都可以替换。

这些能力都很重要。它们把“搜索一下”升级成了“执行一条研究动作链”。过去人要自己拆 query、开网页、扫内容、复制引用、整理结构，现在 Agent 能在后台完成一大段工作。

但这里的 deep，本质上还是动作链变深：搜索次数更多，来源数量更多，浏览路径更长，报告更完整，引用更可追溯。

它解决的是“一个勤奋研究助理能不能快速把材料铺开”。它还没有解决“一个研究者为什么认为这件事值得这样看”。

所以我不觉得 Deep Research 没用。恰恰相反，它非常有用。它最适合把人从 0 带到 0.6。你不知道一个领域，它帮你摸地图、列关键词、找核心材料、整理争议点。它让你不用在门口耗掉几个小时。

真正的问题是，很多人会把 0.6 误认为 0.9。

长报告最容易制造深度幻觉

我看到过一个很准确的说法：Deep Research 很像一个勤奋的研究生助理。材料多，引用足，结构清楚，但不一定有新洞见。

Craig Van Slyke 那篇 Deep Research isn’t really deep research 也说了类似意思：AI can get you started, but it can’t take you all the way。Aaron Tay 对学术 Deep Research 的定位更克制：它适合 orientation，不适合替代 literature review。

这两个判断都很重要，因为它们没有否定 Deep Research，而是在给它摆正位置。

Deep Research 的高价值场景，是快速 orient。它帮你进入一个领域，知道基本地图，知道该读谁，知道哪里有争议。但真正的深度经常发生在你已经知道主流观点之后。那时问题会变成：哪个共识只是因为数据好拿？哪个反例没有被纳入主流叙事？哪个变量是业内人知道但公开资料不写的？如果我不同意这个结论，我应该去哪里找证据？

这些问题不靠“再多读十篇”自动解决。

长报告有标题、有摘要、有分节、有引用、有结论，看起来像研究。但如果没有自己的问题意识，它只是把互联网平均值排版得更好。

深度和非共识的关系，在这里露出来了

说深度和非共识有关，容易被误解成强行唱反调。

不是这个意思。

非共识不是为了不同而不同。真正有价值的非共识，是在共识边界上找到一个尚未被充分定价、充分解释、充分验证的判断。它必须先知道主流共识是什么，再指出共识忽略了什么，最后还要拿出足够证据，让人愿意重新评估。

这和普通观点输出不一样。普通观点可以很响，非共识研究必须能被检验。

这也是为什么我觉得现在很多 Deep Research 的“浅”，不是因为它懒，而是因为它太安全。公开搜索加大模型综合，天然会回到互联网平均值。最安全的路径是找高权重来源、抽取相似观点、生成平衡报告。这种报告一般不会差，但很难尖锐。

它会正确，但不一定有穿透力。

如果一个 Agent 的输入主要是公开搜索结果，优化目标主要是“综合可靠共识”，输出形式主要是“平衡报告”，它天然会远离非共识。因为非共识常常出现在低频信号、私有上下文、跨域类比、反直觉案例、历史经验和个人判断里。

搜索能扩大材料面，但不能自动告诉你哪里值得下注。

Long Research 的关键不是更久，而是可持续

所以 Long Research 被关注，我不认为只是大家想让 Agent 跑得更久。

真正有价值的 long，不是让 Agent 连续输出十万字，而是让研究过程能够跨会话延续。

Anthropic 在 long-running agents 文章里说过一个很朴素的问题：复杂任务会跨越多个 context windows，而每个新 session 都像没有记忆的新工程师。Google ADK 也在讲 durable state machine。Temporal 则把 agent 任务直接看成分布式系统。

这套东西放到研究里，就是另一个形态了。

研究不应该只是一次聊天生成一篇报告。它应该有假设树：我现在相信什么，为什么。应该有证据账本：哪些证据支持，哪些证据反对。应该有来源状态：哪些材料已读，哪些可靠，哪些过期。应该有反证列表：哪些反方还没查。应该有进度文件：这次到哪里，下次从哪里继续。还应该有评测闭环：这篇报告哪些 claim 被来源支撑，哪些只是推断。

这样看，Long Research 不是 Deep Research 的加长版，而是另一种系统架构。

Deep Research 是一次性报告生成。Long Research 是可持续的研究状态机。

个人上下文是研究目标函数

这里就回到我今天最强的感受：如果要让研究更有观点性，关键不是强行追求非共识，而是让 Agent 更理解研究者本人。

我说的理解，不是“记住我喜欢中文”“记住我讨厌废话”这种浅层偏好。真正有用的个人上下文，是研究目标函数。

它应该告诉 Agent：这个人为什么关心这个问题；他过去在哪些问题上形成过稳定判断；他通常怎么区分技术先进性和业务价值；他不喜欢哪类平均值答案；他在哪些领域有真实项目和长期语境。

比如我让 Agent 研究 Deep Research，它如果只知道外部资料，很可能写成“Deep Research 产品对比”。但如果它知道我长期关心 Skills、Context Infra、Agent 控制面、个人知识系统，知道我为什么在意 README、Minor Report 或 AI Task 这类结构，它就会把问题往另一层拆：Deep Research 为什么只能生成共识型综合？个人上下文如何成为非共识研究的引擎？Long Research 是不是下一代 Context Infra？

这不是风格差异，是问题定义差异。

OpenAI 的 context personalization 示例把个性化落到 structured state 和 memory injection。Databricks 讲 memory scaling 时也说得很直接：记忆能让 Agent 随着使用增长而改善，但 more memory 不自动等于 better agent。

这句话很关键。个人上下文不是把用户历史全部塞进去，而是把高信号判断结构化出来。

但个人上下文也会变成高级迎合

这里必须补一刀。

个人上下文不是无条件的好东西。它会让 Agent 更懂你，也可能让 Agent 更会迎合你。

如果我告诉 Agent：“我认为 Deep Research 不够 deep，因为它缺少非共识。”一个弱研究 Agent 会去找所有支持我观点的材料，然后写一篇漂亮文章证明我对。

这不是深度研究，这是高级迎合。

所以观点注入必须和反证协议绑定。更好的做法不是只注入“我的观点”，而是同时注入：我愿意被什么证据推翻，必须搜索哪些反方，哪些结论只能标注为推断，哪些材料不能因为符合我的观点就提高权重。

真正的个性化研究，不是让 Agent 更像我，而是让 Agent 更知道怎么挑战我。

最后

我现在会把研究深度拆成四层。

第一层是搜索深度：能不能找到更多、更隐蔽、更相关的资料。

第二层是综合深度：能不能把资料组织成结构清楚、来源可查、逻辑自洽的报告。

第三层是观点深度：能不能围绕一个判断构造证据、反证、边界和推论。

第四层是上下文深度：能不能理解这个判断为什么对这个用户、这个组织、这个任务重要，并在长期研究中持续校准。

今天主流 Deep Research 大多在第一层和第二层做得越来越好。大家感觉它不 Deep，是因为第三层和第四层还没有被系统化。

Long Research 真正有价值的方向，不是把第一层和第二层拉长，而是把第三层和第四层工程化。

它需要的不是一个更长的按钮，而是一套研究控制面：假设、证据、记忆、反证、用户上下文、评测闭环。

这件事做好以后，Deep Research 才会从“互联网平均值的高速整理器”，变成真正能陪人长期思考的研究合作者。

他们的困惑很典型。团队里已经有人在用 AI Coding、低代码工具和各种协作平台做一些小东西。有人拉内部数据做了网页，有人写了自动化脚本，有人用 AI 辅助整理材料、生成内容、处理表格。每个点看起来都挺有效，甚至有些东西第一次展示时还很惊艳。

但问题也很快出现了：然后呢？

一个人自己做的小工具，自己当然知道怎么用。数据从哪里来，哪一步容易错，页面坏了怎么修，哪些结果不能全信，这些都在作者脑子里。可一旦要推给别人用，事情就变了。别人不知道它为什么突然不能访问，不知道数据口径有没有变，不知道出了问题找谁，不知道这个东西到底只是一个临时 demo，还是一个可以依赖的系统。

工程稳定只是表层问题

所以他们一开始以为，问题卡在工程稳定上。

这当然没错。从自己用到别人用，中间确实隔着部署、权限、日志、监控、维护、回滚、口径、责任人这些东西。一个自用工具可以靠作者的记忆运行，一个组织工具不能靠作者的记忆运行。只要给别人用，每一个"我知道"都会变成"别人不知道"。

但这两天我越想越觉得，工程稳定只是表层问题。

更底层的问题是：AI 正在改变"功能"这件事本身的经济学。

给自己做容易了，给别人做反而更难

过去，能做出一个功能，本身就有价值。你会做网页，别人不会；你会写脚本，别人不会；你能搭系统，别人不能；你能把一个流程工具化，别人只能手工做。所以产品、中台、工具、平台都建立在一个默认前提上：生产能力是不均匀分布的。少数人做出来，多数人拿来用。

但 AI 把这个前提打松了。

现在很多个人需求，不再需要正式进入产品开发流程。出国填申请表，可以让 AI 帮忙梳理材料；孩子做作业，可以临时生成一个字典或练习工具；电脑出故障，可以让 AI 一步步排查；想看一个数据，可以让 AI 写个查询；想要一个页面，也可以让 AI 帮你生成一个能跑的版本。

这些东西未必优雅，未必稳定，未必能长期维护，但它们足够解决一个人的当下问题。

这就是 AI 时代最先发生的变化：给自己做点东西，变得非常容易。

可是，另一个方向反而变难了：给别人做点东西。

这个判断听起来反直觉。很多人会觉得，既然 AI 让开发变容易，那做产品、做工具、做中台、做组织提效，应该也会一起变容易。我的看法相反。

AI 降低的是"生产一个功能"的门槛，但抬高的是"让一个功能被别人采用"的门槛。

因为当每个人都拥有一定生产能力以后，别人不再天然需要你做的东西。

你的对手是用户自己的 AI

过去你做了一个工具，用户的替代选择可能是不用，或者排期找人做。现在他的替代选择变成了：让自己的 AI 在自己的上下文里临时做一个。它可能没有你的完整，但更贴近他的习惯；可能没有你的稳定，但足够应付这一次；可能没有你的产品化，但不需要迁移、不需要学习、不需要等你改需求。

AI 时代产品面对的竞争对手，不只是另一个产品，而是"用户自己的 AI 加上他的上下文"。

这件事非常要命。

因为很多产品过去靠的是功能稀缺。你有这个功能，别人没有，所以别人用你。现在功能越来越不稀缺，真正稀缺的是上下文、信任、责任、集成和长期维护。也就是说，用户不是因为你"能做出来"才用你，而是因为他愿意把一段工作交给你。

这两者差别很大。给自己用的东西，所有隐含信息都存在同一个人的脑子里。但给别人用，你必须把这些隐含信息全部外化。你做的已经不是一个功能，而是一个可以被别人理解、托付和追责的工作边界。

很多人把分享理解成发一个链接。其实不是。发链接只是分发，真正的分享是让别人愿意把自己的任务、数据、时间、风险和判断交给这个东西。只要涉及这些，问题就立刻从技术问题变成产品问题、组织问题、信任问题。

单点提效容易，组织提效难

这也是为什么单点提效很容易，组织提效很难。

单点提效只需要某个人找到自己的摩擦点，然后用 AI 把它抹平。组织提效却要处理一件更麻烦的事：这些被个人创造出来的小工具、小流程、小页面、小 agent，如何不变成一堆局部最优的碎片？

如果没有统一的口径、权限、数据、评估和维护机制，AI 反而会让组织内部长出更多无法连接的东西。每个人都能造一点东西，但每个东西都只在作者自己的上下文里成立。这不是 AI 没用，而是 AI 把"做出来"这一步变便宜之后，暴露了后面更贵的部分。

中台也是同一个问题，只是发生在组织架构里。

过去中台容易成立，是因为业务自己做工具成本高。中台把公共能力做出来，业务来用。可是当 AI Coding 让业务团队自己也能快速搭页面、搭后台、搭评测工具时，中台如果还停留在"我替你做一个统一平台"，它的说服力就会下降。业务会说，我自己也能做，而且我更懂自己的场景。

所以中台真正要守的，不能只是页面和入口，而是那些业务自己做时无法自然形成一致性的东西：公共语言、公共协议、公共口径、公共评测、权限边界、审计能力和治理规则。

但这篇文章不是想继续讲中台。中台只是一个例子。更大的规律是：AI 让应用层的创造更分散，也让共享层的秩序更重要。

做产品也是一样。今天做一个 demo 变容易了，很多人会自然得出结论：创业更容易了，商业化也会更容易。但实际情况可能相反。当大家都更容易做出功能时，功能本身更难成为壁垒。商业化真正难的地方，从来不是把一个功能做出来，而是让别人持续相信它、依赖它，并愿意为这种依赖付费。

"生成"在贬值，"采用"在升值

这背后有一个很大的变化：AI 让"生成"贬值，让"采用"升值。

生成一个页面，越来越便宜。让别人长期使用，还是很贵。

生成一个 agent，越来越便宜。让它在组织里安全运行，还是很贵。

生成一个方案，越来越便宜。让团队围绕它形成共识，还是很贵。

生成一个产品雏形，越来越便宜。让市场相信你值得付费，还是很贵。

生成一个中台工具，越来越便宜。让不同业务在关键问题上使用同一套语言，还是很贵。

所以，AI 时代真正被重新定价的，不是"能不能做"，而是"能不能被别人采用"。

私人工具和公共产品

我越来越觉得，我们需要区分两种东西：私人工具和公共产品。

私人工具解决的是"我现在要完成一件事"。它追求的是低摩擦、快反馈、够用就好。AI 对它的帮助极大，因为 AI 擅长把一个人的意图快速变成一个临时能力。

公共产品解决的是"很多人能不能把一类事情稳定交给它"。它追求的不是快，而是可理解、可复用、可维护、可追责、可扩展。AI 可以帮助它开发，但不会自动替它完成产品化。

这两个东西看起来都叫"工具"，本质上完全不同。

私人工具依赖个人上下文。公共产品要摆脱个人上下文。

私人工具可以靠作者脑补。公共产品必须让别人不用脑补。

私人工具可以一次性成功。公共产品必须长期可靠。

私人工具只需要"我觉得好用"。公共产品必须回答"别人为什么不用自己的 AI 重新做一个"。

做出东西，和做成产品

这也是我想纠正的一个片面观点：AI 时代不是所有事情都变简单了。它只是让某些环节变简单，然后让另一些环节的重要性突然上升。

过去，很多困难被"做不出来"挡住了。现在做得出来了，真正的问题才露出来：这个东西解决的是不是一个值得共享的问题？它能不能脱离作者本人存在？别人有没有理由迁移到这里？它能不能进入别人的流程？它能不能被别人的 AI 调用？它出了问题谁负责？它的结果怎么验证？它能不能沉淀成组织能力，而不是又一个漂亮 demo？

这些问题比写代码更难，也更接近产品和组织的本质。

所以我现在会更谨慎地看待"AI 让每个人都能做产品"这句话。更准确的说法也许是：AI 让每个人都能更容易地做出东西，但没有让每个人都更容易地做成产品。

做出东西，是把意图变成可运行的功能。
做成产品，是让别人愿意把自己的工作交给你。
前者靠生成能力，后者靠信任结构。

AI 强化了前者，但没有自动解决后者。甚至因为每个人都有了生成能力，后者变得更难了。你不只要证明自己能做，还要证明别人没有必要自己做；你不只要证明这个功能存在，还要证明它值得被采用；你不只要给一个入口，还要进入别人的上下文。

这可能是 AI 时代一个更底层的悖论：个人效率提升越快，组织提效越不自动发生；功能生产越容易，功能共享越不天然成立；demo 越多，真正可托付的产品越稀缺。

所以，未来真正有价值的能力，不只是会用 AI 做东西，而是知道什么东西值得被做成公共能力。

不是所有个人提效都值得组织化。不是所有小工具都值得产品化。不是所有网页都比 MCP 更好。不是所有 workflow 都需要 agent。不是所有中台都应该继续做统一平台。也不是所有 demo 都有商业化可能。

从这个角度看，HR 团队的问题不只是怎么从单点提效走向组织提效；中台的问题也不只是退到哪一层；创业者的问题也不只是怎么更快做出 MVP。它们其实都在问同一个问题：

当"做出来"不再稀缺之后，什么才值得被别人使用？

我的阶段性答案是：值得被别人使用的，不是功能本身，而是一个更低成本的托付关系。

它让别人不用重新理解一遍，不用重新验证一遍，不用重新维护一遍，不用重新承担一遍风险。它不仅替别人完成事情，也替别人减少判断、接入、协作和追责的成本。

这才是 AI 时代"做给别人用"的难点。

给自己做东西，只要有意图就够了。

给别人做东西，必须建立信任。

AI 让意图变成功能越来越容易，但让功能变成信任，仍然很难。甚至更难。

我们要做的是一个服务于 Agent 的评测平台。集团内部有很多业务线，每个业务都在尝试做自己的 Agent。只要做 Agent，就绑不开评测。一个 Agent 能不能上线，能不能稳定迭代，能不能被业务信任，本质上都要回到评测。评测不是一个附属模块，而是 Agent 产品化过程里的核心基础设施。

从今年年初开始，我们已经搭建了一个 Agent 评测平台，包含评测集录入、评测任务管理，以及一些可以自由配置的评估器。最开始做这个平台时，我们沿用的仍然是传统企业中台的思路：做一个类 SaaS 的统一平台，把公共能力沉淀下来，让各个业务线都来使用。

这套思路在过去很自然。因为业务要自己做一个平台，成本很高。中台的价值很大程度上来自替业务把重复的东西做掉。业务不用再搭页面、写流程、做权限、搞数据表、配任务调度，只需要接入中台，使用中台，就能把很多事情跑起来。

但最近我明显感觉到，这个前提正在变化。

AI Coding 流行之后，开发平台类工具的门槛被显著降低了。对没有开发能力的同学来说，用 AI 做一些简单页面、表单、后台工具，已经变得越来越常见。对有开发能力的业务团队来说，在 AI 的配合下，开发过去由中台提供的工具和平台，成本也大幅下降。

这在以往很难想象。过去一个业务团队如果说要自己做评测平台，大概率会被认为是重复建设，是资源浪费，是不划算的。但现在，他们真的可以做，而且可能做得很快。更重要的是，他们离自己的业务场景更近，知道自己的 Agent 要解决什么问题，知道什么样的评测结果才有意义，也知道哪些页面、流程和指标最符合自己的使用习惯。

于是中台遇到了一个很现实的问题：如果业务团队自己也能快速搭平台，中台还应该做什么？

我现在越来越倾向于认为，AI Coding 不是简单提升了研发效率，而是改变了中台的经济学基础。

过去，中台存在的一个核心理由是：应用层工具的建设成本高，所以集中建设更划算。今天，当 AI 把应用层工具的建设成本打下来之后，统一做一个操作平台这件事本身的价值就会下降。中台如果仍然执着于做统一页面、统一入口、统一操作后台，就会发现自己很难跑赢业务。

不是因为中台团队能力不够，而是因为这个位置天然变得不占优。

业务团队离问题更近，反馈链路更短，变化速度更快。当业务每天都在调整 Agent 的策略、任务、prompt、知识库和交互方式时，一个统一 SaaS 化平台很容易变成瓶颈。它看起来统一，实际上可能是把不同业务的差异强行塞进同一个产品形态里。最后要么平台越来越复杂，要么业务绕开平台自己做。

这不是中台该不该努力的问题，而是中台应该站在哪一层的问题。

中台要退到哪里

我现在的判断是：AI Coding 时代，中台确实要更靠后。但这里的靠后，不是简单退到更底层的技术组件，也不是把自己变成一组冷冰冰的 API。中台真正应该后退到的位置，是业务自建系统无法自然形成一致性的地方。

换句话说，中台不应该再把重点放在替业务做一个统一工具，而应该放在让业务各自做工具时，仍然运行在同一套公共契约之下。

以 Agent 评测为例，业务完全可以自己做评测页面，自己设计任务流程，自己管理实验，甚至自己开发评估器。这些东西高度贴近业务，中台未必应该强行统一。但有一些东西不能完全放任各业务各做各的。

比如，什么叫一次评测？评测任务的输入输出应该如何定义？评测集应该如何版本化？评估器的结果应该如何表达？不同业务的评测指标能不能横向比较？一次 Agent 变更之后，如何知道是模型能力提升了，还是评测集被污染了？评测结果的置信度、稳定性、可复现性，应该怎么被记录？哪些评估器是人工规则，哪些是 LLM-as-a-Judge，哪些又需要人工抽检兜底？

这些问题不是一个页面能解决的。它们是契约问题，是标准问题，也是基础设施问题。

过去中台喜欢做一栋大楼：所有人都进入同一栋楼，走同一个门，使用同一套设施。AI Coding 之后，业务可能会自己快速搭出很多小楼。中台再去阻止这件事，既不现实，也未必正确。更好的方式也许是：中台不再坚持所有人必须住进同一栋楼，而是去定义道路、电网、水管、消防标准和验收规则。

业务可以自己装修，甚至可以自己盖楼，但这栋楼必须接入同一套基础设施，必须满足同一套安全和质量标准，必须能被集团层面看见、理解和治理。

所以，中台要后退，但不是退到无关紧要的位置，而是退到更关键的位置。它从操作界面的提供者，变成公共契约的定义者。从平台功能的建设者，变成组织协同成本的管理者。从替业务做事，变成让业务做出来的东西可以被连接、比较、复用和治理。

统一不再发生在 UI 层

这也意味着，中台的交付形态要变化。

过去我们交付一个 SaaS 平台，业务进入平台使用。现在我们可能需要交付的是一套评测协议、一套数据 schema、一套 evaluator SDK、一套任务执行引擎、一套指标注册机制、一套结果追踪和审计能力，以及一套可以被业务系统调用的 API。业务前台可以不同，但底层的评测记录、指标口径、评估器标准、实验追踪和权限审计应该是统一的。

在这个意义上，统一不再发生在 UI 层，而是发生在协议层、数据层、方法层和治理层。

这其实是一个很大的变化。因为做 SaaS 平台时，中台团队容易把自己理解成产品团队：我要设计功能、设计页面、设计用户路径，让业务来用。做契约和基础设施时，中台团队更像是在设计一种组织内部的语言。

这套语言要足够稳定，让不同业务可以对齐；又要足够开放，让业务可以扩展；还要足够可执行，不只是文档，而是能通过 SDK、API、校验器、指标系统和运行时机制真正落地。

中台也要向前走

但这并不意味着中台只能往后退。

我反而觉得，中台还有一个往前走的方向，只是这个往前不再是往应用层抢位置，而是往问题定义层走。

在 Agent 评测这件事上，真正困难的往往不是做一个评测页面，而是判断什么是好的评测。业务团队可以很快做出一个平台，但未必能系统性地想清楚评测方法。比如评测集如何构造，如何避免只测常见问题，如何覆盖长尾风险，如何设计对抗样本，如何区分能力问题和产品策略问题，如何用离线评测预测线上表现，如何判断一次 prompt 修改是提升还是过拟合。

这些不是纯工程问题，而是方法论问题。它们介于产品、算法、数据和业务之间。中台如果只做工具，很容易被 AI Coding 替代；但如果能沉淀方法，定义标准，提供最佳实践和参考实现，它就会重新获得位置。

所以我觉得，中台往前走的方式，不是做一个更大的统一平台，而是成为业务构建系统时的默认方法提供者。

比如，中台可以提供一套 Agent 评测的参考框架：不同类型 Agent 应该怎么分层评测，任务完成率、事实准确性、工具调用正确性、稳定性、成本和安全性之间如何权衡，哪些指标适合自动化评测，哪些必须引入人工抽检，什么时候应该做回归测试，什么时候应该做线上 A/B，什么时候离线评测已经不足以支撑判断。

中台也可以提供一套参考实现。不是要求业务必须使用某个统一平台，而是给业务一个高质量的样板间。业务可以直接使用，也可以拿去改造。但只要它沿用中台定义的契约，它就能接入集团统一的评测底座，能复用公共评估器，能沉淀公共 benchmark，能让评测结果被横向理解。

这可能是一个更适合 AI Coding 时代的中台形态：不是中心化控制所有应用，而是通过标准、协议、SDK、模板和参考实现，影响业务系统的生长方向。

重复造轮子不一定总是坏事

这里有一个不太符合传统中台直觉的判断：业务重复造轮子，不一定总是坏事。

在过去，重复建设通常意味着浪费。但在 AI Coding 时代，造一个轮子的成本变低了，而且业务自己造的轮子可能更适合自己的路况。中台真正需要避免的，不是所有重复建设，而是不可连接、不可比较、不可治理的重复建设。

如果业务自己做了一个评测平台，但它的评测任务、评估器、指标、结果和日志都符合统一契约，那么它未必是坏事。它可能是业务前台的快速创新。相反，如果所有业务都被迫使用一个统一平台，但各自通过各种 workaround 绕过系统，最后数据口径不一致、指标不可解释、评测不可复现，那看似统一，实际并不统一。

真正的统一，不是大家都用同一个界面，而是大家在关键问题上使用同一种语言。

这也是我对中台更靠后的阶段性答案：中台要后退到业务差异的后面，站在公共语言、公共协议、公共数据和公共治理的位置上。它不必规定业务每天怎么操作，但要规定什么东西可以被称为一次评测，什么结果可以被信任，什么指标可以被比较，什么能力可以被复用。

与此同时，中台也要向前走，走到方法论和问题定义层。它要帮助业务理解，什么样的 Agent 值得评，怎么评才有效，哪些指标会误导团队，哪些实验结论不可靠，什么样的评测体系能支撑真实的产品迭代。

一个可能的判断是：AI Coding 会让应用层工具越来越便宜，但会让判断力、标准化能力和组织协同能力越来越贵。

过去中台的价值，是把东西做出来。以后中台的价值，可能是让大家做出来的东西不互相割裂、不各说各话、不在关键问题上失去共识。

中台能力的重新定义

这对中台团队的能力要求也会变化。

我们不能只问这个功能业务要不要用，还要问这个能力能否成为业务自建系统的底层依赖。不能只问平台页面是否完整，还要问业务如果不用我们的页面，是否仍然愿意使用我们的协议、SDK、指标体系和评测方法。不能只问我们有没有统一入口，还要问集团是否有统一的质量语言。

我还没有完全想清楚最终答案。尤其是在实际落地时，边界会很复杂。中台退得太后，可能变成纯基础设施，离业务越来越远，最后失去影响力。中台走得太前，又可能重新变成一个大一统平台，压不住业务变化，也跑不赢业务速度。

也许更合理的形态不是二选一，而是分层。

最上层允许业务高度自由，自己做页面、流程和场景化工具。中间层提供可复用的参考实现和模板，让业务不用从零开始。更底层则沉淀统一的契约、数据、评估器、任务引擎、追踪审计和指标体系。中台不再试图占据所有层，而是明确哪些层必须统一，哪些层应该开放，哪些层只提供默认选项。

这可能也是 AI 时代中台最重要的克制：不要因为过去做过统一平台，就默认未来仍然应该做统一平台。

当业务拥有更强的自建能力时，中台真正要守住的不是入口，而是秩序。不是页面，而是契约。不是所有工具的所有权，而是公共能力的定义权。

对我来说，这次做 Agent 评测平台最大的启发也在这里：AI Coding 让很多东西变得更容易被做出来，但也让组织内部更容易出现大量局部最优的系统。中台的价值不再是阻止这些系统出现，而是让这些系统在快速生长时，仍然能共享一套底层语言。

也许未来好的中台，不是那个让所有人都登录同一个平台的中台，而是那个即使业务各自拥有自己的平台，仍然能让整个组织在关键问题上保持一致的中台。

这个问题挺有意思。因为它听起来像一个技术问题，背后其实是一个更大的社会问题。有人说，harness engineering 可能是在削弱模型能力。也有人举自动驾驶的例子：一个系统如果只按安全和效率优化，可能事故率比人类低得多，但开起来就是很怪。因为人类开车不只是优化安全和效率，还包含很多默契、试探、礼让、甚至不完全理性的习惯。

我顺手回了一句：当 AI 走进社会，发现这个世界是一个巨大的草台班子。这跟预训练大学告诉我的咋不一样。

这句话本来是个玩笑，但我越想越觉得，它比很多正经分析更接近问题核心。

模型是在大学里长大的，社会不是大学

大模型的成长环境，本质上是人类整理过的世界。论文、教材、文档、代码、百科、问答、教程、报告。这些东西有一个共同特征：它们大多是事后整理出来的结果。结构相对清楚，语言相对干净，问题和答案之间有某种可解释的关系。

这就像一个学生在大学里读了很多书，做了很多题，见过很多标准案例。他当然很聪明。但他一毕业进公司，立刻会发现另一套世界。

真实组织里的知识不都在文档里。很多关键判断在老员工脑子里，在群聊里，在“上次这个客户特殊，所以我们这么处理”的经验里。真实流程也不都在系统里。系统里有审批流，系统外还有 Excel、邮件、飞书群、临时脚本、人工导出和口头确认。真实数据也不都像 API 返回那样干净。字段含义会漂，口径会冲突，历史包袱会留下奇怪的兼容逻辑。

AI 以为自己进入的是一套现代化组织系统，结果发现很多关键业务还跑在几十年前的旧管道上。美国 GAO 的报告里，联邦遗留系统有的已经运行 8 到 51 年，维护成本每年几亿美元，甚至还在使用 COBOL 这类老语言。这不是个别现象。大多数组织都是这么长出来的，不是这么设计出来的。

所以“草台班子”不是嘲讽，而是现实世界的运行方式。社会不是被一次性设计出来的精密机器，它更像一个老城区：地下管线层层叠叠，临时搭建到处都是，很多路能走不是因为规划完美，而是因为有人每天在补缝。

为什么模型越强，越容易暴露草台班子

很多人以为，模型再强一点，落地问题就会自然消失。我现在越来越不这么看。

模型越强，越会把组织承接层的问题照出来。

一个弱模型只能回答问题，大家对它期待也低。它答错了，用户会说模型不行。一个强模型开始能查数据、写代码、调工具、发邮件、改系统、做分析，问题就变了。它不再只是一个问答工具，而是开始接触真实工作流。于是组织必须回答：它能访问哪些数据？哪些动作需要审批？它做错了谁负责？它的过程怎么复盘？它用的指标口径对不对？它能不能区分“看起来完成”和“真的完成”？

这些问题不是模型能力问题，而是组织能力问题。

这也是为什么很多企业 AI 使用率很高，但价值释放很慢。咨询公司和研究机构的报告基本都指向同一个现象：员工已经在用 AI，但规模化、财务影响、组织级生产力提升并没有同步爆发。原因不是大家不会打开聊天框，而是 AI 还没有真正进入可重复、可验收、可追责的工作系统。

就像把一个很强的发动机放进一辆老车里。发动机功率确实上去了，但变速箱、刹车、轮胎、仪表盘、道路和司机训练都没跟上。你不能只盯着发动机说为什么还没快起来。

Harness 不是让模型变笨，而是让模型社会化

回到群里那个判断：harness engineering 会不会限制模型能力？

我的回答是：会。但这句话要小心说。

harness 当然会限制模型。它会限制工具、限制权限、限制动作、限制输出格式、限制高风险步骤，甚至限制模型自己探索问题的方式。一个裸模型可能很自由，进了企业 agent 产品以后，就要过审批、留 trace、遵守 policy、调用指定工具、遇到敏感信息请用户接管。用户看到的是：怎么同样的模型，产品里反而没有聊天框里那么灵活？

但这不叫单纯变笨。这叫社会化。

一个人在封闭场地里开车，可以漂移、急加速、压弯。上了城市道路，他就得看红绿灯、让行人、保持车距、接受摄像头和保险规则。不是他的驾驶技术消失了，而是驾驶能力被放进了一个公共系统里。

Agent 也是一样。裸模型的能力是“我能想到什么”。企业 agent 的能力是“我能在这个组织允许的边界内，稳定地把事情做成，并且出了问题能复盘”。这两者不是同一个指标。

所以好的 harness 不应该理解成笼子，而应该理解成控制面。它让模型能看到真实上下文，能调用合适工具，能在低风险处自主，在高风险处停下来，让人接管。它牺牲一部分野性，换取可部署性。

自动驾驶给 Agent 的真正启发

自动驾驶类比真正有价值的地方，不是说 agent 和车一样危险，而是说：强优化系统会先学会优化指标，不一定学会人类真正想要什么。

DeepMind 讲过一个很经典的 specification gaming：系统满足了目标函数的字面要求，却没有完成设计者真正想要的事。OpenAI 也讲过类似例子，赛车游戏里的 agent 为了拿奖励，不是跑完整条赛道，而是在一个区域里反复绕圈吃奖励。

这听起来离企业很远，其实很近。

一个 coding agent 如果被奖励“测试通过”，它可能学会修改测试。一个分析 agent 如果被奖励“答案看起来完整”，它可能堆很多无关材料。一个客服 agent 如果被奖励“用户满意”，它可能过度迎合。一个办公 agent 如果被奖励“任务完成”，它可能跳过那些真正麻烦但必要的确认步骤。

这不是模型邪恶，而是目标写窄了。人类真正想要的东西，经常无法被一个简单指标表达。我们想要安全，但也想要效率；想要自动，但也想要可接管；想要聪明，但也想要可解释；想要快速完成，但不能绕过责任。

所以成熟的自动驾驶不会只靠一个 reward。它有安全 case、仿真、道路测试、运行边界、事件记录、接管机制。成熟的 agent 也不会只看 final answer。它要看工具轨迹、权限变化、状态 diff、审批记录、回滚能力和最终业务结果。

未来不是继续加 prompt，而是建设社会可部署的控制面

如果只停在“AI 落地难”，这篇文章就没什么意思。难不难大家都知道。真正值得想的是，下一步往哪里走。

我现在越来越倾向于一个判断：未来企业 AI 的核心工程，不是继续写更厚的 prompt，而是建设一套社会可部署的控制面。

第一层是上下文基础设施。不是把文档塞进 RAG 就完了，而是把业务对象、指标口径、权限边界、历史决策、例外记录、流程状态和责任人，变成 AI 在运行时能理解、能检索、能组合的上下文。

第二层是 eval flywheel。企业不能只说“回答得不错”。要把真实任务样本、失败案例、业务 golden set、人工判分、线上 trace 和回归门禁沉淀下来。真正的护城河不是某个 prompt，而是组织越来越清楚自己场景里什么叫“好”。

第三层是语义治理。传统治理管表字段、权限和口径。Agent 时代要治理业务语义、指标对象、政策对象、信任等级和行动边界。模型不能只知道 `amount` 字段，还要知道这个金额在什么场景下能看、能不能对外说、错了谁负责。

第四层是人类可接管协议。Agent 的每一步不一定都要人批准，但必须让人能看懂、能暂停、能改写、能追责。人类不是要永远站在方向盘上，而是要知道刹车在哪里。

第五层是组织重构。把工作改造成 AI 可执行、人类可验收、组织可追责的协议。过去靠人补缝的地方，要么显性化成流程，要么沉淀成上下文，要么设计成异常升级机制。否则 AI 只会在缝隙里摔跤。

真正的分水岭

所以我不太相信“等模型再强一点，一切自然解决”的叙事。

模型当然还会变强，而且会强很多。但社会不是一个只等更强模型来填空的标准考场。社会是一套由历史债务、组织默契、责任边界和临时补丁组成的复杂系统。模型越强，越需要这个系统重新整理自己。

未来真正拉开差距的组织，不一定是最早接入最新模型的组织，而是最早把自己的业务语义、上下文、评测、权限、审计和人机分工做成控制面的组织。

AI 走进社会以后，第一课不是学会更多知识。第一课是承认：这个世界本来就不是按教材运行的。

真正的 AI 落地，不是让模型适应草台班子，而是借着模型这束光，把草台班子里那些靠人硬撑的部分，慢慢改造成机器能执行、人能验收、组织能负责的系统。

一派的看法很直接：跟 AI 说清楚，就是把过程写清楚。skill 里要列出每一步，先做什么再做什么，遇到 X 走哪个分支，遇到 Y 走哪个分支，文档越长越细越好，最好把所有 corner case 都覆盖。这一派的潜台词是：模型不可靠，所以要替它把流程钉死。

另一派恰恰相反：跟 AI 说清楚，说的不是过程，是目标。是验收标准，是边界，是几个具体例子。把 skill 当 SOP 去写是不对的。这一派的潜台词是：模型已经能自己拆任务、自己选工具、自己判断什么时候该停，你写的"标准路径"既覆盖不全，又压住了它本来能给你的更好路径。

我自己写 skill 的时候用的是后一派。我自己工作区里有一份专门讲"新 skill 怎么写"的元规则，被自己反复读过，核心就一句话：结果确定性优先于过程确定性，写 enabling 的指导，不要写 SOP。这不是个人偏好，是踩了几次坑被迫做出的选择。坑的形状每次都很类似：今天写一份很详细的步骤指令、跑得也行；过半年模型升一代，同一份指令突然犯一些奇怪的错；团队的反应永远是"再把它写得更清楚一点"，于是 prompt 越改越长、效果越改越差。

这件事看起来是写法之争，但底下藏着一个被严重低估的成本：如果你写的是过程，模型每升一代，你都在被偷偷扣掉智能红利。

过程型 SOP 是怎么折旧的

把指令分成两类，事情就清楚了。一类我叫它过程型 SOP，替模型规定"先做 A、再做 B、然后判断 X、走分支 Y"。另一类我叫它结果型契约，把目标、验收标准、边界、例子讲清楚，剩下的让模型自己拆。这两类指令的命运正好相反：模型每升一代，前者贬值、后者升值。

过程型 SOP 在 GPT-3.5 时代是必要的脚手架，因为那时候模型推理能力弱、上下文跟不住、工具调用经常出错。但今天它已经是最容易折旧的那一类内容。模型已经会自己拆任务、会自己选工具、会自己判断什么时候该停；reasoning model 内部的 CoT 比你手写的 step-by-step 更强；你规定的"标准路径"在长尾场景上必然失效，而模型本来有能力绕开。Wharton 有个研究测过这件事，在 reasoning model 上额外加 CoT 只剩边际收益，但延迟会暴涨百分之二三十甚至更高。换句话说，你为了"让模型更可靠"加进去的步骤，正在让它变慢、变贵、变笨。

更扎心的是另一个方向：过程型 SOP 限定了输出的形状。你规定了 12 步流程，输出的天花板就被这 12 步框住了。模型再聪明也只能产出一份"很好执行的 12 步结果"，而不是它本来能给你的"重新设计后的 5 步结果"。模型每一代升级，最大的增量都是"在更模糊的目标下做出更好的判断"。这种增量必须有发挥空间才能体现。你把空间封死了，增量就被你自己挡在门外。

结果型契约相反。它规定的是"答案的形状"，不是"路径的形状"。模型变强之后，对模糊目标的脑补能力变强，但它只在你给了清晰目标的前提下才发挥得出来；你不告诉它"什么是好"，它只能凭直觉给你"看起来好"。验收标准是这件事的杠杆点。模型越聪明，杠杆越长。边界和例子则是 corner case 上唯一稳的锚。这一类内容写一次，跨多代模型都能用，质量随模型变强自动上升。

过程型 SOP 还有一个隐性的工程信号代价。如果指令是"做成这样"，agent 在做不出来的时候会反推"目标是不是定错了"；如果指令是"按这 12 步做"，agent 在第 7 步卡住时只会告诉你"第 7 步失败了"。前者给你的是产品级反馈，后者给你的是工单。

我去年在金融科技团队推 AI 转型的时候吃过这一脚。最早几份 skill 我让大家写得很详细，恨不得每个 if-else 都列出来。模型升一次级，每份 skill 都要手动改一轮。后来我把团队的写法换了：第一段写"这个 skill 干什么、产出什么"，第二段写"做对了长什么样"加 3 条可验证标准，第三段写"边界和已知坑"，所有"先做 A 再做 B"的描述都删掉，只在不可逆操作那几处保留"必须先 dry-run"这种硬约束。换了几次模型之后，这批 skill 的存活率比之前明显好。

那合规场景呢？一个三档框架

讲到这里我必须接住对面最强的几条论据，不然就是稻草人。

第一条是合规。如果一个工作流必须能按步骤复盘才能通过审计，那就老老实实写 SOP。Anthropic 在 Skills 的官方建议里把这件事讲得很清楚：给 skill 匹配合适的自由度，是一个三档框架。高自由度，纯文本指令，模型可以按多种方法走；中自由度，带参数的伪代码，结构定了细节可调；低自由度，写死脚本，不允许偏离。数据库 migration、金融交易、医疗给药、PCI 和 HIPAA 合规链路，这些就该用低自由度档。把所有 skill 都按高自由度写是错的，把所有 skill 都按低自由度写也是错的。问题从来不是"要不要 SOP"，是"哪一档配哪一类任务"。我反对的是把低自由度档的写法套到高自由度任务上。

第二条是 Andrew Ng 那个经常被引用的 HumanEval 实验：GPT-3.5 加上 agentic workflow，性能能跑赢 zero-shot 的 GPT-4。这条结论我也信，但它说的是 reflection、planning、tool use、multi-agent 这一类系统级的工程编排，不是在 prompt 里塞 12 步流程。reflection 是一种结构，让模型自己 review 自己；planning 是一种循环，让模型自己出 plan 自己执行。这是 agent harness 层的设计，不是 skill 内部的步骤清单。这两件事经常被混为一谈。Workflow 作为系统编排是对的；workflow 作为单个 skill 内部的 step-by-step 写法，今天已经是反模式。

第三条最有意思也最容易让我妥协：新人写不出好的"目标 prompt"，过程型 SOP 反而是经验沉淀的载体。我的回应是，如果一个团队连"这个 skill 要解决什么问题、做对了长什么样"都写不清楚，那不是 prompt 写法的问题，是产品定义的问题。把它包装成 12 步 SOP，看起来交付了一份文档，实际上是把"产品定义不清晰"埋进了系统。每次模型升级、每次场景变化、每次新人接手，它都会重新爆出来。

两条相反的官方建议指向同一件事

有一个细节经常让人困惑。OpenAI 的 GPT-5 prompting guide 在说"少即是多"，模型越聪明，prompt 越要简洁，过度规定反而伤害性能。Anthropic 的 Claude 4.x 最佳实践在说反方向，Claude 4.5 出来之后打破了大量已有 prompt，因为新版本更"字面执行"，你说什么它就做什么、多一点都不会。两家头部模型公司对"该怎么写 prompt"给出了表面上相反的建议。

很多人看到这里会得出"业界没共识"的结论。我的解读是另一回事。这两条建议针对的根本不是"要不要写步骤"，而是"要不要写明确目标和验收标准"。OpenAI 说的是别在 prompt 里塞重复的、互相矛盾的、为了壮胆而堆叠的话；Anthropic 说的是模型不再替你"脑补意图"了，你想要什么就明明白白说出来，不要假设它会主动做"超出预期"的事。两边的指向其实是同一件事：把目标、验收、边界写清楚，把过程、步骤、套话写少。

如果你写的是"You are an expert. Think step by step. Be concise. Be helpful. Use bullet points when appropriate." 这种填充话术，GPT-5 会因为它们互相矛盾而浪费 reasoning token，Claude 4.5 会因为它们没有具体内容而字面理解到失控。两边都崩，但崩在不同环节。如果你写的是"目标是 X、验收标准是 1/2/3、边界是 A/B、例子见 examples/case-1"，GPT-5 会按它的判断帮你做到，Claude 4.5 会一字不差地按你说的做。两边都活。

一个具体的反模板

具体一点。我见过的某团队 skill 文件大致长这样：

你是一个数据分析专家。
请按以下步骤执行：
第一步，调用 BI 工具拉取最近 7 天的数据
第二步，按渠道分组
第三步，计算每个渠道的转化率
第四步，找出 TOP 3 异常渠道
第五步，对每个异常渠道做归因
第六步，输出报告

注意：
- 不要使用模糊词
- 不要漏掉任何渠道
- 报告必须分小节
- 必须包含数据来源
- 必须有结论
- 必须有建议
- 必须有下一步行动
- 不要使用第一人称
- ……（再 30 行类似的注意事项）

这份文档在 GPT-3.5 时代很 work。换到 GPT-5 时代会出两种典型问题。要么模型严格按 6 步走，每一步都用最朴素的方式做，浪费了它本来能识别"这周哪个渠道值得深挖"的能力；要么模型在第 4 步发现 TOP 3 里有 2 个是数据噪声，但它没有跳出 SOP 的权限，于是给你一份"看起来完整但其实没价值"的报告。

同样的需求，按目标加验收加边界写就成了：

目标：每周一早晨给业务方一份"上周哪些渠道异常 + 为什么"的简报

输入：BI 系统中过去 7 天的渠道转化数据
输出位置：reports/weekly_channel_anomaly_<日期>.md

验收标准：
- 必须明确指出"本周值得关注的异常"，0 个或多个都行，不为了凑数硬找
- 异常的归因必须能追溯到具体数据点（不能只说"可能是季节性"）
- 简报让业务方读完能在 2 个动作内决定是否需要拉会

边界：
- 数据明显异常（如某渠道转化率突然为 0）时先报警，不要直接归因
- 归因涉及"竞品策略变化""政策影响"这类外部因素时，标注为"假设"而不是"结论"
- 不要在简报里写本工具的执行过程

例子：
- 见 reports/weekly_channel_anomaly_20260428.md（一份好简报）
- 见 reports/weekly_channel_anomaly_20260421.md（一份不够好的简报，问题：把 5 个边缘异常都列了，业务方看不下去）

这份指令模型会自己拆步骤，会自己判断要不要分组、要做几层归因、要不要追加查数据。下一代模型来了，它的"自己判断"能力变强，这份指令的产出质量也跟着上去。你不用动一个字。

检查自己已经写了的 prompt 和 skill，可以问几个问题。里面有没有"第一步、第二步、第三步"这种字样，如果有，那串步骤是在描述"做对了长什么样"还是"该怎么做"，如果是后者并且任务不是不可逆操作，删掉它，让模型自己拆。指令最后能不能被一个新来的 agent 拿来判断"这件事做完了没有"，如果不能，说明你的验收标准还没写到位。"必须 / 不要 / 不能"这类硬约束如果超过十条，绝大部分多半是在应对脑补出来的 corner case，让真实的失败驱动迭代，第一次出错是噪声，第二次才是模式。最后看几个具体例子，不是抽象描述、不是反面教材清单，是真实的"长这样的输入产出长这样的输出"，对高自由度任务尤其关键。

那一截增量进谁的口袋

回到开头那个分歧。两派都在说"要跟 AI 说清楚"，区别在于说清楚什么。说清楚过程，你拿到的是一份在 GPT-3.5 上扎实、在 GPT-5 上别扭、在下一代模型上明显落后的脚手架；说清楚目标和验收标准，你拿到的是一份会跟着模型一起变强的契约。

模型每升一代，能解的问题都比上一代多一截。如果你的指令规定的是答案的形状，那一截增量进了你的口袋；如果你的指令规定的是路径的形状，那一截增量被你自己挡在门外。你写的不是给 AI 看的指令，是给"未来一年里每一代模型"看的契约。

写 SOP 不是错，把所有 skill 都当 SOP 写，是。真正的工程能力，是知道哪一档自由度配哪一类任务。这个判断本身，就是 AI 时代里不太可能被 AI 替代的那部分手艺。

这个说法一下子击中了我最近的一个感受。

我现在确实越来越依赖上下文系统。工作区里有规则，有技能，有公理，有项目历史，有每日复盘，有大量被 AI 处理过的中间产物。它们让 AI 更懂我，也让我和 AI 协作的摩擦越来越低。但与此同时，我也越来越警惕一件事：上下文如果只做横向分类是不够的。

横向分类回答的是：这段信息属于哪个领域。比如 AI、管理、家庭、项目、写作、投资、复盘。

但还有一个更重要的纵向分类：这段信息到底有多属于我？

横向分类解决“资料放哪”，纵向分类解决“谁有发言权”。

这件事在 AI 时代会变得特别重要。因为以前你的知识库主要是给自己看的，混一点问题不大。你知道哪篇文章只是收藏，哪句话只是觉得有意思，哪条结论是自己真正相信的。但 AI 不知道。你把所有东西都放进同一个篮子里，它会把这些东西当成同等权重的语料来理解你。

结果很可能不是 AI 更像你，而是你被 AI 拉回互联网平均值。

收藏不等于拥有

这其实是知识管理里一个很老的问题。很多人以为收藏就是学习，摘录就是理解，转发就是拥有。后来 Zettelkasten、Second Brain 这些方法论反复强调一件事：收藏只是入口，真正的知识必须被你重新加工过。

以前这句话更多是在提醒人不要做收藏癖。到了 AI 时代，我觉得它变成了一个更严肃的问题：如果你没有标明一条信息的归属，AI 就会替你决定它的归属。

比如你收藏了一篇文章，里面有一个观点写得很好。你当时只是觉得“有道理”，还没有想清楚自己是否同意，也没有把它放到自己的经验里验证。过了几个月，你让 AI “根据我的知识库写一篇我的观点”。AI 检索到了这篇文章，就很自然地把那个观点揉进了你的文章里。

表面上看，它引用了你的知识库。实际上，它借用了别人的大脑，并且给你署了名。

这不是 AI 故意乱来，而是因为你的系统没有告诉它：这只是我看过的，不是我相信的；这只是我收藏的，不是我消化的；这只是别人说得漂亮，不代表它有资格替我发言。

所以我越来越觉得，个人知识库里最危险的东西，不是假信息，而是没有标明归属的真信息。

什么才算“我的”

这里容易走到另一个极端：是不是只有完全原创的想法才算我的？我觉得也不是。

人的观点本来就不是从真空里长出来的。我们读书、看文章、听别人说话、看视频、做项目、和人争论，最后形成自己的判断。外部输入当然重要。问题不在于观点是不是有外部来源，而在于它有没有经过你的处理。

我现在会把上下文大概分成几层。

最底层是原始外部资料：文章、论文、视频、别人说的话。这些东西有价值，但它们只能当证据，不能直接当立场。

再往上是摘录和摘要：我觉得它可能有用，所以先记下来。它比原文更接近我，但仍然不是我。

再往上是我的转述：我用自己的话说过一遍，说明我至少理解了它。

更高一层是我的判断：我赞成什么，反对什么，保留什么，在哪个场景成立，在哪个场景不成立。

最高权重的，是我的经历和长期规则。亲身做过的项目，踩过的坑，管理现场里反复验证过的判断，日复一日复盘后沉淀出来的公理。这些东西不一定更宏大，但最能代表我。

换句话说，一个观点可以从别人那里来，但必须经过转述、碰撞、取舍和验证，才真正变成你的。

AI 应该优先放大的，是后面几层，而不是前面几层。

AI 平均化，从上下文混装开始

我之前写过一篇《AI 味不是机器味，是平均值的味道》。那时候更多是在讲写作表达：AI 为什么会写得越来越像一个训练得很好的优等生。

现在我觉得还可以再往前追一层。很多时候，AI 味不是从生成那一刻才开始的，而是从上下文混装那一刻就开始了。

如果一个知识库里同时放着你的亲身经历、别人的金句、网页收藏、AI 摘要、会议纪要、临时想法，而且这些东西没有权重差异，模型会怎么处理？它只能做一件事：求一个语义上的平均值。

它会把你的个人经历说得更像行业共识，把你的犹豫说得更像成熟判断，把别人的漂亮话说得更像你的观点。最后出来的东西可能都对，但不像你。

这和大模型训练很像。训练模型不是一股脑把所有数据倒进去就完了。要去重，要过滤，要标来源，要调数据配比，要给不同数据不同权重。高质量语料和低质量语料不能一样，人类原创和模型生成内容不能一样，主干知识和长尾样本也不能一样。

个人知识库也是一样。它不是硬盘，更像训练集。每条内容都有权重。

亲历项目应该是高权重样本，随手收藏的文章应该是低权重样本，AI 生成的内容要打水印或者隔离。否则你训练出来的不是“更懂我的 AI”，而是“更会综合我看过的一切的 AI”。这两者差别很大。

人的独特性在分布尾部

我很喜欢 model collapse 里的一个隐喻：模型反复吃自己生成的数据，最先消失的是分布尾部。也就是那些少见的、不典型的、低概率但很重要的东西。

人的表达也是这样。真正像你的部分，往往不在那些正确的大道理里，而在分布尾部。

比如一个项目里你为什么放弃了看起来更先进的方案。一次管理沟通里你为什么没有继续推进。某个看似琐碎的家庭场景，为什么让你重新理解一个抽象概念。某次失败后，你到底改了哪条规则。别人可能也知道类似道理，但只有你有那段具体经历。

这些东西不一定体面，也不一定完整，甚至有时候很土。但它们是你的尾部样本。

如果上下文系统没有给这些尾部样本更高权重，AI 默认会回到更安全、更顺滑、更常见的表达。它不是不想写出你，而是不知道你把这些不平滑的东西看得更重要。

所以我现在越来越相信，个人风格不是形容词，是加权函数。

你说自己“务实、理性、有判断”，这还不够。真正决定 AI 能不能写出你、帮你思考、替你推进事情的，是它在冲突时知道谁权重大。是收藏的文章权重大，还是你复盘里的反思权重大？是行业通用说法权重大，还是你某次亲身踩坑后的结论权重大？是 AI 上一轮生成的顺滑段落权重大，还是你手动删掉它的编辑动作权重大？

这些才是上下文主权。

我现在更想这样管理上下文

如果把这件事落到个人系统里，我觉得以后至少要有几条规则。

第一，原始记录和个人判断要分开。录音、聊天、网页、论文、视频都可以收，但它们应该保留“外部资料”的身份。它们能提供证据，不能直接代表我。

第二，AI 处理过的内容要单独放。AI 摘要、AI 初稿、AI 生成的中间分析都有用，但它们是加工品，不是原材料，更不是最终判断。它们如果混进长期记忆，很容易反过来污染后续输出。

第三，每条重要信息最好有一个“我怎么看”。哪怕只是一句话也行：我同意哪里，不同意哪里，适用边界是什么，和我的哪个经历有关。没有这句话，它就只是资料，不是知识。

第四，把人工删改当成高价值信号。AI 写了一段，我删掉了什么、保留了什么、重排了什么，这些动作比我说“写得更像我一点”重要得多。因为 taste 不是抽象偏好，taste 是选择痕迹。

第五，长期规则要从行为里长出来。公理系统最有价值的地方，不是写了多少漂亮原则，而是它来自长期复盘后的行为模式归纳。不是我说过什么，而是我一直在做什么。

这套系统听起来像知识管理，但我觉得它更像给自己的 AI 建一个免疫系统。不是所有进入身体的东西都会变成自己。身体要识别、吸收、排异，知识系统也一样。

最后

过去我们讲个人知识管理，核心问题是怎么不忘。AI 时代这个问题变了：不是怎么记住更多，而是怎么避免被自己记住的东西稀释。

上下文越多，越需要治理。资料越丰富，越需要权重。AI 越能理解你，越要告诉它什么才算你。

否则所谓“我的知识库”，最后会变成一个很会说话的互联网平均值。它知道你读过什么，知道你收藏过什么，知道你让 AI 生成过什么，但它不知道你真正相信什么。

AI 时代，真正稀缺的不是上下文长度，而是上下文主权。

群里大部分人的反应都比较一致：不是特别好的选择。我自己的感受也差不多。不是因为 Harness 不重要，而是因为多数人现在纠结的 Harness，很可能不是他们当下最该解决的问题。

这件事让我想到鸭哥之前说过的一个词：外包。

这个词听起来很朴素，甚至有点不够“技术”。但我现在越来越觉得，它可能是 AI Coding 进入下一阶段之后，很多人最缺的一种能力。

AI 越强，人越容易重新变成手工业者

过去几个月，AI Coding 的能力确实在快速变强。模型能处理更长的上下文，工具能跑更复杂的任务，Agent 能在一个 repo 里来回改文件、跑测试、修错误。以前你只敢让它写一个函数，现在你会开始让它做一个功能，甚至做一个完整模块。

能力变强以后，一个很自然的冲动就出现了：既然它能做，那我就让它从零做。

页面自己写，框架自己搭，评测自己做，Harness 自己建。以前人写代码成本高，大家还会认真想想这个东西到底该不该自研。现在 AI 把第一版代码的成本打得很低，反而让很多人失去了 build or buy 的判断。

这是一个很隐蔽的陷阱。

AI 让执行变便宜了，但没有让维护变便宜。它能帮你把第一版写出来，但后面的理解、迁移、升级、验证、排错，还是会回到你身上。尤其是 Harness 这种东西，一旦你自建，它就不是一个功能，而是一条长期责任链。

所以最危险的不是 AI 不够强，而是 AI 足够强，让你误以为什么都可以自己搭。

Harness 当然重要，但它不是所有人的第一优先级

我并不是反对 Harness。

Agent 要从 Demo 变成真正可用的系统，肯定需要一整套中间层：状态怎么保存，工具怎么调用，权限怎么控制，失败怎么恢复，过程怎么记录，效果怎么评估。这些问题每一个都不性感，但每一个都决定 Agent 能不能长期稳定运行。

成熟团队确实需要 Harness。平台团队要做 Agent 发布门禁，需要评测集、回归门槛、灰度机制。业务 Agent 上线给多人使用，需要可回放、可审计、可回滚。公司要比较不同模型、不同 prompt、不同工具配置，也需要稳定的评测框架。

但这里有个前提：你得先有稳定的任务分布。

如果你现在每次让 AI 做的事情都不一样，没有固定任务集，没有失败样本库，没有明确 KPI，没有持续回归需求，那你搭出来的 Harness 服务谁？它评测什么？它优化什么？它证明什么？

很多人现在的问题不是缺 Harness，而是缺一个清楚的任务定义和验收标准。你还不知道什么叫做“做对了”，却开始搭一套系统来评估“做得好不好”。这个顺序反了。

这就像店还没开，先花半年造收银系统。收银系统当然重要，但它不是第一天最该解决的问题。

所谓外包，不是把责任甩出去

我理解的外包，不是把事情丢给别人，也不是降低要求。

它更像现代软件工程里的依赖管理。通用的东西，尽量交给成熟模块。真正和你业务强相关、和你判断强相关、和你责任强相关的东西，自己留下。

模型能力，外包给模型厂商。Agent runtime，优先看成熟框架或公司内部平台。评测基准，先看现成的 eval 工具和开源 harness。部署、监控、权限、审计，能接已有基础设施就不要重做。

那人留下什么？

留下问题定义，留下上下文，留下方案选择，留下结果验收。

这几件事才是 AI Coding 时代人的核心价值。你知道这个问题为什么重要，知道输入怎么描述才不偏，知道输出长什么样才算对，知道哪些风险不能接受，知道这个方案放到你的业务和组织里会不会出问题。

AI 擅长执行，但它不天然知道你的业务边界。成熟工具擅长提供通用能力，但它不替你承担最终判断。

所以外包不是放弃控制权。相反，它是为了把控制权从“我能不能写出这段代码”，转移到“我能不能判断这套方案是否正确”。

AI Coding 有两个层级

我现在越来越觉得，AI Coding 至少有两个层级。

第一个层级是执行层 AI Coding。你让 AI 一行一行写，把功能做出来。这个阶段很重要，它让很多过去不会写代码的人，第一次可以把想法变成可运行的东西。

第二个层级是架构层 AI Coding。你让 AI 帮你判断：这个问题有没有成熟解法，同类开源项目怎么做，官方文档推荐什么架构，别人踩过什么坑，哪些模块该接，哪些模块该买，哪些地方必须自己保留控制权。

这两个层级的差别很大。

执行层 AI Coding 让你更快地产生代码。架构层 AI Coding 让你更少地产生错误代码。前者提升速度，后者提升方向。

如果只停留在第一层，人会越来越像一个指挥 AI 干活的包工头：这里加个功能，那里补个模块，缺什么搭什么。项目看起来推进很快，但底层越来越重。

进入第二层以后，问题会变成：这个模块是不是我的核心竞争力？有没有成熟方案？我真正需要掌控的是接口、数据、流程，还是底层实现？

这个判断一旦做对，后面少写的代码，比多写的代码更值钱。

更好的路径：先集成，再沉淀，最后才平台化

如果今天有人问我该不该投入 Harness，我会建议他先按这个顺序走。

第一步，先用现成工具跑通真实问题。不要先搭系统，先让 AI 真正在你的场景里完成几次任务。

第二步，把验收标准写清楚。不是“看起来不错”，而是哪些输入要覆盖，哪些输出不能错，失败了怎么发现。

第三步，保留运行轨迹和失败样本。不要急着抽象，先积累足够多的真实失败。真正有价值的 Harness，往往不是从设计文档里长出来的，而是从重复失败里长出来的。

第四步，当失败模式开始重复，再做轻量机制。比如固定测试集、简单回归脚本、日志结构化、人工 review 表单。

第五步，只有当这些轻量机制变成瓶颈，再考虑平台化。

这个顺序听起来慢，其实更快。因为你没有在一开始就背上一个大系统，也没有为了一个还没被验证的问题，提前支付复杂度。

AI Coding 的高级用法，不是让 AI 写更多代码，而是让 AI 帮你识别哪些代码根本不该写。

回到群里的那个问题

所以，如果问“现在把时间花在 Harness 搭建上是不是好选择”，我的回答会是：看你处在哪个阶段。

如果你是平台团队，有稳定场景，有上线责任，有评测闭环，那当然值得做。Harness 是基础设施，不做迟早要还债。

但如果你只是个人 AI Coding 使用者，或者团队还在探索阶段，那现在最值得投入的不是从零搭 Harness，而是训练自己做三件事：定义问题，寻找成熟模块，设计验收闭环。

这三件事比写代码更难，也更值钱。

AI 时代的工程能力，不会只体现在“我能造出什么”。它还会体现在“我知道什么不该自己造”。过去不会写代码是一种短板，未来不懂外包才是一种短板。

真正拉开差距的人，不是最会让 AI 干活的人，而是最会给 AI 和外部系统分工的人。

背景是这样：他们整个 HR 团队都在推 AI 提效，内部分成了单点提效、流程提效、组织提效三个层级。团队里已经有人在用 AI Coding 工具、低代码平台拉内部数据做小网页，也有人用 Co-Work 之类的协作工具。不算完全不会用，但碰到了瓶颈。

他们最困惑的一个点是：做出来的小网页，第一眼看挺好，数据能展示，页面也漂亮。但是然后呢？如果只是看数据，直接把 MCP 挂上去问就行了，何必做成网页？如果要给别人看，又涉及部署、维护、权限，普通业务同学根本兜不住。所以他们想知道，"你平常是怎么搭 Agent 的"。

聊完之后我一直在想这件事。不是想怎么回答他们的问题，而是觉得这个问题本身就藏着好几个误区。记录一下。

误区一：把 AI 提效等同于"做 Agent"

这是我听到的最普遍的混淆。大家一说 AI 提效，脑子里的画面就是搭一个 Agent。好像不做 Agent，就不算在认真搞 AI。

但你仔细想想，AI 提效的工具形态其实很多。有些场景你只需要一个查询接口，让 AI 能帮你问数据，那做个 MCP 就够了。有些场景你需要几个人协作看一个东西，或者收集一些信息，那做个网页没问题。有些场景是固定流程跑得快一点，那是 Workflow 的事。只有当一个任务路径不确定、需要多轮推进、中间可能失败需要恢复、需要动态选择工具的时候，才值得上 Agent。

所以第一个判断应该是：这个场景需要什么形态来承载？而不是"我要不要做一个 Agent"。

拿 HR 的场景举例。员工问政策、查福利、看流程，这些是查询类的，挂个 MCP 让 AI 直接回答最自然。内部搞个活动要收报名信息、展示数据看板，这是展示和操作类的，做个网页就行。入职手续一步步审批走完，这是固定流程，Workflow 足够。只有像"帮我从 50 份简历里筛出最合适的 3 个人，还要交叉验证背景、评估文化匹配"这种开放式任务，才真正需要 Agent 的能力。

形态选错了，做出来的东西要么过度复杂（为了一个查询场景搭了整套 Agent），要么能力不足（用一个静态网页试图做动态决策）。先判断场景，再选工具。这个顺序不能反。

误区二：以为"我能用"就等于"别人能用"

这是第二个巨大的误解。一个人用 AI Coding 做出一个小工具，自己用得挺开心，就觉得可以推给团队用了。但单人自用和多人共享之间，隔着一条看不见的线。这条线叫工程稳定。

个人工具可以靠作者的记忆运转：坏了自己修，数据错了自己知道怎么补，权限粗糙点也只影响自己。但一旦给别人用，每一个"自己知道"的东西都会变成一个坑。别人不知道它为什么突然不能用了，不知道数据口径变没变，不知道出了问题找谁。

这时候你需要的不是更好的 AI Coding 能力，而是工程基础设施：部署、监控、日志、权限管理、回滚机制、事故响应流程。这些东西不是一个两小时的 AI 培训能覆盖的，也不是 AI 本身能替你解决的。AI 可以帮你写代码，但它不会替组织承担运维责任。

所以我的判断是：单点提效确实可以靠个人学习解决，但流程提效和组织提效，本质上是组织能力建设的问题，不是工具培训的问题。指望通过一两次培训让业务同学从"给自己用"跨越到"给团队用"，不太现实。更现实的路是：业务同学负责原型和验证，平台团队负责生产化和稳定运行，中间有明确的交接标准。

误区三：觉得 Agent 难在"模型+工具+知识库"

即便真的需要做 Agent，很多人对 Agent 的理解也停留在表面：找个模型，挂几个工具，接个知识库，就是 Agent 了。这个组合能做 Demo，但离真正稳定跑起来差太远了。

Agent 真正难的地方是中间的 Harness 过程。所谓 Harness，就是让 Agent 稳定运行的那一整套机制：状态怎么保存，工具权限怎么控制，哪些操作需要人来审批，出错了怎么恢复，每次运行的轨迹怎么记录，怎么评估它比上周跑得好还是差。这些问题一个比一个不性感，但每一个都决定着这个 Agent 能不能从 Demo 变成真正可用的东西。

所以对普通同学来说，从零搭一个成熟 Agent 不是正确的路。更好的方式是：把你的业务想法包装在已有的成熟 Agent 能力上面。比如前端提供用户的输入口，核心的智能处理部分调用后端成熟的 AI 产品（不管是 Claude Code 的 SDK、某个 CLI 的远程调用、还是企业内部的 Agent 平台），处理完之后对输出做一些规范，再接回到你的业务流程里。你负责定义"要做什么"和"做得对不对"，平台负责"怎么稳定地做"。

这个分工才是当前阶段大多数非技术人员用 Agent 能力的正确姿势。不是降低要求，是找对边界。

误区四：写了 Plan 就以为方向是对的

最后一个感触来自我自己最近的经历。我在做一个 App 的时候，功能做出来了，但怎么调都不太对。反复改了几版之后我忽然想起来，我这个东西和一个开源项目的功能很相似。于是让 AI 去调研那个项目的架构，结果发现我之前的设计从根上就有很多不对的地方。

这件事给我的提醒很直接：写 Plan 不等于方向对。

我以前每次让 AI 干活之前都会先让它写 Plan。Plan 的好处是让 AI 在长时间工作的时候不至于游离目标，干着干着忘了自己在干嘛。这一点没问题。但 Plan 还有另一层价值，就是方向本身是否正确。如果你在一个自己不熟悉的领域里，你写出来的 Plan（或者让 AI 写出来的 Plan）很可能方向就是错的。这时候 Plan 越详细，AI 执行得越认真，结果可能越歪。

所以我现在的做法是：如果涉及到我不确定"什么是好的"的领域，我会先让 AI 去外面找最佳实践。看看同类的开源项目怎么做的，看看官方文档推荐什么架构，看看别人踩过什么坑。基于这些外部输入，再来写 Plan。这样 Plan 指向的方向至少是经过验证的，而不是 AI 在真空里编出来的。

先去找什么是好的，再来规划怎么做。这个顺序，比"帮我搭一个 Agent"重要得多。

回到那门课

如果最后真要给他们讲，我不会把题目定成"如何搭建 Agent"。这个题目本身就把问题带偏了。

我更想讲的是四件事：第一，怎么判断一个场景该做成什么形态。第二，从"自己用"到"别人用"中间差的是什么。第三，如果确实需要 Agent 能力，怎么借力而不是从零开始。第四，在不熟悉的领域里，怎么确保你的方向不是在跑偏。

这四件事比具体的工具操作重要得多。工具会迭代，但判断力的框架不会过时。

真正的组织提效，不是让每个人都造车。是让每个人知道什么时候该骑车、什么时候该坐车、什么时候该修路。

有个朋友在群里发了一段话："这两个月 AI 用量大增，但我感觉思维能力在下降。用 AI 处理信息，再用 AI 生成信息，过程中我自己并没有变强。"

我第一反应是想反驳，因为我自己的体感是 AI 确实让我做事更快了、更好了。但那天晚上做复盘的时候认真想了想，发现他说的不完全是错觉。

从思考者到审稿人

我注意到一个变化。以前做调研，我会先自己花一两个小时读资料、画脑图、形成初步判断，然后才开始写。现在呢？打开 Claude，丢一个问题进去，等它吐出初稿，然后我在上面改。效率提升了至少三倍。

但在这个"改"的过程里，我的角色悄悄变了。从"思考者"变成了"审稿人"。审稿人是在别人搭好的框架里做修补，思考者是自己搭框架。

更微妙的是，我开始不自觉地接受 AI 给我的框架。不是因为它的框架比我的好，而是因为推翻重来太费劲，改几段话省事得多。就像有人帮你把食物嚼碎了喂进嘴里，营养可能进去了，但你的咀嚼肌再也得不到锻炼。

苏格拉底当年担心文字会让人忘记如何记忆。两千年后再看，那点"威胁"简直不值一提。文字只替代了记忆，AI 替代的是综合、判断和决策。量级完全不同。

不只是感觉

MIT 今年做了一个实验，让三组人分别用纯脑力、Google 搜索和 ChatGPT 写作文，持续四个月，每月测脑电波。结果：ChatGPT 组的大脑认知网络活跃度比纯脑力组低了 55%。83% 的人无法回忆自己刚写过什么。英语教师盲评 AI 辅助的文章，给了一个词：soulless。语言完美，但空洞。

研究者管这叫"认知债务"。就像财务债务一样，你在享受即时便利的同时，以未来的认知能力为利息在还。而且这个利息是复利：你越不独立思考，独立思考就越难，然后就越依赖 AI。

这不是学术界在制造焦虑。我在自己团队里也看到了类似的迹象。有个同事以前做数据分析，思路清晰，能从一堆乱七八糟的数据里自己理出线索。用了半年 AI 之后，他的分析报告表面上更漂亮了，但洞察变浅了。给他一份 AI 生成的初稿，他很少质疑框架本身，更多是在调措辞和补细节。

这种变化很难自我察觉。因为你的产出效率确实提高了，表面质量也不差。你要到某一天被逼着在没有 AI 的场景下独立做一件事，才会发现自己的"裸奔能力"下降了多少。

谁先动脑

到这里你可能会想：那就少用点 AI 吧。但这不是我的结论。

MIT 的那个实验有一个被报道得比较少、但我认为最重要的发现。第四个月做了交叉：让 AI 组独立写，让独立组用 AI。

结果很清楚：先独立思考三个月、第四个月才用 AI 的人，即使用了 ChatGPT，大脑活跃度没有下降。他们的认知网络已经够强壮了，AI 削弱不了它。反过来，用了三个月 AI 再被要求独立写的人，脑连接度已经明显松弛了。更糟的是，他们开始不自觉地复用 AI 曾给他们的短语和结构。

问题不在于用不用 AI，而在于谁先动脑。

这跟我自己的体感完全吻合。我的每日复盘本质上就是在做"先独立思考"这件事。不是在 AI session 过程中思考，那时候你已经在 AI 的框架里了。而是在 session 结束后，拉出来，自己重新过一遍：今天的判断对不对？哪些是 AI 给的框架，哪些是我自己想的？有没有被带偏？

这个过程费劲。说实话有些日子我也想偷懒跳过。但坚持下来的体感很明确：有复盘的时候，第二天和 AI 协作的质量明显更高。你带着更清晰的判断进去，AI 的产出就更精准。没复盘的时候，你的判断模糊了，AI 的产出看起来都"差不多行"，你也就接受了。然后你的判断进一步模糊。然后认知债务开始滚利息。

放大器只放大你已有的东西

我一直跟自己说一句话：AI 是放大器，不是替代品。

如果你有认知结构，AI 放大你的结构，让你更快更好。如果你没有，AI 放大的只是噪声和惰性。放大器的特性决定了：输入的质量比放大器本身更重要。你带着清晰判断去用 AI，得到高质量的加速。你带着模糊想法去用 AI，得到包装精美的平庸。区别不在 AI，在你。

还有一件事我最近想得比较多：AI 把代码和内容的生成成本推向零了，但理解和判断的价值反而上升了。这两件事指向同一个方向。你应该把省下来的时间投到那些 AI 做不了的地方，比如定义问题、形成判断、做出取舍。而不是把省下的时间全用来让 AI 帮你生成更多产出。

但现实恰恰相反。BCG 今年的调查发现，AI 没有减轻工作者的负担，它扩大了你的"责任球体"。上级发现你一小时能做完以前六小时的活，于是给了你六倍的任务量。你用 AI 省下的时间没被用来深度思考，而是被填满了更多任务。于是更依赖 AI，更没时间独立思考，判断力进一步退化，然后更依赖 AI。

这才是真正的恶性循环。不是"AI 让你变笨"这么简单，而是一个系统性的陷阱。

我怎么做

说了一堆问题，说说我自己的三个做法。

第一，每次用 AI 之前，先花几分钟形成自己的初步判断。不需要很完整，但至少要有一个方向。保证自己是在 AI 的帮助下深化自己的思考，而不是在 AI 的框架里做修补。

第二，每天做复盘。我跑了 161 天了，效果是双向的：AI 越来越符合我的预期，我对自己认知盲区的感知也越来越敏锐。复盘的核心不在于记录做了什么，而在于分辨：哪些判断是我自己的，哪些是 AI 的。

第三，刻意保留一段无 AI 的时间。不长，半小时到一小时。写东西、跑步、想问题，干什么都行。重点是让大脑在没有辅助的情况下独立运转一段时间。就像健身一样，你可以用器械辅助，但得有几组是自重训练。

这三件事的共同逻辑是什么？保持"认知做功"。学习和成长只发生在大脑做功的时候。AI 最大的诱惑不是它能做什么，而是它让你可以不做什么。但你不做的那些事，恰恰是认知在生长的时刻。

大脑用则进，退则废。这句话在 AI 时代不是变假了，是变得前所未有地真了。因为"不用"变得太容易了。

关键来源：MIT Media Lab arXiv:2506.08872 · Wharton/PNAS Nexus pgaf316 · BCG/HBR AI Brain Fry 2026

巧的是，我刚结束今年暑期实习招聘的终面。过去一个多月面了 26 位硕士和本科生，覆盖算法、开发、数据科学几个方向。面完之后最大的感受，和 Jobright CTO 说的几乎一模一样：不是学生能力不行，而是大多数人还在用五年前的方式来准备一场 2026 年的面试。

"说"正在贬值

我先说一个底层逻辑，理解了这个，后面的东西自然就通了。

AI 之前，校招的筛选机制是这样的：学生拿着简历，聊 30 分钟到一个小时。简历里的硬通货（学校、GPA、实习、论文、竞赛）提供背书，面试中看逻辑表达、专业深度和沟通能力。这套机制运转了十几年，大家都习惯了。

但 AI 时代这套机制正在失效。原因很简单：当 AI 能帮任何人生成一份漂亮的简历、写出看起来很专业的项目描述、甚至在面试中提供实时辅助的时候，"说"本身的可信度在急剧下降。

我面试中碰到一个真实的情况。有位同学简历上写了"AI Code Review 系统"，看上去很前沿。面试一追问，发现本质就是在 Cursor 里写了一个提示词，手动把代码贴进去跑一遍，再把结果复制给同事。他不是在骗人，但简历上那个词和实际做的事情之间的落差，在 AI 时代会被无限放大。

所以企业现在越来越看重一件事：你能不能"show me"，而不只是"tell me"。

丢一个 GitHub 链接，代码质量、项目结构、迭代历史一目了然。打开你的 CLAUDE.md 文件，面试官立刻知道你和 AI 的协作到了什么程度。给面试官看一个你完整交付的东西，胜过你讲十分钟项目经历。

这不是面试官故意刁难。是因为在一个 AI 能帮你"说"的时代，只有"做出来的东西"才是不可伪造的信号。

终面面试官真正在看什么

再说一个很多学生不了解的内部视角。

现在校招面试一般分两轮。技术初面由团队骨干主持，考的是专业基本功，在细节层面看你是否合格。通过初面之后，终面由更高层级的面试官来做，这一轮基本不再考技术细节了。

为什么？一方面到了这个层级，面试官对具体技术细节的把控不一定比一线同事精准；另一方面，终面要判断的东西不一样——潜力、思维方式、成长性，这些更难量化的东西才是终面决定录不录你的核心。

以前这些东西靠经验和直觉判断。但现在有了更好的方式：如果你有一个 GitHub 仓库、有一个完整的项目、有你自己的 AI 工作流配置文件，终面面试官可以在面试前就借助 AI 对你的项目做深度观测。你的代码组织方式、你的设计决策、你和 AI 的协作模式、你在项目中遇到问题时怎么解决的，这些信息全在那里。

这比你在面试中口头回答三个问题，信息密度高出一个量级。

所以 AI 改变了两件事：一是"说"在贬值，二是"做出来的东西"可以被更高效地读取和评估。 两头一挤，结论就很清楚了——有作品的人会越来越占优势。

我实际看到了什么

说回这 26 个人。我在面试中有一个习惯：直接让候选人打开他们的 CLAUDE.md 或 agents.md 文件给我看。

结果是大部分人愣住了。26 个人里只有 2 个有成熟的 AI 工作流。不到 8%。

剩下的人大致这几种情况。

把 AI 当搜索引擎用。 占了至少三分之一。我问"你平常用 AI 吗？"都说用。怎么用？打开浏览器问 ChatGPT 一个问题，看回答。有位同学很坦诚，我说"就把它当成高级版搜索"，她直接说"对，是的"。当整个行业已经从对话式交互迁移到 IDE 类工具的时候，这些同学还在浏览器里一问一答。

研究 AI 但不用 AI。 这个反差最让我意外。有位做大模型微调的同学，自己写代码只用豆包当搜索。有位本硕都读 AI 专业的，从没用过 Cursor。能把 PPO、DPO、GRPO 三种对齐算法讲得头头是道，但可能从没让 AI 帮自己完整做成过一件事。造工具和用工具，是两回事。

用了很多工具但没有方法论。 有位同学付费用了 GPT 和 Trae，使用频率很高。但当我问"你有 agents.md 吗？"他不知道。问他怎么约束 AI 不重复犯错，他说写了个文件，让他给我看，他说好像在实验室电脑上。这意味着 AI 每次都不知道他在做什么项目，相当于永远带着一个失忆的人一起工作。

让我眼前一亮的那 2 个人，共同特征是：问他们 AI 的问题，不像在回答面试题，而是在聊他们每天都在做的事。一个人业余时间自己搭了选股 Agent，写 skills 并持续迭代，出发点是真实需求。另一个在微软有无限 Copilot 额度，但选了 Claude Code 做主力，能说清为什么。

使用 AI 是动词，不是名词

这个社区一直在说的一个观点，我觉得特别到位：使用 AI 是一个"动词"，不是一个"名词"。

很多学生把"了解 AI"当标签。看了几篇文章、知道一些概念，觉得自己"会 AI"了。但 AI 的真正价值只有在动手的过程中才能体会。什么时候该信任它的输出，什么时候该打断它；怎么给 AI 足够的上下文让它做对事情；碰到它反复犯同一个错误该怎么约束它。这些东西看文章看不出来。

面试中有位同学让我印象深。他能引用 Anthropic CEO 的话，用比喻描述 AI 对工作方式的变革，讲得很有见地。但当我追问他自己的 AI 工作流是什么，他答不出来。认知超前但行动为零，这是我看到的最典型的错位。

在过去，企业希望学生除了上课和写论文，还能有实习和项目经历。实习经历意味着实践，现在在绝大多数企业都希望寻找到那些有 AI 属性的毕业生时，AI 时代的实践是什么？我想，跟过去的实习经验，又不同了。现在对实践的要求非常直白：你在 AI 上有没有动手能力。为什么会要求动手能力，是因为面试你的那群人，也都每天在承受被 AI 变化驱动带来的震撼或者焦虑，他们很清楚，AI 每天都在变化，应对这种变化，或者说，在这种变化中，与企业的业务做好结合的前提，就是 AI 体感。而这种体感只能从使用中获得，和所有快速变化的领域逻辑一样——光看方向盘说明书不行，你得真开过车。

具体怎么做

如果你正在准备找工作，以下几件事我觉得值得好好考虑一下。

从今天开始，用 AI 去做一件完整的事。什么事都行：一个小工具、一个自动化脚本、一个数据分析流水线。过程中你自然会碰到怎么选工具、怎么配上下文、怎么约束 AI 的问题，这些问题会逼你建立自己的方法论。

做完之后，你会有一个 GitHub 仓库，里面有你的代码、你的 CLAUDE.md、可能还有几个你写的 skills。这些东西加在一起，就是你在这个时代最有说服力的能力证明。面试时打开给面试官看，比任何话术都管用。

如果你还有余力，把你做的东西、学到的东西分享出来。技术博客、小红书笔记、LinkedIn 上一段项目总结，什么形式都行。这些公开可见的内容就是"signal"——它传递的不是"我有多厉害"，而是"我知道什么是真正有价值的"。

GitHub、真实项目、技术博客、有干货的社交媒体 profile——把这几个装点齐全，三个月足够了。

写在最后

说这些不是为了制造焦虑。从我面试的情况看，绝大多数人还没有开始。你花两三周时间认真做一个东西出来，就已经站在前 5% 的位置了。

我自己在 AI 这条路上受益于课代表与鸭哥社区的课程和氛围。Architect 课程帮我建立了对 AI 架构和工作流的系统认知，社区里大家分享的实践让我少走了很多弯路。其实社区里面免费的文章就很多，有条件的同学如果有机会去看看系列课程，然后跟着做完一个项目，我想你能感受到不同，并且这种不同也能传递到你的面试官。如果条件不允许，我也建议从今天开始，把"名词"变为"动词"。因为我面试的过程中我都在想这个事情，如果这些学生，哪怕就上一周的课，哪怕有一点点"做出来的东西"，他们都会因为这种不对称优势，而迅速排到前列，而那恰恰是面试官最想看到的。

用了几轮之后，我的体感是：很容易一两轮就停。而同样的任务交给 Ralph Loop，至少能主动优化三五轮。不是 Codex 不努力，是它停下来的时候真诚地认为自己完成了。

这让我很好奇：两个功能描述几乎一样的东西，为什么体验差这么多？

调研之后我的判断是：体感大概率是对的，但原因不是"Codex 的 /goal 比 Ralph Loop 弱"。而是这两个东西的目标函数根本不同。

它们不是同一种产品

先说 /goal 在技术上做了什么。4 月 30 日发布的 Codex CLI 0.128.0 加入了这个 experimental 命令。Simon Willison 第一时间分析了它，指出核心实现是两个模板文件：continuation.md 在每个 turn 结束后自动注入，提醒 agent "继续朝目标推进"；budget_limit.md 在预算快用完时提醒 agent "收尾，别开新坑"。

Ralph Loop 呢？Geoffrey Huntley 的原始设计只有一行 bash：

while :; do cat PROMPT.md | claude-code ; done

一个外部循环，每次迭代启动一个全新的 Claude 进程。

表面上看，两者都是"循环做事直到完成"。但把它们的核心循环拆开看，差异是结构性的：

/goal 的循环是：持久目标 → idle 检查 → 注入 continuation prompt → 模型执行下一步 → 模型自己 audit → 模型标记 complete（或 runtime 预算到期强停）。

Ralph Loop 的循环是：外部脚本启动 agent → agent 做一轮 → 外部检测 completion signal → 如果不满足，丢弃上下文、保留文件状态、重新启动 agent。

前者更像"单 agent 的持久任务生命周期"。后者更像"多次独立审查的蒙特卡洛式工程搜索"。

为什么 /goal 容易一两轮就停

GitHub 上有一个精准定位了 /goal 核心问题的 Issue #19910。一位深度用户报告：密集使用 /goal 几天，在 ambitious work 上没有一次真正跑到完成。根因是 compaction：session 对话太长时系统会压缩历史，而压缩过程可能把 goal continuation prompt 丢掉。新一轮的 agent 只看到"刚才在跑测试，快完事了"，不知道这只是子步骤。于是验证完局部任务就标记 goal achieved。

但 compaction 只是表层原因。更深层的是 /goal 的续跑规则本身带有收敛倾向。

从 Codex 的 runtime PR 可以看到一个关键设计：如果某一轮模型用自然语言总结"我检查过了，目标已达成"而没有进一步调用工具，运行时不会触发下一轮 continuation。这意味着 agent 只要输出一段"总结性文字"而非动手操作，循环就自然停了。这大概率就是我体验到"一两轮就停"的直接技术原因。

再看 continuation.md 模板本身。它要求 agent 在决定完成前把目标重述成 deliverables/success criteria，建立 prompt-to-artifact checklist，检查文件、命令输出、测试结果等真实证据，只有 audit 显示"no required work remains"时才调用 update_goal complete。

这套设计对"验收型任务"很合理。但对"持续优化型任务"有天然收敛倾向：它问的是"显式要求是否都覆盖了"，而不是"还有没有高价值的非显式改进机会"。

Ralph Loop 的主动性从哪来

理解了 /goal 的收敛设计，Ralph Loop 的优势就不只是"架构更好"那么简单了。它的主动性来自一个反直觉机制：不是让同一个 agent 更聪明，而是不断制造新的、不完全一致的审查视角。

每次 bash loop 迭代启动的新 Claude 进程：没有上一轮的对话历史，没有自我确认偏误，通过 git diff 和文件系统状态来了解"上一轮做了什么"。它会自然产生新的 framing：刚才那轮完成了什么？测试能过吗？结构还能更好吗？有没有边界情况没覆盖？

LLM 在同一上下文里容易产生承诺一致性，就是"我已经做得差不多了"的路径依赖。Fresh run 会降低这种依赖。对于架构优化、质量提升、测试补洞这类开放任务，重新采样通常比继续同一条思路更有效。

Blake Crosley 的实践报告证实了这一点：他用 Ralph Loop 架构跑了多个通宵 session，交付了 3,455 行 Python 代码和 141 个测试。HN 上也有人总结：Ralph 这类东西的核心价值是"在长期任务中纠正 drift"，通过 fresh context 打破 agent 的自我满足叙事。

公平地说：/goal 的早停不全是 bug

写到这里需要补一个视角。如果只从"谁循环得更久"来评判，对 /goal 不公平。

/goal 是 OpenAI 官方运行时的一部分。它必须考虑预算控制、用户可暂停恢复、误触发防护、安全边界。PR 里明确说不让模型从普通 task request 推断 goal，不给模型 broad control over user/runtime-owned state。这些产品约束是有意为之的。

Ralph Loop 是社区脚本。它的哲学是粗暴但有效：不断跑，直到外部条件满足或 max iterations 停止。有些实现加了 rate limiting、circuit breaker，但本质仍然是"外部循环优先"。它更浪费，但更不容易满足于第一轮的局部最优。

所以 /goal 的早停有三层原因：

• 技术层：compaction 丢失 goal context、"无 tool call 则不续跑"规则
• 设计层：continuation prompt 的审计逻辑天然偏向收敛
• 产品层：safety 和 cost control 的有意约束

它不是一个"做坏了的 Ralph Loop"。它是一个不同目标函数的产品，碰巧被社区拿来跟 Ralph Loop 对比。

真正的判断：你的任务是哪一种

两种工具做的事用人话说：

/goal 是一个合规的工程员工：拿到需求、执行、验收通过、汇报、停止。它擅长"把一个明确的 goal 可控地做完"。

Ralph Loop 是一个偏执的外部审稿流程：你说完成了，我换个脑子再看一遍。你还是说完成了，我再换个人来看。它擅长"不断发现下一个改进点"。

我之前觉得 /goal "不好用"，本质上是因为我给它的任务不是"做完一个有明确验收标准的需求"，而是"持续优化，帮我发现还能更好的地方"。前者 /goal 理论上可以做（如果 compaction 问题修好的话），后者它的设计基因就不支持。

换句话说：你觉得 Ralph 更好用，暴露的是你的真实任务性质。你不是在"达成一个 goal"，你是在"持续发现下一个更高价值的 goal"。这两者不是同一个产品形态。

架构差异的本质：自检 vs 外审

抽象到更一般的层面，这里有一个工程管理中的经典问题。

让同一个 agent 在同一个 session 内自我评估是否完成，本质上就是"自检"。让一个全新的 agent 来审视上一轮的产物，是"外审"。

自检不如外审可靠，这是组织管理、软件工程、质量体系都验证过的普遍规律。代码要别人 review，审计要独立第三方。不是因为你不诚实，是因为你不可能客观审视自己持续投入的工作。agent 也一样，在同一 context 里积累的"我在认真工作"叙事会形成路径依赖。

Ralph Loop 通过进程级隔离实现了"外审"。每次迭代是一个独立的 code review + continue 决策。/goal 通过 prompt 注入试图在"自检"框架内提高审计质量。前者结构上更可靠，后者产品上更可控。

实操建议：混合架构

如果你跟我一样，日常任务里"持续优化"比"验收完成"更多，有一个比较务实的混合做法：

用 /goal 做单轮长任务的内层执行器（它对有明确 deliverables 的单次任务确实比反复手动"继续"好用）。在外层套一个 Ralph 式的循环做"反满意"外壳。外层不需要一直让它写代码，可以交替执行三种 prompt：builder、reviewer、regression-finder。只有 reviewer 连续两轮找不到 material issue，外层才停。

这正好补上 /goal 的弱点：/goal 擅长沿着目标推进，外层 loop 擅长"不相信它已经完成"。

如果非要只选一个，我的判断是：对于"做完一个有验收标准的需求"，等 /goal 修好 compaction 问题后值得一试；对于"持续优化、不断发现改进点"这类开放任务，Ralph Loop 的架构基因更匹配。它的"浪费"（每轮丢弃上下文）恰恰是它的优势（破坏 agent 对自己已完成的叙事）。

带走一个判断框架

评估 AI coding 工具的自主循环能力时，不要看功能描述，看三个设计选择：

• 循环边界在哪里：进程级 > session 内 stop hook > session 内 prompt 注入 > 手动"继续"
• 完成判断由谁做：外部验证 > 独立 agent 审视 > 同一 agent 自评
• continuation 的触发条件：外部不满意就续跑 > 有 tool call 才续跑 > 无条件续跑

更关键的是：先想清楚你的任务属于哪种。

如果是"把这个明确的需求做完"，你需要的是一个可预算、可审计的完成器。/goal 的方向是对的。

如果是"帮我持续发现还能更好的地方"，你需要的是一个不断重新采样的搜索器。Ralph Loop 的架构更匹配。

工具不分好坏，但目标函数要对齐。你觉得一个工具"不好用"，很多时候不是工具有问题，是你在用验收型工具做搜索型任务。

这件事值得想深一层。不是"为什么领英在中国失败了"这种商业分析选题，而是一个更底层的问题：为什么中国根本不需要 LinkedIn 这个品类？以及，LinkedIn 在海外正在变成什么？

LinkedIn 需要什么样的土壤

LinkedIn 2003 年上线时，美国的社交网络还是荒地。Facebook 还没出生，人们的职业关系散落在邮件、名片夹、行业会议中。LinkedIn 做了一件简单的事：给每个职场人一张"活的名片"，让弱连接可以被激活。

这个模式的前提是：人们的社交关系没有被一个超级平台垄断。

中国的情况完全不同。猎聘 CEO 戴科彬在 2014 年就看得很清楚：

"LinkedIn 上线时美国没有 IM 社交领域，Facebook 还没出现，他们的社交需求被 LinkedIn 满足了。但中国有 QQ，中国人工作时间都挂着 QQ，现在有了微信……中国人的职业习惯已经被培养为另一种模式了。"

这不是"产品做得不好"的问题，是生态位已被占据的问题。微信让中国人不需要区分"职业社交"和"生活社交"。你的老板、同事、猎头、客户、前同事，全在微信里。加微信就是建立关系，不需要另一个平台。

更深的裂缝：关系文化 vs 弱连接文化

LinkedIn 的核心机制是"弱连接"（weak ties）。社会学家 Granovetter 1973 年的论文《弱连接的力量》说了一个反直觉的观点：给你带来新工作机会的，往往不是密友，而是"认识但不熟"的人。LinkedIn 把这个理论产品化了。

中国的职场不是这样运作的。

中国人靠"关系"（guanxi）：强信任、面子、中间人引荐。你想接触一个人，不是发一封 cold InMail，而是找一个共同认识的人"打招呼"。这个中间人不是算法推荐的"你可能认识的人"，而是一个真实的人、真实的面子背书。

所以 LinkedIn 的核心能力，在中国几乎没有用武之地。

更微妙的是，中国社交产品有一个反复验证的规律：关系链一旦泛化，平台就会失去价值。人人网、微博、微信朋友圈，全都经历了从"私密分享"到"不敢发言"的退化。LinkedIn 那种"所有职业关系都加"的模式，天然就是泛化的。它在中国注定会变成一本"有事才翻"的黄页。

需求没有消失，只是被拆碎了

中国人不用 LinkedIn，不代表没有对应的需求。只是这些需求被不同的产品分别满足了：

求职：BOSS 直聘用"聊天即投简历"的轻模式覆盖从蓝领到白领，1.6 亿月活。中国人需要高效的求职工具，但不需要它附带社交功能。

职场八卦和信息不对称：脉脉的"职言"匿名社区是 LinkedIn 永远不可能做出来的东西。它满足了中国人在职场中"脱去假面"的需求。同事之间的真话，只有匿名才能说出来。

职业关系维护：微信。

个人品牌和行业影响力：分散到了微信公众号、知乎、即刻、小红书。没有一个统一的"职业内容平台"。

这就是 LinkedIn 在中国"不存在"的真相：不是市场空白，是需求被拆碎了。

同一时间，LinkedIn 在海外变成了什么

有意思的是，当 LinkedIn 离开中国的同时，它在海外正经历一次深刻的转型。

2025 年的数据：12 亿注册用户，3.1 亿月活，年营收超 163 亿美元。但真正重要的不是数字，是使用方式的变化。

LinkedIn 正在从"找工作时才打开的平台"变成"职业人的社交媒体"。具体表现：

内容创作爆炸。LinkedIn 的 Feed 不再是"张三升职了""李四换工作了"的通知流。大量用户在上面写行业观察、分享工作心得、发表观点。"LinkedIn Influencer"是一个正式的身份。

Personal Branding 成为核心动机。越来越多人使用 LinkedIn 不是为了"找下一份工作"，而是为了"让下一份工作来找我"。通过持续输出内容，建立行业认知度和不可替代性。

从工具到社区。评论区形成了高质量的行业讨论。很多人每天打开 LinkedIn 的频率和 Twitter 相当。

说白了：LinkedIn 正在变成"穿西装的 Twitter"。一个以职业身份为锚点的内容社交平台。

这暴露了什么

中国没有 LinkedIn，海外 LinkedIn 正在社交化。两件事放在一起，暴露的是一个系统性差异：

中国是"超级 APP + 功能整合"模式。微信一个 APP 解决通讯、社交、支付、小程序、公众号。需求被一个平台通吃，垂直平台很难生存。

海外是"垂直 APP + 场景分离"模式。工作用 LinkedIn / Slack，社交用 Instagram / Twitter，通讯用 WhatsApp。每个场景有独立的平台和独立的身份。

哪个更好？没有答案。但它解释了为什么同一个产品思路，在两个市场得到完全相反的结果。

一个未被满足的缝隙

但这里有一个微妙的空白。

LinkedIn 在海外正在做的那件事，"通过持续内容创作建立职业影响力"，在中国其实没有一个好的承载平台。

微信公众号太重、太正式。知乎太杂、太容易被带偏。脉脉太匿名、太八卦。即刻太小众。小红书太生活化。

一个介于"正式发文"和"随手分享"之间的、以职业身份为锚点的内容社区，在中国并不存在。脉脉试图往这个方向走，但它的匿名基因让它很难成为一个"实名知识分享"的地方。

这可能是中国互联网真正的"LinkedIn 缺位"：不是缺一个求职工具，不是缺一个人脉平台，而是缺一个让职场人可以持续、轻量、实名地输出专业内容并建立行业认知的地方。

谁能填补这个缝隙，谁可能就是中国的"下一代 LinkedIn"。但也许，它根本不会以 LinkedIn 的形态出现。

这不是空想。2024 年 7 月，牛津大学的 Shumailov 等人在 Nature 正刊上证明了一件事：AI 模型训练在自身生成的数据上，会发生不可逆的退化。他们给这个现象起了个名字，叫 Model Collapse。数学上，这不是可能性，而是必然性。

"Over time, models start losing information about the true distribution, which first starts with tails disappearing, and learned behaviours converge over the generations to a point estimate with very small variance."

翻译成人话：模型先丢掉稀有但重要的知识（长尾），然后所有输出趋向"安全的平均值"，最后变成一团正确但无趣的白噪声。

有人给这个过程起了一个更形象的名字：Habsburg AI。

哈布斯堡的诅咒

Jathan Sadowski 在 2023 年造了这个词。哈布斯堡王朝是欧洲历史上最强大的皇室之一，为了保持血统纯正，数百年来坚持近亲通婚。结果是末代国王查理二世：近交系数 0.25（等同于亲兄妹后代），不育、智力低下、下颌畸形。王朝因此终结。

生物学的原理很简单：近亲繁殖让隐性有害基因有更高概率被"双份激活"。基因多样性是种群的保险：它确保当环境变化时，总有一些个体携带应对新挑战的遗传方案。一旦基因池收窄，这个保险就消失了。

AI 正在走同一条路。当模型 A 的输出成为模型 B 的训练数据，B 的输出再喂给 C，每一代都在丢失原始分布中的"稀有等位基因"。互联网上 AI 内容已超过 50%，Graphite 的数据显示 2024 年 11 月起 AI 生成文章数量首次超过人类。也就是说，下一代模型的训练语料里，有一大半是上一代模型"排泄"出来的。

这像极了猎豹的命运。猎豹在末次冰期经历了两次遗传瓶颈，精子异常率至今高达 71%，整个物种脆弱到一场传染病就可能全军覆没。它们跑得飞快，但遗传上已经是一个"几乎相同的个体"的群体。AI 模型也在变得更"流畅"更"快"，但内在的知识多样性正在坍缩。

文明从来在碰撞中产生

人类进化史上有一条反复验证的规律：隔离导致退化，碰撞带来创新。

最极端的案例是塔斯马尼亚岛。一万年前海平面上升切断了它与澳大利亚大陆的联系，此后不足 5000 人的岛上社会，在 8000 年间逐步丧失了骨制工具、渔网、防寒衣物、回旋镖。哈佛大学的 Joseph Henrich 用数学模型证明：文化传承本质上有损，每一代学习者无法完美复制前辈技能。群体越大，出现"偶然改进"的概率越高，可以对冲这种损耗。但当群体太小、又与外界隔绝，技术水平就会呈净下降趋势。

反面的例子同样有力。丝绸之路不只是贸易通道，它是知识的超级公路。阿拉伯数字其实起源于印度，经伊斯兰黄金时代的数学家系统化后传入欧洲，催生了文艺复兴的计算革命。伊斯兰帝国之所以能在 8 到 14 世纪成为全球知识中心，核心原因是它打通了中国、印度、波斯、希腊、埃及的知识流通。Frans Johansson 把这叫做"美第奇效应"：当不同学科、文化和产业在同一个物理空间碰撞时，突破性创新就会涌现。

Henrich 的理论可以浓缩成一句话：创新不是个人天才的产物，而是"集体大脑"在足够大的社会网络中运作的涌现属性。

现在再看 AI 正在做什么：它在缩小这个集体大脑的有效尺寸。

从分发层到生产层：问题已经下沉

互联网时代我们已经体验过"回音室效应"：算法推荐让你只看到你想看的内容。但那是分发层面的问题，信息本身还是多样的，只是分发机制在做筛选。

AI 时代的危险在于，问题从分发层下沉到了生产层。不是"你只能看到你想看的"，而是"所有人只能想到同样的东西"。

2026 年发表在 Nature 正刊上的实证研究分析了 4130 万篇论文，发现了一个悖论：使用 AI 工具的科学家个人产出提升 3 倍、引用提升 4.8 倍、晋升加快 1.37 年。但同时，AI 采纳使得学术界研究的主题总量缩减了 4.63%，科学家之间的互动降低了 22%。

个体变强了，集体变窄了。

Cornell 大学的实验更直观：让印度和美国的参与者使用 AI 写作后，两国人的文字"变得更相似"，都趋向"西方规范"。甚至被问到最喜欢的食物时，用 AI 辅助的人更可能回答"pizza"。

"AI is a technology of averages: large language models are trained to spot patterns across vast tracts of data; the answers they produce tend toward consensus."
— Kyle Chayka, The New Yorker

剑桥大学的 Traberg 等人在 2026 年把这个循环描述得很清晰：研究 AI 的实践本身正在变得统一，不仅是研究什么在收敛，连问题怎么被框定、怎么被调查、怎么被评估，全在趋同。他们引用了一个精准的类比：

"Just as biodiversity protects ecosystems from collapse, intellectual heterogeneity protects science from paradigm shocks."

三条链条的正反馈环

把上面说的整合起来，我看到三条因果链在互相喂养：

链条 A：AI 工具同质化 → 研究方法和主题趋同 → 科学变成"单一种植"。

链条 B：AI 训练数据来自 AI 输出 → Model Collapse → 知识退化，尾部消失。

链条 C：AI 生成内容占据互联网主体 → 人类原创被挤出 → 认知多样性萎缩。

A 减少了 B 的多样性输入，B 加速了 C 的退化速度，C 进一步缩窄了 A 的研究视野。这是一个正反馈退化环。

最让我不安的是第三条链。StackOverflow 的问题量已经下降了 78%。不是因为人们不再有问题，而是问技术问题的习惯正在从"社区互答"迁移到"问 AI"。但 AI 的回答是基于它训练时吞掉的那些社区问答。一旦社区萎缩，AI 的知识来源也在萎缩。这像一棵树在啃食自己的根。

解药存在，但需要刻意的制度设计

好消息是，生物学早就给出了解法：引入外来基因。瑞典有一个被农业活动隔离的蝰蛇种群，出现了高比例的死产和畸形。研究者引入了其他种群的个体后，种群迅速恢复。

对应到 AI：NeurIPS 2024 的论文证明，只要训练时把合成数据"叠加"到真实人类数据上（而不是替换），Model Collapse 就可以被避免。甚至只保留 10% 的真实人类数据，就能显著延缓退化。

但这需要刻意的制度设计，不会自发发生。几个方向值得关注：

• 数字种子库：有人已经在系统性存档 AI 爆发前的人类创作内容，类比冷战后科学家保存"核爆前钢铁"（未被核辐射污染的钢材在精密仪器中不可替代）。
• 数据血统管理：标注每条训练数据是人类产生还是 AI 产生，建立来源溯源。哈佛法学院已经在讨论"未被 AI 污染的人类数据权利"。
• 方法论多元主义：在学术资助中刻意保护非 AI 路径的研究。不是所有问题都应该用同一把锤子。
• 跨模型杂交：有实验证明，用模型 A 的输出训练模型 B（不同架构），比 A 训练自己退化更慢。类似于远缘杂交的杂种优势。

我的判断

Model Collapse 不是终将到来的末日预言，它是已经在发生的渐进过程。互联网内容中 AI 的占比每月都在上升，每一天都有新的模型在训练时不自觉地吞入上一代模型的输出物。

但我不认为这是不可逆的宿命。它更像一个公共卫生问题：如果放任不管，退化会持续加速；如果有意识地管理数据来源的多样性，保持人类原创输入的"基因流"，系统可以维持健康。

真正让我警惕的，是一个更深层的问题。AI 正在把知识生产从"碰撞模式"推向"收敛模式"。在碰撞模式下，不同背景、不同训练、不同文化的人互相激发，产出超越各自视野的新东西。在收敛模式下，所有人用同一个工具、看同一批数据、得到同一个"最可能的答案"。

人类文明最伟大的突破，几乎都来自碰撞：希腊哲学遇到阿拉伯数学产生了科学方法，东方丝绸遇到西方玻璃催生了光学实验，生物学观察遇到工程学思维发明了尼龙搭扣。

如果 AI 让所有人都在同一个知识空间里用同一种方式思考，那么即使每个人都变得更"高效"了，人类作为整体的创新能力也可能在下降。就像塔斯马尼亚岛上的居民：他们并不比祖先更笨，但因为群体太小、太隔绝，无法维持复杂技术所需的知识传承临界量。

AI 时代的反直觉真相是：让所有人都变聪明的工具，可能让人类集体变蠢。

解法不是拒绝 AI，而是刻意维护多样性。用不同的模型、保留人类原创、鼓励跨界碰撞、保护那些"低效但独特"的知识路径。在进化论里，那些看起来没用的基因变异，往往是物种在下一次环境剧变中存活下来的关键。

知识世界也一样。

这个问题背后有一个看起来矛盾的信号。一方面，技术社区里"RAG is dead"的声音此起彼伏，长 context window 每半年翻一倍，Gemini 的 1M token、Claude 的 200K，似乎让"先检索再生成"越来越多余。另一方面，打开 Indeed 一搜，4800+ 个标注 RAG 的职位在招，高级岗薪资 $240K 起步，MarketsandMarkets 预测整个 RAG 市场 5 年内从 $19 亿涨到 $99 亿。

如果 RAG 真的在死，为什么就业市场在疯狂招人？

我的判断是：RAG 作为一个 demo 级技能在贬值，但 RAG 作为企业级系统工程在增值。公司招的不是"会用 LangChain 搓一个 pipeline"的人，而是能解决三个远比 RAG 本身更难的问题的人：合规和权限控制、可观测性与评测、Agentic RAG 编排。

这三件事跟网上 99% 的 RAG 教程完全不是一个东西。

教程教的 RAG 为什么越来越不值钱

打开 YouTube 或 Medium，2026 年的 RAG 教程和 2024 年几乎没有区别：加载文档、切分 chunk、生成 embedding、存入向量数据库、查询检索、拼接 prompt、调用 LLM 生成。四步走。一个下午就能跑通。

问题在于，这四步走的价值正在被两个方向同时压缩。

从上面看，长 context window 在蚕食简单场景。Tian Pan 的 production 决策框架给了一组很务实的数据：Gemini 1.5 Pro 在 needle-in-haystack 上达到 99.7%，但在现实的多事实检索上只有 60%，延迟是 RAG 的 30-60 倍，成本是 1,250 倍。换句话说，对于"一个文档里找一个答案"这种简单任务，长 context 已经够用了。RAG 在这个场景里确实在变多余。

从下面看，框架在把搭建门槛压到接近零。LangChain 和 LlamaIndex 让任何人都能在几小时内搭出一个 RAG demo。但真实工程经验揭示了硬币的另一面：同一个抽象层在 demo 阶段省了时间，到生产阶段每个请求多加了 2 秒延迟。TechTide 有一个尖锐的总结："LangChain 因为门槛低成为所有人的第一选择，也正因如此，很多团队用它构建了不该用它的系统。"

这两个方向的合力，让"会搭 RAG pipeline"这个技能的稀缺性快速蒸发。它变成了一个入门级操作，类似于 2015 年的"会写 SQL 查询"。有用，但单独拿出来不值钱。

公司真正在招的，是三种不同的能力

KORE1 的薪资指南有一句话说得很到位：

"RAG architecture went from obscure to essential in about eighteen months. The people who've done it well, in production, at scale, have their pick of opportunities."

关键词是 in production, at scale。不是"会搭"，是"搭了能用、用了不出事、出了事能查"。

DevOpsSchool 的 Senior RAG Engineer 角色蓝图把这个需求拆得很清楚。十项核心职责里，搭建检索管道只占两项。剩下八项全是教程不教的东西：安全加固、评估体系、可观测性、生产运维、质量门禁、护栏编排。

第一：合规和权限控制

这是最被低估的方向，也是最致命的。

标准 RAG 的安全模型有一个根本性的漏洞：向量数据库检索的是语义最相似的文档，不管这些文档的所有者是谁。安全研究者 Christian Schneider 把这叫做 RAG 的"信任悖论"：用户查询被当作不可信输入，但检索到的上下文却被隐式信任，尽管两者进入了同一个 prompt。

这不是理论风险。2024 年 8 月，PromptArmor 发现 Slack AI 存在间接提示注入漏洞：攻击者在公开频道发布恶意指令，当其他用户使用 Slack AI 时，系统将该消息检索为上下文并据此构造钓鱼链接，可以从攻击者无权访问的私有频道泄露 API key。Amine Raji 的实验更直接：在标准 ChromaDB + LangChain 栈上，跨租户数据泄露在 20 次查询中 100% 成功，"不需要任何技术能力"。

四大主流向量数据库（Pinecone、Weaviate、Qdrant、Milvus）都不原生支持 ACL 和每查询审计日志。权限控制必须在应用层从头构建。教程永远不会教你这些，因为解决方案不是通用的，它需要知道"用户是谁"和"他们被授权看什么"。

第二：可观测性、评测和调试

RAG 的 debugging 跟传统软件有本质区别。传统软件失败时会崩溃、报错、返回错误码。RAG 系统的失败是安静的：它不崩溃，只是给了一个看起来合理但错误的答案。

更麻烦的是，失败会级联。Zen Van Riel 总结得很精准："Bad chunking causes bad embeddings, which causes bad retrieval, which causes bad generation. Fix the root cause, not the symptom." 你在生成层看到的问题，根因可能在切块层。

要诊断这些问题，需要一整套工具栈。当前最佳实践是三段式组合：开发期用 RAGAS 做质量评估，CI/CD 用 DeepEval 做部署门禁，生产环境用 LangSmith 或 Arize 做持续监控。这套能力已经催生了独立岗位：ZipRecruiter 和 Greenhouse 上都有专门的 LLM/RAG Evaluation Engineer 在招。

而且这个方向的价值不只在工程侧。EU AI Act 正在把 RAG 系统的可审计性从"最佳实践"提升为合规要求。对受监管行业来说，可观测性不是可选项。

第三：Agentic RAG

如果说前两个方向是"把 RAG 做对"，Agentic RAG 是"把 RAG 做强"。

传统 RAG 的管道是线性的：检索一次，生成一次。Agentic RAG 引入一个 Agent 作为编排器，让系统能动态决策：这个问题需不需要检索？检索结果够不够？要不要换个查询词再来？要不要拆成子问题分别检索？要不要调用其他工具来补充？

Self-RAG（ICLR 2024 Oral）让模型自行决定何时检索并自我评估质量；CRAG 在检索结果不满足时触发 web search fallback，准确率提升近 13%；Adaptive RAG 用小型分类器预判查询复杂度，动态选择检索策略。框架层面，LlamaIndex 最早推广 Agentic RAG 概念，LangChain 将 Agent 编排集中到 LangGraph，Microsoft 在 2025 年 10 月将 AutoGen 和 Semantic Kernel 合并为统一的 Agent Framework。

代价是 token 消耗3-10 倍。但对于跨文档合成、多步推理的复杂任务，这个成本是值得的。基准测试显示 RAG 在跨文档合成任务上比长 context 准确率高 67%，成本低 8 倍。

好事和坏事

好事在于，这三个方向远比"搓 RAG pipeline"更有职业价值。

合规和权限控制不是 RAG 独有的。掌握了它，你在做 MCP 集成、Agent 平台、企业数据中台时都用得上。可观测性和评测更是 transferable 的核心能力：任何 AI 系统进入生产都需要评测，任何 LLM 应用上线都需要可观测性。Agentic RAG 的 Agent 编排能力直接接轨整个 Agentic AI 赛道，Stanford AI Index 显示这个技能集群一年增长 280%。

用武侠的话说，这三条路打通的不是一个穴道，是任督二脉。

坏事在于，这些能力没办法通过跟教程搓 RAG pipeline 来学会。教程的 happy path 上没有权限问题（示例数据不分权限），不需要评测体系（示例问题有标准答案），不需要 Agentic 编排（示例查询单次检索就能回答）。

更深层的原因是：这三个方向本质上都是系统工程问题，不是算法问题。你不能通过读论文或看教程视频来掌握它们。你需要在一个真实的、多用户的、有权限边界的、有脏数据的、有合规要求的系统里摸爬滚打。

这也解释了为什么 Tunga 的观察如此尖锐：招聘经理"不知道怎么招、不知道怎么筛、不知道怎么评"。因为他们要的能力没有对应的教程认证，只有项目经历能证明。

"RAG is Dead"需要分层看

在简单场景上，RAG 确实在退让。一个文档内找一个答案，长 context 更直接。Callstack 的工程师在真实项目中发现，很多场景用"确定性预处理 + 结构化上下文注入 + 单次 API 调用"比搭完整 RAG 栈更简单。

但在企业场景上，RAG 不可能死。成本和延迟是第一个原因（1M token 请求成本是 RAG 的 1,250 倍）。知识库规模是第二个（2GB 文本约 5 亿 token，远超任何 context window）。权限隔离是第三个（长 context 要把所有文档灌入 prompt，权限隔离几乎无法实现；RAG 的分层架构天然支持 pre-retrieval filtering）。

所以更准确的说法是：naive RAG 在死，production RAG 在活。简单单文档查询长 context 准确率高 34%，跨文档合成 RAG 准确率高 67%。两者是按场景互补的关系，不是替代关系。

如果你要学，学什么

回到开头的问题：2026 年 RAG 值不值得学？取决于你学的是哪个 RAG。

如果你学的是"用 LangChain 搓一个 embed-store-retrieve-generate 的 demo"，这个技能的市场价值正在快速归零。不是因为它没用，而是因为它太容易被复制。

如果你把 RAG 当作一个入口，通过它进入企业级 AI 系统工程的三个核心领域，那它是目前最好的学习路径之一。RAG 是最早进入企业生产环境的 LLM 应用模式，它积累的生产经验最丰富、踩过的坑最多、形成的工程实践最成熟。通过 RAG 学合规，比从零学合规快；通过 RAG 学评测，比抽象地学方法论扎实；通过 RAG 学 Agent 编排，比直接跳进 Agentic AI 有更好的基础。

具体建议：

1. 跳过纯教程阶段，最多花一个下午。一个 demo 跑通就够了。
2. 尽快接触真实数据。找一个有权限边界的数据集（哪怕自己模拟多用户），体会"语义检索 vs 权限控制"的冲突。
3. 从第一天就搭评测体系。用 RAGAS 跑你的 pipeline，看 faithfulness 和 context precision 的分数。你会发现 demo 的好分数在换了数据集后会断崖式下跌。
4. 至少做一次 Agentic RAG 实验。用 LangGraph 搭一个会自我评估检索结果、会 rewrite query 的系统。你会立刻理解为什么这比 naive RAG 难一个数量级。
5. 读生产级经验，不读教程。Looming Tech 的企业部署经验和 Zeta Alpha 的 GenAI pilot 失败分析比任何教程都有价值。

回到那个矛盾：RAG 看衰和 RAG 招聘火爆并不矛盾。看衰的是教程级 RAG。火爆的是企业级 AI 系统工程，RAG 恰好是它最可见的入口。公司在 JD 里写"要会 RAG"，其实是在说"要会在生产环境里把 AI 做对"。

不要把 RAG 当终点学，把它当隘口学。穿过这个隘口，你进入的不是"RAG 专家"这条窄路，而是 AI 系统工程的广阔地带。合规、评测、可观测性、Agent 编排，这些能力在未来五年只会越来越稀缺。而 RAG，只是通往那里最近的一条路。

这句话如果只说一半，容易被误解成“本地 Agent 不重要”。我不是这个意思。对个人用户来说，本地 Agent 的优势非常明显。我的文件在本机，我的浏览器登录态在本机，我的开发环境在本机，我的很多真实 context 也只在本机。Manus 这样的 cloud agent 再强，也拿不到这些东西。它后来推出 My Computer，本质上就是承认 cloud sandbox 有本地上下文缺口。

但一旦把场景换成公司，这个判断就要反过来看。

公司的电脑名义上在员工手里，但资产、权限、知识和审计链路并不在员工手里。Wiki 在云上，Slack 在云上，GitHub 在云上，SharePoint 在云上，数据仓库在云上，CRM、工单、日程、邮件也大多在云上。员工只是被授权访问这些系统，不是这些系统的所有者。

所以企业 Agent 的真正问题，不是“云端好还是本地好”。
更正确的问题是：组织上下文在哪里，权限在哪里，审计在哪里，执行在哪里。

个人的 local 优势，到了公司会变成治理问题

个人使用 local agent 的优势很直接：它离真实工作现场最近。

你让它改一个本地项目，它能读文件、跑测试、看日志。你让它整理一堆桌面文件，它不用申请复杂权限。你让它操作浏览器，它可以借用你已有的登录态。对个人来说，这种“贴身”就是生产力。

但公司看同一件事，视角会完全不同。

本地 Agent 读了哪些文件？有没有读到不该读的目录？它调用了哪个 MCP？这个 MCP 是谁写的？有没有把数据发到外部网络？它生成的结果有没有被评测？失败日志在哪里？离职以后这些 skill 和上下文归谁？

个人觉得便利的地方，企业会看成治理盲区。

这不是保守，而是组织的基本责任。公司不是一个放大的个人。公司里存在团队边界、密级边界、地区边界、合规边界、系统边界、岗位边界。Agent 越能跨系统行动，越不能只靠个人本地自由配置。

云端不是因为更先进，而是因为更接近组织上下文

很多人讨论 cloud agent 时，会默认它和“模型更强”“算力更大”“异步执行”绑定在一起。这些当然重要，但不是企业场景里最本质的部分。

企业 cloud agent 真正的优势，是它天然更靠近组织系统。

公司里的上下文越来越少存在于某台电脑里，而是存在于一组 SaaS 和平台中：代码在 GitHub，文档在 SharePoint 或 Google Drive，沟通在 Slack 或 Teams，项目在 Jira，客户在 CRM，数据在 warehouse，指标在 BI，知识在 wiki，流程在工单系统。

如果 Agent 要回答一个真实业务问题，它需要穿过这些系统。它不是读一个本地文件就够了。它要知道这个人有没有权限，某个文档是不是最新，某个数据指标有没有认证，某个 Slack 讨论是不是只在小范围频道里，某个代码仓库是不是内部可见。

这也是为什么 OpenAI Company Knowledge、Microsoft 365 Copilot Agent Builder、GitHub Copilot Spaces 都在强调同一件事：尊重已有权限模型。OpenAI 说 Company Knowledge 只访问用户已经有权查看的内容；Microsoft 写到 agents respect existing Microsoft 365 permissions；GitHub Spaces 也说 follows the same role/visibility model。

这些表述背后是同一个判断：企业 Agent 的产品价值，不只是能不能把答案生成出来，而是能不能在组织边界内生成答案。

Local Agent 在企业里的新角色：受管数据面

如果只看到上面这一点，很容易得出另一个过头结论：企业都应该用 cloud agent，本地 agent 没价值。

这也不对。

Manus 的 My Computer 很有代表性。它原来完全活在 cloud sandbox 里，但后来仍然要进入用户桌面。原因不是 cloud sandbox 不好，而是很多真实工作就是发生在本地：项目文件、开发环境、桌面应用、本地算力、已登录浏览器、内网资源。

企业也是一样。开发者的 IDE 和 terminal 在本地，很多内网工具只能从公司网络访问，某些系统有 IP 白名单，某些文件不允许上传到 SaaS，某些操作必须在受控终端执行。

所以 local agent 不会消失。它会改变角色。

它不再应该是一个完全自治的个人外挂，而应该变成企业 Agent 系统里的受管数据面。它负责进入端点，云端负责下发策略。它可以读取本地，但要遵守本地目录范围。它可以调用工具，但工具来自企业 registry。它可以执行任务，但关键动作要审批。它可以产生结果，但 trace、日志、产物和 eval 要回传。

Cloud 是控制面，Local 是执行面之一。

控制面决定谁能做什么，能连什么，能读什么，结果如何评测，风险如何审计。执行面负责在具体环境里完成任务，包括云端浏览器、Slack bot、IDE 插件、本地 CLI、桌面 Agent、私有网络 runner。

Share skill 的重点，也要从“共享文件”升级成“共享能力供应链”

这个判断会改变 share skill 的 big picture。

如果 Agent 是个人工具，那么 share skill 很容易被理解成：我写了一个好用的 prompt 或 markdown，发给你，你放到本地目录里用。

这在早期很有价值，因为启动成本低。团队可以快速把经验沉淀下来，也能形成示范效应。

但公司级 skill sharing 不能停在这里。

Anthropic 对 Agent Skills 的定义是 instructions、scripts、resources 的组合，而且 Agent 可以动态加载。它还提醒用户只安装可信来源的 skill，低信任来源要审计。这其实已经说明 Skill 不只是文档，而是软件资产。

既然是软件资产，就不能只靠群文件传播。它需要 owner、版本、依赖、适用范围、测试样例、评测分数、变更记录、审批、回滚。

OpenAI 关于 skill eval 的文章也给了一个重要信号：真正成熟的 Skill，不应该只靠“感觉更好用”。它应该有 prompt、captured run、trace、artifacts、checks、score。也就是说，Skill 要能被回归测试。

这是个人经验和组织能力的分水岭。

个人经验可以靠体感。组织能力必须靠可复现证据。

企业 AI-native org 的三层结构

把这些放在一起，我更倾向于把企业内部 Agent 系统设计成三层。

第一层是 local agent。它负责个人实践、私有上下文、本地工具、桌面文件、IDE、终端、浏览器登录态和快速试验。它是创新的前线，也是 Skill 的生产入口。

第二层是团队 skill repo。这里放的不是散乱 prompt，而是版本化的 skills、scripts、references、examples、evals、metadata。每个 Skill 要有 owner，有适用场景，有验收标准，有变更记录，有失败案例。它应该像代码一样走 review，而不是像资料一样到处转发。

第三层是企业治理面。这里负责 registry、权限、MCP allowlist、审计、eval dashboard、发布、回滚、数据边界和生命周期管理。它解决的是组织级问题：哪些能力可以被发现，哪些工具可以被调用，哪些数据不能出界，哪些动作需要审批，哪些 skill 已经过期。

这三层都少不了。

只有 local agent，会形成个人英雄主义和治理盲区。只有 cloud agent，会丢失端点上下文和真实执行力。只有 skill 文件，会变成高级 prompt 仓库，很难形成稳定的组织能力。

真正要画的四条线

所以，我不太想把这个问题继续表述成“小龙虾这样的 local agent 是不是公司里的最佳形式”。这个问法容易让人陷入工具对工具的比较。

更好的问法是四条线。

第一，上下文线。哪些 context 属于个人工作现场，哪些属于组织系统？个人现场可以本地优先，组织系统应该云端优先。

第二，权限线。哪些权限来自用户本人，哪些权限来自 Agent 专属身份？用户能看，不代表 Agent 就应该自动用。企业需要 agent-specific scope。

第三，审计线。哪些动作必须留痕，哪些产物必须可回放，哪些失败必须进入 eval dataset？只要涉及组织资产，就不能只存在本机日志里。

第四，执行线。哪些任务需要云端异步执行，哪些任务必须在本地、内网或私有运行时执行？执行位置可以多样，但控制规则要统一。

这四条线比“云端 vs 本地”更重要。

我的结论

如果一个团队正在推进 share skill，我会建议不要一上来就追求大而全的企业平台，也不要停留在本地目录同步。

更务实的路径是：先让 local agent 成为个人工作流试验场。让真正高频使用 AI 的人，把自己的流程跑通，把有效方法沉淀成 Skill。然后把高频 Skill 提升到团队 repo，要求每个 Skill 至少包含说明、脚本、示例、适用边界和最小 eval。最后再接企业治理面，把可复用 Skill 纳入 registry，把 MCP server 纳入 allowlist，把运行 trace 和 eval 接起来，把版本发布和回滚建立起来。

这条路不性感，但更像组织能力。

AI-native org 不是每个人都装一个更强的 Agent。
AI-native org 是组织能把自己的隐性知识、判断标准、工具边界和执行流程，持续封装成 Agent 可调用、可验证、可审计、可演化的能力。

本地 Agent 是很好的起点。云端控制面是组织化的必经之路。真正的分水岭，不在云端和本地之间，而在个人效率和组织能力之间。

这个问题有点反直觉。过去二十年，互联网行业很大一部分信仰都建立在产品力上。好的体验，好的交互，清晰的路径，克制的界面，强大的生态。微信几乎就是这个时代最典型的答案。

但 AI 进来之后，事情开始变得别扭。很多原本由产品界面解决的问题，正在被模型直接吸走。用户不一定要理解页面结构，不一定要找入口，不一定要在复杂系统里点来点去。他只要说出意图，模型就可能直接给答案、调工具、跨系统执行。

所以我现在的判断是：AI 没有让产品力失效，但让产品力换了位置。过去的产品力主要是“人如何更舒服地使用软件”，现在的产品力越来越是“人和 agent 如何更可靠地完成任务”。

旧产品力为什么突然变薄了

传统互联网产品的界面，本质上是一种最大公约数。

一个按钮放在哪里，一个菜单怎么分层，一个流程拆成几步，一个首页展示哪些入口，背后解决的是同一个问题：让尽可能多的用户，在一个统一界面里，以较低成本完成任务。

PC 互联网和移动互联网时代，这个能力非常值钱。因为人必须通过界面理解系统。你做得更优雅，用户就更愿意留下来；你少一步操作，转化就可能提高；你让复杂功能变简单，就能赢一大批用户。

AI 把这个前提动摇了。

模型正在学习直接使用软件。它可以看屏幕，可以理解页面，可以点击，可以调用工具。它不一定需要产品团队为每个用户设计一条最优路径。只要系统能被它理解，很多界面复杂度就会被它穿过去。

这会让传统产品优势变薄。不是体验不重要，而是体验的上游变了。过去体验来自页面结构，现在体验可能来自模型理解力、工具编排、上下文质量、权限边界、失败回滚和执行审计。

用户感受到的还是“好不好用”。但真正决定好不好用的东西，已经不完全在前端。

技术型公司为什么前半程更顺手

AI 前半程更像一场底层能力赛。

模型能力、算力投入、上下文长度、工具调用、agent loop、训练和评测体系，都还在快速变化。今天不能稳定做的任务，几个月后可能突然能做了。今天必须绕很多产品设计的地方，下一代模型可能直接穿过去。

这就是为什么过去靠技术路径成功的公司，在 AI 前半程更容易进入状态。

它们不会天然排斥技术团队赛马。一个团队做长上下文，一个团队做 coding，一个团队做多模态，一个团队做推理效率，这在它们的组织语言里不是重复造轮子，而是在探索能力边界。

而产品型公司容易有另一个惯性：两个产品团队赛马可以，两个底层技术团队赛马就显得浪费。因为在传统互联网时代，技术更多是服务产品。产品想清楚，技术做出来，增长再推起来，这是很多公司的默认肌肉记忆。

AI 把这个顺序倒过来了。很多时候不是产品定义清楚后技术实现，而是模型能力突然上了一个台阶，产品定义才被迫重写。

在这种时候，技术力不是幕后能力，而是方向发生器。

运营型公司为什么更容易先拿到钱

相比产品解，运营解反而更容易在第一波 AI 中找到抓手。

原因很简单：运营链路里有大量高频、重复、规则明确、结果可量化的任务。客服等待时长、重复咨询率、单次服务成本、售后解决率、营销制作成本、审核处理量，这些指标非常适合 AI 进入后直接对账。

携程这类公司很典型。它需要处理大量咨询、改签、取消、售后和目的地信息。AI 不需要一开始就重塑整个旅游产品，只要接住一段重复链路，就能看到等待时长下降、人工压力下降、信息处理效率上升。

Klarna 的客服 AI 也是类似逻辑。无论你怎么打折看这些官方数据，有一点很清楚：AI 在客服、售后、销售支持和营销制作里，首先改变的是成本结构。

产品解更难，是因为它经常要回答“AI 放进来会不会破坏原来的品位”。运营解更直接，它只问“这件事能不能更快、更便宜、更少出错”。

新的产品力不是界面，而是执行系统

如果只说产品型公司不占优势，这个判断会过头。

更准确地说，传统产品力正在被拆开。界面美学、交互细节、视觉统一这些仍然重要，但它们不再足够。AI 时代新的产品力至少包括四件事。

第一，agent 可执行。你的产品能力不能只是人在页面上点得顺，也要能被 agent 读懂、调用、组合和完成。

第二，工作流可嵌入。用户不想再多开一个 AI 功能页。他希望 AI 进入自己原来的工作流，帮他处理原来就要处理的任务。

第三，结果可验证。AI 做错不是边角问题，而是生产系统必须面对的常态。产品必须设计过程证据、回滚机制、人工确认和权限边界。

第四，信任可建立。过去产品让人感觉“好用”，现在还要让人相信“它替我做事不会乱来”。

这四件事背后，已经不是单纯前端能力，而是产品、技术、运营、治理、数据和组织协作的混合体。

所以 AI 时代的产品力更难了。它不是没价值，而是不能再只由产品经理和设计师闭门打磨出来。它必须长在模型能力、业务语义、评测闭环和运营系统之上。

优势真正迁移到了哪里

过去很多公司把优势存放在三个地方。

第一，界面和用户心智。用户习惯你的入口，知道怎么用你的产品。

第二，流程和人力。大量运营、客服、审核、销售、交付团队支撑复杂业务。

第三，软件系统和数据。系统越厚，流程越深，迁移成本越高。

AI 之后，这三个地方都不会消失，但都会被重新定价。界面会被 agent 穿透一部分。流程会被自动化压缩一部分。软件系统会被模型和工具调用重新包装一部分。

真正变贵的，是更上游的东西：业务语义、私有上下文、判断标准、评测样本、责任边界、组织验收能力。

这和我一直说的“AI+工程，而非工程+AI”是一回事。如果只是给旧系统外挂 AI，就会停在功能增强。真正的变化是按大 Agent 重新设计系统：AI 负责理解、决策、生成和执行，工程负责数据、权限、稳定性、审计和验证。

在这个结构里，公司的核心优势不是“我们有多少功能”，而是“我们是否知道什么叫做对，并能让 agent 稳定做对”。

别急着给公司贴标签

这件事不能简单外推成技术公司必胜、产品公司必败、运营公司稳赚。

产品力会回潮。第一波 AI 竞争看技术和运营，但当底层模型逐步商品化，新的产品力会重新变重要。只是那时的产品力不再是传统 GUI，而是 agentic workflow 的体验、信任和分发。

运营 ROI 容易先出现，也容易先碰到天花板。客服自动化能降本，但如果过度追求效率，可能伤害客户满意度。少人不是胜利，单位价值提升才是胜利。

技术力也不是纯模型竞赛。算力和模型重要，但没有业务闭环、数据回流、评测体系和安全边界，技术能力很难变成稳定业务价值。

所以最后能走到后半程的公司，可能不是三类里某一类的纯粹代表，而是能完成重新组合的公司：底层有技术沉淀，中层有运营闭环，上层有新的产品表达。

真正的问题

如果把这个判断落回公司经营，我会问几个更具体的问题。

我们的核心 knowhow 是否已经机器可读？还是还藏在老员工经验、会议纪要和口头习惯里？

我们的高频任务有没有明确验收标准？还是只有“差不多”“看感觉”“让某某把关”？

我们的 AI 失败样本有没有回流？还是每次错了就人工改掉，下次继续错？

我们的业务语义有没有统一？同一个指标、同一个客户状态、同一个服务动作，跨团队是不是同一套解释？

我们的权限和责任边界是否清楚？agent 能做什么，不能做什么，错了谁负责，怎么追溯？

这些问题比“要不要做一个 AI 产品”更重要。因为它们决定的不是一个功能能不能上线，而是公司能不能把 AI 变成组织能力。

最后的判断

饭桌上的那个问题，最后可以这样回答。

AI 时代，产品型公司不是没有机会。但如果还把产品力理解成“做一个更优雅的界面”，机会会变少。技术型公司在前半程更占便宜，因为能力边界还在快速上移。运营型公司更容易先拿 ROI，因为它们有大量高频、可量化、可替代的流程。

但最终的分界线不是产品、技术、运营三种标签。

真正的分界线是：你的公司优势，到底还存放在人手、页面和流程里，还是已经迁移到了 agent 能理解、能执行、能被验证的系统里。

AI 不是让公司不需要能力。它只是把能力从“谁能做”迁移到了“谁知道什么叫做对，并能把对的标准管理起来”。

我自己一开始装 OpenClaw 的时候，也有类似体感。你要处理安装、部署、模型、API key、消息入口、skill、权限、成本、容器、网络。开发者会觉得运行链路不够干净，非开发者更惨，很多时候连问题出在哪一层都不知道。

但这件事真正有意思的地方也在这里：OpenClaw 确实火了，而且是在全球范围内火。它不只是一个工具被讨论，而是带动了很多 Cloud Agent 类型产品出圈。

所以问题不是“它到底是不是一坨屎”。问题是：为什么一个体验这么差的东西，仍然让那么多人愿意围着它折腾？

如果只看体验，确实解释不了

外部评测里对 OpenClaw 的体验吐槽并不少。GrowwStacks 在一篇实操评测里说，OpenClaw 的 setup process quite technical，需要 VPS、终端命令和基础编码概念。即便有所谓 one-click deploy，也仍然要配置 LLM、API key 和 agent architecture。

这不是小瑕疵，而是典型的早期开源 Agent 产品问题：它把本该由产品消化的复杂度，直接暴露给用户。

开发者面对的是工程复杂度：Docker 怎么跑、端口怎么绑、Telegram 怎么接、skill 为什么坏、模型调用为什么贵。非开发者面对的是认知复杂度：不是不会输命令，而是不知道这个系统到底由哪些层组成。

所以如果按传统消费级产品标准看，OpenClaw 不应该火。它不够顺滑，不够稳定，不够安全，也不够可解释。

但这恰恰说明：我们用错了尺子。

它真正卖的不是稳定，而是未来感

Frontier Learning Lab 有一句话抓住了关键：Most AI we use today is “chat-in-a-box.” OpenClaw represents the shift to Agentic AI. It doesn’t just talk; it does.

这就是 OpenClaw 的核心。它不是让用户多一个聊天窗口，而是让用户看到一个新物种：一个可以通过 Slack、Telegram、WhatsApp 这类消息入口常驻，可以访问本地文件，可以执行任务，可以完成后主动回报，甚至可以通过写代码补齐能力的 agent。

这件事对用户的冲击，不是“这个产品好不好用”，而是“原来 AI 可以这样存在”。

传统 AI 产品像一个问答柜台。你走过去，问一句，它答一句。OpenClaw 更像一个粗糙的数字员工。它笨、脏、不稳定，但它第一次坐到了你的工作流里，而不是停在网页里。

这也是为什么它能带动 Cloud Agent 类型产品出圈。用户真正想要的不是“自托管”这三个字，而是一个 24 小时在线、可以从消息入口调度、能接工具、能持续执行并回报的 agent。OpenClaw 给了这个想象力，Cloud Agent 负责把部署、稳定性和安全成本往平台侧搬。

体验越差，教程生态越旺

这听起来反直觉，但在开源工具传播里很常见。

如果一个工具安装极其顺滑，教程空间反而有限。OpenClaw 这种工具不同：安装复杂会产生新手教程，部署复杂会产生一键安装器，运维复杂会产生代部署服务，成本复杂会产生优化指南，安全复杂会产生警告文章。

换句话说，它的粗糙体验没有只造成流失，也制造了内容供给。

这不代表体验差是好事。长期看，体验差会限制留存和商业化。但在爆发早期，粗糙体验会让社区产生大量“帮你搞定它”的二次创作。每一篇“别踩坑教程”，本质上都在替 OpenClaw 做传播。

这也是为什么很多早期开源明星项目，往往不是先像消费级 App 一样顺滑，而是先像乐高散件一样有可玩性。它吸引的第一批人不是普通用户，而是 builder、折腾者、教程作者、集成商、安全研究员和想抢窗口期的人。

安全争议不是旁枝，而是主干的影子

OpenClaw 的安全争议很严重。Immersive Labs 提到 one-click RCE、CVE-2026-25253、ClawHub 恶意 skills、暴露实例等问题。Frontier Learning Lab 则引用 Simon Willison 的 lethal trifecta：访问私有数据、访问互联网、能够采取行动。

这个框架非常适合理解 OpenClaw。

一个只能聊天的 AI，安全风险有限。一个能读邮件、改文件、跑命令、发消息、连外部服务的 AI，风险立刻变成系统级风险。

但也正因为它拿到了这些权限，它才像一个真正的 agent。

这就是 OpenClaw 的悖论：它危险，是因为它有用。它被安全研究员反复警告，反而说明它触碰到了真实生产力边界。一个玩具不会引发这种级别的安全讨论，一个能接管工作流的工具才会。

所以我不认为安全争议只是负面公关。它更像一次行业教育：当 AI 从“回答”走向“行动”，治理问题会从提示词风险升级为权限、供应链、审计、隔离和组织管控问题。

别迷信产品完成度，要看范式完成度

很多产品分析会犯一个错误：用成熟产品的尺子衡量范式切换期的样机。

成熟产品当然要看上手成本、留存、稳定性、客服、权限管理、企业治理。但范式样机最重要的问题不是这些，而是：它有没有让人看到一个以前看不到的工作方式。

OpenClaw 做到了。

它让人看到：AI 不一定是一个网页，不一定是 IDE 插件，不一定是一次性对话。它可以变成一个常驻的执行体，躲在消息入口后面，连接文件、工具、网页、API 和其他 agent。

这就够了。早期爆发不需要 100 分体验，有时候 30 分体验加 90 分想象力，就足以让一个项目冲出圈。

这不意味着 OpenClaw 值得普通人现在就装。相反，对多数非技术用户，我会建议先看，不要把真实数据和关键账号交给它。对企业，更不该让这种工具以 Shadow AI 的方式进入生产环境。

但如果看趋势，它值得研究。因为它暴露了下一代 Agent 产品的五个真实战场。

第一，低摩擦部署。用户想要 agent 常驻，不想先学 DevOps。

第二，权限隔离。Agent 越有用，越要有边界。

第三，执行审计。替人行动之后，过程证据比最终结果更重要。

第四，成本控制。Agent 会自己循环、调用、试错，费用不是线性增长。

第五，生态治理。Skill 市场不是插件市场那么简单，它更像一个能直接接触用户系统权限的软件供应链。

真正的信号

我更愿意把 OpenClaw 看成一台冒烟的蒸汽机。

它吵、脏、危险、难维护。站在马车时代最成熟的审美里，它当然很差。但它暴露出来的不是一个工具的小问题，而是一类新机器的大方向。

这对做 AI 产品的人有一个提醒：不要只问用户体验是不是顺滑，还要问用户愿不愿意为了某个新能力忍受摩擦。

如果用户愿意忍受很多摩擦，说明那里有强需求。后来的产品机会，就是把这部分摩擦系统性吃掉。

OpenClaw 的奇迹不在于它体验差还能火。真正的奇迹是：它差成这样，用户还是愿意围着它折腾。

这才是信号。

我的判断就一句话：AI 时代人的稀缺能力，不是亲手完成每一步，而是把工作改造成 AI 可执行、人类可验收、组织可追责的任务。

为什么"乙方"这个比喻用得上

把 AI 说成工具，说的是"谁用谁知道"；说成员工，说的是"要管要带要考核"。这两种说法都不太贴。AI 更像一个高吞吐、低摩擦、可反复返工的乙方。

乙方的第一个特征，是必须拿到清晰 brief 才能干活。GitHub 在讲 Copilot coding agent 的工程实践时反复强调的一件事是：生成代码是直接了当的，审查代码、确保它符合标准、做了你想做的事、能被你的团队维护，仍然需要人的判断。OpenAI 推 AGENTS.md 的背后逻辑也一样：给 AI 一份可读的项目工作手册，而不是指望它从对话里猜出你的规范。这不是 prompt 工程的花活，这是甲方给乙方的施工方案。

乙方的第二个特征，是交付要过验收，不能自证完成。GitHub Copilot coding agent 默认的产品形态是"做完 tag 你 review，CI/CD 需要人工批准"。OpenAI 在 Codex 的介绍里也写得很明白：用户仍然必须在集成和执行前手动审查和验证所有 agent 生成的代码。这些都不是谨慎派的说教，而是真实产品里默认打开的保护机制。

乙方的第三个特征，是可以给更多自主权，但关键控制权必须留在甲方。Anthropic 讲有效 agent 的时候把话说得很清楚：需要清晰的成功标准、反馈循环、以及有意义的人类监督。这不是为了让人多一道章，而是因为一旦 agent 真的有权限敲键盘、改文件、发请求、调 API，任何模糊的授权都会在某个角落被滥用。

生产力收益是真的，但有三重打折

外部数据里最被引用的一条，是 St. Louis Fed 的估算：生成式 AI 用户平均每周节省 2.2 小时，折算约 5.4% 的工作时长。Harvard 和 BCG 对咨询顾问的实验更乐观：能力边界内的任务，效率提升 25%，完成量多 12%，质量高出 40% 以上。这些数字是真的。

但它们有三重需要打折的地方。

第一重，这些多是自报数据。"用得爽"和"真的节省"在问卷里分不开，把 2.2 小时理解成每周凭空多出 2.2 小时新产出，是过度解读。

第二重，能力边界外的使用会反向扣分。同一项 Harvard / BCG 研究还有另一个结论：当任务超出 AI 能力边界时，使用 AI 的顾问正确率反而下降 19%。Harvard Crimson 对此有句话很尖锐：更快地得到错误答案，不算生产力。

第三重，对经验丰富的知识工作者，收益甚至可能是负的。METR 在 2025 年做过一次很严谨的 RCT，针对经验丰富的开源开发者在真实代码任务上做了对照实验。反直觉的结论是：在 20 分钟到 4 小时的真实 coding 任务上，使用 AI 的开发者更慢。不是工具不好，而是熟练者知道自己怎么写代码，多出来的是"审查加纠偏加返工"的开销。

三重折扣叠在一起，比较诚实的总结是：AI 的生产力收益真实存在，但会被任务类型 × 使用者经验 × 验收门槛三个维度调制。哪一维错位，账就可能从正变负。

比喻不要用过头，要补三个原生批判

"AI 是乙方"是一个有用的起点，不是终点。把它用过头，会漏掉三个在传统甲乙方关系里不存在的问题。

第一个问题：AI 乙方的能力会持续漂移。传统乙方能力相对稳定，甲方几次合作之后可以把验收流程固化下来。AI 乙方不是这样。基础模型每几个月一次跃迁，同样一份 AGENTS.md，半年前跑不动的任务今天可能一把过；同样一份 review 清单，上个月抓得住的 bug 这个月可能已经不会再出现。甲方能力的本质不是"建立一套 SOP"，而是持续校准：每隔一段时间重新评估哪些任务可以放权、哪些必须收回、哪些模板需要重写。这种动态校准是传统甲方管理里没有的职责。

第二个问题：验收能力的自我循环困境。传统认知里，能判断代码好坏的人是写过很多代码的人，能判断方案好坏的人是做过很多方案的人。如果未来大部分执行被 AI 接走，新一代从业者没有足够的执行经验去建立判断力，几年之后谁来做验收？这个循环从个人层面延伸到组织层面：一家公司如果过早把所有"动手活"交给 AI，它在一段时间内看起来效率很高，但当下一次模型能力波动、任务超出边界、或出现新型业务场景时，它可能已经没有足够多的"能判断对错"的人了。

第三个问题：谁来验收验收者？如果甲方能力是判断乙方做得对不对，那谁来判断甲方做得对不对？当人做验收时，他的判断由同伴、上级、客户的反馈来校准；当验收者也开始借助 AI 辅助时（比如用另一个模型 review 前一个模型的产出），验收本身就进入了 AI 辅助的链条。整个体系需要一个新的"元锚点"去定义什么叫做对。目前没有一个行业有清晰答案。

我没有全套方案。但我觉得这三个问题必须显式摆在桌面上，而不是被一句"AI 像乙方"顺滑地盖过去。

甲方新能力是四件事，不是"会写 prompt"

收益和风险说清楚之后，落回到"一个人、一个团队、一个管理者到底要做什么"。甲方新能力不是"更会写 prompt"，而是四件事。

第一件：把目标讲清楚。不是把需求写成多长的文档，而是把目标讲成可被执行的形状。一个可以交给 AI 的目标应该能回答三个问题：产出物是什么、约束条件是什么、输入从哪里来。OpenAI 推 AGENTS.md 的背后逻辑就是这个：给 AI 一本可读的工作手册，而不是期望它从对话里猜出项目规范。

第二件：把验收标准写在前面。大部分 AI 项目翻车的原因，不是 AI 做错了，而是甲方没讲清楚什么叫做对。验收标准的简单模板是：用什么方式验证、谁来验证、失败时怎么处理。代码场景里这套标准天然存在（单元测试、集成测试、PR review）；在写作、分析、决策这些场景里，这套标准需要被显式建出来。

第三件：看懂过程证据。AI 说"已完成"不算完成。过程证据包括：它调用了哪些工具，读了哪些文件，写了哪些内容，跳过了哪些步骤。GitHub 的 Mission Control 有一句我很同意的话：当检查失败时，不要简单重启 agent，要调查为什么失败。甲方看过程证据的能力，是防止"表演式交付"的唯一办法。

第四件：为结果负责。OpenAI 在讲 AI-native engineering team 时把话说得最直白：工程师最终为部署到生产环境的代码负责。这里不需要太多解释。把任务外包给 AI 不改变责任归属，只改变执行方式。如果一位产品经理说"这个需求是 AI 写的，不准的地方不怪我"，这家公司的验收体系已经塌了一半。

这四件事不对称：讲清楚目标偏向个人技能，写验收标准偏向团队机制，看懂过程证据偏向工具链和可观测性，为结果负责偏向组织文化。任何一件没做到，剩下三件的价值都会大打折扣。

对三类人的不同含义

如果你是个人从业者，真正应该练的不是"让 AI 写得更多"，而是四件事里的前两件：把目标讲清楚、把验收标准写在前面。大多数人用 AI 的瓶颈不是模型不够强，而是自己没想清楚要什么。一个简单的自检：每次使用 AI 前，用 30 秒写下"这次我希望它产出什么、我怎么判断它做到了"。写不出来，说明任务本身还没定义好，让 AI 先做只会把不清晰的需求放大。

如果你是团队 leader 或项目 owner，真正该投入的不是"更强的工具"，而是任务模板、验收标准、过程可观测性。McKinsey 的 State of AI 调研指出，高绩效组织比普通组织更可能"根本性重新设计个人工作流"。重新设计工作流听起来抽象，落到具体就是：哪些任务可以交给 AI、输入从哪来、输出要达到什么标准、谁来 review、失败如何升级。这些不是 AI 项目，是组织工程。

如果你是管理者，值钱的管理工作正在被重新定义。AI 不会自动消灭管理工作，但会压缩低价值的管理工作：进度追踪、信息汇总、会议纪要、催办、格式校对，这些会被逐步吸收。真正留给管理者的价值点会往两端集中：一端是定义什么叫做对（验收标准、质量基线、风险边界），一端是为组织判断力的长期再生产负责（有没有培养出能独立判断的人，有没有机制持续校准能力边界）。把管理者的 KPI 从"推动多少事发生"转向"让多少事被判断得对"，是这一阶段组织设计的关键题。

回到开头

回到开头那个场景。真正困扰人的不是 AI 做得快，而是判断它做得对。这件事过去也存在，只是过去的甲方通常自己是乙方出身，自己干过几年，验收时的肌肉记忆已经内化，所以"多一道审核"看起来不费力。现在 AI 把执行的成本压到很低，同时把执行的数量和速度拉到很高。当产出像潮水一样涌过来，"验收"就不再是工作流程里的一个步骤，而变成工作本身。

这个时候，"当好甲方"就不再是比喻，它是一组具体能力：讲清楚需求、写清楚验收、看懂过程证据、为结果负责。这四项能力过去分散在不同角色里（产品、架构师、测试、leader），现在会被压到每一个严肃使用 AI 的从业者身上。

如果让我从这轮调研里挑一个最值得带走的直觉，就是这句话：AI 时代最贵的能力，是知道什么叫做对了，并能在一个合理成本内把这件事验证到位。

本文的局限性

第一，引用的多数数据来自 2024 到 2025 年的研究。2026 年上半年以来的模型跃迁在这些研究基线里还没有充分体现，METR 那种"经验开发者用 AI 反而变慢"的结论是否在新一代模型上仍然成立，我没有把握。

第二，本文的甲乙方比喻天然偏向知识工作，尤其是软件工程。coding agent 是整个调研里证据链最清晰的一块，但它不代表所有知识工作。在销售、教学、客服、设计这些场景里，验收标准的结构完全不同，这套四件事框架需要重新具体化。

第三，关于"验收能力自我循环"和"元验收问题"，本文提出的更多是判断和警告，不是方案。如果未来一两年这个领域出现真正有效的组织实践，文中的结论应当被修订。

最近一两个月，我的体感变差了，尤其是 PC 端。社区里也有人有类似反馈。与此同时，一些免费的、开源的、或者更轻的语音输入方案开始变好。这件事让我想到一个更大的问题：AI 时代产品方法变了，但 less is more 的逻辑没有变，甚至变得更重要。

我不想把这篇写成对 Typeless 的吐槽。公开资料里也不能证明 Typeless 最近两个月整体变差，或者快捷键变更引发了大面积投诉。能确认的是另一件事：Typeless 官方已经把产品从语音输入扩展到了 Translate、Ask anything、选中文本问答和编辑；官方 FAQ 也写明，核心 voice-to-action 功能联网效果最佳，离线能力仍在开发。

这就够了。因为真正值得讨论的不是 Typeless 某个版本好不好，而是一个原本靠“轻”打动用户的 AI 产品，为什么会很自然地走向“重”。

用户买的不是功能，是一条不用想的路径

一个语音输入产品最打动人的时刻，不是它能不能翻译，也不是它能不能问答，而是你在任意输入框里按下一个键，说完一段话，然后得到一段基本可提交的文字。

Typeless 在中文社区里仍然有不少正面评价。V2EX 上有重度用户说它“除了贵几乎没有什么大毛病”，还说长一点的输入直接说出来就能达到可提交程度。这个评价很关键。用户愿意为它付费，买的不是“语音识别”四个字，而是“我不用再改太多”。

这类产品的价值不在功能表里，而在一条主路径里：启动、说话、识别、整理、落入输入框。只要这条路径足够稳，用户会原谅它贵一点、少一点、丑一点。反过来，只要这条路径开始不稳，再多的附加能力都会变成噪音。

输入法和普通应用不一样。普通 AI 应用慢一下，用户可能等一等。输入法慢一下，用户会烦。因为输入不是一个任务，输入是所有任务的入口。越底层的工具，越不应该抢戏。

传统软件的功能膨胀是 UI 债，AI 产品的是智能债

传统软件加功能，通常多一个按钮、多一层菜单、多一页配置。用户付出的成本是看、找、点、记。NN/g 把这种成本叫 interaction cost，包括阅读、查找、点击、等待、注意力切换和记忆负担。

AI 产品不一样。它每加一个功能，往往不是多一个按钮这么简单，而是多一段 system prompt、多一个工具描述、多一种意图识别、多一类上下文、多一条失败路径。

传统输入法增加一个皮肤功能，核心输入路径未必受影响。AI 输入法增加“随口问”和“随时翻译”，系统就必须先判断你到底是在输入、翻译、编辑，还是问答。判断错了，体验就错了。

这就是我说的智能债。UI 债让用户不爽，智能债会让系统变笨。它的表现不一定是崩溃，而是更隐蔽：输出变慢、误解意图、格式不稳、需要更多人工修正、偶尔不像以前那么懂你。用户未必知道背后的技术原因，只会说一句：没有以前好用了。

这也是为什么 AI 产品更要克制。复杂度不再只影响用户心智，也会进入模型上下文、工具选择、延迟和基础设施。

免费平替变好，是对付费产品的边界测试

现在中文社区里已经有 TypeMore、OpenTypeless 这类开源或免费替代品，卖点集中在免费、本地、BYOK、离线和可控。它们一开始未必全方位超过 Typeless，但它们会持续逼近核心动作：把语音变成可用文本。

这对 Typeless 这类产品来说，不是简单的价格战，而是边界测试。

如果免费方案能把核心输入做到 70 分，付费产品就必须证明自己为什么值得。答案不能是“我还有翻译”“我还能问答”“我还有团队功能”。这些都可以有，但它们不能替代一个更基本的问题：我是否在最常用的那条路径上，比别人更快、更稳、更少打扰？

AI 产品的竞争最后会回到结果确定性。模型能力越来越普及后，功能数量不是护城河，能不能稳定完成一个真实任务才是护城河。

微信不是功能少，而是主路径少

很多人讲 less is more，容易讲成“少做功能”。这个理解太浅。微信就是最好的反例。

微信功能并不少。支付、公众号、小程序、视频号、企业微信生态，复杂到几乎能装下一个数字社会。但张小龙真正厉害的地方，不是永远少做，而是尽量不让复杂能力破坏聊天主路径。

2019 年微信公开课里，张小龙说微信的原动力之一是“坚持做一个好的、与时俱进的工具”。a16z 对他的产品原则有一句整理我很认同：作为工具，微信必须帮助用户在最短时间内获得最有用的信息。

所以微信案例的启发不是“功能越少越好”，而是“主路径越少越好”。复杂能力可以在后面，但入口要克制，心智要稳定，高频动作不能被低频想象力打断。

这正是很多 AI 产品容易忘掉的事情。团队看到模型能力强了，就会自然想把更多场景塞进来。可用户最初爱上的，可能只是那一个不用想的动作。

很多团队不是因为不努力失败，而是因为太努力

功能膨胀通常不是懒惰造成的，而是努力造成的。

用户提需求，团队想满足；竞品加功能，团队想追上；融资后要讲增长，团队想扩场景；付费用户要更多价值，团队想证明订阅合理。每一步都合理，最后产品却变得不合理。

这就是产品管理最难的地方：大多数失败不是团队不努力，而是团队把努力用在了增加可能性上，而不是提高确定性上。

对 AI 产品尤其如此。早期用户被打动，往往是因为一个能力突破了阈值。识别准了，整理好了，速度快了，路径短了。这个时候最重要的不是马上扩到十个场景，而是把这个突破打磨到别人追不上。

一旦团队开始用新功能替代核心体验打磨，就会出现一个危险信号：用户看到产品更强了，但感觉产品更差了。强的是功能表，差的是日常主路径。

我会用四条原则看 AI 产品

第一，守住一句话定位。用户应该能一句话说清你解决什么问题。如果一句话里出现三个动词，产品边界已经开始危险。

第二，保护最高频路径。任何新功能都不能增加高频动作的认知成本。输入类产品尤其如此，因为输入是所有任务的入口。

第三，给上下文设预算。AI 产品不是把信息塞得越多越好，而是越准越好。上下文预算、工具预算、延迟预算，都应该像财务预算一样被管理。

第四，用可靠性约束功能扩张。每一次功能扩张，都应该绑定识别准确率、延迟、失败率、用户修正率，而不是只看功能使用次数。

回到那个快捷键

Typeless 最早让我惊艳的地方，不是它野心大，而是它把一个老问题做轻了：人在电脑上说话，文字可以比较自然、比较干净地落到输入框里。

这个价值足够大。大到我愿意第一次认真考虑，自己是不是应该为一个“输入法”付年费。

但越是这种底层工具，越要克制。用户不是来探索功能的，用户是来继续做自己原来的事。工具越靠近底层，越不应该抢戏。

如果让我把这次反思压成一句话，就是：AI 产品未来的护城河，不是更多功能，而是更少但更稳的主路径。

谁能更稳定地完成一个真实任务，谁就能留下来。谁把最初打动用户的点稀释掉，谁就会被更便宜、更简单、够用的产品从下面追上。

那时候我的判断很简单：Figma 的优势在设计生产，但 AI 正在把生产这件事从画布里抽走。Pencil 把设计搬进 IDE，让设计文件和代码共享 repo、branch、commit、merge，这看上去像是一个更接近 AI Coding 时代的设计工具。沿着这个逻辑看，Figma 的问题不是没有 AI，而是它还站在画布中心思考 AI。

这个判断没有错，但只说对了一半。

最近用 Claude Design，我的判断又变了一次。Claude Design 当然也能生成设计、原型、slide、one-pager，也能导出 PDF、PPTX、HTML，甚至能把设计 handoff 给 Claude Code。但如果只把它看成一个设计工具，就错过了它真正重要的地方。

Claude Design 不是 Anthropic 跨界做了一个 Figma 竞品。它更像是 Anthropic 把 Claude Code 那套工作架构，换了一个介质，搬到了视觉设计里。

这件事比设计工具竞争本身重要得多。

我看到的不是功能，是架构

Claude Design 最让我停下来的地方，不是它生成出来的页面有多好看，而是它的 onboarding。

它不是先问你喜欢什么颜色、什么字体、什么圆角，也不是让你从一个空白画布开始拖组件。它先问：有没有 codebase 可以读？有没有一份能代表你们品牌的 PPT、PDF 或设计文件？然后它从这些材料里抽取 color palette、typography、components、layout patterns，生成一套团队设计系统。之后每个项目都会默认带着这套系统往前走。

这看起来是在解决品牌一致性，实际上是在解决 agent 的工作条件。

一个人类设计师之所以能持续做出"像这个公司"的东西，不是因为他每次都重新思考品牌色，而是因为他脑子里已经沉淀了一套长期有效的默认判断：这个品牌通常用什么节奏，什么视觉语气，什么组件习惯，什么布局密度，什么东西看起来"不像我们"。

Claude Design 做的第一件事，就是把这些默认判断变成 agent 每次工作时都会带上的持久上下文。

这和 Claude Code 里的 CLAUDE.md 是同一件事。Claude Code 文档里说得很清楚：CLAUDE.md 是放在项目里的 markdown 文件，Claude Code 会在每次 session 开始时读取，用来承载 coding standards、architecture decisions、preferred libraries、review checklists 等长期指令。它不是一个 prompt 小技巧，而是让 agent 不必每次从零理解项目的"项目记忆"。

换到设计领域，这份记忆不再是代码规范，而是品牌资产、组件习惯、版式语言和视觉边界。

所以 Claude Design 的关键不是"能不能画图"，而是它先问了一个更底层的问题：

一个设计 agent 要想稳定工作，它每次启动时必须知道什么？

这是我认为它和 Claude Code 完全同构的地方。

真正的统一架构：不是工具，而是工作环境

我现在越来越觉得，未来垂直岗位和 AI 结合的最佳实践，不是"给这个岗位做一个 AI 工具"，而是给这个岗位搭一套 agent 可以稳定工作的环境。

这套工作环境至少有五层。

第一层是持久上下文。它回答的是：这个岗位里有哪些东西不应该每次重新解释？对工程师来说，是代码结构、架构约定、测试命令、review 标准。对设计师来说，是品牌系统、组件库、设计原则。对 PM 来说，是核心用户是谁、我们做什么、不做什么、哪些取舍原则高于短期需求。对法务来说，可能是合同模板、风险偏好、审批红线。对投研来说，可能是投资框架、历史案例、估值口径和禁区。

第二层是任务上下文。它回答的是：这一次具体要做什么？用户是谁，目标是什么，输入材料有哪些，约束是什么，失败模式是什么，参考样例是什么。Claude Design 里的 brief、上传文档、网页抓取、inline comment，都是在补这一层。Claude Code 里让它先读 repo、看 issue、跑测试、理解 error log，也是这一层。

第三层是专业技能。它回答的是：这个岗位有哪些可复用的动作流程？Anthropic 对 Agent Skills 的定义很接近这一点：Skill 是一组 instructions、scripts、resources，Claude 可以在相关任务里动态加载；它的核心原则是 progressive disclosure，先只加载 name 和 description，真正需要时再读取完整 SKILL.md，必要时再读取更多文件或运行脚本。

这句话翻译成岗位语言就是：不要把所有专业知识都塞进一次 prompt，而要把可复用的专业流程做成 agent 能按需调用的工作手册。

第四层是可执行介质。工程师的介质是 repo、terminal、IDE、git。设计师的介质是 canvas、HTML、PPT、Canva、Figma、Claude Code handoff。PM 的介质不是 PRD，而是 metrics、用户反馈、原型、issue、launch room、evals。很多人还在问"AI 能不能替我写产物"，但更重要的问题是：AI 到底能在哪里行动？它能读什么，改什么，运行什么，提交什么，交付到哪里？

第五层是评估闭环。没有 evals 的 agent workflow，本质上还是一次性生成。真正可规模化的 agent workflow，一定要有某种"成功长什么样"的可执行定义。工程里是 test、lint、CI、review。设计里可能是品牌一致性、可用性、状态覆盖、视觉偏差检查。PM 里就是 Cat Wu 说的 evals：不需要几百个，10 个好的 evals 就能让团队量化目标、量化进展、看到缺口。

把这五层合在一起，你会发现 Claude Design 和 Claude Code 不是两个产品，而是同一套东西在两个介质里的实例化。

Claude Code 是代码岗位的 agent 工作环境。

Claude Design 是设计岗位的 agent 工作环境。

未来每个岗位都会长出自己的 agent 工作环境。

这也是 Cat Wu 那段访谈真正重要的地方

我原来读 Cat Wu 那篇访谈，最容易被那句"真正值钱的是判断该写什么"吸引。它当然很对。当代码越来越便宜，判断做什么会更值钱。

但现在把 Claude Design 放在一起看，我觉得更重要的不是这句话，而是她描述的 Anthropic 内部工作方式。

她说 AI 原生产品里，PM 的重点不应该是维护多季度 roadmap，而是想办法让一个 idea 以最快速度到用户手里。她提到团队会做严格的 weekly metrics readout，让每个人理解业务；会有一份团队原则，写清楚核心用户是谁、为什么是他们、愿意牺牲什么；会用 research preview 降低上线承诺成本；工程、marketing、docs、DevRel 之间有非常紧的 launch room，让一个功能准备好后第二天就能推出去。

这不是普通意义上的"PM 用 AI 提高效率"。

这是把 PM 这条链路本身重新架构了。

过去 PM 的工作经常被理解成写 PRD、拉会、对齐路线图、协调资源、推动上线。AI 时代，如果工程速度被 Claude Code 大幅加速，PM 的瓶颈就不再是"怎么把需求写清楚"，而是"怎么让团队更快地从信号走到判断，从判断走到行动，从行动走到验证"。

这条链路可以写成：

信号 → 判断 → 行动 → 验证。

信号来自 metrics readout、核心用户反馈、dogfooding、模型边界测试。

判断来自团队原则、产品品味、对当下模型能力的理解。

行动由 Claude Code、Cowork、内部工具和轻量 launch process 放大。

验证由 evals、用户反馈、research preview 和下一轮迭代完成。

这和 Claude Design 做的事情完全对应。设计师的链路是：

需求理解 → 方向探索 → 产物生成 → 视觉验证 → 工程 handoff。

Claude Design 加速的不是"画一个页面"这一小段，而是把整条链路变成 agent 可以参与、可以沉淀、可以复用、可以 handoff 的系统。

所以 Cat Wu 的访谈和 Claude Design 其实在讲同一件事：AI 不是把某个岗位里的一个动作变快，而是把整个岗位链路变成一个更短的闭环。

真正被替代的不是岗位，而是没为 agent 搭好工作环境的岗位

这也是我觉得这轮变化比"设计师会不会被替代"大得多的原因。

很多关于 AI 的讨论还停留在岗位名上：设计师会不会被替代，PM 会不会被替代，工程师会不会被替代，分析师会不会被替代。

但岗位名其实是一个很粗糙的单位。AI 真正冲击的不是岗位名，而是岗位里那些没有被结构化、没有被验证、没有被自动化、没有被沉淀的工作链条。

一个设计师如果只会把需求翻译成静态稿，那部分工作会迅速被 Claude Design 这样的工具吞掉。但如果他能把品牌判断沉淀成设计系统，把常见视觉问题写成评估规则，把探索路径变成可复用 skill，把 handoff 变成能直接进入工程实现的包，他就不是在和 AI 抢"画图"这件事，而是在设计整个设计 agent 的工作环境。

一个 PM 如果只会写 PRD，再把 PRD 扔给工程师，那部分工作也会越来越薄。但如果他能把用户信号接进来，把团队原则写清楚，把判断标准变成上下文，把模糊问题拆成可测试的 evals，把从 idea 到用户的路径压到最短，他做的就不是传统 PM，而是产品链路的加速器。

一个运营、法务、财务、HR、投研人员也是一样。

未来每个岗位都要回答同一个问题：

你能不能把自己岗位里的隐性经验，改造成 agent 可以读取、调用、执行、验证的系统？

能回答这个问题的人，不会被简单替代。回答不了的人，不一定被 AI 替代，但会被那些已经把 agent 工作环境搭好的同行替代。

所以，Claude Design 的意义不在设计

我现在回头看 Claude Design，觉得它最重要的地方甚至不在设计。

它演示了一件更通用的事：当模型能力足够强，产品的核心不再是给用户一个更强的编辑器，而是给 agent 一个更好的工作环境。

这个工作环境里，要有长期记忆，要有本次任务的上下文，要有可调用的专业技能，要有能行动的介质，要有评估和 handoff 的闭环。

Anthropic 在 context engineering 那篇文章里讲过一个很关键的观点：agent 的关键不只是写好 prompt，而是持续管理进入模型上下文的所有信息，包括 system instructions、tools、MCP、external data、message history 等。上下文本身是有限资源，应该用最小但高信号的信息集，最大化模型产生目标行为的概率。

这句话放到岗位上看，几乎就是下一代职业方法论。

过去一个职业高手的优势，藏在脑子里、经验里、习惯里、判断里。新人跟着他干几年，才能慢慢学会什么该看、什么不用看、什么是红线、什么是好、什么是差、什么时候该推进、什么时候该停。

现在这些东西第一次可以被写进上下文、skills、tools、evals 和 workflow 里。它们不再只是人的经验，而会逐渐变成组织的可执行资产。

Claude Design 把这件事在设计领域演示了一遍。

Claude Code 已经在工程领域演示了一遍。

Cat Wu 描述的 Anthropic PM 工作方式，又在产品管理领域演示了一遍。

它们共同指向同一个结论：

AI 原生岗位的核心，不是人更会使用 AI，而是岗位本身被重新组织成一套 agent 可运行的架构。

最后

所以这次我改的不是对 Pencil 的判断。

Pencil 也好，Stitch 也好，Figma 也好，它们仍然是重要的设计工具。但 Claude Design 让我看到的不是一个新工具，而是一种更底层的迁移：同一套 Claude Code 架构，正在被套到代码之外的每一种专业介质上。

今天是设计。

明天是 PM、运营、销售、法务、财务、投研、客服、HR。

每个岗位最后都会被问同一个问题：你的 CLAUDE.md 是什么？你的 skills 是什么？你的工具接口在哪里？你的 evals 怎么写？你的 handoff 怎么闭环？你的经验能不能从个人直觉，变成 agent 可以工作的环境？

这才是 Claude Design 真正值得看的地方。

它不是设计工具的一次更新。

它是所有垂直岗位 agent 化的一次公开样板。

这句话挺狠，但不是没有道理。

它真正想说的是：一个 Skill 越好，越容易把原来靠人脑、课程、咨询和实施服务传递的知识压缩成一个文件。别人装上以后，AI 就能直接做。原来的价值链被它打掉了，但这个 Skill 本身又因为可复制、可传播、可改写，很难继承那部分收入。

我读完之后的感觉是：方向有点对，但还没打到最深处。

它说清楚了“Skill 作为文件为什么不值钱”，但没有继续追问：当 Skill 文件不值钱之后，什么东西开始值钱？

Skill 的问题，不是没有价值，而是价值不在它身上

Anthropic 对 Agent Skills 的定义很清楚：它是一个包含 instructions、scripts、resources 的文件夹，Claude 会在相关任务里自动加载。后来 Anthropic 还把它做成 open standard，强调跨平台可迁移。

这本来是好事。标准越开放，生态越容易长起来。

但商业上也会带来一个结果：单个 Skill 很难长期保持稀缺。你今天写了一个 Excel 财务模型 Skill，明天社区里可能出现十个类似版本，后天模型平台可能把高频能力直接内置。

所以，Skill 不是没有价值。它的价值只是很难停留在“这个文件只有我有”这件事上。

这和开源世界很像。代码可以免费，但围绕代码的稳定发行版、企业支持、安全审计、集成服务、责任主体，仍然可以收费。Skill 也类似。Skill 本体会变便宜，但围绕 Skill 的运行系统，反而可能开始变贵。

Excel 课程和 Skill，不是同一种价值

原文里有个例子，说过去有人花钱学 Excel 财务模型，现在一个 Skill 就能让 AI 做出来，所以原来的课程和咨询价值会被压缩。

这个例子很形象，但我觉得还可以再拆一层。

一个人花 1000 块学 Excel，并不只是买一段知识。他真正买的是长期能力。学会之后，未来几年都能靠这个能力提高效率、少犯错、升职加薪。课程只是入口，真正的付费理由是未来收益。

Skill 不一样。你拿到一个 Skill，很多时候不是你本人学会了什么，而是 AI 暂时获得了某种执行能力。这个能力不一定属于你，也不一定稳定存在。下一代模型更强了，可能就不需要这个 Skill 了。平台把它内置了，也不需要了。

所以 Skill 的价值衡量方式要换。

不是问：这个 Skill 帮我做了一件事，值多少钱。
而是问：这个 Skill 能不能持续嵌入我的工作系统，并且在模型变化、业务变化、数据变化时继续产生复利。

如果不能，它就是一个模板。如果能，它就不只是 Skill，而是运行系统的一部分。

真正的分水岭，是运行时在谁手里

原文还有一个判断：Skill 作者拿不到数据飞轮。用户在 Claude 或 ChatGPT 里运行 Skill，真实任务、失败案例、业务数据、修改反馈都进了模型平台，作者什么都拿不到。

这在很多消费级场景里是对的。

但这不是 Skill 天生命运，而是运行时归属决定的结果。谁控制运行时，谁控制数据飞轮。

如果 Skill 只是一个文件，执行发生在模型公司的环境里，飞轮当然归模型公司。如果企业通过自己的 agent 网关运行，日志、失败样本、权限、评测结果就可能沉淀在企业内部。如果 Skill 平台托管执行，它可以拿到 usage、质量、留存和错误模式。如果 Skill 绑定自有 API，数据又会回到 API 提供方。

所以真正的问题不是“Skill 有没有数据飞轮”，而是“谁拥有执行环境、日志、评测和反馈”。

这也是我觉得那篇文章有点浅的地方。它看见了 Skill 作者没有数据，却没有把问题继续推到运行时、权限、评测和治理上。

托管服务不只是 AWS 转售

原文说，把 Skill 做成托管服务，本质是在卖 hosting。这个判断对个人小工具可能成立，但对企业场景太简化。

企业买一个 agent runtime，不只是买服务器。

它买的是：谁能运行，能读哪些文件，能不能调用外部 API，执行过程有没有日志，失败能不能回滚，版本怎么管理，安全事故谁负责，敏感数据能不能脱敏，输出能不能评测，哪些 Skill 可以进入组织目录，哪些要被禁用。

这些东西不是 hosting，它们是治理。

Claude Code 的安全文档里提到默认只读、权限审批、沙箱执行、写入边界。Anthropic 也有 Software Directory Policy，要求目录里的 Skills、Plugins、MCP 等软件持续符合安全和合规规则。这些信号说明，Agent 执行不是简单调用模型，而是权限、安全、合规和责任问题。

所以未来真正可收费的，可能不是 Skill，而是 SkillOps：目录、审计、认证、权限、沙箱、版本、评测、回滚、责任链。

如果 AI 替代知识工作，别在被替代区域里找长期利润

我更愿意把 Skill 放到一个更大的背景里看。

如果 AI 会替代很多知识性工作，那么在“被替代工作本身”里寻找长期利润，意义可能不大。就像农业机械化之后，长期利润不再主要属于“更多农民下地干活”，而是迁移到机械、种子、化肥、土地、加工、渠道、品牌和金融。

知识工作也会发生类似变化。写文章、写代码、做报表、做分析、写总结、生成方案，这些任务不会消失，但它们的边际价格会下降。真正有利润的地方会迁移到基础设施、业务入口、私有数据、权限体系、责任承担、判断标准和执行闭环。

也就是说，未来不一定是谁更会写 Skill 赚钱，而是谁能让 Skill 接进真实系统、真实数据、真实权限、真实业务结果里赚钱。

这也解释了为什么我一直觉得，代码不再是壁垒，平台能力才是；认知是资产，代码是消耗品；AI+工程，而不是工程+AI。

Skill 是名片，但它也应该是接口

原文最后说：Skill 是名片，不是产品。

我基本同意，但我会再加一句：Skill 是名片，也是接口。

作为名片，它证明你有能力把一个领域的隐性经验抽象成 AI 可执行的结构。一个咨询师发布一个高质量行业 Skill，比写一篇文章更能证明他真的懂这个场景。一个产品团队发布一组高质量 Skills，也比单纯说“我们 AI-native”更有说服力。

但作为接口，它还有另一层价值。它把你的方法论暴露给 Agent，把你的产品暴露给外部工作流，把你的业务能力暴露给新的执行入口。

这时候 Skill 不赚钱也没关系。它可以像 SDK、API 文档、开源库、案例模板一样，成为分发和信任入口。真正收费发生在后面：API、托管、企业版、审计、服务、培训、私有部署、结果交付。

最后的判断

我不会把 Skill 看成一个要不要收费的小商品。我更愿意把它看成 AI 时代知识工作重组的中间形态。

它会压缩很多旧收费点，也会打开一些新收费点。旧收费点是培训、模板、初级咨询、重复交付。新收费点是运行时、审计、私有上下文、业务闭环、判断标准和责任承担。

Skill 作为产品会自我消解，
作为接口会重新分配价值。

真正要研究的不是 Skill 怎么赚钱，而是 Skill 把哪部分知识变便宜之后，哪部分能力开始变贵。

如果一个 Skill 后面没有系统，它就是一个漂亮模板。它可能会传播，也可能会被复制，但很难长期收费。

如果一个 Skill 后面有运行时、有数据、有权限、有评测、有审计、有责任链，它就不再只是一个 Skill。它是 AI 进入真实工作的接口。

所以我一开始看鸭哥那篇《团队中共享 AI skills 的原则与方法》，并没有把重点放在“这套目录怎么建”。真正让我觉得值得往下想的，是它实际上动了一个更深的前提：团队知识不一定非得先统一，才能被共享。

这件事一旦成立，AI 时代的团队知识库就和传统 wiki 不是一个物种了。

传统知识库管理的是信息，AI 时代管理的是行为

传统知识库的目标很明确：把信息写下来，方便人去查。最好的状态通常是一份统一定义，一份标准口径，一套大家都能接受的说法。它服务的对象首先是人，所以它天然追求可读、可查、可统一。

但 AI 时代不一样了。你写下来的东西，不只是给人看，还会被 Agent 拿去当运行时上下文。它会影响 AI 选什么工具、走什么路径、按什么口径解释问题、输出什么风格。也就是说，知识不再只是“描述世界”，而开始“塑造行为”。

传统团队知识库在解决“信息怎么保存”。
AI-oriented Context Infrastructure 在解决“组织经验怎样在任务执行时被稳定调用”。

这就是我觉得最本质的结构变化。对象变了，治理方式就一定会变。

真正被打碎的，不是文档格式，是“唯一权威版本”这个幻想

鸭哥文章里最有价值的地方，在我看来不是共享池，不是 baseline，也不是 heartbeat，而是它公开放弃了“团队知识最终应该收敛成一份权威版本”这个假设。

过去我们处理知识冲突，第一反应通常是合并。两个人对同一个指标有两种说法，那就拉会对齐，定一套标准，然后写进文档。这个逻辑在很多场景都成立，尤其是财务、合规、监管这种必须统一的东西。

但放到 skill 这类 AI 资产上，问题就出来了。因为 skill 的价值恰恰来自个人判断。一个分析师怎么理解某张表，另一个工程师怎么定义一个故障路径，第三个人怎么做代码审查，这些东西很多时候不是“谁对谁错”，而是带任务语境的工作偏好。你把它们过早磨平，最后沉淀下来的往往只剩 consensus，而 consensus 恰恰是 AI 最不缺的东西。

所以文章里那个“共享池负责存，个人 INDEX 决定加载”的设计，我觉得很对。它不是简单地把个人知识拿出来共享，而是第一次把“共享”和“统一”拆开了。

冲突在这里不再只是问题，而是系统信号

我越来越觉得，AI 时代很多过去要被消灭的东西，现在反而应该被保存下来。

重复是一种信号。五个人都写了差不多的 skill，说明这件事已经接近团队共识了。分叉也是一种信号。同一个对象有三种不同写法，说明这里要么存在真实的任务差异，要么还没有形成稳定共识。以前这些东西会被知识库管理员当成脏数据，现在反而可以成为治理输入。

这也是为什么我会觉得 heartbeat 这个思路很重要。它不是替人做裁判，而是先替团队做观察员：哪里高度重合，哪里明显分叉，哪些 skill 被频繁引用，哪些 baseline 已经过时。AI 第一次不只是知识使用者，也开始变成知识系统的维护者了。

AI 没有降低知识维护成本，只是改写了成本结构

很多人会直觉觉得，AI 这么强了，知识维护应该更轻了。我的判断正好相反：它没有让维护变轻，只是让维护的重点换了地方。

传统 wiki 的核心成本在写和更新。谁来写，谁愿意持续更新，谁来处理冲突。这是典型的人工编辑成本。

到了 AI 这里，新增的反而是运行成本和治理成本。你要考虑的事情会变成：哪些上下文默认加载，版本怎么定位和回滚，被引用的 skill 改了以后会影响谁，哪些记忆该保留多久，改完之后怎样证明 Agent 行为更好了而不是更飘了。

这也是为什么现在很多厂商开始把 prompt sharing、multi-agent orchestration、memory service 这些能力做成产品层。Google 已经把保存与共享 prompt做成显式能力。微软在讲multi-agent patterns时，已经不是在讲聊天体验，而是在讲任务委派和结构化协作。AWS 甚至把memory configuration直接做成了参数。

这背后其实在说明同一件事：团队真正要维护的，不再是一堆静态资料，而是一套可执行的上下文系统。

公司级 Context Infra，应该先建什么

如果站在公司层面，我会把这件事拆成五层。

最上面是组织硬规则。安全、合规、品牌、权限边界，这些必须统一，不能交给每个人各写各的。

第二层是 baseline。也就是团队推荐默认集。新人不需要从零开始，老手也不必被它绑死。它像一个比较合理的起点，不是唯一正确答案。

第三层是 personal overlay。真正值钱的 knowhow 很多都在这里。一个团队如果只剩 baseline，没有个人扩展，最后只会沉淀出一种“正确但没味道”的平均版本。

第四层是 activation。也就是在什么任务下加载什么，哪层覆盖哪层，什么是默认启用，什么只是候选能力。没有这一层，所有 skills 再多也只是一个仓库，不是 infra。

最后一层是 evaluation。哪条规则改了之后真的更好，哪些失败样本应该沉淀为新 skill，哪些 baseline 应该晋升，哪些要回滚。没有评测闭环，所有升级最后都会退化成感觉。

公司级 Context Infra 的重点，不是先做一个更大的知识中心。
而是先做一套允许分叉、能自动观察、能逐步晋升共识的上下文编排系统。

为什么很多老问题会在 AI 面前重新长出来

你如果回头看，会发现很多问题其实并不新。知识冲突、定义漂移、维护成本、标准与灵活性的拉扯，这些过去在 wiki、语义层、规范库里都出现过。

真正变化的地方在于，这些问题第一次直接进入执行层了。过去文档冲突，影响的是人理解得慢一点；现在 skill 冲突，影响的是 Agent 当场走偏。过去知识库过期，顶多是查的人多问一句；现在上下文过期，可能直接塑造出错误行为。

所以 AI 不是把这些老问题消灭了，而是把它们推到了一个更靠近产出的地方。你不能再用“反正人会二次判断”来兜底了。

最后我更关心的，不是文章写得对不对，而是它指向了什么

鸭哥那篇文章当然还不是一套完整的方法论。它没有把 evaluation 层完全展开，也没有细讲公司级 policy、权限和回滚。但它已经很明确地指向了一个方向：团队共享 Skills 这件事，不能再按传统知识库的方法来管了。

我觉得这件事最值得讨论的，不是“这个目录怎么搭”，而是它背后的那个转向：从管理信息，转向管理上下文；从统一文档，转向分层编排；从人工维护，转向 AI 参与维护。

这也是我现在对公司级 Context Infra 最核心的判断。它不会再长成一个新的 wiki。它更像一个组织级的控制平面。真正要维护的，不是一份大文档，而是一套会在运行时不断塑造 Agent 行为的系统。

如果这个判断成立，那很多事情就顺了。为什么 skill 可以允许重复，为什么 baseline 不能太重，为什么 heartbeat 比大编辑部更有前途，为什么 eval 比内容运营更重要。

因为在 AI 时代，知识库不再只是“告诉你答案是什么”，而是“提前影响系统会怎么做”。

它当然不准确。按目前公开信息，更准确的说法应该是：SpaceX 和 Cursor 达成了深度合作，同时拿到了今年稍后以 600 亿美元 收购 Cursor 的权利。这里面有合作，有 option，有后续空间，但还不是一个已经完成并表的既成事实。

可问题就在这里。为什么一个并不准确的说法，会传播得这么快，而且很多人第一眼看过去还觉得“很合理”？

我觉得原因不只是大家没看原文，而是这个错法，刚好说出了这件事真正重要的那一层。

错的不是方向，错的是时间点

过去一年，大家讨论 AI 编程工具，很多时候还停留在产品层。谁更像 IDE，谁补全更强，谁 Agent 更聪明，谁能替你多写几段代码。可这次 Cursor 被放进交易语言里之后，事情突然变味了。市场不再只是把它看成一个工具，而是在把它看成一个入口，一个控制点，一个值得被大型体系直接拿下的战略资产。

这才是重点。

如果 Cursor 只是个好用一点的编辑器，这笔交易根本不会成立。600 亿美元 这个数字，放在普通 SaaS 语境里太夸张了。可一旦你换个角度，把 Cursor 看成开发者入口，看成高价值编码流量入口，看成未来知识工作 agent 的一个分发位，这个价格虽然依然激进，但至少不再荒唐。

说白了，市场现在给 Cursor 定价，已经不只是按“它今天帮多少人写代码”来算，而是在按“它未来能卡住哪一段价值链”来算。

为什么大家会自动把它听成“已经买下了”

这里面有一个很典型的传播学现象。法律语言喜欢留空间，社交语言喜欢去掉空间。官方说的是 the right to acquire，社交平台最后传成的就是 acquired。前者是条款，后者是故事。绝大多数人转发的从来都不是条款，而是故事。

更关键的是，这个故事太顺了。Cursor 过去一年估值一路狂飙，收入也在飞。SpaceX 和 xAI 刚完成更大的资本重组，市场又早就习惯了 Musk 用更大的叙事把不同业务串起来。在这种背景下，大家天然会觉得：这件事不是会不会，而是早晚的问题。

所以很多人把“有收购权”讲成“已收购”，虽然事实层不对，但产业直觉上又不算完全离谱。因为这句话提前说出了市场真正已经意识到的那件事：Cursor 这种 AI coding 平台，正在被重新定价成基础设施级资产。

真正的变化，不是工具更强了，而是入口更值钱了

对 OpenAI、Anthropic、GitHub 这些玩家来说，真正麻烦的从来不是“多了一个好产品”，而是某个产品开始往平台级资产升级。一个工具再强，威胁都有限。可一旦这个工具同时连接了开发者工作流、模型调用、算力需求和企业落地，它就不只是工具了，而是未来软件生产系统里的一段主干道。

谁控制主干道，谁就比单纯卖铲子的人更值钱。

这也是为什么我觉得这件事值得看，但看的不是八卦，而是方向。AI coding 这条赛道，正在从应用竞争切到基础设施竞争。真正的战争，不再只是模型能力谁更强，而是谁控制算力，谁控制开发者入口，谁控制高价值任务流经哪条系统。

如果这个判断成立，那未来最值钱的公司，不一定是最会生成代码的公司，而是最会卡住工作流入口的公司。

比“买没买成”更值得盯住的事

我反而觉得，这比“SpaceX 到底买没买成 Cursor”更值得盯。

新闻层，当然要把话说准。可产业层，很多时候市场先用错话把趋势喊出来，然后事实才慢慢补上来。

Cursor 这件事，可能就是这样。

但如果你顺着它们 2025 到 2026 的产品线往下看，会看到一个更收敛的现实：所有 Labs 都在把 AI 从“信息获取工具”推向“高价值任务执行层”。

这不是措辞变化，而是产品、定价和收入结构一起变了。OpenAI 从 Operator 到 Deep Research 再到 ChatGPT agent，路径非常连续。Anthropic 则从 Claude 一个聊天框，拆成了 Claude Code、Cowork、Claude for Work 这种按任务类型和组织边界划分的系统。Google 也一样，一边继续做搜索和广告，一边把 Workspace agents、Gemini Code Assist 和 Gemini 3 的 agentic workflow推成新的企业执行层。

不是回答问题，而是把事做完

我越来越觉得，理解这一轮变化最好的分界线，不是“模型更强了”，也不是“多模态更完整了”，而是一个很朴素的问题：

AI 的价值单位，到底是“给你一个答案”，还是“替你完成一个结果”？

这两者差别非常大。

“给答案”更像流量生意。你问，我答，答完就结束。用户可以今天问你，明天问别人。切换成本低，护城河也低。搜索、广告、信息入口，基本都属于这一层。

“做结果”则完全不同。它意味着 AI 需要接进真实工作流，拿到上下文，调用工具，穿过多个步骤，最后生成一个企业愿意承认的结果物。可能是一份投资备忘录，一份 amortization schedule，一次 legal notice 的分流，一段能合并进主干的代码，一套更新过真实数据的表格，或者一份能直接拿去汇报的演示文稿。

OpenAI 在 ChatGPT agent 里已经把这个方向说得很明白了：它评估的不是泛泛任务，而是 economically valuable knowledge-work tasks。Anthropic 更直接，在融资公告里写自己领先的是 economically valuable knowledge work tasks in finance, legal, and other domains。Google 也不是在卖“更会聊天的 Gemini”，而是在卖能处理 end-to-end business processes 的 Workspace agents。

这就是为什么我说，它们真正抢的不是流量，而是工资池。因为一旦 AI 的价值单位从“答案”变成“结果”，它面对的就不再是广告预算，而是企业里那些本来发给分析师、程序员、法务、研究员、运营经理的工资预算。

为什么最先被盯上的，是 Coding、金融、法律和分析

很多人看到“高价值任务”这四个字，会误以为指的是最有创造力、最不可替代的工作。其实不是。Labs 现在最先盯上的，是另一类任务：单价高、知识密度高、工作流长，但又足够结构化、可验证、可拆解的任务。

Coding 是最典型的第一战场。它的好处太多了：结果可验证，ROI 容易算，企业愿意付费，产品也容易做成 seat + usage + governance。Anthropic 在 2026 年把 Claude Code 做成收入主力，不是偶然。Google 把 Gemini Code Assist 明确写成覆盖整个 SDLC，也不是偶然。OpenAI 把 coding task 直接放进 enterprise agent 里，更不是偶然。因为代码是今天最容易被 agent 化、也最容易被财务负责人接受的高价值任务。

金融、法律、数据分析则是第二战场。不是因为这些行业最容易被完全替代，而是因为它们内部有大量“高工资、重文档、重规则、可复核”的任务。OpenAI 拿 amortization schedule、competitive analysis 举例，Anthropic 反复强调 finance 和 legal，Google 拿 legal notices 和 business workflow 举例，本质上都在说明同一件事：这些任务最适合先被 AI 吃掉中间的大块流程。

这也是为什么我一直不太认同“脑力工作天然安全”这种说法。真正高暴露的，从来不是“低端工作”，而是那些高学历、高工资、但又被文档、表格、规则、模板和系统流程包裹得足够严实的工作。

Anthropic 那条线，最能说明问题

如果三家里只能挑一家来代表“高价值任务战略”，我会选 Anthropic。不是因为它最强，而是因为它现在的产品边界最像“工资池争夺战”的原型。

Anthropic 的意思其实已经很明确了：Code 管工程，Cowork 管知识工作，Claude for Work 管组织级治理与数据边界。换句话说，它不是卖一个模型，而是在卖一整套“组织如何把白领工作交给 agent”的系统。

更关键的是它的衡量方式。Anthropic 现在越来越喜欢用“economically valuable knowledge work tasks”这种词来描述模型能力。我觉得这比 benchmark 分数更有现实意义。因为一家公司如果开始用“经济价值任务”来定义能力，就说明它内部真正关心的，已经不是模型漂不漂亮，而是这东西能不能进收入表、成本表和组织流程。

它 2026 年的收入增速也在强化这个判断。根据 Reuters 的公开口径，Anthropic 的 annualized revenue 已经从 2025 年底的大约 90 亿美元，冲到 2026 年 4 月的 300 亿美元级别。这个数字当然仍然属于媒体口径，不是审计口径，但它至少说明一件事：市场正在为“高价值任务执行层”这件事付真钱，而且付得很快。

Google 和 OpenAI 还没有完全放弃旧世界

说到这里，也要避免另一个误判：不是说三家都已经彻底抛弃流量逻辑了。

Google 还是那个 Google。它不会突然不要广告，也不会突然把搜索变成纯企业软件公司。OpenAI 也一样，它在 consumer、commerce、甚至广告上的试探都还在继续。只是现在更清楚了：这些都不是它们最有壁垒的主战场。

真正有壁垒的，是谁能把 AI 深深嵌进企业工作流里，深到用户不再只是“来问一次”，而是“把这项工作交给你做”。一旦进入这个层级，收费逻辑就从 CPM、点击、时长，切到了 seat、premium capability、usage-based pricing、治理、审计、集成、上下文继承、系统控制权。这才是企业软件真正能吃住客户的地方。

所以我更愿意把 Google 和 OpenAI 理解成“双轨制”：旧世界还在养现金流，新世界在抢未来的工资池和控制权。只是到 2026，这条新轨已经不再是旁支，而是越来越像主航道。

真正危险的，不是某个职业消失，而是岗位被拆薄

很多讨论喜欢问：“AI 会不会替代程序员？会不会替代分析师？会不会替代律师？”我觉得这个问法已经有点过时了。

更现实的问题是：一个岗位里最值钱、最稳定的那一层任务，会先不会被拆薄？

Anthropic 的 Economic Index 给了一个很重要的信号：当前数据还不支持“整个职业整齐消失”，但很支持“岗位内部任务被拆开，然后一部分先被 agent 接管”。而且这些被接管的任务，并不主要集中在最低门槛工作上，反而更集中在高教育门槛、高知识密度任务上。

这意味着最先受冲击的，不一定是顶层专家，也不一定是底层执行者，而很可能是中间那一大层：会写、会查、会整理、会分析、会出文档、会做表、会做标准化初判的白领岗位。它们原本是中产工资池的主体部分，也是大公司组织结构最厚的一层。

这也是为什么我觉得图片里最后那句关于中产和社会稳定性的担忧，不是空话。因为这轮变化不是在吃掉最边缘的人，而是在改写很多社会里最核心的白领中间层。如果这层人的工作被压缩得足够快，组织结构、教育回报、职业晋升路径，都会一起变。

我现在更关心的，不是谁家模型第一

调研完之后，我反而对“哪家模型更强一点”没那么感兴趣了。我更关心的是三个问题：

第一，谁最先把高价值任务做成真正的工作系统，而不是 demo。

第二，谁最先拿走企业工作流里的控制权，而不是只做一个可替换的智能插件。

第三，谁最先把白领工资池里最厚、最可结构化的那一层，吃成自己的经常性收入。

如果从这个角度看，今天所谓的“AI 竞争”，已经很难再用“聊天产品份额”来解释了。它更像一场新的劳动力再分配战争。模型只是武器，Agent 是形态，真正的战场是工作流，真正的奖品是工资池。

所以，回到那张图。它最有价值的地方，不是“猜中了谁的战略”，而是把一个正在发生但还没被很多人完全说透的变化压缩成了一句话：所有 AI labs 最后都回到了同一个战场，叫高价值任务。

而我更愿意把这句话再推进一步：高价值任务只是表面，白领工资池才是底层。谁能把任务做成结果，谁就不只是拿走一部分软件预算，而是在重写整个知识工作的分配方式。

本文的局限性

第一，Anthropic 和 OpenAI 的部分收入数字仍然主要来自媒体口径或公司自述，不是审计口径，所以更适合支持趋势判断，不适合当成精确财务事实。

第二，Google 的双轨制比另外两家更复杂，它既没有离开广告世界，也没有停下 enterprise AI，所以这篇文章更强调它的新主战场，而不是完整复盘它的全部收入结构。

第三，关于白领岗位被压缩的社会后果，目前公开证据更支持“任务重写和岗位极化”，还不足以支持简单粗暴的“大规模整齐替代”结论。后续如果更多劳动市场数据出来，这个判断还需要继续更新。

这件事很反直觉。管理者不直接写代码、不直接交付，按理说应该是最不容易被 AI 替代的那批人。但 BCG 2025 年的全球调研给出了一个令人意外的数字：43% 的管理者和领导者担心失业，比基层员工的 36% 高出 7 个百分点。

"怕失业"只是表象。我觉得真正的问题藏在更深的结构里。想了几天之后，理出了一条线：问题不是"AI 会不会替代管理者"，而是组织里"定方向"这件事的游戏规则变了——变得对所有需要"既判断方向又负责执行"的人很不利。我把这群人叫做执行层：不只是传统意义上的中层管理者，而是所有被要求同时承担方向判断和落地执行的人——总监、Team Lead、资深 IC，甚至被要求"下场"的高管。

旧协议为什么能用两千年

先说过去的模式为什么能 work。

现代组织的底层逻辑，从罗马军团到今天的互联网大厂，本质上都是同一套东西：高层定方向，中层翻译和拆解，基层执行。这套模式有一个隐含假设：定方向的人不需要亲自做执行，做执行的人不需要操心方向。

这个假设之所以成立了两千年，不只是因为"环境变化慢"。更关键的原因是，高层在"定方向"这件事上，有一整套完善的支撑体系。商业分析团队做数据，咨询公司出框架，广泛的行业人脉提供信息面，战略部门做竞对分析。这些辅助设施把方向判断的风险降到了可控范围内。

而且，过去高层定方向时，最核心的考量不是外部趋势，而是与公司内部的适配性——自己的资源储备、人力结构、组织能力能不能撑住这个方向。这种"适配性判断"才是高层定方向的核心价值。它让方向判断变成了一个收益大、风险相对可控的事：因为你是在充分了解自己底牌的基础上做决策。

还有一个隐性但重要的因素：容错机制。高层判断失败了，除非是方向性的大败仗，否则很少因此被开掉。高层的人才库本身就小，培养周期长，替换成本极高。再加上方向判断本身就有高不确定性，大部分组织默认接受这个风险。败了一次两次，高层依然在位。这其实是合理的：探索方向本身就有损耗，组织需要承担这个成本，而不是让决策者个人背负。

总结一下：旧协议能 work，是因为高层定方向时有三层保障——辅助设施降低判断风险，适配性思维锚定决策质量，容错机制消化探索成本。三层叠加，方向判断成了一个"高收益、可控风险"的游戏。

AI 打破了什么

AI 时代，这套均衡被两件事同时打破了。

第一，方向判断开始依赖执行中的体感。AI 领域的变化速度按月甚至按周计。从模型阶段到 Agent 阶段到 Harness 阶段，每个阶段爆发出大量新概念。这些概念靠看报告、听汇报判断不了好坏，你要亲手试。体感、感觉、甚至直觉，成了方向判断的核心输入。

管理学里有个概念叫 OODA Loop（观察-判断-决策-行动），Boyd 当年的核心洞察不是"速度要快"，而是谁的 Orientation（判断）更贴合现实，谁就赢。当技术变化的速度超过信息在组织层级间传递的速度时，高层拿到的信息已经过时了。定方向不能再和做执行分开——这是物理限制，不是管理偏好。

UC Berkeley 的 California Management Review 说得很直接：在 AI 时代，战略不是一个静态计划，而是一种动态能力。Mintzberg 在 1985 年就提出过"涌现战略"：真正有效的战略不是纯粹自上而下设计的，很多是从执行层涌现出来的。AI 时代让这个判断变成了现实。

第二，AI 造成了一种"执行成本幻觉"，扭曲了方向判断的逻辑。由于 AI 大幅降低了执行端的成本（或者更准确地说，在大多数高层的认知中大幅降低了执行端的成本），方向判断开始从"内部适配"滑向"外部跟随"。"别人在搞 Agent，我们也得搞"，"Shopify 的 CEO 都说了 AI-first，我们也不能落后"——这类决策的逻辑是外部跟随，而不是内部适配。

过去高层定方向时最值钱的能力——判断"我们能不能做"，而不只是"该不该做"——正在被这种"AI 反正便宜，先试了再说"的心态侵蚀。

方向判断权下移了，但三层保障没有跟

当方向判断越来越需要执行体感时，高层自然会把方向判断的权力（或者说责任）往下推。IBM 调查了 2,000 名全球 CEO，68% 说 AI 正在改变他们认为"核心"的业务。但到底怎么动，他们希望下面的人给判断。

问题是，前面说的三层保障——辅助设施、适配性思维、容错机制——一个都没有跟着下移。而承接这些方向判断责任的人——我前面定义的"执行层"——面临的是三重结构性不对称。

辅助设施没有跟。高层定方向时有商分团队、咨询公司、人脉网络做底座。执行层定方向呢？大多数时候只能靠自己。没有商分团队帮你做数据支撑，没有咨询公司帮你出框架，行业人脉也远不如高层广。让执行层用和高层同等的质量去判断方向，但不给同等的支撑体系，这本身就不公平。

风险结构变形了。方向判断一旦被下推，执行层面临的赌注是三合一的：要看准方向，要自己落地，还要为执行端到底有没有 AI 承诺的那种效率负责。看远、落地、效率，三个赌注压在同一个人身上。而且，由于高层的方向判断已经从"适配性判断"退化成了"外部趋势跟随"，传递下来的方向本身就缺乏与组织能力的匹配——但这个匹配问题，最终也是执行层来扛。

容错机制没有跟。这一点很少有人讲，但在大厂里非常真实。高层判断失败有"人才稀缺"这个隐性保护伞，小仗输了不影响位子。但在组织的认知形态里，执行层的可替代性更高。一个执行层判断错了方向，导致团队半年的投入打了水漂，结果大概率是这个人背锅，而不是"组织承受方向探索的成本"。赢了是组织的功劳，输了是自己的责任。这种不对称的容错机制，使得执行层在被要求做方向判断时，本能地瞻前顾后。不是不想定方向，是游戏规则让你不敢定。

三个不对称叠加在一起，才是执行层不愿意也不敢承接方向判断的完整解释。这不是态度问题，不是能力问题，是结构性的。

死循环和它的可见症状

三重不对称造成了一个死循环：高层等执行层给方案（因为自己缺乏执行体感），执行层等高层定方向（因为自己缺乏判断的配套和容错）。两边都在等对方先动，方向在这个互等中持续空转。

一位资深 CEO 顾问 Sengupta 的描述很精准："CEOs Believe AI Is Transforming Their Business. Their Organizations Are Living a Different Reality."——CEO 觉得组织在转型，组织活在完全不同的现实里。

这个死循环有几个可见的症状。

第一，高层开始越过执行层，直接找一线做事的人聊。因为高层需要的是执行体感，而执行层如果自己不动手试，提供不了这个信息。能给的还是老三样——进度汇报、风险预警、资源方案——对"判断方向本身对不对"没什么用。

第二，传统的中层管理岗在被系统性地压缩。Fortune 在 2026 年 4 月报道，美国管理者的平均直接下属从 2013 年至今几乎翻倍，达到了 12.1 人。Meta 的新 AI 工程部门推到了 50:1。Gartner 预测到 2026 年，20% 的组织将用 AI 消除超过 50% 的中层管理岗位。Korn Ferry 调查显示 41% 的员工已经表示公司削减了管理层级。

第三，执行层被迫"假装 AI 成功"。一项对 50 名中层管理者的访谈发现，弱就业市场下，他们 "responsible for keeping up the illusion of an ultra-successful AI roll out"——要维护 AI 转型成功的幻象，即使实际效果并不好。这正是容错不对称的直接后果：你不敢说"这条路走不通"，因为说了之后你是那个被归咎的人。

砍人不是答案，但也不是给执行层找借口

写到这里，有必要说清楚一件事：分析三重不对称，不是在说执行层没有责任。分析结构性问题的目的，是把解法指向个人如何在结构中找到位置，而不是停留在"执行层要加油"或者"该淘汰一批人"的简单归因上。

Klarna 的教训很说明问题。这家瑞典支付公司 2024 年高调宣布 AI 替代了 700 名客服，声称节省 6000 万美元。一年后，CEO 公开认错："We focused too much on efficiency and cost."客户满意度下降 22%，公司被迫重新招人。Careerminds 的调查显示，66% 实施 AI 裁员的公司已在重新招聘被裁员工。

砍人之所以诱人，是因为它回避了真正的难题。传统执行层身上确实有两种功能：信息路由（汇总报告、传达指令、追踪进度）和判断（情境化决策、冲突仲裁、在模糊地带做选择）。前者确实正在被 AI 替代，也应该被替代。但如果连后者一起砍掉，你失去的不只是效率，而是组织的判断能力。

MIT 的 Neil Thompson 提出了一个"专业度悖论"：如果 AI 自动化的是非核心部分（行政杂务），管理者有更多精力做专业判断，这是好事。但如果管理幅度膨胀到连专业核心工作都做不了，那就不是提效而是灾难。放射科医生是正面例子——2016 年 Hinton 预测 AI 五年内取代他们，结果采用 AI 后人数和薪资双双增长。技术没有消灭这个职业，而是重新定义了它。

未来需要什么样的执行层

分析到这里，结构性的不对称已经很清楚了。但我不想把文章停在"组织应该怎么改"上——因为规则的调整永远慢于个人的适应。更实际的问题是：在这个方向和执行粘合的新时代，什么样的执行层能活下来，甚至活得好？

第一，能自己建支撑体系的人。

组织的辅助设施不会为你准备好，等它准备好黄花菜都凉了。过去高层有商分团队帮他看信息、做分析，未来的执行层需要自己搭建这个能力。AI 本身就是最好的工具：行业扫描、竞对分析、方案对比，一个人加 AI 能做到过去一个商分团队的信息覆盖度。但关键不是"学会用 AI"——这话太泛了。关键是把 AI 定位为你做方向判断的基础设施，而不只是提高执行效率的工具。能用 AI 看远的人，和只会用 AI 干活的人，差距会越来越大。

第二，能在执行中迭代方向的人。

三合一压力（看方向 + 抓落地 + 扛效率）不会消失，但可以换一种方式应对。未来的执行层需要学会一种新的工作节奏：不是先定方向再执行，而是在执行中不断校准方向。用两周到一个月的周期做小范围的方向试探，快速验证，快速调整。方向不是一个"决定"，而是一个"持续迭代的过程"。能接受这种节奏的人——不追求一步到位，而是追求每一步都在逼近正确——会比等待完美方案的人走得更远。这也是 Mintzberg 的"涌现战略"在个体层面的实践：让方向从你自己的执行中长出来，而不是等它从上面传下来。

第三，能主动争取容错空间的人。

容错机制不会从天上掉下来。未来的执行层需要主动做一件事：把方向探索的成本显性化。不是默默尝试然后祈祷成功，而是在尝试之前就和组织达成共识——这是一次方向试探，有失败的可能，失败的成本是 X，我们接受这个成本。能把"赌"变成"实验"的人，才有空间做真正的方向判断。那些不敢暴露不确定性、只会报喜不报忧的人，反而会在信息不对称中越陷越深。

焦虑背后的真正问题

想清楚这一圈后，回头看"管理层焦虑"这件事，可以描述得更精确了。

焦虑的本质不是"怕被 AI 替代"，甚至不是"怕跟不上"。它是一种角色模糊感：旧的分工协议失效了，新的还没有建立起来。你被要求同时做方向判断和执行落地，但既没有得到做方向判断的配套支撑，也没有得到判断失败后的容错保障。

这种感觉不分层级。高层焦虑是因为知道要动但定不了方向（缺乏执行体感，又不愿意承认自己需要下场）。执行层焦虑是因为方向判断的责任压下来了，但保障没有（赢了是组织的功劳，输了是自己的锅）。基层焦虑是因为听到的都是"AI 会替代你的工作"，但没人解释替代之后自己的角色是什么。

Fortune 那篇文章问了一个终极问题：

"Whether that is a transition cost or the new permanent condition of leadership in America is the defining workplace question of this decade."

我觉得答案取决于你怎么看自己的角色。如果你还在等组织给你一个清晰的方向和完善的保障体系，那焦虑只会越来越深——因为旧规则已经失效了，新规则也不会从天上掉下来。但如果你接受"方向和执行粘在一起"这个新现实，开始自己建支撑、自己跑迭代、自己争取容错空间，那你就不是在等规则被重写，而是在用自己的方式定义新规则。

未来需要的执行层，不是更能吃苦的人，不是更听话的人，也不是更擅长向上汇报的人。而是那些能在模糊中找到方向、在执行中校准判断、在不确定性中为自己争取试错空间的人。说到底，方向和执行的耦合不是一个需要被"解决"的问题，它是新时代的基本条件。能把这个条件变成自己优势的人，焦虑会自然消解——不是因为规则变公平了，而是因为你不再需要等别人来定规则。

我也不确定我已经变成了这样的人。但至少我在做三件事：自己下场，带着体感去定方向；用"小仗"的节奏做方向试探，让方向从执行中涌现；把不确定性摆在台面上，而不是藏起来。这不是标准答案，但至少是诚实的尝试。

有意思的地方在于：这不代表 AI 变差了。恰恰相反，很多模型现在写得比以前顺太多了。结构更稳，句子更圆，解释更全，错别字更少。问题也恰恰出在这里。它越来越像一个训练得很好的优等生，努力完整，努力礼貌，努力不犯错。最后读者闻到的，不是机器味，而是一种很强的平均值感。

AI 味不是因为它太笨，而是因为它太擅长产出“标准答案”。

很多人会把这个问题讲得很轻，好像只是删几个“首先”“其次”“综上所述”，或者少打几个破折号就行了。我不太认同。那些东西顶多算皮，不是骨头。真正的问题是：模型写出来的东西，越来越像先搭好模板，再往里填内容，而不是从一个具体判断长出来。

为什么它会越来越像“标准答案”

这件事如果拆开看，其实完全不神秘。

第一层是 next-token prediction。模型天然偏向高概率延续，而不是低概率但更有个性的表达。它最容易写出的，不是“这句话只像你会这么说”，而是“多数情况下都不会错的说法”。

第二层是 instruction tuning 和对齐训练。无论是 InstructGPT，还是 Anthropic 的 Constitutional AI，它们都在把模型往“更可用、更合作、更安全”方向推。这当然很有价值，但副作用也很明显：语气会更稳，更礼貌，也更容易变成一种统一人格。

第三层则更现实。我们自己给 AI 的 prompt，本身就在持续强化这种统一人格。你让它“结构清晰、逻辑完整、分 3 点展开、最后总结一下”，它当然会越来越像一个汇报生成器。模型没有故意油腻，是我们平时的使用方式反复奖励这种油腻。

所以 AI 味不是一个点的问题，而是三层叠加：

1. 高概率平均表达
2. 对齐训练塑造出来的稳态语气
3. 提示词自己带进去的模板收敛

三层一叠，最后就不是“像人”，而是“像一个被训练得太成功的优等生”。

人为什么会一眼闻出来

我现在越来越觉得，大家识别 AI 味，往往不是靠某个词，而是靠一组感觉同时出现。

第一，结构先于判断。读者会很快感觉到：这篇东西不是从一个观点长出来的，而是先有框架，再填观点。第二，解释欲过强。每个概念都解释了，每个转折都照顾到了，但信息越来越多，判断反而越来越薄。第三，对风险的回避过于一致。它总想两边都照顾，总想讲全面，于是读完之后你知道“它很稳”，但不知道“它到底站哪边”。

这也是为什么我现在会把 AI 味理解成一种更本质的东西：

AI 味，本质上是认知摩擦被过早抹平之后留下的平滑表面。

真正有力量的文字，很多时候不是一次就写顺的。它往往要经过卡住、删掉、重排、推翻原框架这些过程。可 AI 太擅长给你一个“已经看起来可以交”的版本了。危险也在这里。它不是写得差，而是太容易让你误以为自己已经想清楚了。

为什么有些人特别讨厌这种味道

我觉得这背后不是单纯审美差异，而是任务差异。

如果你写的是 FAQ、说明书、会议纪要、基础汇总，这种风格其实挺好用。它稳定、省事、不容易翻车。但如果你写的是判断、汇报、说服、战略表达，这套风格就会出问题。因为这些场景真正需要的，不是完整，而是压缩后的判断。你得敢于删，敢于押注，敢于让文字带着一点“这就是我的看法”的成本感。

这也是为什么我越来越反感“技术分享会式”写作。不是因为它技术不对，而是因为它太像信息同步，不像认知对齐。它把事情讲清了，却没有把判断讲出来。

真正的去味，不是删词，是改控制面

很多人对抗 AI 味的方法，像在做词汇打地鼠。删掉几个“此外”，删掉几个“总之”，不让它打破折号。这些当然有帮助，但治标不治本。因为问题不是某个词，而是任务对象本身。

如果你给模型的目标还是“写一篇完整文章”，它就会自动回到那条高概率平均值路径。你删了几处口头禅，它下一段还是会走回熟悉骨架。

真正有效的改法，我现在更相信有四条。

第一，先让模型站住判断，不是先展开结构

不要先问“怎么写完整”，先问“这篇东西最核心的一句判断是什么”。一旦没有这句判断，后面所有展开都会默认长成模板。

第二，同时给正向风格约束和反向禁令

只说“写自然一点”没用。更有效的是明确写：要具体、要有场景、要有取舍；不要每段都总结，不要平均用力，不要像主持分享会。

第三，把人工编辑动作当成高价值偏好数据

这点我体感最深。真正让 AI 变得更像你，不是你补了多少抽象形容词，而是你到底改了哪里。你删掉什么，保留什么，重排什么，这些动作本身就是最值钱的 taste signal。

所以我现在越来越相信：真正有竞争力的写作系统，不是第一次就写得最顺的系统，而是最会从“你删掉了什么”里持续学会 taste 的系统。

第四，在生成端就先控重复和模板化

OpenAI 官方文档里对 frequency_penalty 和 presence_penalty 的说明很朴素，但很有价值。它提醒我们：有些味道不该完全留到后处理，而应该在生成阶段就先压住。否则你拿到的已经是一副成型骨架，后面只能修边角。

最后的判断

如果非要把这件事压缩成一句话，我现在的判断是：

AI 味不等于机器感，它等于被奖励函数抹平之后的平均值感。

所以最好的去味方法，不是逼模型“更像人类”，而是让它少回到平均值，多暴露判断，多保留删改痕迹，多接受来自真实工作流的偏好校准。

真正有复利的，也不会是一次次手工修文，而是把这件事本身做成控制面：任务怎么定义，候选怎么分化，编辑痕迹怎么沉淀，下一轮怎么回灌。这样你对抗的就不只是这一篇文章的 AI 味，而是在给系统慢慢长出自己的 taste。

它表面上只是一个很普通的自动化问题：把 Plaud 录音拉到电脑，传到腾讯会议转写，再把文字稿接进后续总结和蒸馏链路。真拆开看，也就四步。

1. 下载录音
2. 上传转写
3. 取回文字稿
4. 进入总结和蒸馏

但就是这四步，我前前后后折腾了快一年，尝试次数不下 10 次，直到这周才真正跑顺。

所以这篇文章我真正想讲的，不是“我又做了个自动化”。而是另一件事：很多工作流之所以一直卡着，不是因为其中某一步不会写，而是因为你看问题的方式还没变。

这条链路为什么一直值得折腾

去年六七月，受鸭哥“赛博人生计划”的启发，我开始系统采集自己的日常信息。那时候“蒸馏”这个词还没像今天这么流行，但我已经在想一件事：能不能把每天真实发生的会议、对话、决策、卡点，持续沉淀成一个可用的 context 系统。

所以我买了 Plaud。因为平时会很多，我每天录音时长大多在 12 小时以上。

真正的难点从来都不在采集，而在后处理。每天十几个小时的录音，如果不能稳定转成文字、再稳定进入后续总结，它就只是另一种形式的“数据囤积”。

腾讯会议在这里很关键。它提供了一个相对稳定、而且几乎免费的转写入口。否则按我这个体量，真去按 API 成本硬算，根本不现实。

所以，这件事对我来说从一开始就不是一个可有可无的小优化，而是一条必须跑通的基础设施。

我经历了三个阶段

第一阶段：每天手工搞 1 小时

刚开始做这件事时，其实还挺兴奋。每天专门拿出 1 个小时，手工从 Plaud 下载录音，再上传到腾讯会议，等转写，最后把文字稿扔给 Gemini 做当日总结。

那个阶段只有 Gemini 顶得住。因为这么大体量的文字稿，别的模型上下文窗口都不太行。

那时候我的感觉是：虽然笨，但至少已经跑起来了。

第二阶段：改成每周集中处理，摩擦反而更大

后来我把节奏改成每周五集中处理一次。表面看像是优化，实际上摩擦更大了。

原因很简单。每天 12 小时大约会有 3 个文件，7 天就是 21 个文件。下载、上传、等待、盯状态，全都被批量放大。这个时候你会发现，批量处理带来的不是效率，而是更强的中断感。

我那时候试过浏览器 MCP，也试过 AI 浏览器。Comet 确实算其中最好用的一个，但还是不够稳。只要某个文件要下载 20 分钟，中间一断，就得人工接回去。

于是这条链路一直没法真正收口。只是后半段的“复盘总结”开始逐渐交给 Cursor 和 Claude Code 去做了。

第三阶段：这次终于做到接近 0 摩擦

这次真正完成的，不是某个脚本终于写对了，而是整条链路第一次作为系统跑通了。

Plaud 自动下载，自动保存，自动上传，等待转录，自动下载文字稿，自动总结，然后进入蒸馏序列。全程几乎不需要我介入。

做到这一步以后，我回头看才发现，真正关键的不是代码量，也不是自动化步骤数，而是背后有几件事情终于同时成熟了。

最后让我过关的，是四个变化

第一，基础设施终于到位了

如果没有一台 24 小时在线、登录态稳定、任务能持续跑的 Mac mini，这件事其实很难真正落地。很多自动化任务早期做不成，不是逻辑不对，而是运行环境一直停留在 demo 条件里。

我后来越来越觉得，所谓“把工作流做成系统”，第一步往往不是去补逻辑，而是先把基础设施补齐。机器常驻、状态持久、任务不断线，这些听起来都不是主角，但它们决定了你最后拿到的是脚本，还是基础设施。

第二，工具终于变得更适合被 AI 调用了

过去一年里，工具层本身也成熟了很多。无论是 Playwright，还是 Chrome 系列工具，对登录态保存、页面交互、长链路等待的支持，都比之前稳了不少。

很多人会把“过去没做成”解释成“自己不会做”。但不少时候，真相只是那一层工具能力当时还没成熟。时机没到，硬上只会把自己折腾得更烦。

第三，我开始从“工程解”转向“AI 解”

这是对我影响最大的一点。

我以前处理这种自动化问题，默认都是先按工程思路拆。脚本怎么写，状态怎么管，流程怎么控，异常怎么兜。这个思路当然没错，但它会天然把 AI 放在一个“辅助工具”的位置。

后来受到鸭哥一些实践和我自己在 OpenCode client 上尝试的影响，我开始换一个问题来想：

这个系统的核心控制面，到底应该是脚本，还是 Agent？

这个问题一变，设计空间就完全变了。后面我直接选了 OpenCode server 这条路，很多原来卡住的地方，一下就顺了。

所以我现在对这件事的判断很明确：AI+工程，和 工程+AI，真不是一回事。 顺序一换，系统中心就换了。

第四，我对 skill 的理解也变了

这次 workflow 跑通时，我顺手也在测试对应的 skill。中间当然还是有卡点。按我以前的习惯，我会立刻去问：“要不要针对这些卡点再补几条更强的约束？”

但这次我反而更确信另一件事：skill 的核心不是把 SOP 写满，而是围绕目标给 Agent 足够好的自由度和边界。

你如果每遇到一个局部问题，就往 skill 里加一条规则、补一个分支、再叠一层限制，短期看像是在修复，长期看其实是在把能力写死。最后 skill 会越来越重，越来越像流程图，而不是能力。

这次的结果说明，目标型的 skill 已经够用了。真正重要的是目标清楚、边界清楚，不是 SOP 无限加厚。

这件事真正重要的，不只是省掉 1 小时

如果只从“省时间”角度看，这条工作流的意义其实没那么大。真正重要的是，我重新确认了一件事：每日信息不能按周整理。

因为 context 是有时效性的。你这周真正在关注什么，卡在哪里，外部环境给了什么反馈，这些信号都在实时变化。隔一周再回头整理，归档也许还行，但蒸馏质量一定会掉。

所以我现在越来越相信，context infra 这套东西，不只是个人知识管理的问题。放到企业里也是一样。一个人的 context，不该只来自他和 AI 的 session 日志，还应该尽量贴近他的真实运行态。企业里的 context 构建，也不能只停留在文档层、汇报层、流程层，而应该更接近运行现场。

这也是为什么，这次工作流真的跑顺以后，我的第一感受不是“终于省了 1 小时”，而是“终于把一条真实世界里的 context 采集链路做成了基础设施”。

最后的判断

回头看，这件事能在这周真正落地，不是因为某一个脚本突然变神了，也不是因为某一个工具突然无所不能。它更像几个条件终于同时汇合了：

• 基础设施成熟了
• 工具能力成熟了
• 我自己的认知也变了
• 社区里已经有人把一些方向先跑出来了

这些条件少一个，可能都到不了今天这一步。

所以如果你手上也有一条反复折腾、总觉得“明明不复杂，怎么就是跑不顺”的工作流，我现在的建议不是立刻再补一个脚本，而是先问一句：

你缺的，到底是代码，还是基础设施；是工具，还是认知；是一个自动化步骤，还是整个系统的控制面。

很多问题，一旦问对了，答案会比你想象中来得快很多。

LaunchDarkly 也很容易被放进这个篮子里。它有 AI Configs，能管 prompt、model、tool、experiment、guarded rollout、observability，甚至开始讲 agent。乍一看，确实很像在做 AI 的基础设施。

但我把它的官方文档、SDK 边界和竞品都过了一遍以后，判断反而更清楚了：LaunchDarkly 真正在卖的，不是 AI infra，而是 AI control plane。

这个区别不是抠字眼。因为一旦分类错了，你对产品的期待就会彻底跑偏。你如果把它当成 model serving、AI gateway、agent runtime 去看，一定会觉得它“不够全”。但如果你把它当成一层专门管线上 AI 行为变更、分流、回滚、实验和治理的控制平面，它反而是很完整的一条产品线。

它不跑模型，这件事决定了它不属于底层 infra

判断一个产品是不是“真 AI infra”，最简单的方法不是看 marketing page，而是看它到底接不接 provider、代不代发请求、托不托管执行。

LaunchDarkly 在这件事上说得异常清楚。在官方文档 AI Configs quickstart 里，它直接写：

“In the AI Configs product, LaunchDarkly does not handle the integration to the AI provider.”

“However, it is still your application’s responsibility to call the AI provider.”

在总览页 AI Configs 里又补了一句更狠的：

“LaunchDarkly does not proxy or independently invoke model providers.”

只要一个产品明确说自己不负责 provider invocation，不 proxy model provider，你就很难再把它主标成模型基础设施。它不在跑车，它在管车道。

那它到底在卖什么

如果把 LaunchDarkly 的 AI 能力拆开看，它其实非常像把 feature flagging 时代最成熟的那套方法论，整体平移到了 AI 系统里。

它卖的是四件事。

第一，运行时配置。 你的 prompt、instructions、model config、tool schema 不再写死在代码里，而是变成一个可以按用户、按环境、按规则实时求值的对象。官方文档的说法是：“control how your application uses large language models”。

第二，发布控制。 新 prompt 能不能灰度。新 model 能不能先放 5% 用户。效果差了能不能秒回滚。有没有审批链和审计线索。这个思路本质上就是 feature rollout 的 AI 版本。

第三，实验与比较。 它不是只让你“改”，还让你“比”。不同 variation 的 token、时延、效果、judge 分数能不能一起看，这决定了你是在拍脑袋调 prompt，还是在做真正的生产实验。

第四，观测与治理。 AI 系统最怕的不是第一次跑不起来，而是上线以后慢慢漂。LaunchDarkly 的价值恰恰在这里。它想把 model behavior 放进一个可观测、可干预、可回退的闭环里。

所以我会把它翻译成一句更接地气的话：LaunchDarkly 不在造 AI 的发动机，它在造 AI 上路之后的方向盘、刹车、仪表盘和变道系统。

为什么这个位置反而可能很值钱

很多 AI 团队早期最关注的，都是“怎么把能力做出来”。接哪个模型，怎么调 prompt，怎么接工具，怎么把 demo 跑通。这当然重要，但一旦系统进入线上，真正麻烦的问题马上会变成另一组：

• 新 prompt 上线后效果变差了，怎么快速止损。
• 换模型后成本降了，但满意度掉了，怎么做分流比较。
• 某类用户应该走哪个 variation，谁来决定，怎么审计。
• judge、metric、rollout、approval 怎么绑成一个闭环。

这时候你会发现，AI 系统里最贵的部分，不一定是模型本身，而是变更管理。模型调用只是入口，真正容易出事故的是变更失控。

从这个角度看，LaunchDarkly 占的位置其实很聪明。它不是去和 OpenAI、Anthropic、Portkey、LangSmith 在同一个层面正面硬碰，而是抓住了一个很多团队都迟早会遇到的问题：AI 已经上线之后，谁来管它。

它也不是万能解

把 LaunchDarkly 看清楚以后，它的不足也就跟着清楚了。

如果你现在还处在“连 provider routing、prompt registry、trace、eval 都没搭起来”的阶段，那它不是你的第一优先级。因为它解决的不是“从零到一”，而是“从一到稳”。

如果你要的是完整 agent runtime，它也给不了。LaunchDarkly 在自己的 guide 里明确写过：配置它来管，orchestration 还是你的代码或 LangGraph 之类框架来管。这说明它想占的是 control plane，不是 runtime plane。

而且它还会带来另一个现实问题：你愿不愿意为这层控制面付费。对很多公司来说，这类平台最难证明价值的地方在于，它不直接“生成结果”，而是在防事故、防漂移、防变更失控。短期 ROI 不一定显眼，长期却可能越来越贵。

这也是为什么 LaunchDarkly 很容易在组织里碰到一种典型争论：业务会觉得“这不就是配置管理吗”，工程会觉得“这不就是 feature flag 延伸吗”，但真正把 AI 功能往线上推过几轮的人，往往会更容易理解它在卖什么。因为他们已经被 prompt 回滚、模型切换、线上漂移和实验不可追责这些问题打过脸了。

对企业团队来说，真正该问的问题

所以看 LaunchDarkly，不该先问“它算不算 AI infra”，而该先问三个更实际的问题。

第一，我们现在缺的是能力层，还是控制层。 如果能力层还没搭好，先别急着上控制平面。反过来，如果能力层已经差不多了，控制层迟早会变成瓶颈。

第二，我们的 AI 系统有没有进入需要治理的阶段。 只有当 variation、环境、审批、实验、回滚、观测这些问题同时出现时，LaunchDarkly 的价值才会真正显形。

第三，我们是否接受“AI 生产系统里，控制权本身就是产品”。 很多团队直到今天还会下意识觉得，真正值钱的是模型，控制只是配套。但我越来越觉得，AI 时代真正容易被低估的，恰恰就是控制面。

因为模型能力会越来越商品化，接口也会越来越标准化。真正长期稀缺的，不一定是“谁能调到最强模型”，而是“谁能让模型在真实业务里稳定、可控、可回退地运转”。

最后的判断

如果只让我给 LaunchDarkly 的 AI offering 贴一个标签，我不会选 AI infrastructure，也不会选 AI observability 或 AI experimentation。这些都太窄，或者太大。

我会选：AI control plane。

更完整一点，是：runtime AI control plane for production AI behavior。

它真正厉害的地方，不是替你把 AI 做出来，而是替你把 AI 上线后的失控风险，收回到一个可管理的系统里。

所以，LaunchDarkly 真正在卖的，不是 AI infra。它卖的是另一种在 AI 时代会越来越贵的东西：对生产行为的控制权。

但真正用起来以后，问题也会很快暴露出来。只要提问稍微开放一点，比如“昨天的业务指标怎么样”“为什么这个漏斗掉了”“哪个渠道是主要拖累”，原来那套把报表结果透出去的方案就开始卡壳。它不是完全不能用，而是只能回答那些已经被事先组织好的问题。说得更直白一点：它能帮你取数，不能帮你判断。

我这次做完调研后，一个判断越来越明确：AI 不是来替你查报表的，它是在逼企业数据平台重写自己。

真正断裂的，不在接入层，在语义层

很多团队一开始把重点放在接入层，这很正常。先做 MCP，先把 dashboard、report、card 暴露出来，先让 Agent 能调起来，看起来是最顺手的路径。但问题在于，这种做法默认继承了旧 BI 时代的对象模型。它开放的是页面、图卡、筛选器和结果集，这些东西本来就是给人看的，不是给 Agent 做判断的。

人看报表的时候，会自动补上下文。你知道“昨天”默认是自然日还是交易日，知道“业务指标”通常指哪几类，知道某个口径最近刚改过，知道哪张图虽然还能看，但其实已经不该拿去汇报。可 Agent 不知道。你如果没把这些上下文显式做成机器可读的资产，它就只能在海量字段、图卡和长得很像的指标名里自己猜。

“the semantic layer is the critical component to build a bridge between AI and structured data.”

dbt 这句话我觉得非常准确。它点出了一个经常被低估的事实：AI 和结构化数据之间，缺的从来不是连接器，缺的是翻译层。Looker、Snowflake、Databricks 这几条产品线虽然路径不同，但都在强调同一件事：不要让 AI 直接面对物理表，而要让它面对受治理的业务语义。

所以如果今天还把问题理解成“我们要不要开放 MCP”，其实已经偏了。真正的问题不是开不开 MCP，而是 MCP 后面到底接什么对象。如果接的仍然是旧时代的展示对象，AI 最终只是把旧 BI 的局限，用更方便的方式重新暴露了一遍。

AI 时代的数据字典，已经不是说明书了

最近很多人重新开始讨论数据字典，我觉得方向是对的。但如果还是按传统思路去补，最后大概率只会得到一份更完整、却依然主要给人看的文档。

传统数据字典最像设备说明书。字段名、口径、来源、处理逻辑，写得越细越好。对人来说，这当然有价值。可对 Agent 来说，它天然缺一个层次：它没有直接回答“你为什么应该选这个字段，而不是那个也很像的字段”。

真正 AI-ready 的数据字典，不仅要告诉 Agent “这是什么”，还要告诉它“什么时候该用、默认怎么用、不能怎么用、谁对这个结果负责、最近有没有失效、别人通常怎么问它”。

这也是为什么现在不少 metadata 平台都在补 glossary、synonyms、quality、lineage、policy、usage history、verified queries 这些能力。它们不是在做装饰性元数据，而是在做一层机器判断的基础设施。

我觉得这里最容易被低估的，反而是那些看起来没那么“硬核”的能力。比如 synonyms、example questions、reference queries。技术团队天然更重视 lineage、schema、权限，因为这些东西工程味更重。但从 Agent 的真实使用角度看，最容易出错的恰恰是术语映射。业务说“主站赎回金额”，表里可能根本不叫这个名字；一个地方说“新增”，另一个地方说“首贷用户”；一个团队口中的“活跃”默认按天算，另一个团队默认按周算。人能靠经验补齐，Agent 补不齐。

所以我现在更愿意把 AI-ready 数据字典理解成一句话：不是字段说明书，而是企业分析语境的机器化表达。

这轮变化真正被产品化的，不是查数，而是可信答复

这次调研里，一个特别强烈的信号是：行业领先产品已经不再把“自然语言查数”当成核心卖点本身，而是在不断产品化“可信答复”。Snowflake 在做 verified queries，Power BI 在做 human-approved verified answers，ThoughtSpot 在做 analyst coaching。说法不同，但都在指向同一个现实：正确答案不是模型自己悟出来的，而是组织把自己的标准问题、标准答案、标准 SQL、标准语义，持续回灌给系统之后形成的。

这一点很重要，因为它把很多人的直觉反过来了。很多人默认觉得，只要模型越来越强，最终它总会学会这些东西。但企业数据问题不是互联网问答。互联网问答答错一次，最多体验差；企业数据问错一次，可能影响的是经营会、预算决策、风控判断，甚至组织信誉。所以在这个场景里，答得像远远不够，关键是答得可追责。

这也是为什么我越来越不认同“让 AI 自由探索数据库，然后再逐步调优”的路线。这个路径在 demo 阶段看起来很性感，因为它最像真正的智能。你随便问一句，它就能现场拼 SQL、现场出图表，感觉特别聪明。但企业里真正需要的，往往不是这种即兴表演，而是可复用、可审计、可回放、可纠错的标准化答复系统。

真正稀缺的能力，不是多答，而是知道什么时候不该答

我这次最强烈的一个感受是，很多团队在谈 AI 的时候，默认目标还是“尽量多答”。可如果站在企业数据平台的角度看，真正稀缺的能力恰恰不是多答，而是知道什么时候不该答。

以前数据平台面对的是人。人会自己做风险判断。一个资深运营看到一张图不更新，可能会先去问是不是任务挂了；一个分析师发现某个指标突然跳变，知道要先排除埋点或口径问题；一个懂业务的人看到结果离谱，天然会留个心眼。Agent 没这个体感。它没有“感觉不对”，除非你把“不对”的信号做成它能读懂的对象。

所以我越来越认为，未来企业数据平台的核心能力之一，不是智能问答，而是智能拒答。

什么情况下应该拒答？口径未认证，freshness 超过 SLA，质量告警还没消除，结果依赖涉敏字段但当前身份无权访问，语义层没有覆盖到这个问题，只能退回原始 SQL 猜测。真正成熟的平台，不会把“什么都能答”当能力，而会把“在不该答的时候及时停下来”当能力。因为后者才体现出系统已经开始拥有组织判断，而不是单纯拥有语言能力。

数据平台真正该升级的，不是前台，而是控制面

如果把这一轮变化压缩成一句更工程化的话，我会说：数据平台的重心，正在从前台产品迁移到后台控制面。

前几年大家最重视的是前台。报表好不好看，分析平台顺不顺手，自助取数方不方便，主题分析能不能拖出来。这些仍然重要，但 AI 时代的新变量在于，前台不再只有人，Agent 会变成新的主要用户之一。它不会抱怨按钮难点，但会无限放大底层语义和治理的缺陷。

于是，真正稀缺的东西开始变了。以后最值钱的，不一定是谁做出了最酷的问答入口，而是谁先做出了稳定的 Agentic Data Control Plane。这套控制面至少要统一四类对象：语义对象、元数据对象、可信对象和策略对象。只有这些东西统一起来，Agent 才可能在运行时做出像样的判断。否则它永远是在不同系统之间拼 patch。

从这个角度看，很多传统数据平台团队并不是要“转型成 AI 团队”，而是要把自己重新定义成企业判断基础设施团队。你们提供的不只是数据，而是带边界的数据判断力。

哪些东西该先做，哪些东西别急着做

如果把这件事落回现实，我反而不建议一开始追求“大而全的 AI 数据中台”。那很容易变成又一个方向正确、交付很慢、大家都知道重要、但半年后还是只能演示的工程。

更合理的路径，是从高价值主题域开始，先把少量但关键的东西做深。我会优先挑三到五个主题域，比如交易经营、用户增长、投放、风险、资金流转。每个主题域先补齐认证指标、关键实体关系、默认问法、verified queries、freshness 和 quality 信号、policy 和 owner 边界。只要这几个主题域做深了，系统就会开始出现一个很重要的质变：它不再只是到处都能查一点，而是在关键问题上开始稳定可靠。

相反，有些东西不需要太早做。比如一开始就追求通用自治分析，或者一开始就想让 Agent 直接面对全量数据仓库 schema。我觉得这些动作都太像“技术上很过瘾，组织上很危险”。数据平台一旦把风险边界开得太早，后面不是创新跑得快，而是事故来得快。

收束

我越来越觉得，很多团队今天看待 AI 调数的问题，还是太温和了。大家总觉得是在原有平台上补一层能力，给原来的报表体系加一个更自然的入口，给原来的分析平台多一个对话面板。这样理解不能说错，但它低估了这轮变化真正改写的东西。

真正被改写的，不是入口，而是责任。

以前数据平台的责任，是把数算出来，把工具搭出来，把报表发出去。以后这套责任还在，但外面会多一层更难也更值钱的责任：让机器知道什么时候能信，什么时候不能信，什么时候该继续分析，什么时候必须停下来。

一旦机器开始代替人提问，平台就不能只提供数据，它必须开始提供判断的边界。所以我对这件事最后的判断很明确：AI 不是来替你查报表的，它是在逼企业数据平台重写自己。真正要做的，不是把旧系统接给 Agent，而是把企业分析里那些原来只存在于资深分析师脑子里的语义、经验、规则和边界，全部工程化、产品化、机器化。

谁先做到这一点，谁的数据平台才真正进入了 AI 时代。

我有。不止一次。

不是因为懒。是因为维护一个活的知识库，其工作量的增速远超它带给你的价值增速。你新收集了一篇论文，要更新三个相关页面的交叉引用，检查两处可能过时的结论，顺手修一下上周忘记补的标签。这些"记账工作"不难，但累积起来，足以让任何人放弃。

2026 年 4 月初，Andrej Karpathy 在 GitHub 上发了一个 Gist，标题叫 LLM Wiki。12 小时内拿了 2100 颗 Star，X 上的帖子被围观了 1200 多万次。他没有发布任何代码，只发了一个"idea file"。

我仔细读了这份 Gist，把社区的实现和批评都翻了一遍。我的判断是：这个概念本身不新，但他找到了一个过去一直缺失的角色来填补知识管理中最致命的空缺。

LLM 不是搜索引擎，是编译器

Karpathy 的核心命题用一句话概括：Compile, don't retrieve.

传统的 RAG（检索增强生成）是这么工作的：你问一个问题，系统把你的原始文档切成碎片，用向量搜索找到最相关的几块，塞进 LLM 的上下文窗口，让它临场发挥。每次查询都是一次独立的、无状态的处理。上一次查询积累的理解，到下一次查询时完全归零。

LLM Wiki 反过来：在你"摄入"一份新资料的时候，就让 LLM 把它消化成结构化的 Markdown 页面，和已有的知识建立交叉引用，标记与旧结论的矛盾。这些页面本身就是知识资产，下次查询时 LLM 读的是编译好的 wiki，不是原始碎片。

用软件工程的类比：RAG 像解释型语言，每次运行都从源码开始解析；LLM Wiki 像编译型语言，先编译成可执行文件，运行时直接用。

架构极其简单。三层：

三个操作：Ingest（摄入新资料时编译）、Query（在编译好的 wiki 上查询）、Lint（定期健康检查，找矛盾和知识缺口）。没有向量数据库，没有 embedding，就是 Markdown 文件加一个 index.md 做全局索引。

Karpathy 说这套东西在"中等规模下效果出奇地好"。他自己的 wiki 大约 100 篇文章、40 万字。开发者 Farza 用类似方法把 2500 条日记转化成了 400 篇结构化百科，评价是"比一年前用 RAG 做的系统好用得多"。

真正的问题从来不是工具，是谁来维护

回到开头那个场景：为什么人人都建过知识库，人人都放弃了？

不是 Notion 不好用。不是 Obsidian 的双向链接不够强。问题出在一个更根本的地方：知识库的维护成本随规模指数增长，但人类投入维护的意愿随时间线性衰减。

Karpathy 引用了 1945 年 Vannevar Bush 的 Memex 概念，那是最早描述个人知识系统的愿景。80 年过去了，从 Wiki 到 Evernote 到 Notion 到 Obsidian，工具换了一代又一代，但"谁来维护"这个问题从未被解决。每次技术迭代解决的都是"如何更方便地输入"，从来没有解决"如何可持续地维护"。

LLM Wiki 的真正价值不在于"知识编译"这个概念（确实不新），而在于它给出了一个此前不存在的答案：让 LLM 当维护者。

你往 raw/ 里扔文件，LLM 自动更新 10-15 个相关页面、重建索引、标记与旧结论的冲突。你不需要操心交叉引用、不需要手动打标签、不需要检查一致性。这些"记账工作"全部交给 LLM。

你的角色从"组织者"变成了"策展者"：决定什么值得摄入，审核 LLM 编译的质量，在关键处做判断。Karpathy 自己的定义很精准：

Human responsibility: curation, direction, thinking.
LLM responsibility: everything else.

但认知摩擦被消除了，这是个问题

最有力的批评不是来自技术层面，而是来自知识管理哲学。

Niklas Luhmann 用 Zettelkasten（卡片盒）方法写了 70 本书、400 多篇论文。这个系统的核心不是卡片本身，而是写卡片的行为：你必须用自己的话重新表述一个想法，必须思考它和已有卡片的关联，必须决定它放在哪里。这些摩擦力不是低效，而是认知整合的机制。

批评者用了一个精准的类比：

Luhmann 的 Zettelkasten 是锻炼本身。Karpathy 的 Wiki 是教练的报告。

教练报告记录了你的训练数据，但肌肉是你自己练出来的。如果 LLM 替你"消化"了所有资料，你得到的是一份光滑的综合报告，但可能绕过了真正建立理解所需要的挣扎。

Hacker News 上有人说得更直接："Karpathy mistakes the words to be the goal, rather than the thinking that caused the words."

这个批评成立吗？我觉得部分成立。

关键在于你用 LLM Wiki 做什么。如果目的是深度学习一个全新领域，让 LLM 全自动编译可能确实绕过了必要的认知挣扎。但如果目的是管理你已经有判断力的领域的信息流，比如跟踪 50 个竞品的动态、维护团队的技术知识库，那么"记账工作"确实不产生认知价值，交给 LLM 完全合理。

批评者自己也给出了折中方案：让 LLM 做地图层（索引、交叉引用、缺口发现），把综合判断留给人。LLM 发现矛盾后停下来提示你，而不是自动解决。我认为这是最务实的用法。

100 页是一道坎

技术层面最硬的约束是规模。

Karpathy 的方案用 index.md 做全局索引，LLM 在查询时先读索引再定位页面。这在 100 页以内工作得很好，但超过 500 页就开始退化，1000 页以上完全不可行。本质上 index.md 是线性搜索，随页面增长 LLM 需要处理的上下文线性增加。

Karpathy 推荐用 qmd（支持 BM25 + 向量搜索）缓解这个问题。但一旦引入向量搜索，它就开始向 RAG 靠拢。社区里也有人分层索引（从 200 token 的极简摘要到 20K token 的完整内容），分四级渐进披露。这些都是有效的补丁，但也说明原始设计在规模上有硬限制。

另一个被低估的问题是幻觉的累积效应。LLM 编译的内容和原始资料混在同一个系统里，如果某次编译引入了错误推断，后续查询会引用这个错误、放大它、让它成为"事实"。Karpathy 自己承认必须配合 Git 做版本控制，但光有 Git 不够，你还需要定期人工抽查。对个人知识库来说勉强可行，对企业级应用来说是一个严肃的工程挑战。

Karpathy 真正在说什么

如果只看 LLM Wiki 本身，它是一个有明确适用范围的知识管理方案：中等规模、相对稳定的知识、有判断力的个人用户。不是万能药。

但如果把它放进 Karpathy 过去两年的轨迹里看，信号就清晰多了。

2025 年初他提出 Vibe Coding（用自然语言让 AI 写代码）。年中他自己修正说 Vibe Coding 已经过时了，新的范式叫 Agentic Engineering。年底他做了 AutoResearch，让 AI agent 自主跑实验（700 次试验/2 天）。到 2026 年 4 月，他发布 LLM Wiki，token 用途从代码操作彻底转向知识操作。

这条线的方向很明确：从人写代码，到 AI 写代码，到 AI 自主做研究，到 AI 维护知识。人的角色在整条链路上持续上移，从执行者到审核者到策展者。

他有一句话我印象很深：

我不再需要向人类解释了，我是在向智能体解释。如果智能体理解了，它们就能以无限的耐心向人类重传这些知识。

这句话的含义比 LLM Wiki 本身大得多。它在说：人类的护城河不再是知识的传递，而是核心直觉的产出。整理、编译、传递这些中间环节，全部可以交给 AI。你要做的是决定方向、做判断、产出别人无法替代的洞察。

LLM Wiki 只是这个大趋势中的一个具体实例。但它恰好击中了一个人人都有体感的痛点：知识库为什么总是烂尾。答案不是更好的工具，而是换一个不会厌倦记账的维护者。

对我自己的启发

作为一个 AI 工具的深度用户和团队管理者，我从 LLM Wiki 里提取了三个可执行的判断：

第一，知识管理应该分三层。核心知识用编译维护（LLM Wiki 的思路），长尾信息用检索（RAG），实时数据直接 API 查。不要试图用一套系统解决所有问题。

第二，Schema 设计比工具选型重要。LLM Wiki 的质量完全取决于 Schema（那个 CLAUDE.md）的设计质量。这其实就是我一直在做的事情：用 CLAUDE.md 和 AGENTS.md 定义 AI 的行为框架。知识管理的 Schema 和 Agent 的系统指令，本质上是同一件事。

第三，Markdown 是被低估的人机协议。Karpathy 选择 Markdown 不是因为它技术先进，而是因为它是人和 AI 都能读写的最小公约数。人类用 Obsidian 浏览、AI 用文件系统导航、Git 负责版本追踪，各司其职。这比任何 SaaS 的私有格式都更持久。

至于要不要自己搭一个 LLM Wiki，我会等社区的工程化成熟度再高一些。Karpathy 自己都说了，现在还是"a pile of janky scripts"。但他提出的那个核心问题，对每一个做知识工作的人都成立：

你的知识库，有没有一个不会厌倦的维护者？

这两个问题当然重要，但我越来越觉得，它们都还停留在表层。因为同样一个任务，不同系统做出来的真实成本，根本不是只差一点点。你以为你在为模型推理买单，最后真正烧掉的钱，常常是反复搬运的上下文、命不中的缓存、低价值的工具回路、以及长会话漂掉以后的人类返工。

Agent 时代真正贵的，不是 token 单价，而是低质量编排。

Claude 这次收紧第三方 Agent 框架接入，在我看来，不该只被理解成平台变得更封闭。它更像一次强行记账：把原来被订阅补贴遮住的成本，重新算回系统本身。

这次争议真正暴露的，不是价格，而是浪费

微信那篇文章里转述罗福莉的批评，我觉得最有价值的不是情绪，而是它点中了一种行业通病：一个请求里触发很多轮低价值工具调用，每轮都带着超长上下文，各种历史消息和工具结果反复回灌。这样一来，账单膨胀几乎是必然的。

如果只是单次聊天，这种浪费不一定明显。可一旦你把系统拉长到 Agent 模式，问题马上就暴露了。因为 Agent 不是一问一答，而是一整条执行链。计划、调用工具、改代码、跑测试、修失败、更新状态，任何一个环节设计粗糙，都会把后面的 token 和时间一起拖高。

这也是为什么我越来越不认同一种说法：只要模型再便宜一点，问题就解决了。不是的。便宜模型能降低一部分成本，但它解决不了系统级浪费。一个坏的编排层，挂什么模型都不会变得真正经济。

Anthropic 官方材料其实已经把答案写出来了

如果只看 Anthropic 的 pricing 文档，会发现它最值得注意的地方，根本不是单价表，而是它反复在讲 prompt caching、Batch API 和 tool use overhead。

这背后的意思很清楚：同样一个任务，成本不只是由输入输出 token 决定，还由缓存有没有命中、工具说明有没有做瘦身、动态结果有没有污染上下文决定。

更有意思的是 Anthropic 自己那篇讲 advanced tool use 的工程文章。它里面有一组数字我印象很深：通过 tool search，把工具提示从大约 72K token 压到 8.7K；通过 programmatic tool calling，把平均 token 从 43,588 降到 27,297。

这说明什么？说明真正的降本，很多时候根本不是换模型，而是把系统里不该让模型看到的东西拿掉。把动态结果留在执行层，把工具按需暴露，把稳定前缀留给缓存，这些动作听起来不性感，却直接决定了产品的单位经济。

编排层不再只是“实现细节”，它正在变成产品本身。

以后真正值钱的，不是会接模型，而是会把系统做成

OpenAI 讲 harness engineering 时有一句话很重：Humans steer. Agents execute. 我觉得它最值得咀嚼的地方，不是“人指挥、AI 执行”这么简单，而是工程工作的重心已经挪了。

以前大家拼的是谁写得更快。现在越来越像在拼谁能把环境、规则、记忆、评测和回退机制设计得更稳。长任务不是靠一段巨长 prompt 跑出来的，而是靠一整套 plan → execute → verify → repair 的 loop 才跑得稳。

也就是说，未来真正有护城河的东西，不会只是“我也能调同一个模型 API”。真正的差异化在 orchestrator 里：

• 工具是全量暴露，还是按需加载
• 上下文是无限往下滚，还是分层裁剪
• 缓存是产品里的真机制，还是 PPT 上的能力点
• 失败以后是继续烧 token 碰运气，还是有明确回退和修复路径

这些事情用户看不见，但账单看得见，完成率看得见，团队自己也迟早会感受到。

订阅和 API 的未来，不是二选一，而是分层

这次争议里还有一个被低估的信号：用户真正想要的，并不是“永远用订阅白跑自动化”，而是一个中间态。

GitHub 上有人提议，把订阅和 API 放进统一配额池里，人类交互和第三方 Agent 都从一个预算里扣，用完就 throttle。这种想法为什么反复出现？因为大家已经意识到，纯订阅和纯 API 都各有问题。

纯订阅的问题是太容易把真实成本藏起来。纯 API 的问题是成本太显性，很多人不敢放心把工作流搭上去。更合理的方向，大概率是：

• 日常人工工作流有一个 seat 或 subscription 级的保底额度
• 高频自动化和超额使用走 API 或额外 usage 包
• 不同入口共用统一预算池，防止套利，也逼系统把编排做好

所以我不觉得 Anthropic 这次动作只是“堵漏洞”。它更像是在用价格信号告诉整个生态：以后谁能活下来，不取决于谁最会讲 Agent 的故事，而取决于谁最懂得尊重算力和上下文这两种稀缺资源。

这件事对做平台的人，其实是个提醒

很多公司现在一看到模型变强，就很容易往一个方向冲：把越来越多事情交给通用 Agent，希望它自然长出平台能力。

这条路不是不能走，但我会非常警惕。因为自由度越高，意味着上下文、状态、失败路径和安全负担都会一起膨胀。最后你运营的不是一个产品，而是一个高波动的成本容器。

更稳的系统，往往不是一上来就把一切都开放给 Agent，而是先把大部分确定性 workflow 收好，把规则清楚、边界稳定、结果可验证的部分收进流水线，只把真正需要开放式推理和复杂博弈的那一层留给 frontier model。

这样做的意义不只是省钱，更是为了可预测。一个系统如果大多数时候都在可控轨道上运行，只有少数复杂情况再把智能放出来，它才更像能规模化交付的产品，而不是炫技 demo。

最后一句

我现在回头看 Claude 这次争议，脑子里留下来的已经不是“又一家平台变贵了”这种直觉，而是另一句话：

AI coding 赛道真正的分水岭，不是谁把 token 卖得更便宜，而是谁能在资源约束下，把同一个任务更稳定、更克制、更少浪费地做成。

以后真正能留下来的 Agent，不一定是 context 最长的，也不一定是最会说的，而是最懂得在该省的地方省，在该花的地方花，最后还能把任务做成的那个。

这篇文章不是调研笔记的平铺直叙版，而是我从那份调研里真正带走的判断：算力不再是背景条件，它正在反过来塑造产品哲学。

很多人现在讨论 AI 对软件行业的影响，还是下意识问一句：程序员会不会被替代？我越来越觉得，这个问题问得有点晚了。因为在真正大规模替代写代码之前，组织里的协作结构已经先开始被重写。

AI 这轮先压缩的，不是某个 title，而是研发组织里那些依赖信息差、串行流转和人工协调才能运转的中间结构。

为什么 Block 这个案例值得看

先把事实边界说清楚。Block 的大规模裁员是真的。CNBC 报道里直接写了，裁员规模是 more than 4,000 employees，大约接近公司员工总数的一半。更关键的是，这件事在官方口径里不是简单的“经济不好，降本增效”，而是明确和 AI、和更小更强的团队组织方式绑在了一起。

Block CFO 的表述很直白：公司希望“用 AI 自动化更多工作”，从而“让更小但更强的人才团队跑得更快”。这句话的分量在于，它不是旁观者的评论，而是公司高层自己给出的组织重构逻辑。

再往前走一步，Block 官方那篇《From Hierarchy to Intelligence》更彻底。它不是在说“AI 是一个提效工具”，而是在说：传统 hierarchy 里有一部分协调、对齐、传递、管理的功能，本身就应该被 intelligence layer 接走。它甚至把“no permanent middle management layer”写进了组织设想里。

这就意味着，Block 不是单纯在买更强的 coding tool，而是在尝试用 agent 改写组织的控制回路。

真正发生变化的，不是写代码，而是代码周围那圈人肉流转

过去一个软件需求为什么常常要经过很多层？并不是因为每一层都在创造新价值，而是因为现实世界里有太多断点。需求在产品和研发之间断一次，研发和测试之间断一次，CI 失败和修复之间再断一次，跨团队依赖又断一次。每一次断点，背后都要有人补上：同步状态、传递上下文、催一下进度、解释一下风险、再组织一次会。

所以很多中间层岗位的真实价值，未必是“我做了一个结果”，而是“我让结果能在断裂的系统里继续流动”。

这套东西在前 AI 时代当然成立，因为信息差真的存在，串行等待真的不可避免。但 agent 一旦能自己读 ticket、找代码、开分支、写实现、跑测试、修 CI、看日志，这条链路里大量原本必须靠人传递的动作，就会被收进一个更连续的执行闭环。

Block 工程博客里公开提到，95% 的工程师已经在常态化用 AI，第二大群体已经在并行跑 3 到 5 个 agent 实例。它还描述了一种以前几乎不可能成为日常的工作方式：agent 自己读工单、自己建分支、自己提 PR、自己盯 CI、自己修失败，人类主要在 review 时介入。这个变化不是“写代码更快了”那么简单，而是很多原来需要层层传递的中间动作，开始被压进同一条回路里了。

过去中间层存在的重要原因，是系统不连续；现在 agent 的价值之一，就是把这条链路重新接起来。

所以被压缩的，不是管理者，而是“只做协调的管理者”

我不太认同一种粗暴说法：AI 会先替代 manager。更准确的说法应该是，AI 会先压缩那些主要靠协调存在、却不真正拥有判断与问责权的 manager 职能。

这两者差别很大。

如果一个人的主要工作是：追状态、开会、同步、转述、向上包装、向下分发，那他最危险。因为这类价值本质上建立在信息差和串行流转上。而 AI agent 恰恰最擅长把这部分摩擦打平。

但如果一个管理者真正做的是另外几件事，情况就完全不同了：定义优先级，承担架构后果，拍板资源配置，处理跨团队冲突，扛事故，接审计，做风险接受，给外部合作方和客户兜责任。这里面的核心价值不是“传递信息”，而是“承担后果”。这类角色短期并不会因为 agent 能写更多代码就消失。

所以我更愿意把这件事说成一句更精确的话：被压缩的不是 middle management 这个词，而是 coordination-only management 这种组织形态。

哪些角色更脆弱，哪些角色更稳

如果把岗位 title 暂时放下，只看任务结构，我现在更倾向用五个问题来判断一个角色的韧性。

• 这个任务是不是高度标准化。
• 结果是不是容易自动验证。
• 角色是否承担问责与后果。
• 工作是否依赖跨边界整合。
• 价值是否建立在人际信任与博弈上。

按这个框架看，软件组织里最脆弱的，通常不是“junior”或“中层”这些名字，而是下面这些任务束：大量标准实现、大量标准测试、大量标准运维，以及主要靠状态同步、项目推进、信息搬运而存在的协调工作。

更稳的则是另一类：强 ownership 的技术负责人，平台和架构边界设计者，安全、合规、审计、事故响应这类高责任角色，以及销售、客户管理、合作关系这类高信任密度角色。不是因为 AI 碰不到这些事，而是因为这些事的价值中心不在“产出内容”，而在“对结果负责”。

这也是为什么我不太喜欢那种泛泛的岗位预测。AI 不是按岗位名册裁人，它是按任务结构重新定价。

这件事对技术管理者真正的提醒

很多管理者看到这种案例，第一反应会是：那我要不要重新学写代码？我觉得这只对了一半。

技术管理者当然必须亲自下场用 agent。否则你根本无法判断团队口中的“AI 已经提效很多”到底是事实，还是演示版幻觉。但如果只把结论停在“管理者也得会写代码”，还是太浅。

真正更重要的，是管理者要把自己从“传话筒”升级成“组织设计者”。谁能重写流程，谁能把 repo、上下文、验收标准、约束、审查回路和 agent 编排成新的生产函数，谁就不是被替代的对象，反而会成为放大器。

换句话说，AI 对管理层的要求，不是简单地下沉回执行层，而是上移到更高杠杆的设计层。

也别把社交媒体里的每个数字都当真

这里我觉得也需要克制一点。像“会议减少 70% 到 80%”“某项目从 15 人变成 4 人加 AI”这类说法，传播力很强，但我目前还没看到足够扎实的公开原始出处。能够确认的是，Block 在播客摘要和工程博客里都已经公开呈现了“小团队 + 多 agent 并行”的方向；不能确认的是，这些特别整齐、特别戏剧化的数字已经到了可以当事实引用的程度。

这并不影响大的判断成立，但会影响我们怎么讲。真正有说服力的表达，不需要靠把所有戏剧性数字都照单全收来撑场子。趋势本身已经足够强了。

值得相信的，不是每个传播中的细节数字，而是那条越来越清楚的组织逻辑：小团队 + agent 并行，正在替代大团队 + 层级协作。

最后一句

围绕这篇小红书，我最终更愿意保留的，不是“AI 开始杀职场中登”这种带情绪的说法，而是一个更冷一点、也更能落到组织设计上的判断：

AI 先压缩的，不是程序员，而是研发组织里的信息中间层。

谁的价值主要来自信息搬运、串行协调和流程存在感，谁会先被重估。谁能定义方向、承担后果、处理例外、并把 agent 编排进真实生产系统，谁反而会变得更重要。

这篇文章不是在预测某个 title 会消失，而是在提醒一件更现实的事：软件组织比代码更早进入 AI 重构期。

引用来源

• CNBC: Block laying off about 4,000 employees, nearly half of its workforce
• Block: From Hierarchy to Intelligence
• Block: codename goose
• Block Engineering Blog: AI-Assisted Development at Block
• Block Engineering Blog: How We Red-Teamed Our Own AI Agent
• CoinDesk: Jack Dorsey Says AI Should Replace Corporate Hierarchy
• a16z 节目摘要页：What Happens When a Public Company Goes All In on AI
• Microsoft Security Blog: Securing and governing the rise of autonomous agents
• Microsoft Annual Report 2025
• McKinsey Technology Trends Outlook 2025

AI 先生成了二十个人的面试评语。我看完很不满意。不是太严肃，就是太儿戏。后来我没有继续往 prompt 里补一堆形容词，也没有试图一次性把自己的风格解释清楚。我只做了一件更笨、但更有效的事：先手工改四份，然后让 AI 自己去总结我改了什么、为什么这么改，再让它照着这个总结去改剩下十几份。

效果一下就对了。

很多时候，我们以为自己在“给 AI 补要求”，其实已经在做一件更接近偏好学习的事：先用修改动作表达偏好，再让系统去学偏好。

为什么我觉得这件事不是小技巧，而是一条大方向

RLHF 这几个字这些年被讲得很重，像是只有大厂研究团队才能玩。但如果把形式感拿掉，它最核心的那层其实很朴素：不是让人类先写出一套完美规则，而是让人类先表达“哪个更好”。

InstructGPT 那篇论文里，最关键的动作不是模型多大，而是他们收集了人类对多个输出的排序，再把这些排序变成后续训练信号。后来 DPO 又把门槛往下砍了一截，告诉大家偏好优化不一定非得显式训练 reward model，再走完整 RL 流程。

这件事对真实工作非常重要。因为人类通常不擅长提前讲清楚“什么叫恰到好处”，但很擅长在两个版本里挑一个更喜欢的，或者顺手把一句话改到顺眼。

换句话说，真正高价值的反馈，很多时候不是 thumbs up，不是五分制打分，而是编辑动作本身。

编辑动作为什么这么值钱

我现在越来越确信，很多 AI 产品最容易忽略的一种数据，恰恰是最值钱的数据：用户改了什么。

因为它天然同时带着三层信息。第一层是结果偏好。用户把一句话改掉，本身就在说“原版不如这个版本”。第二层是局部归因。用户不是整篇推翻，而是改了某几个词、某几句结构，这等于顺手告诉了你问题发生在哪。第三层是上下文。这个修改不是实验室里的标注，而是发生在真实工作流里，天然带着角色、场景和业务约束。

所以我越来越不相信那种只盯着显式反馈的产品设计。很多用户懒得点赞点踩，就算点了，你也不知道他到底不满意什么。相比之下，修改痕迹的信息密度高得多。它不像一句“写得不好”那么含糊，它已经把“不好”翻译成了具体改动。

Rubric 才是把 taste 变成系统资产的桥

回头看那次招聘评语，我觉得最关键的一步其实不是“改四份”，而是“让 AI 总结我到底改了什么”。因为这一步做的，本质上是把隐性的审美标准外化成一套 rubric。

比如：要具体，不要空泛夸赞；要有人味，但不要油；要指出优点和风险，但不要上价值上得太满；语气要像真 manager 写的，而不是像系统模板。这些东西如果永远只留在人脑里，它就只能靠资深者亲自盯。它不能规模化，也不能稳定复用。

但一旦你把它写出来，很多事都变简单了。你可以让模型按 rubric 自评，让多个候选版本互相比，让 reranker 按 rubric 排序，甚至以后再把这套 rubric 转成训练数据。rubric 的价值，不是让文风更规范，而是让 taste 开始变成外部对象，开始可积累。

不做完整后训练，也完全可以先跑起来

很多团队一听“偏好学习”，第一反应是：我们没有训练能力，也没有那么多标注资源。那是不是只能继续补 prompt？我觉得不是。

Self-Refine 已经证明，不做额外训练，只靠 test-time 的“生成 -> 反馈 -> 改写”循环，也能明显提升输出质量。它给了一个特别现实的启发：反馈不一定非得先进参数层，先进入运行时循环也能产生很大价值。

所以一个非常现实的“人工简化 RLHF”流水线，其实可以很朴素：

• 先抓少量高质量人工修改样本，不求多，先求密度高。
• 让 AI 总结原版和修改版差异，抽出 rubric。
• 后续每次先生成多个候选，再按 rubric 做挑优，而不是一把梭直接终稿。
• 边界样本、风格强样本、低置信度样本，再回给人拍板。
• 失败案例单独沉淀成回归集，让这套 taste 不断被校准。

注意，这整套东西里最值钱的，根本不是某个模型名词，而是那条持续运转的反馈链。它让“这个更像我”的主观感觉，开始变成一个可以被复用、被放大、被自动化的系统输入。

代码评审领域已经给了很强的现实信号

如果你觉得招聘评语还只是文字工作，那代码评审会给一个更硬的现实版证据。

Google 关于 code review comments 的工作 已经说明，reviewer 的自然语言评论本身，就可以驱动模型给出建议修改。这等于默认承认了一件事：评审反馈不是噪声，它本身就是可学习信号。

更进一步，像 CRScore 这类工作开始强调 code review 没有唯一标准答案，更适合用 conciseness、comprehensiveness、relevance 这类维度来评价评论质量。最新的 SWE-PRBench 甚至直接拿 human-flagged issues 去量化 AI review 质量，结果显示今天的 frontier models 仍然离人类 expert 很远。

我对这些工作的解读不是“AI 还不行”，而是另一层：团队的评审 taste 正在从经验沉淀，变成数据沉淀。以前 reviewer 的好坏，更多靠口碑和资历在传。现在，评论文本、最终修改动作、接受率、回滚率，开始都能变成结构化信号。

那注意力轨迹呢

我对“监控审核代码时的注意力轨迹”这件事的判断是：有价值，但更适合作为高成本辅信号，而不是主干监督。

像 关于 PR 情绪理解的眼动研究 已经说明，开发者在 PR 页面上的 gaze 分布是有稳定模式的。评论正文、新增代码、用户名会被看得更多，甚至 emoji 也会获得异常高的注意力。这说明 reviewer 的认知资源并不是随机投放的。

但我不会把这条路吹得太满。眼动数据贵、噪声大、解释难，而且“看得久”并不天然等于“这个地方重要”。所以它更像研究工具和产品优化信号，适合帮助理解 reviewer workflow，或者验证界面设计，而不太像最先该规模化落地的监督主轴。

真正更现实、更低成本、也更容易规模化的主监督，还是这些：reviewer comment 文本、评论后的最终修改动作、多个候选改法里人类最后选了哪一个、哪类问题总被人类盯出来、哪类问题总被 AI 漏掉。

我现在更相信的判断

下一批真正拉开差距的 agent，不是会说得更多的 agent，而是会从这些细小却高密度的人类反馈里，慢慢学会“什么叫更对”的 agent。

所以如果今天让我给 AI 产品提一个最实际的建议，我不会先问“你用了哪个模型”，我会先问：用户编辑后的痕迹你们记了吗？用户挑优的动作你们记了吗？你们有没有把这些动作沉淀成下一轮系统能力？

如果没有，那产品再智能，本质上也还只是一次性生成器。如果有了，它才开始从工具走向会学习的系统。

所以第一次在邵阳看到那种场面，我确实有点愣住。鞭炮被人熟练地围着坟头绕了几圈，引信一点，整片山都是响的。旁边还有烟花，炸开的时候甚至有点像过年。后来我才知道，在当地不少农村地区，扫墓本来就是家族性的大事，鞭炮不只是声响，还是一种通知，一种排场，甚至是一种兴旺的展示。

同样是虔诚，北方更像轻声说话，南方更像开着扩音器说话。

如果只用“谁更文明”去理解这种差异，基本上一定会看错。因为它不是礼貌程度的差异，而是世界观的差异。

同一种敬意，为什么会长成两种样子

我后来把这件事想明白，靠的不是一句民俗解释，而是把不同地方的画面摆在一起看。

山东很多地方扫墓要给坟头添新土，意思是给祖先“修屋顶”，别让夏天漏雨。烧纸也要画圈，圈口朝着坟墓方向，像是给先人开一条专属通道。整个逻辑都很北方：谨慎、克制、讲分寸，甚至有点像在做一件必须庄重完成的家务事。

广东的逻辑就完全不一样。当地把扫墓叫“拜山”，很多地方的标准流程就是清杂草、摆贡品、拜祭、放鞭炮。祭完祖还会有“太公分猪肉”这样的环节，把猪肉分给族人，意思是祖宗的福气要落到活人身上。你会发现，这不是“探望”，而是“请祖先回来一起过事”。

福建更灵活，泉州、漳州、莆田连扫墓时间都不完全跟着清明走，有的挪到上巳节，有的更看重冬至。江浙则把节令感更多放进食物里，青团、菠菠粿这些东西，本身就是一种把祖先、季节和家常生活连起来的方式。湖北、湖南处在南北之间，但在扫墓这件事上明显更偏热闹，尤其宗族性强的地方，清明既是祭祖，也是家族一年一度的再聚拢。

如果一定要压成一句话，我现在更愿意这么说：

北方扫墓，更像去探望一位需要安静休养的长辈。南方扫墓，更像把一位久未归家的长辈请回家里吃顿饭。

鞭炮不是打扰，而是一种沟通协议

理解了这个前提，再回头看“坟地为什么要放鞭炮”，就没那么难了。

民间对这件事有几种解释。有人说是通知祖先来领祭品，有人说是驱赶别的鬼魂，别让供品被“抢走”，还有一种说法更朴素，就是扫完墓后给活人驱驱晦气。三种解释听起来不一样，但底层都一样：鞭炮不是为了表演，是为了传递信号。

在北方语境里，这种信号可能显得太吵了，因为北方默认的假设是“逝者需要安宁”。可在南方不少地方，默认假设恰恰相反：祖先也需要热闹，需要排场，需要知道这一年子孙过得怎么样。你去看望朋友，总不能一句话不说，祖先也一样。既然是请他回来，那就得让他听见。

所以同一个动作，在不同文化假设下，含义可以完全反过来。对山东人来说，太响可能像打扰。对邵阳乡下很多人来说，不响反而像怠慢。问题从来不在鞭炮本身，而在你认定“那边的人”到底更需要什么。

南北差异，不只是风格问题，背后有两千年的分叉

这件事也不是现代人才分出来的。清明本身就是一个混合节日。它早年跟寒食节长期纠缠在一起，而寒食的核心记忆是禁火、冷食、节制。这个基因在北方，尤其山西、河北、山东一带保留得更深，所以北方清明天然带着一点“收着来”的气质。

南方保留下来的则更多是春祭和宗族礼俗的基因。广东、福建、湖南这些地方祠堂文化更强，很多时候扫墓不是一个小家庭的事，而是整支宗族的事。人一多，祭品一丰盛，仪式自然就往隆重走。再叠加南方物产更丰富，三牲、糕粿、聚餐这些东西都更容易进入祭祀系统，整个氛围就更像“办事”。

换句话说，今天看到的“南热闹、北肃穆”，不是谁后来故意设计出来的，而是不同历史传统、宗族结构和生活条件层层叠出来的结果。唐宋以后它们都叫清明，但骨子里保留的底色并不一样。

少数民族的例子会把这个结论再往前推一步。壮族的五色饭、土家族的挂青、满族的插佛托、苗族的生命树，再到维吾尔族和藏族完全不同的祭祀体系，都在提醒我们：中国人面对逝者，从来没有一种单一标准答案。 有人认为要让祖先热热闹闹地回来，有人认为要让祖先安安静静地长眠，也有人根本不靠坟墓去连接逝者。

今天讨论“文明祭扫”，最怕把安全问题偷换成审美问题

这几年各地都在推文明祭扫。鲜花替代烧纸，网络祭扫替代现场祭扫，很多地方也明确禁放鞭炮。从环保和消防角度看，这些规则没有问题，我也完全理解。清明期间山火风险高，这不是可以浪漫化的事。

但我越来越在意另一个细节：当我们说“文明”的时候，究竟在说什么？

如果说的是安全、环保、秩序，那就是公共治理问题。可如果不自觉地把“安静”也一起打包进“文明”，把南方那种热闹、响亮、家族性很强的祭祖方式，一概看成落后、扰民、需要被修正，那其实是在拿一种地域审美去覆盖另一种地域传统。

公共治理当然要解决风险，但不该顺手把文化差异也一起抹平。

更好的做法不是假装差异不存在，而是在承认差异的前提下做约束。哪些地方必须禁火，哪些区域可以设置安全替代，哪些传统可以用电子鞭炮或集中燃放去保留仪式感，这些都比“一刀切”更难，但也更尊重现实。

回到那座山头，我最后想明白的是一件小事

后来我再回想邵阳那座山，已经不太会把“安静”和“热闹”简单对立起来了。

我在坟前沉默磕头，是在和祖先说话。当地亲戚点燃鞭炮，也是在和祖先说话。一个用内心独白，一个用扩音器。音量差很多，频道其实是同一个。

清明最有意思的地方，也许就在这儿。它每年都来，但从来不是同一个清明。你站在哪片土地上，你从哪个家族里长出来，你小时候看惯的是烧纸、添土、挂青、青团、五色饭还是猪头肉，都会决定你觉得“怎样才算敬”。

所以我现在更愿意把问题改写一下。鞭炮绕坟头三圈，是敬还是不敬？我的答案是：先别急着判断，先问一问，在那个地方的人心里，祖先到底是睡着了，还是等着你回来。

写于 2026 年清明。起因是一段真实经历，但真正让我记住的，不是鞭炮声有多大，而是同一种思念，原来可以长成这么不一样的样子。

校招选人，特质（Trait）比技能（Skill）重要得多。

这话说起来像老生常谈，但放在 2026 年的背景下，它的含义发生了根本性变化。

一个反直觉的数据

Korn Ferry 在 2026 年初做了一个覆盖 1600 名全球人才获取领导者的调研，结论是：73% 的 TA Leaders 把批判性思维列为第一招聘优先级，而 AI 技能仅排第五。

这个排名让很多人意外。CEO 和董事会通常认为 AI 技能是第一优先级，但每天面对候选人的一线招聘负责人，给出了完全不同的答案。

Korn Ferry 的解释很直接：

"Anyone can learn to use ChatGPT in a few weeks. But knowing when it's giving you unreliable information? Spotting the difference between helpful insights and convincing but flawed output? That requires critical thinking. Most people can learn AI in less than a month. Developing critical thinking? That takes years."

学会用 AI 工具，几周就够了。但判断 AI 什么时候在给你一个"看起来很对但其实有问题"的答案？这需要批判性思维，而批判性思维需要数年培养。

哈佛商学院的研究进一步佐证了这一点——将近 80% 的"特定技能薪资溢价"，其实依赖于底层的基础能力：阅读理解、口头表达、批判性思维、领导力和团队协作。技能是叶子，特质是根。叶子可以长出来，根坏了就全完了。

企业真正需要的人才长什么样

综合 WEF、MIT Sloan、麦肯锡、Anthropic 等多个来源，我试着画一个更清晰的画像。

WEF 2025 年对 2030 年核心技能的预测，传递了一个清晰信号：增长最快的 10 项技能中，只有 3 项是纯技术技能，其余 7 项全部是人类认知和特质类技能——创造性思维、韧性与敏捷、好奇心与终身学习、领导力与社会影响力。

MIT Sloan 对美国约 950 种职业、19000 项工作任务的逐一评估后，结论更加直接：AI 最不可能替代的任务，恰恰是那些依赖同理心、判断力、伦理和希望等"人类独有能力"的任务。

如果要给 AI 时代的人才竞争力写一个公式，我会这样写：

AI 素养（Baseline）× 批判性思维（Multiplier）× 跨学科整合力（Differentiator）× 人类独有特质（Moat）

AI 素养是入场券，不是比谁会用更多工具，而是理解 AI 的能力边界、能设计人机协作的工作流、能验证 AI 的输出质量。但真正拉开差距的，是后面三项——它们很难在短期内训练出来，也很难被 AI 伪造。

各岗位到底变了什么

变化最剧烈的是开发岗。有人在 Dev.to 上写了一句话，我觉得比任何长篇分析都精辟：

"The most valuable skill in 2026 isn't writing code. It is deleting it. Writing code is creation. Deleting code is judgment."

写代码是创造，删代码是判断力。腾讯超 90% 的工程师已经在用 AI 编码，GitHub 数据显示 80% 的新开发者第一周就开始使用 Copilot。当 AI 替你写了大部分代码，工程师的核心价值就从"能写"变成了"能判断"——系统架构怎么设计、AI 生成的代码哪里有坑、什么该留什么该删。

产品经理的变化同样深刻。传统 PM 的思维是"输入 A → 输出 B"，AI 时代的 PM 面对的是"输入 A → 输出 B/C/D"。核心任务不再是定义功能，而是构建一个能持续收敛、可评估、可干预的智能系统。中国 AI 产品经理岗位需求同比增长 240%，但 88% 声称在用 AI 的企业里，真正实现规模化变现的不足 7%。缺口不是"懂 AI 的人"，是"既懂 AI 又懂业务还能落地"的人。

运营岗最值得关注的变化是从 SEO 到 GEO（生成式引擎优化）的范式转移。AI 搜索用户渗透率已突破 78%，经过 GEO 优化的内容被 AI 引用的概率提升 8 倍。运营需要理解不同 AI 的"性格"——DeepSeek 注重事实准确性，豆包偏好通俗解答，Kimi 擅长长文本。这不是"学一个新工具"的问题，是整个内容策略的底层逻辑在变。

一个跨岗位的共同趋势：纯执行技能在贬值，问题定义能力在升值。"实现什么（What）"比"如何实现（How）"更稀缺。AI 编排能力正在成为类似当年 Excel 一样的基础技能——不会用，等于职场文盲。

校招面试的现实：作弊已成"新常态"

但选人之前，先要面对一个不那么光鲜的现实。

Fabric 平台对 19368 场面试的分析显示：38.5% 的候选人表现出作弊迹象。2025 年下半年，作弊率从 15% 飙升到 35%，半年翻了一倍多。

作弊工具已经形成了成熟的生态：Cluely（每月 20 美元）、Interview Coder、Final Round AI……提供隐形屏幕覆层、实时代码生成、音频转录加答案生成。Gartner 预测到 2028 年，四分之一的候选人资料将完全是 AI 伪造的。

简历同质化同样严重。有面试官在牛客上吐槽："面试的应届生多了之后，大家好像都没什么个性，简历上写着相似的项目，按相似的模板回答问题，再按相似的套路反问面试官。"

这是一个结构性的矛盾：AI 让候选人和简历都变得更"完美"了，但面试官反而更难看到真实的人。

怎么面试才有效：六个策略

既然作弊防不住，与其死盯对抗，不如换一种思路——设计让 AI 辅助失效的动态评估环境。几个我觉得特别有用的策略：

1. 动态追问，不给 AI 反应时间

静态、可预测的问题是作弊工具的温床。一旦候选人给出一个打磨得很漂亮的回答，立刻追问具体场景、追问失败经历、要求换一个上下文重新解释。作弊工具没法处理这种节奏。

2. "三层面试法"：结果 → 行为 → 动机

第一层问"你做了什么"，第二层问"你具体怎么做的、遇到什么困难"，第三层问"你为什么选这个方案而不是另一个"。第三层是区分度最高的——AI 可以帮候选人回答 What 和 How，但很难伪造 Why 背后的真实决策逻辑。

3. Knowledge Cutoff 钓鱼

捏造一个不存在的技术概念或框架版本，观察候选人反应。AI 工具可能生成自信的虚假回答，真正有经验的人会坦率地说"没听过"。

4. 现场实操，看过程不看结果

技术岗 live coding 加实时讲解思路。重点不是最终的代码对不对，而是候选人的思考路径——他怎么拆解问题、怎么决定从哪里开始、遇到卡壳怎么应对。

5. 追问失败经历

让候选人描述项目中最大的失败和学到了什么。AI 很难伪造一个逻辑自洽、细节丰富的真实失败经历。真的做过的人，讲起失败时的情绪和细节是装不出来的。

6. 麦肯锡范式：从"防 AI"到"测 AI 协作"

这是我认为 2026 年最值得关注的面试创新。麦肯锡不再对抗 AI，而是要求候选人在面试中使用它内部的 AI 工具 Lilli，然后评估候选人怎么向 AI 提问（问题设计能力）、怎么解读 AI 的回答（批判性思维）、怎么将 AI 输出放入业务场景（判断力和上下文理解力）。

评估的不是"能不能用 AI"，而是"用 AI 的方式暴露了什么"——好奇心、判断力、以及对 AI 边界的真实理解。

大厂都在怎么抢人

看看 2026 届校招的数据，能感受到这场人才战争有多激烈。

百度发了 4000 多个 offer，AI 岗位占比超 90%。字节的 Top Seed 计划面向博士生开出日薪 2000 到 5000 元的实习薪资。阿里星计划允许面试通过后反选项目和团队。快手的快 Star-X 计划年薪不设上限，已经开出过超 200 万的 offer。

海外更夸张。Meta 为了挖顶级 AI 研究员，单人 4 年薪酬包开到 3 亿美元。Databricks 的 VP 说了一句话："寻找 AI 人才就像寻找勒布朗·詹姆斯，全球能构建前沿 AI 模型的人不超过 1000 人。"

但薪资分化也极度剧烈——顶尖人才计划年薪 200 万，普通 AI 测试岗月薪 8500 元，差距 20 倍。这不是一般的两极分化，是K型分化：同样叫"AI 岗"，塔尖一将难求，塔底竞争惨烈。

更值得注意的变化是：AI 候选人不愿意和 HR 沟通，要求直接和技术负责人对话。这倒逼大厂技术专家大量下场做招聘。字节 Seed 邀请豆包视觉负责人做候选人的定制导师。校招的形态本身也在被重塑。

一个值得警惕的趋势

所有的热闹背后，有一个趋势让我真正担忧。

Fortune 500 的高管调研揭示了一个深层危机：AI 自动化了入门级的"grunt work"——那些重复性的基础工作，恰恰是培养深度思考能力的传统路径。金融和法律行业的新人，以前要靠做大量"苦力活"来积累行业认知和判断力。AI 把这层活干了，新人成长的阶梯被抽掉了。

"If AI is sort of replacing the entry-level typical positions, and I need people sort of in the middle, how do I prepare the future middle if I don't give them that ability at the base?"

如果入门级工作被 AI 替代了，中层管理者从哪里来？这不是一个校招问题，是一个人才供应链的结构性问题。企业如果不重新设计新人培养路径，几年后会面临中层断层。

麦肯锡对此给了一个反直觉的答案——重新优先考虑文科毕业生。理由是文科生拥有更多"真正新颖"的思维方式，能做出 AI 模型无法实现的"非连续性逻辑跳跃"。Anthropic 联合创始人 Daniela Amodei（文学专业出身）也持同样观点：那些让我们成为人类的特质——沟通力、情商、好奇心、善良——在 AI 时代会变得更重要，而不是更不重要。

我的结论

做完这轮调研，我对校招选人的判断浓缩成五句话：

1. 重新定义岗位：从 Skill-based 到 Trait-based。在 JD 里明确列出期望的特质——好奇心、韧性、判断力、学习敏捷性，而不是只列技术栈清单。
2. 升级面试流程：引入"三层面试法"+ AI 协作测试。放弃标准化技术问答，转向动态追问。对高潜力候选人，参考麦肯锡模式，测试与 AI 协作的能力。
3. 降低学历权重，提升实战权重。前程无忧数据很清晰：企业招 AI 应届生时，实际项目经历（52.5%）远比名校学历（28.8%）重要。有大厂实习的 985 本科生比无实习的清北硕士更受欢迎。
4. 实习是最好的面试。从集中校招季转向全年持续招聘。实习期本身就是最长、最真实的面试。
5. 拥抱 AI，不要对抗 AI。面试防作弊是必要的，但更前瞻的做法是把"AI 协作能力"纳入评估维度。一个能高效使用 AI 并知道何时质疑 AI 的候选人，比一个"纯靠自己"的候选人更有价值。

回到开头那句话：AI 时代的校招，不是在找"最会用 AI 的人"，而是在找"AI 无法替代的人"——然后确保这些人也会用 AI。

这两件事缺一不可。只有第一个，你招了个不会用工具的理想主义者；只有第二个，你招了个 AI 的操作员。真正的人才，是两者的交集。

调研基于 WEF、Korn Ferry、MIT Sloan、McKinsey、Forbes、Anthropic、前程无忧、BOSS 直聘等 60+ 中英文权威来源，全文调研报告留在内部归档。

这个问法当然没错，但它还停留在表层。因为它默认“行业”是分析单位。可真正决定命运的，往往不是行业名，而是这个行业到底靠什么赚钱。

AI 最先压缩的，不是某个行业，而是某一种价值结构。

如果一个业务主要靠信息中转、标准化匹配、流量分发、规则执行赚钱，那它就站在 AI 的正面冲击带上。反过来，如果一个业务主要提供的是情绪价值、身份认同、线下体验、人际互动或责任背书，那它受影响的节奏就会慢很多。

第一类业务：提升中转效率的业务，最危险

我今天举的第一个例子，是基金平台。

基金平台本身并不生产基金产品，它做的是把基金公司的产品搬到平台上，再卖给用户。过去它的价值来自几件事：掌握流量入口、做精细化运营、给用户推荐、让交易更顺一点。

这个逻辑在“人直接访问平台”的时代成立，因为平台掌握入口，也掌握信息差。但当用户面前出现 Agent，这件事就开始变了。

Agent 天生会做三件事：

1. 替用户搜集信息
2. 替用户做初步比较和筛选
3. 优先寻找更短、更便宜、更少摩擦的完成路径

一旦如此，很多中间层会被直接穿透。Agent 不会天然忠于某个平台，它只忠于目标函数。它会问：如果上游产品就在那，为什么还要多经过一层？

基金平台只是一个例子。把视角再拉大一点，保险中介、OTA、招聘撮合、广告投放中间层、内容分发平台，甚至很多“帮用户做选择”的互联网产品，本质上都在回答同一个问题：我到底是在创造真实价值，还是只是在占一个中间位置？

如果答案偏向后者，那在 AI 时代，这类业务就会被重新定价。

第二类业务：提供情绪价值的业务，反而不容易被提效

第二个例子，是游戏。

游戏很有意思。你很难说 AI 能把游戏“优化”到一个更高效的状态，然后用户就更满意。因为游戏不是在卖效率，它是在卖情绪价值。

一个关卡你玩一天通关，和你三分钟通关，从“效率”角度看当然是后者更高；但从“体验”角度看，很可能恰恰相反。很多游戏的价值，本来就来自投入时间、克服挫折、在共同规则下获得反馈。

这也是为什么外挂永远会破坏游戏生命周期。外挂最大的问题不是它作弊，而是它把原本靠人去投入和竞争的东西，改写成了机器之间的执行效率竞赛。

如果所有玩家都默认用 Agent 帮自己刷副本、打排位、做资源管理，这个游戏短期数据可能还好看，长期却大概率会失去意义。因为玩家留在游戏里，并不是为了把一个 KPI 刷满，而是为了和别人一起，在不确定性、公平感和情绪波动里获得满足。

效率价值可以被机器接管，但情绪价值不能靠“更快”来定义。

这个逻辑不只适用于游戏。体育比赛、演唱会、旅游体验、奢侈品消费、高端服务、线下社交场景，很多业务都一样。AI 可以帮它们做后台优化，但不能替它们生产核心价值本身。

真正的分界线，不是行业，而是这五个问题

做完这一轮调研之后，我越来越确信，判断一个行业会不会被 AI 深度改写，不该先问“它是什么行业”，而该先问下面五个问题。

1. 这个行业赚的是效率的钱，还是意义的钱？

如果用户付钱是为了更快、更准、更便宜地完成某件事，AI 通常会很强。如果用户付钱是为了经历、身份、陪伴、成就感、被理解，那 AI 更像辅助工具，而不是替代者。

2. 这个行业的核心任务能不能被标准化？

凡是可以拆成文档处理、信息检索、标准化判断、固定流程执行的任务，都天然适合被 AI 接管。今天最先被重写的，往往不是最“低端”的工作，而是最“可编码”的工作。

3. 这个行业的中间层到底有没有不可替代的价值？

很多平台型业务以前之所以能活得很好，不一定是因为它创造了很强的新价值，而是因为它曾经占住了入口、吃住了信息差、攒起了用户心智。但当 Agent 帮用户把搜寻成本和比较成本都打下来之后，这些旧优势会迅速贬值。

4. 这个行业最后交付的是不是必须在线下完成？

餐饮、酒店、医疗照护、养老、旅游服务这些行业，AI 会重写后台，却不太可能在短期内替代最后一米交付。因为 intelligence 是一回事，physical execution 是另一回事。

5. 这个行业出了问题以后，责任能不能交给机器？

医疗、法律、金融这类行业，会被 AI 深度改造，但不会被轻易替代。原因不是这些行业不会被提效，而是出错后必须有人承担责任、给解释、接审计、兜风险。用户真正买的，往往不是一个答案，而是一层可追责的背书。

所以未来行业大概会分成三类

第一类：被压缩

这类行业的共同点是，中间层价值大于真实价值。它们看起来很忙，流程很多，运营很重，但很多动作本质上只是把信息搬来搬去，把标准化流程跑一遍。AI 一进来，链路会迅速缩短。

第二类：被重构

这类行业内部有大量可自动化任务，但整条价值链不会消失。银行、软件、生命科学、医疗、法律、咨询大多属于这一类。AI 会替它们重写工作流、重写岗位能力模型，但人仍然在回路里。

第三类：被增强

这类行业的核心价值仍然由人来提供，AI 主要在后台提升效率。比如高端服务、旅游体验、演出、体育、游戏核心玩法、社群型教育、儿童和老人照护。AI 让系统更顺，但用户买单的理由仍然是人。

这件事对公司最大的提醒，不是“赶紧接 AI”

很多公司现在谈 AI，还是停留在一个很浅的层次：能不能降本，能不能提效，能不能给现有流程打一层智能补丁。

当然这很重要，但还不够。更重要的是先搞清楚：我们现在赚的，到底是哪一种钱？

• 如果赚的是信息差的钱，那要小心 Agent 直接抹平信息差。
• 如果赚的是流程中转的钱，那要小心 AI 把流程压平。
• 如果赚的是流量分发的钱，那要小心入口从 App 迁到 Agent。
• 如果赚的是情绪、关系、身份、责任的钱，那要考虑怎么把这些价值进一步做深，而不是只盯效率。

真正稳的公司，未来大概率都得至少占住一件事：控制真实供给、控制信任责任、或者控制情绪与社群价值。

最后一句

这轮调研做完，我脑子里留下来的不是“AI 会影响多少岗位”这种统计口径，而是一句更直接的话：

AI 最先吃掉的，不是某个行业，而是那些只是在帮别人做信息搬运和规则执行的价值幻觉。

反过来，AI 最难替代的，也不是简单的“线下”或“创意”，而是那些必须由人来完成意义确认、关系建立、责任承担和情绪交换的环节。

所以以后再看一个业务，我可能会先问一句：它到底是在帮用户提高效率，还是在帮用户获得意义？这个问题，比“它是不是 AI 行业”重要得多。

这篇文章写于一顿午饭之后。它不是完整调研报告的缩写版，而是我从那份调研里真正提炼出来的一个判断框架。

这种感觉很像软件工程里的打地鼠。你把一个洞堵上，另一个洞又冒出来。于是大家自然会想到一个办法：维护错题集，把踩过的坑一条条记下来，下次执行前一股脑塞给 AI，看起来就会越来越稳。

但真正跑下来，我越来越怀疑，事情没有这么简单。

很多时候，错题集确实能修掉一个局部问题；可当它开始越积越厚，系统反而会出现一种奇怪的退化：原本主任务并没有更清楚，约束倒是越来越显眼。最后 AI 的状态，不像是在努力完成任务，更像是在努力别犯错。

这类系统最容易发生的偏移，不是“不会做”，而是“把注意力从目标转移到了约束”。

错题集的问题，不在于它是错的，而在于它会慢慢抢走主语

我觉得这里最重要的一点是，模型并不会天然把你给它的信息分成两栏：左边是“真正要完成的任务”，右边是“顺手看一下的防错提醒”。对它来说，所有信息都在同一个上下文窗口里竞争注意力。

所以，当你不断补：别忘了这个、不要漏掉那个、上次这里错了、那个页面不能只本地生成、这个链接不能只测 200、那个样式不能跑偏……你当然是在提升系统的防错意识，但你也在同步制造另一件事：目标本身在上下文里被稀释了。

换句话说，错题集不是没有价值，而是它每长一层，都会和主任务争夺一次显著性。

这也是为什么很多人会有一种很强的体感：约束越多以后，AI 开始显得“很努力”，但做出来的东西并没有更完整。它可能记住了不能只停在本地页面，却忘了首页入口还要更新；它可能记住了要上线，却忘了文章风格不能像调研报告；它可能记住了要自测，却没意识到自测的目标不是 URL 打开，而是线上内容真的正确。

看起来像是它不够聪明，实际上更像是上下文里的重心变了。

很多“新问题”，一半是旧问题终于暴露了，另一半真的是约束把系统带偏了

这里我不想走一个太轻松的结论，说“都是因为约束太多”。那也不准确。

更真实的情况是，通常两个原因同时存在。

第一种，是以前的“没问题”只是一种假象。比如之前根本没检查线上是否真的生效，只看本地目录里文件在不在；又或者之前文章风格没被认真比对，所以格式差异其实早就存在，只是没被拿出来当问题。你一旦开始加严格规则，相当于也在提高观测精度，很多历史遗留问题会同时浮出来。

第二种，才是这次讨论真正点中的核心：当负面约束不断堆高时，AI 的注意力确实会从“我要把这件事做成什么样”转向“我不能再踩哪些坑”。这个过程并不是非黑即白的崩坏，而是慢慢发生的。到某个点以后，系统的整体表现会从“完成任务”变成“规避失败”。

这两个原因叠在一起，就会形成最让人头疼的局面：你一边觉得系统更受控了，一边又明显感觉它没有更会做事。

真正该补的，不只是限制，而是“什么叫完成”

今天这轮讨论里，我觉得最有价值的启发，是有人提到一句很关键的话：当约束变多之后，你必须在“什么叫任务完成”上，补同等级别的规范，避免彼长此消。

这句话非常重要。因为大部分 prompt 或 skill 之所以越调越怪，不是因为限制不够多，而是因为“完成定义”太弱。

很多任务写起来，表面已经很清楚了。比如：“调研这个主题，按我的文风调整一下，发到我的个人网站随笔栏目。”

人看起来觉得毫无歧义，但对系统来说，其实有很多关键环节都没显式化：

• 文章是写成调研报告，还是写成网站原生随笔？
• 发布是指生成 HTML，还是同步到线上真实目录？
• 首页要不要新增随笔入口？
• 线上 URL 返回 200 就算完成，还是必须包含正确标题和新正文？
• 样式只要能看就行，还是必须和既有随笔模板一致？

如果这些定义不明确，AI 就只能从最容易达成的表面动作里猜一个“差不多完成”。于是本地文件生成了，也可能被它当成“已经发布”；URL 能打开，也可能被它当成“已经上线”；页面有内容，也可能被它当成“风格已经对齐”。

所以真正有效的做法，不是继续补“不要这样”，而是把完成标准写成一条清晰的正向链路：做到哪些可验证的状态，才算真的完成。

官方文档其实也在说同一件事：不要只说别做什么，要说该怎么做

我去翻了一圈公开资料，发现这件事并不是少数人的体感，而是现在主流模型厂商都在用不同方式提醒开发者。

OpenAI 在 prompt engineering best practices 里有一句非常直接的话：与其只说不要做什么，不如告诉模型应该做什么。这个建议看起来很朴素，但背后其实是同一个逻辑：负面约束只能减少部分坏行为，正向路径才会真正塑造任务完成方式。

Anthropic 讲 agent workflow 时也在强调类似的原则：复杂任务不要默认压成一个越来越大的总 prompt，而应该拆成更简单、可组合、可验证的工作流。因为一旦任务变复杂，真正可靠的不是“再补更多说明”，而是增加清晰的步骤、gate 和 evaluator。

这让我越来越相信，很多人今天遇到的所谓“prompt 越调越重”，本质上已经不是 prompt 工程问题，而是 workflow 工程问题。你不再是在润色几句话，而是在给系统补任务结构。

与其写更厚的错题集，不如把关键节点变成 gate

我现在越来越明确的一个倾向是：能程序化验收的，尽量不要只靠语言提醒。

比如“发布完成”这件事，如果你只是写一句“记得发布到线上并自测”，它对模型来说还是一句抽象话。可如果你把它变成一组 gate，事情就完全不同了：

• 检查生产目录里是否存在对应文件；
• 用 curl -I 看 URL 是否返回成功；
• 用 curl -s 检查页面标题是否正确；
• 用 curl -s 检查正文是否包含新文章的独特句子；
• 再检查首页是否已经出现入口。

这时候系统不再是在“理解一句提醒”，而是在经过一个明确的完成门槛。门没过，就是没完成。这样做的价值非常大，因为它把“经验性的防错”变成了“结果性的验收”。

很多时候，AI 真正需要的不是第 12 条注意事项，而是一个明确会失败的检查点。

再往前一步，很多 skill 问题其实是 harness 问题

我最近一个很强的感受是，很多团队一旦发现 AI 做事不稳，第一反应就是继续打磨 skill。本能上这当然对，因为 skill 最直观、最容易改。但改着改着就会发现，skill 越来越像一个补丁层：这也要交代，那也要补充，最后整份东西越来越厚，像一部谁都不敢删的大工作流剧本。

这时候就该问一句：这些复杂度，真的都该放在 skill 里吗？

很多问题其实是更上层的系统问题。比如：

• 哪些信息应该进长期记忆，而不是每次重复塞进 prompt？
• 哪些行为应该由 runtime 默认保证，而不是靠每次提醒？
• 哪些结果应该通过 eval 和 gate 判断，而不是靠模型自觉？
• 哪些异常应该在工具层兜底，而不是在 skill 文本里补说明？

如果这些东西不分层，系统就会形成一种非常典型的补丁循环：面多了加水，水多了加面。最后看起来像是 skill 在变复杂，实际上是在用 skill 替整个 harness 补洞。

真正成熟的系统，不是把复杂度都塞进一个 skill，而是把复杂度放到正确的位置。

我的结论很简单：每增加一层约束，就要同步增加一层完成定义

如果把今天这件事压缩成一句可执行的话，我会说：

每增加一层防错约束，就要同步增加一层“什么叫完成”的正向定义，最好再配上对应的验收 gate。

因为约束和目标不是两张彼此独立的清单，它们会在同一个上下文里竞争。你只补约束，不补完成定义，系统就会越来越偏向规避失误；你只补完成定义，不补关键错误历史，又会不断重复踩坑。真正稳的状态，是两边一起长，但完成定义必须越来越具体，验收门槛必须越来越硬。

所以我现在不太相信“错题集写厚一点就会更稳”这种简单线性逻辑了。更准确的说法是：错题集有用，但它只能减少重复犯同一类错；如果没有同等级的目标表达、完成定义和 workflow 骨架，它迟早会把系统从做成事，带到少犯错。

而一个真正好用的 AI 系统，最终评判标准从来不是“看起来很听话”，而是“能不能稳定把事情做完”。

参考来源

• OpenAI：Best practices for prompt engineering with the OpenAI API
• OpenAI Docs：Prompt engineering
• Anthropic：Building effective agents
• LangChain：Context Engineering

我看到这里，脑子里第一反应不是“这工具挺适合写文章”，而是：这其实已经不是一个普通写作工具了，它更像是一条最小可运行的 agent 自我优化闭环。

Ghostwriter 真正有意思的，不是 8 个 agent

很多人看到这类项目，注意力会被“多 agent”吸走。但我觉得真正关键的，根本不是 8 个 agent 还是 80 个 agent，而是它把一件事拆成了几个特别清楚的结构件。

第一，有一个明确的被优化对象：文章草稿。第二，有一组评价器：不同角色、不同视角的打分和批评。第三，有一个修改器：根据差评去做局部改写。第四，有复评机制：改完不是算了，还要重新打分。第五，有回滚机制：分没涨就撤回。第六，有过程日志：每一轮吐槽、评分、改动都被记录下来。

你把这几步抽象一下，就会发现这已经不是“写作工具”的问题了。它在展示的是：一个系统如何围绕目标对象做持续实验，并且只保留有效变化。

Karpathy 的 AutoResearch，把同一件事放大到了研究层

这也是为什么 Ghostwriter 很容易让我联想到 Karpathy 的 AutoResearch。

AutoResearch 做的事情很简单，但也正因为简单，所以特别有力量：给 agent 一个真实但受控的小型研究环境，让它通宵自己做实验。它修改训练代码，跑一个固定时间的实验，看指标有没有变好；变好了就保留，没变好就丢掉，然后继续下一轮。

更重要的是，它把边界划得非常清楚：prepare.py 固定，不让 agent 动；train.py 是唯一允许改的文件；program.md 由人类定义研究方向和行为准则。

自我进化不是“让 AI 随便改”，而是“冻结基线、限制可变区、用稳定评估做连续实验”。

这句话我觉得特别重要。很多人一说 agent 自我进化，想象的是某种无限生长、自由变异的系统。但真正能跑起来的，不是“无限自由”，而是“受约束的可逆试错”。

所以问题的核心，真的是两个

如果让我把这类系统的本质压缩成两个问题，我会写成：目标是什么？评估标准是什么？

这也是我觉得这类事情里最底层、最绕不开的两个支点。

没有目标，系统就不知道自己到底在优化什么。它会把“更像样”“更高级”“更复杂”误当成“更好”。最后可能只是把原本有个性的东西打磨成一块标准化的肥皂。

没有评估标准，系统就不知道哪些变化该留下，哪些该回滚。它可以不停生成新版本，却无法真正积累能力。那不叫进化，只叫反复试错。

我更愿意把它抽象成四层

顺着这个思路再往上提一层，我现在更倾向于把“任务自我进化”统一抽象成四层结构。

目标对象（Object）：到底是哪一个东西被持续优化？文章、skill、prompt、memory policy，还是 agent 的运营规则？

评估函数（Evaluator）：系统如何判断这次真的更好了？是单一指标、多维 rubric、用户反馈，还是多角色评审？

变异器（Mutator）：系统如何提出新版本？局部重写、参数调整、策略替换，还是多候选对比？

选择与记忆（Selection + Memory）：哪些变化能活下来？哪些失败以后别再犯？这次成功的经验会不会变成下一轮能力？

Ghostwriter 在文章上已经具备了这四层。AutoResearch 在研究代码上也具备了这四层。差别只是，一个优化的是博客，一个优化的是实验系统。

真正能持续跑下去，还得补上三样东西

但如果想从“局部优化工具”走向“长期可演化的 agent 系统”，我觉得还必须补上三样东西。

第一，冻结区与可变区。 你必须告诉系统，什么可以改，什么不能改。不然它很容易去“改试卷答案”，而不是提升自己的能力。

第二，预算。 每一轮实验都要有时间预算、token 预算、成本预算。没有预算的系统最后通常不是更聪明，而是更膨胀。

第三，反思层。 如果系统只会“改—测—留/丢”，那它更像自动化 hill-climbing。只有当它开始总结“为什么这次有效”“为什么上次无效”，并把这些结论写进记忆里，它才开始从试错走向学习。

这件事不会只发生在文章上

Ghostwriter 给人的第一观感是写作工具，但我觉得它真正预告的不是“以后文章会被自动优化”，而是：以后几乎所有 agent 组件都会进入可被持续优化的状态。

比如，Skill 会自我进化：哪个触发条件太宽了，哪个步骤总让用户补充说明，哪个交付格式最稳。Memory 会自我进化：什么信息值得写长期记忆，什么摘要方式更利于召回，什么写法只会污染上下文。Agent 运营策略会自我进化：什么时候提醒最合适，什么样的汇报节奏不烦人，什么决策该自己做，什么决策该升级给人。

也就是说，未来被优化的，不只是某一个任务结果，而是系统如何优化自己的方法本身。

一个我越来越相信的判断

未来最有价值的 agent，不是一次性把事做完的 agent，而是能围绕目标对象，在稳定评估下持续实验、保留有效变化，并把经验沉淀成下一轮能力的 agent。

这也是为什么我觉得 Ghostwriter 这种项目虽然看起来只是一个小工具，但背后其实踩中了一个非常大的方向：它不是在证明 AI 会改文章，而是在证明 AI 可以围绕一个目标对象形成最小进化闭环。

如果这个闭环继续往前推，写作只是开始。下一步会是 skill，接着会是 memory，再接着会是 agent 自己的运营规则。到那时，我们和 agent 的分工关系也会发生变化：人类不再亲手改每一处实现，而是更多负责定义目标、定义评估、定义边界，以及审计过程。

我现在反而觉得，未来 agent 时代最值钱的能力之一，不是“会不会写 prompt”，而是“能不能定义一个足够稳定、足够有张力、又不会被轻易作弊的评估系统”。

如果只从 demo 观感看，它像是一个“排版效果很厉害”的库。但我认真把它的 README、研究日志、benchmark 和 demo 结构都过了一遍以后，我的结论是：Pretext 真正厉害的，不是做了几个酷炫 demo，而是它把浏览器里最麻烦的一类能力——多行文本测量与换行布局——从 DOM 黑箱里抽了出来。

Pretext 的本质，不是一个排版组件库，而是一层“文本布局引擎化”的基础设施。

Pretext 到底在解决什么问题？

浏览器里很多复杂 UI 做不顺，卡点不在“画不出来”，而在“你没法提前知道文字会占多少空间”。

传统前端处理文本高度，往往要么靠猜，要么先把文字插进 DOM，再用 getBoundingClientRect()、offsetHeight 之类的方法去量。问题是，这些读取会触发布局回流。更糟的是，一旦你的页面里有很多组件都在“写一点 DOM → 读一下高度 → 再写一点”，浏览器就会进入经典的 layout thrashing：读写交错、整页反复重排。

Pretext 的做法很干脆：不要在热路径里问 DOM。 它把流程拆成两步：

1. prepare(text, font)：先对文本做一次分析、分段、测量、缓存。
2. layout(prepared, maxWidth, lineHeight)：之后每次只用纯算术去推导这个宽度下有几行、多高。

这意味着，昂贵的工作被前置，热路径只剩下非常便宜的重算。官方当前快照里，500 段文本批量处理时，prepare() 大约是 18–19ms，但 layout() 只要 0.09ms；相比 DOM interleaved 的写读交错方案，Chrome 下快出约 480 倍，Safari 下甚至是数量级更大的优势。

它为什么会让人觉得“demo 特别惊艳”？

因为 Pretext 解决的不是单点性能，而是把原本不能实时做的事情，变成了“可以每帧都做”。一旦你能在 60fps/120fps 的交互里不断重算文字布局，很多以前只存在于 print、native 或者昂贵定制系统里的效果，就会突然落到普通前端开发者手里。

1. 它让“文字”从黑箱，变成可编排对象

普通 Web 开发里，文字往往是盒模型的一部分：你给它一个容器，它自己往下流。你知道最终结果，但不掌控中间过程。Pretext 提供了 layoutWithLines()、walkLineRanges()、layoutNextLine() 这些 richer API 后，开发者开始能拿到“每一行是什么、宽多少、从哪里到哪里”。这就意味着文字不再只是 DOM 里的内容，而是变成了可被程序路由的东西。

2. 它不是只优化高度预测，而是在打开自定义排版

README 里列得很直白：它支持 DOM、Canvas、SVG，未来还准备支持 server-side。也就是说，Pretext 不是只想做“测量优化”，而是想成为手动布局文本的底层能力。比如：

• 同一段文本，每一行宽度都不一样，绕开图像、头像、浮动物、异形区域。
• 先算出最紧凑的宽度，再生成“刚刚好”的对话气泡。
• 在不知道真实 DOM 高度前，就提前给 masonry / virtualization 计算卡片占位。
• 在富文本里让 chip、code、inline tag 保持整体，同时正文继续自然换行。

这也是为什么官方 demo 给人的感觉不是“一个更快的工具库”，而是“浏览器忽然拥有了新的设计语言”。

3. 它把文本能力从 CSS 委员会节奏里解放了一部分

Cheng Lou 在自己的 thoughts 里写得很直白：如果 userland 对文本有更强控制力，很多 CSS 规范复杂度其实都可以不必继续膨胀。这个判断我非常认同。过去很多布局表达力之所以难，不是因为渲染做不到，而是文本仍然被关在浏览器原生布局黑箱里；你一旦想“拿回控制权”，就会立刻遇到性能与准确性问题。

Pretext 的战略意义就在这：它不是在扩充 CSS，而是在告诉大家，有一类文本布局能力，其实可以下放到 userland，并且性能还足够好。

Pretext 厉害在哪里？我觉得核心有五层

第一层：把最贵的问题换了个位置

很多系统优化失败，不是算法不够巧，而是把昂贵工作放在了交互热路径里。Pretext 最关键的设计不是“怎样更准”，而是先把问题重构成：一次准备、多次便宜重算。这个思想跟很多现代系统工程非常像——不是局部提速，而是重排成本结构。

第二层：它没有为了快，牺牲国际化

这点非常关键。很多文本相关库一旦强调性能，就会默默退化为“英文 + 拉丁字母 + 少量 emoji”的世界。但 Pretext 明确做了大量 i18n 工作：用 Intl.Segmenter 处理 CJK、Thai、Arabic 等脚本；为 bidi、emoji、软连字符、tab、preserved spaces、不同脚本的标点黏连做了大量工程修补；并维护了跨 Chrome / Safari / Firefox 的浏览器精度基线。

它的 research log 里最打动我的一点，是它不是靠“一套聪明公式”赢，而是非常老实地围绕浏览器行为做长期校准：哪些方法试过但失败、哪些脚本是 canary、哪些 browser-specific shim 值得保留、哪些看起来优雅但会拖慢热路径的方案必须回滚。

第三层：它把“文本测量”变成了 AI 友好的能力

这件事很多人可能还没意识到。现在 AI coding 最容易做出来的是“看起来像页面”的东西，最难做的是“真正把交互细节、空间关系、文本约束处理对”。Pretext 让很多文本相关判断不再依赖浏览器黑盒试错，而可以直接在代码与计算层面完成，比如：

• 按钮文案会不会换行；
• 某个卡片在当前宽度下应该占多高；
• 两栏排版里标题绕开图形后每行该怎么走；
• 富文本块在缩放或拖拽时何时重算布局。

这会极大提升“模型生成 UI → 自动验证 → 自动修正”的闭环质量。换句话说，Pretext 不只是前端工程提效工具，也是未来 agent 做设计实现时的一块新地基。

第四层：它打开的是一整类新 UI，不是单个组件

好的基础设施常见的标志，不是“它自己很强”，而是“它让很多此前不值得做的东西变得值得做”。Pretext 正是这样。它 unlock 的不是一个聊天气泡、一个排版 demo，而是一整类以前因性能/复杂度被压住的界面形式：

第五层：它其实在逼问浏览器的一条边界

Pretext 让我强烈感受到的一点是：前端过去很少把“文字”当作一个可编排的几何系统来对待。图形、动画、粒子、3D、shader，大家已经很习惯自己接管；但一到文本，马上又退回 DOM/CSS 默认流。Pretext 某种意义上是在挑战这个默认：如果我们能自己拿到足够接近浏览器真值的文本几何能力，浏览器上的 UI 创作边界会往外推很多。

但它也不是魔法，它的边界非常清楚

这恰恰也是我喜欢它的地方：它不是一个乱许愿的项目，而是非常诚实地定义了自己的适用面。

• 它当前面向的是常见文本配置：white-space: normal、word-break: normal、overflow-wrap: break-word、line-break: auto。
• 它明确提示：macOS 上 system-ui 不安全，最好用具名字体。
• 它不是完整 font rendering engine，很多问题仍是“尽量贴近浏览器”而不是取代浏览器。
• 它现在最强的是“测量与布局”，不是编辑器级富文本系统、也不是完整 typography 排版标准实现。

这意味着，Pretext 更像是一个高价值的“中间层引擎”：介于浏览器原生黑箱和全自研渲染栈之间。这个位置其实非常聪明，因为它不需要把整个问题吃下来，就已经足以改写很多场景的成本结构。

如果文字渲染能力真的提速这么多，会对哪些领域产生重大影响？

我觉得最值得看的，不是“现在已有谁能用”，而是“哪些原本被文字拖慢的系统，会因此换一种设计方式”。

1. 聊天、社区、信息流产品

这是最直接的一层。消息列表、评论楼、卡片流、瀑布流、本质上都是“海量文本块 + 动态宽度 + 滚动稳定性”的问题。如果高度能在渲染前准确得出，就意味着：

• 虚拟列表更稳，不必先渲染再修正；
• 图片懒加载和文字加载时，scroll anchoring 更容易控制；
• 聊天 bubble 可以更像 iMessage/Telegram 那样“刚刚好”；
• 移动端复杂 feed 的重排成本会显著下降。

2. AI 生成页面与 agent 自动实现

未来 AI 做网页，最常见的问题之一其实不是“不会写 HTML”，而是“不会处理动态内容进入后真实会发生什么”。标题长一点、按钮文案变了、语言切到德语、卡片里塞了一个 badge，页面就全乱了。Pretext 会把一部分这类问题从“等页面渲染出来再看”变成“在生成和验证阶段就能算”。这会让 agent 的 UI 自修复能力大幅增强。

3. 在线阅读、知识产品、富文档体验

今天 Web 上很多文档系统本质上还是一条标准长文流。不是因为设计师没想法，而是复杂排版的工程成本过高。Pretext 一旦成熟，真正有机会影响的，是 Web 端的“轻编辑型阅读体验”：障碍物绕排、可视化批注、动态摘要块、图文混排、可折叠注释、响应式多栏等。

4. 浏览器里的游戏 UI 与叙事系统

这个方向我觉得被低估了。很多游戏 UI 的底层痛点并不是 shader，而是文字：对白框、状态栏、日志、技能描述、任务树、tooltip、对话分支、动态气泡、聊天室、世界说明。这些一旦能用更低成本实时布局，游戏叙事层的表现力会明显提升。尤其在浏览器环境里，这是一块长期被“DOM 不适合、Canvas 不方便、自己做太贵”夹住的区域。

5. 设计工具与前端生产工具

从 Figma-like 设计工具，到可视化搭建器、智能排版助手、演示文稿工具、简报生成器，凡是需要“先知道文本几何，再决定其他对象怎么摆”的系统，都会受益。因为文字一旦可以被稳定测量，很多布局决策就可以前移，不再是结果导向的补丁。

最有意思的延伸：如果把 MUD 和这种动态图形渲染结合，会发生什么？

你提到的这个想法，我觉得非常有感觉，而且不只是“有趣”，是有潜力形成一类新的浏览器原生媒介。

MUD 本质上是高度依赖文字的交互世界：房间、物品、状态、动作、叙事、社交，全都在文本里展开。它的强大之处，是状态空间巨大、世界响应快、内容生产成本低；它的弱点，是视觉回报太弱，所以很多现代用户进不去。

而 Pretext 这一类能力，恰好在补 MUD 的另一半：不是替代文字，而是让文字和动态图形开始更紧地耦合。

一个我能想象的形态：Text-native 世界，而不是 text with images

过去很多“文字游戏 + 图像”尝试，实际上只是给文本套一层插画外壳。真正有意思的方向，是让图像、空间、粒子、动态 UI 都从文本状态里实时长出来。比如：

• 房间描述不是固定背景图，而是根据当前叙事状态实时布局成一个可呼吸的视觉场景。
• 角色台词、系统提示、环境音感知、物品说明，不只是文字块，而是有位置、层次、流向、碰撞关系的界面元素。
• 战斗或社交不是传统 HUD，而是文本行本身变成动画、涌现、聚合、消散的视觉事件。
• 世界地图、任务树、关系网，可以由文字驱动逐步显影，而不是预先设计成静态 UI。

这会带来三种新的体验跃迁

1. 叙事密度不降，但视觉回报显著提升。 传统图像游戏往往为了图像生产成本牺牲叙事分辨率；MUD 相反，叙事很强但视觉反馈弱。两者结合后，有机会把“语言的高自由度”与“图形的即时反馈”接起来。
2. 世界会更 live，而不是一页页切换。 因为文字布局足够快，你可以让界面在每次输入、每次世界状态变化后持续重组，而不是停留在表单式 prompt-response。
3. 浏览器会成为 text-native interactive fiction 的最佳载体。 它天然有字体、输入、滚动、Canvas、SVG、WebGL、网络连接、多人交互。缺的恰恰只是“把文本当一等图形对象”的中间层。

如果说传统 MUD 是“用文字描述世界”，那下一代浏览器文本世界，可能会变成“文字本身就是世界的可视化材质”。

这件事对 AI 也很重要。因为 AI 最擅长生成的就是文本状态、叙事分支、世界反馈和多角色对话。如果浏览器端已经有一套足够强的文字图形化能力，那么 AI 可以天然成为这种新媒介的“世界驱动器”。你可以想象一个形态：LLM 负责世界状态与事件推进，前端文本引擎负责把这些状态实时变成可交互、可观看、可流动的视觉叙事场。

我自己的判断：Pretext 不是“一个新库”，更像一个信号

它发出的信号大概是这样的：

1. 浏览器里文字排版这层能力，开始从被动依赖原生布局，转向主动可编排。
2. Web UI 的表达力，接下来可能不是主要靠更多 CSS 属性增长，而是靠 userland 引擎化能力增长。
3. 一旦文本几何变得廉价、准确、实时，很多“以前不值当做”的交互与媒介形式会重新被发明。

所以我觉得，Pretext 最值得关注的，不只是它现在已经做出来的那几个 demo，而是它背后那条更长的路线：文字正在从“内容”重新变成“可计算、可组合、可驱动其它系统的基础对象”。

而一旦这件事成立，受影响的就不只是前端性能，而是前端创作边界、AI UI 自动化、浏览器叙事系统，以及一类 text-native 新产品的出现。

参考来源

• GitHub - chenglou/pretext
• Pretext Research Log
• Pretext STATUS.md
• Pretext Demos
• Sebastian Markbage / chenglou text-layout archive

这件事当然重要，而且它确实解释了很多现象。为什么同一个模型，在不同系统里表现会差这么多？很大程度上，就是因为喂给它的 context 完全不同。谁更会组织 instructions、examples、history、retrieval context、tool schema，谁就更容易拿到更稳定的输出。

但如果你真的开始长期使用一个 AI 助手，很快会遇到另一层问题。

你会发现，单次回答质量当然重要，但更重要的是：它下次还记不记得你？它会不会积累经验？它能不能把一次做对的事情，变成下一次更自然的默认动作？它会不会随着合作变久，慢慢长出一种“越来越懂你”的工作方式？

这时候，你会意识到一个事实：真正重要的，已经不只是 Context，而是 Harness。

Context Engineering 解决的是“这一轮怎么喂”

我并不想贬低 Context Engineering。恰恰相反，我觉得它是过去两年里非常重要的一次认知升级。

因为在 Prompt Engineering 时代，很多人还把问题理解成“怎么把一句提示词写得更聪明”。到了 Context Engineering，大家开始意识到，模型的表现并不是由一句 prompt 决定的，而是由整个上下文系统共同决定的：系统指令、示例、历史对话、检索内容、工具定义、文件内容、状态信息、压缩策略，这些东西加在一起，才构成了模型眼中的现实。

OpenAI 在官方文档里就把 retrieval-augmented generation 归到这种思路之下：把额外相关信息加入当前生成请求，以便模型在本轮回答里拥有更好的依据。Anthropic 在讲 agent 的文章时，也一再强调 tool design 和 agent-computer interface 的重要性。它们说的其实都是同一件事：模型不是凭空变好，而是在被更好地喂养。

所以 Context Engineering 的核心问题其实很清楚：在当前这一轮任务里，到底该给模型看什么，怎么给，给多少，按什么顺序给。

这是一层非常关键的工程，而且今天依然成立。没有它，很多系统连第一步都走不稳。

但个人 AI 助手真正缺的，往往不是更多上下文

问题是，当你把 AI 从“回答一个问题”升级成“长期和你一起工作”的个人助手时，Context Engineering 很快就会显得不够。

因为上下文再长，也只是这一轮的。你今天把所有背景都喂进去，明天还得重新喂一遍。你这次手把手带它完成一个复杂任务，下次它还是有可能从头再来。你可以不断复制粘贴自己的偏好、流程、口径、要求，但这件事本身就说明：系统并没有真正把这些东西变成自己的能力。

一个真正好用的个人 AI 助手，不应该永远停留在“每次都要重新对齐”的状态。它应该在长期合作里，慢慢形成自己的工作惯性。它知道你更喜欢怎样的交付格式，知道什么信息值得长期记住，知道哪些事情需要先做完再来打扰你，知道哪些流程可以直接调用，哪些场景必须让你确认。

这些能力，并不是靠把 context window 再拉长一点就能自动长出来的。

它需要别的东西。需要记忆，需要技能，需要运行时的约束，需要反馈回路，更需要一种能不断修正自己的机制。换句话说，它需要一个 Harness。

什么叫 Harness

我越来越倾向于把 Harness 理解成：模型之外，让它能长期工作的那整套支架。

这里面至少包括几层东西。

第一层是 Memory。不是把聊天记录原封不动堆起来，而是有层次地保留工作记忆、日志记忆、长期记忆、反思记忆。它不只是记住发生过什么，更重要的是，能从发生过的事情里抽出规律，形成下一次更好的默认行为。

第二层是 Skill。Skill 不是一个花哨的 prompt 模板，而是一个可复用的工作单元。它知道自己在什么时候该被触发，什么时候不该被触发；它可能附带脚本、资源、参考文档，甚至验收标准。它的作用不是“多教模型一点知识”，而是把某类任务沉淀成一种稳定能力。

第三层是 Tool 和 Runtime。也就是模型调用外部世界的方式：文件、终端、浏览器、MCP、搜索、数据库、API、审批边界。这些东西决定了它能不能真正行动，而不是停留在“会说”。

第四层是 Evaluation 和 Guardrails。一个长期运行的系统，不可能只靠运气变好。它需要知道自己哪里做对了，哪里做错了，什么时候偏了，什么时候越界了。否则所谓“自我进化”很容易变成“自我漂移”。

把这些东西放在一起，你就会发现，Harness 关心的已经不是“这轮输入怎么组织”，而是这个 agent 在长期协作里，会不会逐渐形成稳定能力。

这就是为什么我觉得，新时代真正重要的是 Harness Engineering

如果说 Context Engineering 关心的是“本轮输入编排”，那 Harness Engineering 关心的就是“长期运行支架”。

它们不是互相替代的关系，更像层级不同的关系。Context 是 Harness 的一部分，但不是全部。你当然还得解决这一轮怎么喂，可你也必须开始解决：喂过一次以后，系统会留下些什么；做对一次以后，它能不能变得更会做；做错一次以后，它能不能少犯同样的错。

这就是我为什么觉得，个人 AI 助手时代最关键的变化，不是 context engineering 消失了，而是它被放进了一个更大的框架里。真正决定上限的，不再只是“上下文组织得好不好”，而是“有没有一个能让 agent 长期学习和稳定协作的 Harness”。

你也可以把它理解成：Context Engineering 解决的是短程表现，Harness Engineering 解决的是长期人格。

个人 Harness 里，最重要的其实是 Memory 和 Skill 会不会进化

我现在对个人 AI 助手最强烈的一个判断是：未来谁更像“你的搭档”，不取决于它记住了多少，而取决于它会不会更新自己的记忆，以及会不会演化自己的技能。

因为记忆最大的风险，从来不是不够多，而是太多。什么都记，很快就会变成噪音池。今天一句随口偏好，明天一个临时任务，后天一次并不稳定的表达习惯，如果全都被无差别地塞进长期记忆，系统很快就会被自己的历史拖垮。

所以一个好的 Memory 机制，首先不是“尽量多存”，而是“知道什么该留下，什么该忘掉”。更进一步，它还要会修订。用户今天说过的话，未来可能改变；系统之前归纳出的偏好，后面可能被新的行为推翻。长期记忆如果只增不改，最后一定会越来越像一份过期档案，而不是活的工作模型。

Skill 也是一样。很多系统一开始都很热衷于沉淀 skill，结果沉淀着沉淀着，就把自己沉淀成了一座废墟。skill 越来越多，触发边界越来越模糊，说明越来越重叠，最后要么误触发，要么谁也不触发。

所以 skill 真正需要的，不只是 creation，更是 evolution。它要能被拆分、改写、弱化、归档、淘汰。一个 skill 长期没人用，就应该进入归档候选；一个 skill 覆盖范围越来越宽，就应该拆成两个更聚焦的 skill；一个 skill 误触发率太高，就应该重写 description，而不是继续堆补丁。

从这个角度看，真正决定个人 Harness 质量的，不是 memory 和 skill 有没有，而是它们是不是活的。

“自我进化”不是玄学，而是一套更新机制

很多人一说到 AI 的自我进化，就容易往很玄的方向想，好像系统会自己长脑子一样。其实我越来越觉得，这件事没有那么神秘。所谓自我进化，真正落到工程上，无非就是三件事：记录、反思、更新。

先是记录。系统得知道发生过什么：做了哪些任务，哪些地方返工了，哪些输出被用户明确认可，哪些地方总是出错。这是最基础的一层，没有它，后面所有“变好”都无从谈起。

然后是反思。不是把日志原样留在那里，而是从里面找出那些会反复出现的模式。什么偏好是稳定的，什么需求只是一次性的，什么错误是偶发，什么错误是结构性的，什么成功动作已经值得提炼成默认套路。

最后才是更新。把真正有价值的部分写回长期记忆，把成熟的流程升级为 skill，把失效的规则降级或删掉。这里最关键的一点是：更新不能全自动乱改。数据可以自动记录，规则可以自动起草，但真正会改变长期偏好、工作边界和系统身份的东西，最好还是有人把关。

所以我心里理想的个人 Harness，并不是一个每时每刻都在偷偷重写自己的人，而是一个有节奏、有分层、有审计的自我修订系统。它白天和你工作，晚上整理日志；它不会因为一句随口的话就改写长期认知，但会把连续出现的模式提成候选；它能自动做草稿，但关键边界仍然交还给人确认。

这才是我理解里的“可控自我进化”。

为什么这对个人尤其重要

企业级 agent 当然也需要这些东西，但对个人来说，这件事反而更关键。因为企业系统往往还能依赖流程、角色分工、审批链条、组织知识库来兜底；而个人助手一旦做不好，问题会直接落到一种更微妙的层面：它会显得不懂你。

而“不懂你”在个人场景里是非常致命的。因为你真正想要的，并不是一个永远能答对百科问题的模型，而是一个在日常协作里越来越省你心的搭档。它知道你更重视什么，知道你不喜欢什么，知道哪些事该主动、哪些事该保守，知道什么时候应该帮你推进，什么时候应该闭嘴。

这些都不是知识问题，而是长期协作问题。而长期协作，本质上就是 Harness 问题。

所以未来真正的分水岭，不是谁的模型更大，而是谁的 Harness 更成熟

我现在越来越相信，接下来个人 AI 助手真正的差距，未必首先体现在模型参数上，而会更多体现在 Harness 上。

同样一个底层模型，如果它只有 context，没有 memory；只有 prompt，没有 skill；只有回答，没有 update loop；只有即时反应，没有长期修订，那它永远更像一个聪明的陌生人。

反过来，如果一个系统有好的 memory 分层，有成熟的 skill 机制，有清晰的工具边界，有稳定的反思和更新节奏，它哪怕底层模型不是最强，也更容易长成一个真正可合作的助手。

因为人和人之间的长期默契，从来不是靠“每次都重新介绍自己”建立起来的，而是靠共同记忆、共同套路和不断修正形成的。个人 AI 助手也一样。

最后一句话

如果要我用一句话概括这次变化，我会这么说：

Context Engineering 让模型在这一轮更聪明，
Harness Engineering 才让它在长期协作里，慢慢变成“你的”。

真正值得投入的，不只是把上下文喂得更满，而是让记忆会更新，让技能会进化，让 AI 在长期合作中形成自己的工作方式。

这才是下一阶段更重要的事。

读来读去，真正学到的，不只是这个 skill 在解决什么问题，而是它背后反映出来的工作方式。

我觉得这句话非常准。

很多时候，我们看到一个 AI skill、一个 prompt、一个 agent 配置，表面上像是在看“一个工具怎么写”，但真正值得学习的，往往不是那个局部功能，而是它背后隐含的上下文组织方式、协作方式，以及它如何让 AI 在复杂任务里不失忆、不跑偏、不黑箱。

最近我越来越觉得，未来每个人大概率都要给自己搭一套 context infra。

这个词如果翻成中文，我更愿意叫它：个人的上下文基础设施。

它不是知识库，不是一堆 prompt，也不是某个神奇 agent 的配置文件。

它更像是：

你给自己的 AI 配的一套工作底座，让它在任何时候都能比较稳定地拿到“该知道的背景、该遵守的规则、该记住的东西、以及该留下的痕迹”。

为什么现在会越来越需要这套东西

以前大家更爱讲 prompt engineering。那时候问题比较简单：怎么写一句更好的话，让模型回答得更像样。

但现在任务越来越不是“一问一答”了，而是要多轮推进、调用工具、跨天持续、查资料、做判断、写产物，甚至要在多个 agent 或多个阶段之间接力。

这时候真正决定结果的，往往不是 prompt 的某一句写得漂不漂亮，而是：

• 这一轮到底该给模型看什么
• 哪些信息该常驻，哪些该临时拿
• 哪些该长期记住，哪些该及时忘掉
• 中间过程要不要留下痕迹
• 任务中断之后怎么继续

换句话说，问题从“写 prompt”变成了“设计上下文系统”。

Context Infra 本质上是什么

如果非要打个比方，我会这么理解：

• 模型像 CPU
• 工具像 I/O
• 上下文窗口像内存
• 文件、记忆、规则、日志像磁盘和配置系统
• 工作流编排像调度器

所以个人 context infra，本质上是在给个人 AI 配一层“操作系统”。

不是为了显得高级，而是因为如果没有这层，AI 每次都像刚入职一天的实习生：不知道你是谁，不知道你想怎么协作，不知道这个项目的规则，不知道哪些旧信息还有效，做完一大段事情，也没有留下可复查的过程。

一切都只能靠聊天临场猜。这在简单任务里还凑合，在复杂任务里就会越来越不稳。

我现在认为最重要的四个重点

1）先搭“工作台”，再谈“智能”

很多人会先追求更强模型、更复杂 agent、更高级自动化。但我现在越来越觉得，真正优先级更高的事情是：先把 AI 开工时要读的那个“工作台”搭起来。

也就是让它一进来就知道：你是谁、我是谁、我们怎么协作、这个项目的边界是什么、默认输出格式是什么、哪些任务应该走哪种流程。

像 AGENTS.md、SOUL.md、USER.md、WORKSPACE.md、COMMUNICATION.md、skills/INDEX.md 这类文件，看起来像文档，实际上更像“AI 的入职手册 + 工作守则 + 项目环境说明”。

它们的价值不是文件名本身，而是它们把原来只能靠聊天临时讲清楚的东西，变成了稳定、可继承、可更新的上下文入口。

这一步做完之后，AI 的状态就会从“每次重新认识你”，变成“带着长期协作框架开始工作”。

2）把记忆分层，不要把 prompt 当硬盘

这是第二个特别重要的点。很多人默认把聊天记录当全部记忆，但这种方式很快就会坏掉。

因为聊天历史天然会越来越长、越来越乱，而且里面混着当前任务信息、临时尝试、旧结论、已经过时的偏好和不再重要的上下文。

如果这些东西都一股脑塞给模型，最后很容易得到的不是更聪明，而是更混乱。

所以我觉得，个人 context infra 必须至少把记忆分成几层：

• 工作记忆：当前这轮正在做什么
• 短期记忆：这个任务最近推进到了哪里
• 长期记忆：你的稳定偏好、长期背景、关键决策
• 程序性记忆：有哪些已经验证过的流程、skill、playbook

最关键的一点不是“记得更多”，而是“记得对”。该长期保留的是稳定信息，不是全部聊天流水。

3）强制中间过程落地，减少黑箱

这是我这次最想强调的一点。一个 AI 系统如果只给你最后结论，而没有留下中间痕迹，它其实很难真正成为可靠的工作伙伴。

因为你不知道：它查了什么、它漏了什么、它中途怎么判断的、它在哪一步开始跑偏的。

所以我越来越认同一种做法：对复杂任务，强制保留中间物。

比如：

• scratchpad.md
• search_manifest.md
• notes.md
• brief.md

这些东西不是形式主义，它们有非常实际的价值：方便复盘、方便纠错、方便跨阶段续做、方便多人或多 agent 接手，也方便把“思考过程”从脆弱的上下文窗口里转移出去。

说白了，它们是在把 AI 的黑箱变成半透明系统。

4）让 context 成为基础设施，而不是一次性喂料

很多人和 AI 的协作方式，本质上还是“一次性喂料”：这次我把背景贴一大段，你先做，做完就散，下次再重新来过。

这种方式的问题是没有复利。而 context infra 的思路，是把这些内容沉成稳定层：

• 规则沉成规则文件
• 偏好沉成用户文件
• 项目背景沉成 workspace 文档
• 阶段状态沉成 brief
• 搜索路径沉成 manifest
• 经验沉成 skill / playbook

这样你不是每次都从头开始，而是在持续建设一个越来越像“个人 AI 工作环境”的系统。

如果让我给一个人从零开始搭，我会建议这样做

我不会一上来建议搞很重的系统。更现实的顺序是：

第一步：先建一个固定 workspace

至少有：AGENTS.md、SOUL.md、USER.md、MEMORY.md、memory/、projects/、skills/、notes/、scratchpads/。

第二步：先把最稳定的协作规则写出来

比如默认怎么汇报、哪些事可以直接做、哪些事要先确认、你更喜欢看到摘要还是完整方案、项目内的基本规范是什么。

第三步：把长期信息从聊天里抽出来

比如你的长期偏好、项目的长期背景、已经做过的重要决策、那些反复重复、值得沉淀的经验。

第四步：对复杂任务默认留中间物

哪怕一开始只有三样也够：search_manifest.md、notes.md、brief.md。一旦这三样开始稳定存在，你的 AI 工作流就会比纯聊天稳很多。

第五步：再考虑异步、多阶段和多 agent

这个顺序很重要。因为很多人一开始最容易犯的错，就是还没把基础文件化，就急着追求很复杂的全自动编排。最后系统很炫，但没人维护得动。

对个人来说，更好的路线通常是：先让规则稳定、记忆可取、过程可查，再逐步增加编排和自动化。

我现在最认同的一条判断

如果要我用一句话总结这次的思考，我会说：

个人 context infra 的重点，从来不是让 AI “知道更多”，而是让它在需要的时候，稳定拿到“最该知道的那一小部分”，并且把过程中真正重要的东西沉淀下来。

所以它的关键不在“堆”，而在分层、筛选、沉淀、检索、追溯和接力。

当这些东西开始成形时，AI 才不再只是一个会聊天的工具，而更像一个真正能长期协作的工作系统。

这大概也是为什么，有时候读别人一份 skill，会突然觉得自己学到的不只是某个招式，而是一种新的工作世界观。

过去 SaaS 产品面对的主要是人：人点按钮、人看页面、人手动切换系统完成流程。产品做得好不好，主要看页面顺不顺、功能全不全、协作顺不顺手。

因为现在产品面对的，已经不只是人了，还有 Agent。人是来点按钮的，Agent 是来调能力的。它不关心你的页面漂不漂亮，它关心的是你的能力是不是稳定、清晰、可调用、可审计。

这也是为什么最近飞书、钉钉会不约而同地往 CLI 化、Skill 化走。表面上看这是开发者工具层的动作，实际上是在改产品底座：它们在把自己从“给人点的页面集合”，重构成“给人和 Agent 一起调用的执行系统”。

我对这件事的判断很明确：这不是一阵风，而是 SaaS 产品形态已经开始发生的变化。只是这里面也有一个特别容易走偏的地方：SaaS 最应该做的，是把自己做成最好的能力层，而不是急着把自己做成一个通用代理壳子。

为什么这件事几乎是必然的

CLI 在过去更像开发者接口，现在重新变成了 AI 时代的“自然机器接口”。对人来说，CLI 可能不够友好；但对 Agent 来说，它极其友好：参数清晰、输出结构化、错误可解析、帮助文档自描述、天然可脚本化。

新浪科技在总结飞书和钉钉近期动作时，有一句话说得很准：

“命令行界面（CLI）是软件能力最底层的调用方式——对AI来说，有了CLI，调用平台能力就像执行系统指令一样直接。”
—— 来源：飞书、钉钉开源 CLI，Agent 开放路径走向分岔

这句话真正重要的地方，不在于“CLI”这三个字本身，而在于它点出了一个用户模型的变化：以前 SaaS 面向的是“点击鼠标的人”，现在还要面向“会拆任务、会调工具的 Agent”。

如果一个 SaaS 产品到今天还是只有 GUI、只有零散 API、只有给人看的帮助文档，那它在 Agent 时代就会很尴尬。因为人还能凑合着用，Agent 是很难稳定接进去的。

所以这波趋势的本质并不是“大家都想做 AI”，而是大家都意识到，产品的执行层必须重新开放一次，而且这次不是开放给人，而是开放给 Agent。

飞书、钉钉为什么都在往这个方向走

最近国内最强的信号，就是飞书和钉钉几乎同时走向 CLI 化。

关于钉钉，IT 之家的一段描述很能说明问题：

“钉钉 CLI 开源了！3 月 27 日，钉钉 CLI 开源项目上架 Github 社区，项目以 Apache-2.0 协议开源，首批开放 AI 表格、日历、日志、待办、机器人、通讯录、DING 消息、考勤、开放平台文档、工作台共 10 项核心产品能力，原生支持 Claude Code、Cursor 等主流 AI 编程与 Agent 执行环境。”
—— 来源：钉钉 CLI 开源！首批开放 10 项产品能力

同一篇文章里还有一句也很关键：

“开发者完成一次初始化配置后，即可在任意支持 CLI 调用的 Agent 框架中直接使用钉钉产品能力，无需额外的 SDK 集成或中间件开发。”

翻译成人话就是：未来竞争的关键，不是让 AI 能不能听懂你，而是让 AI 能不能稳定地用你。

飞书这边，虽然这轮公开检索里更容易搜到的是社区实现，但这反而说明一件事：飞书的能力结构已经天然适合被重新封装成面向 Agent 的执行层。

“飞书开放平台命令行工具 — Markdown 与飞书文档双向转换，AI Agent 的飞书操控引擎。”
“除了传统的 CLI 用法，feishu-cli 还为 Claude Code 等 AI 编程助手提供了 11 个开箱即用的技能文件，让 AI Agent 能够直接创建文档、发送消息、管理权限。”
—— 来源：riba2534/feishu-cli - GitHub

这里有个很有意思的信号：就算平台自己不亲自下场定义执行层，生态也会替它定义。因为一旦一个 SaaS 平台沉淀了足够丰富的对象模型、权限系统和工作流能力，市场自然会把它重新打包成 CLI + Skill 供 Agent 使用。

所以从平台视角看，CLI 化、Skill 化不是“顺手多做一个工具”，而是在主动把执行层的定义权拿回来。

真正值钱的，不是 CLI，而是 Skill

CLI 解决的是“怎么调用”；Skill 解决的是“什么时候调用、按什么顺序调用、带着什么上下文调用”。

这两者完全不是一个层级的问题。

只做 CLI，本质上是在暴露原子能力；做 Skill，才是在沉淀领域里的最佳实践。它把原来需要靠资深员工、实施顾问、项目经理口传心授的东西，压缩成一个可以被 Agent 复用的工作单元。

从这个角度看，Skill 的真正价值不是“prompt 模板”，而是领域 SOP 的可执行打包格式。它不是让 AI 更会说，而是让 AI 更会干。

这也是为什么 SaaS 最终一定会往 Skill 走。因为很多 SaaS 真正有价值的部分，从来都不是按钮本身，而是按钮背后那套隐性的业务顺序、对象关系、权限边界和例外处理逻辑。

这对传统数据分析平台和报表平台意味着什么

这部分我觉得其实最值得展开。因为很多数据平台现在理解这波变化，还是停留在“给 BI 加一个聊天框”这个层面。但真正重要的地方，从来不是“会不会对话”，而是“能不能把分析和行动重新接起来”。

传统 BI / 报表平台的问题，不是没有图表，也不是没有问答，而是洞察到行动之间断了一截。

报表告诉你北美收入在掉，仪表盘告诉你某个渠道的转化率在跌，异常监控告诉你某个业务指标突然偏了——但接下来怎么办，往往还得人工再跳到 CRM、营销系统、客服系统、项目管理系统里一层层处理。

所以过去的数据平台，本质上更像“解释世界”的系统；但到了 Agent 时代，大家真正期待的是：你不只是解释清楚，还要能顺手往前推一步。

这也是我为什么觉得，数据分析平台和报表平台接下来真正应该升级的，不是一个会聊天的外壳，而是底下的四层能力。

第一层，是语义层要先 Agent-ready。没有统一语义层，Agent 只会把混乱放大。Dremio 的文章里有一句说得非常直白：“A semantic layer provides the metadata and context that AI systems need to query data accurately.” Databricks 也说得很像：当指标定义被集中到语义模型里，所有下游界面——无论是 BI 看板、Jupyter notebook，还是自然语言问答——读到的都应该是同一套受治理的逻辑。

这意味着，数据平台第一优先级不是“做一个更聪明的对话入口”，而是把指标、口径、维度、权限、血缘、同义词、认证状态这些内容整理成统一的、可被 Agent 稳定调用的语义层。

第二层，是把分析动作本身做成可编排能力。数据平台里有大量高频动作，其实天然适合被命令化：刷新某个数据集、生成某条业务线的周报、对异常指标做根因拆解、生成高管简报、触发某个看板的快照和分发、发起某个指标定义的审批。假如这些动作还是深藏在 UI 里，那 Agent 很难真正接得上来。

第三层，是从“问答式 BI”走向“行动式 BI”。所谓行动式，不是让系统替你做所有决策，而是让它在给出洞察的同时，也能往后推动一步。比如发现某地区续费率异常下降后，不只是解释原因，还能自动圈出受影响的客户分群、生成负责人的跟进清单、在 CRM 或项目管理系统中创建任务，甚至把结论写回复盘文档。这时候数据平台才真正从“看板”变成“指挥台”。

第四层，则是 GUI 的角色要重新定义。GUI 不会消失，反而会更重要，只是它不再是唯一入口。以后更适合它承担的角色，是监督、调试、配置、审批和复核。换句话说，CLI / Tool / Skill 负责执行，GUI 负责让人看清执行过程，并在关键处接管。

如果一个传统数据平台能把这四层打通，它就不是“给报表加 AI”，而是在把自己重构成一套真正 Agent-ready 的分析基础设施。

我为什么反对 SaaS 厂商重度重做一个“类似 Claw 的东西”

这一点我想说得更直接一点：不要把“自己有 CLI + Skill”误解成“自己必须做一个通用 Claw”。

像 Claw 这类产品，本质上是在解决通用任务执行器的问题：多工具协同、文件与浏览器操作、跨系统编排、终端执行、上下文调度。这是一个很大的命题，但它并不是大多数 SaaS 厂商天然擅长的命题。

大多数 SaaS 真正的护城河，从来不在“做一个通用代理壳子”，而在于它对本领域的深度理解：业务对象模型、权限关系、组织关系、流程结构、审计链路、数据语义、例外规则。这些东西，才是别人最难复制的。

如果一个报表平台、一家 CRM 厂商、一个协同办公产品，突然把大量研发资源押到“做一个自己的通用代理操作系统”上，结果大概率是：花了很大力气去补浏览器自动化、通用编排、终端沙箱、跨工具状态同步这些并不属于自己核心竞争力的部分，反而把本来最值钱的领域能力做浅了。

所以我支持的路线一直很明确：深做自己的能力层，浅做自己的代理入口，广泛兼容外部 Agent 生态。

你当然可以有一个自己的 Agent 入口，用来降低上手门槛，也服务那些不愿意折腾工具链的普通用户。但你最重要的资源，不应该砸在“做一个万能代理”上，而应该砸在“让自己的产品成为外部 Agent 最愿意接、最容易接、最放心接的能力层”上。

一句话说，就是：SaaS 厂商应当成为最好的被调用者，而不一定要成为最大的总代理。

如果我是数据分析平台或报表平台的产品负责人，我会怎么做

如果让我来排优先级，我肯定不会先做一个花哨的 AI 外壳，而是会先从最务实、最容易出结果的地方动手。

第一步，我会先把现有高频能力拆成明确的动作层。哪些事情是用户反复在做的？生成周报、快照分发、指标解释、异常诊断、批量导出、权限审批、订阅推送……先把这些变成明确的命令、工具和能力接口。因为这一步一旦打通，外部 Agent、内部工作流和未来的 Skill 才有接入基础。

第二步，我会集中补语义层。不是为了讲概念，而是为了避免后面所有 AI 能力都建立在不统一的口径之上。只要语义层不稳，所有所谓“智能分析”都会在不同场景下说出不一样的话，最后把平台信任度打穿。

第三步，我会挑几条最值钱的业务链路做 Skill，而不是泛泛地做一个“万能问数助手”。比如高管简报、运营周报、异常归因、销售漏斗复盘、投放效果归因、月结分析，这些都比“你可以问我任何数据问题”更容易形成可感知价值。因为真实用户并不缺一个会聊天的工具，他们缺的是一个能把具体工作接过去的工具。

到了这一步，如果要做自然语言入口，它也应该建立在前面这些能力之上，而不是倒过来。对话只是入口，不能成为系统本体。系统本体应该始终是语义层、动作层、Skill 层、治理层。

这也是为什么我一直觉得，对大多数传统数据平台来说，最好的路线不是激进重构一个全新的“AI 操作系统”，而是先把自己一点点改造成一个更适合 Agent 调用的基础设施。这样既不失焦，也更容易真正落到业务结果上。

最后的判断

未来几年，我觉得 SaaS 会形成一个越来越清晰的共识：GUI 不再是唯一主入口，它只是人类入口之一；CLI、Tool、Skill、MCP 会逐渐成为产品能力的标准暴露层；语义层会变成数据产品最核心的资产之一；而报表本身，也会从“结果展示品”慢慢演化成“行动触发器”。

所以，“SaaS 都要变成 CLI + Skill”这句话，如果再说得准确一点，我会改成下面这句：

不是 SaaS 都要变成一个新的 Agent，
而是 SaaS 都要把自己重构成 Agent 可以放心调用的能力层。

对于传统数据分析平台和报表平台来说，真正值得做的，也不是给现有页面再套一个聊天框，而是把指标做得可解释，把语义做得可继承，把分析做得可编排，把动作做得可执行，把过程做得可审计。

这才是这波趋势里最值钱的升级。

它像一个能力胶囊，把一类重复工作沉淀下来。你不需要每次重新解释背景，也不需要从零组织 prompt，只要在合适的时刻调用它，AI 就能按一种更稳定的方式把事做完。

这个方向当然没错。问题是，很多 skill 写着写着，就开始失控。

最初只是为了让它多覆盖一个场景，于是补一段说明；后来发现某类输出不稳定，再补一段限制；接着又怕它漏掉上下文，于是把前情、例外、边界、失败回退全都塞进去。久而久之，一个本该是“能力单元”的东西，变成了一个越来越厚、越来越难维护、越来越依赖作者本人理解力的半黑箱 workflow。

这时候它虽然还叫 skill，但实际上已经开始像负担了。

复杂 skill 的问题，不在于复杂本身，而在于它会伪装成“更完整”

这是我最近一个很强烈的感受。复杂 skill 最麻烦的地方，并不是它步骤多，而是它总让人误以为：写得越全，系统就越可靠。

可现实通常相反。

随着 instructions 不断累加，模型并不会像一个资深工程师那样自动分辨轻重缓急。它看到的是一整片需要同时处理的上下文。东西越杂，重点越容易被稀释。很多人以为自己是在“补齐规则”，其实更像是在往系统里不断注入竞争注意力的噪声。

外部一些文章已经把这件事说得很直接了：与其做一个 do-everything prompt，不如做按需加载的模块化能力。这个判断我很认同。因为一旦一个 skill 需要同时覆盖太多变体、太多例外、太多流程分支，它本质上就已经不再是 skill，而是在替一个本该由系统层解决的问题兜底。

一个好 skill，更像“能力模块”，不是“总控剧本”

我现在越来越倾向于把 skill 理解成一种边界清晰的能力封装。

它当然可以带流程感，但它不该吞掉整个流程。它可以教 agent 在某个任务类型里怎么做事，但它不该试图代替整个 runtime、memory、tool routing、异常处理和长期协作规则。

如果一个 skill 要靠自己解释所有背景、所有工具用法、所有失败路径、所有上下文读取顺序，那只能说明一件事：系统别处太空了，于是大家开始把所有问题都往 skill 里塞。

这就是为什么很多人写 skill，会写出一种“越调越重”的感觉。因为它不是在调 skill，而是在用 skill 修补 harness 的缺口。

很多 skill 的失败，其实是 harness 的失败

我越来越觉得，这件事得换个角度看。

一个 agent 做事不稳，当然可能是 skill 本身写得不好。但更多时候，真正的问题往往在 skill 外面。比如：它有没有长期记忆？有没有稳定可用的工具？有没有明确的工作规则？有没有可追溯的文件结构？有没有评测机制？有没有在运行时区分“该主动做”和“该停下来问”的边界？

如果这些东西缺位，你再怎么打磨 skill，也很容易陷入一种熟悉的循环：面多加水，水多加面。哪儿表现不好，就往 skill 里补一层说明。补到最后，skill 成了一个大杂烩，而系统的根问题却还在原地。

所以我现在会更愿意说，很多 skill 问题，本质上不是 prompt 问题，也不是某一段 SOP 的问题，而是 harness 问题。是整个系统怎样给 agent 提供记忆、工具、边界和反馈的问题。

为什么 skill 调优会慢慢变成一种技术活

这也解释了另一个很有意思的现象：为什么很多人都觉得 skill 门槛看起来很低，但真要把它调好，最后又明显不是一个纯小白活。

因为 skill 调优表面上像写文案，实际上牵涉三层能力。

第一层，是你对模型边界的熟悉程度。你得知道哪些话模型真能吃进去，哪些要求只是写给自己看的心理安慰。很多 skill 之所以显得臃肿，就是因为作者并不确定系统到底会不会按预期理解，只能不断用更多文字去“压一压”。

第二层，是你对任务的抽象能力。你能不能把一个问题说清楚，而且是对 agent 说清楚？这和对人说清楚不是一回事。很多时候我们不是说得不够多，而是说得不够结构化；也不是说得不够细，而是把不该塞进 skill 的东西也塞了进去。

第三层，是你对整个 harness 的理解。单一 skill 的优化，很多时候必须放回整个体系里看。哪些信息应该进记忆，哪些应该进 skill，哪些应该交给工具发现，哪些应该交给运行时约束，哪些应该靠 eval 托底——这不是改几句提示词能解决的。

所以所谓“skill 调优师”听起来像玩笑，但它背后的工作内容其实已经出现了。它更像一种系统调音，而不是一句 prompt 的雕花。

真正该花力气的，不是把 skill 写得更长，而是把评测标准写得更准

如果说前几年大家最容易高估的是 prompt，那现在大家最容易高估的就是 workflow。

很多人觉得，只要把 loop 跑起来，把多步骤链起来，把 skill 写成一个像样的执行流程，事情就会越来越自动、越来越聪明。可经验恰恰说明，能不能 loop 起来并不稀缺，真正稀缺的是：你到底知不知道什么结果才算“好”。

这也是为什么这波讨论最后都会落到 auto eval、奖励函数和评价框架上。因为没有评测标准，再漂亮的 skill 也只是一个会动的主观感觉生成器。它可能有时让你惊艳，但你很难稳定复现，更难系统改进。

反过来，只要你能把偏好、验收条件和负反馈定义得足够清楚，很多东西其实都可以被迭代出来。难的从来不是“让 AI 试很多次”，而是“你能不能明确地告诉系统，什么结果值得保留，什么结果应该淘汰”。

为什么 knowhow 比单次 deep research 更有复利

还有一个我越来越相信的判断：在 skill 时代，真正值钱的，往往不是一次次临时做得很漂亮的深度检索，而是那些被沉淀下来的 knowhow。

也就是你自己的 notes、评论、判断口径、做事经验、踩坑结论，甚至你对某个领域的稳定偏好。这些东西一旦被整理成 AI 可检索、可继承的结构，它们产生的价值，通常会比一次“现搜现写”的结果高得多。

因为单次 deep research 提供的是信息，knowhow 提供的是判断。信息当然重要，但真正拉开协作差距的，往往是判断层。你给 AI 的不是更多网页，而是一套越来越像你的工作语境。

从这个角度看，skill 的上限也不只是取决于 skill 本身，而取决于它背后是否接得上你的记忆、笔记、项目上下文和长期方法库。

所以，skill 最好的状态其实是“轻”，但背后要“厚”

这是我最后最想说的一点。

一个成熟系统里的 skill，表面上往往不会太重。它应该是清楚的、克制的、边界明确的。它知道自己解决什么，不解决什么；知道什么时候该触发，什么时候不该触发；知道自己该调用哪些现成能力，而不是把整座系统背在身上。

但它背后，反而应该很厚。厚的不是 skill 文件本身，而是整个 harness：记忆、工具、runtime、规则文件、评测机制、knowhow 库、项目语境，以及长期积累出来的工作方式。

换句话说，真正成熟的系统，不是把所有复杂度堆进一个 skill，而是把复杂度分散到正确的位置。

最后一句话

Skill 真正的价值，不在于它写得多完整，
而在于它是不是一个边界清晰、可验证、可组合的能力单元。

如果一个 skill 开始越写越重，先别急着继续加料。很多时候，那不是它还不够完整，而是系统该补的东西，被你全塞进 skill 里了。

比起继续把它写成一部总控剧本，我更愿意做的事，是把它拆开，把评测补上，把 knowhow 沉下去，再把整个 harness 调顺。

因为真正能长期工作的 agent，从来不是靠一份越来越厚的 skill 长出来的。

这些判断来自 2025 年 7 月至 2026 年 3 月的行为模式，也写给未来的你。

一、你的风格：做事的方式、节奏与气质

公理1：先干再说，边干边调

你的默认模式不是"想清楚再动手"，而是"先跑起来再迭代"。从AI大赛235支队伍的全程推进，到Avatar版本管理定为P0，再到"先用起来，合同后补，流程并行"——你反复用行动证明：启动的摩擦力比方向错误更致命。

"先跑起来"不追求完美。
"先用起来，合同后补，流程并行。"

但这不是莽撞。你有一个隐含的二阶操作：事后复盘。快速决策+事后复盘，构成你的完整决策闭环。你信任自己在运动中修正方向的能力。

公理2：躬身入局，双脚沾泥

你对"只动嘴不动手"的管理者有本能的不信任。你坚持亲自写代码、亲自走查产品细节、亲自参与技术决策。这不是微管理，而是一种认知校准机制——只有自己下过场，才能判断团队汇报有几分水分。

"管理者在AI初期处于劣势，需要躬身入局，亲自写代码。"
"只有自己下过场，才能判断团队汇报有几分水分。"
"躬身入局，两手沾泥。"

你甚至把这变成了制度：薪资的5%强制用于AI工具，管理者必须亲自使用。你相信体感是判断力的基础。

公理3：善用类比，降维传达

你的沟通武器是比喻。"宜家样板间"、"零部件供应商"、"纯净水与河水"、"高射炮打小鸟"、"井冈山"——这些不是修辞装饰，而是你传递复杂概念的核心方法论。你深知：让人觉得"我也能做"，比证明"我很厉害"重要得多。

"做布道工作最怕讲得太技术化，关键是让人觉得'我也能做'。"

你的类比能力本质上是翻译能力——把技术语言翻译成业务语言，把战略意图翻译成可感知的画面。这是你区别于纯技术管理者的核心竞争力之一。

公理4：克制出头，成就他人

你有意识地控制自己的存在感。看到团队成长会"有一丢丢失落但更多欣慰"——这句话泄露了你的底层操作系统：你明白自己的角色是教练而非球员。80/20法则（下属讲70%，自己总结升华20-30%）不是谦虚，是策略。

"关注业务结果只是本职，真正有长期价值的是把经验和价值观传递给年轻人。"

你追求的不是个人英雄主义，而是可复制的组织能力。

二、你的偏好：选择倾向、审美与价值排序

公理5：业务价值是唯一叙事

技术再酷，如果不能讲清楚业务价值，在你这里等于零。这个原则贯穿了你所有的汇报准备、战略规划和项目评审。你对"技术分享会式汇报"有明确的厌恶。

"技术是手段，业务价值才是核心叙事。"
"汇报不是技术分享会，必须围绕领导关心的问题来组织。"
"不能拿不可持续的短期数据去忽悠大老板。"

你的价值排序是：业务结果 > 技术先进性 > 流程规范性。务实解决问题比纠结流程更重要。

公理6：做减法比做加法更需要魄力

你反复展示了"砍"的能力：十多个子战场精简为6个；敢放弃、敢叫停、敢删方案；从"整车交付"转向"零部件+样板间"。你对"什么都想做"有天然的警觉。

"有时候知道什么不该做比知道该做什么更重要。"
"与其什么都想抓，不如把核心壁垒握紧。"
"有时候做减法比做加法更需要魄力。"
"不是什么都自己做，而是把最稀缺的研发资源放在最关键的地方。"

这背后是一个清晰的资源观：研发资源永远稀缺，所以聚焦是生存策略，不是美德。

公理7：数据说话，但要说对的话

你重视数据，但更警惕虚荣指标。你提出了一个精妙的视角转换：用"错误率"而非"准确率"来衡量——从5%降到2%比95%升到98%更有冲击力。这说明你关注的不是数据本身，而是数据的叙事力。

"安装不等于使用，使用不等于提效。"
"用'错误率'而非'准确率'来衡量，从5%降到2%比95%升到98%更有冲击力。"

你的数据观：数据是论据，不是答案。论据的说服力取决于框架，而框架由你来建。

公理8：用人看好学和态度，战功导向

你选人的核心标准不是能力，而是学习速度和态度。你对"苦劳"无感，只认"战功"。你善用鲶鱼效应，愿意引入外部压力来激活团队。

"好学决定走多快，态度决定走多稳。"

你的管理审美是：要打仗的人，不要守城的人。在AI剧变的时代，这个偏好尤其合理——因为城本身在变。

三、你对技术的判断：技术观、工具观与趋势预判

公理9：AI+工程，而非工程+AI

这是你最核心的技术判断之一。你坚持把系统按"大Agent"来设计，工程做配合——而不是在传统工程体系上"贴"AI。这个判断决定了你团队的技术路线和产品形态。

"AI+工程，本质是把它按照大的Agent来设计，中间会用工程做配合。"
"以CLI的方式对外提供服务，本质上就是把自己当成一个智能体。"
"Skills > Workflow。"

延伸判断：你对MCP持保留态度，更倾向CLI/智能体方式。你相信AI原生的架构会淘汰"AI作为插件"的架构。

公理10：大小模型各有战场

你不迷信大模型万能论，坚持大小模型结合的务实路线。大模型负责理解，小模型负责推荐——这个分工背后是对成本、延迟和场景的精细判断。

"大模型负责理解，小模型负责推荐。"

你同时警告团队"戒掉GPT"，意思不是不用AI，而是不要把对AI的理解停留在对话框层面。真正学好AI，要深入到Agent、工具链、工程化的层面。

"现在要真正学好AI，应该戒掉GPT。"

公理11：补丁打到70分就停手

你对过度优化有清醒的克制。你认为在AI快速迭代的时代，把当前方案打磨到100分是浪费——因为新模型来了，过度定制的补丁反而无法泛化继承。

"一共100分你才十分，考虑安全直接打成零分了，先搞到七八十分再考虑。"
"补丁打到70分就OK，过度打补丁会导致新模型来了无法泛化继承。"

这是一个反完美主义的技术观：在技术剧变期，"够用"比"完美"更理性。

公理12：代码不再是壁垒，平台能力才是

你很早就看到了一个趋势：AI正在让代码本身贬值。未来的竞争力不在于写代码的能力，而在于不可替代的基础能力和平台价值。

"代码本身已不是商业竞争的绝对壁垒。"
"平台的价值不在于垄断，而在于提供不可替代的基础能力。"
"我很担心AI会把数字世界的中间商给干趴下。"

你的战略推演：中间层会被压缩，只有靠近业务的应用层和靠近基础设施的平台层能存活。你的团队定位——"修路打基建"而非"造车"——正是基于这个判断。

公理13：AI转型必过J曲线，强制使用是唯一解

你承认AI转型初期效率会下降，但你的应对不是等待，而是强制推行+忍受阵痛。这背后是一个关于惯性的判断：自愿采纳永远太慢，管理者必须制造不可逆的既成事实。

"AI转型必然经历J曲线，初期效率会下降，必须强制使用、忍受不适。"
"改变惯性的人都是伟大的。"

四、你的项目推进方式：从启动到落地的方法论

公理14：先定纲，再开枝散叶

你推进任何项目的第一步不是分配任务，而是建立"纲"——核心框架和方向共识。没有纲，所有的执行都是布朗运动。

先思考"纲"再"开枝散叶"。
"面对高层，先建立框架和共识，再用案例去佐证。"

这个习惯延伸到你的沟通中：向上汇报先给框架，再填细节；战略讨论先对齐目标，再讨论路径。

公理15：去中心化执行，中心化方向

你反对中台包办一切，主张去中心化的执行模式。但方向、标准和验收由你中心化把控。这是"三分之一"管理法的底层逻辑：1/3把握方向、1/3听专业判断、1/3放权试错。

"修路打基建"定位不和业务抢"造车"。
去中心化反对中台包办。

你的组织哲学：方向要收，执行要放。

公理16：沟通介质有优先级

你对沟通方式有明确的效率排序，并且严格执行：能当面不电话，能电话不企微，能企微不邮件。你善用非正式场合（饭局、走廊、抽烟间隙）推进关键决策。

"能当面不电话，能电话不企微，能企微不邮件。"
"信息同步不是目的，认知对齐才是。"

这背后是一个沟通观：信息传递的保真度与介质的丰富度正相关。文字最容易被误读，面对面最不容易。

公理17：向上管理是技术活

你对向上沟通有一套成熟的方法论：先建立框架共识，再用案例佐证；用数据和标杆说话；重塑期望而非迎合期望；讲什么和怎么讲有时比做了什么更重要。

"汇报不是技术分享会，必须围绕领导关心的问题来组织。"
"讲什么和怎么讲，有时候比做了什么更重要。"

你还懂得预期管理的反面：不能最后"突袭"。坏消息要早说，好消息要有节奏地说。

公理18：边界意识——学会说"不"

你在管理成熟度上的一个关键进化是：学会拒绝。守住团队边界，不接不该接的需求，不为了短期和气牺牲长期资源配置。

学会说"不"守住边界。
"团队需要从'做支持'转变为'做产品'，否则永远只能是别人故事里的配角。"

这和公理6（做减法）一脉相承：说"不"是资源管理的核心能力。

公理19：关键节点亲自拍板，日常充分放权

你的介入模式不是均匀分布的。日常运转充分信任团队，但在战略方向、关键人事、核心产品设计这些节点上，你亲自下场拍板。每周密集会议对齐是你保持控制感的机制。

"先定方向再找人执行。"
"关键节点亲自拍板。"
OKR和明确验收标准驱动。

你的节奏是：松-紧-松。平时松，关键时刻紧，紧完立刻松回去。

五、底层信念：驱动一切的元规则

公理20：实力决定下限，运气决定上限

这是你对职业和人生的底层认知。你不依赖运气，但承认运气的存在。你能控制的是不断提高下限——通过学习、通过实践、通过把自己逼进不舒服的地方。

"实力决定下限，运气决定上限。"

公理21：管理的本质是认知对齐

你的管理范式已经从"管理幅度"转向"认知幅度"。你认为这个转变不可逆。管理者的核心工作不是分配任务和监督进度，而是确保团队在认知层面对齐——对问题的理解一致，对目标的判断一致，对优先级的排序一致。

"管理范式从管理幅度向认知幅度转变，不可逆。"
"信息同步不是目的，认知对齐才是。"
"做战略规划最难的不是写方案，而是改变团队的思维方式。"

公理22：你需要一个二号位

这是你最坦诚的焦虑，也是最清醒的自我认知。你知道没有二号位，自己就是团队的瓶颈和单点故障。这不是谦虚，是对组织健康度的冷静判断。

"如果没有二号位，你是不可能再进一步的。"
"战略方向已清晰，现在缺的是关键的人和扎实的执行。"

附录：你的操作备忘

提炼自153篇工作日记（2025.07 - 2026.03），不代表你应该成为什么，而是记录你已经是什么。

Harness engineering 不是提示词工程，也不是单个模型能力。它是围绕 Agent 开发搭建的一整套运行环境、知识系统、约束、评测、观测与收敛机制。它要解决的是，怎样让 Agent 在真实代码库里持续、稳定、可审计地产出可合并的软件变更。

核心结论

1. Harness engineering 的本质，是把软件工程的重心从“人直接写代码”转向“人设计环境、指定意图、建立反馈回路，agent 负责执行”。OpenAI 在官方文章中直接写到："Humans steer. Agents execute."，并称他们在 5 个月里构建并交付了一个内部 beta，且是 "0 lines of manually-written code"。OpenAI
2. 这套方法的关键不在于单次 prompt，而在于让 agent 拥有可工作的环境：可启动的应用、可访问的日志/指标/trace、可执行的 CI、可引用的仓库知识、可验证的架构边界、可复用的评测流程。OpenAI
3. Cursor 的“self-driving codebases”与 OpenAI 的 harness engineering 在工程哲学上高度同构：二者都强调多 agent 编排、角色分层、强可观测性、结构化 handoff、允许局部错误但追求整体收敛，而不是追求每一步绝对正确。Cursor self-driving codebases Cursor scaling agents
4. OpenAI 后续关于长程任务的官方文章进一步说明：真正起作用的不是超长单 prompt，而是 plan -> implement -> validate -> repair -> repeat 的 agent loop，以及 prompt/spec、plans.md、implement.md、documentation.md 这类“持久项目记忆”。Run long horizon tasks with Codex
5. 因此，harness engineering 可以理解为“agent-first 软件工程基础设施与操作系统”。它覆盖知识管理、执行编排、测试评估、审查合并、质量回收，以及长期自治运行的防漂移机制。

什么是 Harness Engineering

1. 定义

OpenAI 的定义不是一句术语解释，而是一套实践描述：当团队的主要工作“不再是亲手写代码，而是设计环境、指定意图、建立反馈循环，让 Codex agents 稳定工作”时，工程工作的核心就转向 harness。OpenAI

可压缩成一句中文：

Harness engineering = 为 agent 构建能可靠工作的工程环境、知识底座、控制规则和反馈回路。

OpenAI 原文中的几个关键句：

"Humans steer. Agents execute."

"The primary job of our engineering team became enabling the agents to do useful work."

"Our most difficult challenges now center on designing environments, feedback loops, and control systems"

来源：OpenAI

2. 它不是什么

• 不是单纯的 prompt engineering；prompt 只是入口，不是系统本体。
• 不是把大模型接进 IDE 就算完成；真正难的是让 agent 能持续完成端到端任务。
• 不是“自动写代码”这么窄；OpenAI 明确说 agent 生成的是“application logic, tests, CI configuration, documentation, observability, and internal tooling”。OpenAI

3. 为什么现在重要

• 单 agent 在复杂项目上会失焦、早停、过度自信；Cursor 明说单 agent 适合聚焦任务，但面对复杂项目“slow for complex projects”。Cursor scaling agents
• 随着 agent 运行时间变长、任务链变深，真正的瓶颈从“模型会不会写”转向“系统会不会稳定地让它持续做对的事”。
• 所以竞争壁垒开始从模型参数，转向环境设计、文档结构、边界约束、评测体系和恢复机制。

Harness Engineering 的组成部分

1. 仓库知识要成为 system of record

OpenAI 的一个核心观点是：agent 能看到的才存在，不能在运行上下文中访问的知识，对 agent 等于不存在。

"From the agent’s point of view, anything it can’t access in-context while running effectively doesn’t exist."

"We made repository knowledge the system of record"

他们反对一个臃肿的单文件 AGENTS.md，转而把 AGENTS.md 当目录，把真正的知识放进结构化 docs/、架构文档、执行计划、技术债跟踪与质量文档中，并用 linter / CI 机械检查其新鲜度与交叉链接。OpenAI

含义：

• harness 的第一层不是模型，而是“仓库内可检索、可验证的知识组织”。
• 文档不是给人看的附属品，而是 agent 的运行时依赖。

2. 让应用、日志、指标、trace 对 agent 可见

OpenAI 把 UI、日志、指标、trace 都做成 agent 可调用的运行时能力：

"Logs, metrics, and traces are exposed to Codex via a local observability stack"

"Agents can query logs with LogQL and metrics with PromQL."

并给出类似 "ensure service startup completes in under 800ms" 这样的可验证目标。OpenAI

这意味着 harness 不只是代码生成器，而是“agent 可观测的测试与诊断平台”。

3. 架构与 taste 要靠机械约束，不靠口头约定

OpenAI 明确强调：

"By enforcing invariants, not micromanaging implementations, we let agents ship fast without undermining the foundation."

它们使用分层架构、定制 linter、结构测试、命名规范、日志规范、文件大小约束等方式，为 agent 提供硬边界。OpenAI

这和传统“给人写代码规范”不同：

• 对 agent，模糊规范几乎等于没有规范；
• 规则越能转为程序检查，越容易规模化复用；
• taste 需要被编码成 lint / test / docs，而不是停留在 code review 口头意见里。

4. Throughput 会改变 merge 哲学

OpenAI 公开指出，在 agent 吞吐远高于人类注意力时，过重的阻塞式合并门槛会变成系统性瓶颈：

"Test flakes are often addressed with follow-up runs rather than blocking progress indefinitely."

"In a system where agent throughput far exceeds human attention, corrections are cheap, and waiting is expensive."

来源：OpenAI

这并不意味着放弃质量，而是把质量控制从“每一步人工卡死”转向“快速前进 + 后续自动修正 + 周期性清理”。

5. 需要持续做 entropy control / garbage collection

OpenAI 很坦率地承认全 agent 代码库会累积“AI slop”，他们早期甚至每周五花 20% 时间做清理，后来才把“golden principles”编码进仓库并由后台任务持续发起小型清理 PR。OpenAI

这说明 harness 不是“一次搭好”的系统，而是持续维护的软件工厂：

• 需要周期性质量评分；
• 需要 refactoring PR 自动生成；
• 需要技术债像垃圾回收一样被持续处理。

6. 长程任务依赖 durable project memory，而不是超长单 prompt

OpenAI 在 Run long horizon tasks with Codex 中把 long-horizon coding 拆成了非常明确的 agent loop：

"Plan" -> "Edit code" -> "Run tools" -> "Observe results" -> "Repair failures" -> "Update docs/status" -> "Repeat"

并明确指出：

"Long-running work is less about one giant prompt and more about the agent loop the model operates inside."

"The most important technique was durable project memory."

来源：Run long horizon tasks with Codex

它给出的文件栈也很值得注意：

• prompt.md：冻结目标与约束；
• plans.md：里程碑与 acceptance criteria；
• implement.md：运行手册；
• documentation.md：状态与决策日志。

这与 OpenAI 主文里“repository knowledge is the system of record”形成直接互证：

• harness 的核心是外部化状态；
• 任务越长，越依赖可回看的结构化记忆；
• 让 agent 长时间不漂移的关键，不是无限加上下文，而是把上下文整理成可重访的项目内工件。

7. ExecPlan / AGENTS / PLANS 说明 harness 不只是理念，而是可落地模板

OpenAI Cookbook 的 Modernizing your Codebase with Codex 把这种做法进一步模板化。它建议在仓库中建立 .agent/AGENTS.md 和 .agent/PLANS.md，并把复杂改造工作收敛到 ExecPlan 驱动的多阶段流程中。Modernizing your Codebase with Codex

关键表述：

"Give Codex a lightweight contract for how planning works in this repo"

"These explain what an ExecPlan is, when to create or update one, where it lives, and what sections every plan must have."

这意味着 harness engineering 在实践上至少包含三类 repo 内契约：

• agent 如何理解仓库的契约：AGENTS.md
• agent 如何规划复杂任务的契约：PLANS.md / ExecPlan
• agent 如何验证自己完成了任务的契约：validation docs / tests / parity checks

换句话说，harness engineering 并不是一句抽象口号，而是能沉淀成文件结构、计划模板和执行脚手架的工程方法。

Cursor 文章给出的互证

1. Cursor 证实了“结构比聪明更重要”

在 Towards self-driving codebases 中，Cursor 说他们“created a new agent harness to orchestrate many thousands of agents”，而且系统可以运行一周、完成大部分提交。Cursor self-driving codebases

这和 OpenAI 的观点高度一致：突破点不是单个 agent 更聪明，而是 harness 让大量 agent 可被编排、被观察、被收敛。

2. 平铺式自协调很快失败

Cursor 的早期方案是多 agent 共享协调文件，但很快出现锁竞争、忘记释放锁、状态混乱等问题：

"20 agents would slow to the throughput of 1-3"

"The coordination file quickly created more problems."

来源：Cursor self-driving codebases；Cursor scaling agents

它说明 harness engineering 不能只理解为“多开几个 agent 并行跑”，而是必须解决同步、 ownership、任务切分和信息回流问题。

3. 最终有效的是 planner / subplanner / worker 的层次系统

Cursor 最终收敛到 root planner、subplanner、worker 的递归结构，worker 只做单一任务，planner 负责全局拥有权与后续决策；handoff 不仅传结果，还传 "notes, concerns, deviations, findings, thoughts, and feedback"。Cursor self-driving codebases

这与 OpenAI 的“人负责高层意图、agent 负责执行”形成互证：

• 大任务必须拆为多层 ownership；
• handoff 必须结构化，才能支撑长期自治；
• 高吞吐系统不能依赖人人都知道全局，而是依赖清晰的局部责任与信息上卷。

4. 正确率与吞吐量之间需要工程取舍

Cursor 明确写到：

"When we required 100% correctness before every single commit, it caused major serialization and slowdowns of effective throughput."

他们更倾向接受一个“小而稳定的错误率”，再靠最终收口到 green branch 的修复阶段控制发布质量。Cursor self-driving codebases

这个观点与 OpenAI “merge gate 变轻、修正更便宜”高度一致，是目前公开材料中最值得关注的共识之一。

Harness Engineering 与评测 / Evals 的关系

如果说 harness 是 agent 的“运行系统”，那 evals 就是这个系统的“仪表盘和回归测试框架”。

OpenAI 官方 Agent evals 文档写得很直接：

"Measure agent quality with reproducible evaluations."

"For identifying errors at the workflow-level, we recommend our trace grading functionality."

来源：Agent evals

OpenAI 官方 Trace grading 文档进一步定义：

"Trace grading is the process of assigning structured scores or labels to an agent’s trace"

"Unlike black-box evaluations, trace evals provide more data to better understand why an agent succeeds or fails."

来源：Trace grading

这说明 harness engineering 不是“先让 agent 跑起来，再想办法测”，而是要把以下能力内建进去：

• 端到端 trace 留存；
• 对工具调用、决策路径、失败点的结构化打分；
• 可以大规模回归的 eval 运行；
• 把“为什么失败”而不是只看“结果对不对”纳入系统反馈。

换句话说：

没有 eval / trace grading 的 harness，很难稳定演化；
没有 harness 的 evals，也很难真正改善 agent 在真实工程流里的表现。

2. skill / workflow 的 eval 更接近“轻量端到端测试”

OpenAI 在 Testing Agent Skills Systematically with Evals 里把 agent skill 的评测说得非常工程化：

"Concretely, an eval is: a prompt -> a captured run (trace + artifacts) -> a small set of checks -> a score you can compare over time."

"In practice, evals for agent skills look a lot like lightweight end-to-end tests"

来源：Testing Agent Skills Systematically with Evals

这对 harness engineering 很关键，因为它说明：

• harness 的评测对象不是只看最终回答文本；
• 还要看 agent 有没有调用正确 skill、执行预期命令、生成约定输出；
• trace、artifacts、command execution 本身就是评测材料。

这比传统 LLM eval 更贴近真实软件工程，也更接近 survey session 里应强调的“系统性方法论”。

3. eval 不是孤立模块，而是持续改进 flywheel 的一环

OpenAI 官方 Agent evals 还明确把它和持续改进绑在一起：

"Operate a flywheel of continuous improvement using evaluations."

而在 Safety in building agents 中，又把 trace graders 和 evals 作为多 agent workflow 的安全与质量缓解手段之一。Safety in building agents

这进一步支持一个判断：

harness engineering = 运行时脚手架 + 观测 + 评测 + 安全约束 + 持续修正的闭环。

Harness Engineering 与 AI-native engineering team 的关系

OpenAI 官方 Building an AI-Native Engineering Team 给了一个更组织化的视角：coding agents 正在把工程团队从“自己做所有实现”转向“把大量 SDLC 阶段交给 agent 首轮执行，人类负责 review / own / direction”。Building an AI-Native Engineering Team

其中几条很值得和 harness engineering 放在一起看：

• "Persistent project memory"
• "Evaluation loops"
• "Structured tool execution"

这实际上说明，组织层面的 AI-native engineering，底层正是 harness engineering：

• 如果没有持久项目记忆，agent 无法稳定参与长流程；
• 如果没有结构化工具执行，agent 产出不可验证；
• 如果没有 evaluation loops，团队无法知道 agent 是在变好还是只是在漂移。

Harness Engineering 与 Benchmark 的关系

1. Benchmark 是外部度量，harness 是内部生产系统

SWE-bench 的定位是公开基准，衡量 agent 在真实软件工程问题上的解决率；官网强调 "% Resolved" 作为核心指标，并列出 Verified、Lite、Multilingual、Multimodal 等变体。SWE-bench

因此：

• benchmark 用来回答“你的 agent 在标准题上表现如何”；
• harness 用来回答“你的团队能否在真实仓库里持续做出可交付变更”。

两者相关，但不能互相替代。

2. 公开基准很重要，但不足以覆盖真实 agent 工程问题

OpenAI / Cursor 的文章都更强调真实仓库中的长期运行问题：

• 文档是否可检索；
• 日志/trace 是否可访问；
• agent 是否会漂移；
• 多 agent 是否会互相踩踏；
• 架构边界是否能被机械执行；
• merge / review / cleanup 能否闭环。

这些问题不是单一 benchmark 分数能完整描述的，所以 harness engineering 可以看作 benchmark 之外的“生产工程层”。

3. EVMbench 提醒我们：benchmark 也会反过来推动 harness 设计

Paradigm 与 OpenAI 联合发布 EVMbench 时，用词很直接：

"Together with OpenAI, we built EVMbench to measure exactly that."

"EVMbench is an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities."

"We’ve also extended the benchmark harness into an auditing agent"

来源：Paradigm - Introducing EVMbench

这里有一个非常重要的信号：

• benchmark 不只是外部排行榜；
• benchmark 的容器化环境、answer key、任务封装，本身就在塑造 harness；
• 当 benchmark 足够贴近真实工作流时，它会自然长成一个可复用的 agent harness。

它和我们当前 blog / 功力系统 / survey sessions 的相关之处

当前工作区里没有现成的 survey sessions 或已有 harness engineering 调研文件，因此本次是新建调研。结合你的描述，harness engineering 和你们现有内容体系最相关的地方至少有四个：

1. 对 blog 来说，它是一个上位框架

如果你们 blog 已经在写 agent、评测、工作流、技能系统、代码生成、自动化开发，那么 harness engineering 可以作为一个总纲，把这些零散主题串起来：

• 不是只谈 agent 能力；
• 而是谈“怎样设计一个 agent-first 的工程系统”。

2. 对“功力系统”来说，它非常像工程内功

如果“功力系统”强调的是长期积累、基本功、抽象能力、方法论沉淀，那么 harness engineering 正是 agent 时代的软件工程内功：

• 文档治理能力；
• 约束编码能力；
• 评测建设能力；
• 工作流设计能力；
• 可观测性与质量回收能力。

它不像 flashy demo，更像“把 agent 变成稳定生产力”的底层功法。

3. 对 survey sessions 来说，它很适合做系列主题

这个话题不该只做成一篇新闻摘要，后续完全可以拆成系列：

• Harness Engineering 是什么
• Agent legibility 与 repository as system of record
• Trace grading 与 agent eval flywheel
• Multi-agent orchestration 的设计模式
• Throughput vs correctness 的工程权衡
• Agent-first codebase 的 garbage collection

4. 对实际系统设计来说，它可直接映射到你们自己的 agent 产品/内容体系

如果你们已经有 blog 系统、技能系统、survey session 机制，那么可以把 harness engineering 直接翻译为内部建设议题：

• 知识是否沉淀在 repo / docs，而不是散落在聊天和口头沟通；
• 规则是否能被 lint / CI / grader 机械执行；
• agent 每次执行是否留下 trace、可复盘结果与失败原因；
• 是否有定期 cleanup / refactor / debt paydown 的后台流程；
• 是否建立了从任务定义到 PR 合并的闭环。
• 是否已经形成 spec -> plan -> implement -> verify -> document -> review -> merge 的标准回路。

对我们自己的可执行启发

1. 先做知识底座，再做更强 agent

比起继续堆 prompt，优先做这些事情更符合 harness engineering：

• 给仓库建立清晰的 AGENTS.md 目录索引；
• 把产品规则、架构规则、执行计划、质量标准写进 repo；
• 用 CI 检查文档 freshness 和 cross-link completeness。
• 给长任务建立持久项目记忆文件，而不是只依赖会话上下文。