质检规则最初被做成了提交前的一道闸——后来摘掉了。同样一套规则，放在「挡住正在干活的人」和「事后给主管看」两个位置，误伤的代价差着数量级。

任何靠人维持同步的副本，迟早会漂。README 里手写的版本号落后了五个版本，更新日志被抄成三份——把它们收成单向的真源关系，再给「漏写不报错」的地方装上闸门。

拿埋点数据做 A/B 归因，得出「新功能上线后准确率掉了一大截」——被当场指出口径有问题。那个字段从头到尾只记录了其中一方的输出。

发版被拆成五步串在一条 npm 命令里。每一步都有自己的闸门——而最容易出事的，是那些失败时不报错的地方。

这个项目的大部分代码是和 AI 编码助手一起写的。真正决定协作质量的不是模型，是那些写给它看的文档、给它设的闸，以及几次它（和我）被自己的记忆骗到的经历。

一个看似只需要一行代码的判断，被宿主系统的改版打穿了三次。每一代都有一个看起来天经地义的依据，而每一个依据都在某天悄悄失效。

过滤器写错不报错，而是「看起来查到了全量」。在这样的接口上做相似检索，第一件事是验证你的过滤条件真的生效了。

三级分类树里 38% 的叶子重名，加分改变不了「同名无法区分」。于是先分流再打分——然后树被改了层级，锚点淹没了小系统，分词器切不开连写的中文。

第一版只把框架当变量字典，控件样式全部重写——被一眼看穿「根本没用上」。改成真用之后，又踩到了全局样式框架会悄悄改写你以为自己控制的属性。

入口迭代了三次。最后删掉的那颗小球做得很精致——贴边三档、换位手柄、呼吸动画。问题恰恰在于它看起来太像一个「东西」了。

一年里最贵的那些 bug，没有一个是因为不懂某个 API。全都是因为相信了一件不该相信的东西——八条原则，每条配一个真实案例。

同一件事，写死一条链和交给模型自己编排，差别不在能力上，在于出问题时你能不能定位到是哪一步。

「调试日志」开关立项就有，但它只管得住两个文件——其余三百多处裸 console 拨不拨都照样刷屏。收口的过程里有四条规矩和一个环形缓冲。

一个不能上架、不能开源的浏览器扩展，靠一个人做完分发、更新、鉴权、公告、更新日志、统计和排障。这是整个系列的地图。