在代码审查中做极严格的可维护性审计：消除复杂分支…

对当前分支的改动进行深度代码质量审计，主动寻找能大幅简化结构、删除复杂度而非重排复杂度的重构机会。

适用场景

解决思路

1. 以基线提示开始：对当前分支的改动做深度代码质量审计，在不影响行为的前提下重新思考如何结构化/实现这些改动以实质提升代码质量，改进抽象、模块化，减少意大利面代码，提升简洁性与可读性；要有野心，若有明确路径改进实现且涉及重构部分代码库就去做；极度彻底严谨，量两次切一次。
2. 对结构性简化保持野心：不要止步于『这里可以更干净一点』；寻找能重新框定改动、让整条分支、辅助函数、模式、条件或层级彻底消失的机会；优先选择事后看来让代码显得必然的方案；假设通常存在一个『代码柔道』动作——更有效利用现有架构、让改动戏剧性更简单优雅的重组；若看到删除复杂度而非重排复杂度的路径，强力推动该路径。
3. 不要让 PR 把文件从 1k 行以下推到 1k 行以上，除非有非常强的理由：默认视为强烈的代码质量坏味道；优先提取辅助函数、子组件、模块或局部抽象，而不是让文件膨胀超过 1000 行；若 diff 跨过该阈值，明确询问是否应先分解代码；只有当存在令人信服的结构性理由且结果文件仍组织清晰时才可豁免。
4. 不允许现有代码中出现随意的意大利面式增长：高度怀疑插入到无关流程中的新临时条件、零散特例或一次性分支；若改动在随机位置添加『奇怪的 if 语句』，视为设计问题而非风格小问题；优先把逻辑推入专用抽象、辅助函数、状态机、策略对象或独立模块，而不是纠缠现有路径；即使技术上能工作，也要指出让周围代码更难推理的改动。
5. 倾向于清理设计，而不仅仅是接受能工作的代码：若行为可保持不变而结构能实质变干净，推动更干净的版本；不要给留下更混乱代码库的『能工作』实现盖章；强烈偏好能彻底移除活动部件的简化，而非只是把同样复杂度四处扩散的重构。
6. 偏好直接、无聊、可维护的代码，而非 hacky 或魔法代码：把脆弱、临时或『魔法』行为视为代码质量问题；对隐藏简单数据形状假设的通用机制保持怀疑；标记那些增加间接性却不带来清晰度的薄抽象、身份包装或直通辅助函数。
7. 当类型与边界清洁度影响可维护性时强力推动：当可以存在更清晰的类型边界时，质疑不必要的可选性、unknown、any 或大量 cast 的代码；偏好显式类型模型或共享契约，而非松散形状的临时对象；若某分支依赖静默回退来掩盖不清晰的不变量，询问是否应把边界显式化。
8. 把逻辑保留在规范层并复用现有辅助函数：指出泄漏到共享路径的功能逻辑或通过 API 泄漏的实现细节；优先使用现有规范工具/辅助函数而非定制一次性实现；把代码推向正确的包、服务或模块，而不是让架构漂移正常化。
9. 当更清晰的结构显而易见时，把不必要的顺序编排和非原子更新视为设计坏味道：若独立工作无充分理由被串行化，询问是否应改为并行；若相关更新可能留下半应用状态，推动更原子的结构；不要过度关注微优化，但要标记让实现更脆弱的可避免编排复杂度。
10. 对每个有意义的改动追问：是否存在让代码戏剧性更简单的『代码柔道』动作？能否重新框定改动以减少所需概念、分支或辅助层？这改进了还是恶化了局部架构？diff 是否在应有更好抽象处增加了分支复杂度？原本内聚的模块是否变得更耦合、更有状态或更难扫读？逻辑是否在正确的文件和层？改动是否让文件或组件超出健康大小边界？是否有重复条件暗示缺失模型或辅助函数？实现是直接可读还是依赖特例与偶然控制流？抽象是否真正物有所值还是只是包装？diff 是否引入 cast、可选性或临时对象形状掩盖真实不变量？逻辑是否在规范层，还是 diff 跨边界泄漏细节？编排是否比需要的更顺序或更不原子？
11. 在以下情况升级发现：复杂实现本可通过更清晰的重新框定删除整类复杂度；重构只是搬动代码却未减少读者需在脑中保持的概念数量；PR 导致文件跨过 1000 行，尤其新代码本可拆分；新条件被硬塞到无关代码路径；一次性布尔、可空模式或标志使现有控制流复杂化；功能特定逻辑泄漏到通用模块；通用『魔法』处理隐藏简单结构使代码更难推理；薄包装或身份抽象增加间接性却不简化任何东西；不必要的 cast、any、unknown 或可选参数模糊真实契约；复制粘贴逻辑而非提取辅助函数；在已繁忙函数中间实现狭窄边界情况处理；技术上通过测试却让代码更不模块化或更不可读的重构；可能变成永久债务的『临时』分支；代码库已有规范工具却用定制辅助函数；逻辑加在错误层/包而应住在更中心处；顺序异步流中明显独立的工作本可并行更简单清晰；部分更新逻辑让状态比必要更不原子。
12. 识别到代码质量问题时优先建议：删除整层间接而非打磨它；重新框定状态模型让条件消失而非被集中；改变所有权边界让功能成为现有抽象的自然延伸；把特例逻辑变成更简单、异常更少的默认流；提取辅助函数或纯函数；把大文件拆成更小专注模块；把功能特定逻辑移到专用抽象后；用类型模型或显式分发器替换条件链；分离编排与业务逻辑；把重复分支合并为单一更清晰流程；删除不能实质澄清 API 的包装；复用现有规范辅助函数而非引入近似重复；让类型边界更显式从而简化控制流；把逻辑移到已拥有该概念的包/模块/层；当并行也能简化编排时并行化独立工作；当部分状态更难推理时把相关更新重构为更原子流程。
13. 不要满足于『也许重命名这个』的反馈，当真正问题是结构性时；不要满足于同一混乱想法的更干净版本，若存在通往更简单想法的可行路径。
14. 审查语气直接、严肃、对质量要求高：不要粗鲁，但不要把重大可维护性问题软化成温和建议；若代码让代码库更混乱，清楚说出；若实现错过了戏剧性简化的机会，也清楚说出。
15. 使用以下推荐措辞：`this pushes the file past 1k lines. can we decompose this first?`；`this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`；`this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`；`this feels like feature logic leaking into a shared path. can we isolate it?`；`this abstraction seems unnecessary. can we just keep the direct flow?`；`why does this need a cast / optional here? can we make the boundary more explicit instead?`；`this looks like a bespoke helper for something we already have elsewhere. can we reuse the canonical one?`；`i think there's a code-judo move here that makes this much simpler. can we reframe this so these branches disappear?`；`this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?`
16. 按以下顺序优先排列发现：1) 结构性代码质量回退；2) 错过的戏剧性简化/代码柔道重构机会；3) 意大利面/分支复杂度增加；4) 让代码更难推理的边界/抽象/类型契约问题；5) 文件大小与分解问题；6) 模块化与抽象问题；7) 可读性与可维护性问题。
17. 若存在更大结构性问题，不要用低价值小问题淹没审查；偏好少量高确信度评论而非一长串表面笔记。
18. 不要仅因行为看似正确就批准。批准门槛是：无明确结构性回退；当可见路径存在时无明显错过的让实现戏剧性更简单的机会；无无理由的文件大小爆炸；无特例分支导致的明显意大利面增长；无让代码更难推理的明显 hacky 或魔法抽象；无不必要的包装/cast/可选性变动掩盖真实设计；无明确的架构边界泄漏或可避免的规范辅助函数重复；无错过的会实质提升可维护性的明显分解机会。
19. 把以下视为推定阻塞项，除非作者能清楚证明：PR 在存在可行代码柔道动作可删除时保留大量附带复杂度；PR 把文件从 1000 行以下推到 1000 行以上；PR 添加临时分支让现有流程更纠缠；PR 通过在共享代码中散布功能检查解决局部问题；PR 添加不必要的抽象、包装或大量 cast 的契约让设计更间接；PR 重复现有辅助函数或把逻辑放在错误层而存在明确规范归属。
20. 若这些条件未满足，留下明确、可操作的反馈并推动更干净的分解。

适用边界 · 注意事项

• 仅需快速风格检查或表面 lint 时，不适用此极严格结构性审查
• 改动很小且不涉及结构、抽象或分支复杂度时，不必套用此重审查
• 当代码库明确接受临时债务且无可行简化路径时，强行推动重构可能不划算