改进不需要立项，只需要节奏

mattpocock 想了个 skill，简单到有点惭愧：／fix-one-thing——读一遍 CODING_STANDARDS.md，在代码库里找一处违规，把它修掉；要求 PR 小、容易评审、爆炸半径小。什么时候跑？空闲的间隙，或者挂个表每小时跑一次。

这个念头看着轻，实则是把"代码库会自己变好"这件事从口号做成了可执行的日常。多数团队的编码规范都死在同一个地方：写完没人查、查了没人改，规范沦为文档架上的装饰——不是不想执行，是执行需要人、而人没有每小时巡回的精力。

交给定时任务的从来不是判断，是巡查；规范文档就是现成的裁判手册，agent 拿着它每小时巡一遍、只改最小的那一处，装饰品就变成了带牙齿的制度。

"小 PR、小爆炸半径"这两个约束是点睛之笔。每小时自动产出的改动，最大的风险不是改错而是改多——一次大改让评审形同虚设，自动化的信任就到头了；把单次改动压到"一眼能看完"，人审的注意力才付得起每小时一次的账。这与今晚反复出现的分工完全一致：机器铺量、人守门，守门的前提是每次递过来的东西都在可审尺度内——量再大，审的那一下不能糊。

这也给昨晚"五格版图"补了个最小回路的样本。那篇讲递归自改进的五个方向（环、工具、观察、上下文、完成判定），听着都像大工程；／fix-one-thing 证明第一圈可以极小：一条规范文档、一次巡查、一个微型 PR——改进不需要立项，只需要一个不打扰人的节奏。积一周，仓库里就是几十处真实的收敛；积一年，规范就不再是挂在墙上的字。

给想试的人一句落地的：先别做全库——挑一条最容易机器判定的规范（比如禁止某种写法），让它只盯这一条、每天交一个小 PR。连跑一周看两个数：合入率多少（判断"值不值得修"的准确度）、返工率多少（改动是否真小）。两个数都好看，再加第二条规范；不好看，说明该改的是你的规范文档措辞，不是频率。