当前阅读总时间是：20,773小时

1

前几天跟一个学生讨论 AI，她提到一个很有意思的问题。

她说，自己用过不少模型，也知道它们能干活。有的模型写代码速度很快，有的模型回答问题看起来也不错。但是在使用过程中，她总有一种隐隐的不信任感。

这种不信任感，不一定是对 AI 的傲慢。更准确地说，是她还不知道该如何判断 AI 的回答到底好不好。

过去我们讨论 AI，最常问的问题是：AI 能不能做这件事？

现在这个问题已经不够了。因为很多时候，AI 的确能做。它能写代码，能写文章，能翻译，能做图，能帮你整理材料，能帮你做调研。真正的问题变成了：AI 给出的答案，看起来都比我强，我怎么知道它到底有没有达到我期待的高度？

这就是 AI 时代的第一个重要能力：不是提问能力，而是判断能力。

提问能力当然重要。但是如果没有判断能力，提问能力越强，反而越危险。因为你会得到更多看起来很像答案的东西，却不知道哪些是真的，哪些是假的，哪些是普通正确，哪些是真的高水平。

2

AI 让我们进入了一个更不容易相信世界的时代。

以前伪造一张聊天截图、伪造一张奖状、伪造一个图片证据，多少还需要一点技术门槛。你要会 PS，要懂排版，要花时间调整细节。现在，这个门槛正在迅速降低。

图片可以生成，视频可以生成，聊天记录可以生成，简历上的经历也可以在 AI 的帮助下被包装得越来越像真的。甚至一个人并没有真正做过某个项目，也可以让 AI 帮他准备一套看起来很完整的项目复盘。

这会带来一个直接后果：原来社会里那些简单的评价秩序会变得更复杂。

以前看到奖状，会默认它大概率是真的。看到论文，会默认作者确实参与了。看到视频，会觉得这总不会是假的吧。看到一个学生简历上写了很多成果，也许不会立刻怀疑。

但以后不行了。

不是说我们要把所有人都当成骗子，而是说世界会逼迫我们更谨慎。法律、学校、公司、平台的规则都会慢慢调整，但是规则永远是滞后的。很多权利和边界，本来就是从错误和事故里长出来的。先出现足够大的问题，大家吃了亏，社会才会开始补规则。

AI 时代也是这样。我们很可能要先经历一批谣言、造假、版权纠纷、学术争议、简历包装和信任危机，然后才会慢慢形成新的共识。

所以，年轻人不能只是学习如何使用 AI，还要学习如何在 AI 制造出来的复杂世界里保持清醒。

3

怎么保持判断力？

第一，不要盲目崇拜模型。

有的人一听是某个顶级模型，就天然更相信它。这个心理可以理解，因为好模型的平均能力确实更强。但是具体到每一个任务，模型名字不能替代判断。

同一个模型，做不同任务，表现会差很多。写代码可能很强，做网络安全题可能受安全策略影响。写一篇通用文章可能很顺，判断一个高度专业的问题可能会胡说。哪怕是最好的模型，也可能在某些地方犯很低级的错误。

所以，我们不能把信任建立在模型名字上，而要建立在验证过程上。

第二，要学会交叉验证。

看到一个说法，不要只问一次 AI。可以让不同模型分别判断，可以让 AI 给出处，可以让它列出反方证据，可以让它帮你检查自己的推理漏洞。尤其是涉及合作、求职、论文、项目经历、奖项荣誉这些高价值信息时，更要让 AI 参与事实核查。

比如，一个人简历上写了某篇论文。我们可以让 AI 查这篇论文的期刊、会议、作者列表、引用情况、研究内容和难度。还可以让 AI 判断，这个成果是否符合这个人当时所处阶段的能力范围。

AI 不一定能给出最终判决，但它可以极大降低初步审查的成本。

第三，要看细节。

判断一个项目是不是真的，最好的方法不是问“这是不是你做的”，而是让对方讲细节。

如果他真的做过，他会记得项目从什么时候开始，过程中遇到过哪些困难，哪一次讨论最关键，哪个地方卡了很久，最后为什么选择这个方案。他不一定表达得很漂亮，但是细节会自然冒出来。

如果他没有做过，只是背了一套包装材料，就很难经得起追问。

面试里判断项目经历，论文答辩里判断研究贡献，跟人合作时判断对方实力，本质上都要看细节。细节不是装饰，细节就是证据。

4

AI 时代的实力，也要换一种理解。

过去我们说一个人有实力，常常看他的学校、奖项、论文、实习、项目、工作经历。这些东西仍然重要，但它们会变得越来越不够。

因为这些东西都可以被包装，甚至可以被伪造。

真正重要的是，你能不能经得起审查。

你说自己做过一个项目，那你能不能讲清楚它解决了什么问题？为什么这个问题值得解决？原来最好的方法是什么？你的方法好在哪里？好多少？是正确率更高，还是速度更快，还是成本更低？有没有跟当前最好的方法对比？如果别人质疑“我用 AI 半天也能做一个类似工具”，你怎么证明你的工具不是一个玩具，而是一个成熟的成果？

这些问题都很现实，也很残酷。

我在跟那个学生讨论她的论文时，就做了一次模拟提问。她的论文是一篇工具型论文，不是提出一个全新的理论，而是把已有理论实现成可以使用的工具。

一开始她讲得比较散，说自己做了数据清洗、代码实现、实验测试，整个流程都走了一遍。这个回答能证明她参与过，但还不能很好证明这个成果的价值。

后来我们一点点追问，才追到关键点：她的工具跟已有的冠军级求解器相比，在相同时间内求出的结果数量有五倍以上提升。

这句话才是重点。

如果是面试，或者申请研究生，或者向一个不了解你领域的人介绍成果，你不能等别人追问十几分钟才说到重点。你要一开始就讲清楚：

我解决的是什么问题。
原来的最好方法是什么。
我的结果比它好在哪里。
这个工作体现了我哪些能力。

谦虚是一种美德，但是在需要证明自己的场合，过度谦虚会变成表达能力不足。

5

在一个更不信任的世界里，保持实力还有另一层含义：不要同流合污。

这句话听起来有点重，但现实确实会把人推到这种位置。

如果别人可以买奖、可以买软著、包装简历、论文挂名、实验结果微调一下就能发出去，你怎么办？

你可能会想，既然连一些著名学校、著名教授都会造假，为什么我不能？既然这样做收益很大，惩罚又未必很重，我为什么要吃亏？

这时候就不是技术问题了，而是选择问题。

一个朴素的理由是，你做坏事之后不一定会被抓住，但你永远不知道什么时候会爆雷。更可怕的是，一旦形成路径依赖，你会越来越习惯突破边界。第一次觉得紧张，第二次觉得问题不大，第三次就变成理所当然。

到最后，你不是犯了一次错，而是把自己训练成了一个会持续犯错的人。

还有一个更朴素的理由是，人要能睡得着觉。

不是每个人都要把自己想象成道德英雄。很多时候，不作恶并不是因为自己多高尚，而是因为自己知道，干了坏事会害怕，会心虚，会不安，会担心哪一天被翻出来。

这也挺好。

能对坏事感到害怕，说明人还没有坏到不可救药。能保留这种害怕，很多时候就是普通人最实用的道德防线。

6

除了判断力和实力，AI 时代还需要想象力。

我问过那个学生一个问题：如果你有无限的 token，你会用来做什么？

她说，她问过身边的学长学姐，大家的回答都比较局限。大概就是做科研、跑数据、翻译资料、完成作业。不是这些事情不好，而是这些答案暴露出一个问题：我们还没有真正打开 AI 带来的想象空间。

很多受过良好教育的人，很容易变成功利主义训练出来的高效执行者。

老师说这个重要，就做这个。学长学姐说这个有用，就做这个。竞赛榜单上有这个，就做这个。简历需要这个，就做这个。

这样当然能取得成绩，也很值得肯定。但是如果一个人永远只做别人已经说过有用的事，他的上限会受到限制。

想象力不是坐在那里空想出来的。想象力也需要训练。

怎么训练？多用。

就像读书一样，有一种读书方式是遇到好书才读。还有一种读书方式是，不管有没有遇到所谓好书，这个月就要读够一百个小时。后者听起来有点笨，但它会把你逼进更多可能性里。

使用 AI 也是这样。如果只是在有明确需求的时候才打开 AI，你会永远停留在熟悉场景里。写作业、写代码、改简历、做总结，来来回回就这些。

但是如果你要求自己在有效探索的前提下多用 AI，你就会开始问：我还能让它做什么？它能不能帮我做一个工具？能不能帮我复盘一次谈话？能不能帮我训练表达？能不能帮我做一个给小学老师用的教案系统？能不能帮我把手机里的注意力重新引导到我真正想去的地方？

很多新想法，就是在这种“多用一点”的压力下出现的。

7

最后，功利主义和理想主义并不是对立的。

学生时期，我们很容易把功利主义当成主线，把理想主义当成甜品。周一到周五是功利主义，晚上和假期才是理想主义。先把成绩、论文、保研、实习、工作这些事情做好，如果还有余力，再做一点自己真正感兴趣的事。

这个思路有现实合理性。

但是它也有一个问题：过度功利会让人失去主动性。

别人说什么有用，你就做什么。别人说什么没用，你就不做什么。你看起来很聪明，很会选择，实际上是在把自己的想象力交给外部评价体系。

理想主义的价值，不只是让人活得浪漫一点。它还会反过来帮助一个人取得更大的现实成就。

一个人因为喜欢学习而持续阅读，后来可能在 AI 时代更快适应新工具。一个人因为对编程本身感兴趣而长期探索，后来可能在工作中拥有更强的工程判断。一个人因为想帮助别人而做一个小工具，后来这个小工具也许会变成真正有价值的产品。

功利主义让人知道眼前要做什么，理想主义让人不被眼前困住。

AI 时代也是这样。

如果你只把 AI 当成完成任务的工具，你会变得更高效。但是如果你把 AI 当成扩展想象力的伙伴，你才可能变得更自由。

所以，年轻人最该训练的，确实不是单纯的提问能力。

更重要的是判断力，知道什么是真的，什么是好的，什么是值得相信的。

更重要的是实力，让自己的经历、成果和表达经得起审查。

更重要的是想象力，在别人都沿着既定标准往前跑的时候，还能问一句：我自己真正想做什么？

这三个能力，可能才是 AI 时代最硬的通行证。

信息管理的终极问题：我们用信息网络建造的，从来不是真理

——在《Nexus》之后，重新看 AI 辅助编程与信息管理

没有人直接生活在现实里

设想一个场景。

一位老人在山东某家三甲医院的结算窗口前出院。他买过一份惠民保。十分钟后，他的医保报销、商保赔付和自付金额，被同一台屏幕一次算清。他不再需要保留发票，不再需要去保险公司柜台递材料，也不再需要拜托儿子拍照上传 App。

从他的角度看，他只是少跑了几次腿。

但从信息网络的角度看，这十分钟里发生的事，比他这一生大部分政治新闻都更重要。一个原本散落在患者、医院、医保部门、商保公司之间的低信任信息链，被改造成了一张可验证、可结算、可监管的网。截至 2024 年，这个平台已在山东全省上线，2760.30 万笔医保业务以「一站式结算」方式完成，惠及 511.22 万参保人，累计报销 13.34 亿元。[^1]

这位老人没有看见这张网，但他的余生将持续生活在这张网定义的现实里。

这就是信息管理。它不是整理资料，不是文件归档，不是把表格做得更漂亮。它决定一个社会如何看见自己，谁被看见，谁被忽略，谁有权行动，谁必须等待。

人类从来不直接生活在现实里。我们生活在被信息网络组织过的现实里。

信息的两张脸

有一种很顺口、也很危险的说法：信息越多，人类越接近真理。

这并不成立。

赫拉利在《Nexus》里反复提醒一件事：信息有两种功能，但它们并不天然重合。第一种功能是发现现实——让我们看见从未被看见的东西。第二种功能是组织人——让分散的个体能够协调、服从、行动。前者通向智慧，后者通向秩序。两者偶尔同向，更多时候各走各路。[^2]

历史上最强大的信息网络，往往不是最接近真理的网络，而是最擅长组织人的网络。

一种宗教让百万人愿意为同一个神而死，靠的不是事实核查，而是叙事的可复制性。一支军队让普通士兵冒着子弹冲锋，靠的不是哲学论证，而是命令链的清晰度。一家公司让员工每天准时打卡，靠的不是科学发现，而是工资单和考勤系统。

这些都是信息网络。它们记录的、传递的、强制的东西,大部分与真理无关。

赫拉利的提醒在 AI 时代变得格外刺耳：一个网络越强大，并不代表它越接近真实。它可能只是更擅长动员人、分类人、约束人，让人按某种规则行动。

社交媒体是信息网络。
医保系统是信息网络。
你公司里的 CRM 是信息网络。
未来部署在企业内部的 AI agent harness，也是信息网络。

它们的力量不在于「记录了什么」，而在于：让什么被看见，让什么被忽略；让谁能行动，让谁承担责任；让什么被当成事实，让什么被当成噪音。

回到那家医院的结算窗口。它表面上多了一个便民流程，实质上重新定义了三件事：医院与商保之间谁有权读取什么数据，费用如何被分类，赔付责任如何被分配。这是新的事实秩序。

信息管理之所以重要，因为它从来不是中性的。

一家公司是怎么变成半盲的

每一个组织都不直接接触现实。

它通过订单、合同、票据、病历、日志、报表、监控指标和会议纪要来感知世界。这些东西如果没记录，组织就看不见；如果记错了，组织就看错了；如果传得太慢，组织就活在过去。

很多小企业不是没业务，是老板看不见自己的业务。

客户在哪个销售手上，他不知道。
合同有没有续签，他要等月会。
发票有没有开，财务还没汇总。
钱到没到账，要在群里问一遍。
售后由谁跟进，全靠当事人记忆。
仓库里到底剩多少货，要去问那个干了十二年的老员工。

现实其实早就发生了。组织只是没形成统一感知。

这就是赫拉利意义上的「半盲」状态：信息已经存在于人世间，但还没有被组织成网络。它分散在每个人的手机、Excel 和大脑里，无法相互校对，也无法被任何一个共同视角看见。

一家公司从半盲走向看得见的过程，从来不是「上一套 SaaS」那么简单。它是一种治理升级。

谁有权录入？
谁有权修改？
什么算重要客户？
什么算正式投诉？
谁负责催款？
员工离职后，客户关系归个人还是归公司？

只要这些问题没答案，再贵的系统也只是把混乱搬进数据库。

信息管理还做了一件容易被忽略的事：它替组织记忆。

人会遗忘。组织也会。一个接口为什么不能改、一个客户为什么有特殊条款、一种药品为什么不能进某个支付流程、一次上线为什么会失败——这些经验如果只活在某个具体的人脑子里，等他离开，组织就会重新犯同一个错误。

信息系统的价值，是把「某个人知道」变成「这个系统知道」。这是从个人能力到组织能力的关键一跳。

协作的真相是：每个人都活在自己的版本里

只要有多人协作，就一定需要一个共享的现实模型。

但大部分项目的失败，不是因为大家不努力，而是因为没有形成共同的现实。

需求文档写在一个地方。
设计图存在另一个地方。
代码是第三套逻辑。
测试不知道真实意图。
运维不知道上线风险。
老板看到的是被销售层层修饰过的进度。

一群人看似在协作，其实活在不同版本的现实里。每个人的版本都不算谎言，但拼起来不构成同一个故事。

更糟糕的是，没有人知道哪个版本最接近真相。

这就是为什么开会越多的组织，往往越混乱。会议本身不是协调，会议是为了消除版本差异而进行的临时手术。如果信息系统是健康的，差异会被自动磨平；如果信息系统是病的，会议只是在不断暴露病情。

信息管理的本质，不是让大家说一样的话，而是让大家看到一样的世界。

任何网络都会犯错，问题是错了之后会发生什么

任何一个信息网络都会犯错。

数据会错，规则会错，模型会错，人会错，AI 也会错。

问题不在「会不会错」，而在「错了之后会发生什么」。

赫拉利用相当大的篇幅讨论过中世纪教会和 20 世纪极权宣传体系。它们都是极其高效的信息网络——覆盖广、传播快、组织严密。但它们都缺一样东西：自我纠错的机制。异见被清除，反对被压制，错误被神圣化。于是，这些网络越高效，灾难就被放大得越彻底。[^3]

一个网络的健康程度，从来不取决于它传播信息的效率，而取决于它识别和修正错误的能力。

软件工程师其实早就懂这个道理，只是用了别的词汇。

测试是纠错。
日志是纠错。
监控是纠错。
审计是纠错。
回滚是纠错。
代码 review 是纠错。
事故复盘是纠错。
权限隔离是预防性纠错。
用户申诉是社会性纠错。

一个没有这些机制的信息系统，会变成非常危险的东西。它不只是错，还会以系统权威的方式错。

接下来谈 AI 时，请记住这一点。我们不是在讨论 AI 会不会犯错——它一定会。我们要讨论的是：当一个能犯错的智能体，被放进一个本来就缺乏纠错机制的网络里，会发生什么。

AI 辅助编程真正降低的，不是写代码的成本

过去几年，关于 AI 辅助编程，所有的注意力都集中在一件事上：写代码更快了。

这个视角太窄。

数据本身不算新鲜。Stack Overflow 2025 开发者调查显示，84% 的受访者已经在使用或计划使用 AI 工具，专业开发者中 50.6% 每天使用 AI；同一份调查里，开发者对 AI 输出准确性的不信任比例已经超过信任比例。[^4] Gartner 预测，到 2028 年，75% 的企业软件工程师会使用 AI code assistants。这个趋势意味着，开发者的角色会越来越多地从「实现」滑向「编排、约束和验证」。[^5]

把这两组数字放在一起，会得到一个并不令人鼓舞但很重要的结论：AI 已经高频进入开发流程，但人类仍然必须验证它的产出。

更深层的变化藏在另一个地方。

写代码从来不是一个软件项目里成本最高的部分。

真正贵的，是沟通需求、设计数据模型、对接权限、写接口、生成报表、清洗脏数据、部署上线、培训用户、修 bug、跟随业务调整、长期维护。代码只是这条长链中的一段。

所以，当一个外包公司不愿意给小工厂做质检系统，不是因为代码难写，是因为整条链都不划算。当一家县医院接不进某个商保产品，不是因为接口神秘，而是因为没人愿意为这点业务量配齐一支团队。当一家养老机构上不了长护险结算系统，不是因为技术不存在，而是因为定制开发的成本永远高于这家机构付得起的金额。

于是这些需求长期被压抑。它们不是「不存在」，它们是「不值得」。

AI 辅助编程改变的，是「不值得」这条边界。

它不是把一个大型系统便宜一点做出来。它是让大量原本不值得做的小型信息系统，第一次变得值得做。

我把这个变化称为：毛细血管信息化。

过去，信息化主要发生在主干道——大型银行的核心系统、大型医院的 HIS、国家医保平台、城市级政务系统、大企业的 CRM。这些系统投入巨大、周期漫长、参与人多。

接下来要发生的事，是信息化向毛细血管渗透。

某个险种和某家医院之间的结算规则。
某个社区里几位独居老人的巡访记录。
某个小工厂的质检异常闭环。
某个外贸公司的回款提醒。
某个老师对学生长期学习状态的追踪。
某家律所的客户材料流转。
某家药房特药的处方核验和支付。

每一个都不大。加起来数量巨大。它们对应的是现实世界里无数尚未被软件覆盖的流程。

这才是 AI 辅助编程的社会意义。软件正在从「大机构的基础设施」，变成「具体流程的低成本管理层」。

医保结算窗口背后的三层信息秩序

让我们再回到那位老人面前的结算窗口。

这一次，把镜头放慢。

第一层是事实层。这位患者是谁？他的住院费用多少？医保应付多少？商保可赔多少？这些是赤裸裸的事实。听起来简单，但在过去，每一项都可能在不同系统里、以不同口径、以不同时点存在。事实层的工作，是让它们以同一种语法被表达。

第二层是秩序层。哪些机构有权读取哪些数据？谁来计算赔付？医院如何出具结算单？商保何时履行赔付责任？患者是否需要垫资？这一层定义的不是事实，是事实如何改变行动。

第三层是纠错层。如果身份匹配错了怎么办？如果费用分类错了怎么办？如果保险责任判断错了怎么办？如果有人骗保怎么办？如果系统接口失败怎么办？这一层决定，当前两层出问题时，谁会发现，多久之内发现，谁有权修正。

三层缺一不可。

少了事实层，秩序无凭可据。
少了秩序层，事实无法行动。
少了纠错层，前两层会以不被察觉的方式偏离真实，最后变成一种自动化的虚假。

这个三层模型不只适用于医保。它适用于所有信息系统。

中小企业的 CRM，事实层是客户、合同、报价、发票；秩序层是谁负责催款、谁有权打折、谁审核回款；纠错层是对账、抽查、客户申诉。

软件工程的代码仓库，事实层是代码、需求、日志、事故记录；秩序层是 review、CI、发布流程、权限分级；纠错层是测试、监控、回滚、复盘。

养老机构的护理记录，事实层是服务时间、服务内容、签字确认；秩序层是排班、保险结算、家属通知；纠错层是抽访、家属申诉、第三方审计。

任何一个信息系统，如果你看不清它的三层结构，那它八成已经在某一层失效了。

创新药支付：当事实链不够长，赔付就无法发生

医保结算窗口只是开始。

国家医保局关于「双目录」机制的文件指出，打破医保、医院与商保之间的数据壁垒，是支持创新药研发和商业健康保险扩张的前提。一些试点已经把保障从「事后补偿」延伸到「全程服务」：上海三甲医院推进「医保+商保一站式秒赔」，广州穗新保与医院实现全流程数据对接。^6

为什么创新药这件事必须由信息网络才能解决？

因为价格只是表面问题。

商保过去很难覆盖创新药，不只是因为药贵，是因为信息不够长。

保司不知道患者的真实疾病轨迹。
不知道用药的真实周期。
不知道疗效是否成立。
不知道停药率有多高。
不知道是否合规使用。
不知道是否存在欺诈。

没有这些信息，就无法做精算。没有精算，就没有可持续的产品。没有产品，患者就无药可保。这是一条被信息缺失锁死的链条。

当信息网络贯通诊断、处方、购药、支付、用药、随访、疗效、不良反应、再次治疗、真实世界数据时，整条链才有可能松动。商保不再面对一份残缺的病历，而是面对一段连续的事实。

