SuperAPI AI 工具集

cursor-cursor-team-kit-thermo-nuclear-code-quality-review

编程与开发

查看项目

更新于 10-16 06:07

技能介绍

用途

Thermo-Nuclear Code Quality Review 是一个用于 Cursor 的代码审查技能,面向对实现质量、可维护性、抽象质量和代码库健康要求极高的场景。它要求审查者不局限于指出局部清理机会,而是主动寻找“代码柔道”式重构:在保持行为不变的前提下,让实现显著更简单、更小、更直接、更优雅。

主要能力

该技能以一段基线提示词为核心:对当前分支的改动执行深度代码质量审计,重新思考如何组织或实现改动以在不影响行为的前提下实质提升代码质量,改进抽象与模块化,减少意大利面式代码,提升简洁性与可读性;鼓励大胆重构,要求极其彻底与严谨,做到“量两次,切一次”。

在此基础上,技能附加了不可妥协的审查标准,包括:

  • 对结构性简化保持野心,不满足于“可以更干净一点”,寻找让整条分支、辅助函数、模式、条件或层级彻底消失的重构机会。
  • 不允许 PR 在没有充分理由的情况下把文件从 1k 行以下推到 1k 行以上,默认视为强烈的代码质量异味,优先抽取辅助函数、子组件、模块或局部抽象。
  • 不允许现有代码中出现随机的意大利面式增长,对新插入到无关流程中的临时条件、零散特例或一次性分支保持高度怀疑,将其视为设计问题而非风格小问题。
  • 倾向于清理设计而非接受“能跑就行”的实现,优先选择能彻底移除活动部件的简化,而非把同样的复杂度四处扩散的重构。
  • 偏好直接、朴素、可维护的代码,把脆弱、临时或“魔法”行为视为代码质量问题,警惕隐藏简单数据形状假设的通用机制,标记只增加间接层而不带来清晰度的薄抽象、身份包装或直通辅助函数。
  • 在影响可维护性时,强力推动类型与边界清晰化,质疑不必要的可选性、unknown、any 或大量类型转换,偏好显式类型模型或共享契约。
  • 让逻辑留在规范层级并复用现有辅助函数,标记特性逻辑泄漏到共享路径或实现细节通过 API 泄漏,优先使用现有规范工具而非定制一次性实现。
  • 将不必要的串行编排和非原子更新视为设计异味,若独立工作被无理由串行化,应询问是否应并行执行;若相关更新可能留下半应用状态,应推动更原子的结构。

使用方式

该技能以提示词形式在 Cursor 中运行,针对当前分支的改动执行审查。它提供了一组主要审查问题,例如:是否存在让实现显著更简单的“代码柔道”动作?能否重新表述改动以减少所需概念、分支或辅助层?改动是改善还是恶化了局部架构?是否在应有更好抽象的地方增加了分支复杂度?原本内聚的模块是否变得更耦合、更有状态或更难扫读?逻辑是否位于正确的文件与层级?是否让文件或组件超出健康的大小边界?是否存在重复条件暗示缺失的模型或辅助函数?实现是否直接可读,还是依赖特例与偶然控制流?抽象是否真正物有所值,还是只是包装?是否引入了类型转换、可选性或临时对象形状掩盖了真正的不变量?逻辑是否位于规范层级,还是细节跨越了边界?编排是否比需要的更串行或更不原子?

技能还列出了应积极标记的情况,例如:复杂实现本可通过更清晰的重构删除整类复杂度;重构只是搬动代码而未减少读者需要记住的概念数量;PR 导致文件跨过 1000 行;新条件被硬塞进无关代码路径;一次性布尔值、可空模式或标志使现有控制流复杂化;特性特定逻辑泄漏到通用模块;通用“魔法”处理隐藏简单结构;薄包装或身份抽象只增加间接层;不必要的类型转换、any、unknown 或可选参数模糊真实契约;复制粘贴逻辑而非抽取辅助函数;在已经繁忙的函数中间实现狭窄边界情况处理;技术上通过测试但降低模块化或可读性的重构;可能变成永久债务的“临时”分支;在代码库已有规范工具时另起炉灶;逻辑加在错误层级或包;明显独立的工作被串行异步执行;部分更新逻辑使状态不够原子。

适用场景

该技能适用于对代码质量要求极高的代码审查,尤其是当改动可能引入结构性回归、错过显著简化机会、增加意大利面式分支复杂度、破坏边界或抽象、导致文件膨胀、损害模块化或可读性时。它强调优先处理结构性代码质量回归、错过的显著简化或代码柔道重构机会、意大利面式或分支复杂度增加、边界或抽象或类型契约问题、文件大小与分解问题、模块化与抽象问题、可读性与可维护性问题,并建议在存在更大结构性问题时不要用低价值细节淹没审查,宁可给出少量高确信度意见。

限制

该技能设定了明确的批准门槛:不能仅因行为看似正确就批准。批准条件包括:没有明显的结构回归;在可见路径存在时没有明显错过让实现显著更简单的机会;没有不合理的文件大小爆炸;没有因特例分支导致的明显意大利面式增长;没有明显 hacky 或魔法抽象让代码更难理解;没有不必要的包装、类型转换或可选性变动掩盖真实设计;没有明显的架构边界泄漏或可避免的规范辅助函数重复;没有明显错过的能实质提升可维护性的分解机会。技能将这些视为推定阻塞项,除非作者能清晰论证。

该技能还规定了审查语气:直接、严肃、对质量要求严格,不粗鲁,但也不把重大可维护性问题软化成温和建议。如果代码让代码库更乱,就明确说出来;如果实现错过了显著简化机会,也要明确说出来。技能给出了若干推荐措辞示例,并强调不要满足于“也许改个名”这类反馈,也不要满足于只是把同样混乱的想法清理得稍微干净一点,如果存在通往更简单想法的可行路径。

关于该技能的具体安装方式、平台支持范围、收费模式或价格信息,资料中暂未提供。