← #803

如果编程已经被解决，为什么软件还在不断变差？

文章摘要

这篇原题为《Nothing Works and Everyone Is Euphoric》（一切都坏了，而所有人都在狂欢）的短文，来自博主 ptrchm。文章的出发点是一个刺眼的反差：一边是 Agentic 时代承诺的生产力与质量双提升——模型不断变强、程序员不断被裁、「年底 AI 将写出 100% 的代码」这样的口号满天飞、有人为了在自动化浪潮吞掉一切之前抢一块蛋糕而「token-maxxing」到把自己送进医院；另一边则是作者作为普通用户日复一日遭遇的、越来越糟的软件体验。

作者列举了仅仅一周之内碰到的几个例子。银行 App 平均要刷三次 FaceID 才能弹出 3D Secure 确认页。macOS 上打开 Slack，Dock 图标弹跳了好几秒都没反应，他不耐烦地切到 Ghostty 开始敲命令，结果 Slack 窗口这时候冒出来抢走焦点，git pull 就这么发进了群聊。冰箱发出怪声想走保修，LG 的多步长表单填到最后提交失败，而他之所以知道失败，是因为他打开了 JavaScript 控制台。车机系统刚做了一次更新，本来就不好用，现在更是每次开车都自己重启：转向灯提示音会随机静音直到重启系统、点地图打开的是收音机、点击后要等一到两秒才有反应——作者强调这已经不只是 UX 问题，而是直接影响驾驶注意力的安全问题。更荒诞的是，几个月前他在 LinkedIn 上刷到过重做这套车机 OS 的产品经理发帖自我祝贺「干得漂亮」。

作者随后做了两点重要的自我校正。第一，他不认为这是纯粹的怀旧偏误之外的错觉，但也承认 Snow Leopard 时代「一切都很稳」的记忆有选择性成分——那时软件确实更好，但主要是因为它简单得多；此后我们不断叠加新抽象、新前端框架、更复杂的基础设施，「用户体验」的及格线一路抬高，而整个系统变得越来越脆。第二，这篇文章不是在反 AI：那些嗡嗡作响的 GPU 农场确实给了我们超能力，问题是我们没有把这份能力用来造更好的软件。

他给出的真正病因是激励结构：软件厂商长期以 KPI 为导向，而「让东西更稳定」往往对数字没有直接贡献，在汇报 PPT 里也不好看——他虚构了一句 BigCo 产品经理永远不会说出口的话：「这个季度我们不发新功能，也不打算重新设计任何东西，我们只修 bug。」只要这种态度不变，软件质量的大衰退就会继续。

结尾却是乐观的：当公司们集体陷入「AI 债务」的漩涡时，个体开发者反而获得了前所未有的机会，去造出以前能力范围之外的软件。作者对自己车上的 Android Auto 和 LG 那个愚蠢的网站已经不抱希望，但他选择相信日常软件会因为这种普遍的挫败感而变好——我们已经能看到针对 macOS 和 Windows 现状的「反抗行为」，他希望这股风气能蔓延到整个技术栈。

HN 评论精华

这条帖子拿到 900 多分、680 多条评论，讨论极其发散。需要如实说明的是：票数最高的几条讨论串里，有相当大一部分并没有在谈软件质量，而是从文末链接的 Omarchy 发行版一路跑偏成了对 DHH 政治立场的长篇论战。以下按主题梳理。

「这跟 AI 没关系，一直就这样」是最主流的反驳

AussieWog93：「十年前我就注意到同样的现象了，我不觉得这和 AI 有任何关系。」
Jtarii：软件质量的下滑远早于 AI，「微软根本不需要 AI 就能把 Windows 11 做成那样」，大公司的激励结构本质上就与「造出人们真正愿意用的高质量软件」不一致。StilesCrisis 补刀：作者列举的例子基本都早于 LLM——macOS 应用抢焦点是老毛病，卡顿的车机在 LLM 之前就存在，LG 的网站在 LLM 之前也一样烂。
RugnirViking：复杂度 + 缺乏「把事情做对」的激励。「我们其实知道造好软件需要哪些工具（社会的和技术的），但面对巨大的复杂度，人们只想要下一个功能、下一个能被销售拿去邀功的东西。」
prologic 提出了一个有意思的框架：软件既没变好也没变差，你看到的只是「写代码的成本趋近于零」。成本趋零，缺陷暴露的速度就上升。软件按定义就是 malleable 的、几乎没有约束，所以极难做到「完美」——这也是他认为 SRE 会是少数存活下来的岗位的原因。

组织与激励诊断