这才是信息管理真正可怕的地方。它不只是提高效率。它会改变哪些事情「可能发生」。

一份创新药保单能不能出生，取决于事实链是否够长。

中小企业不是没管理，是管理活在老板脑子里

中国大量中小企业，不是没管理，是管理高度依赖人脑。

客户信息在销售微信里。
报价单在 Excel 里。
合同在网盘里。
发票在财务的电脑里。
回款靠老板亲自追问。
售后靠销售记忆。
库存靠仓库老员工知道。
项目延期靠群里吵出来。
员工离职后，很多客户关系和历史经验一起消失。

很多人会说：上 CRM、上 ERP。

现实是，中小企业经常上不起来。标准 SaaS 太重，字段不贴合，员工不愿意填，流程变得太快，老板想要的报表又是个性化的。大型 ERP 更不现实——成本、实施周期和组织成熟度都不匹配。

AI 辅助编程的机会，是让一家企业可以「长出」刚好够用的系统。

不是一上来买一个庞然大物。
而是从最痛的地方开始。

先把客户、合同、应收账款整理成一个小系统。
再把销售跟进记录接入。
再生成回款提醒。
再接入发票和银行流水。
再生成每周经营报表。
再把售后问题转成工单。
再让一个 agent 每天巡检异常。

每一步都不需要一个完整团队。每一步都可以在不打断业务的情况下增长。

但这里藏着一个赫拉利式的警告：信息系统不能凭空创造秩序。

它只能把已有的秩序显性化，把隐性的秩序结构化，把混乱暴露出来——或者，在更糟的情况下，把混乱固化下来。

如果老板自己也说不清客户分类规则，AI 不会帮他想清楚。
如果销售拒绝录入关键事实，AI 不会替他承担。
如果财务数据本身混乱，AI 只会自动化这种混乱。
如果公司内部权责不清，AI 会把责任的真空写进每一份自动生成的工单里。

中小企业信息化最难的部分，从来不是写代码。是让一家企业愿意面对它自己的真实流程。

Agent 是新一代官僚

现在轮到房间里那只越来越大的灰犀牛：AI agent。

OpenClaw 这一类 agent harness 的关键，不是聊天，是把大模型放进一个带工作区、工具、技能、配置和长期上下文的运行环境。它的 skills 可以作为带有 SKILL.md 的目录来教 agent 如何使用工具，workspace 也可以承载和具体环境相关的上下文。[^7]

如果把它部署在企业内部，它会成为某种东西——一种我们语言里还没有合适词汇的东西。

它不只是工具。
它不只是助手。
它甚至不只是流程自动化。

它是一台微型制度生产机器。

老板说：每天早上列出超过 30 天未回款的客户。Agent 去查合同、发票、收款记录，生成清单。这是一条新的制度。

销售说：这个客户同意了新报价。Agent 自动更新客户状态、生成合同草稿、提醒财务开票。这是另一条新的制度。

财务上传银行流水。Agent 自动尝试匹配合同和发票，标记异常项。又是一条。

售后接到投诉。Agent 自动生成工单，关联客户、产品、合同和历史问题。又是一条。

这些「制度」过去需要一个产品经理、一个工程师、一个运营人员、一个审批流设计者协作几周才能跑起来。现在，一句话之后，它就在运行。

这是非常美好的画面。也是非常危险的画面。

因为制度生产从来有两面。

好制度可以降低摩擦、减少误判、保护弱者、提升效率、让责任清晰。
坏制度可以制造形式主义、增加填报负担、强化监控、固化偏见，把人困在不合理的流程里。

AI agent 的危险在于——它非常勤奋。它可以源源不断地生成流程、表格、指标、看板、规则、提醒。如果没有人类判断介入，它会变成一种新型物种：

自动官僚。

自动官僚的特点，赫拉利在《Nexus》里其实早已勾勒过雏形。它能把所有事情表格化，把所有行为指标化，把所有例外流程化，把所有沟通工单化，把所有人放进某种评分体系里。

它运转良好。它从不抱怨。它每天准时生成报表。它绝不偷懒。

但它未必知道这些东西是否真的接近现实，是否真的减少负担，是否真的提升智慧。

这个风险并不抽象：一旦 agent 可以安装第三方技能、访问文件、执行命令、调用外部服务，技能来源、权限边界、执行日志和外部授权就必须被纳入治理。[^8] 这些不是技术细节，而是治理问题。

一个真正可用的企业内部 agent harness，必须是这样一组东西的总和：

工具能力 + 权限边界 + 审计日志 + 沙箱环境 + 人工审批 + 数据治理 + 回滚机制。

少一项，它就不是基础设施，是事故源。

信息管理会从「搜索」滑向「供给」

传统信息管理基本上围绕搜索展开。

资料很多，你来找。
文档很多，你来搜。
知识库很大，你输关键词。
搜索结果给你，剩下你自己判断。

这种范式建立在一个假设上：信息的最终消费者是人，而人有时间和耐心。

这两个假设都正在失效。

接下来的信息消费者，会越来越多地是 agent。它们没有时间、没有耐心，也没有「自己再判断一下」的习惯。它们要求信息直接、结构化、可执行。

更重要的是，使用者的需求本身在变化。

人们不再想「找到资料」。他们想「完成任务」。

帮我改这个模块。
帮我排查这个 bug。
帮我判断这个客户是否有回款风险。
帮我生成本周经营报告。
帮我看这个患者是否满足保险责任。

完成任务所需的信息，不应该完全靠人去搜，而应该由系统主动供给。

一个 coding agent 要修改支付状态机，它应该自动拿到相关需求背景、状态机文档、接口契约、表结构、历史事故、下游依赖、测试用例、监控指标、上线回滚方案、权限和合规要求。这不是奢侈，这是它能不能被信任的前提。

一个企业经营 agent 要生成回款报告，它应该自动拿到合同、发票、银行流水、客户信用记录、销售跟进、催款历史、账龄规则、异常标记、老板关心的报表口径。

一个医疗支付 agent 要判断商保赔付，它应该自动拿到患者授权、保单责任、诊断、费用明细、医保结果、药品目录、历史理赔、风控规则、人工复核条件。

这叫任务型上下文供给。

它不是知识库的升级，是信息管理范式的转变。

但这里也有一个赫拉利式的危险：系统供给什么，AI 就基于什么行动。

如果上下文错误，AI 会错。
如果上下文缺失，AI 会猜。
如果上下文过期，AI 会用旧现实行动。
如果上下文带有偏见，AI 会放大偏见。
如果上下文没有权限边界，AI 会越权。

未来一家企业真正稀缺的，不是知识库，是可信上下文管理系统。

它要知道哪些信息最新，哪些已经废弃；哪些有权威来源，哪些只是讨论；哪些需要人工确认，哪些不能给 AI 看；哪些可以用于自动执行，哪些只能用于辅助判断。

这件事还没有名字。但它会成为 AI 时代信息管理的新核心。

高效幻觉系统

到这里，必须诚实地谈一件事。

AI 辅助编程降低信息系统建设成本之后，世界不会自动变好。

我们可能得到更高效的医院结算、更精准的企业管理、更好的养老服务。我们也可能得到更多垃圾系统、更多形式主义、更多虚假指标、更多自动化压迫。

最大的风险不是没有信息。

最大的风险，是错误信息被系统化。

过去一个员工误解规则，影响有限。
未来一条 AI 生成的规则被写进系统，可能影响所有人。

过去一位老板拍脑袋，影响一次会议。
未来这条拍脑袋的规则被写入自动审批流，会长期运行。

过去一个基层单位为了应付检查做几张假表，是一次性材料。
未来 AI 可以每天自动生成看似完美的假秩序。

过去一个理赔员判断有偏差，还有人工讨论的空间。
未来如果模型和规则自动拒赔，患者可能连问题出在哪里都不知道。

我把这种系统称为高效幻觉系统。

它有数据，有报表，有看板，有流程，有自动化，有 AI 总结。它运转得无可挑剔。

它只是不接近真实。

它只是更快地产生一种看起来合理的秩序。

这正是赫拉利反复警告的事：一个网络越高效，并不代表越真实；秩序越严密，并不代表越智慧。

未来的信息系统设计者，每天都要在心里问自己几个问题：

这个系统减少了现实摩擦，还是只是增加了填报？
它让真实问题更早暴露，还是更容易被包装？
它帮助一线，还是只是帮助上级制造控制感？
它让弱者更容易申诉，还是让弱者更难反抗系统判断？
它能纠错，还是只会维护自己的权威？
它让组织更聪明，还是让组织更自信地犯错？

这些问题没有标准答案。但不问的人，注定会建出高效幻觉系统。

真正的分水岭：纠错能力

未来组织之间的差距，不会是数据多少的差距，也不会是 AI 能力的差距。

会是纠错结构的差距。

所有组织都会有更多 AI。
所有组织都会有更多数据。
所有组织都会有更多自动化。
所有组织都会生成更多文档、报表、代码和流程。

但并不是所有组织都会因此变聪明。

有的组织会因为 AI 变得更快、更透明、更能学习。
有的组织会因为 AI 变得更乱、更官僚、更自信地犯错。

分水岭就在纠错。

一个强组织会问：

数据从哪里来？
谁验证？
什么时候过期？
规则怎样版本化？
AI 输出如何测试？
异常如何报警？
用户如何申诉？
责任如何追溯？
错误如何转化为制度改进？

一个弱组织只会问：

能不能自动生成？
能不能快点上线？
能不能多出几个报表？
能不能让 AI 替人干活？

这两种组织正走向完全不同的未来。

前者把 AI 当成学习机器。
后者把 AI 当成幻觉机器。

个人也有一张信息网

这篇文章不只关于社会和企业。

每一个人也都是一张小型信息网。

你的事实层，是你记录了什么——读书笔记、工作日志、代码片段、错误清单、会议纪要、想法、情绪、目标。

你的秩序层，是这些记录如何改变你的行动——是否形成 checklist，是否形成决策原则，是否形成可复用的 prompt，是否形成项目模板。

你的纠错层，是你如何发现自己错了——是否复盘，是否记录预测和结果，是否承认误判，是否更新方法，是否定期清理过期的认知。

一个真正强大的个人信息系统，不是资料最多，而是能不断把经历变成经验，把经验变成方法，把方法变成行动，把行动结果再反馈回来。

这就是个人版的 Nexus。

AI 时代，这件事的难度并没有降低。它只是变得更可见。

你过去靠记忆维持的秩序，AI 会要求你显式化。你过去靠直觉做的判断，AI 会要求你提供上下文。你过去能蒙混过去的混乱，AI 会以系统化的方式暴露出来。

这是好事。它逼你成为一个更清醒的人。

一个新的稀缺角色：信息管理架构师

如果把这一切落到职业上，我会说，未来最稀缺的角色不是程序员，不是产品经理，也不是 AI 培训师。

是一种你可以叫它「信息管理架构师」的人。

他做的事情大致是这样：

进入一家企业，观察信息流。
找出关键事实散在哪里。
识别哪些流程靠人肉记忆维持。
判断哪些数据必须结构化，哪些不必。
设计最小可用的数据模型。
用 AI 辅助编程快速生成轻量系统。
部署内部 agent harness。
建立权限、审计、备份、报表、提醒。
把老员工的经验转成规则和 checklist。
把企业从「人脑管理」推向「半自动信息系统」。

这个角色的价值不在于写多少代码，而在于能判断：

什么值得系统化？
什么不值得系统化？
什么必须人工裁决？
什么可以自动化？
什么数据必须准确？
什么流程会制造负担？
什么指标会诱导造假？
什么权限不能开放？
什么动作必须留痕？
什么错误必须能回滚？

他其实是一种微型制度设计师。

AI 辅助编程越强，这个角色就越重要。因为实现成本下降之后，真正稀缺的就是判断力。

当任何人都能让 AI 生成一个系统时，问题就变成——

你生成的，是好秩序，还是坏秩序？

结语：我们要用信息网络建造一个怎样的现实

让我们回到《Nexus》的核心问题。

人类不直接生活在现实里，而是生活在被信息网络组织过的现实里。

医院如何记录病人，决定病人如何被治疗、如何被支付。
企业如何记录客户，决定客户关系如何被维护。
学校如何记录学生，决定学生如何被理解。
政府如何记录基层，决定资源如何被分配。
软件如何记录状态，决定流程如何运行。
AI agent 读取什么上下文，决定它如何行动。

这些记录从来不是中性的。它们定义什么被看见，什么被忽略；什么算事实，什么算异常；谁有权行动，谁必须等待；谁承担责任，谁拥有解释权。

AI 辅助编程降低了建造信息网络的边际成本。这会释放巨大的社会生产力。医院和商保会更好衔接。中小企业会拥有刚好够用的系统。养老、教育、制造、基层治理、专业服务都会被毛细血管式地信息化覆盖。

但赫拉利的警告必须留在每一个建造者的耳边：信息网络不一定通向真理。它也可能通向幻觉、权力、官僚主义和失控。

所以未来真正重要的问题，不是「AI 能不能写更多代码」，也不是「我们能不能建更多系统」。

是这样一个问题：

我们要用这些低成本的信息系统，建造一个更接近真实、更能纠错、更尊重人的现实——

还是建造一个更高效，但更虚假的秩序？

这才是信息管理的终极问题。

对个人而言，它决定你能不能把经历变成成长。
对企业而言，它决定它能不能把个人经验变成组织能力。
对社会而言，它决定资源能不能被更准确、更公平、更低摩擦地配置。
对 AI 时代而言，它决定非人类智能能否安全地进入人类的现实。

信息管理不是整理资料。

它是智能的地基，是组织的神经系统，是社会的连接方式，是权力的分配机制，是错误能否被修正的制度条件。

它是我们用信息网络建造现实的能力。

而 AI 辅助编程的到来，只是让这个古老问题——变得更迫切、更具体，也更值得每一个认真对待未来的人，重新坐下来学习一次。

[^1]: 国家医保局：山东医保商保一体化同步结算平台已实现全省上线，2024 年山东省 2760.30 万笔医保业务通过「一站式结算」完成，惠及 511.22 万参保人，累计报销 13.34 亿元。

[^2]: Yuval Noah Harari, Nexus: A Brief History of Information Networks from the Stone Age to AI (2024). 信息有“两种功能”的论述贯穿全书，尤其见关于“真理与秩序”的张力的章节。

[^3]: 同上。Harari 关于信息网络自我纠错机制的讨论，是《Nexus》中针对 AI 风险最核心的论证之一。

[^4]: Stack Overflow Developer Survey 2025: 84% 的受访者正在使用或计划使用 AI 工具；专业开发者中 50.6% 每天使用 AI 工具；同份调查显示开发者对 AI 输出准确性的不信任比例已超过信任比例。

[^5]: Gartner 预测：到 2028 年，75% 的企业软件工程师将使用 AI code assistants。开发者角色从“实现”转向“编排、约束和验证”，是本文基于这一趋势作出的延伸判断。

[^7]: OpenClaw 官方文档：skills 可以作为带 SKILL.md 的目录承载 agent 使用工具的方式；workspace 可承载与具体环境相关的长期上下文。

[^8]: 这里指 agent harness 在第三方技能、文件访问、命令执行、外部服务授权等能力上天然存在的治理风险。

从泥板账本到 AI Agent：信息网络如何建造现实

几千年前，在美索不达米亚的一座城市里，一个书记员把一袋麦子、一头羊、一笔债务，刻在泥板上。

对今天的人来说，这只是一个古老的记录动作。但在当时，这个动作已经改变了现实。

在麦子被刻上泥板之前，它只存在于仓库里，存在于某个人的记忆里，存在于交易双方的口头承诺里。泥板出现之后，麦子开始进入另一个世界：一个由符号、账本、税收、债务、库存和行政命令组成的世界。

这个世界不完全等同于物理现实，却能反过来支配物理现实。

谁欠谁多少粮食，谁必须交税，谁有权领取配给，谁没有完成义务，都可以被泥板决定。一个人可以不认识国王，也从未见过帝国，但只要他的名字出现在账本上，帝国就已经伸手进入了他的生活。

这就是信息网络最古老的力量。

它不仅记录现实。它建造现实。

今天，我们以为自己生活在钢筋、水泥、汽车、手机和互联网之中。但更深一层看，我们生活在无数信息网络之中。

医院的病历决定一个人如何被治疗。医保和商保的结算系统决定一笔医疗费用如何分摊。公司的 CRM 决定一个客户属于谁。学校的成绩和档案决定一个学生如何被理解。政府的统计口径决定资源如何被分配。代码仓库、测试、日志和监控决定一个软件系统如何运行。AI agent 读取什么上下文、拥有什么权限，决定它如何行动。

所以，信息管理不是整理资料。

信息管理是人类用符号、制度和机器建造现实的方式。

一、信息网络让陌生人生活在同一个现实里

如果一个部落只有几十个人，信息管理很简单。

谁欠谁一只羊，谁今天生病，谁昨天打猎失败，谁和谁发生冲突，这些事情可以靠记忆、闲谈和共同生活来管理。每个人都认识每个人。现实被保存在人的脑子里。

但当人类社会变大之后，记忆就不够用了。

城市需要知道仓库里有多少粮食。国家需要知道谁该服兵役。寺庙需要知道谁献了祭品。商人需要知道远方的合伙人是否守约。公司需要知道客户是否回款。医院需要知道患者用过什么药。软件团队需要知道某个接口为什么不能改。

规模一旦扩大，人类就必须发明一种东西：可共享的现实。

文字、账本、档案、合同、地图、货币、法律、数据库、知识库，都是可共享现实的技术。

它们让互不相识的人，可以围绕同一套事实和规则行动。

一个现代公司，就是这样一种信息网络。

销售说客户很重要，财务说客户欠款 90 天，仓库说库存不足，法务说合同条款有风险，老板说本月现金流很紧。如果这些信息散在不同人的微信、Excel、电脑硬盘和记忆里，公司就不是一个统一行动的组织，而是一群各自握着碎片现实的人。

公司真正成为公司，不只是因为它有营业执照、办公室和员工，而是因为它能把客户、合同、发票、库存、回款、售后、责任和决策连成一个共同现实。

同样，医院真正成为医院，不只是因为它有医生和病床，而是因为它能把身份、诊断、检查、药品、费用、病历、医保、商保和后续随访连成一个可信现实。

人类文明的扩大，就是信息网络不断扩大的过程。

但有一个问题也随之出现：可共享的现实，并不一定是真实的现实。

二、信息的目的不只是发现真理，也可能是制造秩序

现代人常常有一个天真的信念：信息越多，我们就越接近真理。

这并不一定成立。

信息有两种完全不同的功能。

第一种功能，是帮助我们发现世界。例如医学数据帮助医生发现疾病，财务数据帮助企业发现经营风险，测试日志帮助工程师发现 bug。

第二种功能，是把人组织起来。例如宗教经典组织信徒，法律条文组织国家，绩效指标组织公司，平台算法组织流量，行政表格组织基层治理。

发现真理和制造秩序，当然可以相互支持。但它们不是同一件事。

一个信息网络可以非常强大，却不一定真实。它可以把很多人高效组织起来，让他们按照某种规则行动，却未必让他们更接近现实。

历史上有许多这样的信息网络。

帝国的户籍、教会的名册、殖民地的地图、现代公司的 KPI、社交媒体的推荐算法，都能把复杂的人和事压缩成可管理的类别。压缩本身不是坏事，没有压缩就没有管理。但每一次压缩都会丢失一些东西。

一个活生生的人，进入系统后变成“参保人”“用户”“客户”“员工”“学生”“高风险账户”“低价值客户”。这些标签能帮助组织行动，也可能让组织忘记标签后面的人。

这就是信息管理的悖论。

没有信息网络，大规模协作无法发生。只有信息网络，人又可能被网络重新定义。

所以真正的问题不是要不要信息管理，而是要建造什么样的信息管理。

三、AI 编程让信息秩序第一次进入毛细血管

过去，信息系统是一种昂贵的东西。

大型银行可以建设核心系统，大型医院可以建设 HIS，大型企业可以上 ERP，国家可以建设医保平台，城市可以建设政务系统。主干道上的信息化，已经持续了几十年。

但社会并不只由主干道构成。

一个社区里老人有没有按时吃药？一个小工厂的哪道工序经常返工？一个外贸公司的哪笔应收账款快变成坏账？一个小诊所如何记录患者复诊？一个教培老师如何持续追踪学生的错题、情绪和目标？一个律所如何管理客户材料、合同版本和交付证据？

这些需求是真实的。

但在过去，它们常常不值得被系统化。

不是因为没人需要，而是因为定制开发太贵，标准 SaaS 太重，实施周期太长，维护成本太高，业务变化太快。于是大量现实只能停留在微信群、Excel、纸质单据、口头经验和老员工脑子里。

AI 辅助编程改变了这个经济学。

它当然能让程序员更快写代码。但更重要的是，它降低了小型信息系统的建造成本。过去需要一个小团队才能做的事，现在可能由一个懂业务的人、一个 AI coding 工具和一套验证流程逐步完成。

这会带来一种新的历史现象：

毛细血管信息化。

信息化不再只发生在银行、医院、政府和大企业这些主干道上，而会渗入每一个具体流程。它会进入养老院的护理记录，进入小工厂的质检照片，进入教培机构的成长档案，进入诊所的复诊提醒，进入外贸公司的回款预警，进入药房的特药核验，进入律所的材料流转。

每一个系统都很小，但数量巨大。

它们会像毛细血管一样，把软件带到现实世界的末端。

这可能是 AI 编程最深远的社会影响：不是让少数大公司拥有更强的信息系统，而是让无数小组织第一次可以拥有刚好够用的信息秩序。

四、医院、医保和商保：患者为什么曾经是接口

医疗支付提供了一个清晰例子。

患者看病产生大量信息：身份、诊断、检查、治疗、药品、耗材、费用、票据、病历、医保结算、商保责任、历史疾病、用药记录。每一项信息都可能影响谁来付钱、付多少钱、什么时候付。

如果医院、医保和商保之间没有可信的信息网络，患者就会变成接口。

医院把信息给患者。患者把发票、病历和费用清单拍照上传给保险公司。保险公司再用人工方式判断材料真假、责任范围、费用重复、药品目录和骗保风险。

换句话说，现实已经在医院发生了，但保险公司无法直接访问那个现实。它只能通过患者搬运的材料，重新拼接现实。

