pstack的thermo-nuclear-code-quality-review：终极可维护性审计详解
【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude
pstack是面向 Claude Code、Codex、Pi 等 AI 编码智能体的技能栈，而其中的thermo-nuclear-code-quality-review（热核代码质量审查）是一个"极致严格"的代码可维护性审计工具：它会以近乎苛刻的标准审查你当前分支的改动，专治巨型文件、面条式条件分支和腐化的抽象层，并推动 Agent 主动做"代码柔道"式的结构重构，而不是只挑几处小毛病就交差。
它是什么：一次"不留情面"的代码质量审计
普通 code review 技能大多满足于"功能对不对"，而 thermo-nuclear-code-quality-review 的定位完全不同——它的官方描述是：Run an extremely strict maintainability review（运行一次极其严格的可维护性审查），聚焦三件事：
- 抽象质量：这层封装真的值得存在吗，还是只是套娃？
- 巨型文件：一个 PR 有没有让文件突破 1000 行红线？
- 面条式增长：新的 if 分支是不是被随手插进了不相干的流程？
它的核心指令要求审查者"大胆"（ambitious）：不只是找局部清理点，而是主动寻找能让实现大幅变简单、变小、更直接的重构路径。完整规则定义在 plugins/pstack/skills/thermo-nuclear-code-quality-review/SKILL.md。
如何触发：一条斜杠命令启动热核审查
安装 pstack 插件后，直接输入/thermo-nuclear-code-quality-review即可调用，官方文档将其登记为"extremely strict maintainability audit"（见 docs/reference.md 的斜杠命令表）。也可以用自然语言触发，比如"对这个分支做一次深度代码质量审计"或"来一次最严厉的可维护性审查"。
它的审查基线可以概括为一句话：
对当前分支的改动做一次深度代码质量审计。在不改变行为的前提下，重新思考如何组织与实现这些改动，大胆重构，把抽象、模块化和可读性提上去。三思而后行（Measure twice, cut once）。
七大铁律：审计时不可妥协的审查标准
技能文件中列出了 7 条"不可协商"的硬性标准，这是理解该技能的关键 👇
| # | 铁律 | 一句话解释 |
|---|---|---|
| 0 | 结构简化要大胆 | 别停在"这里可以稍微干净点"，要寻找让整个分支、辅助函数、模式彻底消失的"代码柔道"解法 |
| 1 | 1000 行红线 | PR 不应把文件从 1000 行以下推到以上，除非有极强的结构性理由，否则必须先拆分 |
| 2 | 禁止面条式蔓延 | 往无关流程里插临时 if、散落特例，是设计问题而非风格问题 |
| 3 | 设计优先于"能跑就行" | 行为不变但结构更干净时，坚决推动更干净的版本 |
| 4 | 直白优于魔法 | 警惕隐藏简单数据形状假设的通用"魔法"机制和薄封装 |
| 5 | 类型与边界要干净 | 质疑不必要的any、unknown、可选参数和类型断言 |
| 6 | 逻辑放在规范层 | 复用现有工具函数，反对重复造轮子和架构漂移 |
第 7 条则关注编排质量：无意义的串行化、可能留下半更新状态的非原子操作，都是设计坏味道。
审查者会问你的 13 个问题
对每一处有意义的改动，审查者都会过一遍这套问题清单，其中几个最"扎心"的：
- 是否存在一个"代码柔道"动作，能让实现变得简单得多？
- 这次改动是改善了还是恶化了局部架构？
- 一个此前内聚的模块，是否变得更耦合、更有状态、更难扫读？
- 重复出现的条件分支，是不是暗示缺失了一个模型？
- 这个抽象真的在创造价值，还是只是一个 wrapper？
会被"重点打击"的 15 类坏味道
技能文件明确列出了要"激进上报"的问题，包括：文件因 PR 突破 1000 行、特例分支被焊死在不相关代码路径上、功能逻辑泄漏进通用模块、复制粘贴而非抽取、"临时"分支（大概率变成永久债务）、以及"通过测试但让代码更不模块化"的重构等。
与之配套，它还规定了一组优先修复方向：删除整层间接性（而不是打磨它）、重设状态模型让条件分支消失、把特例逻辑变成更少例外的默认流程、用类型化模型或显式分发器替换条件链、把独立工作并行化、把相关更新重构成更原子的流程。原文强调：不要满足于"也许可以改个名"这种反馈，当真正的问题在结构层面时。
审计输出：一份分层报告，而不是一锅乱炖
审查的可交付物有严格格式 👇
- 一个独立目录（例如
/tmp/<project>-thermo/），内含一份总结报告+ 每个子系统的详细报告（01_<subsystem>.md、02_<subsystem>.md……） - 总结报告控制在约 200 行内，一眼读完：结论、每条发现的简短叙述、修复顺序建议、指向详细报告的链接
- 详细文件承载深度：测量数据、产生数据的命令、验证状态、可操作的代码柔道提案
- 发现项用散文段落书写——点名文件和证据，用句子解释问题与解法，禁止碎片行和标签堆砌
发现项按优先级排序：结构性回归 > 错失的大幅简化机会 > 分支复杂度增长 > 边界/抽象/类型契约问题 > 文件体积 > 模块化 > 可读性。原则是：少量高置信度的意见，好过长篇大论的表面小疵。
审批门槛：不通过"它似乎能跑"就批准
这是该技能最"狠"的地方。它明确拒绝仅因"行为似乎正确"就批准，并列出若干推定阻断项（presumptive blockers）：
- ❌ 文件从 1000 行以下被推到以上
- ❌ 在已有流程中加入临时分支，使其更纠缠
- ❌ 添加不必要的抽象、wrapper 或类型断言密集契约
- ❌ 在已有规范工具函数存在时重复造轮子
- ❌ 存在可行"代码柔道"路径却保留了大量偶然复杂度
作者若不能清晰论证，就必须接受"推动更干净的拆分"这一结论。
组合技：与 swarm 并行审查的威力
thermo-nuclear 审查不是孤岛。当它借助 pstack 的swarm技能（plugins/pstack/skills/swarm/SKILL.md）扇出并行审查者时，技能文件特别规定：各审查者的独立报告就是交付物的详细文件，而非可丢弃的原始输出——判断汇总进总结，细节保留在磁盘上并互相链接。
它与 pstack 的其他审查类技能形成互补：
- interrogate：多模型对抗式审查，靠模型多样性找盲点，偏"挑错"
- thermo-nuclear-code-quality-review：单视角但极严，偏"可维护性与结构健康"
- deslop：提交前给 diff 做一轮"去噪清理"
一键安装：在你的智能体里启用热核审查
在 Claude Code 中执行两条命令即可安装 pstack 插件（含本技能）：
/plugin marketplace add michael-denyer/pstack-claude /plugin install pstack@pstack-claudeCodex 和 Pi 用户则分别运行codex plugin marketplace add/pi install对应命令，详见 README.md 的 Install 章节。需要说明的是，该技能源自 Cursor 的 cursor-team-kit（见 NOTICE-skills.md），pstack 项目将其移植为跨运行时可用的技能，规则本身保持原样。
写在最后：为什么需要这么"狠"的审查
AI 编码智能体写代码的速度越快，代码腐化的速度也越快——临时分支、膨胀的文件、层层套娃的抽象，正是"临时方案永久化"的高发区。thermo-nuclear-code-quality-review 的价值在于：它把资深工程师才会坚持的"结构洁癖"固化成了可重复执行的流程，让 Agent 在合并前主动回答一个问题——这次改动是让代码库变干净了，还是变脏了？🚀
【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