hibikir（高赞）：很多产品失误来自「没有人真正拥有任何东西」的大型产品团队，内部目标对齐极差。「我在公司被激励去做的事，和我认为最重要的事毫无关系；而要穿过那个迷宫才能被允许去做更好的工作，根本不值得。」组织越小，错位程度越合理，但不冒高风险的话，去大而糟的组织反而是更好的路径——令人沮丧。
BobbyTables2：大组织里每个团队都要花荒谬的精力写「胶水」逻辑，去绕开另一个团队产品的设计/架构问题；双方都不真正理解对方的组件；而合作几乎不可能，因为那会打乱某个 PM 不切实际的排期、削弱他的权威。
xg15 一句话总结全文：「『编程已被解决』是上层管理者视角，不是开发者或用户视角——而那个视角关心软件质量和可用性的程度，大约相当于麦当劳董事会关心营养价值的程度。」
luciana1u：「结果瓶颈从来不是把事做得更快，而是把事做对，而我们把知道这个区别的人优化掉了。」
HackerThemAll 打了个比方：你设计厨房时把洗衣机放在一个门根本打不开的位置，请专业人士来，你期待他纠正你；但在软件里，自称「软件工程师」的人会照着指令把洗衣机放在那儿，因为「这不是我的活」——那不是工程师，那是码农旅鼠。

认为 AI 确实是加速器的一方

iLoveOncall：过去一年里大量软件明显变差，要么是没用的新功能（比如 Slack 近一年的所有新东西），要么是大量严重 bug。「显然罪魁祸首是审查不足的 AI 代码……没人再在乎韧性、良好实践和安全，所有人只在乎功能产出。所有归因于 AI 效率的『生产力提升』，实际上都来自这两年行业对任何标准和用心的彻底无视。不在乎的时候当然能拉出更多屎，AI 在这件事上什么都没改变。」pixl97 反驳：这最终回到用户身上——「只要用户还在买烂软件，为什么要花钱做 QA？你就是问题本身。你停用 Slack 了吗？他们因此亏钱了吗？没有的话，凭什么改？」
dminik 给了一个量化直觉：AI 是力量倍增器，假设平均带来 20% 提升——那么一个 0.8x 的开发者配上 1.2 倍的 LLM，得到的是 0.96x，而且移动的轴是速度不是质量。让本来就不在乎质量的开发者去 vibecode，你只会得到更大体量的 slop。他说这来自亲身经历：「我开始收到 devops 团队提交的功能 PR，这是一次非常有启发的体验。」
nope1000：AI 生成的代码会放大你代码库里已有的缺陷。如果架构烂、没文档、文档过期、需求含糊，AI（甚至一个好的人类开发者）凭什么能写出高质量软件？

焦点被抢这件小事引发了最长的技术讨论串

frameset（142 条子回复的起点）：KDE Plasma + Wayland 上有一个全局设置可以控制什么程序有权抢焦点，「用起来非常棒，每次不得不用公司的 Mac 或 Windows 时我都会想念它。」
fer：「我至今不理解为什么『焦点抢夺防抖』不是行业标准。如果我正在打字或操作某个 UI，任何其他 app 都不应该能抢走焦点，句号。想弹烦人的提示、发出愤怒的电脑音效、闪图标，随便。99.9%（如果不是 100%）的情况下，那件事和我正在做的毫无关系，完全可以等。想象一下你在终端里工作，某个程序决定抢走 STDIN——GUI 里我们为什么就接受了？」
TacticalCoder 分享了一个实用防御：当年用 Emacs erc 上 IRC 时他写了 elisp 保护，任何包含自己真名的内容都会被拦下。他建议所有「群聊类」软件都该有默认和可配置的过滤器，比如粘贴私钥或明文密码前要二次确认。

几个值得一提的少数派

smikhanov 逆向举证：过去十年里有大量「东西确实在变好」的例子被选择性忽略——六年前某大公司推出的新芯片让极客们狂喜，同时重做了整个 OS、全套软件、编译器和 SDK，还保证了旧芯片上写的一切继续可用；某家二十年前起步的存储服务从「每纳分钱每吉字节」做到「每皮分钱」，不丢数据、高可用，半个互联网的数据都放在那儿。
hypfer 对开篇的「AI 引发的集体精神病」提出质疑：那两个「被送进医院」的推文链接，可能只是有人为了十五秒网络成名而（假装）做蠢事，照单全收本身就是问题的一部分。
Biologist123 则从另一侧佐证：他做调解工作，最近确实见到几个案子，当事人与 LLM 手拉手构建了自己的法律主张，在事实明显可争议的情况下变得绝对确信——提交的所有文书一眼就是聊天机器人写的。
hasbot 给整个讨论区下了个评语：「这篇帖子和目前的评论让我想起 1984 里的『两分钟仇恨』。仇恨周什么时候？」Y-bar 接梗：「每周只要我得用 Jira 就是仇恨周。或者 SharePoint。或者 Slack。或者 Teams。或者 Magento。」
Y-bar 还给出了对怀旧问题最平衡的回答：Mac OS 7/8/9 时代每周都会硬崩几次，今天最多一个月一次；但变化的是小 bug 多了 1000%——当年似乎每个功能都真的能用，而今天光是到目前为止他就已经在系统和常用软件里遇到十几个小问题。「这是另一种形式的精疲力竭。」