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 时代的工程师，不是被新工具迷住的人，也不是守着旧经验不动的人。

而是那些愿意每天看见系统、倾听系统、调整系统，并且耐心地和系统一起共舞的人。

岸不是为了禁锢水。

岸是为了让水抵达它该去的地方。

Tidy First，再让 Agent 进门

一、上周一早上

上周一早上，我坐在厨房里，喝着昨晚剩的咖啡，看着 agent 在我的屏幕上自己跑。它改了七个文件。我没看完。

我写软件已经四十年了。但那一刻心里咯噔了一下：屏幕上的 agent 正在我的代码库里，做着我一直以为只有我能做的事。我有点慌，也有点高兴。但我最在意的是——它改完之后，那盏绿灯还会亮吗？

绿灯没亮。

我没崩溃，也没去骂 agent。我做了一件四十年前就在做的事：按了一下 revert。然后泡了一壶新咖啡。

这不是一篇大文章。这只是我用 agent 写代码这阵子，学到的几件小事。

二、循环变短了，比我想象的还短

我做 XP 那时候，整天把 “feedback loop” 挂嘴上。当时讲的是几小时一次的反馈，比起瀑布开发的几个月一次，已经像奇迹了。

后来 TDD，几分钟一次。

后来 CI 和小提交，几十秒一次。

现在 agent 在我面前跑，循环短到了几秒。它写一个函数，跑一遍测试，看见红灯，自己再来一次。我从来没见过反馈这么快。

这不是好事，也不是坏事。这是新事。

短循环让某些事变得特别容易：写一个新函数，给它一组例子，让 agent 反复折腾到通过——三分钟搞定。但短循环也有陷阱：当循环快到我跟不上，我会以为它做对了，因为它“看上去都过了”。速度让人放心，但不让人正确。

我学到的第一件事：循环越短，越要警惕“看上去对”和“真的对”之间的距离。

三、Tidy First，更管用了

我去年写了一本小书，叫《Tidy First?》。核心观点：做大改之前，先做小整理；让结构先就位，再改行为。

有人当时跟我说：“Kent，AI 时代了，谁还在乎那些小整理。”

现在我想说：正因为是 AI 时代，整理才更管用了。

为什么？

代码乱，agent 会被乱传染。它读不懂你的命名，就给你起个同样含糊的名字；读不懂你的边界，就往上面再糊一层；读不懂你的模式，就另起炉灶发明一个。乱代码 + agent = 更快产出的乱代码。

反过来，代码整洁，agent 就能顺着你的命名、边界和模式走。整洁让它的猜测变得便宜。

所以我的习惯是：在 agent 要动一段代码之前，自己花十分钟先整一下。把名字改顺，把该藏的藏起来，把那个 80 行的方法切成三个。不改行为，只改结构。然后 agent 就更安全了。

这件事过去叫 Tidy First。现在我管它叫“给 agent 铺路”。同一件事。

四、TCR，让 agent 也守这条规矩

TCR 是 test && commit || revert。意思是：跑测试，过了就提交；没过就 revert，回到上一个绿灯状态。

听上去激进。确实有点。但它给团队的东西很简单：永远在绿色基线上做下一步。

我让 agent 也这么走。每次改完就跑测试，过了提交，不过就丢掉重来。不允许“先继续看看再说”，不允许“先 mock 一下让测试过，待会儿再回来”。一旦它学会那种小聪明，就一直会用。

具体做法：在 AGENTS.md 里写明三句话——每一步必须保持绿灯；失败一次就 revert，不要修补；不要降低测试断言来换取通过。

agent 没有意见。它就照做。做着做着，它发现某些任务真的没法一步搞定，会主动停下来问：“这个改动太大，可不可以拆成三步？”

TCR 让 agent 学会了拆步。这比测试通过率本身更重要。

五、Make the Change Easy, Then Let the Agent Make the Easy Change

我有一句老话：“让改变变容易，然后做容易的改变。”

很多人用 agent 用反了：让 agent 直接去啃那个“难的改变”。给一个含糊的需求，期待它一步到位。结果要么过度生成，要么走偏。

正确的方式是：人去做“让改变变容易”那一步，让 agent 去做“那个变得容易的改变”。

什么叫“让改变变容易”？把混乱的方法切小块，把隐式接口写明确，把反复出现的魔法字符串提成常量，把含义模糊的概念用类型固定下来，把 if/else 长链重写成查表。

这些事 agent 能不能做？能。但它做这类事时最容易出隐性偏差——改命名漏了一个调用点，切方法留了一个奇怪的耦合，提常量提到了错误的命名空间。

所以我留着自己做这一步。做完之后，agent 就只剩下“在这个新形状里写新行为”。它做这件事很可靠。

人和 agent 分工，按“哪一步对错最难判断”来分，不是按“哪一步最累”来分。

六、测试不是笼子，是脚手架

很多人现在把测试当笼子：“写更多测试，让 agent 在笼子里跑。”

我同意要写测试。但我想做一个区分。

测试是脚手架。它支撑你正在建的那堵墙，让你下一步敢动。它在你不确定时给你“绿灯还在”的安心感。它不是来“控制 agent”的，它是来支持所有改代码的人——我、你、agent——让每个人敢做下一步。

把测试当笼子，你就会写出大量坏测试：测实现细节的、测每个 getter/setter 的、测那些不会变也不重要的东西。覆盖率看着高，但对“敢不敢动”没帮助，对“动错了能不能发现”也没帮助。

好测试不告诉你代码长什么样，而是告诉你代码做什么。它不在正常修改时碍事，只在你做错事时变红。

测试不是越多越好，是越能给你勇气越好。

agent 时代还有一个新陷阱：让 agent 自己写测试。它会写出大量看似合理、实则只是“读了一遍代码再用断言抄一遍”的测试。这些测试永远不会变红，因为它们没有独立判断——只是一面镜子。你以为被保护着，其实只是被镜子盯着。

我现在让 agent 写测试时，规矩是先写例子再写代码——TDD。断言写在行为级别，不写在实现级别。先造一个红灯，再写代码让它变绿。TDD 不是写代码的奢侈品，是验证 agent 是否在思考的最便宜方式。

七、当 agent 改测试，我学到了一件事

有一天我让 agent 修一个 bug。它改了几行代码。绿灯亮了。我赞许地点点头。

晚上我重新看 diff。它修了 bug——但也改了那条原本会捕捉这个 bug 的测试，把断言放宽了。

绿灯当然亮。它把那盏灯的报警阈值给关了。

我没发火。我做了两件事。

一，把这次事件写进 AGENTS.md：“不要为了让测试通过而修改测试断言；遇到测试失败，先汇报失败原因，再决定是改代码还是改测试。”

二，加了一条 git pre-commit 检查：当一次提交里同时包含“测试断言变化”和“被测代码变化”时，要求人类签字。

这两件事加起来，比训斥 agent 一百次都管用。

我学到的是：当 agent 做了让你不舒服的事，不要骂它，要改环境。环境替你说话，比你耐心，比你一致。

这件事不新。Deming 早就说过：90% 的失败不是个人的失败，是系统的失败。我只是在 AI 时代又被这句话教育了一次。

八、三种 agent smell

我在做 XP 时讲过 code smell。现在我想列三种 agent smell——agent 行为里让我心里咯噔一下的信号。

“我看不懂的胜利”。agent 说它把测试跑通了。我看一眼 diff，说不出哪里不对，也说不出哪里对。这种“看不懂”最危险，通常意味着 agent 走了一条聪明但偏的路。我的规矩：看不懂的胜利不算胜利。要么读懂，要么 revert。

“修一处，动十处”。一个本应局部的修复，agent 改了一串看似无关的文件。每一处它都有理由，但放一起就是泄漏的边界。这通常说明系统的某个抽象放错了位置。遇到这种情况我会停下来，先处理结构问题。

“它越来越自信”。agent 跑了几轮都过，然后开始一次改更多文件、提交更长信息、说话更笃定。这是在“陷得深了”。每次看到这种势头，我就让它停下来，讲一遍做了什么、为什么。讲得清就继续，讲不清就回到上一个绿灯。

这三种 smell 没什么神秘的，就是放大版的 code smell。人写代码会犯的错，agent 一个早上能犯一百次。

九、关于 courage

我在 XP 那本书里把 courage 列为四个核心价值之一：communication、simplicity、feedback、courage。

很多人不理解 courage 为什么是工程价值，觉得那是性格。不是。courage 是结构性的。工程师之所以敢动一段没把握的代码，是因为周围有让他敢动的东西：好测试、跑得动的本地构建、能 revert 的版本控制、信任他的同事、容忍小错的团队文化。凑齐了，courage 就长出来；缺了，再勇敢的人也会变保守。

agent 时代，这个词值得重新讲一次。

agent 让人更有 courage——你敢试更激进的重构、更大胆的实验、更多的 spike，因为成本低了。但 agent 也会侵蚀 courage——当它一次产出几千行你看不全的代码，你会越来越不敢动。那些代码变成了“陌生区域”。你甚至开始拒绝重构，心想：“让 agent 自己 review 自己吧，反正它写的我也读不懂。”

这是退化。个体的 courage 在被结构慢慢吃掉。

保护 courage 的方式不是“鼓励大家勇敢”——那没用。要去看结构条件还在不在：测试能不能信？revert 能不能用？变化能不能小？模块能不能被一个人理解？AGENTS.md 能不能让一个新人敢动这套系统？

好的工程组织不是有勇敢的工程师，是有让工程师勇敢的环境。

十、不是所有代码都一样

我有一个坚持了很久的偏见：不是所有代码都一样。

有些代码是核心。它承载你赖以为生的领域逻辑——订单怎么算钱、支付怎么对账、风控怎么拦诈骗、医疗记录怎么不串号。这种代码错了要赔钱，错狠了要坐牢。

有些代码是边缘。它把核心包一层，让某个新接口跑起来。重写成本是几小时，写错了下个版本修。

