yzr-coding-review

yzr-coding-review

把代码 review 约束成发现可追溯、结论可执行的产物

输入与输出

输入（任一形态）：代码段 / 文件路径 / git diff / patch（两者都只 review 改动）/ 项目根目录 + 范围

输出：两种形态（对话式分析回答 / 报告形态）+ 逐条过子循环，路由见章节

执行原则

1. 不主动改文件：产出是结论 / 报告，用户点头后才走具体重构
2. 每条发现可追溯：每条发现映射到至少 1 个 catalog 规则名
3. 审视边界收敛：catalog 收录的设计层问题照常报；bug 修复 / profile / benchmark / 安全审计等

执行类工作不展开（指出"建议另行专项处理"）；机械可判定项（风格规则 / 格式 / TODO / docstring 缺失）归 CI，不占发现项

1. 产物留在对话内：报告 / 结论不落成文件，不主动持久化（落文件即成无人维护的第二真源）；

多模型管线的中间产物（物化快照、扫描候选落盘）不受本条约束，落盘口径见多模型编排

评审立场

立场四条单源在章节，默认路径与多模型评审员以该节为准

工作流

Step 1: 收集代码

解析输入，确定语言 + 行数；行数 > 500 时与用户确认分段粒度（按文件 / 按类 / 按函数，未指定则按文件结构），发现按该粒度分批呈现

Step 2: 走 catalog 补充

必读 规则清单；agent 用其中的重构规则 + 合理性审视规则补齐设计层问题。 数值阈值项（函数长度 / 嵌套层数 / 参数个数等）先现场 grep / AST 速算拿客观计数，再对照规则内的阈值判断， 不凭目测；重复块检测跑 tools/dup_scan.py（精确 / --fuzzy 近似两模式）拿候选组，报不报由 agent 按规则裁。 用户显式要求多模型 / 交叉评审时本步的发现生产整体改走多模型编排的 subagent 逐票， 编排者不再自产发现

Step 3: 形态路由

默认进 对话式分析回答（见章节）；用户明确要报告或大范围体检（多文件 / 遗留代码）时进 报告形态（见章节）；形态可中途切换

Step 4: 对话式分析回答（默认）

1. 理解复述：按章节向用户复述这段代码，拿不准处显式说"这里我理解为 X，若不对请纠正"。为什么：理解偏了，后面所有发现都是空转；用户纠正理解时，基于纠正后的理解重审再列发现
2. 结论先行：一句话给出"有没有优化空间"（没有就说明理由，收尾）
3. 列要点：按代码位置顺序（file:line）；发现 ≤ 3 条直接给全（位置 + 规则名 + 问题 + 建议）；

超过 3 条给全量简表（每条一行）

1. 收尾问询：超过 3 条时问"逐条过一遍还是出一份报告"，≤ 3 条时问是否进入具体重构；逐条过按

代码位置顺序逐条呈现，每条等用户表态：

• 确认记为"接受"
• 改判按用户意见修正内容
• 跳过记为"跳过"
• 追问展开讲清该条后再回到该条表态

确认 / 改判 / 跳过处理完即进下一条

1. 逐条过完全部后输出汇总（接受 / 改判 / 跳过 计数 + 采纳清单），询问是否出报告或进入具体重构

Step 5: 报告形态

开头先给一段理解复述（口径见章节，不超过一段），再按 报告模板 两档输出；末尾问用户要不要追问 / 跳过 / 改判，或切回对话式分析回答逐条过