这就是低级信息网络的典型状态：信息存在，但不能以可信、结构化、授权可用的方式流动。

山东医保商保一体化同步结算平台的意义，就在于改造了这条链。国家医保局披露，2024 年山东省有 2760.30 万笔医保报销业务享受医保、惠民保“一站式结算”，惠及 511.22 万参保人，累计报销 13.34 亿元。

这不是简单的便民服务，而是现实组织方式的改变。

原来，一个患者出院后还要在医院、医保、商保之间来回奔波。现在，系统可以在结算时识别参保关系，计算基本医保和商业医疗保险的赔付金额，并把个人自付部分一起呈现出来。

这背后有三层结构。

第一层是事实：患者是谁，诊断是什么，费用是多少，医保报销多少，商保责任是什么。

第二层是秩序：谁有权读取数据，谁来计算赔付，谁承担费用，患者是否需要垫资，医院和保险公司如何结算。

第三层是纠错：身份错了怎么办，费用分类错了怎么办，保险责任判断错了怎么办，有人骗保怎么办，接口失败怎么办。

如果只有事实，没有秩序，数据只是一堆记录。如果只有秩序，没有纠错，系统就会以制度的名义规模化犯错。

创新药支付会让这个问题更明显。

许多创新药不是完全没有价值，而是缺乏可持续支付机制。商业保险要设计产品，需要知道真实风险、用药周期、疗效、停药率、合规使用情况和欺诈风险。没有信息，就没有精算。没有精算，就没有保险。没有保险，许多昂贵疗法就很难被普通人触达。

所以医疗信息管理不只是让报销更快。

它会改变哪些治疗可以被支付，哪些药物可以被纳入保障，哪些患者可以获得新的机会。

信息网络不仅反映现实。它扩大或缩小现实中的可能性。

五、AI Agent：一种新的非人类书记员

过去的信息系统，大多是被动的。

数据库不会自己决定拒赔。文档库不会自己修改流程。报表不会自己给员工发提醒。搜索引擎不会自己执行 SQL、发邮件、部署代码或生成合同。

AI agent 改变了这一点。

当一个 agent 能够读取文件、调用工具、访问数据库、操作浏览器、发送消息、修改代码、生成报表、触发工作流时，它就不再只是一个回答问题的工具。

它变成了信息网络中的行动者。

这是一种新的历史角色：非人类书记员。

古代书记员把谷物、税收和债务写进泥板，帮助国家管理人。现代 AI agent 可以把自然语言中的意图转成字段、表单、脚本、流程、权限、提醒、审计、测试和报表，帮助组织管理现实。

OpenClaw 这类 agent harness 的意义，不只是聊天窗口里多了一个聪明助手。它把模型放进一个有工作区、有工具、有技能、有长期上下文的运行环境中。技能可以由 SKILL.md 这样的文件定义，工作区可以承载具体环境的上下文，工具可以让 agent 对外部系统采取行动。

这相当于给非人类书记员配备了眼睛、手、记忆和一套制度手册。

老板说：列出超过 30 天未回款的客户。agent 可以查询合同、发票、银行流水，生成清单。

销售说：客户同意新报价。agent 可以更新客户状态，生成合同草稿，提醒财务开票。

财务上传银行流水。agent 可以匹配合同和发票，标记异常项。

售后收到投诉。agent 可以生成工单，关联客户、产品、合同和历史问题。

这看起来像效率工具。但更深层看，它是在生产制度。

一个原来靠微信群催款的企业，开始拥有回款提醒制度。一个原来靠护士记忆复诊的诊所，开始拥有复诊任务系统。一个原来靠纸质记录服务的养老机构，开始拥有护理证据链。

AI agent 的危险，也恰好来自这里。

它不是太懒，而是太勤奋。

它可以不断生成流程、表格、指标、看板、规则、提醒和评分体系。它可以把所有例外流程化，把所有沟通工单化，把所有人放入某种标签和分数中。

如果没有人类判断，它可能成为一种自动官僚。

自动官僚不会疲惫，不会抗议，也不会主动质疑自己的指标是否荒谬。它只会高效执行。

但高效执行不等于接近真实。

六、三个闸门：事实、秩序和纠错

任何信息系统，无论是古代帝国的税册、现代医院的结算平台，还是未来企业内部的 AI agent，都可以用三个闸门来判断。

第一个闸门是事实。

系统是否准确记录了发生的事情？患者身份、诊断、费用、药品是否准确？客户、合同、发票、回款是否准确？需求、设计、代码、测试、日志是否准确？

许多组织第一关就过不了。数据没有记录，记录不完整，字段口径不一致，关键事实藏在聊天记录里，系统里的数据和真实情况分离。

事实层不稳，后面所有智慧都会变成幻觉。

第二个闸门是秩序。

事实如何改变行动关系？

一个客户欠款 60 天，只是事实。谁去催，何时催，是否暂停发货，是否进入风险名单，这是秩序。

一个患者使用创新药，只是事实。是否符合商保目录，是否需要医生确认，是否触发随访，是否进入赔付流程，这是秩序。

一个测试失败，只是事实。是否阻断发布，是否通知负责人，是否回滚，是否触发事故复盘，这是秩序。

秩序层是信息系统最有权力的地方。

因为谁定义流程，谁就在定义行动。谁定义指标，谁就在定义重要性。谁定义权限，谁就在定义谁能看见、谁能改变现实。

第三个闸门是纠错。

事实错了怎么办？规则错了怎么办？系统错了怎么办？AI 错了怎么办？

有没有测试、校验、监控、审计、申诉、人工复核、版本管理、回滚、异常处理和事故复盘？一个弱系统会把错误藏起来。一个强系统会把错误变成下一次制度改进。

AI 时代最关键的不是生成更多事实，也不是生成更多流程，而是设计更强的纠错结构。

因为 AI 会同时加速事实生产和秩序生产。它会生成更多文档、更多代码、更多表格、更多指标、更多审批节点。如果没有纠错，错误也会获得自动化的翅膀。

未来组织之间的差距，不是信息多少的差距，而是纠错能力的差距。

强组织会问：数据从哪里来？谁验证？什么时候过期？规则如何版本管理？AI 输出如何测试？异常如何报警？用户如何申诉？责任如何追溯？错误如何进入复盘？

弱组织只会问：能不能自动生成？能不能快点上线？能不能多出几个报表？能不能让 AI 替人干活？

前者把 AI 变成学习机器。后者把 AI 变成幻觉机器。

七、从搜索时代，到上下文供给时代

过去的信息管理围绕搜索展开。

文档很多，你来搜。知识库很大，你输关键词。搜索结果给你，剩下自己判断。

这种模式有一个隐含假设：人是行动者，系统是资料库。

但 AI agent 时代，这个假设会改变。

人往往不是想找资料，而是想完成任务。

帮我修改支付状态机。帮我排查这个 bug。帮我判断客户是否有回款风险。帮我生成本周经营报告。帮我判断某个患者是否满足保险责任。帮我给学生制定下阶段学习计划。

完成任务需要的不是资料列表，而是正确上下文。

一个 coding agent 修改支付状态机时，应该自动拿到需求背景、状态机文档、接口契约、数据库表结构、历史事故、下游依赖、测试用例、监控指标和回滚方案。

一个经营 agent 生成回款报告时，应该自动拿到合同、发票、银行流水、客户信用记录、销售跟进记录、历史催款记录、账龄规则和异常标记。

一个医疗支付 agent 判断商保赔付时，应该自动拿到患者授权、保单责任、诊断、费用明细、医保报销结果、药品目录、历史理赔和人工复核条件。

这意味着信息管理会从“搜索资料”变成“供给上下文”。

未来真正重要的系统，不只是知识库，而是可信上下文管理系统。

它要知道哪些信息最新，哪些已经废弃，哪些来自权威来源，哪些只是讨论，哪些需要人工确认，哪些不能给 AI 看，哪些可以用于自动执行，哪些只能用于辅助判断。

上下文供给错了，AI 就会基于错误现实行动。上下文缺失，AI 就会猜。上下文过期，AI 就会使用旧现实。上下文没有权限边界，AI 就会越权。

于是，一个古老问题在 AI 时代重新出现：谁有权定义现实？

过去，这个权力属于书记员、官僚、神职人员、会计、档案管理员、数据库管理员、产品经理和管理者。未来，它还会属于那些设计 AI 上下文和 agent 权限的人。

八、更高效的幻觉系统

AI 辅助编程会让世界出现许多好系统。

老人护理可以更连续，学生成长可以更细致，小工厂生产可以更透明，医疗支付可以更顺畅，中小企业可以不再完全依赖老板记忆和微信群。

但同一种技术也可以制造坏系统。

一个坏系统不一定看起来很坏。它可能有漂亮的界面、实时的看板、自动生成的总结、完整的流程、严密的指标和看似客观的评分。

它的问题是：它不接近真实。

它只是把某种偏见、某种偷懒、某种权力意志、某种拍脑袋规则，写进了系统。

过去一个老板的拍脑袋决定，可能只影响一次会议。未来这个决定可以被写进自动审批流，长期运行。

过去一个基层单位为了应付检查做假表，只是一份材料。未来 AI 可以每天自动生成看似完美的假秩序。

过去一个理赔员判断错误，患者还可能找到人争论。未来如果模型和规则自动拒赔，患者可能连问题出在哪里都不知道。

这就是更高效的幻觉系统。

它让组织更快、更整齐、更自信，却未必更聪明。

这种风险并不新。人类历史上，信息网络一直可能制造幻觉。只是 AI 让幻觉拥有了新的速度、新的规模和新的执行能力。

九、中小企业信息管理架构师

当任何人都可以让 AI 生成代码时，真正稀缺的就不是代码，而是判断。

未来可能出现一种新的角色：中小企业信息管理架构师。

这个人不是传统程序员，也不是传统咨询顾问，更不是单纯教别人使用 AI 工具的培训师。

他的工作是进入一家企业，观察信息如何流动。

关键事实散在哪里？哪些流程靠老员工记忆维持？哪些数据必须结构化？哪些流程值得系统化？哪些事情必须人工裁决？哪些权限不能开放？哪些指标会诱导造假？哪些动作必须留痕？哪些错误必须能回滚？

然后，他用 AI 辅助编程快速生成轻量系统，部署内部 agent harness，接入文件、表格、邮件、飞书、企微、数据库，建立权限、审计、备份、报表和提醒，把老员工经验转成规则、模板和 checklist。

这个角色的价值，不在于把所有东西自动化。

恰恰相反，他最重要的能力，是知道什么不该自动化。

有些问题需要记录，有些问题需要流程，有些问题需要谈判，有些问题需要组织变革，有些问题需要老板亲自做裁决。

AI 可以把秩序执行得更快，但不能替人判断秩序是否正当。

实现成本越低，判断力越值钱。

这也是为什么 AI coding 时代，真正重要的人不只是会写代码的人，而是能设计可执行、可验证、可纠错的信息网络的人。

十、信息管理的终极问题

人类不只是生活在自然现实里。

我们还生活在信息网络建造的现实里。

一个人在医院里如何被记录，决定他如何被治疗和支付。一个客户在公司里如何被记录，决定他如何被维护或放弃。一个学生在学校里如何被记录，决定他如何被理解。一个基层问题在政府系统里如何被记录，决定资源是否会抵达。一个 bug 在工程系统里如何被记录，决定它会被修复、忽略，还是再次发生。

AI agent 出现以后，这个问题变得更紧迫。

因为信息网络不再只是记录和传播信息。它开始生成信息、解释信息、做出判断、采取行动。

过去我们管理的是信息。现在我们还要管理基于信息行动的智能体。

这要求新的制度能力：上下文管理、工具权限管理、行动边界管理、人机责任分配、模型输出验证、自动化审计、异常回滚、多 agent 协作治理、提示注入防护、敏感数据隔离、人工审批节点。

这些听起来像技术细节，实际上是未来组织治理的核心。

因为当 AI agent 能够访问文件、数据库、邮件、代码仓库、财务系统、客户系统和生产环境时，它就不再是一个助手。它已经成为组织行动网络的一部分。

所以，AI 编程的真正问题不是“代码会不会更便宜”。

代码当然会更便宜。

真正的问题是：当建造信息网络的成本下降之后，我们会建造什么样的现实？

我们会建造一个更接近真实、更能纠错、更尊重人的现实，还是建造一个更高效、更整齐、更虚假的秩序？

这才是信息管理的终极问题。

它不是资料整理问题。它是智能的地基，是组织的神经系统，是社会的连接方式，是权力的分配机制，也是错误能否被修正的制度条件。

几千年前，书记员把麦子刻在泥板上，人类第一次大规模把现实转化为可管理的符号。

今天，AI agent 正在把自然语言中的意图转化为流程、代码、权限、报表和行动。

泥板、账本、数据库和 AI agent 之间，隔着几千年的技术史，却连接着同一个问题：

我们如何用信息网络建造现实？

以及，当这个网络错了以后，我们是否还有能力把现实夺回来？

参考资料

• Yuval Noah Harari, Nexus: A Brief History of Information Networks from the Stone Age to AI, Random House 图书介绍：https://www.randomhousebooks.com/books/762444/
• Stack Overflow Developer Survey 2025, AI 部分：https://survey.stackoverflow.co/2025/ai
• Gartner, Gartner Says 75% of Enterprise Software Engineers Will Use AI Code Assistants by 2028：https://www.gartner.com/en/newsroom/press-releases/2024-04-11-gartner-says-75-percent-of-enterprise-software-engineers-will-use-ai-code-assistants-by-2028
• 国家医疗保障局，医保商保一体化同步结算平台已经开始上线运行：https://www.nhsa.gov.cn/art/2025/1/29/art_14_15596.html
• 国家医疗保障局，“双目录”机制启动：协同共治支持创新药高质量发展：https://www.nhsa.gov.cn/art/2025/7/15/art_14_17274.html
• OpenClaw Skills 文档：https://docs.openclaw.ai/skills

信息管理的终极问题：AI 编程真正改变的不是代码，而是现实

有一个词，我们一直把它理解小了：信息管理。

一说信息管理，很多人想到的是文档、表格、知识库、ERP、CRM、OA、Notion、飞书、Confluence。它听起来像一种行政工作，最多是管理效率问题：资料别丢，文件好找，流程能走。

但如果把镜头拉远一点，信息管理真正管理的不是资料，而是现实。

一个公司能不能知道客户欠了多少钱，是信息管理。一个医院能不能把诊疗、医保、商保、药品和结算连起来，是信息管理。一个小工厂能不能知道哪批货快延期、哪道工序频繁出错，是信息管理。一个 AI agent 能不能拿到正确上下文、在正确权限下行动、出错后能不能追溯，也是信息管理。

这篇文章的核心判断只有一句：

AI 辅助编程真正降低的不是写代码的成本，而是建造信息秩序的成本。

如果这个判断成立，那么 AI coding 的意义就不只是程序员生产效率提升，而是大量过去“不值得系统化”的现实流程，会第一次拥有被软件化、结构化、自动化、可追溯化的机会。

这件事会释放巨大生产力，也会制造新的风险。

因为信息系统从来不是中性的。它决定什么被看见，什么被忽略，谁能行动，谁承担责任，什么算事实，什么算异常，以及错误能不能被修正。

一、先纠正一个天真的想法：信息越多，不等于越接近真理

赫拉利在《Nexus》里提供了一个很大的视角：人类历史不仅是工具史、战争史、经济史，也是一部信息网络史。

《Nexus》的官方介绍把问题放得很大：从石器时代到 AI，信息网络如何塑造世界，以及信息与真理、官僚制与神话、智慧与权力之间的复杂关系。

这里最关键的提醒是：信息不天然等于真理。

信息至少有两张脸。

第一张脸，是帮助人类发现现实。比如病历记录帮助医生判断病情，财务流水帮助企业判断经营状态，测试日志帮助程序员发现 bug。

第二张脸，是把人连接起来、组织起来、动员起来、约束起来。宗教经典、帝国文书、公司制度、绩效指标、平台算法，都是信息网络。它们未必更真实，但它们能让大量人按照同一套规则行动。

所以一个信息网络越强大，不代表它越智慧。它可能只是更擅长分类、监控、分配、动员和制造服从。

这也是为什么 CRM 不是一个简单的客户表。

一个公司上线 CRM，看起来只是录入客户名称、联系人、合同金额和回款状态。但它实际上在重新定义企业现实：

谁是重要客户？哪个销售真正拥有客户关系？欠款由谁跟进？客户投诉算不算正式流程？老板相信销售口头汇报，还是相信系统数据？员工离职后，客户关系属于个人，还是属于公司？

CRM 不是工具，它是组织内的信息权力重分配。

医疗支付也一样。

过去患者看完病，要自己垫钱，自己保存发票、病历、费用清单，再上传给保险公司理赔。表面看是流程低效，深层看是医院、医保、商保之间缺少可信的信息网络，于是患者被迫成为信息搬运工。

国家医保局披露，山东医保商保一体化同步结算平台已经全省上线。仅 2024 年，山东省就有 2760.30 万笔医保报销业务享受医保、惠民保“一站式结算”，惠及 511.22 万参保人，累计报销 13.34 亿元。

这个案例的意义不只是“少交几张纸”。它意味着原本分散在患者、医院、医保、商保之间的低信任信息链，被改造成了一个可识别、可计算、可结算、可监管的信息网络。

信息管理的本质，是把现实变成可以共同确认、共同执行、共同纠错的结构。

二、信息管理的四个底层功能

为什么信息管理这么重要？可以拆成四个功能：感知、记忆、协调、纠错。

第一，信息管理是组织的感知系统。

组织并不直接接触现实。它通过订单、合同、票据、病历、日志、报表、会议纪要、客户反馈、监控指标来感知现实。

如果这些信息没有被记录，组织就看不见。如果这些信息被错误记录，组织就看错了。如果这些信息传递太慢，组织就滞后于现实。

很多小企业并不是没有业务，而是老板无法实时看见业务。客户在哪个销售手上，合同有没有续签，发票有没有开，钱有没有到账，售后有没有处理，库存够不够，下周哪个订单会延期，这些问题散在微信、Excel、记忆和口头承诺里。

现实发生了，但组织没有形成统一感知。

第二，信息管理是组织的记忆系统。

人会遗忘，组织也会遗忘。

为什么这个系统当初这么设计？为什么某个接口不能改？为什么某个客户有特殊条款？为什么去年某次上线失败？为什么某个供应商被拉黑？

如果没有信息管理，这些经验会随着人员流动、项目结束、群聊沉底而消失。组织就会不断重复犯错。

所以信息管理的价值，是把“某个人知道”变成“这个系统知道”。

第三，信息管理是组织的协调系统。

多人协作的前提，是大家共享同一个现实模型。目标是什么，谁负责什么，当前进度是什么，依赖关系是什么，完成标准是什么，风险由谁处理，变更发生在哪里。

很多项目混乱，不是因为大家不努力，而是因为每个人都活在不同版本的现实里。需求写在一个地方，设计写在另一个地方，代码又是第三套逻辑，测试不知道真实意图，运维不知道上线风险，老板看到的是被美化过的进度报告。

第四，信息管理是组织的纠错系统。

这是最容易被忽略、但最关键的一层。

系统不可能永远正确。数据会错，规则会错，模型会错，人会错，AI 也会错。成熟的信息系统，不是不犯错，而是能快速发现错误、定位错误、修正错误，并把错误转化为下一次的制度改进。

软件工程师对这一点非常熟悉。

测试是纠错，日志是纠错，监控是纠错，审计是纠错，回滚是纠错，代码 review 是纠错，事故复盘是纠错，权限隔离是预防性纠错。

一个没有纠错机制的信息系统，会以系统权威的方式犯错。

这比普通错误更危险。

三、AI 编程改变了信息系统的经济学

过去几年，大家讨论 AI 辅助编程，重点常常放在“代码生成”。

这个视角太窄。

Stack Overflow 2025 开发者调查显示，AI 工具已经高频进入开发流程，专业开发者中有一半左右每天使用 AI 工具；但同一份调查也显示，开发者对 AI 输出准确性的主动不信任比例高于信任比例。

这说明 AI coding 的真实状态不是“AI 替代程序员”，而是“AI 高速生成，人类必须验证”。

Gartner 的预测也很类似：到 2028 年，75% 的企业软件工程师会使用 AI code assistants。开发者角色正在从纯粹实现，转向约束设计、上下文供给、agent 编排和结果验证。

但这只是第一层变化。

更深的变化是：当代码生产成本下降后，很多过去不值得做的信息系统，开始变得值得做。

过去做一个小系统，成本不只在写代码。要沟通需求，要设计数据模型，要写前后端，要接权限，要部署，要培训用户，要修 bug，要适应流程变化，还要长期维护。

一个小企业想做客户回款提醒系统，找外包公司不划算。一个小工厂想做质检异常闭环，买大型 MES 太重。一个养老机构想做护理记录和长护险结算，定制开发不划算。一个教培机构想做学生成长档案，标准 SaaS 又不贴合。

于是这些需求长期被压抑。

AI 辅助编程的意义，不是让大型系统便宜一点，而是让大量长尾流程第一次可以被系统化。

我把它叫做：

毛细血管信息化。

过去信息化主要发生在主干道：银行核心系统、大型医院 HIS、国家医保平台、大型 ERP、城市级政务系统、大企业 CRM。

未来信息化会进入毛细血管：某个社区的老人巡访，某个小工厂的质检流程，某个外贸公司的回款提醒，某个老师对学生长期学习状态的记录，某个律所的客户材料流转，某个药房的特药支付和处方核验。

这些系统每一个都不大，但数量巨大。它们对应现实世界里无数尚未被软件覆盖的流程。

软件正在从大机构的基础设施，变成具体流程的低成本管理层。

四、医院和商保，是一个非常好的样本

医疗支付是典型的信息管理问题。

患者看病产生的信息包括身份、诊断、检查、治疗、药品、耗材、费用、票据、病历、结算、医保报销、商保责任、历史疾病和用药记录。每一项信息都可能影响支付结果。

过去商保理赔麻烦，不是因为保险公司不知道用户希望快赔，而是因为它缺少可信、结构化、合规可用的数据链。

患者上传照片，保险公司要判断发票是不是真的，病历是否完整，诊断是否符合责任，药品是否属于保障范围，费用是否重复报销，是否存在骗保风险。

这等于保险公司要从一堆材料里重建现实。

