夜雨聆风
这两天刷到 Cursor Team Kit 里面一个很厉害的 Skill。
名字也挺狠，thermo-nuclear-code-quality-review。
光看这个名字，你大概就知道它不是来给你鼓掌的。
它的定位很简单，就是在 PR 合并之前，专门抓那种「能跑，但是让代码库变得更糟」的改动。
说真的，我觉得这句话挺刺耳的。
因为过去一年很多团队上 AI 写代码以后，最容易形成的错觉就是，只要功能跑起来了，只要测试绿了，只要页面能点了，这个改动就算过关。
但工程里真正吓人的东西，往往不是红色报错。
而是那些安静通过的改动。
多包一层函数。
多塞一个 if else。
把一个文件里的复杂逻辑搬到另一个文件里。
PR 看起来很规整，diff 也不大，甚至 demo 还能跑。
但代码库的心智负担，又重了一点。
thermo-nuclear-code-quality-review 狠就狠在这里。
它不是问「这个功能能不能用」。
它问的是「这次改完以后，这个代码库有没有变得更好维护」。
这个标准一下就把很多 AI coding 的幻觉打碎了。
因为 AI 太擅长补丁式解决问题了。
你说这里报错，它给你补一个分支。
你说类型不对，它给你加一个 adapter。
你说这个地方复用一下，它给你抽一个 helper。
每一步都像是在帮忙，但连着跑十几轮以后，一个原本还算清楚的模块，可能就变成了一个谁也不敢碰的迷宫。
这不是 AI 写错了。
更麻烦。
它是 AI 把问题写「对」了，但用一种会污染代码库的方式写对了。
所以这个 Skill 的第一条原则我特别喜欢，删除复杂性，而不是搬运复杂性。
很多所谓重构，其实只是把复杂度换了个地方藏起来。
原来 A 文件里有一坨逻辑，大家觉得难看，于是抽到 B 文件里。
表面上 A 文件清爽了。
但调用栈变深了，名字变抽象了，读代码的人要来回跳三次才能明白原来那段判断到底在干嘛。
这不叫简化。
这叫换地方堆杂物。
真正的简化应该让系统里的总复杂度下降。分支少一点，概念少一点，重复规则收回到正确的位置，读者不需要在五个文件里拼一张脑内地图。
这块我觉得对 AI 写代码尤其重要。
因为 AI 很喜欢「显得像工程」。
它会给你抽象，会给你命名，会给你拆层。
但有时候那个抽象就是一张很薄的纸。
第二条更直接，阻止超过 1000 行的文件。
这是一条很粗暴的红线。
但我反而觉得粗暴得很有价值。
一个文件超过 1000 行以后，通常就不是代码多一点的问题了，而是它已经开始承接太多责任了。
状态管理也在里面。
业务规则也在里面。
接口转换也在里面。
特殊 case 也在里面。
你改一个地方，心里会虚，因为你不知道另一头会不会炸。
更糟糕的是，AI 还特别容易继续往这种大文件里加东西。
因为它读到了上下文，看见前面就是这么写的，于是非常顺手地照着风格再补一段。
大文件会吸引更大的文件。
这玩意有点像工程里的重力井。
你如果没有硬上限，它就会一直吞。
第三条，是标记 thin wrappers 和 leaked logic。
thin wrapper 就是那种看起来有封装，其实只是在转发参数的函数或者类。
比如上层调用 A，A 调 B，B 又调 C，中间每一层都没增加真正的语义，只是把参数原封不动传下去。
这种代码最讨厌的地方是，它让系统看起来更「架构化」了，但理解成本反而上升。
你想找真正干活的地方，要一路穿过一堆空门。
leaked logic 更隐蔽。
它指的是本来应该被某一层封装起来的业务规则，散落到了调用方。
比如权限判断本来应该在 service 里，结果页面层也判断一次，API 层也判断一次，某个 hook 里又补一段特殊逻辑。
短期看是快。
长期看就是边界被打穿。
下次规则一变，你根本不知道要改几个地方。
这也是我觉得很多 AI 生成代码最危险的地方。
它会为了完成当前任务，把规则就地写在最方便的位置。
它不一定知道这个规则应该属于哪一层。
或者说，它知道，但它没有足够强的审计压力去坚持。
于是项目里到处都是一些「看起来合理」的小判断。
每个都能解释。
合起来就很要命。
第四条其实是整个 Skill 的灵魂，拒绝「能工作但让代码更乱」的 PR。
这句话我觉得可以贴在每个 AI 编程团队的墙上。
功能正确，不等于可以合并。
测试通过，也不等于可以合并。
维护性不是锦上添花，它应该是一等公民。
以前人写代码的时候，团队还可以靠 code review 慢慢磨。
但 AI 介入以后，代码产出速度突然变快了。
一个人一天能开很多 PR。
以前一周才积累出来的结构腐蚀，现在可能一个下午就堆出来。
如果 review 只盯着功能对不对，那相当于把门开了一半。
真正需要拦住的，是那些不报错、不爆炸、但会让下一次修改更痛苦的东西。
更有意思的是，它没有让审计 agent 自己到处乱翻。
这点很反直觉。
很多人做 agent，第一反应是给它更多工具，让它自己探索仓库，自己找 diff，自己读文件，自己下判断。
听起来更智能。
但 code review 这件事，太自由反而是坏事。
因为 review 的价值不是逛仓库，而是在固定证据上做苛刻判断。
所以它先让父 agent 把案卷准备好。
一个 shell 子 agent 跑 git diff <base>...HEAD，默认 base 是 main。
另一个 explore 子 agent 抓变更文件的完整内容。
然后父 agent 把两份东西整理成结构化 prompt，明确分成 ### Git / diff output 和 ### Changed file contents。
审计 agent 到这一步才进场。
我喜欢这个设计的原因也在这里。
它把「收集事实」和「做判断」拆开了。
不是为了显得架构复杂，而是为了避免审计 agent 在探索阶段就被噪声带跑。
很多时候我们让一个 agent 自己探索、自己收集、自己判断，它会在探索阶段就被带偏。
一会儿看到老代码有问题，一会儿看到 README 也该改，一会儿又想顺手重构别的模块。
review 就变成了散步。
但这个 Skill 的思路是，父 agent 把案卷整理好，审计 agent 上来只开庭。
而且它还有一个很重要的约束，只评判 diff 中看得见的东西。
但如果改动碰到了模块边界，就要追踪跨文件影响。
这个平衡挺关键。
只看 diff，容易变成局部审查。
到处发散，又会变成泛泛而谈。
它要求你盯着这次改动，但不要假装边界不存在。
说实话，这比很多团队的人肉 code review 还更像 review。
还有一个 fallback 逻辑也值得说一下。
如果 Cursor Team Kit 插件不在，它就退化成一次严厉的可维护性审计。
目标还是那几个，尽量大胆简化，不让文件无故膨胀到 1000 行以上，不容忍随手加 if else 让分支乱长，要求显式类型和清楚边界，尊重 canonical layers。
这反而说明，这个 Skill 最有价值的地方不是插件本身。
是它把团队平时不好意思说出口的话写硬了。
「这个 PR 能跑，但我不想让它进来。」
很多 code review 里，最难拒的就是这种改动。
你说它错吧，它没错。
你说它不完整吧，它也完整。
但你心里知道，它会让下一个人多绕两层，多猜一个规则，多背一段历史包袱。
AI coding 把这个问题放大了。
以前这种结构腐蚀是一点点来的，现在可能是一个下午来的。
所以团队不能只升级生成能力，也要升级拒绝能力。
不是拒绝 AI。
是拒绝那些把维护成本留给下一个人的代码。
这件事如果不流程化，最后一定会输给速度。
因为「先合了再说」永远比「停下来想想边界」更诱人。
代码质量不是靠口号守住的。
是靠每一次 PR 门口，有人认真问一句。
这个改动，是让系统变简单了，还是只是把复杂性换了个地方藏起来？
如果答案是后者。
那它就算能跑，也不应该合并。
参考来源：
Cursor Marketplace, Team Kit，https://cursor.com/marketplace/cursor/cursor-team-kit Cursor official plugins repo, thermo-nuclear-code-quality-reviewagent，https://github.com/cursor/plugins/blob/3347cbab5b54136f6fba0994c3a01a56f7fb7fca/cursor-team-kit/agents/thermo-nuclear-code-quality-review.md
🔥 精选文章推荐
awesome-design-skills：让 AI 写前端时终于有一点设计品味
AI让代码写得飞快，Code Review却成了“堰塞湖”？技术负责人的破局手册来了
别再乱喂 Agent 了：Superpowers 把 coding agent 的开发流程做成了一套方法论
