热核代码审查：一份提示词

来源：X @

2026 年 5 月 21 日，Cursor 工程师 eric zakariasson 在 X 上发帖，称 /thermo-nuclear-code-quality-review 是“目前 Cursor 内部使用最多的 skill”^[24,29]，该帖累计浏览量约 48.98 万次 ^[24,29]。热核代码审查（Thermo Nuclear Code Quality Review）由此进入公众视野。素材将其描述为一种通用“机制”^[0]；实际上它是 Cursor 官方 plugins 仓库中的一份 SKILL.md 提示词文件 ^[5,6]。

它是什么：Cursor 官方仓库里的一份 SKILL.md

这份 skill 位于 cursor/plugins 仓库的 cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md ^[5]。文件元数据将其定义为“对抽象质量、巨型文件和面条式条件增长进行极其严格的可维护性审查”，并将“热核代码质量审查”“深度代码质量审计”“尤其苛刻的可维护性审查”列为触发语 ^[5,6,22]；元数据还设置了 disable-model-invocation: true，即不允许模型自动调用 ^[5]。名字中的“热核”是刻意夸张的修辞——Codelynx 的作者解读说，“名字故意夸大，这正是重点：一场无情的代码质量审计”^[27]。

公开可查的形态就是这份提示词本身：SKILL.md 的主体要求审查代理“对当前分支的变更做深度代码质量审计，重新思考如何在不影响行为的前提下改进实现”，并强调“如果存在明显的重构路径，就大胆去做”“量两次，剪一次”（Measure twice, cut once）^[5,9,25]。从公开资料中只能看到提示词，没有任何训练数据或算法细节 ^[5,6]。它的分发方式同样是提示词包：pi.dev 上有社区打包的 @barlevalon/thermo-nuclear-code-quality-review-skill（v0.1.0），注明“基于 cursor/plugins”^[6,22]，在 Pi 中用 pi install npm:@barlevalon/thermo-nuclear-code-quality-review-skill 安装 ^[6]，在其他环境则用 npx skills add --skill thermo-nuclear-code-quality-review ^[27]。pi.dev 还附了安全提示：这类包可以执行代码并影响代理行为，安装第三方包前应审查源码 ^[6]。

审查规则：删掉复杂度，而不是挪动它

素材将功能拆成“抽象质量评估、代码气味检测、条件增长分析”三项 ^[0]，对照 SKILL.md，它们对应描述中的三个焦点：抽象质量、巨型文件、面条式条件增长 ^[5,6]。具体规则写进提示词，属于“不可协商的附加标准”，第一条就是“对结构化简化要大胆”^[5]。Cursor 内部使用者的概括更直白：删掉复杂度而不是挪动它，拦截超过 1000 行的文件，标记薄包装与泄漏的逻辑，拒绝能用但把代码弄乱的 PR ^[24,29]。

其中“文件超过 1000 行”是最出名的硬规则 ^[26,27]。这个阈值本身并不新鲜——业界 SQALE 标准就把“文件行数 < 1000”这类规则当作代码质量度量的最小单元 ^[11]。区别在于执行者：传统工具由扫描引擎按规则计算并折算成技术债 ^[11]，热核审查则将判断交给被提示词驱动的模型 ^[7]。Codelynx 总结它检查的正是可维护性与整体结构、1000 行规则、面条代码与纠缠的依赖，以及“把复杂度翻转成简化”的 code-judo ^[27]。

一次审查如何跑起来

公开演示来自 Matt Pocock 的 YouTube 频道（32.3 万订阅）：他让这个 skill 审查最近合并进主分支的几个 PR，并顺带通读了 SKILL.md ^[9,25,28]。在其开源项目 Sandcastle 上实测，约 7 条建议中 5 条真正有用 ^[7]。daily.dev 将其定性为“推动 AI 代理对结构化改进保持野心的严格自动化审查提示词”^[7]。

在代理环境中它可以被并行编排：Skills Directory 上出现了名为 Thermos 的衍生 skill，同时启动两个审查子代理——一个查 bug、安全与特性开关泄漏，一个查可维护性、结构、文件规模增长与抽象——再把两份结论综合起来 ^[10]。有人不拿它做审查，而是借其原则做规划：“用 /thermo-nuclear-code-quality-review 的原则帮我规划”^[24,29]。素材设想的“集成于编辑器或 CI/CD 流水线、合并前即时反馈”^[0]，也符合静态分析工具普遍以 IDE 插件、CI/CD 集成形态落地的主流做法 ^[49]。

代码气味与抽象质量：概念有研究，机制靠提示词

“代码气味”这个概念有扎实的研究支撑：它指源码中次优的设计或实现选择，往往让代码更容易被修改、更容易出故障 ^[20]；它最初被提出来作为软件设计问题的指示器，如今气味检测已是识别设计缺陷的成熟方法 ^[19]。学术界为此积累了大数据集（如 QScored 的代码气味与质量度量数据集）^[17]，也常用复杂度、内聚、规模、封装、耦合、继承等度量配合机器学习模型做自动检测 ^[21]，近年用机器学习研究气味的论文呈上升趋势 ^[18]。

但热核审查并不运行这些检测器。它没有公布任何度量计算或模型，公开形态就是要求审查者“极端严格、大胆重构”的提示词 ^[5,7]；“什么是好抽象、哪里算坏气味”，由被提示词塑造的模型来判断。

边界：严格是有代价的

它被有意设计得苛刻 ^[5,27]，代价也由此而来。合并节奏上，它会拒绝“能用但把代码弄乱”的 PR ^[24,29]，对想快速合入的团队是摩擦。建议质量上，实测 5/7 的建议真正有用 ^[7]，其余未必值得采纳。AI 审查的固有短板是难以理解项目特有惯例与复杂业务背景 ^[51]。它的典型用法因此是“用 AI 快速写完代码后，确认没在代码库里留下炸弹”——Codelynx 的作者把它当作应对 AI 快速开发积累技术债的安全网 ^[27]。素材还提醒，这类审查可能有较高的计算开销、更长的构建时间，更适合核心模块的深度审计，且不能替代人工 review 的沟通价值 ^[0]。