当医保与商保一站式结算出现，信息网络就升级了。事实层记录患者是谁、费用是多少、医保报销多少、商保可赔多少。秩序层规定哪些机构有权读取哪些数据、谁来计算赔付、医院如何出具结算单、患者是否需要垫资。纠错层处理身份匹配错误、费用分类错误、责任判断错误、接口失败和欺诈风险。

这三层缺一不可。

创新药支付会把这个问题推向更深处。国家医保局关于“双目录”的文章提到，创新药支付正在从事后补偿延伸到全程服务，一些地方已经在探索“医保+商保”一站式秒赔和全流程数据对接。

这意味着医疗信息管理正在从“报销一笔钱”，变成“管理一条健康服务链”。

诊断、处方、购药、支付、用药、随访、疗效、不良反应、再次治疗、真实世界数据、保险产品迭代、医保目录谈判，这是一整条链。

没有信息，就没有精算。没有精算，就没有可持续产品。没有可持续产品，很多高值创新药就很难进入支付体系。

信息管理不仅提高效率，还会改变哪些事情可能发生。

五、中小企业真正需要的，不是 SaaS，而是刚好够用的秩序

中国大量中小企业不是没有管理，而是管理高度依赖人脑、微信群、Excel、口头承诺和个人经验。

客户信息在销售微信里。报价单在 Excel。合同在网盘。发票在财务电脑。回款靠老板追问。售后靠销售记忆。库存靠老员工知道。员工离职后，客户关系和历史信息一起消失。

过去很多人会说：上 CRM，上 ERP。

但现实中，中小企业常常上不起来。标准 SaaS 太重，字段不贴合，员工不愿意填，流程变动快，老板想要的报表又很个性化。

AI 辅助编程带来的机会，是让企业可以逐步长出刚好够用的信息系统。

不是一上来买一个庞然大物，而是从最痛的地方开始。

先把客户、合同、应收账款整理成一个小系统。再把销售跟进记录接入。再自动生成回款提醒。再接发票和银行流水。再生成每周经营报表。再把售后问题转成工单。再让 AI agent 每天巡检异常。

这个过程过去需要产品经理、后端、前端、运维、实施顾问共同参与。现在不代表完全不需要人，但每一步的成本会显著下降。

OpenClaw 这类 agent harness 的意义，也应该放在这里理解。它的关键不是聊天，而是把模型放进一个带有工作区、工具、技能、权限和长期上下文的运行环境。它不只是回答问题，而是能执行流程。

在企业内部，它可以成为一种“轻量信息系统工厂”。

老板说：每天早上列出超过 30 天未回款的客户。agent 去查合同、发票、收款记录，生成清单。

销售说：这个客户同意了新报价。agent 更新客户状态，生成合同草稿，提醒财务开票。

财务上传银行流水。agent 尝试匹配合同和发票，标记异常项。

售后收到客户投诉。agent 生成工单，关联客户、产品、合同和历史问题。

但这里有一个底线：

AI 可以帮助企业系统化流程，但不能替企业做业务裁决。

如果老板自己也说不清客户分类规则，如果销售不愿录入关键事实，如果财务数据本身混乱，如果公司内部权责不清，那么 agent 只能把混乱自动化。

信息系统不能凭空创造秩序。它只能把已有秩序显性化，把隐性秩序结构化，把混乱暴露出来，或者在坏情况下把混乱固化下来。

六、Agent harness 是微型制度生产机器

如果从《Nexus》的视角看，OpenClaw 或类似 agent harness 不应该只被理解成 AI 工具。

它更像一台微型制度生产机器。

因为它可以把自然语言中的意图，转化成表单、字段、数据库、流程、权限、脚本、报表、提醒、审批、审计、测试和文档。

一家企业原来靠微信群催款，agent 可以把它变成回款提醒制度。一家诊所原来靠护士记患者复诊，agent 可以把它变成复诊任务系统。一个小工厂原来靠老师傅判断设备异常，agent 可以把它变成巡检记录、异常分类和维修闭环。

这就是制度生产。

但制度生产有两面性。

好的制度可以降低摩擦、减少误判、保护弱者、提升效率、让责任清晰。坏的制度可以制造形式主义、增加填报负担、强化监控、固化偏见、把人困在不合理流程里。

AI agent 的危险在于，它很勤奋。它能不断生成流程、表格、指标、看板、规则、提醒。如果没有人类判断，它可能变成一个自动官僚。

自动官僚的特点是：它能把所有事情表格化，把所有行为指标化，把所有例外流程化，把所有沟通工单化，把所有人放进某种评分体系里。

但它未必知道这些东西是否接近现实，是否减少负担，是否提升智慧。

所以企业内部部署 agent harness 时，不能只问“它能做什么”，还要问：

它能看什么？它能改什么？它能代表谁行动？哪些动作必须人工确认？谁能修改它的规则？它引用的数据从哪里来？它生成的报表如何验证？它错了以后谁负责？它是否把管理者的偏见系统化？

一个真正可用的企业内部 agent harness，必须同时具备工具能力、权限边界、审计日志、沙箱环境、人工审批、数据治理和回滚机制。

没有这些，它只是一个很强但不安全的自动化入口。有了这些，它才可能成为企业信息管理的基础设施。

七、所有信息系统，都可以用三层模型看

为了把讨论落到实践，可以用一个三层模型理解信息管理系统：事实层、秩序层、纠错层。

事实层回答：发生了什么？

它包括数据、文档、记录、日志、表单、票据、病历、合同、代码、监控指标、聊天记录、邮件和交易流水。

事实层的关键标准是准确、及时、完整、结构化、可追溯。很多组织的问题，第一层就失败了。数据没有记录，记录不完整，字段口径不一致，关键事实藏在聊天记录里，系统里的数据和真实情况不一致。

事实层不稳，后面所有分析都会漂。

秩序层回答：这些事实如何改变行动关系？

一个客户欠款 60 天，这是事实。谁去催，什么时候催，是否暂停发货，是否进入风险名单，这是秩序。

一个测试失败，这是事实。是否阻断发布，是否通知负责人，是否回滚，是否记录缺陷，这是秩序。

信息系统最强大的地方就在第二层。它不是记录现实，而是组织现实。

这也是权力最容易隐藏的地方。谁定义流程，谁就在定义行动。谁定义指标，谁就在定义什么重要。谁定义权限，谁就在定义谁能看见、谁能行动。

纠错层回答：如果事实错了、规则错了、系统错了，如何发现和修正？

它包括测试、校验、监控、审计、申诉、人工复核、版本管理、回滚、异常处理、抽样检查、事故复盘和制度更新。

这是 AI 时代最关键的一层。

因为 AI 会加速事实层的生成，也会加速秩序层的生成。它能快速生成文档、流程、代码、规则、报表和审批节点。但如果没有纠错层，错误也会被快速放大。

未来信息管理最值钱的，不是事实层，也不是秩序层，而是纠错层。

真正成熟的人不会只问“能不能自动化”，而会问：

这个系统错了以后怎么办？

八、信息管理会从搜索，变成上下文供给

传统信息管理很大程度上围绕搜索展开。

资料很多，你来找。文档很多，你来搜。知识库很大，你输关键词。搜索结果给你，剩下自己判断。

AI agent 时代，这个模式会变。

因为用户往往不是想找资料，而是想完成任务。

帮我改这个模块。帮我排查这个 bug。帮我判断这个客户是否有回款风险。帮我生成本周经营报告。帮我看这个患者是否满足保险责任。

完成任务所需的信息，不应该完全靠人搜索，而应该由系统主动供给。

一个 coding agent 要修改支付状态机，它应该自动拿到相关需求背景、状态机文档、接口契约、数据库表结构、历史事故、下游依赖、测试用例、监控指标和上线回滚方案。

一个企业经营 agent 要生成回款报告，它应该自动拿到合同、发票、银行流水、客户信用记录、销售跟进记录、历史催款记录、账龄规则和异常标记。

这叫任务型上下文供给。

所以信息管理会从“文档整理”升级成“上下文基础设施”。

但这里也有危险。系统供给什么，AI 就基于什么行动。如果上下文错误，AI 会错。如果上下文缺失，AI 会猜。如果上下文过期，AI 会用旧现实行动。如果上下文没有权限边界，AI 会越权。

未来企业真正需要的，不只是知识库，而是可信上下文管理系统。

它要知道哪些信息最新，哪些信息废弃，哪些信息有权威来源，哪些只是讨论，哪些需要人工确认，哪些不能给 AI 看，哪些可以用于自动执行，哪些只能用于辅助判断。

九、最大风险：建成一个更高效的幻觉系统

到这里，不能只讲机会。

AI 辅助编程降低信息系统建设成本后，世界不会自动变好。我们可能得到更高效的医院结算、更精准的企业管理、更好的养老服务；也可能得到更多垃圾系统、更多形式主义、更多虚假指标、更多自动化压迫。

最大的风险不是没有信息，而是错误的信息被系统化。

过去一个员工误解规则，只影响局部。未来一个 AI 生成的规则进入系统，可能影响所有人。

过去一个老板拍脑袋，只影响一次会议。未来这个拍脑袋规则被写进自动审批流，就会长期运行。

过去一个基层单位为了应付检查做假表，只是一次性材料。未来 AI 可以每天自动生成看似完美的假秩序。

这就是高效幻觉系统。

它有数据，有报表，有看板，有流程，有自动化，有 AI 总结。但它不接近真实。它只是更快地产生一种看起来合理的秩序。

所以未来信息管理设计者必须不断问：

这个系统减少了现实摩擦，还是增加了填报？它让真实问题更早暴露，还是更容易被包装？它帮助一线工作，还是帮助上级制造控制感？它让弱者更容易申诉，还是让他们更难反抗系统判断？它能纠错，还是只会维护自己的权威？

十、未来最稀缺的角色：信息管理架构师

如果把前面的判断落到职业和商业机会，我会提出一个角色：

中小企业信息管理架构师。

这个人不是传统程序员，不是传统咨询顾问，也不是纯 AI 培训师。

他进入一家企业，观察信息流，找出关键事实散在哪里，识别哪些流程靠人肉记忆维持，判断哪些数据必须结构化，设计最小可用数据模型，用 AI 辅助编程快速生成轻量系统，部署内部 agent harness，建立权限、审计、备份、报表、提醒，把老员工经验转成规则和 checklist。

这个角色的价值不在于写多少代码，而在于判断：

什么值得系统化？什么不值得系统化？什么必须人工裁决？什么可以自动化？什么数据必须准确？什么流程会制造负担？什么指标会诱导造假？什么权限不能开放？什么动作必须留痕？什么错误必须能回滚？

AI 辅助编程越强，这个角色越重要。

因为实现成本下降后，真正稀缺的是判断力。

当任何人都能让 AI 生成一个系统时，问题就变成：

你生成的是一个好秩序，还是坏秩序？

结语：信息管理不是整理资料，而是建造现实

我们可以回到最开始的问题：信息管理为什么重要？

因为人类不是直接生活在现实里，而是生活在被信息网络组织过的现实里。

医院如何记录病人，决定病人如何被治疗和支付。企业如何记录客户，决定客户关系如何被维护。学校如何记录学生，决定学生如何被理解。政府如何记录基层，决定资源如何被分配。AI agent 读取什么上下文，决定它如何行动。

AI 辅助编程降低了建造信息网络的成本。这会释放巨大的社会生产力。医院和商保可以更好衔接，中小企业可以拥有刚好够用的系统，养老、教育、制造、基层治理、专业服务都可以被毛细血管式信息化覆盖。

但赫拉利提醒我们，信息网络不一定通向真理。它也可能通向幻觉、权力、官僚主义和失控。

所以未来最重要的问题不是“如何让 AI 写更多代码”，也不是“如何建更多系统”，而是：

我们要用这些低成本信息系统，建造一个更接近真实、更能纠错、更尊重人的现实，还是建造一个更高效但更虚假的秩序？

这才是信息管理的终极问题。

参考资料

• Yuval Noah Harari, Nexus: A Brief History of Information Networks from the Stone Age to AI, Random House 图书介绍：https://www.randomhousebooks.com/books/762444/
• Stack Overflow Developer Survey 2025, AI 部分：https://survey.stackoverflow.co/2025/ai
• Gartner, Gartner Says 75% of Enterprise Software Engineers Will Use AI Code Assistants by 2028：https://www.gartner.com/en/newsroom/press-releases/2024-04-11-gartner-says-75-percent-of-enterprise-software-engineers-will-use-ai-code-assistants-by-2028
• 国家医疗保障局，医保商保一体化同步结算平台已经开始上线运行：https://www.nhsa.gov.cn/art/2025/1/29/art_14_15596.html
• 国家医疗保障局，“双目录”机制启动：协同共治支持创新药高质量发展：https://www.nhsa.gov.cn/art/2025/7/15/art_14_17274.html
• OpenClaw Skills 文档：https://docs.openclaw.ai/skills

1

前几天，我跟一个学生讨论了一个问题：在证明自己和自我实现之间，应该怎样取得平衡？

我先问她，你在什么时候觉得自己证明了自己？

她说，对学生来说，最直接的就是取得成绩。小时候上台领奖，拿很多奖状，会觉得很自豪。现在也是，如果自己实现了同龄人还没有实现的事情，就会觉得这段努力是有效的。

这个回答很真实。

对很多学生来说，证明自己就是考出好成绩，拿到奖，发表论文，进入更好的学校，获得老师和同学的认可。再往后一点，证明自己就是找到好工作，升职加薪，买房买车，让别人觉得你过得不错。

我们从小就被这样的评价体系训练。小学有奖状，中学有排名，大学有绩点，工作之后有薪水、职级和头衔。每个阶段都有一个榜单，明着的或者暗着的。你在榜单上往前一点，就觉得自己更有价值。

这当然不是坏事。

人需要阶段性的证明。没有这些证明，我们很容易陷入迷茫，不知道自己到底有没有进步，也不知道自己过去的努力是否值得。

问题在于，如果一个人一直活在“证明自己”里面，他会越来越不知道自己真正想做什么。

2

那个学生刚发了一篇论文。对她来说，这是一个很重要的成果。

但是她说，自己当时其实有一点失落。

她第一时间把消息发到家里的群里，家人没有太多反应。妈妈私聊她，说弟弟快中考了，让她好好督促弟弟学习。爸爸在群里发的是自己五一出去兼职的照片。

她突然意识到，自己的喜悦好像没有人能够接住。

我对这种感受很熟悉。

升职加薪，工作做得不错，收入提高了，这当然是值得开心的事情。但是要跟谁分享呢？

跟父母说，他们不一定懂。跟兄弟姐妹说，关系未必到那个程度，而且别人可能会觉得你在炫耀。跟朋友说，朋友能不能真心为你高兴，也很难讲。

我自己很骄傲的一件事情，是阅读超过一万小时。以后如果到两万小时、三万小时，我也会很开心。但是这个喜悦更难分享。别人可能会说，读这么多书很厉害，可是这个能挣多少钱？

很多喜悦，注定只有少数人懂。

这一点越早接受越好。

小时候我们拿奖状回家，父母嘴上说不要骄傲，继续努力，但你还是能从他们脸上看到骄傲。长大之后，事情变复杂了。你的成就不一定符合他们的想象，他们也未必有能力理解你的艰难。

这不是谁的错。

人长大之后，就是要慢慢学会为自己保存喜悦，也学会寻找真正能理解你的人。

我写公众号，很大程度上就是这样。关注的人不多，经常读的人更少。但是我相信，在那些读者里面，总有十个二十个人，能够理解我为什么会因为阅读、写作、AI、编程这些事情感到开心。

有些知己未必认识你，也未必评论过你。他只是读到了，然后懂了。这样也很好。

3

证明自己，很多时候是向别人证明。

向父母证明，向老师证明，向同学证明，向面试官证明，向社会证明。

小时候，很多人听到的话是：你要争气。

这句话前面常常还有一个隐藏的主语：你要为爸爸妈妈争气。于是考一百分、拿第一名、考上好学校，不只是你自己的成就，也像是在完成家族里的某种使命。

这样的动力当然有用。

很多人就是靠着这股劲，一路读书，一路考试，一路从更小的地方走到更大的地方。如果没有“争气”这两个字，可能根本撑不到今天。

但是，证明自己终究只是一种任务。

考试是任务，拿学历是任务，找工作是任务，赚钱也是任务。这些任务很重要，因为它们给我们提供基本的生存条件和社会位置。

可是任务完成之后，人总要问下一个问题：然后呢？

如果我已经证明自己是一个合格的人，一个有能力的人，一个不比别人差的人，那我接下来要做什么？

很多人在这里卡住了。

因为他过去的人生一直在回答外部评价体系提出的问题。考试问他，你能考多少分？学校问他，你绩点多少？公司问他，你能创造多少价值？社会问他，你赚多少钱，住什么房子，配偶怎么样？

可是自我实现问的是另一个问题：你自己想成为什么样的人？

4

自我实现不是一个很好定义的词。

它肯定不是单纯地挣更多钱。钱很重要，我从来不反对挣钱。没有钱，人很难自由，也很难自律。但是对我来说，成为亿万富翁不是自我实现。

它也不是娶一个让别人羡慕的妻子，不是住大豪宅，不是开豪车，不是当大官。

这些东西不是不好，而是它们属于外部评价体系。别人看了会羡慕，亲戚朋友听了会觉得你混得好。但是如果你自己并不真正认同，它们就不是你的自我实现。

我更愿意这样理解自我实现：

发挥自己的创造力、想象力和聪明才智，做成一些自己认为有价值的事情，并且对他人产生积极影响。

比如，我如果能做出一个很好的开源项目，让很多人因此受益，我会觉得这是自我实现。

比如，我在阅读上持续进步，不只是自己读得开心，还能把学习和阅读的观念分享给更多人。哪怕只影响一两个人，让原本不怎么看书的人开始愿意看书，我也会觉得这件事有价值。

自我实现不一定轰轰烈烈。

它不一定要成名成家，不一定要改变世界，不一定要得到很多掌声。一个人做了自己真正认可的事情，并且让另一个人的生活变好了一点点，这就已经不是一件小事。

利他，是自我实现很重要的一部分。

人看到别人过得不好，会有恻隐之心。看到偏远地区的孩子吃午饭不方便，我愿意给免费午餐项目捐款。看到学生被应试教育困住，我愿意跟他们讨论学习和 AI。看到有人因为不知道怎么读书而痛苦，我愿意写文章分享自己的经验。

这些事情不一定能带来多大的世俗回报，但是它们会让我觉得，自己活得更像自己。

5

有意思的是，证明自己和自我实现并不是完全对立的。

很多人会把功利主义和理想主义分开。周一到周五是功利主义，晚上和假期是理想主义。先把现实任务完成，再用剩下的时间做一点自己喜欢的事。

这种安排很现实，也很容易理解。

但是我越来越觉得，理想主义不是功利主义之外的甜品。理想主义会反过来帮助一个人获得更大的现实成就。

如果一个人年轻的时候只想着进大厂、加班、刷题、跳槽、涨薪，他当然可能在短期里取得更好的收入。但是他可能没有时间阅读，没有时间探索，没有时间做那些看起来没什么用的事。

这些没用的事，将来可能会变得很有用。

我一开始用 AI 辅助阅读和思考，更多是出于兴趣，不是为了工作。后来 AI 辅助编程越来越流行，这种长期跟 AI 对话的习惯，反而让我更快适应新的工作方式。

阅读也是一样。很多书在读的时候并不知道有什么用。但是读得多了，理解能力、表达能力、跨学科思考能力都会慢慢增长。等到某一天机会出现，你才会发现，原来过去那些看似没有用的积累，都在暗处帮了你。

过度功利的人，看起来很聪明，其实容易失去主动性。

别人说什么有用，他就做什么。别人说什么没用，他就不做什么。学长学姐说这样，他就这样。老师说那样，他就那样。

听劝当然是优点。

但是一个人不能只有听劝。你还要有一些别人没有要求你做、甚至别人不理解但你仍然想做的事情。

这些事情，才可能把你的天花板往上抬。

6

回到那个学生身上。

她刚发了论文，接下来要把这篇论文写进简历，作为自己能力的重要证明。

我提醒她，一定要好好准备怎么讲这篇论文。

不是简单地说，我做了一个工具。也不是说，我很努力，做了数据清洗、代码实现和实验测试。

这些当然是真的，但还不够。

如果你想让别人理解这项成果的价值，就要讲清楚：

这个问题为什么重要。
已有最好的方法是什么。
你的工具相比它提升在哪里。
提升有多大。
这个过程中你真正贡献了什么。
你遇到的最大困难是什么，又是怎么解决的。

她后来讲到一个关键点：她的工具相比已有的冠军级求解器，在相同求解时间里，能求出五倍以上的结果。

这就是一句很有力量的话。

很多年轻人不是没有实力，而是不会证明自己的实力。明明做了很好的工作，讲出来却像是在描述一次普通作业。

这不是包装造假。

包装造假是把没有的东西说成有，把很小的东西说成很大。真正需要训练的表达，是把真实的信息组织成一个别人能理解、能相信、会被打动的故事。

尤其是在 AI 时代，一个人的成果会被更多审查。别人会问，这是不是你做的？是不是 AI 帮你写的？是不是导师安排好了你只是执行？是不是第二作者做了主要贡献？

你要经得起这些问题。

经得起问题，不是靠嘴硬，而是靠细节、逻辑和真实参与。

7

证明自己之后，年轻人还应该做什么？

我的答案是：把人生慢慢从外部评价里拿回来。

不是不考试，不发论文，不找好工作，不赚钱。不是这样。

这些事情仍然要做，而且要认真做。一个人连基本任务都完成不了，就很难谈自由，更难谈自我实现。

但是在完成这些任务的同时，要开始建立自己的评价体系。

你要知道，什么事情会让你真心开心。什么事情即使没人夸，你也愿意继续做。什么事情虽然现在看起来没有用，但你相信它会让你变成更好的人。什么事情能让你帮助别人，也让你觉得自己的人生更有意义。

证明自己，是从别人那里拿到一张通行证。

自我实现，是你拿着这张通行证，去走自己的路。

很多人拿到通行证之后，又急着去拿下一张。拿了一张又一张，最后忘了自己本来想去哪里。

这很可惜。

年轻的时候，证明自己很重要。因为你需要机会，需要资源，需要别人相信你。

但是越往后走，越要把问题换回来：

我想创造什么？
我想理解什么？
我想帮助谁？
我想成为什么样的人？

