AI 编程

AI 编程的未来已经到来，只是分布得极不均匀

代码涨 30%、PR 涨 23%，上线功能却没多。AI 削掉的是意外复杂度；决定"建什么"的本质复杂度，还得靠人跟人对话。

AI 写代码的速度已经快到几年前没人敢想，但你每天在用的软件——Gmail、Canvas（课程平台）、Mac、iPhone 上的应用、Zoom、GitHub——过去一年并没有肉眼可见地多出一大堆新功能。与此同时，大公司一直在公开喊"全面上 AI"。借威廉·吉布森那句被引用无数次的话改一下就是：AI 软件的"未来已经到来，只是分布得极不均匀"。

Michael Hilton 在《The Last Software Engineer》2026-10-15 这篇里想解释的正是这种不均匀，并且他的结论是：不均匀是有原因的——而且原因不在写代码这一段。

一、先把"AI 没用"这个误读排除掉

作者说得很清楚：他不是在说 AI 没有影响。

一批新的、由 AI 写出来的软件确实在出现：一个操作系统、一些开发工具、Epic Games 启动器、游戏、一个社交应用，甚至有 Photoshop 替代品（原文补了一句：截至写作时质量参差）。
还有一类更日常的东西：作者自己用 AI 写了一整套脚本，几乎每天都在用——从"把评分标准录进 Gradescope"这种用完就扔的小工具，到一个用摄像头记录考勤的赛博物理系统。这些活在 AI 之前根本不划算做。

所以真正的问题不是"AI 有没有用"，而是：为什么有的软件因为 AI 变快，有的没有？

二、数据：代码 +30%，上线功能几乎不动

作者引了一篇哈佛的研究：样本约 70 万员工、700 家公司、约 3 亿条工作事件。结论是 AI 智能体的采用带来了大且显著的增长——

代码行数 +30%
提交数 +20%
PR 数 +23%

这组数字和他从行业里听到的、以及其他文献里的说法是一致的。但同一批研究去看"上线到生产的功能"这个指标时，只看到小幅正向、统计上不显著的效果。

于是问题变成了：写了这么多代码，为什么我们看到的软件功能增长差异这么大？

作者先排除了两个最常见、也最容易被当成解释的说法：

① 是滞后吧？ 不太可能。持续部署已经普及，很难想象大多数大公司会攒着 6 到 9 个月的功能压着不发。

② 是都在堆 LLM 功能吧？ 界面上的"闪亮按钮"（sparkle button）确实到处都有，Zoom 的 AI Companion 之类的功能也确实上线了，但作者认为这个量级解释不了 30% 的额外产出——你没有看到 30% 那么多的新功能。

三、"写代码"被接管了，"软件工程"没有

回到 2026 年初那条被反复引用的表态。Dario Amodei 说 Anthropic 有些工程师不写代码了，他们只做"代码周围的所有事"；紧接着又说："我不知道，可能还有 6 到 12 个月，模型就能端到端完成 SWE（软件工程师）的大部分甚至全部工作。"

作者的评价很克制，但很关键："写代码被 AI 接管"这件事确实发生了，可我们在"软件工程"任务上并没有看到同等幅度的收益。 两者不是同一件事——差别在于 code 和 software engineering 中间那一大段。

那一段是什么？作者的答案是一本书。

四、静脉导管与摩天楼

图 1：Atul Gawande《The Checklist Manifesto》（图片来自原文，书页链接见 https://atulgawande.com/book/the-checklist-manifesto/）。

《The Checklist Manifesto》讲的是清单怎么用。作者 Atul Gawande 一开篇给的是医疗领域的战果：在"插入静脉导管"这个流程里加一份简单的五步清单，效果惊人。

关键在于这件事的适用边界：清单对"小而定义清晰"的任务极其有效——而这一类任务，恰好也是 AI 最擅长的。

那对于复杂到没法事先写好清单的任务呢（书里举的例子是盖摩天大楼）？Gawande 去查了，发现清单这个概念仍然存在，但它已经不是一份任务列表，而是一份"必须发生的对话"清单：在建筑进入下一阶段之前，某些对话必须先发生。他给的例子是——电工必须在封墙之前跟石膏板工人谈过。

为什么？因为有些任务复杂到无法事先描述清楚，必须由专家在推进过程中持续对话，才能保证项目还在轨道上、每一步都做对了。

作者的观点很直接：建一个大型软件项目处在这条谱系的复杂端，更像盖摩天楼，而不是插静脉导管。 它没法压缩成一份短清单，它需要一整队专家各自用自己的专业判断，项目才可能成功。

五、1986 年的答案：意外复杂度与本质复杂度

这不是新问题。1986 年 Fred Brooks 在《No Silver Bullet》里就论证过：没有任何一项新技术能让软件生产率提升一个数量级。

他的理由是把软件的复杂度分成两种：

意外复杂度（accidental complexity）：来自工具——语言、编译器，以及"把想法翻译成机器能跑的东西"这整段工作。
本质复杂度（essential complexity）：来自问题本身——搞清楚软件到底该做什么，并确保所有部件能拼在一起。

