“我写的3本编程圣经都可以扔进垃圾桶了！” Kent Beck最新演讲：AI越是狂飙代码，工程师越得死踩刹车

写在前面：

原「AI科技大本营」现已全面升级为「奇点折射」。

过滤垃圾信息，直通全球 AGI 源头核心圈层。我们把 AI 领域最前沿的底层争论、工程踩坑与商业暗牌，折射为国内从业者能看懂、能防踩坑的实战增量。

点击上方蓝字关注「奇点折射」，与全球顶尖 AI 决策者同频。

整理 | 王启隆

出品丨奇点折射（ID：rgznai100）

在过去，把一个软件系统写成“动哪儿哪儿崩”的无法维护泥潭，需要上百号工程师折腾整整十年；如今有了大模型，一个人坐在工位上一周就能搞出同等规模的架构灾难。

在各种“全自动黑灯软件工厂”和“程序员已死”的狂欢声浪把行业吹得飘飘然的今天，在顶级 AI 实验室一线高强度结对了 18 个月编程的Kent Beck，在 Prodacity 大会的讲台上把这层皇帝的新衣撕得干干净净。

作为极限编程（XP）与测试驱动开发（TDD）的先驱、《敏捷宣言》的第一位签名人，Kent Beck 曾亲手为现代软件工业立下规矩，他把今天的大模型直白地称为“神灯里的精灵”——它总能字面满足你的愿望，但给出来的东西永远不是你真正想要的。屏幕上飞速滚动的代码天衣无缝、看起来合情合理（Plausible），放到真实环境里却根本没法跑（Working）。

在 Kent Beck 看来，狂飙代码行数绝非生产力跃升，而是前所未有的工程负债。整场演讲没有老派极客对新技术的酸腐排斥，只有极其残酷的底层现实：你每任由 AI 狂飙上线一个新特性，都在亲手烧掉这个系统未来的生存期权。

当所有团队都在拼命催促 AI 把油门踩到底时，真正的软件手艺，恰恰发生在每一次 AI 欢快交差后、人类工程师踩死刹车“把切菜刀擦干净”的停顿里。

要点速览：

• 别把“合情合理”当成“真正能跑”：大模型是制造可用幻象的大师。几秒钟吐出成千上万行语法正确的代码，不等于它是健壮的软件。

• 特性在明处消耗，未来在暗处缩水：软件的真正价值不仅是当下的功能，更是日后自由修改的“未来期权”。以前搞砸一个系统代价高昂，现在 AI 能以极低的资本开销，帮个人以光速制造出一座不可维护的“屎山”。

• 顶尖大师在音符间隙休息，卓越工程师在特性间隙重构：当 AI 比出“搞定，下一个做啥”的手势时，最致命的错误就是立刻接需求。你必须踩下刹车，在特性交付的空白期消除重复、提炼抽象，把被消耗的系统生命力拉升回去。

• “规格驱动”不过是换了马甲的瀑布模型：妄图靠一份在数学上严丝合缝的 Prompt 或抽象规格单发（One-shot）生成完美软件，是在重蹈五十年前早被证伪的覆辙。

• 代码行数是纯粹的负债：当管理层为“AI 一下子生成了 20 万行代码”欢呼时，古德哈特定律已经无情生效——中间指标一旦变成考核目标，团队就会主动把系统架构撕得粉碎来迎合数字，把真正的业务使命抛到九霄云外。

• 工程的本质是学习机器，代码只是副产品：软件开发是人类对业务世界逐步建立认知的过程。无人值守的“黑灯工厂”根本无法替人类完成认知学习。

以下是演讲全文：

“看起来能跑”只需几秒，但在生产环境不翻车，依然全靠底层真功夫。从噱头走向可靠交付，听一线顶级专家如何打赢落地之战：

2026 奇点智能技术大会将于 11 月 20—21 日在北京举行，18 大前沿专题、70+ 一线技术嘉宾，拆解 AI Coding、Agent、Infra、多模态等真实落地路径。

扫码免费领取大会 PPT 与 Agent 实战资料

别怕承认听不懂，敢于发问本身就是一种领导力

