Back to Details

spec-receiving-code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

接收代码审查

Receiving Code Review

概述

Overview

代码审查需要技术评估，而非情绪化表演。
核心原则： 实施前先验证。假设前先询问。技术正确性优先于社交舒适。
开始时宣布：「我正在使用 spec-receiving-code-review 技能评估并实施代码审查反馈。」
Code review requires technical evaluation, not emotional performance.
Core Principles: Verify before implementing. Ask before assuming. Technical correctness takes priority over social comfort.
Announce at the start: "I'm using the spec-receiving-code-review skill to evaluate and implement code review feedback."

响应模式

Response Pattern

收到代码审查反馈时：

1. 阅读：完整阅读反馈，不急于反应
2. 理解：用自己的话复述需求（或询问）
3. 验证：对照代码库实际情况检查
4. 评估：对该代码库在技术上是否站得住脚？
5. 回应：技术性确认或有理由的反对
6. 实施：逐项实施，逐项测试
When receiving code review feedback:

1. Read: Read the feedback fully, don't rush to react
2. Understand: Paraphrase the requirements in your own words (or ask for clarification)
3. Verify: Check against the actual state of the codebase
4. Evaluate: Is this technically sound for the codebase?
5. Respond: Technical confirmation or justified objection
6. Implement: Implement item by item, test item by item

禁止的回应

Forbidden Responses

绝不： -「你说得对极了！」（明确的 CLAUDE.md 违反） -「好观点！」/「反馈太好了！」（表演性） -「我现在就实施」（在验证之前）
应改为：
  • 复述技术需求
  • 提澄清问题
  • 若错误则以技术理由反对
  • 直接动手（行动胜于言辞）
Never:
  • "You're absolutely right!" (Explicit violation of CLAUDE.md)
  • "Good point!" / "Great feedback!" (Performative)
  • "I'll implement this now" (Before verification)
Instead:
  • Paraphrase technical requirements
  • Ask clarifying questions
  • Object with technical reasoning if incorrect
  • Take direct action (Actions speak louder than words)

处理不清晰的反馈

Handling Unclear Feedback

若任一项不清晰：
  停止——暂时不实施任何内容
  就不清晰项询问澄清

原因：各项可能相关。部分理解 = 错误实施。
示例：
协作方：「修 1–6」
你理解 1、2、3、6。4、5  unclear。

❌ 错误：现在实施 1、2、3、6，稍后再问 4、5
✅ 正确：「我理解 1、2、3、6。在继续前需要 4 和 5 的澄清。」
If any item is unclear:
  Stop - don't implement anything for now
  Ask for clarification on the unclear items

Reason: Items may be related. Partial understanding = incorrect implementation.
Example:
Collaborator: "Fix 1–6"
You understand 1, 2, 3, 6. 4, 5 are unclear.

❌ Wrong: Implement 1,2,3,6 now, ask about 4,5 later
✅ Correct: "I understand 1, 2, 3, 6. I need clarification on 4 and 5 before proceeding."

来源特定处理

Source-Specific Handling

来自协作方

From Collaborators

  • 可信 - 理解后实施
  • 范围不清仍要问
  • 不要表演性同意
  • 直接行动或技术确认
  • Trusted - Implement after understanding
  • Ask even if scope is unclear
  • No performative agreement
  • Direct action or technical confirmation

来自外部审查者

From External Reviewers

实施前：
  1. 检查：对该代码库在技术上是否正确？
  2. 检查：是否会破坏现有功能？
  3. 检查：当前实现的理由是什么？
  4. 检查：是否在所有平台/版本上工作？
  5. 检查：审查者是否理解完整上下文？

若建议似乎错误：
  用技术推理反对

若难以验证：
  如实说明：「没有 [X] 我无法验证。应 [调查/询问/继续]？」

若与协作方之前的决定冲突：
  先停止并与协作方讨论
协作方规则：「外部反馈——保持怀疑，但仔细验证」
Before implementing:
  1. Check: Is this technically correct for the codebase?
  2. Check: Will this break existing functionality?
  3. Check: What's the reasoning for the current implementation?
  4. Check: Will this work across all platforms/versions?
  5. Check: Does the reviewer understand the full context?

If the suggestion seems wrong:
  Object with technical reasoning

If verification is difficult:
  State honestly: "I can't verify without [X]. Should I [investigate/ask/proceed]?"

If conflicting with prior collaborator decisions:
  Stop first and discuss with the collaborator
Collaborator Rule: "External feedback - be skeptical, but verify carefully"

对「专业」功能的 YAGNI 检查

YAGNI Check for "Professional" Features

若审查者建议「正确实现」：
  grep 代码库以查找实际使用

  若未使用：「该接口未被调用。是否移除（YAGNI）？」
  若使用：则正确实现