这些问题没有标准答案，也不会像考试一样给你明确分数。

可是，一个人真正的人生，往往就是从这些没有标准答案的问题开始的。

AI 编程的生产函数：当代码变便宜，什么变贵了

我想从一个反直觉的观察开始。

过去两年，关于 AI 编程的讨论里，最常见的说法是“AI 让程序员效率翻了 X 倍”。X 是多少不重要，反正大家都说这是一场效率革命。

但如果你认真追踪过这件事，会发现一个很有意思的现象——真正深入工程组织内部的人，反而很少这么说。他们说的是另一些东西：上下文工程、激励扭曲、token 通胀、锯齿能力、生产函数重排、判断溢价。这些词听起来都不像“效率翻倍”那么爽快，但更接近真相。

这群人里我最愿意追的一位，是 Gergely Orosz。他不是模型公司的人，也不是工具测评博主，而是一个长期在工程组织内部看问题的写作者——Uber、Microsoft、Skype、Skyscanner 他都待过。后来创办了 The Pragmatic Engineer，从 2023 年开始持续做 AI 编程的调研和报道，一路追到 2026 年。

为什么我觉得他的视角格外重要？因为他提供了一个稀缺的东西：一个有方法论、有时间纵深、有真实样本的工程现场观察。他既不站在模型公司的角度，也不站在职业焦虑的对立面，而是反复追问——这些工具到了真实工程组织里，到底怎样改变了工程师、团队、成本和度量。

这篇文章想做的，是把他这几年的观察提炼成一个可用的思维框架。我会用八个相互独立又彼此咬合的概念来组织：心理价格、锯齿能力、生产函数、上下文工程、token 通胀、指标黑洞、判断溢价、生产系统。

理解了这八个概念，你大概就能比 95% 关于 AI 编程的讨论看得更深一点。

一、心理价格：AI 编程的真正变化在哪里

先给一个数据序列。

Orosz 从 2023 年开始做开发者 AI 使用调研。第一年大约 170 多位工程师反馈，核心结论是“明显有用，但影响边界未定”。2024 年他记录到生成式 AI 工具被 75% 以上的工程师使用。2025 年这个数字是 85%，只有约 4% 的人说自己不用。到了 2026 年，95% 的受访者每周使用 AI，75% 称一半以上工程工作要用，56% 称七成以上要用。

光看数字会得出一个简单结论：AI 编程已经主流化了。但这个结论太浅。真正发生变化的，不是“用没用”，而是用 AI 时的心理价格。

经济学里有个概念叫心理账户，卡尼曼在《思考，快与慢》里讨论过。同样是损失十美元，“丢了一张电影票”和“丢了一张十美元钞票”在人脑中的核算方式完全不同。账面价格相同，心理价格不同，行为就不同。

AI 编程的真正转折，就发生在心理价格的翻转上。

2023 年我们用 AI 像用一个按小时收费的顶级律师——每次提问之前精心组织 prompt，生怕浪费一次调用。心态是“这个问题值不值得动用 AI”。2026 年的工程师早不是这种心态了，默认动作变成了“先让 AI 看一眼”，工作流变成“AI 跑一轮 → 出三个方案 → 我挑一个”。底层 token 价格未必整齐降了一百倍，但主观体验上，已经从“昂贵顾问”变成了“自来水”。

这个翻转的意义，比任何具体百分比都重要。它不是效率提升，是行为模式改写。

换句话说，AI 编程的第一阶段变化不在能力，在心理价格。当调用一次 AI 的心理成本足够低，工程师的整套工作流就会自动重排。能力跃迁是大事，但行为重排才是真正的范式变化。

二、锯齿能力——AI 不是均匀的杠杆

理解 AI 编程的第二关，是放弃“均匀提升”的幻觉。

很多讨论默认 AI 是个均匀工具，比如“提升 30% 效率”。但 Orosz 的观察反复指出一件事：AI 在不同任务上的表现差异极大，不是均匀提升，而是锯齿状提升。

我管它叫锯齿能力。意思是：AI 在某些任务上表现极佳，在另一些任务上几乎没用，在某些任务上甚至会把事情搞更糟。这不是“平均效率”能描述的，必须按任务类型分。

Orosz 的材料里给出过非常具体的分布：

高峰区——greenfield 项目、原型开发、小型工具、迁移脚本、测试补全、样板代码、文档生成、跨语言翻译。共同特征是：边界清楚、历史依赖少、上下文需求小、失败成本低。AI 在这里几乎是降维打击。

低谷区——大型既有代码库里的核心模块、高约束遗留系统、内部框架密集的环境、合规相关逻辑、跨团队接口。Orosz 在 LinkedIn 上专门写过：从 Google、Meta、Microsoft 等大公司开发者那里听到的反馈是，在二十年历史的核心服务里，AI 工具的价值常常远小于 greenfield 项目，很多人实际用法仍停留在 autocomplete。他还提到一个例子：某大公司给所有开发者配了 Cursor 许可证，几个月后约一半人停止使用。

反向区——AI 给出看似漂亮、实则绕过内部约定或重复实现的代码。副作用不在生成那一刻显现，而在数月后维护时显现。METR 和 Cursor 都做过类似研究，发现在某些大型开源任务中，使用 AI 的开发者实际花的时间反而更长。

锯齿能力解释了一个普遍困惑：为什么两个工程师对 AI 编程的体验截然相反？一个用 Cursor 周末做出小应用，觉得软件工程要被颠覆；另一个在公司核心服务里调几行代码反而更慢。两人讲的都是真话，差别在于他们抓到了锯齿上不同的齿。

所以评估 AI 编程不能问“它有多大用”，要问“在哪种任务上有多大用”。任何不区分任务类型的“AI 编程效率提升 X%”，本质上都在求一个无意义的平均数。

三、生产函数重排——瓶颈不会消失，只会迁移

经济学里有个概念叫生产函数，描述投入和产出的关系。

软件工程的生产函数大致可以写成：工程师时间 × 技能 × 团队流程 × 工具 × 代码库状态 → 软件产出。AI 进来之后，函数本身没有崩塌，但每一项的权重和性质都在重组。这个过程，我称之为生产函数重排。

Orosz 在多篇文章里呈现过同一个观察：AI 让代码生成速度大幅提升后，瓶颈并没有消失，而是迁移到了别的地方。他记录到的场景是：工程师写代码速度上来了，团队反而开始被 Product 和 Design 阻塞；Staff+ 工程师更多卷入 PRD 和上游产品定义，因为如果需求不清楚，AI 只会更快地产出错误方向的代码。

具体拆开来看：

工程师时间的重心从“实现”迁向“定义、审查、验证、处理例外”。亲手写代码的占比下降，定义任务、提供上下文、审阅 AI 输出、构造验证路径的占比上升。

技能的核心从“语言/框架熟练度”迁向“系统理解、产品判断、架构品味、AI 编排能力”。语法和样板可以让 AI 补齐，但“知道这段代码值不值得存在”无法外包。

团队流程从“围绕人写代码”重组为“围绕人和 agent 共同工作”。代码审查的对象从同事变成 agent 输出；CI 流水线要不要嵌入 AI 步骤；工具如何在团队间共享上下文——全是新议题。

工具从“编辑器”扩展为“能跨代码库、命令行、文档、CI、issue tracker 行动的半自主系统”。Orosz 反复强调，Claude Code 这类工具代表的是从“建议下一行代码”到“围绕任务操作工程环境”的范式跃迁。

代码库状态的权重急剧上升。测试完善、文档清楚、架构边界明确的代码库更容易被 AI 利用；混乱、隐式约定多、缺少测试的代码库会放大 AI 的错误。本来就在拉开差距的代码库质量，被 AI 放大得更厉害了。

一言以蔽之：AI 编程不是给生产函数加了一个常数，是把每个变量都换了一种性质。瓶颈从不消失，它只迁移。瓶颈在哪里，哪里就是真正需要投入注意力的地方。

四、上下文工程——AI 时代的新第一性原理

如果说生产函数重排是从外部看变化，那从内部看，最重要的新工作是上下文工程。

这个词不是我发明的，但在 AI 编程语境里，它被严重低估了。

所谓上下文工程，是指如何系统性地为 AI 提供它做出有效输出所需要的全部上下文——代码库结构、内部约定、业务规则、风险边界、验证标准。

Orosz 在多篇文章里反复提到这个主题。他讨论的“AI 工具在大型代码库里效果差”，本质就是上下文工程问题——大型代码库的上下文是隐式的、非文档化的、深度纠缠的，AI 拿不到，只能在表层瞎写。他关注 MCP（Model Context Protocol），也是因为这件事——MCP 之所以重要，不是因为它是个神奇协议，而是因为它代表了 AI 助手与真实工程系统之间的连接：代码库、数据库、文档、issue tracker、CI/CD、内部服务都可能成为 AI agent 可调用的上下文和工具。

上下文工程可以分三个层级，由浅到深：

第一层：Prompt 工程。告诉 AI“你要做什么”。最浅的一层，也是大多数人停留的地方。

第二层：环境工程。配置好“AI 能看到什么”——代码库结构、相关文件、已有约定、历史变更，通过 MCP、文件挂载、知识库等方式让 AI 接触到必要信息。

第三层：组织工程。设计好“AI 如何在组织里安全运转”——权限边界、敏感数据隔离、合规约束、审查流程。这是大公司真正卡住 AI 编程的地方，也是小公司能跑得飞快的原因——它们没这层包袱。

三层的难度指数上升。Prompt 工程人人能做；环境工程是工程师的活；组织工程是管理者、安全、合规、架构师一起才能干的活。

Orosz 在大公司案例里反复呈现的“工具很强，但用不起来”，本质上就是组织工程没解决。模型不是问题，让模型在公司既有约束下安全调动公司既有资源才是问题。

理解上下文工程，是从工具使用者升级为系统设计者的关键。AI 编程时代真正稀缺的能力，不是“会写 prompt”，而是“会工程化地为 AI 提供它需要的上下文”。这个能力越往组织层走越值钱，也越难。

五、Token 通胀——重演云计算 FinOps 的故事

现在谈一个非常具体也非常残酷的话题：钱。

Orosz 在 2026 年 4 月的文章里记录到，过去两三个月很多科技公司的 AI agent 花费在急剧增长。他采访了 15 家公司的人员，看到一些组织的 token 花费在 6 个月内增长约 10 倍，且没有放缓迹象。例子非常生动：有公司从原来每人每月约 200 美元的预算，涨到每人每月数千美元；有工程师每天在 Claude Code 上花数百美元；有团队把昂贵模型用在低价值任务上。

这就是 token 通胀——跟 2010 年前后的云计算成本失控几乎一比一对应。

云计算的故事大家熟悉。早期觉得云就是更灵活的基础设施，按需付费应该更便宜。过了几年发现账单失控——原因不是云本身贵，而是没人管：每个团队都能开实例，谁也没盯着关；每个项目都自己买带宽，谁也没归集；月底账单出来财务部门一片哀嚎。后来才有了 FinOps：预算归属、成本可见性、tagging、自动化关停、异常检测——本质上是给“花钱”补上一套组织肌肉。

AI 编程现在就是云计算的 2010 年。Agentic coding 工具不再是补全几行代码就走，它会反复读文件、生成计划、调用模型、运行命令、出错重试、再读上下文，每一次跑都在啃 token。消费从个人订阅小钱，变成了团队级、组织级的开支。但大多数公司目前的治理水平连云计算 2010 年都不如——因为云计算至少还有 instance ID、tag、归属组，AI agent 跑出来的 token 是谁的，谁也没答好。

Orosz 呈现了两派分歧：

Let it rip 派：先放开让工程师充分使用，再测量产出和质量。担心过早控费会扼杀效率跃迁。
Treasury 派：必须先建治理和上限。担心没有度量地放开会制造惊人浪费和扭曲激励。

两派都不完全对。但有一条共识：AI 编程的成本已经不是个人订阅级别的小问题，它是组织级别的财务议题，需要靠归属、可见性、异常检测、默认模型策略和 token 上限来管理。

过早控费会扼杀创新，过晚控费会引爆账单。正确答案不是选边，是承认这是一个组织治理问题，尽早建立 FinOps for AI 的能力。

六、指标黑洞——错误指标会制造错误行为

我对生产力指标有一个长期的怀疑，AI 编程时代把这个怀疑进一步加深了。

Orosz 和 Kent Beck 曾讨论过软件工程生产力指标的风险。核心论点是：一旦某个指标和金钱、地位、绩效绑定，人们就会游戏化它；越容易度量的东西，越可能不是最该优化的东西。这话放在 AI 编程上，来得特别快也特别狠。

Orosz 记录到一个现象叫 tokenmaxxing——当公司把“AI 用得多”当成先进性指标时，工程师就会最大化 token 消费。做法包括：故意运行 agent 来满足使用指标、把任务拆得更细以便切出更多 token、放着便宜模型不用而开高级模型、用昂贵工具做低价值活。他的判断很尖锐：tokenmaxxing 对 AI 厂商很好，对其他所有人都不好。

这就是指标黑洞。它的形成机制简单，破坏力却极强：公司想推动 AI 转型 → 选了最容易测量的指标（token 消费、采纳率、PR 数量、AI 接受率、工具登录次数）→ 指标被绑定到考核或战略汇报 → 工程师为了指标好看而调整行为 → 行为不再代表“AI 真的在帮组织赚钱”，而代表“AI 看起来在帮组织赚钱”→ 被污染的指标继续被用于决策 → 决策错误，资源浪费，但仪表盘上一切都很绿。

Orosz 和 Kent Beck 把开发者工作拆成 effort、output、outcome、impact 四层。越靠前越容易量化，越靠后越接近真实价值。AI 编程的陷阱是它显著增加 output（更多代码、更多 PR、更多 token），管理者容易误以为 impact 同步增加。但软件工程里，更多代码经常意味着更多维护负担。

那有没有什么指标值得追？从 Orosz 的材料里可以整理出一组互相制衡的方向：

关键不是找到一个神奇数字，而是建立一组互相制衡的指标体系。任何单一指标都会被游戏化。McKinsey 式的“努力和产出最容易测量”在 AI 时代变得更危险——因为 output 的虚假繁荣实在太容易制造了。

七、判断溢价——能力的相对价值正在重排

现在转到更宏观的层面：能力市场的重新定价。

Orosz 在 2026 年的文章里把工程师粗略分成三类：Builders、Shippers、Coasters——爱建系统的人、强烈交付驱动的人、维持现状的人。他的判断不是“AI 让所有人变强”，而是“AI 放大每种人原本的倾向”。Builders 用 AI 重构、补测试、清理技术债；Shippers 用 AI 把想法快速推向用户；Coasters 用 AI 制造“看起来完成了”的假象。

这个分法有点扎心，但它准。AI 不是公平的提升器，是放大器。有判断力的工程师变得更有判断力，没有判断力的工程师变得更没判断力。

这背后是一种系统性的重新定价——我叫它判断溢价。

当代码生成的边际成本逼近零，能力市场上原本被代码生产能力遮蔽的“判断类能力”就会显著升值：

• 把模糊需求变成清晰任务
• 给 AI 提供足够上下文
• 审查 AI 输出，识别幻觉和过拟合
• 设计可验证边界
• 判断“这段代码是否值得存在”
• 在大量 AI 候选方案中收敛
• 控制成本和资源

这些能力有一个共同特征——它们要求一个有 stake 的人。AI 可以推理，但不需要为推理结果承担后果；人推理同时承担后果，这是判断溢价的根源。

Orosz 呈现的一个细节让我印象很深：2026 年的调查中，staff+ 和 director+ 级别的人对 agentic 工具的热情非常高。这跟“AI 让初级工程师更受益”的常见叙事不太一样。但仔细想想很合理——越资深的工程师，越能把 AI 当执行层杠杆。他们知道要问什么、哪里危险、怎样验证、哪些输出不能信。AI 对他们不是替代思考，而是把思考转成更快的实验和实现。

对初级工程师，AI 是双刃剑。它能解释陌生代码、生成样板、帮助调试，加速学习；但也可能让人绕过最关键的成长环节——理解为什么这样写、哪里会坏、如何承担后果。Orosz 关注的“AI slop”现象，本质上就是学习路径错乱的产物：更多代码被生成，但质量、可维护性、上下文理解未必同步提高。

对个人的启示很直接：与其问“AI 会不会替代我”，不如问“我的能力组合有多少落在判断层”。落在判断层的越多，AI 越是你的杠杆；落在执行层的越多，AI 越是你的替代者。能力市场正在被 AI 重新定价，这种重新定价不是均匀的——它会把原本就在判断层的人推得更高，把困在执行层的人挤得更紧。

八、生产系统观——AI 编程是一场组织能力建设

到这里，我想把前面的概念串成一个总图。

如果只能用一句话总结 Orosz 这几年的判断：AI 编程改变的不是某个工具，而是软件工程的整套生产系统。

工具视角的提问方式是：哪个工具最强？哪个模型最准？哪个 IDE 最快？这种提问有价值，但它解释不了为什么同样的工具在不同公司里能产生差距如此巨大的结果。

生产系统视角不一样。它把 AI 编程拆成至少七个相互咬合的子系统：

这些子系统彼此耦合。指标子系统失灵会污染成本子系统；上下文子系统薄弱会拖垮工具子系统；治理子系统缺位会让任何工具都跑不起来。

这就是 Orosz 反复强调的：“最大问题不是工具不够强，而是上下文、治理和激励”。在大公司语境里，工具能力的边际收益已经很小，组织能力的边际收益才是主要变量。

生产系统观对管理者最有用。它把“我们要不要采购 Cursor”这种简单问题，升级为“我们的生产系统准备好让 AI 进入了吗”。它把“工程师 AI 采纳率多少”这种虚荣指标，升级为“我们的子系统之间是否在咬合，还是在打架”。

对工程师个人也有用。它告诉你，最该投资的能力不是某个具体工具的熟练度（那会很快被新工具替代），而是你在这七个子系统里的覆盖度——能不能既懂工具，也懂上下文，也懂验证，也懂成本，也懂指标，也懂治理。

九、把八个概念合起来：AI 编程现实主义的认知地图

把上面八个概念合在一起，可以画出一张认知地图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

心理价格翻转 → 行为模式改写 → 工作流被自动重排
       ↓
锯齿能力分布 → 任务类型决定收益 → 不能用平均数判断
       ↓
生产函数重排 → 瓶颈迁移而非消失 → 新瓶颈在判断层和组织层
       ↓
上下文工程 → AI 能力的真实边界 → 决定大公司能否真正用上 AI
       ↓
token 通胀 → 重演云计算成本失控 → 必须建立 FinOps for AI
       ↓
指标黑洞 → 错误指标制造错误行为 → 用一组互相制衡的指标
       ↓
判断溢价 → 能力市场重新定价 → 执行能力贬值，判断能力升值
       ↓
生产系统观 → AI 编程是组织能力建设 → 不是工具升级

这张图里没有“AI 会替代程序员”或“AI 改变一切”这种廉价判断，因为它没有解释力。有的是一组分析维度，让你面对任何具体问题时都能定位到合适的层次。

比如有人问“我们公司该不该买 Cursor”，你可以反问：你们的上下文工程做到第几层了？指标子系统会不会污染采购决策？成本治理能不能承受 agentic 工具的扩张？

有人问“AI 会不会替代程序员”，你可以反问：哪种程序员？做哪种任务？在哪种代码库里？落在判断层还是执行层？

有人问“我该不该让团队全员用 AI”，你可以反问：你的团队 Builders 多还是 Coasters 多？指标子系统能区分真假使用吗？打算用什么标准衡量 ROI？

这些反问不是抬杠。它们是在把问题从“是非题”还原为“分析题”。AI 编程从来都不是是非题。把它压扁成是非题的人，要么在卖东西，要么在自欺。

十、写在最后：保留判断力本身就是一种修炼

写完这八个概念，最想留下的不是任何具体结论，而是一种认知姿态。

AI 编程的浪潮是真的。它真的在改变工程师、团队、成本、度量和工具。Orosz 的调查数据从 75% 涨到 95%，Claude Code 两年内冲到一线工具，agentic coding 已经不再是未来时态。这些没有争议。

但越是浪潮汹涌，越需要保留一点判断力。

判断力的反面不是反对浪潮，是不被浪潮带着跑。当所有人都在喊“用 AI”，问一句“用来干什么”是判断力。当所有人都在追“采纳率”，问一句“采纳之后呢”是判断力。当所有人都在比“token 消费”，问一句“消费换来了什么”是判断力。

Orosz 这几年做的事情，本质上就是在替整个行业保留这种判断力。他不是反对 AI，是反对廉价的对 AI 的判断。他不否认浪潮，但始终把浪潮拆回到具体的工程现场——在哪种任务上有用？在哪种代码库里失效？在哪种激励下被扭曲？在哪种治理下能跑通？

这种“拆回到现场”的能力，在 AI 时代会越来越稀缺。因为 AI 让“看起来有道理”的内容变得太便宜了——每个人都可以让 AI 帮自己写出一篇“AI 编程的十大趋势”。当看起来有道理的内容泛滥，真正稀缺的反而是看穿这些内容、回到事实、回到现场的能力。

这种能力没法外包给 AI。它需要一个有限的、会承担后果的、长期身处现场的人来生长。

所以 AI 编程现实主义，最后落到的不是某个工具选择，也不是某个组织架构，而是一种个人姿态：在所有人都在加速时，留出一点不加速的时间；在所有人都在生成时，留出一点不生成的判断。

这不是反技术。它只是承认一件事——当生成变得便宜、判断变得昂贵时，最值得投资的不是更多 token，而是更清醒的自己。

而 Gergely Orosz 这几年在做的事，就是用工程现场的细节，反复提醒整个行业一件基本但容易被忘记的事：在浪潮里保持清醒，本身就是一种工程能力。

可能也是 AI 时代里，最被低估的那一种。

别把 AI 编程当成更快的打字机

我承认，我对最近这一两年关于 AI 编程的讨论是有点烦的。

这个烦不是说讨论本身错。是讨论的姿势不对。一边是模型公司发布会上的 demo，一个十二岁小孩用一句话就让 AI 写出一个完整的 SaaS，全场鼓掌；另一边是公司里跑出来的“AI 使用率排行榜”，工程师为了不显得落后于战略，每天往 Claude Code 里塞 token，塞得键盘都冒烟。两边看上去走在不同的方向上，其实是同一个毛病——都把 AI 编程理解成了更快的打字机。