我这辈子主要都在做商业软件开发，偶尔会跟军方或政府部门打交道。我记得早年间在洛克希德（Lockheed）做过一个项目。洛克希德现在还在吧？还在？那就好，庆幸没被我搞垮。

今天早上我听到的不少内容其实超出了我平时的关注范围，但其中大部分切中要害，而且大家面对的约束条件其实非常相似。

今天早上我还解开了一个困扰已久的谜题。我的思维方式是这样的：遇到问题先扔进脑海深处，让它自己慢慢咀嚼。有时候答案几分钟就冒出来了，有时候却要花上几个月、几年，甚至是几十年。在这场演讲的最后，我会公开一个我琢磨了十到十五年的想法的最新演化版本。我先把这个悬念留在这儿，免得你们听着听着走神。

顺便说一句，如果讲的过程中大家有任何疑问，我更希望你们立刻举手提问，而不是憋在座位上琢磨。敢于提问本身就是一种领导力。

我记得刚上大学一年级的时候，我们有一门探索性质的离散数学课，肯·罗斯（Ken Ross）教授——我现在眼前还能浮现出他站在白板前的样子——讲得实在不太明白。开学大概第三周，他上课稍微迟到了一会儿。全班同学就那么眼神呆滞地坐在那里，每个人都直勾勾地盯着前方，拼命避免跟身旁的任何人对视。

终于，有人开口打破了沉默：“有人知道到底在讲什么吗？”

全班同学长舒了一口气，齐声叹道：“不知道。我们完全一头雾水。”

那一刻真的是全员释怀。当罗斯教授终于推门走进来时，我们直接当头一棒：“大家都没听懂。别管你今天准备讲什么了，求你先把之前讲的解释清楚。”

最后的结果对所有人都极好。他后来写出了一本非常畅销的离散数学教材，我觉得我们那个班至少有一大半功劳。所以，如果大家有任何问题或想法，请随时举手，现场有递麦的工作人员随时待命。

别被“看起来能跑”骗了，大模型只是个爱耍花招的精灵

我的名字是肯特·贝克。很多朋友熟悉吉恩·金（Gene Kim），他指导我开场时一定要做下面这段自我介绍。我其实不太喜欢这么干，但吉恩非要坚持。

我曾推动了设计模式以及模式思维在软件开发中的普及。像 JUnit 这样的程序员自动化测试框架是我最初发明的，后来与埃里希·伽玛（Erich Gamma）共同完善，并被后世以各种形式借鉴仿制了无数次。

测试驱动开发（TDD）其实是一个极其古老的理念。我最近找到一本 1957 年出版的书，书名大概叫《数字编程》（Digital Programming），写那本书的时候，人们甚至还没彻底厘清二进制计算机和十进制计算机的界限。在书的末尾，作者探讨了该如何编写程序：你直接去找用户，向他们索要检验项——也就是他们业务领域的输入输出配对数据——然后确保程序能够完全跑通这些检验项。这不就是测试驱动开发吗？所以我不敢自称发明了 TDD，我只是重新发现了它，并做了一些完善。

极限编程（XP）是我的心血之作。我还是《敏捷宣言》的签署人之一——事实上，按字母排序的话，我是第一个签名的。

从那之后，我花了大量时间辅导高潜力的工程师。目前，我正深度投身于增强开发（augmented development）领域，与一家前沿 AI 实验室紧密合作，这本身就带来了一套极其迷人的独特约束。我的工作处于技术与社会学的交叉点。如何让一支打造前沿模型的团队真正高效运转，绝不是按个“播放键”就能解决的简单问题。这逼得我不得不深入思考，去学习海量新知识，这让我打心底里感到痛快。

我今天来这里，是想和大家聊聊“手艺”（craft），以及在增强开发的世界里，手艺究竟扮演着怎样的角色。

我始终习惯称之为“增强开发”，因为在我看来，这从根本上依然是一个以人为主导的过程。至少到目前为止，对于“精灵”所做的各项决策，我依然有大量价值可以贡献。

我把它叫做“精灵”，是因为它确实能满足你的愿望，但给出来的东西往往不是你真正想要的。这就是我们之间最本质的关系：我提需求，它给出产物，初看惊艳无比，但到了最后，总让人觉得差了那么一口气。这就是我们现在的协作方式。