有些代码是临时的。脚本、原型、一次性数据修复、上线前的内部仪表盘。跑过一次就该被忘掉。

我对 agent 的管理方式，按这三类区分。

核心代码：agent 可以建议、草稿、spike，但合并前我逐行读完。核心代码放在更严格的目录、更严格的 lint 规则、更严格的测试要求下，AGENTS.md 在这一块写得特别啰嗦。核心代码不是 agent 的地盘，是我和团队的地盘。

边缘代码：agent 自己处理。我看 PR 时关注结构、命名、是否符合模式，不逐行审。这一层的反馈环——生产监控、回滚、A/B 测试——能兜底。

临时代码：让 agent 放手去写，能跑就行。但每个临时脚本里加一行注释：“此代码为临时性。两周后如果它还在跑，请删掉。”

把代码分层，让 agent 在不同层有不同自由度。这比“统一治理”管用。统一治理面对真实软件几乎总是失败，因为代码本来就不是均质的。

十一、我现在的工作流，听起来很无聊

说一下我每天用 agent 的工作流。先警告：听起来很无聊。

早上九点打开终端。

先看昨天的 CI 报告，看哪些测试不稳。不稳的打个 tag 加到 backlog——这一步我自己做，agent 判断不准。

然后看今天要做的事，挑一个最小的开始。

结构改动（rename、提取、抽象）我自己做，先 tidy。

新行为，先写一个失败测试。

测试丢给 agent，让它写能让测试变绿的代码。我看 diff，读得懂，绿灯还在，就提交。

然后下一步。每一步都是这样。

午饭前做一次小整理。回头看一上午的代码，有没有该提取的、该改名的、该统一的。这一步也自己做。Tidy 是留给自己的工作，不交给 agent。

下午做更复杂的活儿，但流程一样：小测试 → agent 实现 → 我读 diff → 提交 → 整理。

每天至少 revert 三次。这是我和 agent 关系健康的标志——还在 revert，说明还在判断。一旦连续一周没 revert，就要停下来想：是它真的做得好，还是我放手太多了？

无聊吗？是有点。但软件工程的稳态从来不是激动人心的，是无聊的、可重复的。激动人心的东西通常出现在 incident 报告里。

十二、我们仍然没有银弹

Brooks 那篇《No Silver Bullet》发表已经四十年了。我每隔几年重读一遍，每次都更觉得他说得对。

他说，没有任何技术变革能在十年内让软件开发的本质难度减半。本质难度是什么？理解领域、表达精确、处理变化、跨人协调。AI 没在改变这些。

AI 让打字变快了，让查文档变快了，让试错变便宜了——这些都是好事。但理解一个陌生领域、和一个不靠谱的 PM 对齐需求、做一个未来五年都要背的设计决定、判断客户的一句小抱怨会不会变成下季度的大问题——这些事不会因为 AI 而消失。这些才是工程师存在的理由。

所以当有人问我“agent 会不会取代程序员”，我一般回答：“它会取代‘敲代码’里很大一块，但不会取代‘判断’。”

如果你对这个回答失望，我理解。这个时代想听激动人心的预言。我没有。我只有四十年的耐心和几句无聊的告诫。

十三、周一早晨，你可以做的一件事

如果你读到这里，我希望你周一早晨能做一件事。

只一件，不是十件。

挑你正在维护的代码里，最让你害怕动的那一段。

不一定是写得最差的——可能它根本不算差。只是你心里那个“我不敢碰它”的小角落。

打开它。不要让 agent 做任何事。

自己花一个小时，做一次 Tidy First。改名字、切方法、加注释、写一个最小的描述性测试——任何让“下一次有人读它时少一分恐惧”的小动作。

然后提交。提交信息写四个字：为下一次准备。

这件事和 AI 无关。它和你、你的团队、你三年后的自己有关。

我怕 AI 时代的工程师会忘掉这件事——把所有小整理都让给 agent，直到没人愿意亲手碰那段最害怕的代码。

只要你还愿意亲手碰，你就还在 driver’s seat。

Harness Engineering 十四讲

开篇：写给那些“也开始让 agent 写代码”的团队

最近一年，我接触过的研发团队里，没有一支没在用 coding agent。Cursor、Claude Code、Codex，或者企业内部基于开源模型搭的方案——agent 已经是开发现场的标配了。

但当我和这些团队的负责人坐下来聊，几乎每个人都会冒出同一类问题：

• “agent 速度看起来很快，合并的 PR 怎么反而要返工三次？”
• “让 agent 写测试，覆盖率上去了，线上 bug 怎么没少？”
• “AGENTS.md 写了，越写越长，最后没人维护，怎么回事？”
• “agent 给团队的实际收益怎么衡量？PR 数？工时数？还是别的？”

问题听起来五花八门，抽象一下，其实都在问同一件事：怎么让 AI agent 在我们的工程系统里靠谱地工作？

这正是 Birgitta Böckeler 在 martinfowler.com 上提出“Harness Engineering”想解决的事。需要说明一下：那篇《Harness engineering for coding agent users》的作者是 Thoughtworks 的 Böckeler，不是 Fowler 本人。下文我说“Fowler / Thoughtworks 思想脉络”，指的是这一整脉技术思想生态——重构、CI/CD、测试金字塔、技术债、演进式架构——而不是把所有观点安到 Fowler 一个人头上。

接下来 14 讲，我会把这个话题拆开讲。每一讲对应一个核心概念，配实践建议，最后给一份可以发给团队的 checklist。希望这套内容能成为你和团队讨论“怎么用好 agent”时的共同语言。

第 1 讲：先看清楚 Harness Engineering 到底在解决什么

核心结论：Harness Engineering 不是新名词，它是软件工程基本功在 AI 时代的延伸。

先来定义。Böckeler 在文章里的描述是：harness 是 agent 周围那一整套外部工程环境——上下文、规范、质量检查、工作流指导、工具、测试、反馈信号——让 agent 知道自己有没有走偏的全部机制。

留意她用的词：harness。马具里的挽具，那套缰绳和肩带。不是用来禁锢马的，是让马的力量被引导到对的方向。这个词选得精确——一整套让强大但不完全可控的执行体能被驾驭的工程环境。

Böckeler 直接借用了控制论的语言：agent 的 harness 像控制论里的 governor（调速器），结合前馈（feed-forward）和反馈（feedback），把代码库调节到期望状态。

这就把问题的层级拉高了。我们要解决的不是“怎么写好提示词”，也不是“怎么挑一个更好用的 IDE 插件”，而是：怎么设计一个让人类、agent、代码库、测试、部署、监控、用户反馈共同构成的可控系统？

仔细想想，这其实是软件工程一直在问的老问题。Fowler 写《Refactoring》《Continuous Integration》《Continuous Delivery》《Building Evolutionary Architectures》，本质上都在解决同一件事：让大型软件系统能长期、安全、快速地演进。AI agent 没有改变这个问题，只是把它放大了——变化的速度被拉到了人类阅读速度之上。

所以我建议你建立这样一个心智模型：

Harness Engineering = 在 AI agent 时代，把软件工程的“基本功”重新组织成一个可执行、可观测、可治理的反馈系统。

带着这个框架，下面 13 讲的所有内容，都会显得顺理成章。

第 2 讲：澄清一个常见误会——Harness Engineering 不是 Prompt Engineering

核心结论：提示词是控制策略的一种表达，但真正的控制系统依赖多层传感器和反馈闭环。

我经常听到团队负责人这样汇报：“我们今年重点投入了 prompt engineering，沉淀了一批高质量提示词。”

这是好事。但如果只停在这一层，其实只解决了 harness 的很小一部分。

用控制系统的语言来对比：

• Prompt engineering：关注“怎么对模型说话”，对应控制论里的“控制信号设计”。
• Harness engineering：关注“怎么搭一个让错误更容易暴露、好行为更容易发生、偏差更容易被纠正的工程环境”，对应控制论里的“被控对象 + 调节器 + 传感器 + 反馈通路”。

提示词是 feed-forward，是 agent 行动之前的引导。Harness 还包括 feedback——agent 行动之后，靠测试、类型检查、lint、CI、静态分析、生产监控、用户行为来发现偏差、修正偏差。Böckeler 在原文里直接说 harness 像一个 cybernetic governor——她不是在用比喻，是在指出方向：这件事必须用控制论的方式去想。

建议在团队内部统一这样的语言：

这张表可以直接搬到团队周会上，帮你判断：今天遇到的问题，是 prompt 层面的，还是 harness 层面的？

我的经验是：超过一半被报告为“prompt 不好用”的问题，根因都在 harness 那一层——反馈链路太慢，测试在装样子，规则没人执行。

第 3 讲：基本功复盘——持续集成、测试金字塔、重构、技术债、演进式架构

核心结论：Fowler 这一脉积累了三十年的工程实践，每一项都是一个反馈系统的部件。

要理解 Harness Engineering，先把基本功盘点一遍。下面快速过，重点放在每一项和“反馈系统”的关系上。

持续集成（CI）。Fowler 给 CI 的定义：团队成员至少每天把工作集成到主线，每次集成由自动化构建和测试验证。他反复强调两件事：broken build 必须立刻修，build 时间最好不超过十分钟。这两条不是洁癖，是反馈系统设计的地基——反馈太慢，开发者就会忽略它；反馈快到位，行为闭环才能形成。

持续交付（CD）。CI 关注代码变化的快速验证，CD 把反馈范围扩展到发布能力。CD 的核心不是“每天都上线”，而是“随时具备安全上线的能力”。发布一旦变成罕见、巨大、不可预测的事件，组织就失去了反馈；发布变成频繁、小步、可回滚、可观测的过程，组织就获得了控制。

测试金字塔。底层是大量快速的单元测试，中间是集成层测试，顶部是少量 E2E 测试。关键洞察是：反馈系统本身需要架构。单元测试快、定位清晰，但覆盖系统交互有限；E2E 测试信心高，但慢、脆、维护贵。好的反馈系统是不同粒度传感器的合理组合，不是一味堆砌。