打字机这个比喻我得解释一下。打字机这东西的好处是写得快，坏处是它不会替你想该写什么。如果你本来就不知道要写什么，打字机只是让你更快地不知道写什么。如果你是抄写员，打字机让你更快地抄；如果你是写情书的，它让你更快地写情书；如果你是骗子，它让你更快地骗。打字机不挑活，它只是提速。

我的同行里有一个叫 Gergely Orosz 的人，他写一份 newsletter 叫 The Pragmatic Engineer，本人在 Uber、Microsoft、Skype、Skyscanner 这些地方做过工程。这个人有意思的地方在于，他既不是模型公司的，也不是测评博主，是一个长期蹲在工程组织内部看问题的人。他从 2023 年就开始追这件事，一直追到今年，留下了一串能让人冷静下来的观察。我读他的东西比较多，越读越觉得，他做的事情其实很朴素，就是把“AI 编程”这台漂亮的打字机搬下台，重新放回工程现场，看一看它在真实的水泥和螺丝面前到底干了些什么。

这篇就是借他的视角，说说这个过程里被忽略的那些事。

一、有些热闹是真热闹，有些热闹是热闹本身

Orosz 自己每年做调研，都会把工程师拉来问一句：你用 AI 吗？

数字是越来越漂亮的。2023 年他征集了一百七十多份反馈，工程师普遍说“挺有用”；2024 年大约 75% 的人在用；2025 年到了 85%；2026 年这个数字飙到了 95%，其中 75% 的人说一半以上的工作要用，56% 的人说七成以上的工作要用。Claude Code 几乎一夜之间冲到最受欢迎工具的前几名，Anthropic 的模型挤掉了不少老牌选手。

这种数字看多了，第一反应是软件工程的天变了。第二反应是想想自己用没用，没用的话心里有点慌。第三反应才是问一句：这数字到底意味着什么？

有意思的是第三反应。

数字告诉你工程师在用 AI，但它没告诉你他们用 AI 干什么、用得怎么样、是因为有用而用还是因为不用就显得落后而用。这就好比一个数字说“今年有 95% 的家庭买了电饭煲”，你能据此推断出大家都吃上香喷喷的米饭吗？不能。这个数字也可能只意味着电饭煲卖得好，米饭可能照样夹生，照样烧糊，照样有人煮完一锅放冰箱里忘掉。

Orosz 自己很清楚这件事。他一边记下“使用率创新高”，一边在另一篇文章里冷冷地写：他在大公司工程师里听到的反馈是，公司给所有人配了 Cursor 许可证，几个月之后大约一半人不再打开它。这两件事看起来矛盾，其实根本不矛盾。很多人用 AI，是因为公司发了；很多人不再用 AI，是因为发现自己手头那活儿用了反而更慢。这两种人加起来，凑成一个漂亮的数字。

在我看来，数字的真正用处不是证明结论，而是提醒人去问一个尴尬的问题：这群正在使用 AI 的人，里头有多少人是真的因为它好用？

二、AI 是把锯齿，不是磨刀石

Orosz 在 LinkedIn 上发过一段话，意思大致是这样：行业里关于 AI 编程的成功故事很多，但没什么人愿意承认它在大型成熟代码库里的效果远不如 greenfield 新项目。他从 Google、Meta、Microsoft 等大公司开发者那里听到的反馈是，在公司里二十年历史的核心服务上，AI 工具的价值往往小得多，很多人实际用法仍然停留在 autocomplete，而不是完整的 agentic 开发。

这话听上去像泼冷水，其实它只是在描述事实。

我自己的体验和 Orosz 描述的差不多。一个周末，我在自己的小项目里让 Claude Code 跑一通，半天写出一个能跑的小工具，那种感觉像捡到钱。第二天回到公司，让同一个工具去改一个 2014 年遗留下来的服务里的几行代码，结果它得先理解六层封装的内部框架，再揣摩一堆没有文档的隐式约定，最后给出一个看起来对、实际上把上下游打穿了的 patch。我花在解释上下文、修补它的副作用、给它打补丁的时间，比我自己写还多。

为什么会这样？因为 AI 的能力不是均匀的。它不是那种“在所有任务上稳定提升 30%”的工具。它更像一把锯齿——某些齿很锋利，某些齿是缺口，某些齿甚至会反过来割到你。

锋利的那些齿，对应的是边界清楚、上下文少、试错成本低的活：原型、脚本、迁移、跨语言翻译、样板、CRUD、测试骨架、文档生成。这些活的共同特点是“做错了影响小，做对了不需要太多内部知识”。AI 在这种活上像猛兽。

缺口的那些齿，对应的是上下文重、约定隐式、依赖纵深、错了代价大的活：成熟代码库里的核心模块、性能敏感路径、跨团队协作的接口、合规相关的逻辑、长期演进的架构。这种活的关键根本不是“写”，是“知道这家公司这十年来为什么这么写”。AI 看不见这个十年。

会反咬人的那些齿，更微妙——AI 给出一份漂亮的代码，看上去比你能写的还工整，但悄悄绕过了一个你内部约定好的抽象，或者重复实现了一个已经存在的工具方法，又或者引入了一个微小的语义偏差，要等到生产事故那天才看见。这种代码合进主干的那一瞬间看着人畜无害，但它会变成你团队下个季度的维护噩梦。

理解这把锯齿的形状，比争论“AI 能不能替代程序员”重要得多。它解释了为什么两个工程师对 AI 编程的体验会差到完全相反的程度：一个人用 Cursor 周末做出小应用，觉得软件工程要完了；另一个人在十几年的老服务里调一行配置，被 AI 折磨到怀疑人生。两边讲的都是真话。差别只是他们各自抓的是这把锯齿上的哪个齿。

三、Tokenmaxxing：刷量这件事，永远不会缺席

我读 Orosz 的材料里，最让我笑出声的是一个词，叫 tokenmaxxing。

意思很简单：当公司开始把“AI 用得多”当成先进性指标时，工程师就会开始最大化 token 消耗。

这事本身的可笑之处在于，它太可预见了。任何在中国的 IT 公司待过几年的人，对“指标一旦挂在 KPI 上立刻就被刷掉”这种事简直是有肌肉记忆。代码行数、提交数、bug 修复数、CR 通过率、加班时长、周报字数、群里活跃度——所有这些指标，只要被官方拿去当评估，第二天它就不再代表它原本想代表的东西。它代表的是：员工知道这玩意儿被用来评估自己。

token 不过是这条长长清单里的最新一员。

Orosz 记录到的细节非常生动。他采访了十五家公司的人，看到有些组织半年内 token 花费暴涨十倍，没有放缓迹象。有公司的工程师每天在 Claude Code 上花掉数百美元；有公司从原来每人每月两百美元的工具预算飙到每人数千美元；有公司的开发者为了“AI 使用指标”运行 agent，把任务拆得越细越好，反正切出来都是 token；有公司把 Claude 这种昂贵工具用在打杂活上——这就像让外科医生贴创可贴，贴一次比挂一次专家号还贵。

Orosz 给 tokenmaxxing 下的定义我特别欣赏，他大致这么说：这件事对 AI 厂商很好，对其他所有人都不好。

这话翻译成大白话就是：当你开始用 token 数衡量“你的公司有多 AI”时，你已经把自己变成了 AI 厂商最好的客户，不管他们的产品有没有真的让你赚到钱。

我得插一句私货。我对这种事情的厌恶不只是因为浪费钱，更因为它羞辱了一线工程师。一个工程师为了不显得落后于公司战略，开始故意运行 agent、故意拆细任务、故意放着便宜模型不用而开高级模型——这不是他想这样，是组织逼他这样。逼他用一种他自己都觉得很傻的方式来证明自己跟得上时代。这种事情发生过太多次了。每一次都让人恶心。

所以 Orosz 在这件事上的判断我觉得是非常宝贵的：错误的指标会制造错误的行为。当一个组织把“用了多少 AI”本身当成目标，它就一定会得到一群擅长把 AI 用得“看起来很多”的员工。但这个组织真正需要的，从来不是 AI 用得多，是事情做得对。

这两件事经常被混为一谈。混着混着，钱就烧光了。

四、我们正在重演一遍云计算早期的故事

我对 token 失控这件事的另一个直觉是：这一幕我们看过。

云计算早期，公司一窝蜂上云。理由都很漂亮——弹性、按需、降本、提速。然后过了几年，账单到了，发现钱烧得比 IDC 还猛。原因不在云本身，而在没人管。每个团队都能开实例，谁也没盯着关；每个项目都自己买带宽，谁也没归集；老板看不到全貌，工程师没有归属感，财务部门看着月底账单只会念阿弥陀佛。

后来才慢慢出现 FinOps 这个东西，开始做预算归属、成本可见性、资源治理、tagging、自动化关停。本质上是给“花钱”这件事补上一套组织肌肉。云本身没变，变的是治理。

AI 编程现在差不多就是云计算 2010 年的样子。

现在大家还沉浸在“按个人订阅几十美元/月”的旧叙事里，觉得 AI 工具就是那点小钱。但 agentic coding 一旦普及，账单的形状是会变的。一个 agent 不是补全几行代码就走的，它是反复读文件、生成计划、调用模型、运行命令、出错重试、再重试的。它每跑一次都在啃 token。token 不再是个人订阅这种“小钱”，它成了团队级、组织级、跟人头数和任务复杂度强相关的开支。

更要命的是，这种开支没有云计算那种现成的归属机制。云资源至少还有 instance ID，还有 tag，还有归属组。AI agent 跑出来的 token 是谁的？某个工程师的？某个团队的？某个产品的？某个 CI 流水线里偷偷调起来的某个工具的？大多数公司目前都没回答好这个问题。

Orosz 在这件事上呈现的两种声音都值得听。一派是“let it rip”，先放开让工程师用，再测量产出，再讨论控费——他们的担心是过早控费会扼杀真正的效率跃迁。另一派是必须先建治理，否则 token 会变成新的浪费中心——他们的担心是没有度量地放开会制造惊人的浪费和扭曲的激励。

这两派谁都不全对。但我觉得有一条共识他们都该承认：AI 编程的“账单”问题已经不是个人问题了，是组织问题。是要靠治理、归属、可见性、异常检测、设默认值、加上限这些“不性感”的东西去管的。

那些以为只要选对模型就能解决一切的人，会在某个季度末被财务请去聊一聊。

五、绿地公司可以飞，老房子里还得修管道

Orosz 写过一段我特别认同的判断，大意是：AI 编程的红利，对小团队和创业公司更友好，对大公司则要复杂得多。

为什么呢？小团队的代码库新、约定少、决策链短、合规约束轻、试错速度快。一个有判断力的工程师加 AI，在这种环境里像是给一个少年装了喷气背包——飞起来之前他什么都没有，飞起来之后他什么都不缺。这就是为什么我们能不断看到“两个人做出原本五十人才能做的产品”这种故事。这些故事真的不假，但它们大多发生在没有历史包袱的地方。

大公司的处境完全不一样。代码库是十几年前几百号人攒起来的，里头有一堆只在公司内部传授的隐式约定，有一堆早已离职的工程师留下的逻辑黑洞，有一堆 PII 数据访问限制，有一堆合规审查流程，有一堆和上下游团队互相承诺过的契约。这种环境下，让 AI 写代码不是“让 AI 写代码”这么简单，而是“让 AI 在一栋你不愿意拆又不敢乱动的老房子里加一根新管道”。

老房子有老房子的尊严。它今天还能跑、还能赚钱，本身就值得敬畏。乱拆的代价远远高于多盖一栋新楼的代价。

Orosz 记录的事实是：很多大公司在 AI 工具上反应慢，并不是因为它们笨，而是因为它们必须处理安全、合规、预算归属、供应商锁定、数据治理、采购流程这些“不性感”的东西。这些东西看起来拖慢了创新，其实是公司能持续存在的原因之一。

这件事对个人选择也是有启发的。对一个想最大化享受 AI 编程红利的人来说，去一家能让你飞起来的小公司可能比待在一家管道复杂的大公司更划算。但对一个真正想理解软件工程长期形态的人来说，老房子里发生的故事才更值得看。

因为长期来说，世界上大部分软件，都是老房子。

六、Senior 比 Junior 更兴奋，这事你想过没

Orosz 在 2026 年的调查里有一个很反直觉的发现：staff+ 和 director+ 级别的工程师，对 agentic 工具的热情非常高。Claude Code 这种东西在他们当中受欢迎的程度，超过很多人的预期。

这跟我们平时听到的“AI 让初级工程师更受益”的故事不太一样。

我想了很久这个反差。我觉得它其实挺合理的。

资深工程师之所以更兴奋，是因为他们最清楚自己被卡在哪里。他们清楚自己手里那些“早就该做但一直没时间做”的活——补一个测试矩阵、清理一段技术债、把某个内部工具升级到现代版本、给一个野生的脚本加上 README、把某个模块重构得不那么离谱。他们脑子里有一个长长的待办清单，每一条都是“我知道这事重要但今天还有更紧的事”。

AI 进来之后，这种工程师手里的杠杆突然变长了。他们知道要做什么、知道哪些是坑、知道怎么验证，AI 只是替他们把“动手”这一步做完。这是天作之合。一个有判断力的人，加上一个肯干粗活的执行层，加起来就是一台真正运转得起来的机器。

初级工程师就尴尬一点。他们手里没有那张待办清单，他们手里只有公司布置的任务。AI 给他们的不是杠杆，是替代品——替他们写代码，替他们查错，替他们解释。看上去他们获得了更多，实际上他们失去了一段最重要的成长机会。

我说这话不是想吓唬谁。我是想说：AI 对人的放大作用，是双向的。你有判断力，AI 让你更有判断力；你没有，AI 让你更没有。那些最容易被 AI 替代的人，恰恰是那些把“会写代码”当成自己唯一卖点的人。会写代码这件事，正在快速贬值。但“知道什么代码值得写、什么代码不值得”这件事，正在快速升值。

Orosz 在文章里把工程师粗略分成 Builders、Shippers、Coasters 三类——爱建系统的人、强烈交付驱动的人、维持现状的人——并认为 AI 会把每种人原本的倾向放大。Builders 用 AI 重构、补测试、清债；Shippers 用 AI 把想法快速推向用户；Coasters 用 AI 制造“看起来完成了”的假象。这个分法听起来有点扎心，但我觉得它准。

世界从来不是公平地把好处发给每个人的。世界只是把放大器接到每个人身上，让他们原本的样子更明显一点。

七、写代码这件事，正在被重新定价

我自己写了二十多年代码。我一开始是觉得 AI 编程是个工具问题——选哪个工具、用什么 prompt、什么模型最好。但越往后越觉得，这事的真正变化不在工具，在身份。

写代码这件事，对一个工程师意味着什么？

它不只是产出。它是一种掌控感。你坐在屏幕前，世界乱糟糟的，但你这一片是你说了算的——光标在哪，函数怎么命名，这一行用 if 还是 switch，全凭你。你写的每一段代码都像一个微型协议：在这个范围内，世界按我说的办。这个掌控感，是工程师职业身份里非常底层的一块东西。

AI 拿走的，恰恰就是这种“我说了算”的那一段。它把代码生产从“我亲手做出来”变成“我审阅一份提案”。从产出者，变成裁决者。这是个很大的身份转变，比任何工资变化都要大。

Orosz 自己很坦白地写过这种感觉。他写到 2026 年初的某段时间，他发现新一代模型让他停止手写代码，因为让 Claude Code 写已经更快了。他既兴奋，也难受——兴奋是因为效率确实跳了一档，难受是因为他意识到一种自己曾经珍视的手艺正在被重新定义。这话我觉得说得很真诚。我也是这种感觉。

我不准备假装这种失落不存在。它存在。它真实。它对一个把代码当作自己人生一部分的工程师来说，是有重量的。

但我也不准备把这种失落浪漫化成“工匠精神被 AI 摧毁了”。坦白说，工匠精神不是手敲键盘，工匠精神是“对自己产出的东西负责到底”。一个工匠精神饱满的工程师，今天用 AI 写代码，但他愿意为最后那段代码的质量、风险、维护成本承担责任，他依然是一个工匠。一个工匠精神匮乏的工程师，就算他坚持每个字符都自己敲，他也不是工匠，他只是一个手感不错的打字员。

工匠精神在 AI 时代不死，只是它从“打字层”上移到“判断层”。从写每一行代码，转向定义问题、设计系统、审查质量、塑造产品、组织流程。code 这件事仍然在，只是它不再是工匠精神的唯一载体。

这件事对工程师个人来说有点冷酷，但也有点温柔。冷酷在于，那些只会写代码的人会越来越脆弱；温柔在于，那些懂系统、懂产品、懂取舍的人，会比任何一个时代都更值钱。

八、一个糟糕的问题：AI 会不会让程序员失业

Orosz 在这种问题上从来不直接回答。他更喜欢把问题拆开。

“会不会让程序员失业”这种问题，我觉得它和“汽车会不会让马车夫失业”是一样的。答案当然是会。但这个答案没什么用，它太粗了。它没告诉你具体哪种马车夫先失业，哪种工种从马车夫转成了出租车司机，哪种工种反而变得更稀缺（比如修车工、保险评估员）。

工程师这个职业内部，AI 影响是非常不均匀的。

有些活会被吃掉：样板代码、CRUD、迁移脚本、跨语言翻译、文档生成、原型搭建。这类活的共同特点是上下文少、风险低、规则明确，正好踩在 AI 的舒适区上。

有些活反而会升值：复杂系统设计、模糊需求的澄清、跨团队协调、生产事故处理、长期架构演进、对“什么是好软件”的品味。这类活的共同特点是上下文重、需要判断、需要有人承担后果。AI 在这里只能当参谋，拍板的还得是人。

所以问题不应该问“AI 会不会让程序员失业”，应该问“AI 让哪种程序员更脆弱、哪种更值钱”。

更脆弱的：把“写代码”当成自己唯一职业身份的那种人。一旦写代码这件事的边际成本降到接近零，他们就失去了唯一的支撑。

更值钱的：把“写代码”当成众多技能之一、并且把判断、审查、设计、协作、产品理解放在更高位置的那种人。AI 对他们来说不是替代，是杠杆。

我觉得 Orosz 的真正贡献，是反复在不同的文章里、用不同的角度，把这个分化讲清楚。他没说“程序员要完了”，也没说“程序员要起飞了”。他说的是：程序员这个职业内部正在分层，分得比以前任何时候都厉害。

这是个让人有点不舒服但更接近真相的判断。

九、给管理者的几句不太礼貌的话

我对管理者群体一直有点意见，是因为他们最容易把 AI 编程这件事理解错。

管理者最容易犯的错是：把“AI 转型”当成一次采购。

他们觉得，给每个工程师配一个许可证，再开几次“AI-first 战略宣讲会”，再在 KPI 里加一项 AI 使用率，事情就办完了。这种做法的失败是写在剧本里的。它失败不是因为 AI 不好用，而是因为这种姿势本身就把 AI 用废了。

Orosz 关于 tokenmaxxing 的报道已经把这种失败的轮廓画清楚了。把“用了多少 AI”当目标，工程师就刷量；把“生成了多少代码”当生产力，团队就制造更多代码；把“AI 采纳率”挂上绩效，员工就为了表演而使用。这些行为都是组织自作自受。它们不是工程师不诚实，是组织在用错误的方式问问题。

我对管理者的建议——虽然他们大概不会听——是把 AI 转型放回工程目标里。

别成天盯着“我们用了多少 AI”，去看客户价值是不是更快到了用户手里。别拿 AI 采纳率当绩效，看看缺陷率有没有在降。token 消耗对不对标同行不重要，长期维护成本可不可控才重要。至于工程师是不是都打开了 Cursor——你不如去问问他们，是不是比去年更满意自己的工作。

这些问题听起来不性感，写不出朋友圈金句，没法在年度汇报里做成一张漂亮 slide。但它们是真问题。AI 编程是真的能在这些问题上有所作为，前提是你愿意承认你想要的是这些，而不是看起来像 AI-first。

还有一件事。管理者得承认 AI 编程让代码更快出现的同时，也让坏代码更快出现。METR 和 Cursor 自己的研究都呈现过一个让人不舒服的结果：在某些情况下，使用 AI 的开发者实际花费的时间反而更长。Orosz 在引用这种研究时不是用来否定 AI，他是用来提醒：学习曲线、提示成本、等待成本、审查成本、上下文不完整，全都是真成本。它们不会出现在工具仪表盘上，但它们会出现在你下个季度的事故复盘里。

如果你只看仪表盘，仪表盘永远是绿的。问题在仪表盘之外。

十、一些尾声

写到这里，我得承认，我对 AI 编程的态度并不像表面上那么悲观。

我对它持有的是一种“现实主义的谨慎乐观”。乐观的部分是真的：它确实让一些事情成为了可能，让一些瓶颈消失了，让一些人找到了新的杠杆。我自己也是这其中的获益者之一。

谨慎的部分也是真的：它制造了一批新的指标陷阱、新的成本黑洞、新的组织扭曲、新的错误激励。我见过的公司里，不少是还没搞清楚怎么用，就先把“用没用”挂到了 KPI 上的；有些工程师还没建立起判断力，就把代码生成权交给了 AI；有些管理者还没问对问题，预算已经批下去了。

Orosz 这几年做的事情，其实是在反复提醒整个行业：别忙着兴奋。先停下来想清楚——你要的是什么、你怕的是什么、你打算把什么交出去、你打算自己守住什么。

这是工程现实主义。它不性感，不上头条，不会出现在融资材料的封面上。但它是少数几样在浪潮过去之后还能站得住的东西之一。

AI 编程是不是更快的打字机？我希望读到这里的人都已经能给出自己的答案。

它当然能让你打字打得更快。但如果你要的只是打字更快，那你大概率会在某一天发现，你打了一堆没有人需要读的字。打字机的悲剧从来不是它太慢，是它太快——快到让人来不及想清楚自己到底要写什么。

所以问题从来不是“AI 编程能不能让你更快”。问题是：当一切都变快之后，你打算用这些多出来的时间干什么。

如果答案是“想清楚一点点”，那么这场浪潮值得参与。

如果答案是“再多塞一点点 token”，那祝你好运。

毕竟，人这一辈子，能用来想清楚事情的时间本来就不多。AI 给你省下来的那点时间，最好别拿去刷指标。

AI 编程的组织议题：从工具采购到激励设计的一份从业者笔记