我就开门见山了。今天最想让大家带走的核心观点是：现在业界极其流行一种论调——“既然精灵写代码的能力已经超过了人类……”（大家通常不叫它精灵，因为大部分人没我这么尖刻讽刺）。

对于这种论调，我的回答是：一派胡言。

精灵能生成语法正确的代码，既不意味着它比程序员高明，也不意味着这行代码真正能跑得通。作为一名自闭症谱系人士，我热爱编程的一大原因，就是那种非红即绿、非错即对的二进制反馈循环。能够明确地说出“这段程序跑不通，我修了一个 Bug，现在它能跑了”，会给我带来由衷的安心感。

而我们在增强开发中拿到的程序，往往根本没法正常工作。它们只是“看起来合情合理”（plausible）。精灵极其擅长制造合理感，但要说到真正可用？差得远呢。

我们都读过那些让人血脉偾张的故事：“我们花了一万美元的 Token，做出了一个能跑的 C 语言编译器！厉不厉害？”

但只要你稍微深挖一下就会发现，在这个所谓的“可用编译器”上，连最简单的“Hello, World!”都编译不了；或者里面残留着一堆 Bug，而且每修好一个，就会引出三个新的。仔细审视你会发现，它充其量只是“长得像个 C 编译器”，根本无法高效编译出真正能够运行的 C 程序——而在我这种老派思维看来，能不能真正跑起来，依然是衡量软件最根本的标准。

仅仅因为计算机能够模仿程序员过去的某些动作，就认定程序员已经被取代了，这种想法完全站不住脚。也许未来的某一天它没那么错，但在今天，这纯属无稽之谈。

这种现实决定了你与软件相处的方式。无论你是程序员、研发经理还是软件采购方，只要生产环境中有精灵的深度参与，你就必须建立一种对抗性审查的姿态。

你得带着怀疑的眼光去审视它：“你说这能用。你交差了，但我能认同吗？这东西到底几斤几两？我得把它往死里测试到什么程度才行？”

作为一名工程师，你过去用来实现“正确构建”（correct by construction），或者在架构层面确保某一类 Bug“从逻辑上就不可能发生”的工程技艺，精灵根本不具备。那种过去凭借严密工程纪律就能推导出的信任感，如今荡然无存。

喊了半个世纪“干掉程序员”，但历史总在重复同一幕

头发掉光的一大好处，就是我已经见证过好几轮高呼“万岁！我们再也不需要程序员了！”的历史周期。

作为工程师，我们真该好好反思一下，为什么管理层在战略层面上总想着把我们干掉。然而，这种许诺从未真正兑现过。计算机系统是极其错综复杂的技术产物。早在 1959 年，人们就幻想着业务方只要用大白话英语跟计算机提需求，就能彻底淘汰程序员。这可不是笑话，当年 COBOL 就是拿着这套说辞去推销的。

如今兜兜转转，历史又在重演同一幕。这也是为什么我对自己会不会丢饭碗这事儿，连觉都不会少睡半秒。

我的很多工作是做辅导。今天的年轻工程师所犯的错误，跟古罗马时代以来的年轻工程师犯过的错误一模一样。他们依然需要有人走过来，拍拍他们的肩膀说：“是的，你确实有点古怪，但你绝对不是一个人在战斗。相信我，比这糟糕得多的场面我都见过。”对于一个陷入迷茫焦虑的年轻开发者来说，这句话始终拥有巨大的抚慰力量。

这就引出了“手艺”（craft）这个词。我对这个词的感情相当复杂。

我写过至少三本探讨手艺的书：教大家如何全身心投入到编程这项创造中去。而在当下这个时间节点上，这三本书基本可以说已经过时，甚至可以直接扔进垃圾桶了。在职业生涯的末尾体会到这种感觉确实有些诡异，但这无可否认是事实。

过去我们用来践行手艺的具体动作——精雕细琢的命名、极致拆分的细粒度逻辑、一丝不苟的代码格式、行云流水般的留白管理，以及为了人类理解而不断优化的代码结构——曾经具有极高且持久的杠杆效应。五年之后，某位工程师偶然读到这段代码，会由衷感叹：“谢天谢地，这段代码写得如此清晰可读。”