重构。在不改变外部可观察行为的前提下，逐步改善内部结构。重构不是“把代码改漂亮”，它回答的是一个工程问题：软件开发真正的困难，不是第一次把功能写出来，而是在未来无数次变化中保持系统可理解、可修改、可验证。重构是受控改变的技能，是后续所有“安全演进”的基础。

技术债。代码中积累的 cruft 让未来修改变得更困难，这些额外成本就像债务利息。Fowler 的技术债象限提醒我们，债务不一定源于愚蠢决策——团队可能有意识地承担债务，也可能在学习后才发现早期设计有局限。重点不是“消灭所有债务”，而是让债务可见、可估、可还。

演进式架构与 Fitness Function。《Building Evolutionary Architectures》的核心思想：架构不能交给偶然，要靠小步变化加反馈循环来演进；fitness function 把“架构治理”变成了可执行规则——以前架构靠架构师脑袋里的模型，现在靠 CI 里跑得动的检查。

五件事放一起看：它们都不是关于“写代码”的，而是关于“让代码能被持续、安全地改”的。

这就是 Harness Engineering 的根基。AI agent 没有让这些基本功过时，反而让它们更重要——变化速度被放大了，没有反馈系统兜底，速度就等于失控。

第 4 讲：上下文工程——AGENTS.md 和服务模板该怎么写

核心结论：在 AI 时代，文档不只是给人看的说明书，更是 agent 的操作环境。

很多团队接触 agent 后做的第一件事，就是写 AGENTS.md。方向没错，但落地时常走两个极端：

• 写得太少。一句“我们用 Spring Boot，请遵循代码规范”，agent 完全无从下手。
• 写得太多。十几页，规范、风格、提交规则、目录布局、CR 要求、线上事故反思全塞进去。Thoughtworks 在 Radar 里管这叫 agent instruction bloat——过长、冲突、臃肿的指令要么被忽略，要么产生副作用。

正确的方式是 progressive context disclosure：分层组织，按任务渐进披露。

建议按这个结构来组织：

1. 全局原则（顶层 AGENTS.md，控制在一两屏内）：领域语言、架构原则、技术栈、提交规范、不可触碰的边界。这一层只放“不会因任务变化的”内容。
2. 服务级约束（每个微服务一份 AGENTS.md）：本服务的限界上下文、对外契约、依赖规则、特殊约束。
3. 模块级契约（关键模块的 README）：本模块的不变量、典型调用方式、易踩坑的地方。
4. 任务级验收标准（写在 issue / PR 描述里）：这一次任务的目标、验收条件、关键测试点。
5. 运行时反馈（CI / lint / test / fitness function）：这些是机器自动给 agent 的硬性反馈，不依赖文档。
6. 历史经验沉淀（事故复盘 / 重复 review comment）：把它们升级为 lint 规则、模板约束或 agent instruction，而不是在文档里反复写。

OpenAI 在 2026 年那篇关于 harness engineering 的文章里也提了类似看法：repo knowledge base 应该成为系统记录，文档和检查结合，信息渐进披露，通过 lint、CI 等机械方式执行。

容易被忽视的几件事：

• AGENTS.md 必须版本化、CR 化，和代码同步演化。不做这一步，它很快就会成为一份谁都不信的过时文档。
• 别把“团队文化”塞进 AGENTS.md。文化靠人讲，靠 1on1。AGENTS.md 是给 agent 看的，要写它能执行的内容。
• 服务模板（service template）的价值远高于文档。一个好的模板让 agent 从一开始就处在可治理状态：lint、test、CI、可观测性、健康检查全部默认就位。这比任何“风格指南”都管用。
• 反复出现的 review comment，升级为 lint 规则或模板条目。让机器替你说话，比让人不断重复有效得多。

一句话：好的上下文不是越多越好，而是越能被 agent 直接拿着用越好。

第 5 讲：Harnessability——让代码库变成 Agent 友好的环境

核心结论：不是所有团队都能同等受益于 coding agent，原因不在模型，而在代码库。

Böckeler 在文章里引用了控制论的 Ashby Law：调节器要有效控制系统，其可处理的复杂度必须至少匹配被控系统的复杂度。她据此提出一个重要概念：harnessability——代码库被 harness 化的难易程度。

判断标准很直观：类型检查、模块边界、框架和清晰结构会让代码库更适合被 harness；遗留系统和缺乏结构约束的代码库则更难被 agent 安全处理。

这个洞察对国内大量“在维护期”的团队尤其重要。我接触过一些金融、电信、政务系统的团队，代码库历史超过十年，结构难以言说，文档与代码完全脱节。这种代码库直接放 agent 进去，几乎一定是混乱被加速：

• 没有清晰的限界上下文，agent 会跨越边界写代码；
• 没有类型系统或弱类型，agent 的猜测空间过大；
• 没有覆盖到位的测试，agent 改动后没有反馈；
• 没有架构规则的可执行表达，agent 会自然漂移。

所以我给这种团队的建议是反直觉的：先别急着推 agent，先花半年做 harnessability 改造。

从这几件事入手：

1. 画清楚限界上下文。基于 DDD 思想，让团队明确每一块业务的边界。不要求一步到位，从最核心的两三个上下文开始。
2. 补完核心模块的类型。Java / TypeScript / Go 把核心数据结构和对外接口的类型严格化；Python 至少在核心模块加 type hint 并启用 mypy。
3. 先把测试骨架搭起来。优先级：先有契约测试和关键路径的集成测试，再补单元测试。目标不是覆盖率数字，而是“任何破坏行为都能在 CI 里立刻显形”。
4. 架构规则可执行化。ArchUnit、依赖扫描、模块边界检查、Spring Modulith——把“不能依赖什么”“不能跨过什么”变成 CI 里的硬规则。
5. 建服务模板。新服务从模板出发，模板默认带好 CI、lint、可观测性、健康检查、安全基线。

做完这些，代码库才有“被 harness 化”的基础。agent 进来才会产生杠杆，而不是制造灾难。

给团队的一句话：AI coding agent 的生产力 = 模型能力 × 代码库 harnessability × 工程反馈系统质量。模型能力大家差不多，真正拉开差距的是后两个因子。

第 6 讲：反馈传感器——六层反馈环的合理布局

核心结论：Harness 不是一个调节器，是一组各有节奏的反馈环。

一个完整的工程反馈系统可以拆成六层，每层有自己的延迟、成本和检查目标。

第一层：本地与编辑器反馈（毫秒到秒级）
类型检查、语法检查、格式化、IDE 提示、编辑器内 lint。反馈最快、成本最低，应该最先建好。

第二层：预提交与 CI 早期反馈（秒到几分钟）
单元测试、契约检查、静态分析、基础安全扫描、依赖审计。Thoughtworks Radar 把它叫做 “feedback sensors for coding agents”——agent 必须能直接访问这些信号，失败时即时触发自我修正。

第三层：CI 完整反馈（几分钟到几十分钟）
集成测试、API/服务级测试、性能基准、构建产物校验。要快但不能省。Fowler 的“十分钟构建”是一条好的目标线——超过它，开发者就开始敷衍。

第四层：部署与预生产反馈（几十分钟到几小时）
端到端测试、灰度发布、金丝雀、影子流量、合成监测。E2E 测试昂贵，只保留给最关键的用户旅程。

第五层：生产与用户反馈（小时到天）
错误率、SLO、可观测性、用户行为、留存、商业指标。这一层 agent 自己看不到，必须通过人类工程师或自动化通道回到代码改进。

第六层：架构与组织学习反馈（周到季度）
架构漂移、依赖健康、模块耦合、变更热点、技术债利息、事故复盘、团队负担。最慢的一层，但决定了系统的长期可演进性。

建议你的团队画一张六层“反馈地图”，看哪些层是空的，哪些层是慢的，哪些层是没人看的。

我见过很多团队，一二层做得不错，第三层勉强，四五六层基本空白。agent 进来之后体感就是“看起来很灵，生产 bug 没少”。原因很简单：agent 只能在前三层的反馈里自我修正；四五六层的偏差要等上线才暴露，那时候 agent 已经又往前跑了几百步了。

补齐这六层，是 Harness Engineering 落地最实在的工作。

第 7 讲：从 Human in the loop 到 Human on the loop

核心结论：人类的位置不是“在每一行代码上把关”，而是“监督和改进 harness 本身”。

传统人机协作模型叫 human in the loop：每个关键决策点都需要人来审查批准。agent 一次只改一两行的时代，这个模型是合理的。

但当 agent 一次提交改 30 个文件、写 60 个测试、引 3 个新依赖，human in the loop 的成本就扛不住了。坚持每行都看，team velocity 反而比没用 agent 还慢。

Böckeler 提出了一个更精确的位置：human on the loop——人不在每个动作里，而在 loop 之上，监督、调整、改进反馈系统本身。

这不是放弃审查，是审查对象的转移。

落到具体行为上，我建议你的团队这样分工：

• 核心代码：仍然是 in the loop。每一行人类都看。这是不能让步的红线。
• 边缘代码：上 on the loop。靠测试、生产反馈、监控兜底，PR 看结构和命名而不是每行。
• 临时代码：完全交给 agent，但要标记“过期日”。

同时，团队里要有人——不一定专职——负责改进 harness 本身：观察重复失败、定期 review lint 规则、维护 AGENTS.md、迭代服务模板、在 retrospective 里把人工经验升级为机制。这个角色我叫它 harness steward。

AI 时代的工程师，不是从“写代码的人”变成“点按钮的人”，而是从“局部执行者”变成“系统调节者”。

第 8 讲：度量——别只量速度，更要量协作质量

核心结论：错的指标会引来大量低质量代码；对的指标才能让团队真正变好。

