代码质量评审

来源

这是中文译文，方便对照阅读。本站不发行中文版插件。英文原文 pstack/skills/interrogate/references/code-quality-review.md，取自 pstack 官方仓库 cursor/plugins 的提交 12d587d。

本站英文页

代码质量评审

每名评审者在评审标准之外还应用此代码质量视角。这是严格标准，聚焦实现质量、可维护性、抽象质量与代码库健康。

首要原则：对代码结构要有追求。不要只找局部清理。主动寻找「代码柔道」式重构——在保持行为不变的前提下，让实现显著更简单、更小、更直接、更优雅。

核心 Prompt

从此基线开始：

对当前分支变更做深度代码质量审计。 重新思考如何组织/实现变更，在不影响行为的前提下有意义地提升代码质量。 改进抽象与模块化，减少意大利面代码，提升简洁与可读性。 若有清晰路径改进实现且涉及重组部分代码库，要敢于去做。 极其全面、严谨。量两次，切一次。

维度

每个维度只陈述一次。应用与你相关的那些。

0. 对结构简化要有追求。 不要停在「可以稍微干净点」。寻找能整段消掉分支、辅助函数、模式、条件或层的重构角度。假设「代码柔道」式改动常存在——更有效利用现有架构，让变更显著更简单。若能删除复杂度而非 仅仅重排，要用力推。

1. 若无充分理由，不要让 PR 把文件从一千行以下推到一千行以上。 视为强异味。优先抽取辅助函数、子组件或模块。若 diff 跨该阈值，先问是否应分解。仅在有充分结构理由且结果文件仍清晰有条理时豁免。

2. 不要允许既有代码里意大利面式增长。 警惕新的临时条件、散落特例、插入无关流程的一次性分支。「随机地方的奇怪 if」是设计问题，不是风格小问题。优先把逻辑推进专用辅助函数、状态机或模块，而非缠住现有路径。

3. 偏向清理设计，而非只接受能跑的代码。 行为可不变而结构明显更干净时，推更干净版本。优先减少活动部件的简化，而非把同样复杂度摊到更多地方。

4. 优先直接、平淡、可维护的代码，而非取巧或魔法式写法。 将脆弱、临时或「魔法」行为视为问题。警惕通用机制掩盖简单的数据形状假设。标记薄抽象、身份包装、透传辅助函数等增加间接却不增清晰度的写法。

5. 当类型与边界整洁度影响可维护性时要追问。 质疑不必要的可选性、unknown、any 或大量类型转换——若可建立更清晰的类型边界。优先显式类型模型，而非松散临时对象。分支靠静默回退掩盖不清不变式时，问是否应把边界写明确。

6. 逻辑放在规范层，复用现有辅助函数。 指出功能逻辑漏进共享路径，或实现细节漏过 API。优先现有规范工具，而非一次性定制实现。把代码推向对的包、服务或模块，而非把漂移正常化。

7. 当更干净结构显而易见时，不必要的顺序编排与非原子更新是设计异味。 独立工作无理由串行时，问是否应并行。相关更新可能留下半应用状态时，推更原子结构。不要过度纠结微优化，但要标记可避免、却让代码更脆的编排复杂度。

输出期望

优先结构层面的质量回退与错过的简化，然后意大利面式与分支复杂度，然后边界、类型、文件规模，再是较小的模块化与可读性问题。

批准门槛

不要仅因行为看起来正确就批准。以下视为默认阻塞项，除非作者能充分说明：PR 保留大量附带复杂度而一次「代码柔道」式改动本可删掉；把文件从一千行以下推到以上；加临时分支缠住现有流程；在共享代码里散落功能检查；增加不必要的抽象、包装或大量转换的契约，或重复现有辅助函数、把逻辑放错层——当已有清晰规范归属时。条件不满足则给出明确可执行的反馈，推动更干净的分解。

评审语气

直接、严肃、对质量要求高。不要粗鲁，但不要把重大可维护性问题软化成轻微建议。代码让代码库更乱就说。实现错过明显的大幅简化也说。不要满足于「也许改个名」而实质问题是结构性的。