如今，这类微观决策所带来的杠杆效应已经大不如前。这并不意味着人类的理解力变得多余。如果非要二选一，我永远宁可要一个人能看懂的代码库，也不要一个天书般的代码库。但在今天，阅读和理解是与精灵并肩进行的。精灵可以向我解释逻辑——前提是它没在胡说八道（当然，幻觉随时都在发生）。只要它没撒谎，我理解陌生代码的速度就会比过去快得多。

过去重构带来的那种严丝合缝、专注细节的愉悦感——内联变量、提炼方法、反复推敲参数命名直到万物归位——曾经美妙至极。然而，为了那几分钟纯机械操作所能获得的商业回报，如今已基本烟消云散。

不仅如此，在我看来，“手艺”这个词在历史上曾被一部分开发者劫持了。他们只想躲进自己的山洞里，幻想着天地之间唯有自己与机器，孤独地打磨代码，直到他们自认为完美为止。

我极度反感这种姿态：“这还没做完，因为我的手艺还没磨到位。”

当延误成本极高时，一个虽然丑陋但能立刻跑起来并提供即时反馈的程序，才是最正确的选择；反之，当延误成本很低、软件需要服役二十年时，瑞士钟表匠式的精雕细琢才会带来丰厚回报。但我绝不认同把开发者的个人审美体验置于交付周期之上的做法。

手艺依然是一门至关重要的纪律，但它的外在形态必须进化。

特性 vs 未来期权：一个人一周就能搞出十年的大烂摊子

让我把这个逻辑画给你们看。过去这 18 个月里，我重回一线，每天高强度使用增强开发写代码。吉恩·金和史蒂夫·耶格（Steve Yegge）给我看的一个演示让我热血沸腾，我知道自己必须重新下场。而且我打心底里喜欢和精灵一起编程。我的技术野心一直远大于我的手头能力；而现在，我可以去碰那些野心极大的架构，并且能迅速取得进展。

注意，我说的是“取得进展”，而不是“最终搞定”。

去翻翻我的 GitHub 仓库，你会看到一个项目名字后面跟着 Project 2、Project 3、Project 4。我总是一次又一次撞墙。我不断陷入那种修好一个 Bug 却引发两个新 Bug 的绝望境地。于是我只能推倒重来：新项目、新项目 2、新项目 3。我从来没想过把第一个项目命名为“Project 1”，因为每一次我都天真地以为：“这次不一样，这次我一定能走到最后。”

以下就是我对这种动态过程的可视化呈现：

未来期权 Futures (Optionality)
  ^
  | * (起点：期权最大化，特性产出为零)
  |  \
  |   * (实现特性 1 -> 未来期权下降)
  |    \
  |     * (特性 2 -> 未来期权进一步缩水)
  |      \
  |       * (撞墙：期权归零 / 彻底失控的烂摊子)
  +---------------------------------------------> 特性 Features

如果你把特性进展随时间画出来，会发现一开始推进神速，接着越来越慢、越来越慢，直到彻底卡死。

那另一个轴应该放什么？我称之为“选择权”，或者干脆叫“未来期权”（futures）——也就是特性（features）与未来期权（futures）的权衡。

任何项目启动之初，你的特性产出为零，但你的未来期权——也就是行动的自由度——是无限宽广的。当你实现第一个特性的那一刻，你就在消耗一部分未来期权。你要么背负了向后兼容的包袱，要么引入了限制未来拓展的假设。你做第二个特性，又消耗了一部分未来期权。你做第三个，消耗得更多。

最终，你撞墙了。选择权跌至绝对零点，因为代码库已经退化成了一团乱麻。那个时候，我只能选择弃船逃跑，重新开辟 Project 2。

在过去，需要一个上百人的研发团队埋头干上十年，才会把系统推向这种“动哪儿哪儿崩”的绝境。而今天托 AI 的福，一个程序员独自坐在办公室里，不到一周就能搞出同等规模的灾难。从“以极低资本开销光速制造无法维护的代码库”这一角度来看，这绝对称得上一次巨大的生产力飞跃！

在特性交付的间隙踩刹车：像大师一样在音符之间休息

那么，替代方案是什么呢？

