速评：一份 8 月 23 日的 GSoC 2026 项目总结，我拖到这几天才点开。开头几段差点让我关页面——交付物清单、三人分工、六个月时间线，模板一个不落。
真正让我停下来的是一句话，作者自己写的：评审意见几乎都在让改动变小。
这句放别人手里，大概会被当成客套话滑过去。把这 31 个 PR 的合并记录摊开，它不是自谦，是账本。GSoC 的通稿向来只列做过什么，谁会把"我被删了多少行"写进总结当主线。
versions.json 那个数据结构，导师最初提的是六个字段的对象，latest、label、major、exactVersion、commit、frozen 一个不缺。评审最后一刀砍成纯 semver 标签的字符串数组，理由干净得没法接——剩下五个字段全能从版本字符串本身、以及它在数组里的位置推出来。六个字段里五个是冗余。这结构不是设计出来的，是被逼出来的。
许可证白名单更狠。作者自己写了允许列表加拒绝列表，评审整块删掉，理由是项目本身没有许可证政策，合并版不带任何配置。这块代码不是被简化，是被判定为不该存在。
手写 SVG 换图标库，第二个提交先把刚写的文件删了，净减 108 行。作者自己加的 commit 输入参数，评审一句"跨仓库触发并不需要它"，删掉。还有 URL——四个 PR 冒出四种症状，作者后来想明白了根因只有一个：手写的 URL 字符串都是潜在 bug。解法不是逐一找，是把所有链接都赶去走同一个 helper，让新问题长不出来。
5 月 28 日 #110 把 versions.json 立成唯一数据源，8 月 14 日 #241 收尾，中间七十多天，每一版实现都在往回收。
这剧本，反倒不眼熟。圈里大多数项目的 review 是 LGTM 排队，能有人认真说一句"这段去掉"就算负责了。这边是把一个学生六个月写的东西反复往小里收，收到六项交付物一个没少、总行数反而下来了。删代码不稀奇，删完还能把交付清单全须全尾交出去，才稀奇。
也不是所有复杂度都能砍。Lighthouse 那套被拆成两个工作流——审计以无特权身份跑、结果传 artifact，另一支拿到 pull-requests: write 才负责发评论。这不是为简洁拆的，是因为检出不可信 fork 代码的任务不能有写权限，安全模型画出来的线，谁也砍不动。能推导出来的删掉，推不出来的留着，这条分界线比总结里任何一句"学到了很多"都实用。
顺带说一个我个人比较服的点：Lighthouse 的阈值，作者故意设成警告不是报错，理由写得很直白——第一天就设成阻断门槛，会促使大家想办法绕过。这个判断的成熟度不太像第一反应。阈值定在哪是技术问题，知道人会绕着走，是经验问题。
但删得狠有个盲区，作者自己认了：31 个 PR 全都没带测试。CSS 和链接重写这类改动不带还说得过去，可 Lighthouse 那个格式化脚本是纯函数，类别规则也是纯函数，这类东西没测试，等于把"跑起来了"和"跑对了"之间的距离留给下一个人。队友在补，这条值得跟——砍代码砍不出测试来。
再往下翻评论，比整篇文章都硬的东西出现了。
Vinh Nguyen 指出派发环节本质上是即发即忘：createWorkflowDispatch 在 GitHub 接受事件之后立刻返回 204，所以 webpack 核心仓库那边的发布任务变绿，不代表 doc-kit 的 release.yml 真的跑过。应用令牌生成挂了、工作流文件被改名了，任一环节出问题，文档都是悄悄过期，全程不亮红灯。
这正好戳在整套设计最漂亮的地方。发布即触发、自动更新 versions.json、自动开 PR、Vercel 出预览、维护者合并——链路听着滴水不漏，可每一棒都只能证明"我交出去了"，证明不了下一棒有人接。作者负责的就是运维侧，六项交付物全部落地，截至发文链路也确实完整跑通过一次。问题恰恰在这句"跑通过一次"。
Vinh 给的解法我建议直接裱起来：用一个跟派发链路完全无关的定时任务做断言，读 versions.json 首项，跟 npm 上最新的 webpack 版本比，落后超过一个版本就失败。理由只有一句——告警不能和被监控对象待在一条失败路径上。
这句话的射程远不止 webpack。多少团队的监控就挂在告警系统自己身上，告警死了没人知道。
这里立个 flag：等 webpack.js.org 正式切过去之后，我回来核两件事。一是 Lighthouse 四个类目现在还全是警告，作者说要等八个审计 URL 的分数稳了，优先把可访问性升成错误，这道坎他跨不跨；二是 Google Search Console 里那个从发布到被索引平均 27 天的延迟，切换之后实打实是多少。
切过去之后真正会打脸的，不会是那 31 个 PR 的代码质量，是那条"跑通过了"的流水线，在人没盯着的时候还跑不跑。
跑通过一次，不算数。