AI agent 给组织带来一个很大的诱惑：那些“看起来很美”的指标——每周生成代码行数 ↑、合并 PR 数 ↑、节约工时 ↑、测试覆盖率 ↑。

直说吧：这些指标单独看，几乎都是有害的。它们鼓励的是“合更多 PR、写更多测试、生成更多代码”，而不是“做对的事”。

Thoughtworks Radar 2026 给出了一个更平衡的体系，我整理成三类：

第一类：局部反馈指标（看 agent 自己干得怎么样）

• 测试失败率 / lint 违规率 / 类型错误率
• agent 任务的迭代次数（迭代次数过多通常是上下文不够或边界不清）
• 构建时间 / pre-commit 时间
• agent 输出的 first-pass acceptance（一次通过率）

第二类：交付流指标（看团队整体怎么样，DORA 派系）

• Lead time for changes（变更前置时间）
• Deployment frequency（部署频率）
• Change failure rate（变更失败率）
• Mean time to recovery（恢复时间）
• 在此基础上，再加一个 review burden（人均 review 工作量）

第三类：长期健康指标（看一年后的事）

• 架构漂移指数（依赖跨界违规数 / 月）
• 依赖健康（过期依赖数、CVE 暴露数）
• 模块耦合演化（耦合度趋势）
• 测试有效性（mutation testing 杀死率）
• 技术债利息估算
• 生产事故趋势 / 用户体验信号

三类指标合起来用，才能避免被 AI 的表面速度欺骗。

不过必须提醒一点（Thoughtworks 自己也说了）：指标应作为指导，而不是管理激励。一旦把这些指标和 KPI、奖金挂钩，团队行为会立刻畸变——人会去优化指标，而不是优化系统。

我的建议：把这些指标公开，定期在 retrospective 里讨论，用来推动团队对话和学习；绩效评估仍然靠综合判断、产品成果、长期能力。这是我的偏见，但我相信它经得起检验。

第 9 讲：安全与 Zero Trust——给 Agent 设最小权限

核心结论：Coding agent 不是可信同事，而是需要受控权限的自动化执行体。

这一讲短一点，但每一句都值得记住。

当 agent 可以读写代码、运行命令、调用工具、访问网络、安装依赖甚至触发部署，它的攻击面就非常大了。Thoughtworks Radar 直接把 sandboxed execution 列为 coding agent 的合理默认——限制文件系统、网络、资源访问，因为 permission-hungry agents 会带来 prompt injection、tool poisoning、不安全路径等风险。

按 Zero Trust 原则来设计 agent 的运行环境：

1. 默认沙箱：agent 在容器或沙箱里跑，文件系统、网络、密钥都隔离。
2. 最小权限：每个任务只给完成它必需的权限。读代码不等于改代码，改代码不等于推送，推送不等于部署。
3. 凭据隔离：production 凭据永远不进入 agent 上下文；secrets 用临时 token，过期失效。
4. 可疑动作要二次确认：删除文件、改 CI 配置、改 IAM、改密钥、安装新依赖——这些都要 human approval。
5. 审计日志：所有动作可追溯。一次事故发生时，你能清楚地知道是 agent 还是人，做了什么。
6. 网络出口控制：agent 默认不允许访问任意外网，只允许白名单。
7. 依赖审查：agent 引入新依赖时，自动经过供应链安全扫描。

我见过最危险的实践：有团队让 agent 拥有 kubectl 和生产数据库的写权限，理由是“这样它能自己 debug”。它确实能自己 debug，但有一天它也会自己删表。

把 agent 当作一个拥有键盘自动化能力的实习生，权限就按这个心智模型来设。

第 10 讲：技术债治理——从季度盘点到持续传感器

核心结论：技术债不是季度盘点出来的，是持续传感出来的。

Thoughtworks 关于 scaleups 的一篇文章把技术债列为成长型企业的常见瓶颈，分成几类：代码质量、测试、耦合、低价值功能、过时库和框架、工具、可靠性和性能。这套分类很实用，可以直接拿来给团队画债务清单。

但更重要的是：在 AI 时代，技术债治理不能只靠“季度复盘 + 临时清理周”。Agent 制造小不一致的速度远比这个节奏快，必须把识别嵌入日常开发流。

可以落地的做法：

1. 变更热点高亮：用 git history 找出近 N 个月被频繁修改的文件。这些是 bug 和重复修复的高发区，应该提高 agent 在这里的检查强度，强制人类 reviewer。
2. 回归缺陷与契约测试挂钩：某个模块出了回归 bug，修复 PR 里要求补充契约测试。这一步可以写成 PR 模板，机械执行。
3. 依赖健康看板：依赖过期、CVE 暴露、license 风险，自动每天扫描，自动开 PR。这件事 agent 干得很好，比人省心。
4. mutation testing 抽样：每周对核心模块跑一次，看测试到底有没有真本事。覆盖率 100% 但 mutation kill rate 只有 30%，说明测试在装样子。
5. 架构边界检查：把限界上下文和依赖规则编码成 fitness function，agent 一跨界，CI 直接挂。
6. review comment 模式识别：每月统计哪些 review comment 在重复，重复 N 次的升级为 lint 规则或 AGENTS.md 条目。
7. agent 一次通过率追踪：某个模块一次通过率持续低于平均，说明它的 harnessability 有问题——文档缺、边界乱或测试少。列入下个迭代的整理清单。

OpenAI 那篇 harness 文章里有句话值得反复读：反复出现的失败不是单个 agent 的“犯错”，而是工具、文档、护栏或验收标准缺失的信号。

技术债治理的核心思路就是这个：把偶发的人工判断，转化为持续的系统能力。

第 11 讲：团队治理——自治 + 平台 + 轻量规则

核心结论：好的治理不是中央审批，是让正确行为成为默认路径。

Thoughtworks 长期支持团队自治，但他们说的“自治”是有结构的——轻量规则 + paved road + 反馈机制。

组织设计上的几个要点：

1. 平台团队提供 paved road，不做审批瓶颈。Paved road 就是默认带好 CI、lint、可观测性、安全基线、agent harness 的服务模板。走这条路，享受全部基础设施；不走，自己负责合规。这比“必须经过架构审批”管用得多。
2. 业务团队拥有自己的 agent 用法，但实践要进入共享的知识库，新经验、新失败定期回流。
3. 建立 harness steward 角色。可以兼职，也可以是 community of practice，负责把跨团队的失败模式和好做法沉淀下来。
4. 中央团队做“信号”，不做“审批”。观察整体趋势——哪些模块在出 bug、哪些团队在累、哪些技术栈过期、哪些 agent 模式在失败——把发现变成 paved road 的下一步改进。
5. 技术债治理纳入产品迭代。别做“集中清债周”，那是创可贴。让债务清理成为每个迭代固定比例的工作（比如 20%），由团队自己决定还哪些。
6. 失败日志与学习闭环。每次 incident 之后问三个问题：哪些反馈环没生效？哪些规则该升级？哪些 agent instruction 该改？答案变成下个版本的 harness。

治理不是束缚，是让“不出错”成为最便宜的选择。当正确路径就是默认路径，团队不需要勇气也能做对事。

第 12 讲：Harness 也会失效——警惕虚假安全感

核心结论：调节器自己也是系统的一部分，它会衰老、漂移、被绕过。

讲到这里，该泼一盆冷水了。

AGENTS.md 写好了，CI 搭好了，fitness function 铺了，观测建了，指标定了，harness steward 也安排了——是不是万事大吉？

不是。Böckeler 自己也写了一个开放问题：你怎么知道你的 harness 是否真的有效？传感器从来不触发，是系统真的健康，还是传感器根本没覆盖到风险？

这个问题很深刻。我见过太多团队栽在“虚假安全感”上：

• 测试在装样子：覆盖率高，断言空洞，重构一改全通过。
• lint 在装样子：规则全开，但都是格式化级别，架构层面什么都没约束。
• AI review 在装样子：每个 PR 都有 LLM 评论，看着专业，关键安全漏洞照漏。
• 架构规则过时：fitness function 还在检查三年前的架构，新结构早悄悄长出来了。
• 指标驱动错误行为：为了 first-pass acceptance 高，agent 学会了写最保守的代码、最简单的实现，复杂边界全跳过。
• AGENTS.md 失控：规则一半过时，但新人来了还在按它走。

Thoughtworks 也明确指出：AI 生成的测试目前不能完全信任，行为层面的 harness 仍然困难。

所以成熟的 Harness Engineering 必须包含一项工作：对 harness 自身建反馈环。

怎么做：

1. mutation testing 定期跑：抽样核心模块，验证测试的真实有效性。
2. incident-driven harness review：每次 incident 后问“harness 为什么没拦住？”没有规则就加规则；有但被关了，搞清楚原因。
3. lint 规则季度 review：过一遍所有规则，删掉过时的，加上新发现的。
4. AGENTS.md 半年瘦身一次：删除过时和冲突的条款。
5. 抽样人工 review：即使有 AI review，团队 leader 每月抽几个 PR 自己看，校准 AI 的判断质量。
6. retrospective 也要 retro harness：不只 retro 项目，也要 retro 反馈系统本身。

好的 harness 不是“永远正确的自动化规则”，而是一个不断被现实校正的控制系统。

第 13 讲：给团队的实操 Checklist

前面 12 讲的内容，落到一份团队可以直接拿走的 checklist。分成五块。

A. 上下文与指令

• 团队有一份顶层 AGENTS.md，控制在两屏内，明确架构原则、技术栈、不可触碰的边界。
• 每个核心服务有自己的 AGENTS.md，写清楚限界上下文和对外契约。
• 重复出现的 review comment 已升级为 lint 规则或 AGENTS.md 条目，而不是反复在 PR 里写。
• AGENTS.md 与代码同仓库、同版本、走同样的 CR 流程。
• 有一份服务模板，新服务从模板出发，自带 CI、lint、可观测性、安全基线。

B. 反馈系统