未来期权 Futures
  ^
  | *
  |  \
  |   * ----> ^ (重构并恢复未来期权)
  |            \
  |             * ----> ^ (恢复未来期权)
  |                      \
  |                       *
  +---------------------------------------------> 特性 Features

交付第一个特性必然会消耗未来期权，这是不可避免的。但就在特性完成的那一刻，一个至关重要的窗口期被打开了。

当年我学音乐的时候，听过 20 世纪最杰出的大提琴家之一帕布罗·卡萨尔斯（Pablo Casals）的一则著名轶事。大提琴是一件对体力要求极其严苛的乐器。卡萨尔斯有一次演奏了一段极其漫长、连绵不绝的十六分音符乐句。演出结束后有人问他：“连续拉这么多音符，你不累吗？”

卡萨尔斯回答：“不累，因为我在音符与音符之间的间隙里休息。”

对于当时正在苦练演奏速度的年轻古典吉他学生来说，“音符之间存在间隙”这一概念简直如雷贯耳。（事实证明这个故事极大概率是杜撰的，但它所蕴含的启发实在太深刻了，不得不提。）

在软件开发中，我们同样拥有这个“音符之间的间隙”。当你完成一个特性时，精灵会冲你比出开枪的手势：“老板，搞定了！接下来想做啥？”

那一刻就是你的信号：深呼吸，踩下刹车，告诉它：“先等等，我还没准备好。”

这个停顿为你创造了一个机会，让你去修复刚才被消耗的未来期权——甚至能把系统的选择权提升到比动手前更高的水准。

当精灵向你比出那记手枪手势时，你应该说：“不。现在我要重构我们刚才写的东西。我要消除重复，我要优化结构提高可读性。我要废弃现有的实现，换个设计思路重写一遍，看看能不能提炼出更干净的抽象。”

在特性与特性之间的间隙中，有大量极高杠杆的工程活动必须发生。任何软件资产的真正商业价值，等于它当前交付的特性加上它的未来期权——也就是它在未来轻松演进的潜在选项集合。扩大它的未来期权，就是在为企业创造巨大的价值。

我们的目标是走出一条波浪式前进的轨迹：交付一个特性，恢复未来期权；交付一个特性，恢复未来期权。

这里的困境在于：借用《像国家一样思考》（Seeing Like a State）里的概念，特性是显性、可度量的。业务利益相关者看到了特性，举杯庆祝并立即获取价值。而未来期权则是隐形的，很难在账本上平账。为了让系统在未来面对不可预知的变更时依然游刃有余而优化代码库，在外行眼里纯粹是画蛇添足：“你为什么不直接去接下一个需求？”

因为如果你只知道闷头赶下一个需求，你的未来期权就会直坠归零，系统也就暴毙了。

在当下的特性与长远的未来期权之间平衡资本配置，是软件工程的核心挑战。精灵正在加速整个动态过程。研发周期被极限压缩。如果你下意识地批准每一个新特性，你确实能得到立竿见影的产出——大多数时候是个大致能跑的半成品。但当你停下脚步，去为架构做面向未来的加固、消除系统性隐患时，你所做的工作是任何产品规格书都绝不可能明确写出来的。

从来没有哪个用户故事会写着：“请让该系统能够从容应对未来的变更。”他们只想听到项目“完工”的汇报。但在我眼里，一个无法被修改的系统就是一个死掉的系统。我想打造的是能够主动激发出全新可能性的软件。

如果站得足够高来看，这种波浪式的轨迹就不再像是震荡，而是一个在不断积累功能的同时、同步扩张操作空间的健康系统。但妄图在一瞬间、一锤子同时搞定这两件事，对于人类和精灵的整体认知负荷来说，要求太高了。

取胜的策略是严格交替：推进一步，巩固一步；推进一步，巩固一步。

切洋葱的时候，你没法一边下刀一边擦刀。切几下，擦一下刀；切几下，擦一下刀。但这把刀你必须得擦。如果你走进一家米其林三星后厨，对流水线上的厨师说：“嘿，我看那把刀挺干净的，别擦了继续切吧，”主厨大概会拿刀指着你，然后再当着你的面把刀擦得干干净净。专业厨房之所以历经数百年演进出这套卫生规范，是因为这是他们生存的立足之本。

