码农早餐 · 2026-10-17

Claude 写了 Claude Code 约 90% 的代码，PR 数量翻倍的同时 revert 率还降了 40% 以上——他们的做法是每个 finding 先让一组 agent 交叉投票，够票才发给人看。我觉得真正值得抄的不是「让 AI 写」，而是这套把人从读代码里捞出来的过滤机制。

Claude 写了 Claude Code 九成代码，他们怎么审？

Claude 写了 Claude Code 自身约 90% 的代码。这句话是整篇官方博客的开篇第一句，也是理解后面所有流程的前提——代码产出量到了这个级别，逐行人工 review 在物理上就不可能了。从 6 月到 9 月，合并进 Claude Code 代码库的 PR 数量翻了一倍多，同期被 revert 的比例反而降了 40% 以上。他们没取消 review，而是把「读代码」这件事大部分交给了机器，把人的时间留给机器判断不了的问题。你如果正在被 PR 队列压着，这组数字值得先记下来。

具体怎么做的：每个 PR 在人工看之前先过一遍 Claude review，它会拿 diff 对着整个 repo 和 PR 声明的意图问三个问题——这个改动解决了它要解决的问题吗、符合系统设计吗、会不会弄坏别的东西。更关键的是，每个 finding 在给人看之前，先由一组 agent 交叉投票验证，够票数才发出来；只涉及风格、诊断、清理的 finding 直接丢掉，这套过滤是他们拿自己的 PR 做过 A/B 才留下的。发出来的按严重程度排序，并标注 Important、Nit 还是 Pre-existing——不是这个 PR 引入的 bug，不会算在作者头上。安全审查单独一层，bug review 或 security review 只要有 finding 没关，PR 就不能合并，要么修，要么写一句理由关掉线程（这也是误报的出口）。管理员可以按 repo 设 Quick、Standard、Deep 三档，Deep 用在一个漏掉的 bug 比多花的时间更贵的仓库。研究预览阶段上线时，内部拿到实质性 review 评论的 PR 占比从 16% 涨到 54%。

有个细节值得单独拎出来：当自动 reviewer 反复标同一件事，他们的处理是去改源头——改 skill、加 lint 规则，或者更新 CLAUDE.md 和 REVIEW.md。CLAUDE.md 告诉 Claude 这个项目是什么（技术栈、约定、目标和非目标），每次 review 都会加载它，所以在大代码库里必须写短；REVIEW.md 由 code owner 写，讲清自己那块地盘上什么算失败——文档是「它在撒谎」，配置是「它路由错了」——并且要求 finding 必须给出文件名和行号当证据，不接受从变量名猜。他们团队自己的判断是，「有没有人读过这段代码」是个不精确的代理指标，真正该问的是「这个改动可能坏在哪，哪种检查——自动的还是人工的——才是抓它的正确工具」。原文没说这套流程之后有没有出过事故。

💡 主厨说：我站「把人的时间留给只有人能干的事」这条，但前提是 revert 率不涨——他们降了 40%，这个数才是这套流程的合格证，没有它，省下的 review 时间只是挪到了修 bug 上。

来源：

• How the Claude Code team does code review

Postgres 19 延期：AI 审查员找出的 bug 多到修不完

Postgres 19 推迟了，原因有点反直觉：AI 审查工具报出的问题数量超过了人类能处理的速度。原文只有标题和导语，没有给出具体 bug 数、延期多久、是谁在跑这些审查工具，所以细节我不替它补。但这件事本身值得写代码的人留意——AI 找 bug 的能力已经强到能把一个成熟数据库的发版节奏拖住，可它报出来的东西有多少是真问题、有多少是噪音，目前没人替你筛。反过来想，先别急着把 AI 审查塞进 CI 当门禁，它现在更像一个话多且不累的同事，产出得有人接得住。

来源：

• hackernews · magoghm

android/skills 冲上 GitHub 趋势榜，仓库页没写它是干什么的

android/skills 出现在 GitHub 趋势榜上，趋势值 35。仓库地址挂在 android 组织下，但页面上的 About 一栏是空的，没有描述也没有官网链接，抓到的正文基本是 GitHub 自己的导航菜单，看不出里面装了什么。所以现在能确定的只有一件事：官方组织开了个叫 skills 的仓库，并且被推到了趋势榜上。要不要点开看，取决于你对「skills」这个词在当下语境里的联想——但仓库自己没说，我也不替它说。

来源：

• android/skills

64 维 key 的容量账：线性层 64 条，自注意力上百万

一篇不查资料、纯靠直觉重推 Transformer 的长文，把线性层、MLP、自注意力统一看成三种「记忆仓库」，用干扰信号比来算各自能装多少条记忆。作者给的数字是：key 取 64 维时，线性层大约 64 条，MLP 约 2700 条，自注意力能到一百万以上。对天天调模型的人，这套视角的价值不在背结论，而在解释为什么加宽、加深、换注意力各自换来的是什么——容量和召回率是两笔账，不是一回事。想搞懂 attention 到底在存什么，这篇值得点开。

来源：

• You could have invented transformers from memory

单台 Mac Studio 跑 816B：苹果 MLX 把双机门槛压到一台

前两期我们聊过 Muse Spark Open：816B 参数、开放权重，得两台 Mac Studio 才跑得起来，门槛不低。今天苹果 ML 研究给了个转折——最新版 MLX 加 RDMA over Thunderbolt，单台 Mac Studio（最高 512GB 统一内存）就能跑，四台集群解码超过 36 tokens/秒，比人读得快。

要注意实测条件：Muse Spark Open 是 MoE，816B 里只有 42B 活跃参数，而且是在 NVFP4 4-bit 量化下测的，不是原生精度。同批还测了 Mistral Medium 3.5（128B）和 Qwen 3.8（27B），对比 M5 Ultra 和 M3 Ultra 两代，指标是 TTFT、吞吐和峰值功耗。

所以「双机才能跑」没被推翻，是被压低了：单机起步、多机扩展。想本地跑大模型的人，现在该看的是量化和内存占用，不是参数量。

来源：

• Apple ML Research: Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio

---

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