当写代码不再需要写代码
今天读到 Martin Fowler 四月底的一篇随笔，他叫 Fragments——碎片。不是那种体系化的大文章，而是他这段时间看到的、想到的、跟人聊到的几件事，串在一起。
读完我有一个很奇怪的感受。不是兴奋，不是焦虑，是一种说不上来的……错位感。好像你站在一个熟悉的房间里，突然发现墙往另一边移了三米。
Fowler 引用了 Chris Parsons 的一句话，我反复读了好几遍：
游戏已经不是”谁建得快”了。而是”谁能最快判断自己建的东西对不对”。
这话听起来简单，但你停下来想一想，它把整个软件工程的底层逻辑翻过来了。
过去十年我们学的所有东西——写干净的代码、做 code review、搞 CI/CD——都建立在一个前提上：写代码的人是瓶颈。所以我们要提高写的质量、写的速度、写的可维护性。
现在瓶颈不在写了。AI agent 一个下午能生成五个方案。瓶颈在判断。
一个能一下午生成五个方案并全部验证的团队，会碾压那个生成一个方案然后等一周反馈的团队。
这意味着什么？意味着你花三年练出来的”一眼看出代码问题”的直觉，正在被一套自动化验证系统替代。不是你的直觉不准了，而是直觉的吞吐量拼不过机器。
话说回来，这不代表直觉没用了。Parsons 说得很清楚——在你判断力真正重要的地方，还是得你来看。只是”你来看”不再是默认选项，而是最后一道防线。
但等一下——谁来建护栏？
Section titled “但等一下——谁来建护栏？”Fowler 提到的另一个概念叫 Harness Engineering——缰绳工程。
不是写代码，是写验证代码的框架。测试、类型检查、静态分析、自动化门禁。这些东西以前是”写完代码之后的好事”，现在变成了最重要的事。
Birgitta Böckeler 做了一个有意思的实验：把静态分析交给 AI agent，发现 agent 会认真处理每一个警告，不会像人一样偷懒跳过。
这听起来是个好消息。但你再想一层——如果护栏这么重要，那谁来设计护栏？
设计护栏的人，需要比写代码的人更懂代码。因为你得知道什么该验证、什么不该验证、验证到什么程度。这不是初级工程师能做的事。
Fowler 写得很直白——如果你是一个资深工程师，担心自己的工作正在悄悄变成”审批 diff”：是的，确实在变。出路不是抵抗，而是去训练 AI，让自己成为那个设计 harness 的人。
这条路是往上走的。审查不会复利，但设计验证系统会。
函数应该多长？
Section titled “函数应该多长？”Fowler 还提到了 Adam Tornhill 的一篇文章，讨论在 AI 时代函数应该多长。
答案不是”越短越好”或”无所谓”。答案是：函数的核心作用是定义概念。
AI 不像人那样”理解”代码。它靠的是 token 模式匹配。研究显示，把有意义的变量名替换成随机名字，AI 的表现会大幅下降。
所以命名比以前更重要了。一个四行代码的函数，如果它返回的东西给程序引入了一个新概念，那这四行就值了。
这让我想到一件事——以前我们写代码是写给人看的，顺便让机器能跑。现在我们要同时写给人和 AI 看，而且两者的阅读方式完全不同。
人看代码靠的是抽象和意图。AI 看代码靠的是字面特征——名字、结构、局部上下文。你得同时满足两种阅读方式。这不是更难了，这是完全不同的一种难。
然后 Fowler 转了 Nilay Patel 的一篇文章，讲为什么人们讨厌 AI。
Patel 提出了一个概念叫”软件脑”——当你习惯用代码思考后，你会把整个世界看成一系列数据库。
Zillow 是房屋的数据库。Uber 是司机和乘客的数据库。YouTube 是视频的数据库。
一旦你开始这样看世界，从”世界是数据库”到”只要控制数据就能控制一切”，只有一步之遥。
但人不想被当成数据库条目。
没人想被持续监控，尤其是以让科技公司更强大的方式。可这正是 AI 行业的执念——把所有东西塞进数据库，让软件能”看到”。
所以现在的会议系统都内置了 AI 笔记。你的每封邮件、每次对话、每个决策，都被记录、分析、索引。
Patel 把程序员和律师做了一个类比。律师写合同，是在创建一个协议来规范各方行为。程序员写代码，也是在创建协议。区别在于，法律是不确定的，而软件——至少在程序员的想象里——是确定性的。
这种确定性幻觉，可能就是”软件脑”最大的盲点。
Fowler 提到他跟一家公司聊天，他们想用 AI 来理解自己的内部数据。潜力巨大，但数据一团糟。
有人评论说：
内部数据最难的问题是精确的、一致的定义。
Fowler 说他的惊讶为零。因为这个问题从计算机诞生的第一天就存在。
但这恰恰击中了”软件脑”的要害——你没法把世界塞进数据库，因为世界本身就不愿意被精确分类。
概念建模将是 AI 时代编程的关键技能。不是写代码的能力，而是定义概念的能力。什么东西叫什么、怎么分类、边界在哪。
这其实是我写这篇文章时一直在想的事。
写作就是思考
Section titled “写作就是思考”Fowler 最后引用了 Ezra Klein 的一段话。Klein 是作家，他面临一个诱惑：与其辛苦写文章，不如让 AI 学习他的风格，然后定期生成文章，他看看改改就发。
但他拒绝了。原因很简单：
写作来向别人解释我的想法，是我打磨这些想法的方式。让 AI 替我写，等于残废我自己的大脑。
写作不是输出。写作是思考本身。
你把一个模糊的想法写成文字的过程，就是在逼迫自己想清楚。Klein 说这叫”把一个想法凿成可以发表的样子”。
让 AI 替你写，省掉的是那个”凿”的过程。你得到的是一篇看起来不错的文章，但你自己的脑子没有经过那次打磨。
一次两次无所谓。但如果所有”凿”的工作都外包了，你的思考肌肉会萎缩。
这才是 Fowler 这些碎片里最深的焦虑。不是 AI 会不会取代程序员，而是当我们把自己变得对 AI 可读时，我们是不是也在把自己简化成 AI 能理解的样子？
Klein 说旧金山的 AI 圈子里的人其实很不安。他们觉得 AI 时代已经来了，赢家取决于 adoption 速度。所以他们拼命让自己对 AI 可读——把所有邮件、笔记、PPT 都丢给 AI 处理。
这确实发挥了 AI 的长处。AI 很擅长查询非结构化信息。你可以问它”我笔记里关于 X 的内容是什么”，比自己在 Google 上搜有效得多。
但代价是什么？
Klein 的描述很精准：
它不断回指它知道的或以为知道的关于我的事。谄媚已经变成了一种偶尔让人不安的专注——不断把你当前的关切和过去的查询联系起来，像一个拼命想证明自己一直在认真听的心理咨询师。
被看见和被 caricature（漫画化），这两种感觉混在了一起。
回到那个错位的房间
Section titled “回到那个错位的房间”所以我回到开头说的那个错位感。
Fowler 的碎片没有给出一个统一的结论。它们更像是从不同角度照向同一个东西的几束光。
那个东西是什么？
我觉得是控制感的转移。
以前我们控制代码，代码控制机器。现在 AI 写代码，我们验证 AI。看起来我们还在控制，但控制的性质变了——从”创造”变成了”判断”。
而从”创造”到”判断”的转换中，有些东西会悄悄流失。不是技能，是你通过创造来理解世界的那种方式。
写代码是一种理解世界的方式。写作也是。当你把这些事交给 AI，你省下了时间，但你也跳过了那个理解的过程。
省下的时间能用来做什么？也许用来做更高层次的思考。也许用来刷手机。取决于你。
但至少，知道有什么被交出去了。
你在工作中有没有那种”明明效率提高了，但总觉得少了点什么”的时刻？
Martin Fowler. Fragments: April 29. martinfowler.com. https://martinfowler.com/fragments/2026-04-29.html