技能介绍

问题从哪来

重构和「顺手改逻辑」混在一起时，PR 差异被格式化噪音淹没，意外行为变更又常成为回归主因。AI 生成代码在可读性、跨文件模式一致性和安全面上还有额外风险：Veracode 2025 等数据表明，其漏洞密度往往高于人工代码，且不少问题来自组件交互而非单行危险写法。你需要的是只动结构、不动语义的清理，以及能落到证据上的审查，而不是泛泛的「代码建议」。

技能如何工作

禅（Zen）把任务分成两种模式：重构会提交行为保留的代码变更并附重构报告；审阅只输出审查报告，不改代码。工作流强调按阶段执行、为每条建议写明依据，并用认知复杂度（而不仅是圈复杂度）衡量可读性——例如单函数认知复杂度 > 20 会触发质量门（SonarQube 常见阈值）。

子命令与配方覆盖典型场景：naming 纯重命名、extract/split 拆长函数、constants 提取魔法数、dead 删死代码、simplify/guard 压缩冗余分支与嵌套 if，默认 refactor 做复合异味治理。自然语言也会按关键词路由到对应配方。每次重构默认遵守范围层：例如「专注」级通常限制在 1～3 个文件，一次只应用一项有意义、可验证的改动；重构前后跑相关测试，覆盖率不低于基线。

审阅侧会扫描代码异味、跨文件一致性，并对 AI 生成代码关注架构漂移、重复逻辑、边界缺口，以及错误信息泄露、N+1、字符串拼接 SQL 等具体形状。与 Judge（缺陷/安全）、Radar（新测与覆盖）、Atlas（架构拆分）、Builder（功能实现）等有明确分工，避免越界。

边界与注意点

先问再动：公共 API/导出符号重命名、大规模目录重组、可能反射调用的删除、无规范阈值的一致性大迁移等。从来没有：改逻辑或行为、把新功能和重构混在同一 PR、覆盖项目 formatter/linter、在不理解耦合的情况下做「霰弹枪式」多文件修改。文件级未使用资源应交给 Sweep；Diff 过大（如 >400 LOC）时审查缺陷检出率会明显下降，宜先拆分再审。

截图预览

使用场景

PR 合并前对中等规模 diff 做只读审阅，检查命名、嵌套深度与跨文件模式是否一致，输出带证据的审查报告而不改代码。
AI 生成认证、会话或状态机相关实现后，按审阅模式扫描架构漂移、边界缺口及错误回显、N+1、拼接 SQL 等交互型风险。
单函数认知复杂度超过 20 或方法过长时，在专注范围（约 1～3 文件）内做一次 `extract`、`split` 或 `guard`，跑通现有测试确认通过/失败签名不变。
准备提交独立重构 PR：先用 `dead`、`naming`、`constants` 清理未使用私有代码与魔法数，与功能改动分 commit，避免 reviewer 被无关 diff 干扰。