我打算用一种相对冗长且偏向行业内部视角的方式，写一份关于 AI 编程的笔记。这份笔记不是给营销人员看的，也不是给那些把 AI 当成奇观的旁观者看的；它是写给那些在工程组织里实际承担成本、做出采购决策、设计激励机制、并最终需要在年底向 CFO 解释钱花到哪去了的人。如果你属于这类人，那么我假设你已经读过足够多关于“AI 改变一切”的高层叙事，也已经对这种叙事产生了健康的怀疑——这种怀疑既不是反对技术本身，也不是出于职业焦虑，而仅仅是因为你在工程组织里待得够久，知道任何一项被宣传成“改变一切”的东西，最终都需要在采购流程、合规审查、预算归属、绩效考核和事故复盘里逐一证明自己。

带着这种从业者的视角，我想谈一谈 Gergely Orosz 这几年在 The Pragmatic Engineer 上对 AI 编程的持续追踪。我先声明，我不打算重复模型公司发布会上的口号，也不打算引用那些“工程师效率翻 N 倍”的耸动数字（这类数字的来源通常包含足够多的免责条款，使得它们在严格意义上几乎不可证伪也不可证实）。我想谈的，是 Orosz 在他的报道里反复呈现出来的那些“不太性感”的议题——上下文工程、token 治理、采购决策、激励扭曲与组织政治——也就是任何一个真正在工程组织里推动 AI 落地的人都绕不过去的议题。

在我观察到的范围内，Orosz 是少数几个在这一波 AI 浪潮里既不站队模型公司、也不站队反 AI 派、并且持续把工程组织本身作为分析对象的写作者。他的视角恰好是我自己最熟悉的视角——我职业生涯的大部分时间也都花在思考“为什么看起来明明很合理的工程实践，在真实组织里就是推不动”这类问题上。所以这篇笔记，与其说是对 Orosz 观点的转述，不如说是借他这几年累积的报道，把我自己长期想说但一直没系统说过的几件事讲清楚。

我会按七个相互关联的主题展开：采纳率叙事的可信度问题、锯齿能力的真实分布、上下文工程这个大公司核心瓶颈、token 治理的 FinOps 视角、tokenmaxxing 现象的激励经济学、判断溢价对人才市场的重新定价，以及生产系统视角下的管理者议程。每一节我都会尽量保持一种“把话说全”的写法——这意味着段落会偏长、限定词会偏多，也会包含一些基于个人经验的从业者注脚。如果你只想要一句话结论，这份笔记不适合你；如果你想理解为什么“一句话结论”在这个领域里几乎总是误导人的，那么请继续读。

一、采纳率叙事：那些漂亮的数字到底意味着什么

让我先从一组数字开始，这组数字本身是真实的，但围绕它们形成的叙事则需要被仔细审视。

Orosz 从 2023 年开始系统性地向工程师调研 AI 编程使用情况。第一年他收到约 170 份反馈，整体偏正面。2024 年他记录到生成式 AI 工具的开发者使用率超过 75%。2025 年这个数字升到 85%，仅约 4% 的人表示完全不用。到了 2026 年，他的样本里 95% 的工程师每周使用 AI，75% 的人称一半以上的工作要用，56% 的人称 70% 以上的工作要用。这些数字在表面上构成了一个无懈可击的“AI 编程已主流化”的故事。

但任何一个在工程组织内部待过几年的人，看到这种数字曲线，第一反应应该不是兴奋，而是好奇——好奇这些数字背后的真实采纳质量是什么。在我参与过的各类工具采购里，“采纳率”这个指标常常意味着两件完全不同的事情：要么是工具本身好用到工程师抢着用，要么是公司层面要求每个工程师必须用，至于他们用得有多深、用得对不对、用了之后有没有产出实际价值，这些问题往往被采纳率本身的光鲜数字遮蔽了。

Orosz 自己是清楚这一点的。他在 LinkedIn 上写过一段话——我已经在多个内部会议里把这段话当作清醒剂来引用——大致意思是：行业里关于 AI 编程的成功故事很多，但很少有人愿意承认它在大型成熟代码库里的效果远不如 greenfield 项目；他从 Google、Meta、Microsoft 这一类大公司的开发者那里听到的实际反馈是，在公司核心系统的语境里，AI 工具的价值往往明显小于它在新项目中的表现，许多人实际使用方式仍然停留在 autocomplete 这个相对浅的层面。他还提到一个具体例子：某大公司给所有开发者配了 Cursor 许可证，几个月之后大约一半人不再使用。

这两组事实（高采纳率与高弃用率）在表面上是矛盾的，但在工程组织内部却完全不矛盾。它们只是说明，“采纳率”这个指标在企业语境里早已被复杂的组织动力学污染——一部分采纳是真实的，一部分采纳是合规性的（比如战略宣讲后的姿态使用），还有一部分采纳是在 KPI 压力下产生的（这一点我下面会专门展开）。把这三种采纳混在同一个百分比里报告，相当于把“客户喜欢我们的产品”和“客户被迫订阅了我们的产品”混在同一个续约率里报告——它在数学上是正确的，但在管理决策上是有害的。

我对那些试图用采纳率证明 AI 转型成功的管理者，有一个相当一致的建议：在你拿出 95% 这个数字之前，请先回答三个子问题——这 95% 里有多少是工程师在做之前做不到的工作，又有多少是用 AI 做以前自己也能做的工作；这 95% 里有多少在过去三个月里产生了可以归因到 AI 的具体结果（比如缺陷率下降、交付周期缩短、客户问题更快解决），又有多少只是在仪表盘上贡献了好看的曲线；以及，如果你明天悄悄关闭所有这些 AI 工具，公司未来三个月的实际产出会受到多大影响——这是一个有点反直觉但非常有效的诊断方法，它绕开了所有关于“使用率”的故事，直接问“价值”这个本质问题。

如果这三个问题的答案让你感到不安，那么你的 AI 转型可能比你想象的更早地进入了 vanity metric 阶段。这并不是 AI 工具本身的问题——它是任何一项被组织正式推动的技术变革都会在某个阶段必然遇到的问题。承认这件事，是把转型从公关阶段推进到工程阶段的第一步。

二、锯齿能力：在哪种工作上有用，在哪种工作上无用

Orosz 反复强调 AI 编程能力的“锯齿状”特征——在某些任务上极其有用，在另一些任务上几乎帮不上忙，在某些任务上甚至会让事情更糟。这一点不只是修辞，它有非常具体的工程含义，而且这些含义对采购决策、人才配置和工作流设计都产生直接影响。

让我把这个分布说得更具体一些（基于我自己在不同规模公司里观察到的、也大致与 Orosz 报道的情况吻合的分布）：

AI 在以下任务上提供高确定性收益：原型开发、内部工具、迁移脚本、测试骨架、跨语言翻译、文档生成、低风险的小功能、CRUD 表单、样板代码、简单脚手架。这一类任务的共同特征是上下文需求小、规则相对明确、错误代价低、可逆性强。AI 在这里能稳定地把一项原本需要几小时的工作压缩到几分钟，这种压缩是真实的，并且通常能直接转化为团队产出。

AI 在以下任务上提供低且高度方差的收益：成熟代码库里的核心模块修改、跨服务接口变更、性能敏感路径优化、并发与一致性逻辑、合规相关代码、安全敏感模块、跨团队协作的契约层。这一类任务的共同特征是上下文重、隐式约定多、副作用范围大、错误代价高。AI 在这里偶尔有用，但其有用性高度依赖于工程师本人的判断力——也就是说，AI 在这里不是工具，而是放大器：放大判断力的存在或缺失。

AI 在以下任务上提供负收益：需要深度理解组织历史的架构决策、跨多个系统的根因分析、涉及业务和技术折衷的优先级判断、长期演进路径的设计、需要承担实际后果的发布决策。这一类任务里 AI 的输出往往看起来合理，但它无法承担后果，因此在严格意义上不构成可信输入；任何把这一层工作交给 AI 的人，本质上是把责任结构悄悄外包给了一个不存在责任能力的实体——这件事的长期代价通常会在某个事故复盘里显现，并且通常会让一个本来挺好的工程师承担本不该由他独自承担的责任。

我特别想强调这个三分法对人才配置的含义。在我经手过的几个工程组织里，最常见的错误是把 AI 工具均匀地配给所有工程师，然后期待整体产出均匀提升。这个期待几乎从不实现，原因正是因为锯齿能力的不均匀分布。一个更可行的做法（虽然在政治上更难推行）是先识别团队里哪些工作落在第一类、哪些落在第二类、哪些落在第三类，然后把 AI 工具的预算和组织注意力主要集中在第一类上，对第二类保持谨慎评估，对第三类明确不做激励——直到组织有了足够的上下文工程能力（下一节会展开）来把第二、第三类逐步往第一类的方向迁移。

这种做法的政治难点在于，它需要管理者承认“我们的 AI 转型不会让所有人均匀受益”。这种承认在很多公司是不被允许的，因为现行的转型叙事要求所有人都看起来同样兴奋。但在我观察到的范围内，那些愿意做这个承认的组织，最终在两到三个季度后展现出比那些追求均匀光鲜采纳率的组织明显更好的实际成果——这个差异不是因为他们用了更好的工具，而是因为他们对“工具有效边界”的认识更诚实。

诚实是一种被严重低估的工程能力。

三、上下文工程：为什么大公司用 AI 比小公司难十倍

Orosz 在多篇文章里都呈现过一个现象——AI 编程对小团队和创业公司更友好，对大公司则要复杂得多。这件事在表面上似乎可以归因于工具成熟度或开发者技能差异，但在我看来，它的根本原因只有一个：上下文工程。

让我把这个概念解释得更具体一些。AI 模型的能力是相对均一的——同一个 Claude Code 在创业公司和大公司里运行，模型本身没有差别。差别在于这两种环境下 AI 能“看到”的上下文完全不同。

在一个三个月历史、五千行代码、两个工程师维护的代码库里，AI 几乎可以看到一切——所有文件、所有约定、所有上下游依赖、所有测试。只要工程师愿意把代码库交给 AI，模型基本上可以建立完整的全局图景。在这种环境下，“agentic” 这个词是名副其实的：AI 真的可以围绕任务自主操作工程环境。

但在一个十五年历史、八百万行代码、三百个工程师维护、跨二十个内部框架、三千个内部服务、五十种部署管道的代码库里，“让 AI 看到一切”在物理上不可能、在合规上被禁止、在组织上没有人有权限做这件事。这种代码库里真正的工作上下文有相当大一部分是非文档化的——它存在于资深工程师的脑子里、存在于多年来的 Slack 历史里、存在于离职工程师留下的注释里、存在于和上下游团队达成过又被悄悄修改的口头协议里。这些东西不会自动进入 AI 的上下文窗口，而且在大多数情况下也无法以可信的方式被结构化输入。

这就是为什么 Orosz 反复呈现的那个现象——大公司给所有人配 Cursor 许可证、几个月后一半人弃用——在工程上是有合理解释的。它不是工具问题，也不是工程师问题，是上下文供给问题。模型再强，没有上下文它也只能写出“看起来合理但实际上忽略了三十个内部约定”的代码；而审查这种代码的成本，在某个临界点之后会超过工程师自己写的成本——这就是工具被弃用的真实原因。

那么大公司怎么办？这是一个真问题，而且没有简单答案。在我看来，大公司的 AI 编程战略不应该围绕“采购更好的工具”展开，而应该围绕“建设上下文供给系统”展开。这个系统至少包括三层：

第一层：可被 AI 检索的代码层上下文。包括代码库结构索引、内部框架的标准用法、约定库、设计模式库、历史决策的可检索文档。这一层的工作量巨大且没有捷径——它本质上是把过去十几年内部口口相传的 tribal knowledge 系统化沉淀。

第二层：可被 AI 理解的业务层上下文。包括产品规则、合规约束、SLA 条款、跨团队接口契约、关键不可变假设。这一层比第一层更难，因为业务上下文的迭代比代码快得多，文档天然滞后。

第三层：可被 AI 安全访问的运行时上下文。包括与生产数据的隔离机制、敏感操作的权限边界、审计日志、回滚路径。这一层是合规、安全、SRE 共同负责的工作，它决定了 AI 能否被允许进入工程流程的关键节点。

值得注意的是，这三层工作里，没有一层是单纯采购就能解决的。它们都是组织能力建设——需要长期投入、需要跨部门协作、需要对“什么是 tribal knowledge、它如何被沉淀”这个看似抽象的问题给出具体的工程答案。就我所见，那些把 AI 转型主要理解为“采购工具”的大公司，几乎无一例外地在 18-24 个月后陷入低效采纳的泥潭；而那些一开始就把它理解为“建设上下文供给系统”的公司，虽然前期看起来进展慢，但在第二年开始展现出可见的复利效应。

这不是巧合。这是工程上下文密度的本质属性——它无法被绕过，只能被建设。

四、token 治理：FinOps for AI 这件事到底有多严肃

接下来我要谈一个更具体的运营议题：token 成本。

Orosz 在 2026 年 4 月的一篇文章里详细记录了过去几个月许多科技公司 AI agent 花费的急剧增长。他采访了 15 家公司的工作人员，看到一些组织的 token 花费在 6 个月内增长约 10 倍，且没有放缓迹象。具体的例子他写得很细：有公司从原来每人每月约 200 美元的 AI 工具预算，涨到每人每月数千美元；有工程师每天在 Claude Code 上花数百美元；有公司发现开发者为了“AI 使用指标”运行 agent；有团队把 Claude 这种昂贵工具用在低价值任务上。

我对这个现象的看法相当直接：我们正在重演 2010-2015 年云计算成本失控的剧本，而且这一次的曲线可能更陡。

让我把这个类比说得更精确一些。云计算早期，企业普遍认为“按需付费”就是“少花钱”，这个误解的根源在于他们把“可以按需”和“会按需”混为一谈。实际发生的事情是：每个团队都获得了开实例的权力，但谁也没有关实例的责任；每个项目都自己买带宽，但谁也没归集；财务部门在某个季度末突然发现账单是预算的三倍，于是开始疯狂找谁该负责，但发现整个组织里没有任何一个人有完整可见性。FinOps 这个学科就是在这种历史背景下产生的——它本质上是给“按需付费的灵活性”补上一套组织肌肉，让花钱这件事重新可见、可归属、可治理。

AI 编程现在面对的成本结构问题，和当年云计算的问题在结构上几乎一致，但有几点更糟：

第一，单位成本的不透明度更高。云计算的实例费用至少是按小时×规格计费的，工程师可以大致估算成本。token 的消费则取决于上下文长度、模型选择、retry 次数、agent 行为等多个变量，工程师在调用之前几乎无法准确预估单次调用的成本。

第二，归属机制更弱。云资源至少有 instance ID、tag、project、cost center 这一整套归属链。AI agent 跑出来的 token 是谁的？是那个发起调用的工程师？是 CI 流水线？是某个内部工具？大多数公司目前在归属层面还停留在“看 API key 是谁的”这种粗糙水平。

第三，行为放大效应更明显。云资源的浪费通常是被动的（忘了关），AI 的浪费可以是主动的（agent 自己决定多 retry 几次、多读几个文件、多生成几个候选）。这意味着就算工程师本人完全没有恶意，agent 的行为模式仍然可能在不知不觉中把一次调用变成十次调用。

第四，激励错位的可能性更大。这一点我下一节会展开，但简单说，AI 工具厂商的收入与你的 token 消费成正比，这意味着工具的设计取向天然倾向于鼓励更多调用——这与你作为采购方的利益并不天然一致。

那么应该怎么做？我的建议是把“token 治理”从一个工程问题升级为一个 FinOps 问题，并按以下几个维度建设：

预算归属：每一笔 token 消费都应该可以追溯到具体的人、团队、项目、任务类型。这听起来基础，但大多数公司目前做不到。

可见性：管理者和工程师本人都应该能看到自己最近的 token 消费曲线。以我的经验，仅仅“让工程师看到自己花了多少钱”这一项，就能在前两周显著降低 30-50% 的不必要消费。

默认值：默认模型应该是性价比最高的，而不是能力最强的。能力最强的模型应该是工程师明确选择的，而不是默认推送的。

异常检测：单个工程师/项目的 token 消费如果在一周内陡增 X 倍，应该自动触发告警。这件事不需要复杂的 AI——简单的统计阈值就够了。

上限：每个团队应该有月度 token 预算上限，超出需要明确审批。这不是为了省钱，是为了让“花钱”这件事重新进入决策视野。

关于 ROI 的诚实评估：定期把 token 消费曲线和工程产出曲线（速度、质量、缺陷率、客户满意度等）放在一起看。如果两条曲线长期不相关，说明 AI 投资没有产生工程价值，这件事必须被严肃讨论而不是被掩盖。

Orosz 在他的报道里呈现了行业里的两派分歧——let-it-rip 派认为应该先放开使用、再讨论控费，财务管控派认为必须先建立治理、再放开使用。这两派各有道理，但我个人倾向于一种中间立场：先放开使用是合理的，但放开的同时必须把可见性建好。换句话说，让工程师试，但所有的试都被记录在案、可被分析、可被回顾——这样在三个月后做评估时，你才有真实的数据基础来判断哪些用法值得保留、哪些应该停掉。

没有这一层基础，任何关于“AI 是否值钱”的讨论都只是猜想。在企业语境里，猜想是高级别管理层的特权，但它不是工程组织该用的决策方式。

五、tokenmaxxing：当指标变成激励，激励变成行为

我现在要谈一个 Orosz 创造或者至少推广的术语，叫 tokenmaxxing。

它的定义大致是：当公司把“AI 用得多”当成先进性指标或绩效信号时，工程师会开始故意最大化 token 消费——通过运行不必要的 agent、把任务拆得更碎、用昂贵模型做廉价活、放着便宜替代品不用而开高级模型。Orosz 在他的报道里给出过一个非常精炼的判断，大意是说这件事对 AI 厂商很好，对其他所有人都不好。

这个现象在我看来不是 AI 时代独有的，它只是一个非常古老的组织行为学规律的最新版本：任何被绑定到激励的指标都会被游戏化。Goodhart’s Law 早就说过这件事——当一个度量成为目标，它就不再是一个好度量。

让我把 tokenmaxxing 的形成机制写得更精确：

战略叙事。公司高层希望对外（投资人、董事会、媒体）和对内（员工、合作伙伴）展示“AI-first”。这本身没有问题——这种叙事在 2025-2026 年是合理的市场动作。

寻找指标。战略叙事需要可被汇报的进展。最容易被汇报的是采纳率、token 消费、活跃用户数、AI-generated PR 数量这一类指标。它们的好处是数字能涨、能做成 slide、能在年度汇报里展示出曲线。它们的坏处是它们与工程价值的关联度极弱。

绑定激励。指标进入团队 OKR、部门考核、甚至个人 KPI。这一步是分水岭——一旦指标被绑定到激励，下一步就不可避免。

行为调整。工程师为了在这些指标上看起来好看，开始调整行为：故意多调用 agent、用昂贵模型做简单活、把一个任务拆成五个 PR 以提高 PR 数、在不需要 AI 的地方使用 AI 以提高采纳率。这些行为在工程师层面是完全理性的——他们只是在响应组织发出的激励信号。

决策污染。被污染的指标继续被高层用来做战略决策。基于“采纳率提升 50%”，公司决定增加 AI 工具预算；基于“token 消费翻倍”，公司证明转型正在加速。这些决策建立在已经被污染的数据上，因此它们与真实的工程价值脱钩。

反噬。在某个时间点（通常是预算审查或事故复盘），公司发现 AI 投资与产出的关联度远低于预期。这时候责任通常被归到“工具不够好”或“工程师不会用”，而不是“激励设计错了”。然后公司启动新一轮工具采购或培训，整个循环重新开始。

这个循环我经历过不止 AI 这一个版本——过去几年的低代码、再往前的 DevOps 转型、再往前的敏捷转型，都走过类似的路径。每一次的关键失败点都不在工具或工程师，而在第二、第三阶段——选错了指标、错误地绑定了激励。

tokenmaxxing 之所以特别有破坏力，是因为它的反馈延迟特别长。云成本失控会在月底账单上立刻显现，技术债会在下次发布事故里显现，但 AI 投资 ROI 的真实信号通常要 6-12 个月之后才能看清——而这段时间里，被污染的指标会持续制造“一切顺利”的假象。

我对管理者关于 tokenmaxxing 的建议（虽然我承认这种建议在大多数公司不会被采纳）非常具体：

不要把 token 消费、AI 采纳率、AI-generated PR 数量绑定到任何形式的考核或汇报。这些指标作为“可见性数据”是有价值的，但作为“激励信号”是有害的。一旦它们进入考核，它们就会被游戏化，从那一刻起它们停止反映真实情况。

衡量 AI 的价值要回到工程结果本身：交付速度、缺陷率、change failure rate、客户问题解决时间、开发者满意度。这些指标本身也会有问题，但至少它们是“组织真正想要的东西”的近似——而采纳率不是。

如果一定要衡量 AI 使用，至少分类衡量：区分高价值场景（边界清晰、ROI 可证明）和低价值场景（agent 自己决定多跑几次的那种）。把整体 token 数当成单一指标，等于把客户支付的钱和员工随手刷的钱算在一起。

在组织层面接受一个不舒服的事实：在 AI 转型的前 12-18 个月，最重要的“成果”可能是搞清楚“什么不该做”，而不是“做了多少”。这种姿态在很多公司不被允许，但它是少数几个能避免长期 ROI 灾难的姿态。

这些建议不会让人兴奋，但它们大概率比下一次工具采购更值钱。

六、判断溢价：工程师劳动力市场的一次安静重排

我现在要谈一个更长期的问题：工程师劳动力市场正在发生的重新定价。

Orosz 在 2026 年的一篇文章里把工程师粗略分成三类——Builders、Shippers、Coasters——并指出 AI 不会让所有人均匀变强，而是会放大每种人原本的倾向。这个分法听起来像是性格描述，但在我看来它更接近一种能力组合分类：Builders 倾向于把 AI 用作系统建设的杠杆，Shippers 倾向于把 AI 用作交付加速器，Coasters 倾向于把 AI 用作维持现状的便利工具。

更宏观地看，这个分化反映了一个更基本的事实：当代码生产的边际成本逼近零时，工程师劳动力市场上“代码生产能力”的相对权重会下降，“判断类能力”的相对权重会上升。我把这个现象称为判断溢价。

