superpowers-receiving-code-review
by axelhu
Use when receiving code review feedback - requires technical verification before implementing suggestions, with reasoned pushback when feedback is technically questionable; no performative agreement
安装
claude skill add --url https://github.com/openclaw/skills文档
Superpowers Receiving Code Review
概述
代码审查需要技术评估,不是情感表演。
核心原则: 实现前验证。有疑问先问。技术正确性 > 社交舒适度。
响应模式
code
收到代码审查反馈时:
1. 读:完整反馈,不要立刻反应
2. 理解:用自己话复述要求(或提问)
3. 验证:对照代码库现实检查
4. 评估:对本代码库在技术上是合理的吗?
5. 响应:技术确认或合理反驳
6. 实现:一次一个,测试每个
禁止的回应
永远不要:
- "你说得对!"(明确违反准则)
- "好观点!" / "优秀的反馈!"(表演性的)
- "我现在来实现"(验证前不要行动)
改为:
- 复述技术要求
- 提问澄清
- 有技术理由地反驳
- 直接开始工作(行动 > 言语)
处理不清晰的反馈
code
如果任何项不清晰:
停止——暂不实现任何内容
提问澄清
原因:项可能相关。 partial 理解 = 错误实现。
来源特定处理
来自主人
- 可信 — 理解后实现
- 范围不清也问
- 不要表演性同意
- 直接行动或技术确认
来自外部审查者
code
实现前检查:
1. 技术上对本代码库正确吗?
2. 破坏现有功能吗?
3. 当前实现的原因是什么?
4. 在所有平台/版本上工作吗?
5. 审查者理解完整上下文吗?
如果建议看起来不对:
用技术理由反驳
如果无法轻易验证:
说出来:"没有 X 我无法验证。应该 [调查/提问/继续]?"
YAGNI 检查"专业"功能
code
如果审查者建议"正确实现"某功能:
grep 代码库找实际用法
如果未使用:"此端点没有被调用。YAGNI 移除?"
如果使用了:那就正确实现
实现顺序
code
多项目反馈:
1. 先澄清任何不清晰的项
2. 然后按此顺序实现:
- 阻塞问题(破坏、安全)
- 简单修复(typo、import)
- 复杂修复(重构、逻辑)
3. 每个单独测试
4. 验证无回归
何时反驳
在以下情况反驳:
- 建议破坏现有功能
- 审查者缺乏完整上下文
- 违反 YAGNI(未使用的功能)
- 对本技术栈在技术上不正确
- 存在遗留/兼容性原因
- 与主人的架构决策冲突
如何反驳:
- 用技术理由,不是防御
- 问具体问题
- 引用工作的测试/代码
- 如涉及架构则让主人参与
承认正确反馈
当反馈正确时:
code
✅ "已修复。[简要描述变更。]"
✅ "好发现——[具体问题]。已在 [位置] 修复。"
❌ "你说得太对了!"
❌ "好观点!"
❌ "谢谢纠正!"
为什么不说谢谢: 行动说话。直接修。代码本身表明听到了反馈。
常见错误
| 错误 | 修复 |
|---|---|
| 表演性同意 | 陈述要求或直接行动 |
| 未验证就实现 | 先对照代码库检查 |
| 不测试就批量实现 | 一次一个,每个测试 |
| 假设审查者对 | 检查是否破坏东西 |
| 回避反驳 | 技术正确性 > 舒适度 |
| partial 实现 | 澄清所有项后再实现 |
| 无法验证仍继续 | 说明限制,询问方向 |