代码变便宜以后，系统把账单转给了维护者 (2026)

先看结论

代码生成变快之后，软件工程没有少一笔账，只是账单换了收款人：从写出第一版代码的人，转到了负责定义正确、验证结果、维护依赖和处理事故的人身上。

北京时间 7 月 25 日早上的 Hacker News 热榜，把这件事放在了六个不同的场景里。Claude Opus 5 把模型能力和单位成本继续往前推；Buz 试图用 LLM 清理 Bun 的大块代码库；一篇关于软件质量的文章质疑「代码写得更多」为什么没有带来更好的产品。另一边，Postgres 的通知吞吐、摄像头固件里的 GitHub 管理员 token，以及一颗受引脚和面积限制的交换芯片，都在提醒同一件事：系统的难点从来不只在把东西做出来。

下表的分数、评论数和排序是当前热榜的抓取快照，不是永久排名。作者背景只写本轮页面能核实的内容；没有独立履历的地方，直接标为未公开。

当前热榜的六个切面

帖子	抓取时热度与发帖时间	HN 提交者 / 原文作者	原文事实与讨论分歧
Claude Opus 5	1213 分，665 条评论；7 月 25 日 00:57	`alvis`；Anthropic 官方发布页	Anthropic 宣称 Opus 5 接近 Fable 5 的前沿能力，价格为一半，并在多个官方评测中领先。评论区把争论拉回图表口径、实际任务成本、自动降级和人工往返时间。1 2
Postgres LISTEN/NOTIFY actually scales	174 分，28 条评论；7 月 25 日 03:05	`KraftyOne`；原文署名 Peter Kraft，背景未公开	DBOS 把流写入从约 2.9K 次/秒提高到最多 60K 次/秒，做法是应用侧缓冲并批量发送通知。评论区质疑 8000 字节通知上限、大型数据库配置和突发流量，作者澄清这不是修改 Postgres 内核。3 4
My security camera shipped a GitHub admin token in its login page	489 分，168 条评论；7 月 24 日 19:54	`hhh`；原文为作者第一人称，背景未公开	研究者从 Hanwha 摄像头固件中发现重复出现的 GitHub token，报告称它曾拥有组织内数百个仓库的管理员权限。评论区把问题扩展到 IoT 固件、应用包和硬编码凭据；作者称厂商在收到邮件后撤销了 token。5 6
If coding has been solved, why does software keep getting worse?	450 分，367 条评论；7 月 24 日 17:08	`pchm`；个人文章作者背景未公开	文章用银行 App、Slack、冰箱保修表单和车载系统举例，认为软件复杂度和 KPI 让稳定性长期吃亏，同时明确说这不等于 AI 是唯一原因。评论区更多指向产品所有权、目标错位和维护工作缺少回报。7 8
Buz, a fork of Bun using modern Zig	219 分，158 条评论；7 月 24 日 17:26	`kristoff_it`；原帖作者 `jazzzooo`，页面未提供可核实履历	作者称 Buz 仍远未达到生产可用，已删除超过 1.1 万行死代码，并暂不接受人工编码贡献，先用 LLM 整理约 60 万行代码。评论区争论测试是否可能证明错误架构是正确的，以及维护者如何保留人的判断。9 10
Designing an Ethernet Switch ASIC	78 分，20 条评论；7 月 21 日 05:35	`random__duck`；原文作者背景未公开	这是一篇仍留在当前 top 40 的旧帖，不是 7 月 25 日新发。作者把目标收窄到 3 端口、100 Mbps、cut-through、非管理型交换芯片，并公开引脚、面积、外部 PHY 和地址表等约束。11 12

1. 模型更便宜，验证成本没有消失

Anthropic 的发布页把 Opus 5 的卖点写成「接近 Fable 5 的能力，一半价格」，并列出 Frontier-Bench、CursorBench、ARC-AGI 3、Zapier AutomationBench 和 OSWorld 2.0 等结果。这里有一个很清楚的产品方向：模型厂商不再只卖单次回答，而是在卖每个任务完成一次所需的推理预算。1