什么是判断类能力？我觉得它至少包括：

• 把模糊的业务需求转化为清晰可执行任务的能力
• 设计可验证的输出边界和成功标准的能力
• 在大量 AI 候选输出中识别出真正可信的那一个的能力
• 识别 AI 幻觉、过拟合、或绕过内部约定的能力
• 判断“这段代码值不值得存在”的能力
• 在系统层面预判一个变更可能引发的副作用的能力
• 在跨团队、跨系统、跨时间尺度上做合理折衷的能力
• 在事故发生时定位根因并设计预防机制的能力
• 在不完整信息下拍板的能力，并愿意为这个拍板负责

这些能力都有一个共同特征——它们要求一个有 stake 的人来执行。AI 可以推理，但它不需要为推理结果承担后果；人类可以推理同时承担后果，这个差异在 AI 时代变得格外珍贵。

Orosz 调查里那个反直觉的发现——staff+ 和 director+ 级别的人对 agentic 工具最热情——在判断溢价框架里完全可以解释。资深工程师之所以更兴奋，是因为他们最清楚自己被卡在哪里：他们手里有一长串“知道该做但没时间做”的任务清单（重构、测试矩阵、技术债清理、内部工具升级），AI 给了他们一个把这些清单消化掉的杠杆。他们的判断力和经验不被 AI 替代，反而被 AI 放大——他们提供的是“做什么、怎么做、什么算完成”，AI 提供的是“动手”。

而初级工程师面对的情况则相反。他们手里没有那张清单，他们手里只有公司布置的任务。AI 给他们的不是杠杆，更接近替代品——替他们写代码、查错、解释。这种替代在短期内看起来加速了产出，但长期看会让他们绕过最关键的成长机会：理解为什么这样写、哪里会出错、如何承担后果、如何在一个有限信息的真实系统里做判断。这就是 Orosz 关注的“AI slop”现象的本质——更多代码被生成，但工程判断力没有同步增长。

判断溢价对工程师个人职业策略的含义相当直接：

短期（未来 12-24 个月）：AI 工具的熟练度本身有一定的市场溢价，因为还有相当一部分团队在补这个缺口。值得投资，但要意识到这个溢价的窗口期不会太长——工具熟练度本身会快速贬值，因为它太容易被新工具替代。

中期（未来 2-5 年）：判断类能力的市场溢价会显著扩大，特别是那些能跨“代码 + 系统 + 业务 + 组织”四个维度做判断的工程师。这种 T 型甚至 π 型能力组合，在 AI 时代会成为定义 senior 级别的真正标准——不再是“能写多少行代码”，而是“能保障多少行代码值得存在”。

长期（5 年以上）：那些把“会写代码”作为唯一职业身份的工程师会面临结构性挤压。这不是说他们会失业，而是说他们的市场价位会从原本的“高于平均”逐步回落到“平均或以下”。这件事不会一夜之间发生，但它的方向是确定的。

判断溢价对组织人才策略的含义同样具体：

招聘：以“代码量”或“语言/框架熟练度”作为主要筛选标准的公司会越来越多地招到错的人——招到的是擅长写代码的人，但需要的是擅长判断的人。招聘流程里需要明确加入判断类能力的考察，比如系统设计、需求拆解、风险识别、跨系统决策等。

晋升：如果晋升标准里“代码产出”权重过高，组织会自动把判断力强的人推离他们最该做的工作。判断力强的人往往代码量不会比 AI 加持的初级工程师多，但他们的工作不能用代码量衡量。

培养：初级工程师的成长路径需要重新设计。如果把“先写大量代码积累手感”作为默认培养路径，AI 会让这条路径在工程意义上失效。新的路径需要更早引入“判断、审查、负责”的训练，可能甚至需要刻意限制 AI 在初级工程师身上的使用，以保护他们最关键的成长窗口。

这些事情不可能速成，需要长期投入，短期内看起来也会与 AI 转型的主流叙事格格不入。但它们是组织在 AI 时代真正需要做的人才工作。

七、生产系统视角：管理者真正该上的议程

我把上面六节的内容收拢一下，提出一个我认为管理者应该认真对待的议程框架。

绝大多数关于 AI 转型的管理者议程都太简单了——它们大致长这样：“采购一批 AI 工具 + 给所有人配许可证 + 在 KPI 里加一项 AI 使用率 + 季度汇报里放一张采纳率曲线”。在我观察到的范围内，这种议程几乎无一例外地在 12-18 个月后陷入虚荣指标困境，最终需要重启。

更靠谱的议程不应该围绕“工具采购”展开，而应该围绕“生产系统重构”展开。生产系统视角把 AI 转型理解为对一整套工程生产流程的重新设计，而不是对其中一个工具节点的替换。在这个视角下，管理者的真正议程至少包括以下几项工作：

明确 AI 在不同任务类型上的定位。基于锯齿能力的真实分布，明确告诉团队哪些场景鼓励大胆使用 AI、哪些场景使用 AI 时需要更严格的审查、哪些场景明确不依赖 AI。这种分类不应该是抽象原则，而应该是写在内部 wiki 上的具体清单。

建设上下文供给系统。这是大公司能否真正用上 AI 的核心瓶颈，需要长期投入。包括代码层、业务层、运行时层的三层上下文工程，每一层都需要专门的负责人和路线图。把这件事当成“文档完善工作”来做的公司，三年后会发现自己什么都没做出来；把它当成“基础设施建设”来做的公司，会在第二年开始享受复利。

建立 FinOps for AI 能力。把 token 治理升级到与云成本治理同等的严肃程度。包括预算归属、可见性、默认值、异常检测、上限、ROI 评估。这件事的前期投入不大，但它是少数几件能让 AI 转型在两年后不变成预算灾难的事情。

重新设计指标体系。明确放弃把“AI 使用率”和“token 消费”作为激励指标，回到工程结果本身（交付速度、质量、缺陷率、开发者体验、客户价值）。在这一过程中，要做好心理准备——短期内你的“AI 转型成果汇报”会比同行难看一些，因为你不再追求那些容易做出来的虚假数字。但你的工程组织会因此保持健康。

实施分级的人才策略。承认 AI 对不同 seniority 的工程师产生不同影响。资深工程师应该被鼓励大胆使用 agentic 工具去清理他们手里的存货；初级工程师的 AI 使用应该被有意识地节制，以保护他们的成长窗口。这件事在政治上很难——它会让人误解为“对初级工程师不公平”——但它是负责任的人才工作。

升级代码审查、测试、发布的工程实践。当代码生产速度上升 N 倍，下游的审查、测试、发布流程必须同步升级，否则瓶颈会迁移到这些环节并造成系统性堵塞。具体包括：审查标准是否需要提高、测试覆盖率的最低线是否要上调、发布灰度策略是否要更保守、回滚能力是否要更强。这些工作的投入回报不在“我们用了多少 AI”上，而在“我们的事故频次有没有保持低位”上。

定期做诚实的 ROI 复盘。每个季度（不是每个月，那太频繁；不是每年，那太晚）拿出一个工作日，把这个季度的 AI 投入（钱、人时、工具采购）与产出（具体的工程结果）放在一起对比，并允许团队明确说出“这部分投入没产生价值，下季度停掉”。这种复盘的价值不在于纠正具体决策，而在于它是组织文化层面的一种诚实承诺——承认 AI 转型不是一次单向加速，而是一个需要持续校正的长期工程。

我承认这份议程比“采购 + 配许可证 + 上 KPI”难得多、慢得多、也无聊得多。它不会出现在融资材料的封面上，也不会让 CEO 在年度汇报里发出激动的总结。但它是少数几件能让你的组织在三到五年后真正从 AI 中获得复利的事情。

而且——这一点我觉得在 2026 年这个时间点尤其重要——做这件事的窗口正在快速收窄。当 token 通胀的曲线持续陡峭、当虚荣指标越来越普及、当全行业的 ROI 焦虑开始浮现，那些已经把生产系统重构做扎实的组织会展现出明显的相对优势；而那些还在为下一份 AI 工具合同和下一份采纳率汇报忙碌的组织，会越来越发现自己被困在一个看起来很忙、实际上没动的状态里。

八、一些克制的尾声

我写这份笔记的目的，不是反对 AI 编程，也不是给 AI 转型泼冷水。我自己日常工作里大量使用 AI 工具，并且能感受到它们带来的真实生产力提升——这种提升是真的，不是叙事。

但与此同时，我也观察到这场浪潮里大量被忽略的组织议题。这些议题不吸引眼球、不上头条、不会出现在模型公司的发布会里，但它们决定了一家公司在 AI 转型上是真的在前进，还是只是在制造前进的样子。Orosz 这几年最有价值的工作，就是把这些被忽略的议题反复拽到台前——上下文工程、采购流程、token 治理、激励扭曲、生产系统重构。这些议题不是 AI 编程的反面，它们是 AI 编程在工程组织里能否真正落地的前提。

如果一定要我给这份笔记一个一句话的收束，我会说：AI 编程的胜负不在模型层，而在组织层；不在工具采购，而在系统重构；不在采纳率，而在判断力。任何把这件事处理成简单工具问题的公司，都会在两到三年后用具体的代价学到这个道理；那些一开始就把它当成组织能力建设的公司，会在同一时间点开始收获复利。

这两种结果的差距，最终不会显示在 token 消费曲线上，而会显示在更长期的工程质量、人才结构、和组织韧性上。这些东西在仪表盘上看不见，但在五年之后看得见。

而五年——以软件工程的尺度——并不算长。

和系统共舞：当 AI agent 走进软件这架活机器

我想说的其实很简单：

AI coding agent 没有让软件工程的基本功过时。它只是把系统里的水流拧大了。

水流变大以后，真正重要的问题不是水从哪里来，而是岸够不够清楚，闸门够不够灵，排水口够不够快。换成软件工程的话，就是：代码生成变快以后，测试、构建、评审、监控、架构边界、团队学习，能不能跟上。

这就是 Birgitta Böckeler 在 Martin Fowler 网站上那篇《Harness engineering for coding agent users》真正有价值的地方。文章署名是 Böckeler，不是 Fowler 本人。她属于 Thoughtworks，而 Fowler 长期在那里工作。所以我下面说 Fowler / Thoughtworks 这一脉，指的是一种工程思想生态，不是把文章误归到某一个人名下。

这篇文章用一个词概括 AI 时代的软件工程：harness。

我愿意把它翻译成：让力量有形状的东西。

一、软件不是仓库，是池塘

我们平时说代码库，很容易把它想成一个仓库：文件放在里面，谁需要谁取出来，改完再放回去。

但这不是代码库真实的样子。

代码库更像一片池塘。它看起来安静，其实一直在流动：需求进来，代码进来，bug 进来；测试修掉一部分 bug，重构排掉一部分债务，部署把一部分变化送到用户手里；人来了又走，知识被写进文档，也会慢慢过期。

你只看一个 commit，会觉得那只是几行代码。你拉长时间看十年，会看到一个会生长、会老化、会积累记忆、也会遗忘的活系统。

AI agent 走进这片池塘以后，发生了什么？

它没有把池塘变成机器。它只是让一条水流突然变快了：写代码这件事，变得更便宜、更快、更容易批量发生。

问题也就从这里开始。

二、系统里最危险的事，是只放大一条流

系统思考里有三个很朴素的词：存量、流量、反馈。

存量，是某一刻可以数出来的东西。代码行数、模块数量、未解决的 bug、技术债、测试用例、文档、团队成员的脑容量，都是存量。

流量，是让存量增加或减少的动作。提交代码、修复 bug、删除依赖、补测试、写文档、做复盘，都是流量。

反馈，是系统发现自己偏了以后，把它拉回来，或者继续推着它往前走的力量。类型检查、单元测试、CI、code review、监控告警、事故复盘，都是反馈。

AI agent 主要改变了哪一个？

它主要放大了“提交代码”这条流。

这当然很有用。可是任何系统都怕一件事：只放大流量，不增强反馈。

水龙头变大，排水口没变，浴缸会溢出来。城市扩张很快，下水道没跟上，雨季就会内涝。软件也是一样。

如果写代码的速度提了十倍，但测试反馈、构建反馈、架构治理、依赖审计、生产监控、人类理解，都还停在原来的速度，你不会得到一个十倍高产的团队。

你会得到一个十倍速度制造混乱的团队。

这不是反 AI，也不是保守。这只是系统规律。

三、harness 是什么

Böckeler 说的 harness，不是给 agent 套一根绳子那么简单。

它是一整套工程环境：上下文、规范、工具、测试、检查、监控、信号。它的作用不是压住 agent，而是把 agent 的力量导向代码库真正需要的方向。

我更喜欢这样理解：

harness 是代码库周围一组活着的反馈环。

最快的一圈，是编译和类型检查。名字写错、参数不对，几秒钟就能知道。

再慢一点，是单元测试。一个分支被改坏，几十秒内被抓出来。

再慢一点，是集成测试和 CI。组件之间的契约坏了，几分钟到几十分钟内暴露。

更慢的是生产反馈。真实用户变慢了、报错了、流失了，监控和指标会说话。

还要更慢的，是架构和技术债反馈。模块膨胀、依赖混乱、review 越来越累，往往几周甚至几个月后才显形。

最慢的，是组织学习反馈。同一类问题反复出现，同一条规则总被绕过，同一个团队总在夜里救火，这些通常要更长时间才能看清。

这些反馈没有谁可以替代谁。

你不能指望生产监控替代单元测试。等用户替你发现 bug，已经太晚了。你也不能指望类型检查替代架构治理。类型系统能告诉你一个变量错了，不能告诉你一个模块边界已经变形。

真正好的 harness，是这些圈都还活着，而且它们的信号能被人看见。

四、AI 让延迟变得更贵

反馈有一个特别关键的属性：延迟。

动作发生以后，多久能知道后果？这决定了系统能不能被调节。

过去，一个人一天可能改一个文件，review 到第二天也还勉强说得过去。现在，一个 agent 一次可以改三十个文件，生成六十个测试，引入两个依赖，顺手改掉三条接口契约。

如果反馈还停在“明天再 review、下周再集成、上线后再看”的节奏，系统就会出问题。

因为动作太快，信号太慢。

这也是为什么 Fowler 那一脉长期强调持续集成、快速构建、自动测试。所谓“十分钟构建”不是程序员洁癖，而是系统控制的基本要求：

让信号比破坏来得早。

AI 把执行速度提上来了，反馈延迟就不能再被当成小问题。构建慢、测试慢、review 慢、监控慢，在 AI 时代都会变成更大的风险。

五、不是所有代码库都同样适合 agent

Böckeler 提到一个很好用的词：harnessability。

意思是：有些代码库天生更容易被 harness 驾驭，有些则不容易。

什么样的代码库更容易？

边界清楚。模块知道自己负责什么，也知道不该碰什么。

测试可信。跑过的测试真的能给人安全感，而不是一堆装饰。

构建稳定。失败能说明问题，成功也值得相信。

文档和规则可执行。不是写给人看的口号，而是能进入脚本、模板、AGENTS.md、CI 和 review 流程里的约束。

生产信号清楚。出了问题能知道哪里痛，而不是只知道“好像有点慢”。

这样的代码库，用 agent 会更安全。因为 agent 的动作虽然快，但它每迈一步，都能碰到边界、听到反馈、看见后果。

反过来，如果一个系统本来就没有测试、没有边界、没有监控、没有可信文档，AI 带来的第一件事很可能不是生产力，而是混乱的加速度。

所以“要不要上 agent”不是一个工具问题。

它首先是一个系统问题：你的代码库有没有足够清楚的岸？

六、不要只盯着最低层的指标

Donella Meadows 写过一篇文章，叫《Leverage Points: Places to Intervene in a System》。里面把干预系统的杠杆点分成十二级，从弱到强，大概可以理解为：参数、缓冲、结构、延迟、反馈、信息流、规则、自组织、目标、范式。

很多关于 AI 写代码的讨论，都卡在最低层。

一天写多少行代码？合多少 PR？节省多少工时？agent 跑了多少轮？

这些不是没用。但它们只是参数。参数好测，杠杆却很低。

更高一层，是结构。模块边界是不是清楚？依赖图是不是可理解？代码是不是能被局部修改？

再高一层，是反馈。测试、CI、review、监控、事故复盘，能不能把系统拉回健康状态？

再高一层，是信息流。谁能看见风险？谁知道某个 agent 总在绕过规则？谁知道同一种 review comment 已经重复了一百次？

再高一层，是规则。哪些代码可以合并？哪些检查不能跳过？什么情况下必须回滚？agent 可以改哪里，不能改哪里？

再高一层，是目标。团队到底想优化什么？是 PR 数量，还是长期可维护性？是看起来省了多少人力，还是让用户和工程师都更少受折磨？

最高处，是范式。我们到底把软件工程师看成什么？

如果工程师只是“把需求翻译成代码的人”，那 AI 看起来就在替代工程师。

如果工程师是“把意图变成可演化系统的人”，那 AI 只是多了一个执行层。

范式不同，所有指标都会变样。

七、目标会偷偷换掉

AI 进入组织以后，最危险的变化常常不是技术变化，而是目标变化。

一开始，团队可能说自己的目标是：做用户喜欢的产品，让系统稳定，让新人能读懂代码，让工程师不要长期疲惫。

后来，AI 来了，目标悄悄变成了：PR 更多、周期更短、工时更少、报表更好看。

这些新目标并不一定错。但它们和原来的目标不是一回事。

目标一变，系统里的激励、指标、会议、周报、review 标准都会跟着变。表面上吞吐提高了，背后可能是技术债变厚了，用户体验变差了，工程师更累了，事故更多了。

所以 Thoughtworks Technology Radar 提醒大家，不要只看 coding throughput。我也赞同。

更好的指标，应该一起看：first-pass acceptance、iteration cycles、post-merge rework、failed builds、review burden、DORA，以及生产事故和用户体验。

但还要再说深一点：

选择指标，本身就是选择目标。

你测什么，系统就会学着变成什么。

八、工程师的位置正在上移

过去，工程师大量时间花在写代码上。

代码是存量。提交是流量。修 bug 是流量。我们天天在这些层面忙。

AI 让一部分执行工作变便宜以后，工程师并不是没事干了。恰恰相反，那些过去一直重要、但总被推迟的高杠杆工作，终于变成了主业。

写清楚 agent 如何在这套代码里工作，这是规则层。

设计 fitness function，保护架构边界，这是反馈层。

把反复出现的 review comment 变成文档、脚本或模板，这是信息流和规则层。

决定团队到底追求什么，不被 PR 数牵着走，这是目标层。

理解软件不是一次性生产出来的，而是长期长出来的，这是范式层。

Böckeler 借用了一个很好的说法：human in the loop 正在变成 human on the loop。

人不再只是站在循环里亲手搬每一块砖。人开始站在循环之外，看循环本身是否健康。

这不是退场。

这是工程师的工作重心上移。

九、怎么和系统共舞

她还写过一篇短文，《Dancing With Systems》。中心意思是：复杂系统不能被彻底控制，只能被持续倾听、引导和调谐。

放到 AI 时代的软件工程里，我会把它变成几条很具体的建议。

第一，先听系统说话。

不要急着加更多 agent、更多规则、更多指标。先看现有系统反复在哪里疼：事故复盘里重复出现的根因，review 里反复出现的问题，CI 里反复失败的步骤，线上指标里反复冒头的异常。

系统一直在说话。很多时候，是我们太急着下命令。

第二，把心智模型摆出来。

有人把 agent 当同事，有人把它当代码机器，有人把它当省人力工具，有人把它当加速器。这些理解不同，后面的规则就会完全不同。

最麻烦的不是大家意见不一致，而是大家以为自己说的是同一件事。

第三，不要为了速度关掉反馈。

为了让 agent 跑得顺，把测试跳过；为了让指标好看，把 acceptance 定得很松；为了减少摩擦，把 review 变成形式。这些动作短期都舒服，长期都会变成系统的账单。

第四，把失败沉淀成环境，而不是情绪。

如果 agent 总是犯同一种错，不要只骂它，也不要只换一个提示词。问一问：这件事能不能变成测试？能不能变成模板？能不能写进 AGENTS.md？能不能进入 CI？

一次失败如果只留下情绪，它会重复发生。一次失败如果变成环境，系统就学习了一次。

第五，把时间视野拉长。

AI 让今天变得很兴奋，但软件真正的账期通常在三年以后。三年后，谁维护今天生成的代码？谁解释今天定下的规则？新人打开这个模块时，是感谢你，还是被你困住？

能经得起三年追问的决定，才是好决定。

第六，承认复杂性不会消失。

AI 不会消灭复杂性。它只会改变复杂性的位置。

你把代码变简单，复杂性可能跑到提示词里。你把提示词变简单，复杂性可能跑到工具链里。你把工具链变简单，复杂性可能跑到组织流程里。

好的工程不是消灭复杂性，而是把复杂性放到最容易被看见、被讨论、被管理的地方。

十、harness 也需要被检查

还有一件事必须说清楚：harness 自己也会失效。

测试会变成走过场。lint 会变成噪声。架构规则会过期。AI review 可能看起来很聪明，却漏掉关键问题。指标可能驱动错误行为。AGENTS.md 可能越写越长，最后没人读。

调节器本身，也是系统的一部分。

所以成熟的 harness engineering，必须有一条反馈环专门用来检查 harness 自己：

测试是否还有效？

CI 是否真的能挡住风险？

review comment 是否应该沉淀成规则？

某条规则是不是已经过时？

agent 是否总在绕过同一类约束？

没有这条反馈环，harness 会从工程能力慢慢变成装饰。

十一、最后回到那句话

软件工程过去几十年的重要实践，持续集成、测试、重构、技术债治理、演进式架构、Technology Radar，本质上都在做同一件事：

让一个由人和代码组成的活系统，变得更容易被驾驭。

AI coding agent 没有改变这件事。

它只是把这件事变得更紧迫。

如果有人说，AI 来了，软件工程的旧规则都过时了，不必急着反驳。系统会用自己的方式给他反馈。

如果有人说，AI 改不了什么，我们照旧就行，也要保持警觉。水流已经变大，岸的形状就必须重新检查。

真正属于 AI 时代的工程师，不是被新工具迷住的人，也不是守着旧经验不动的人。

而是那些愿意每天看见系统、倾听系统、调整系统，并且耐心地和系统一起共舞的人。

岸不是为了禁锢水。

岸是为了让水抵达它该去的地方。