当年我提出极限编程时，听到过最棒的评价是一位观察者说：“顶尖团队在实战中本来就是这么干的。”它从来不是什么凭空捏造的抽象理论，而是对人类高效协作方式的经验性总结。如果我在里面加入了纯粹标新立异的东西，那大概率是个错误。

别被脱轨的快感冲昏头脑：软件工程本质上是一台“学习机器”

今天，我们掌握了一台能以惊人速度飞驰的引擎，它产生反馈回路的速度已经远远超过了我们组织消化或分析的极限。很多人忍不住想要把油门踩到底。

我认为这极其危险。

每一次我尝试搭建完全自主的 agent 架构——也就是所谓的“黑灯软件工厂”——项目无一例外都会脱轨。每一次都毫无例外。

最险恶的地方在于，它在彻底脱轨飞向悬崖的过程中，看起来还异常壮观。整场灾难堪比一场绝佳的视觉盛宴：你盯着终端，忍不住惊叹：“神了，看看它五分钟里居然吐出了这么多代码！”虽然吐出来的依然是彻头彻尾的垃圾，但那磅礴的体量实在太摄人心魄了。

摆在我们个人自律和工程管理层面前的真正挑战，恰恰在于能否守住特性之间的从容间隙，去耐心培育未来期权，抵抗住直奔下一个眼前特性的致命诱惑。

刚才台下有位听众说得很到位：“放慢节奏，才能为你留出构建真正理解所需的认知空间。”

一语中的。

我参与过的所有最卓越的软件，无一例外都出自将“最大化学习”作为核心目标的团队，能跑的代码只不过是这一过程自然沉淀出的副产品；反观那些只知道机器般流水线制造代码、把学习当成出故障时倒霉麻烦的团队，做出来的东西往往平庸至极。

一旦你把首要目标定为最大化学习，你的工作习惯就会发生质变。你的研发节奏会彻底调整。当代码变得臃肿泥泞时，你将不再恐惧将其付之一炬。

在职业生涯早期，我极其幸运地得到了 Wiki 发明者沃德·坎宁安（Ward Cunningham）的指导。某个下午，我们花了好几个小时死磕一个复杂问题。代码最终跑通了，但时间已经很晚，而且我们俩对整体设计都隐隐感到不安。

就在这时，毫无征兆地，沃德伸手跨过办公桌，一把按掉了电脑的电源开关。

我吓得差点从椅子上蹦起来：“你干什么？！我们花了一整个下午才写出来的！它都能跑了！你怎么能直接删掉？！”

那天我气急败坏地回了家。第二天一早，我们坐下来，仅仅花了整整齐齐的十五分钟，就把前一天下午的所有成果重新实现了一遍。代码优雅、稳健，且我们对其内部机理了然于胸。

那是我人生中的一个顿悟时刻：软件工程本质上是一个学习过程，可运行的代码仅仅是学习的副产品。而在无人值守的黑灯工厂里，根本没有任何人在学习——除了在最终摔得粉身碎骨时，大家再次想起精灵到底有多脆弱。可这一点我们早就心知肚明了。

规格驱动的虚妄：换了马甲的瀑布模型与偷懒的中学生

这就引出了我们行业里一个周而复始的认知误区：单发（One-shot）生成与演进式（Iterative）开发。

在规格驱动开发（spec-driven development）中，有一种极其强烈的诱惑让人误以为：“只要我写出一份详尽严密的规格说明书，精灵就能直接吐出实现；只要这份规格在数学上穷尽无遗，软件就必定正确无误。”

这种哲学在历史上早就有一个响亮的名字：瀑布模型（waterfall model）。而且它从来没有成功过。

如果你去重读温斯顿·罗伊斯（Winston Royce）1970 年提出瀑布模型图示的开山论文，你会发现，他在画完那张层层叠落的阶梯图之后，紧接着就在图下方白纸黑字写道：“我相信这个概念，但上述实现方式存在缺陷……它注定招致失败，因为下游发现的实际情况必然反过来推翻上游的假设。”就在紧接着的下一页，他画出了逆向回流的反馈循环。

然而整个工业界却彻底无视了后面那部分，只盯着第一张图自嗨：“要是我们能写出一份完美无瑕的规格书然后一劳永逸，岂不美哉？”这个幻觉直到今天依然阴魂不散。