HN 的争论很快绕开了宣传页。有人指出，Opus 5 在某些图表中的优势依赖评测、努力等级和成本口径；也有人认为，即使 token 更便宜，如果模型需要更多轮人工往返，人的时间就会把账单补回来。另一条评论把问题说得更实在：真正该比较的是完成任务的成本，而不是 token 数或单次输出价格。2

这给 AI 产品一个不太舒服的验收标准：模型回答得更好，不等于工作流更便宜。要把重试、人工检查、上下文整理、错误回滚和最终责任都算进去。否则所谓的成本下降，只是把一部分成本移到使用者身上。

2. 代码生成变快，维护没有自动发生

Buz 的作者没有把项目包装成一个已经完成的 Bun 替代品。他在 Ziggit 上写得很直白：项目仍处于早期，离生产环境很远；当前目标是把基于 Rust 重写前最后版本 Bun 的代码移到现代 Zig，并清掉作者认为的技术债。他称已经删掉超过 1.1 万行死代码，但同时也承认很多测试还没有通过，项目会持续追赶上游。9

更有意思的是它的贡献政策。作者暂不接受人工编码贡献，打算大量使用 LLM，把自己放在驾驶位上处理架构和代码质量。这个决定听起来荒谬，甚至有点像「禁止人类提交」的笑话，但它把一个通常被藏起来的事实摆到了台面上：生成代码和维护代码是两种不同的劳动。

评论区的反方也没有停在「AI 好不好」上。有人说 LLM 可以按明确指令重构，先设计再编码也能减少清理；另一边则指出，模型会忘掉 CLAUDE.md 里的规则，测试可能只是把错误的架构证明成自洽，形式化验证也不会替你确认需求是不是错了。10

所以，AI 编程工具真正稀缺的输入不是 prompt，而是判断标准：什么算正确，哪些抽象不该出现，哪些测试代表用户需求，谁有权拒绝一次「看起来能跑」的提交。

3. 软件质量首先是所有权问题

pchm 的文章列出了一串很具体的坏体验：银行 App 要连续触发数次 Face ID，Slack 窗口抢走终端焦点，冰箱保修表单在最后一步失败，车载系统更新后出现声音消失、误打开应用和一到两秒延迟。作者没有把这些例子简单归咎于 AI，反而说软件一直会有 bug，今天的问题还来自更多抽象层、前端框架和基础设施复杂度，以及稳定性在 KPI 里不够显眼。7

这段克制很重要。文章标题在问「如果写代码被解决了，软件为什么还在变差」，正文给出的答案却不是模型能力不足，而是团队没有把稳定性当成值得投入的工作。HN 评论沿着这条线继续追问：大产品团队里可能没人真正拥有一个功能，业务目标和用户需要也可能不对齐。8

这也是为什么「让 AI 多写一点」不一定改善产品。若验收标准只奖励新功能、发布频率或短期转化，模型会很有效地帮团队增加变更量，却不会替团队决定哪一个回归 bug 值得今天就修。代码供给增加以后，维护优先级反而更需要有人负责。

4. 性能数字必须连着语义和坏路径看

DBOS 的 Postgres 实验很适合说明一个常见误读。初始实现把每个流写入都放进触发器通知，受到 NOTIFY 提交时全局排他锁的限制，吞吐约为每秒 2.9K 次。优化后的做法把通知放进内存缓冲，周期性批量刷出，真正的数据仍在表里；读者在通知丢失时再用低频轮询补偿。作者报告在并发读者场景下最多达到每秒 60K 次写入，延迟为 15 到 100 毫秒。3

这不是一个简单的「Postgres 原来很快」故事。通知在这里不是事实源，只是叫醒读者的提示，所以丢一条通知可以通过回表发现；如果业务把通知本身当作不可丢失的事件，缓冲的语义就不成立。评论区还指出，NOTIFY 有约 8000 字节的数据限制，实验使用了 96 核、384 GB 内存的数据库配置，突发流量和连接位置也会改变结果。4