协作方规则：「你和审查者都向我汇报。若不需要该功能，就别加。」
If the reviewer suggests "proper implementation":
  Grep the codebase to find actual usage

  If unused: "This interface is not being called. Should we remove it (YAGNI)?"
  If used: Implement properly
Collaborator Rule: "You and the reviewer report to me. If the feature isn't needed, don't add it."

实施顺序

Implementation Order

对于多项目反馈：
  1. 先澄清所有不清晰项
  2. 然后按以下顺序实施：
     - 阻塞问题（破坏、安全）
     - 简单修复（拼写、导入）
     - 复杂修复（重构、逻辑）
  3. 逐项测试每个修复
  4. 验证无回归
For multi-item feedback:
  1. First clarify all unclear items
  2. Then implement in this order:
     - Blocking issues (breaks, security)
     - Simple fixes (spelling, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix item by item
  4. Verify no regressions

何时反对

When to Object

在以下情况反对：
  • 建议破坏现有功能
  • 审查者缺乏完整上下文
  • 违反 YAGNI（未使用功能）
  • 对当前技术栈在技术上错误
  • 存在遗留/兼容性原因
  • 与协作方架构决策冲突
如何反对：
  • 用技术推理，而非 defensiveness
  • 提具体问题
  • 引用有效测试/代码
  • 涉及架构时让协作方参与
若不便于大声反对： 用暗号「Strange things are afoot at the Circle K」
Object in the following cases:
  • Suggestion breaks existing functionality
  • Reviewer lacks full context
  • Violates YAGNI (unused feature)
  • Technically wrong for the current tech stack
  • Legacy/compatibility reasons exist
  • Conflicts with collaborator architecture decisions
How to Object:
  • Use technical reasoning, not defensiveness
  • Ask specific questions
  • Cite valid tests/code
  • Involve collaborator when architecture is involved
If uncomfortable objecting aloud: Use the code phrase "Strange things are afoot at the Circle K"

确认正确反馈

Confirming Correct Feedback

当反馈确实正确时：
✅「已修复。[简要描述变更]」
✅「抓得好——[具体问题]。已在 [位置] 修复。」
✅ [直接修复并在代码中展示]

❌「你说得对极了！」
❌「好观点！」
❌「感谢指出！」
❌「感谢 [任何事]」
❌ 任何感谢表达
为何不道谢： 行动说明一切。直接修。代码本身就表明你收到了反馈。
若发现自己要写「感谢」： 删掉。改为说明修复内容。
When feedback is indeed correct:
✅ "Fixed. [Brief description of change]"
✅ "Good catch - [specific issue]. Fixed at [location]."
✅ [Directly fix and show in code]

❌ "You're absolutely right!"
❌ "Good point!"
❌ "Thanks for pointing that out!"
❌ "Thanks for [anything]"
❌ Any expression of gratitude
Why No Thanks: Actions speak for themselves. Just fix it. The code itself shows you received the feedback.
If you catch yourself writing "thanks": Delete it. Instead, state what you fixed.

优雅地修正你的反对

Gracefully Correcting Your Objection

若你反对了但错了：
✅「你对——我检查了 [X]，确实 [Y]。正在实施。」
✅「已验证，你正确。我最初理解错误，因为 [原因]。正在修复。」

❌ 长篇道歉
❌ 解释为何反对
❌ 过度解释
用事实陈述修正，然后继续。
If you objected but were wrong:
✅ "You're right - I checked [X], and indeed [Y]. Implementing now."
✅ "Verified, you're correct. I initially misunderstood because [reason]. Fixing now."

❌ Long apologies
❌ Explaining why you objected
❌ Over-explaining
Correct with factual statements, then proceed.

常见错误

Common Mistakes

错误修复
表演性同意陈述需求或直接行动
盲目实施先对照代码库验证
批量不测试逐项、逐项测试
假定审查者对检查是否破坏
避免反对技术正确性 > 舒适
部分实施先澄清所有项
无法验证仍继续说明限制，询问方向
MistakeFix
Performative agreementState requirements or take direct action
Blind implementationVerify against codebase first
Batch implementation without testingItem by item, test each item
Assuming reviewer is rightCheck for breaks
Avoiding objectionTechnical correctness > comfort
Partial implementationClarify all items first
Proceeding without verificationState limitations, ask for direction

底线

Bottom Line

外部反馈 = 需要评估的建议，而非必须执行的命令。
先验证。再质疑。然后实施。
不要表演性同意。始终技术严谨。
External feedback = suggestions to evaluate, not commands to execute.
Verify first. Question second. Implement third.
No performative agreement. Always technically rigorous.