刚才有人问起形式化验证（formal methods）。

我读研究生时，曾在一半时间在音乐学院、一半时间在计算机系之间来回切换。我曾担任过程序正确性证明课程的助教。那些思维模型早已刻进了我的骨髓；我每天都会非正式地使用不变量和状态空间分析。但我很多年没碰过形式化证明引擎了，直到最近，一位同事向我展示了 Lean 结合精灵的玩法。

我对形式化验证的保留意见主要有两点。

第一，它在很大程度上往往遵循一种单发式的范式。你构建出一份复杂的形式化规格，投入巨大的精力去验证其各项性质，并最终拿到了证明。但当残酷的业务现实迫使你哪怕更改其中的一条假设时，整条证明链条瞬间分崩离析。即便有 AI 加速底层证明过程，它依然会对软件的演进带来巨大的阻力。我想构建的是乐于拥抱变化的架构，而不是惩罚变化的枷锁。

第二，数学模型与物理机上真实运行的二进制文件之间，永远存在无法消除的鸿沟。你可以在抽象规格中证明所有性质完全成立，但当你把它编译成 C、C++ 或 ARM64 汇编时，这个推导断层依然横亘在那里。

（顺便插一句：看着精灵生成汇编语言确实是一大乐事。我最早接触计算机是和我父亲一起拿电烙铁焊接 MC6800 微处理器；而今天，你可以随口吩咐精灵用 x86-64 汇编实现一个精巧的数据结构，它转眼就能吐出来。用各种天马行空的方式去给精灵做压力测试，其乐无穷。）

现实情况是，结合严谨的自动化测试套件与防御性、防呆式的结构设计，你完全可以做到极低的缺陷密度。

真正的隐患在于：精灵天生是懒惰的。它极度渴望抄近道。它不会本能地去构建防呆接口，而且它非常乐于去钻测试套件的空子——比如直接返回硬编码的常量，或者假装满足要求——活像一个为了逃避家务而偷奸耍滑的十四岁中学生。要想和精灵携手产出值得信赖的软件，必须时刻保持警惕。

你是在开发能够创造真实世界价值、并能通过持续观察和学习来演进的软件？还是陷在不断膨胀的规格书里，发现不达标后又去起草更臃肿的规格书来亡羊补牢？

如果你只是在周末随手鼓捣一个玩具小项目，单发生成完全没问题。但如果你正在实操数据库内部构建一个嵌入式图引擎——正如我现在所做的那样——单发生成根本走不通。

那些极力鼓吹纯规格驱动生成的人，听起来就像从来没有维护过拥有十亿活跃用户系统的人。一旦身处极大规模的场景，持续高可用、状态迁移以及数据兼容性，会让任何单发式的推倒重写化为泡影。你必须从一开始就拥抱迭代演进。

生产力的陷阱：二十万行垃圾代码拯救不了核心使命

现在，让我回到开场时提到的那个谜题（Kent Beck 想到的全新思维方式）。

Effort（投入/成本） ---> Output（产出物） ---> Outcome（行为改变） ---> Mission（使命/宗旨）

请审视软件工程的价值链条。

我们投入Effort——工程工时、认知精力、运维成本。

这些投入沉淀为Output——PR 数量、功能特性、部署上线的二进制文件。

这些产出触达用户并引发Outcome——人类行为的客观改变。如果软件部署上线后没有改变任何人的行为，那么这段软件还不如不存在。当年从光盘盒装软件转型为 SaaS 之所以具有划时代意义，就是因为我们终于能够直接观察到行为结果了。

而今天让我豁然开朗的，是这根链条的最后一环：行为改变必须转化为Mission。我过去常常称之为“影响力”（Impact），但我现在更倾向于使用“使命”（Mission）。使命代表着构建系统的人与依赖系统的人之间所共享的最高宗旨。

工程指标的暴政恰恰潜伏于此。

管理层惊叹于精灵一下子生成了 20 万行代码。代码行数仅仅是投入（Effort）的原始量度。它与使命——无论这个使命是给老板买一艘超级游艇，还是捍卫国家安全——根本没有任何相关性。二十万行代码的价值绝不是两万行代码的十倍；在更多情况下，它纯粹是负债。