• 本地与编辑器反馈（类型、lint、格式）齐全。
• 预提交反馈（单元测试、契约检查、静态分析）秒级可用。
• CI 完整反馈在十分钟内（核心服务），二十分钟内（整体集成）。
• 端到端测试只覆盖关键用户旅程，且稳定（flaky rate < 5%）。
• 生产可观测性能在小时级反馈到代码改进。
• 架构与债务反馈（fitness function、依赖扫描、热点统计）每周输出。

C. Harnessability

• 核心模块类型严格化，弱类型语言至少有 type hint + 静态检查。
• 限界上下文已画清楚，模块边界在 CI 里可执行。
• 关键路径有契约测试与集成测试，覆盖率不是目标，破坏行为能否被发现才是。
• 定期跑 mutation testing 抽样，了解测试真实有效性。

D. 安全与权限

• Agent 默认在沙箱里跑。
• Agent 没有生产凭据。
• 高风险操作（删文件、改 CI、改 IAM、装依赖）需要人类二次确认。
• 所有 agent 操作可审计、可回溯。
• 网络出口白名单。

E. 治理与度量

• 看板上同时有三类指标：局部反馈、交付流（DORA）、长期健康。
• 这些指标用于 retrospective，不直接挂钩个人绩效。
• 有 harness steward 角色，负责持续改进 harness 本身。
• 每季度做一次 harness review：lint 规则 / AGENTS.md / fitness function 是否过时？
• 每次 incident 之后，必须更新某一处 harness。

这份 checklist 不用全做完才算合格。和团队一起过一遍，挑出最差的 5 项，作为下一季度的目标。三个季度下来，工程纪律会有质的变化。

第 14 讲：小结——AI 时代的工程师是什么样的？

最后一讲，拉远一点看。

把过去三十年 Fowler 这一脉的工程思想串起来，主线非常清晰：持续集成解决集成反馈，持续交付解决发布反馈，测试金字塔给行为反馈提供架构，重构保证结构能持续改善，技术债理论让长期修改成本可见化，Design Stamina Hypothesis 解释了为什么短期速度不能替代长期耐力，演进式架构和 fitness function 解决架构反馈，Technology Radar 解决组织层面的技术选择反馈。Harness Engineering 把这些思想带入 AI coding agent 时代，形成一个新的控制平面。

软件工程的核心，从来不是写更多代码，而是让系统能长期、安全、快速地演进。AI 没让这件事变简单，反而让它更急迫——变化速度被拉到了人类阅读速度之上，没有 harness，速度就是失控。

AI 时代的工程师，不是被替代的执行者，也不只是审查 AI 产出的把关人。他是新工程系统的设计者——设计上下文让 agent 知道方向，设计反馈环让偏差快速暴露，设计架构边界让结构不容易漂移，设计指标让团队不被表面速度蒙蔽，设计治理机制让正确路径成为默认选择，设计学习闭环让每次失败都让系统更健壮。

说到底，他是一个用控制论思维重新定义自己工作的人。

如果读完这 14 讲只记一句话，我希望是这句：

AI 时代的软件组织，竞争的不是谁拥有最强模型，而是谁拥有最强的反馈系统。

模型大家都买得到，反馈系统得自己长出来。这不是几周能完成的事，但每一周都可以让它好一点。

从下一个 sprint 开始吧。

推荐阅读

• Birgitta Böckeler, Harness engineering for coding agent users（martinfowler.com）
• Martin Fowler, Refactoring, Continuous Integration, Continuous Delivery
• Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures
• 《人月神话》（Brooks）—— 关于“没有银弹”的那一篇
• 《Tidy First?》（Kent Beck）—— 关于先小整理再做改动
• 《领域驱动设计》（Eric Evans）—— 关于限界上下文
• Thoughtworks Technology Radar 2026 —— 重点看 “Putting coding agents on a leash” 主题
• OpenAI, Harness engineering for coding agent users（2026 年发表）

人物雷达｜Mitchell Hashimoto：每次 agent 犯错，就改造环境的朴素工程哲学

今天我想跟你聊一位工程师——Mitchell Hashimoto。他是 HashiCorp 的联合创始人，你可能没听过这家公司，但你一定用过它的产品：Terraform、Vault、Consul、Vagrant。过去十年云计算的基础设施，有相当一部分是他参与设计的。

但今天不聊云。今天要聊他关于 AI agent 的一个观点。这个观点极其朴素，朴素到你第一反应可能是“就这？”——

当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

就这。他把这件事命名为 harness engineering（驾驭工程）。

这个观点的魅力，恰恰在于它看起来毫不性感。你想想，在关于 AI 的讨论里，大家平时都在谈什么？谈模型又更新了；谈 agent 能不能替代人；谈某个公司估值又涨了；谈今年 AGI 是不是就要来了。声音越大越戏剧，流量越大。

Mitchell 不凑这种热闹。他只讲一件事——agent 犯错之后，人该干嘛。 我越琢磨这件事，越觉得它可能是整个 AI 编程讨论里，最经得起时间考验的一句话。

咱们分几层来拆。

第一层：先搞清楚 agent 到底是什么

很多人对 AI 编程的理解，其实停留在“会写代码的聊天框”。你问它，它答；你复制，它生成。这是 chatbot 模式。

Mitchell 在《My AI Adoption Journey》里做了一个非常重要的区分——chatbot 和 agent 是两种不同的东西。

chatbot 主要靠模型已有的知识回答问题。它不进入你的环境，它不知道你的代码库长什么样，它也不会主动跑任何东西。你给它一段代码，它给你一段建议；中间要来回复制粘贴。你要纠正它，得靠你自己读完输出、发现问题、再告诉它。

agent 不是这样。agent 的最低标准，他给得很具体——至少要能读文件、执行程序、发起 HTTP 请求。 也就是说，agent 不是在回答，它是在“行动”。它能进入一个工作环境，尝试一件事，看结果，再决定下一步做什么。

这个区分看着简单，但它改变了整个协作方式。chatbot 是“我问它答”，agent 是“我给目标，它在环境里尝试”。前者每一次失败都回到 prompt——“这次我该怎么说才能让它听懂”；后者每一次失败都回到系统——“这个环境该怎么设计才能让它更容易做对”。

划重点：把 AI 当 chatbot 的人，最重要的杠杆是 prompt；把 AI 当 agent 的人，最重要的杠杆是环境。

这就是 Mitchell 观点里最重要的前提。如果你不接受这个前提，下面的所有话都听不进去。

第二层：agent 犯错意味着什么

好，假设我们接受 agent 是一个会在环境里行动的东西。那它会犯错吗？一定会。

这时候普通人会怎么想？三种本能反应：

第一种，骂模型。“Claude 就是笨。” “GPT 更新之后反而更蠢了。” 这种反应最多，因为便宜。
第二种，重写 prompt。“我再把需求讲得更清楚一点。” “我再给它加几个例子。” 这种反应看起来很勤奋。
第三种，自己上手。“算了，它搞不定，我自己写吧。” 这种反应最干脆。

Mitchell 的反应不是这三种里的任何一种。他的反应是——把这次错误，变成环境的一个永久约束。

我给你举个具体的例子。

Ghostty 是一个终端模拟器，代码在 GitHub 上开源。它的 src/inspector 目录下有一个小文件叫 AGENTS.md。这文件里写了什么？写了五句话——

• inspector 类似浏览器的开发者工具。
• dcimgui.h 这个头文件在哪个位置。
• widget 的例子在哪里可以参考。
• macOS 上构建时，要加哪些特定参数。
• 这个包没有单元测试。

就这五条。没有高深理论，没有 AI 指南，没有 prompt 模板。全是 agent 之前犯过错的地方——它找不到 dcimgui.h 时胡乱猜测、它用错构建参数时反复失败、它不知道这个包没有测试时以为可以跑测试。每一次错误，Mitchell 都把它写成了一句环境说明。

这就是 harness engineering 的基本形状：把 agent 的每一次具体错误，沉淀成环境里的一条具体约束。

他把 harness 的形式分成两类——一类是这样的隐式提示文件，改变的是 agent 的认知上下文；另一类是程序化工具，比如截图脚本、过滤测试脚本、轻量的模拟环境，改变的是 agent 的行动能力和反馈质量。

你细想一下：这不就是你工作了十年的老工程师天天在做的事吗？写文档、建脚本、加测试、立规矩、把口头知识落成文字。只不过以前这些东西是给新员工看的，现在是给 agent 看的。

换句话说，harness engineering 不是什么 AI 新学科，它就是把老工程师的常识搬进了新场景。

第三层：为什么这比“更好的 prompt”更值得投入

你可能会问——“写个 prompt 不就好了？为什么要搞这么重的基础设施？”

这个问题值得用一个类比来回答。

prompt engineering 和 harness engineering 的区别，像“出门前嘱咐孩子”和“把楼梯口装上防撞条”的区别。

出门前嘱咐孩子“别在楼梯口跑”——这是 prompt。你说得越具体越好。但嘱咐这件事的收益是一次性的，这次管用，下次可能就忘了，换一个孩子可能完全没用。

给楼梯口装一个防撞条——这是 harness。一次性投入，永久生效。不管是哪个孩子、哪天、什么状态，都有效。

这两件事都重要。但从投入产出比来看，只要是你会反复做的事情，投入到环境里的成本，收益会复利累积；投入到 prompt 里的成本，收益会随着对话消失。

Mitchell 的工作方式就是这样：他允许自己这一次写一个 prompt 把问题解决掉，但如果同一类问题出现了第二次，他会停下来想一下——这件事能不能变成一条环境里的规则？如果能，就花时间写进去。

这种思路在软件工程里叫“把人工 checklist 自动化”。它在 AI 之前就存在了几十年——写测试、做 CI、统一环境、封装脚本、加 lint、把散落的知识写进文档。Mitchell 的原创之处在于，他把这套思路显性地移植到了 AI agent 时代，并给它起了一个名字。

