> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AI 编程的未来已经到来，只是分布得极不均匀 - URL: https://www.hubwiz.com/blog/ai-coding-velocity-feature-gap-essential-complexity/ - Published: 2026-10-27T14:59:45.000Z - Updated: 2026-10-27T15:50:29.000Z - Description: 代码涨 30%、PR 涨 23%，上线功能却没多。AI 削掉的是意外复杂度；决定"建什么"的本质复杂度，还得靠人跟人对话。 - Author: admin - Tags: 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 中间那一大段。 那一段是什么？作者的答案是一本书。 ## 四、静脉导管与摩天楼 ![《The Checklist Manifesto》封面](https://www.hubwiz.com/blog/content/images/2026/10/checklist-manifesto-book-cover.jpg) 图 1：Atul Gawande《The Checklist Manifesto》（图片来自原文，书页链接见 [https://atulgawande.com/book/the-checklist-manifesto/](https://atulgawande.com/book/the-checklist-manifesto/?ref=hubwiz.com)）。 《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 层防线](https://www.hubwiz.com/blog/claude-code-team-code-review/)——把人工时间压到真正需要判断的地方。 - [交付验收门：绿测试与"Agent 说做完了"都不算证据](https://www.hubwiz.com/blog/agent-delivery-verification-gates/)——「有明确 oracle」这件事得落成可执行的检查。 - [AI 时代职业护城河：三种模式、工作流与判断力](https://www.hubwiz.com/blog/ai-career-moat-three-modes-workflow-judgment/)——哪些活交给 AI、哪些永远自己做。 另一组可以对照着看的数字：Anthropic 自己的[就业与产出报告](https://www.hubwiz.com/blog/anthropic-employment-hiring-output/)里，技术部门人均产出大幅上升的同时，初级岗占比从 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。原文链接：（正文图片来自原文，已转存至站内）。 本文由汇智网编译整理，转载请注明出处。 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/) **相关阅读** - [AI 编程之后，软件会像 Excel 一样通用：不再有版本更新](https://www.hubwiz.com/blog/generalist-software-like-excel/) - [AI 时代职业护城河：三种模式、工作流与判断力](https://www.hubwiz.com/blog/ai-career-moat-three-modes-workflow-judgment/) - [Agent 说"做完了"，证据呢：三道交付验证门](https://www.hubwiz.com/blog/agent-delivery-verification-gates/)