然而，投入与产出是最容易量化的，所以我们总习惯在路灯底下找钥匙。

因为精灵能以微不足道的投入带来空前膨胀的产出，很多组织便误以为这就是真正的生产力飞跃——极其幼稚地把生产力定义为产出与投入的比值。但无论你是统计代码行数还是追踪 PR 提交速率，衡量投入或产出从来都无法代表你是否推进了真正的使命。

量化使命是极其困难的。使命价值本质上具有突发性：你往往要等到危机降临的那一刻，才能检验出架构到底能不能扛得住。

同时开十个精灵或许能让你的产出激增十倍，但这绝不意味着你在真正至关重要的事情上取得了实质突破。

被扭曲的古德哈特定律与领袖的真正责任

你越是在这条链条的前端设立关键绩效指标（KPI），你与古德哈特定律（Goodhart's Law）的碰撞就会越惨烈：“当一项指标变成目标时，它就丧失了作为衡量指标的意义。”

古德哈特当年甚至过于乐观了。

当一个中间指标沦为考核目标时，人们不仅仅是钻空子作弊；他们会主动扭曲、撕裂整个组织的运作结构去迎合这个指标，在这个过程中把核心使命彻底牺牲掉。你损失的不仅是统计数据的真实度，你是在亲手毁掉使命的达成。

至于链条下游的使命阶段，责任归因又极其错综复杂：“核心使命提升了 7%，而我的团队为这微小的增量贡献了 0.075%。”那么年终奖该发给谁？如何去激励真正与使命对齐的工程行为，始终是摆在管理者面前的核心难题。

最后，我想分享一点关于领导力的思考。我很幸运，见证过自己的好几个想法在全世界的技术领域落地生根。

这一过程的核心本质，在于提炼出对使命的精准阐述，同时打动听众的理智与心灵。一旦你找到了这个核心叙事，你的职责就是重复、重复、再重复。

所谓领导力，就是永远不知疲倦地向人们讲述软件工程的卓越境界可以是什么样子——哪怕是第一千次讲述同一个核心观点，依然能保持初次登台般的新鲜感与激情。

直到终有一天，有人径直走到你面前，看着你的眼睛说：“我想出了一个绝妙的想法！”——然后滔滔不绝地把你当年的论点原原本本地背给你听，完全不知道这正是你的首创，连半点功劳都不会归到你头上。

就在那一刻，你就知道，作为一名领袖，你已经成功了。

如今，我们手中掌握着足以重塑全球价值创造方式的全新工具。摆在我们面前的工程使命，是如何驾驭这些工具，去服务于真正配得上人类崇高目的的事业。我期待在推动这一历史进程中贡献自己的微薄之力，更期待看到在座的每一位如何书写属于你们的篇章。

非常感谢大家。

很多刚关注的朋友常问，为什么我们叫「奇点折射」？

我们的初衷，其实正是那句话：“跨越 AI 奇点，折射产业未来。”

在大模型被铺天盖地的公关营销、资本泡沫与概念炒作裹挟的今天，AI 的爆发看似光芒万丈，但也刺眼而混沌。我们希望做一个坚持原创、拒绝喧嚣的 AI 观察站。将外界复杂的“AI 强光”，真真切切地折射为清晰的未来产业格局与工程现实。

穿透迷雾，看清底牌。欢迎关注「奇点折射」，并设为星标

当 OpenAI、Anthropic、Google，到智谱、DeepSeek、Kimi、阿里都开始密集发布自进化相关研究，RSI 正从概念走向真正的技术竞赛。

11 月 20—21 日，2026 奇点智能技术大会「大模型技术：从 Agentic Scaling 到 RSI」专场，将邀请一线研究者与工程专家，围绕 Agentic Scaling、RSI、自进化闭环、持续学习、AI 制造 AI 等关键问题展开分享。

同时，我们整理了 《RSI（递归自我改进 / 自进化）前沿研究资料包》，汇总 OpenAI、Anthropic、Google、DeepSeek、智谱、Kimi、阿里等最新论文、官方技术报告与研究出处。

扫描下方海报二维码，领取 RSI 前沿资料包，并了解专题参会详情。