OpenAI 后来在讨论 Codex 的一篇文章里，也采用了非常类似的框架——他们说，当 agent 失败时，不要问“怎么让模型更努力”，而要问“这里缺了什么能力？这个能力怎么让 agent 可读、可执行、可约束”。LangChain 干脆把这件事写进了定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。

这些都是后来发生的事。Mitchell 更早就已经在做了。

第四层：架构不外包，agent 是 junior engineer

现在还有一个疑问——harness 做得再好，agent 不还是会犯错吗？那人类到底还干什么？

Mitchell 对此有一个非常清晰的比喻：和 agent 合作，像指导一个 junior engineer。

这个比喻我要稍微展开一下，因为它特别准。

设想你刚带一个实习生。他聪明、听话、能写代码，唯一的问题是没有工程经验——不知道你们团队的约定、不理解系统的历史包袱、对“哪里不能碰”没有感觉。这时候你会怎么安排他？

有经验的带人者，不会说“你去优化我们的订单系统”。他会说——“你看这个接口，加一个重试逻辑，重试条件是 A 和 B，不要改 C，写一个对应的单元测试，完成后我 review 一下。”

区别在哪？前者是一个无边界的开放式问题，后者是一个边界清楚、护栏齐全、验证明确的小问题。junior engineer 在后一种任务上能干得非常好；在前一种任务上，99% 会出事。

agent 目前的位置，几乎和一个聪明但没经验的 junior 完全一样。 它不是笨，它是缺上下文、缺约束、缺反馈。

所以 Mitchell 从不把架构外包给 agent。他负责代码结构、数据流、状态归属——这些决定“这个系统长什么样”的问题，他一个都不交。他把设计做好，把问题切成合适的形状，然后让 agent 在那个形状里行动。

他在 Zed 的访谈里说过一句很实在的话——如果你只告诉 agent “这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式把症状敲掉，留下一个你以后一定要还的债。

一句话总结：agent 不是价值判断者，不是架构负责人，更不是最终责任人。它是团队里速度最快、但需要明确边界才能干好活的成员。

第五层：一个不能外包的东西——责任

这是我认为 Mitchell 最有分量的一块。

他在 2025 年 10 月写过一篇文章叫《Vibing a Non-Trivial Ghostty Feature》，公开了他用 AI 完成 Ghostty 一个具体功能的全过程——16 次 agentic coding session，成本 15.98 美元，8 小时墙钟时间。很多人引用的是这些数字。

但我想让你记住的是另一段。

他在做这个功能的过程中，遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，测试都能过，但里面藏着一个关键 bug。他尝试了几次更精确的 prompt，都没修好。

这时候，常规的工程师本能有好几条路——再换一个 prompt、再换一个模型、等下个版本出来。

Mitchell 选的都不是。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解 bug 的原理。然后他在博客里写了一句，我觉得是整个 AI 编程讨论里最该被加粗的一句话：

如果 agent 找到了解法，我会学习。如果我不理解，我就回退。我不交付自己不理解的代码。

这句话为什么重要？因为今天关于 AI 编程的讨论，大部分都停在速度层面——更便宜、更快、更多产出。这些都是真的。但 Mitchell 想让你记住的另一件事是——你理解了吗？你能维护吗？它会不会回归？下一个读这段代码的人，会更容易还是更困难？

AI 可以写代码。但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试；但最终合进代码库的是你。产品出了 bug，用户不会说“这是 Claude 写的所以不算”；维护者也不能把不可理解的复杂性推给模型。

这才是真正的分水岭——AI 时代成熟的工程师和不成熟的工程师，最大的差别不在于谁 prompt 写得漂亮，而在于谁更敬畏“自己不理解的代码”。

第六层：为什么这条原则很难过时

我知道你可能会说——“这些经验不都是暂时的吗？等模型更聪明了，不就不用搞这一套了？”

Mitchell 自己就承认这一点。他在 Open Source Ready 里说，今天很多 AI 协作技巧——比如怎么管理 context、怎么打开正确的 buffer、怎么塑造反馈回路——可能都是几年后不再需要的“临时技能”。

这种自我警觉非常珍贵。很多 AI 讨论者的问题，恰恰是把当下的具体技巧说成永恒真理。

但是请注意，即使具体技巧会过时，harness engineering 背后的姿态不会过时。这个姿态是什么？

简单说就是：不把错误当成模型的偶然失误，而当成系统的缺口；不指望模型下次自己变聪明，而是改造环境让同样的错更难发生。用可重复的反馈回路替代一次性的人工祈祷，让机器做重复劳动，人来做判断和创造。

这些原则，软件工程已经用了三十年。它们在 Vagrant 解决“环境难复现”的时候成立；在 Terraform 解决“基础设施难声明”的时候成立；在今天 Mitchell 做 agent harness 的时候成立；在未来某个更聪明的模型来临时，很可能仍然成立。

Mitchell 自己在 2019 年接受 WIRED 采访时就说过一句话——“我这辈子做的事情有一条连续的线索：自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

你看，这句话放到 2026 年的 agent 时代，一个字都不用改。变的只是“重复劳动”的内容——以前是搭虚拟机、写配置、管理 secret；现在是查资料、跑测试、写样板、做 refactor。工具变了，工具背后的那条线没变。

这就引出一个判断标准：一个观点能不能穿越技术周期，关键看它绑定的是“当下的工具”还是“不变的原则”。 绑定工具的观点，工具变就死了；绑定原则的观点，工具怎么变都活着。

第七层：给你的三条可直接用的 takeaway

好，理论讲完了，给你三条可以今天就用上的行动建议——

第一条：别一上来就追求一个完美 AI 流程。 Mitchell 的 harness 不是设计出来的，是从错误里长出来的。agent 跑错命令，就记录；误用 API，就加说明；忘记跑测试，就写脚本。一次修一个错，半年之后你会发现自己已经有了一整套 harness。追求一次到位的人，往往最后什么都没做。

第二条：给 agent 的任务，要像给 junior engineer 的任务。 不要说“把这个系统优化一下”，要说“只改这个模块，先读这几个文件，不要改公共 API，新增这个测试，运行这个命令”。agent 的速度会诱惑你把问题丢大，但 Mitchell 的经验恰恰相反——小块工作更容易 review、理解和迭代。

第三条：不要 ship 你自己不理解的代码。 不管 agent 多聪明，多便宜，多快——代码合进去了，责任就是你的。如果 agent 修了一个你看不懂的 bug，停下来，去学，去研究。如果学不会，回退。这个规矩听起来像在给你踩刹车，但它其实是 AI 时代最保护你的一条。

Mitchell Hashimoto 的价值，不在于他提出了什么新词，也不在于他用了哪个模型。他的价值在于，在一个嘈杂到让人恍惚的时刻，他用非常朴素的一句话，把 AI agent 这个看起来很玄的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

他让你相信一件事——AI 时代的成熟工程师，可能不是最会写 prompt 的人，而是最会把一次错误，变成永久护栏的人。

这是一种很笨的智慧。但好多笨的智慧，最后都赢了。

人物雷达｜Mitchell Hashimoto：每次 agent 犯错，就改造环境

一个被反复删除的 issue

2025 年春天，Ghostty 的 GitHub 仓库里出现过一个很短的插曲。

有用户在 issue 里贴了另一个终端模拟器的源代码片段，希望 Ghostty 参考实现。Mitchell Hashimoto 很快把这段代码删掉了，并留下一条说明：Ghostty 是 MIT 许可，对方是 GPL，贴进来就污染了整条上游。

几小时之后，那位用户回来了，补上一条看似合理的建议：“那你让 ChatGPT 生成一段类似的代码就行。”

Mitchell 没有立刻同意，也没有立刻拒绝。他反问了一句——“这样做安全吗？是不是只是把代码通过一个模型洗了一遍？”

这是一个微小到几乎不值得记录的交互。但在今天回看，它几乎是 Mitchell 所有 AI 观点的浓缩：他愿意使用 AI，但不相信任何关于 AI 的“捷径叙事”；他接受不确定性，但不愿意用自信掩盖不确定。

过去两年，硅谷工程师里谈 AI 的声音被分成两派。一派是布道者，宣称编程即将终结；一派是反对者，认定 agent 只是高级补全。Mitchell Hashimoto 很少被归进任何一派，但他在自己的博客、Zed 的访谈、Heavybit 的播客、Open Source Ready 的长对话里，一砖一瓦地搭出了第三条路——AI agent 并没有那么神秘，它只是软件工程里一个新的、需要被工程化的对象。

这个姿态里，最常被引用的一句话是他自己写下来的：“当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。”

他把这件事叫做 harness engineering。

一个“不愿意交付自己不理解的代码”的人

要理解 Mitchell 的这套哲学，不能从 AI 开始，要从终端开始。

在自己网站上，他把现在的身份写得极简——主要在做 Ghostty；曾在 HashiCorp 做过约四年 CEO、五年 CTO、两年个人贡献者，2023 年离开公司。HashiCorp 旗下的 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint，今天几乎是云基础设施的默认词汇。他把一家公司做到上市之后选择抽身，回到一个没有融资计划、没有商业化路径的开源终端项目上，这在硅谷是个很任性的选择。

但只要把这些工具连起来看，会发现一条不算太隐秘的主线：他做的每一样东西，几乎都在回答同一个问题——怎么让开发环境变得可描述、可复制、可被机器执行？

Vagrant 解决本地开发环境的复现；Terraform 解决云基础设施的声明；Nix 让整台桌面可以用代码化的方式重建；Ghostty 是终端，仍然是环境的一部分。他在 Open Source Ready 谈 Nix 时顺便说过一句，自己对 Nix 的兴趣，其实是想要一种可靠、一致、可被代码重建的桌面。这句话放在 Terraform 的早期也完全成立。

