码农早餐 · 2026-10-12

3 个月、5000 亿 token、4 个 Agent 分工反编译，上下文压缩阈值从默认 90% 手动压到 42%，第一个月就还原了约 80%，目标是可编译可读的 C++ 源码。看到这个数我第一反应不是「好厉害」，是这套编排方式比那个游戏更值钱——能不能复现才是关键。

烧掉 5000 亿 token：AI Agent 反编译出 FPS 游戏

3 个月、5000 亿 token、Claude Max 20x 加 Codex Pro 双订阅同时跑，4 个 Agent 分工：3 个反编译并提交，1 个专门审 commit 挑 bug。作者把上下文压缩阈值从默认的 90% 手动压到 42%，靠提前压缩省 token；Agent 之间用 Discord 一个频道互相通信，GitHub webhook 把 CI 失败直接甩进频道，谁改炸了谁自己看。第一个月就还原了约 80%，游戏能启动、主菜单能显示、地图能加载。目标不是跑通 demo，而是可编译、可读的 C++ 源码。看到 5000 亿这个数，我第一反应不是「好厉害」，是这账单换来的东西能不能复现——它真正的产出不是那个游戏，是一套能跑几个月的 Agent 编排方式。

来源：

• hackernews · davikr

重写成 Rust 后，重负载下通知送达率只有 1%

DHH 把 Campfire Once 从 Ruby on Rails 重写成 Rust，方式是让 AI agent 代劳——他自己不愿意读也不愿意写 Rust。之后又加了 Elixir 和 Go 版本。有人拿这几个版本做了对比，结果不太好看：在重负载下，Rust 版的新消息通知送达率只有 1%，而 Elixir 版是 100%。不过这两个数字的基数不一样，Rust 是在 6-7k 个事件里送达 1%，Elixir 是约 1.7k 个事件里送达 100%，直接比大小并不公平。

问题出在哪儿？作者 Piotr Sarnacki 指出，prompt 不够具体时，很多决定就是抛硬币：要不要保持向后兼容？更在意延迟还是吞吐？崩溃后丢掉新内容通知能不能接受？这些你没明说的问题，LLM 会替你默默回答。Rust 版就没保持 100% 向后兼容，为了缓存方便砍掉了 CSRF token，还用进程内队列替掉了 Redis；Elixir 版则更贴近 Rails 原版。这些差异跟语言无关，所以拿它们比语言优劣本身就不成立。代码层面也有硬伤：Elixir 版用一个进程串行处理所有 SQL 查询，连读操作都不并发；Rust 版则有数据库操作没走 async。Rust 的 async runtime 是协作式调度，任务不让出，同一 worker 线程上的其他任务就全等着——一个同步锁持有 10ms，整条线程跟着罚站。

他还重跑了一次恒定到达率的测试：100 POST/s 下，Rust 收到约 14% 的事件，Elixir 约 60%，看着还是 Elixir 赢。但同一档流量下 Rust 没有任何 HTTP 错误，Elixir 有约 23% 的 POST 请求超时，最坏的事件送达延迟接近 180 秒；Rust 在投递落后时会断开客户端，浏览器重连后拉取最新消息，反而绕过了漏掉的事件。原文到这里就断了，后面怎么收尾没说。折腾过 async runtime 的人都知道，这类坑不会因为语言换了就自动消失。

来源：

• hackernews · drogus

10 分钟 ChatGPT，换来第 13 题集体崩盘

先看这项研究到底做了什么。团队做了三组随机对照实验，一共 1222 人。第一组 354 人，一部分人自己做 15 道分数题，另一部分人旁边开着 ChatGPT，可以随时问、甚至直接要答案。开 AI 的那组一开始准确率确实更高——然后第 12 题之后，研究者把 AI 拿走了。那组人的正确率几乎是立刻掉下来，跳过题目的比例同时往上窜。同样的剧本在 667 人的第二组和 201 人的第三组（SAT 阅读理解）里又演了一遍。论文题目很直白：《AI 辅助降低坚持性并损害独立表现》，本周在 Conference on Language Modeling 上做了报告。这个结论今年春天先以预印本流传过一轮，WIRED、Psychology Today 都写过，现在过完同行评审端上来的还是同一个味道。

这里得说句公道话，标题里的「10 分钟」是实验里接触 AI 的时长，不是「10 分钟就永久废掉你」的意思。它测的是「撤掉拐杖之后」的表现，这个设计比「用 AI 的人更笨」的粗暴结论精确得多。真正被拿走的东西，论文里有个词叫 productive struggle——那种卡住、烦躁、想骂人、然后自己摸出答案的过程。你我都知道那几分钟有多难受，也知道答案从哪来的。

对写代码的人来说，这件事的落点不在「要不要用 AI」，而在你把哪一段外包出去。让 AI 写样板、查 API、翻译报错，这些本来就不产生认知；但遇到那种「想两小时没想通、想通了记一辈子」的设计问题、并发问题、性能瓶颈，直接要答案的代价，会在你下次没有 AI 的时候连本带利还回来。一个可操作的做法：卡住时先自己写三行思路再问，或者让 AI 只给方向不给代码。论文作者的建议也是这个——让回答更像 tutor，而不是答案机器。

来源：

• Using AI for Just 10 Minutes Erodes Your Ability to Persist at Hard Things

---

4 个 Agent 分工、Discord 频道通信、谁改炸了谁自己看，这套编排你敢不敢搬到自己手头的活里？敢，还是先等等。明早 8 点见。

本期从过去 24h 的 X / Hacker News / GitHub Trending 共 45 条信息中挑出 3 条（全天逐小时采写、经事实校对后于晨间选编）。内容由 LLM 辅助生成，每条均附原始来源链接，重要决策请交叉验证。