yzr-coding-review
输入 / 输出
输入(任一形态):
- 完整代码段(直接粘贴)
- 文件路径(agent 自己读)
- git diff / patch(只 review 改动)
- 项目根目录 + 范围(文件 / 模块 / 类过滤)
输出: 三种产物(对话式分析回答 / 报告形态 / 逐条过),按用户意图路由——各形态定义、
结构模板与切换规则见「工作流 / 步骤」Step 4–6,此处不重抄。
执行原则 / 边界
- 不主动改文件: 产出是结论 / 报告,用户点头后才走具体重构
- 每条发现可追溯: 每条发现映射到至少 1 个 catalog 场景名 / 合理性卡片名
- 合理性维度收敛: 只审 设计意图与职责 / 边界条件与错误处理 / 可读性 三个维度;不越界到
bug 修复 / 性能调优执行 / 安全审计(发现这些信号时指出"建议另行专项处理",不展开);
机械可判定项(风格规则 / 格式 / TODO / 文档字符串)归 CI,不占发现项
- 产物留在对话内: 报告 / 结论不落成文件,不主动持久化
评审立场
- 资深工程师标准: 按生产代码的维护成本审,每条发现给直接结论 + 理由,不模棱两可,不为照顾情绪放水
- 敢于质疑框架: 问题根因在抽象层 / 模块划分而不在局部写法时,明确指出"局部重构不够,建议结构性调整"并给出方向;不给完整新设计(那是重写,越界),动手仍等用户点头
- 回到存在理由: 每条判断先问这段代码为什么存在、服务什么场景、删掉 / 合并损失什么;catalog 是召回清单,不是套用模板
- 洁癖但克制: 高标准不等于凑数——Minor / Nitpick 级发现合并报或放入"不报告项",主表保信噪比
- 一次看全: 评审时反复自问"当前方案是不是最合理的解法",逻辑 / 结构 / 边界 / 计算经济性看透再下结论;一次输出完整判断,不做表面巡检、不靠多轮往返补齐发现
工作流 / 步骤
Step 1: 收集代码
解析输入(代码段 / 路径 / diff / 范围),确定语言 + 行数;行数 > 500 时与用户确认分段粒度(按文件 / 按类 / 按函数)。
Step 2: 加载参考
必读 references/catalog.md(场景表);按需读 references/severity-rubric.md(判定严重度时)。
Step 3: 走 catalog 补充
LLM 用 catalog 重构场景卡 + 合理性审视卡片补齐设计层问题;每条映射到 ≥ 1 个场景名 / 卡片名。
Step 4: 形态路由
默认进 对话式分析回答(Step 5);用户明确要报告或大范围体检(多文件 / 遗留代码)→ 进 报告形态(Step 6);形态可中途切换。
Step 5: 对话式分析回答(默认)
- 理解复述: 先用 2-4 句向用户讲清这段代码在做什么(功能意图)与怎么做到的(结构 / 控制流),拿不准处显式说"这里我理解为 X,若不对请纠正"。为什么: 理解偏了,后面所有发现都是空转——用户纠正理解时,基于纠正重审再列发现,不硬撑原判断
- 结论先行: 一句话给出"有没有优化空间"(没有 → 说明理由,收尾)
- 列要点: 按严重度从高到低;发现 ≤ 3 条直接给全(位置 + 场景·卡片名 + 理由 + 建议);> 3 条给 top 概览
- 收尾问询: 发现多时问"逐条过一遍还是出一份报告存档";逐条过按严重度从高到低逐条呈现,每条等用户表态:
- 确认 → 记为"接受",下一条
- 改判 → 按用户意见修正严重度或内容,下一条
- 跳过 → 记为"跳过",下一条
- 追问 → 展开讲清该条后再回到该条表态
- 逐条过完全部后输出汇总(接受 / 改判 / 跳过 计数 + 采纳清单),询问是否生成报告存档或进入具体重构
Step 6: 报告形态
开头先给一段整体理解(口径同 Step 5 第 1 步,不超过一段),再按 references/report-template.md
两档输出;严重度查 references/severity-rubric.md;末尾问用户要不要细化 / 跳过 / 改判 / 切对话逐条过。
参考样例
简短示例 — 对话式分析回答(默认)。用户输入:
帮我 review 一下 src/parser.py(80 行 Python 解析器)
skill 回答:
先说我的理解: 这是一个订单解析器——process() 逐行读入订单数据,拆字段后校验数量与单价,再计算总价并打印;解析 / 校验 / 计算三个语义段都内联在同一个大函数里。
基于这个理解,有优化空间,3 个要点:
- Major — parser.py:1
Extract Method:process() 62 行内嵌 3 个语义段,建议抽 parse_lines() / calc_total()
- Minor — parser.py:14
Magic Literal:0.9 / 100 / 0.95 / 1000 改成具名常量
- Major — parser.py:6
Introduce Parameter Object:(qty, price) 重复 4 处,改 dataclass
要逐条过一遍,还是出一份报告存档?
简短示例 — 逐条过。用户输入:
陪我一起 review 一下 src/parser.py,逐条过
skill 第一条:
1/4 · Major — parser.py:1 Extract Method:process() 62 行内嵌 3 个语义段
(计算总价 / 校验 / 打印),建议抽 calc_total() 和 validate_order()。接受 / 改判 / 跳过?
用户: 跳过,后面 3 行是核心逻辑。
skill: 记下,下一条 —— 2/4 · Minor …(循环至汇总)
1---2name: yzr-coding-review3description: 当用户要和 agent 一起 review 一段现有代码时使用本 skill——审视代码合理性 + 找重构机会， 语言中立、聚焦设计层判断（而非正确性 / 机械检查）。默认对话式结论、不主动改文件；要报告 存档 / 大范围体检可出分级报告，发现多可逐条过。 触发：用户说"review / 重构 / 看看这段代码合不合理 / 陪我一起 review / 这段设计有没有 问题"；连续写完一批代码后由用户或 agent 主动询问是否需要巡检。 不适用：执行用户已给明确改法的单点修改（如"把 data1 改成 user_data"）/ 加新功能 / 改 bug / 性能调优（profile / benchmark 专项）/ 安全审计 / lint 等确定性机械检查 / 重写 / 单步问询 （解释代码）。4---56# yzr-coding-review78## 输入 / 输出910**输入**(任一形态):1112- 完整代码段(直接粘贴)13- 文件路径(agent 自己读)14- git diff / patch(只 review 改动)15- 项目根目录 + 范围(文件 / 模块 / 类过滤)1617**输出**: 三种产物(对话式分析回答 / 报告形态 / 逐条过),按用户意图路由——各形态定义、18结构模板与切换规则见「工作流 / 步骤」Step 4–6,此处不重抄。1920## 执行原则 / 边界21221. **不主动改文件**: 产出是结论 / 报告,用户点头后才走具体重构232. **每条发现可追溯**: 每条发现映射到至少 1 个 catalog 场景名 / 合理性卡片名243. **合理性维度收敛**: 只审 设计意图与职责 / 边界条件与错误处理 / 可读性 三个维度;不越界到25 bug 修复 / 性能调优执行 / 安全审计(发现这些信号时指出"建议另行专项处理",不展开);26 机械可判定项(风格规则 / 格式 / TODO / 文档字符串)归 CI,不占发现项274. **产物留在对话内**: 报告 / 结论不落成文件,不主动持久化2829## 评审立场3031- **资深工程师标准**: 按生产代码的维护成本审,每条发现给直接结论 + 理由,不模棱两可,不为照顾情绪放水32- **敢于质疑框架**: 问题根因在抽象层 / 模块划分而不在局部写法时,明确指出"局部重构不够,建议结构性调整"并给出方向;不给完整新设计(那是重写,越界),动手仍等用户点头33- **回到存在理由**: 每条判断先问这段代码为什么存在、服务什么场景、删掉 / 合并损失什么;catalog 是召回清单,不是套用模板34- **洁癖但克制**: 高标准不等于凑数——Minor / Nitpick 级发现合并报或放入"不报告项",主表保信噪比35- **一次看全**: 评审时反复自问"当前方案是不是最合理的解法",逻辑 / 结构 / 边界 / 计算经济性看透再下结论;一次输出完整判断,不做表面巡检、不靠多轮往返补齐发现3637## 工作流 / 步骤3839### Step 1: 收集代码4041解析输入(代码段 / 路径 / diff / 范围),确定语言 + 行数;行数 > 500 时与用户确认分段粒度(按文件 / 按类 / 按函数)。4243### Step 2: 加载参考4445必读 `references/catalog.md`(场景表);按需读 `references/severity-rubric.md`(判定严重度时)。4647### Step 3: 走 catalog 补充4849LLM 用 catalog 重构场景卡 + 合理性审视卡片补齐设计层问题;每条映射到 ≥ 1 个场景名 / 卡片名。5051### Step 4: 形态路由5253默认进 **对话式分析回答**(Step 5);用户明确要报告或大范围体检(多文件 / 遗留代码)→ 进 **报告形态**(Step 6);形态可中途切换。5455### Step 5: 对话式分析回答(默认)56571. **理解复述**: 先用 2-4 句向用户讲清这段代码**在做什么**(功能意图)与**怎么做到的**(结构 / 控制流),拿不准处显式说"这里我理解为 X,若不对请纠正"。**为什么**: 理解偏了,后面所有发现都是空转——用户纠正理解时,基于纠正重审再列发现,不硬撑原判断582. **结论先行**: 一句话给出"有没有优化空间"(没有 → 说明理由,收尾)593. **列要点**: 按严重度从高到低;发现 ≤ 3 条直接给全(位置 + 场景·卡片名 + 理由 + 建议);> 3 条给 top 概览604. **收尾问询**: 发现多时问"逐条过一遍还是出一份报告存档";逐条过按严重度从高到低逐条呈现,每条等用户表态:61 - **确认** → 记为"接受",下一条62 - **改判** → 按用户意见修正严重度或内容,下一条63 - **跳过** → 记为"跳过",下一条64 - **追问** → 展开讲清该条后再回到该条表态655. 逐条过完全部后输出汇总(接受 / 改判 / 跳过 计数 + 采纳清单),询问是否生成报告存档或进入具体重构6667### Step 6: 报告形态6869开头先给一段**整体理解**(口径同 Step 5 第 1 步,不超过一段),再按 `references/report-template.md`70两档输出;严重度查 `references/severity-rubric.md`;末尾问用户要不要细化 / 跳过 / 改判 / 切对话逐条过。7172## 参考样例7374**简短示例 — 对话式分析回答(默认)**。用户输入:7576> 帮我 review 一下 src/parser.py(80 行 Python 解析器)7778skill 回答:7980> 先说我的理解: 这是一个订单解析器——`process()` 逐行读入订单数据,拆字段后校验数量与单价,再计算总价并打印;解析 / 校验 / 计算三个语义段都内联在同一个大函数里。81>82> 基于这个理解,有优化空间,3 个要点:83>84> 1. **Major** — parser.py:1 `Extract Method`:`process()` 62 行内嵌 3 个语义段,建议抽 `parse_lines()` / `calc_total()`85> 2. **Minor** — parser.py:14 `Magic Literal`:`0.9` / `100` / `0.95` / `1000` 改成具名常量86> 3. **Major** — parser.py:6 `Introduce Parameter Object`:`(qty, price)` 重复 4 处,改 dataclass87>88> 要逐条过一遍,还是出一份报告存档?8990**简短示例 — 逐条过**。用户输入:9192> 陪我一起 review 一下 src/parser.py,逐条过9394skill 第一条:9596> **1/4 · Major** — parser.py:1 `Extract Method`:`process()` 62 行内嵌 3 个语义段97> (计算总价 / 校验 / 打印),建议抽 `calc_total()` 和 `validate_order()`。接受 / 改判 / 跳过?9899用户: 跳过,后面 3 行是核心逻辑。100skill: 记下,下一条 —— **2/4 · Minor** …(循环至汇总)
yzr95924