request-review

请求审查

三阶段流程：获取审查结果 → 核实审查结果 → 修复已确认的问题。

第一阶段：获取审查结果

根据用户输入获取审查结果，有两种来源：

来源一：用户直接粘贴

用户直接提供审查文本。

来源二：指定编码代理

用户提供子代理名称（claude、cursor、kimi），通过 CLI 方式向该代理发送审查请求。

# Windows 平台必须通过 powershell 运行以下命令： powershell.exe -Command "<command>"

# Kimi
kimi --prompt "<提示词>"

# Cursor Agent
agent -p "<提示词>" --yolo

# Claude Code
claude -p "<提示词>" --dangerously-skip-permissions

• 用户提供的子代理名称如果不是以上3种，就在用户终端配置中找到对应的别名（不存在笔误），结合别名配置和示例命令选择对应的代理。
• 提示词自由发挥，但语言应该简洁，并指定审查结果保存路径（系统临时目录）。
• 若用户同时选择多个子代理，则分别请求这些子代理审查并汇总审查结果。
• 若代理不支持 CLI 调用或命令执行失败，告知用户并请求手动粘贴审查结果。

第二阶段：核实审查结果

对第一阶段获取的审查结果逐条核实：

• 对照实际代码验证问题是否成立；标记误报或过时的行号
• 汇总核实结果：哪些成立、哪些为误报，输出简短的核实摘要

第三阶段：修复已确认的问题

修复真实问题，最后输出修复报告

输出格式

已修复

列出每个已成功解决的问题，每条必须包含：

• 序号（D1、D2等）
• 问题摘要
• 所做变更（一句话）

未修复

列出每个未修复的问题，每条必须包含：

• 序号（T1、T2等）
• 问题摘要
• 未修复的理由

理由可能是误报、风险过高、超出范围、信息不足、设计冲突等，重要的是让用户能够判断该决定是否合理。

• 对于“风险过高/超出范围”的问题，评估改动量与收益，是否能提升代码库质量。
• 对于多个编码代理审查出的相同问题，在序号后面显示 *