Brooks 在 80 年代认为，针对意外复杂度的大幅改进已经基本发生完了。而作者说：过去几年 AI 毫无疑问又把这一层大幅削掉了一大块。 但即使意外复杂度被彻底消除，本质复杂度仍然在那里。Brooks 把这一点总结成一句话——造软件最难的部分是"精确地决定要建什么"（deciding precisely what to build）。

六、飞起来的项目，和原地不动的项目

作者的观察是：AI 开发最成功的那些案例，通常落在两类里。

第一类：一个人（或很小的团队）说了算。 比如 Omarchy 这类由单个开发者主导的项目——他可以对"软件该做什么"单方面拍板。决策成本极低，所以编码提速能直接变成产出。

第二类：有明确 oracle（正确性判据）的任务。 比如把老程序重写一遍（原文举的例子是 Halo）：对错可以被自动验证，AI 可以不停地跑下去。

而"功能速度低"的那一类，特征正好相反：大型软件项目、要决定往已有产品里加什么、没有明显正确的答案、并且有一大群专家和利益相关方，各自目标不同、优先级不同。

把这些人协调起来，和 Gawande 描述的电工与石膏板工人之间的对话是一回事。

于是作者给出了全文最锋利的一句推论：如果写代码变快了，但对话没有变快，那么"代码更多、功能没多"正是我们应该看到的结果。

维度	会飞的 AI 项目	原地不动的 AI 项目
决策人数	一个开发者 / 极小团队	一群专家 + 多个利益相关方
正确性判据	有明确 oracle（老程序行为、测试）	没有明显正确答案，靠判断与取舍
主要瓶颈	编码（AI 大幅削掉）	对齐与决策（对话，AI 削不掉）
AI 增益去向	直接变成产出	变成更多代码与更多评审负担
典型例子	Omarchy、重写 Halo 这类移植	大型产品的新功能

（上表为我们根据原文整理的对照，非原文图表。）

七、原文结论

"（AI 软件的）未来已经到来，只是分布得极不均匀。为什么？因为造软件的挑战本身分布得就不均匀。"

一个开发者可以拥有单一愿景，并以过去闻所未闻的速度实现它；有清晰 oracle 时，AI 可以不停地生成代码。但当你要在一个没有清晰答案的复杂环境里做复杂决策时，能写更多代码并不等于会有更多功能上线。

本质复杂度依然存在。AI 能显著加速 Software Engineering 里"Software"那一半，但"Engineering"那一半的挑战还在。不该假装消除了意外复杂度就等于消除了本质复杂度——不过作者说，他对这样一个未来感到兴奋：软件工程师可以把精力放在解决本质问题上，而不只是敲代码。

八、编者补充：怎么判断你手上这件事是"插管"还是"造楼"

原文的框架很好用，但它是解释性的，不是操作性的。我们把它压成三条判据和一个分工建议。

判据一：有没有唯一正确答案？ 能写成断言、能跑出红绿、能跟旧版本逐字节比对——这是插管，AI 可以直接推进到验收。需要"哪个更好"的判断、需要权衡取舍——这是造楼。

判据二：能不能一个人拍板？ 决策人数是最强的预测变量。一个人说了算的项目，编码提速能 100% 转化；五个人要开会才能定接口的项目，提速会被会议吃掉。

判据三：验收标准能不能事先写清？ 写不出验收标准的任务，自动化只会把不确定性往后推（生产线上的说法叫"把问题搬到下游"）。

分工建议：把 AI 放在意外复杂度上，把人的时间腾给本质复杂度。 迁移、脚手架、样板代码、补齐测试、批量改写、跨版本 API 替换——这些是 AI 的主场；需求边界、取舍理由、验收判据、跨团队的对话——这些是人的主场。这条线划错了，就会出现原文描述的现象：PR 数量涨了 23%，功能数量没动。

团队侧要多做一件事：给"对话"提速。 如果编码端已经加速，而评审、对齐、验收还按老节奏走，多出来的 PR 只会变成新的排队库存。站内三篇正好是这条线的补丁：

Claude Code 团队怎么做代码评审：7 层防线——把人工时间压到真正需要判断的地方。
交付验收门：绿测试与"Agent 说做完了"都不算证据——「有明确 oracle」这件事得落成可执行的检查。
AI 时代职业护城河：三种模式、工作流与判断力——哪些活交给 AI、哪些永远自己做。

另一组可以对照着看的数字：Anthropic 自己的就业与产出报告里，技术部门人均产出大幅上升的同时，初级岗占比从 21% 降到 14%——产出确实涨了，但这不等于"更多功能"，更不等于"更少的人"。

边界：作者自述他的观察是轶事性的（文中原文即标注 anecdotal），哈佛那篇研究与所有工作论文一样需要更多复现；"上线功能数"这个指标本身也很难量——部署了不等于被发现，被发现不等于被使用。另外，不要把这篇读成"AI 别用了"：作者的核心主张是加速该加速的那一半，别假装另一半也跟着加速了。

来源：Michael Hilton,《The future of AI software is already here — it's just not very evenly distributed》, The Last Software Engineer, 2026-10-15。原文链接：https://thelastsoftwareengineer.substack.com/p/the-future-of-ai-software-is-already（正文图片来自原文，已转存至站内）。

本文由汇智网编译整理，转载请注明出处。