工程上真正可复用的部分不是 60K 这个数字，而是先问清楚：哪一层是事实源，通知丢了能否恢复，流量是平稳还是突发，测试机器和生产机器差多少。性能是约束条件的函数，不是产品标签。

5. 固件是供应链的一部分，不是代码的垃圾桶

安全研究者 hhh 下载 Hanwha 摄像头固件，解开多层压缩和加密后，用 trufflehog 扫到一个 GitHub token。报告称，这个 token 在约 30 个文件中重复出现，曾拥有该组织数百个仓库的管理员权限；作者又下载了约 500 份固件，能用同样方式提取约 62%，其中 3 份包含同一个 token。作者没有声称这证明 token 一定已经被攻击者使用，只是提醒访问摄像头管理界面的人可能接触到包含 token 的文件。5

报告给出的可能原因也很具体：摄像头 UI 使用 Vite 构建，把整个 CI 环境的 process.env 写进了前端文件。作者把问题发给 Hanwha 后，对方在 12 小时内回复并撤销 token。这里的修复速度值得记录，但不能抹掉前面的设计错误：凭据进入构建产物后，固件、镜像、缓存和设备管理界面都可能成为泄露面。5 6

这类事故和 AI 没有必然关系，却正好说明了代码自动生成时代的一个边界：系统不会因为某段代码由人写、模型写或脚本生成，就自动知道哪些内容不能被带进产物。秘密扫描、构建隔离、短期凭据和发布前撤销测试，仍然要有人把它们接进流水线。

6. 最可信的项目，往往先把目标缩小

Ethernet Switch ASIC 这篇旧帖仍留在当前 top 40，原因不在于它承诺了一个万能路由器，而在于作者把第一版目标压到了一个能被验证的范围：3 端口、全双工、100 Mbps、cut-through、非管理型交换芯片。由于 Tiny Tapeout 的数字 tile 只有 24 个 GPIO，作者选择外部 PHY；由于片上存储面积有限，又放弃了需要完整缓存数据包的 store-and-forward 方案。页面写明芯片已流片，预计 2026 年 11 月 15 日开始 silicon bring-up，这意味着它还没有完成硅后验证。11

这篇文章的价值正在于它没有把「开源硬件」写成一个无约束的愿景。引脚、面积、外部 PHY、地址表大小、TTL 和时序都被写成设计的一部分；有一个 RMII hold constraint 还被作者承认得太晚，下一版需要改成更严格的 2.0 ns。11 12

软件也需要这种诚实的缩小。先承诺一个能测的行为，再把依赖、边界和失败方式写出来，产品才有机会在离开作者电脑后继续工作。

代码便宜以后，四张账单会变得更清楚

把六条帖子放在一起，主线不是「AI 会不会取代程序员」，而是生产速度变快后，哪些工作仍然不能省：

定义正确。 Opus 5 的 benchmark 不能替团队定义什么叫任务完成；Buz 的测试也不能替人确认架构方向。
持续验证。 Postgres 的 60K 写入要连着通知语义、硬件配置和突发流量看；ASIC 的 100 Mbps 要连着 PHY 时序和流片后的 bring-up 看。
控制边界。 摄像头固件证明构建产物就是供应链的一环；软件更新则证明稳定性不是发布后的附注，而是功能本身。
承担责任。 文章里的坏体验、代码库里的死代码和模型输出的错误，都不会因为生产工具更快而自动找到负责人。

对团队来说，下一次把 AI 接入开发流程前，可以先问四个问题：这次生成的代码改变了什么架构假设？测试是否验证了用户真正需要的行为？构建产物里是否带走了不该带走的权限？出错之后，系统有没有回滚、回放或切回人工的路径？

这些问题没有模型发布页那么漂亮，却决定了便宜的代码最后会不会变成昂贵的系统。

代码变便宜以后，系统把账单转给了维护者