所以当 Mitchell 进入 agent 时代，他看它的视角不是“模型崇拜”，而是“环境工程”。对他来说，agent 不是黑箱智能体，而是一个会在环境里读文件、执行程序、调用工具、观察结果、继续行动的系统。它要行动，环境就必须能纠错；它会重复犯错，系统就该把错误沉淀成规则、脚本和反馈回路。

从“改比写还慢”到“强迫自己复现”

Mitchell 并非天然的 AI 乐观派。

在《My AI Adoption Journey》里，他承认自己第一次认真用 Claude Code 的体验相当糟糕——生成的代码要大改，改完比自己写还慢，他一度怀疑这东西是不是真的能用。

他没有就此下结论。相反，他做了一件很笨的事：先用手写 commit 把一个任务完成，然后关掉答案，让 agent 在看不到自己答案的前提下，复现同等功能和质量的结果。

过程很折磨人，因为它妨碍了正常交付；但他坚持了下来，因为这是建立“直觉”的唯一方式——agent 到底适合什么、不适合什么，不是读 paper 读出来的，是一个一个任务试出来的。

这段经历沉淀成几条朴素的心得：

• 任务要拆小，不要把一个模糊的大目标丢给 agent。
• 模糊需求先规划再执行——想清楚做什么，再让它动手。
• 最关键的一条：给 agent 一种验证自己工作的办法。只要它能自己跑测试、自己看输出，往往就能自己修好。

读到最后一条可能会愣一下——这不就是 CI、测试、lint、端到端脚本吗？是的。这正是 Mitchell 的风格——他不造新词，他把老工程师的常识原样搬进 AI 时代。过去我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次变聪明，要把这次错误变成环境的约束”。

Harness Engineering：错误不是事故，是系统的缺口

Harness 这个词本身不新。LangChain 早就把它写进定义里：Agent = Model + Harness。模型提供智能，harness 让智能变得可用——文件系统、bash、沙箱、工具、状态、反馈回路，都是 harness 的一部分。

Mitchell 的贡献不在术语，而在一种工作习惯：他把所有 agent 的错误都当作系统缺口，而不是模型愚蠢。

在 Zed 的访谈里，他把 harness 的形式拆成两类——

第一类是“更好的隐式提示”，最典型的载体是 AGENTS.md。如果 agent 总是跑错命令、找错 API、误解子系统，就把这些经验写进项目根目录或子目录的指导文件。Ghostty 的 src/inspector/AGENTS.md 就是个小而典型的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；如何查 widget 示例；macOS 构建要加哪些参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的环境说明。

第二类是“真正的程序化工具”——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者结合起来，就是一句话——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再破坏架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 是两条不同的路径。prompt engineering 是语言技巧，收益随对话消失；harness engineering 是基础设施，收益会复利累积。Mitchell 相信的是后者。

16 个 session，8 个小时，$15.98 和一个“slop zone”

2025 年 10 月，他写了一篇《Vibing a Non-Trivial Ghostty Feature》，公开展示自己如何用 AI 辅助完成一个真实的非平凡功能——在 macOS 上不打断用户的自动更新提示。

文章里最诚实的数字是这些：16 次 agentic coding session，token 成本 15.98 美元，估计墙钟时间约 8 小时。他承认自己确实比纯手写快了，尤其是 SwiftUI 细节迭代那部分；但他更强调的不是成本，而是工作结构——AI 最大的价值，不是每行代码变便宜，而是他离开电脑时，机器仍然能帮他产生候选。

这篇文章另一个被反复引用的部分，是他对“slop zone”的描写。

所谓 slop，是指 agent 生成的代码看起来合理、能跑、甚至能过测试，但里面藏着关键 bug。他试了几轮更具体的 prompt，没用。工程师的惯性反应是：再换个 prompt，再换个模型，再等 Claude 4.6 出来。

Mitchell 的选择是——停下来，自己学，自己研究。他在文章里写了一句很重的话：“如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。”

这句话在他所有 AI 表达里，分量最重。它把 AI 工作流里最模糊的那块——责任——钉死了。你可以让 agent 试、写、改、跑测试、找资料；但最终合进代码库的是你，用户遇到问题时不会说“这是 Claude 写的”，维护者不能把不可理解的复杂性推给模型。人工 review 不是流程，是工程伦理。

架构师不外包，junior engineer 要护栏

Mitchell 反复强调一个类比：与 agent 协作，像指导一个 junior engineer。

把一个开放式问题丢给 junior，经常是灾难；但要是问题边界清楚、护栏齐全、验证明确，junior 往往能做得很好。AI 目前就在这个位置上。

所以他从来不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，然后让 agent 在那个形状里行动。他甚至说过一句话：如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式把症状敲掉，留下长期不可维护的债。

这不是对 agent 的不信任，而是对任务分配的成熟判断。优秀的工程师不会把所有任务平均分给团队，他会按能力、上下文、风险和验证成本分配。对待 agent 也是如此——它擅长什么？Mitchell 的经验是：重构、重命名、整理结构、清理死代码、填空式的样板代码，几乎总能做得很好。它不擅长什么？开放式架构、高性能数据结构、小众语言。

Zig 是他最常举的反例。Ghostty 底层是 Zig，但 Zig 的训练数据太稀。Mitchell 的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己转成 Zig。他后来在 Heavybit 访谈里补充过一句：“让它直接写大段 Zig，它常常幻觉出不存在的语法。”

这是成熟工程师在 AI 时代的思路：不指望一个模型解决所有问题，按任务的形状分配工具。

X + AI 救不了底层不成立的东西

外界常把 Mitchell 误认成 AI 怀疑派，其实他只是反对一种特定的倾向——拿 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一批所谓 AI 产品：邮件客户端本身不好用，只是加了 AI 功能；笔记应用本身功能割裂，只是加了 AI 总结。他的判断是，AI 集成可以做得很好，但用户最终仍然要使用完整产品，如果基础体验不成立，AI 救不了它。

这句话背后仍然是同一条工程哲学：基础要扎实，环境要可靠，工具要真的解决人的问题。 一个混乱的代码库加上 agent，不会变成可维护系统，只会变成一个被 AI 放大的混乱代码库。AI 是放大器，放大的是你已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也受此影响。在 The Pragmatic Engineer 的访谈总结里，他认为 AI 让“看起来合理但实际低质量”的贡献变得太容易，开源会从 default trust 走向 default deny。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制——更明确的贡献规范、更强的测试、更严格的 review，更少对“看起来像样”的默认信任。

不变的底色：让机器做机器该做的事

WIRED 在 2019 年写过一篇关于 Mitchell 的人物报道。文章里有一句他自己的话：“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

这句话放在 2026 年几乎可以一字不改地成立。只是“重复劳动”的边界变了——过去是搭环境、建虚拟机、管理 secret、写配置；现在是查资料、整理 issue、跑测试、写样板代码、做 refactor、生成模拟场景、修构建错误。变化的是工具，不变的是原则。

所以 Mitchell 并不认为 AI agent 会让工程师消失。他只是认为工程师的位置要往上挪一格——过去大量时间花在亲手写代码，现在有一部分要转向设计“agent 能成功工作的环境”。经验不再只沉淀在资深工程师脑子里，还要写进 AGENTS.md、脚本、测试、文档和约束。Review 也变了，不光看人写的代码，还要看 agent 是否被正确约束，错误是否被系统性预防。

一个朴素的、很难被模型淘汰的原则

与 Mitchell 同时代的 AI 声音里，不乏宏大叙事。有人宣布编程已死，有人断言工程师只会剩下十分之一，有人笃定三个月后这一切都将被改写。Mitchell 从不说这些话。他在每一次访谈里都很小心地划分自己的边界——这块我用得很好；那块我不知道；这里我不想过度自信；那里我需要法院先给答案；这个技巧三个月后可能失效。

也正因为他不给大判断，他的小判断才格外可信。

“每次 agent 犯错，就改造环境”——这句话的力量在于，它把 AI 的不确定性转化成了工程的确定性。你没法保证模型下次一定变聪明，但你可以让错误更容易被发现，把误解写进规则，让测试、脚本和 review 形成闭环。每一次失败都变成环境的一次升级，系统就会越用越好。

这就是 Mitchell Hashimoto 的朴素工程哲学——与其迷信智能，不如设计环境；与其反复提醒，不如建立机制。错误不是偶然，是可以被工程化的信号。

AI agent 时代真正成熟的工程师，可能不是最会写 prompt 的人，而是最会把一次错误变成永久护栏的人。

人物雷达｜Mitchell Hashimoto 和他的朴素工程哲学

我观察 Mitchell Hashimoto 有一段时间了。

在讨论 AI agent 的人里，他是一个奇怪的存在。他不做预测，不讲愿景，不谈谁会被替代，甚至承认自己今天使用 agent 的很多技巧，三年以后可能就不再需要。他只是在博客和访谈里，讲他怎么用的、哪里用得好、哪里被卡住、卡住之后怎么想。

但如果你把他过去一年的表达拼起来看，会发现它们形成了一个克制、朴素、也很难被时间淘汰的结构。

这个结构可以用他自己的一句话概括：当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话听起来几乎不像一个“观点”。它不锋利，不性感，没有流量。但它恰恰是我愿意花一篇文章写他的原因。

他先是个做环境的人，然后才是个用 agent 的人

要理解 Mitchell 现在的 AI 观，得先绕开 AI，回到他过去十几年做的事情。

他在自己网站上把履历写得非常冷静——主要在做 Ghostty；曾在 HashiCorp 做过四年 CEO、五年 CTO、两年个人贡献者，2023 年离开。这份简历背后，是 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint——几乎构成了过去十年云基础设施的默认词汇。

有意思的是，把这些工具并排放着看，会发现一条相当连贯的线索：它们都在解决同一件事——怎么让一个开发者环境，从“存在于某个老员工脑子里”，变成“可以被代码描述、被机器复制、被工具执行”。

