receiving-code-review · 评审反馈处理
收到代码评审意见时的技术处理流程：先验证再改，不表演式附和、不盲目照做。
收到评审先读完整反馈、自己复述需求、对着代码库验证、评估是否适用于本项目，然后技术确认或有理有据地驳回。反馈含糊先停下问清再动；多项反馈先厘清再按阻塞问题→简单修→复杂修的顺序逐项测试实施。外部评审意见保持审慎怀疑，用事实和测试说话。
调用示例：在聊天框中说"帮我过一下这份评审意见，哪些该改"。
产品详解
定位
receiving-code-review 是一套评审处理方法：技术评估而不是情绪表演。它规定"收到评审→动手改"之间的完整流程。
核心能力
- 六步响应模式：读（完整反馈）→ 懂（自己复述）→ 验（对照代码库）→ 评（适用于本项目吗）→ 应（技术确认或有理驳回）→ 改（逐项实施测试）。
- 禁止表演式附和：不说"你完全说得对""好建议"，直接陈述修复内容。
- 含糊反馈先问清：有任何一项不清楚就停下，全部厘清后再动；不做部分理解下的实施。
- 来源区分处理：人类伙伴可信但范围不明仍要问；外部评审意见需逐项验证（技术上对本代码库是否正确、是否破坏现有功能、是否了解全貌），冲突时先与人类伙伴讨论。
- YAGNI 检查：评审建议"专业实现"时先 grep 实际调用；没调用的直接问要不要删。
- 实施顺序：阻塞问题（崩溃/安全）→ 简单修复 → 复杂重构；逐项测试，不批量合并。
- 驳回机制：建议破坏现有功能、评审者缺上下文、违反 YAGNI、技术上对本栈不正确、与架构决策冲突时，用技术理由驳回。
- GitHub 行内评论：在评论 thread 内回复，不发顶层 PR 评论。
工作流程
- 完整阅读反馈，不急着反应
- 自己复述需求（或发问）
- 对照代码库验证每项
- 评估是否适用于本项目；有理有据地确认或驳回
- 先厘清含糊项，再按阻塞→简单→复杂的顺序逐项实施
- 逐项测试，验证无回归
输入与输出
| 输入 | 必填 | 说明 |
|---|---|---|
| 评审反馈 | 是 | 评审意见列表 |
输出：每项评审的技术结论（实施/驳回/问清）+ 逐项测试通过的代码修改。
适用场景
- PR 评审意见的技术评估与实施
- 外部 reviewer 意见的谨慎处理
- 多人协作中的评审流程规范
使用前准备
- 无需 API key。
- 该方法假定你能访问代码库验证评审意见；无法验证时明确说出局限并问方向，而不是硬着头皮推进。
receiving-code-review 隶属于 Aiglade Skill 库。在 Aiglade 聊天框中用自然语言描述需求即可调用。