Menü
收到代码评审反馈后、实现建议之前使用，尤其当反馈不清楚或技术上存疑时——要求技术严谨性和验证，而非表演性附和或盲目实现
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | receiving-code-review |
| description | 收到代码评审反馈后、实现建议之前使用，尤其当反馈不清楚或技术上存疑时——要求技术严谨性和验证，而非表演性附和或盲目实现 |
代码评审需要技术评估，而非情绪表演。
核心原则： 先验证再实现。先询问再假设。技术正确性优先于社交舒适感。
收到代码评审反馈时：
1. 阅读：完整读完反馈，不急于反应
2. 理解：用自己的话复述需求（或者提问）
3. 验证：对照代码库现状检查
4. 评估：对当前代码库而言技术上合理吗？
5. 回应：技术性确认或有理有据的反驳
6. 实现：逐项实现，每项都测试
绝不要：
正确做法：
如果有任何项目不明确：
停止 - 先不要实现任何东西
询问 不明确的项目
原因：各项可能相互关联。部分理解 = 错误的实现。
示例：
用户："修复 1-6"
你理解 1、2、3、6。对 4、5 不确定。
❌ 错误：先实现 1、2、3、6，之后再问 4、5
✅ 正确："我理解第 1、2、3、6 项。第 4 和第 5 项需要澄清后才能继续。"
实现之前：
1. 检查：对当前代码库而言技术上正确吗？
2. 检查：是否会破坏现有功能？
3. 检查：当前实现方式有何原因？
4. 检查：是否在所有平台/版本上可行？
5. 检查：评审者是否理解完整上下文？
如果建议看起来有误：
用技术理由反驳
如果无法轻松验证：
如实说明："没有 [X] 我无法验证这一点。我应该 [调查/询问/继续]？"
如果与用户之前的决策冲突：
先停下来与用户讨论
用户的规则："外部反馈——保持怀疑，但仔细核查"
如果评审者建议"正确实现"：
grep 代码库检查实际使用情况
如果未使用："这个端点没有被调用。移除它（YAGNI）？"
如果在使用：那就正确实现
用户的规则："你和评审者都向我汇报。如果我们不需要这个功能，就不要添加。"
对于多项反馈：
1. 先澄清所有不明确的项
2. 然后按以下顺序实现：
- 阻塞性问题（崩溃、安全）
- 简单修复（拼写、导入）
- 复杂修复（重构、逻辑）
3. 逐个测试每个修复
4. 验证无回归
在以下情况反驳：
如何反驳：
如果不太方便公开反驳的暗号："Strange things are afoot at the Circle K"
当反馈确实正确时：
✅ "已修复。[简要描述改了什么]"
✅ "好的发现 - [具体问题]。已在 [位置] 修复。"
✅ [直接修复并在代码中展示]
❌ "你说得完全对！"
❌ "好观点！"
❌ "感谢你发现了这个！"
❌ "感谢你 [任何事]"
❌ 任何感谢表达
为什么不感谢： 行动自己会说话。直接修复就好。代码本身就说明你接收到了反馈。
如果发现自己快要写"感谢"： 删掉它。改为描述修复内容。
如果你反驳了但你是错的：
✅ "你是对的——我检查了 [X]，它确实 [Y]。正在实现。"
✅ "验证了这一点，你是对的。我最初的理解有误，因为 [原因]。正在修复。"
❌ 长篇道歉
❌ 辩护为什么你之前反驳了
❌ 过度解释
陈述事实性更正，然后继续。
| 错误 | 修正 |
|---|---|
| 表演性附和 | 陈述需求或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 批量处理不测试 | 逐项实现，逐项测试 |
| 假设评审者是对的 | 检查是否会破坏功能 |
| 回避反驳 | 技术正确性 > 舒适感 |
| 部分实现 | 先澄清所有项目 |
| 无法验证仍然继续 | 说明限制，请求指导 |
表演性附和（错误）：
评审者："移除遗留代码"
❌ "你说得完全对！让我移除那些..."
技术验证（正确）：
评审者："移除遗留代码"
✅ "检查中... 构建目标是 10.15+，这个 API 需要 13+。向后兼容需要保留遗留代码。当前实现 bundle ID 有误——是修复它还是放弃 13 以下支持？"
YAGNI（正确）：
评审者："实现完善的指标追踪，包括数据库、日期筛选、CSV 导出"
✅ "grep 了代码库——没有地方调用这个端点。移除它（YAGNI）？还是有我遗漏的使用场景？"
不明确的项目（正确）：
用户："修复第 1-6 项"
你理解 1、2、3、6。对 4、5 不确定。
✅ "理解第 1、2、3、6 项。第 4 和第 5 项需要澄清后才能实现。"
在 GitHub 上回复行内评审评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而非发表顶层 PR 评论。
外部反馈 = 待评估的建议，而非待执行的命令。
验证。质疑。然后实现。
不要表演性附和。始终保持技术严谨。
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
在实现完成、测试通过后，引导决定如何集成工作——提供合并、PR 或清理的结构化选项