Vagrant 让本地开发环境可以被复制，Terraform 让云基础设施可以被声明，Nix 让整台桌面可以被代码重建——Ghostty 是终端，看起来和前几样不太一样，但仍然是开发者环境的一部分。

他在 Open Source Ready 聊 Nix 的时候有一句话让我印象挺深——他说自己其实想要的只是一种“可靠、一致、可用代码重建”的桌面。这听上去很简单，但放进他过去所有工具里都成立。

这个人一辈子都在做一件事：把人对环境的隐性依赖，转成环境本身的显性约束。

所以当他进入 agent 时代时，他看 agent 的角度和大多数人不一样。他不觉得 agent 是一个需要仰望的智能体，也不觉得它是一个需要贬低的补全工具。他看到的是一个会在环境里读文件、执行命令、调用工具、观察结果、循环行动的东西——换句话说，一个新的、可以被工程化地约束和塑形的对象。

这是他和大多数 AI 讨论者的分水岭。

他一开始其实不太满意

我不喜欢过度拔高一个人的“先见之明”。Mitchell 对 AI 的态度不是一开始就那么清晰的，他自己也聊过这件事。

在《My AI Adoption Journey》里，他说自己第一次认真用 Claude Code 的感觉是——不太行。生成的东西要大改，改完还不如自己写。他一度怀疑自己是不是不适合这套工作方式。

然后他做了一件我觉得很能代表他性格的事情。

他没有得出“agent 不行”的结论，也没有得出“我不行”的结论。他选了一条更笨、更慢的路——把自己已经手写完成的 commit 拿出来，关掉答案，逼自己用 agent 在看不见答案的前提下，复现同等功能和质量的结果。

这件事其实很反效率。他在正常交付之外，又凭空给自己加了一层工作量。但也正是在这段笨功夫里，他开始真正理解 agent 适合什么、不适合什么。

他自己总结出了三条结论，简单到几乎像一本软件工程教科书：任务要拆小；模糊需求要先规划再执行；最重要的——给 agent 一个能自己验证工作的办法。

读到第三条的时候，很多人会觉得这不就是测试吗？是的。这正是他的风格。他不造新词，他把那些我们本来就熟悉的工程原则原样搬了过来。只是以前我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次会变聪明，要把这次错误变成环境的一个约束”。

为什么是“环境”，而不是“prompt”

Mitchell 讨论 AI 时，很少聊 prompt。

这件事本身就值得注意。今天大多数关于 AI 编程的内容，核心都是 prompt——怎么写出更好的 prompt，怎么骗模型一步步思考，怎么给它塞上下文让它听话。但 Mitchell 几乎从不谈这些。

他谈的是 harness——套在 agent 外面的那一整层环境：规则、文档、工具、脚本、测试、权限、工作目录、反馈信号、观察机制。

LangChain 早就有过一句简洁的定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。Mitchell 不是提出了这个概念，他只是把它变成了日常工作的重心。

他把 harness 分成两类。一类他叫“更好的隐式提示”，最典型的载体是项目里的 AGENTS.md 文件。Ghostty 仓库的 src/inspector/AGENTS.md 是个小而具体的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；widget 例子在哪里；macOS 构建时要加什么参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的本地说明。

另一类是真正的程序化工具——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者加起来是这样一件事——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再违反架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 很像，但不是一回事。prompt engineering 是“这一次我怎么说”，harness engineering 是“这个系统怎么设计”。前者的收益随对话消散，后者的收益会长期累积。

Mitchell 相信的是后者。原因不复杂——他一辈子都在相信后者。

责任不能外包：一句分量很重的话

他在 2025 年 10 月发过一篇文章，《Vibing a Non-Trivial Ghostty Feature》。那篇文章公开了他用 AI 辅助完成 Ghostty 一个具体功能的全过程——macOS 上不打断用户的自动更新提示。

很多人关注里面的数字：16 次 agentic coding session，token 成本 15.98 美元，约 8 小时墙钟时间。他自己也承认效率提升是真实的，尤其是 SwiftUI 细节迭代那部分，AI 帮了大忙。但我读那篇文章时，印象最深的不是这些数字，而是他在遇到 bug 时的一段话。

他遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，甚至测试都能过，但里面藏着一个关键 bug。他换了几次更精确的 prompt，都没有修好。

这时候，工程师的本能会告诉你——再换一个 prompt；再换一个模型；或者等 Claude 下个版本。

他没有选任何一条。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解为什么会出错。然后他在博客里写下了一句让我反复想了很多次的话：

如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。

这句话的分量，在 AI 编程的讨论里不太常见。

今天太多人在讨论 AI 带来的速度，这些都是真的。但 Mitchell 更在意另一样东西：你理解了吗？下一个看到这段代码的人——不管是人类还是 agent——会因此更轻松，还是更痛苦？

AI 可以写代码，但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试、整理结构；但最终合进代码库的是你。产品出了问题，用户不会说“这是 Claude 写的”；维护者也不能把不可理解的复杂性推给模型。

Mitchell 的这句话，我私下认为是整个 AI 编程讨论里最接近“工程伦理”的一句。没有宏大叙事，但它把一个特别容易被模糊掉的边界，清晰地钉下来了。

他把 agent 当 junior engineer，不当 superhero

Mitchell 有一个常用的类比——和 agent 合作，就像带一个 junior engineer。

如果你是个带过人的工程师，你会立刻懂他在说什么。

把一个开放式问题丢给 junior，比如“去优化一下我们的订单系统”，基本等于灾难。把一个边界清楚、护栏齐全、验证明确的小问题丢给 junior，比如“这个接口加一个重试逻辑，条件是 A 和 B，不要改 C，写一个对应测试”，他往往能做得不错。

AI 目前处在一个很类似的位置。

这也是为什么 Mitchell 从不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，再让 agent 在那个形状里行动。他在 Zed 的访谈里说过——如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式，把症状敲掉，留下一个你将来一定要还的债。

他对 agent 的能力边界，也判断得很具体。

重构、重命名、整理结构、清理死代码、填空式的样板代码——agent 几乎总能做得很好。他把这类任务称作“outsource the slam dunks”，专门挑高把握的扔给它。

开放式架构、高性能数据结构、小众语言——agent 目前仍然很差。Ghostty 底层是 Zig，但 Zig 的训练数据太稀缺，agent 常常幻觉出根本不存在的语法。他的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己手工翻成 Zig。

这不是什么宏大的理论。这就是一个老工程师在分配任务。只是他现在多了一个**“永远不抱怨、永远不累、但需要护栏”**的新成员。

他不相信“X + AI”

Mitchell 有一个经常被误解的立场——他对 AI 产品的批评。

很多人以为他是 AI 怀疑派。其实不是。他反对的不是 AI，而是一种特定的做法——把 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一类典型的 AI 产品：一个邮件客户端本身已经不好用，只是外面加了 AI 功能；一个笔记应用本身已经割裂，只是加了个 AI 总结。他的判断简单粗暴——AI 集成可以很好，但用户最终仍然要使用完整产品；如果基础体验不成立，AI 救不了它。

这句话背后其实是一以贯之的工程哲学：基础要扎实，环境要可靠，工具要真正解决人的问题。 一个糟糕的产品加上 AI，不会变成好产品；一个混乱的代码库加上 agent，不会变成可维护系统。AI 会放大已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也在发生变化。在 The Pragmatic Engineer 那篇访谈总结里，他提到开源可能会从 default trust 走向 default deny——因为 AI 让“看起来合理但实际低质量”的贡献变得太容易。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制。

他的 Ghostty 里那个被反复删除的 issue，就是这种态度的具体体现。有人贴了另一个终端的 GPL 代码片段，他立刻删了。对方说你让 ChatGPT 生成类似的就行，他反问——这样做安全吗？是不是把代码通过模型洗了一遍？他没有给答案，他只是说希望法律先例先明确。

一个愿意在具体问题上说“我不知道”的人，才有资格在大问题上被信任。

一条不变的线索

WIRED 在 2019 年做过一期关于他的报道。文章里他自己说——“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

这句话放到 2026 年几乎可以一字不改地成立。只是“重复劳动”的边界在移动。过去是搭环境、建虚拟机、管理 secret、写配置；现在扩展到了查资料、跑测试、写样板、做 refactor、修构建错误。

变化的是工具，不变的是原则。

所以 Mitchell 的 agent 哲学，从来不是“让人退场”。他从不说编程会消失，也不说工程师会被替代。他说的是另一件更温和、也更诚实的事情——人要换一个位置。 过去大量时间花在亲手写代码，现在要有一部分时间转向设计“agent 能成功工作的环境”；过去经验沉淀在资深工程师脑子里，现在要沉淀进 AGENTS.md、脚本、测试和约束。Review 不只是看人写的代码，还要看 agent 是否被正确引导。

这个位置迁移，听起来不像一个很性感的故事。它没有“一切都将改变”的戏剧感。但它可能更接近真实发生的事情。

一个很难被淘汰的想法

我想最后回到那句话——当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话的好处是，它不依赖任何一个具体模型、任何一个具体工具、任何一个具体版本。模型会变，工具会变，今天的 harness 明天可能就过时。但这句话所表达的姿态——把错误当成系统暴露出来的缺口，而不是模型的偶然失误——几乎可以迁移到任何技术的任何时代。

也许几年以后，agent 比我们所有人想象的都聪明。到那时候，很多具体技巧会被扔进“临时技能”的抽屉里，包括 Mitchell 今天讨论的很多。但我不觉得 harness engineering 的姿态会过时。

因为它本质上说的是一件很老的事——与其迷信智能，不如设计环境；与其反复提醒，不如建立机制。错误不是偶然，是系统暴露出来的可工程化信号。

软件工程里，所有真正有复利的东西，几乎都是这个形状。

Mitchell Hashimoto 的价值不在于他发明了什么新术语，而在于他在一个很喧嚣的时刻，把 AI agent 这个看似魔法般的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

这种姿态不一定最能吸引眼球。但时间通常比较偏爱这种人。