用 LingCode 给出并处理代码审查

当 PR 带着审查意见退回来时，最朴素的工作流是"审查者比我资深，照着改就行"。这会以两种可预见的方式出问题：

• 自信但错误的反馈被直接上船。 审查者可能误读了上下文、忽略了附近的辅助函数，或套用了并不适合当前场景的模式。盲目落实后，建议不仅没有改善行为，反而带来了退化或死代码。
• 正确的反馈被辩解掉。 听到"这里有问题"时，第一反应往往是捍卫自己的设计决策，而不是用新鲜的眼光重新审视代码。真正的 bug 就这样存活下来了。

本教程中的技能为 LingCode 提供了一套明确的协议：读取评论、对照代码核实意见、分类（同意 / 不同意 / 不明确），然后再采取行动。输出结果要么是一次精准的修复，要么是一份精准的回复，解释为何该建议并不适用。

• LingCode — 下载安装程序。
• 一个带有审查意见的 PR。 适用于 GitHub、GitLab，以及任何审查者粘贴到聊天中的工作流。gh pr view --comments 是最简便的拉取方式。
• 在本地检出对应分支，这样 LingCode 才能读取审查者当时看到的代码——而不仅仅是 diff。

在对应分支上打开聊天面板，让 LingCode 获取完整的审查线程，而不是仅对 diff 做摘要：

Fetch review comments on this PR (use `gh pr view --comments` or
`gh api`). For each comment, capture: file, line, reviewer's claim,
and any suggested code. Don't act on anything yet — list them.

你需要的是带有行锚点的原始线程。如果先让另一个模型把五条评论合并成"处理反馈"再交给你，那就是会产生糟糕修复的版本。

这是本技能存在的核心步骤。让 LingCode 读取被引用的文件，然后验证审查者的说法是否成立：

For each comment, open the referenced file and verify the claim:
- Quote the actual code at that line.
- State whether the reviewer's description of it is accurate.
- Note any context they may have missed (helpers, callers, tests).
- Only then classify: AGREE, DISAGREE, or UNCLEAR.

Do not classify a comment AGREE without first reading the code.
"Looks reasonable" is not verification.

"先核实再分类"是消灭盲目认同失败模式的关键规则。如果 LingCode 无法引用审查者所指的代码，它就没有资格同意对方。

防御性失败模式是把每条审查意见都视为必须满足的要求。高效的做法是把"我不同意，原因如下"视为一种正常回复。让 LingCode 像撰写修复方案一样认真地撰写反驳意见：

For every DISAGREE classification, write a short reply (3-6 lines)
that:
1. Restates the reviewer's concern in your own words so they know
   you read it.
2. Quotes the code that actually addresses the concern, OR
   explains the constraint they may have missed.
3. Proposes a path forward — "leave as-is," "rename for clarity,"
   "add a comment explaining the constraint."

Don't be defensive. Don't be apologetic. Just be precise.

目标是让审查者能够接受这个回复，或者在下一轮提出进一步反驳。含糊的"好的，我会看一下"是最糟糕的结果——它让线程悬而未决，分歧也依然存在。

有些审查意见在技术上纯属错误——对语言特性、框架行为或约束条件的误解。本技能教 LingCode 直接说出来，并提供证据：

If a reviewer claim is technically incorrect (wrong about an API,
a language behavior, a framework lifecycle, etc.), reply with:
- The specific incorrect claim.
- The actual behavior, with a link to docs or a small repro
  snippet.
- Why this matters for the PR — does it change the suggested fix?

Be willing to write "this is not how X works" with evidence. That
is not rude. Implementing wrong feedback to be polite is rude to
the next maintainer.

核实和分类完成后，"同意"清单的处理就是机械性工作了。让 LingCode 一次性完成应用，然后重新跑测试：

For every AGREE classification:
1. Apply the suggested change (or a close variant if the suggestion
   has a small flaw you noticed during verification).
2. Run the affected tests.
3. If anything fails, stop and surface the failure — don't paper
   over it with a follow-up tweak.

Then write one commit per logical group of related changes —
not one commit per comment.

每条评论一个 commit 看起来整齐，但会让 diff 难以审查。按意图分组：比如"统一命名反馈"、"收紧 X 处的错误处理"、"为 Y 补充缺失的测试"。

"不明确"清单是大多数意外范围蔓延的源头——LingCode 猜测审查者的意思，实现了某些东西，然后引发新一轮评论。正确的协议是主动提问：

For every UNCLEAR classification, write a reply that:
- Quotes the comment.
- States the two or three interpretations you considered.
- Asks the reviewer which one they meant.

Do not guess and implement. A clarifying question is cheap;
re-reviewing a wrong implementation is not.

这也是推回超出范围的反馈的好时机——"好主意，我们把它记录为后续 issue，而不是在这个 PR 里扩展范围"。审查者通常会同意；如果不同意，你已经揭示了一个真正值得在更多代码落地之前解决的分歧。

在将 PR 提交给人工审查之前，先对自己的分支运行 LingCode 的 /review，并将输出结果通过同样的协议处理一遍。你可以在人工审查者花费时间之前，自己捕获所有"同意，修复"的反馈，最终提交给人工审查时只剩下真正有争议的内容。

这种效果会叠加。在 /review 之上再用审查接收技能做自我审查，意味着人工审查者收到的 PR 质量更高，合并速度更快，下次的 PR 也会更小。

完整的协议已打包为一个技能——将其放入 LingCode 的技能文件夹，然后让 LingCode"处理这个 PR 的审查评论"即可调用：

---
name: receiving-code-review
description: Use when receiving code review feedback, before implementing suggestions — especially if feedback seems unclear or technically questionable. Triggers: 'fix the review comments', 'address feedback', 'apply review', 'reviewer said X', PR comments fetched, code review thread, 'agree with the review and apply'. Actions: verify each claim against the actual code (quote the line), classify AGREE/DISAGREE/UNCLEAR, push back when wrong (write rebuttal with evidence), implement when right, ask reviewer when ambiguous. Anti-patterns: blind agreement, reflexive defense, summarizing reviews into 'address feedback' before reading line-by-line.
---

Process incoming code review feedback with technical rigor. The
two failure modes are blind agreement (implement bad suggestions)
and reflexive defense (ignore good ones). Avoid both.

For each review comment:

1. Fetch the raw thread (gh pr view --comments or equivalent).
   Preserve file + line anchors. Do not summarize away detail.

2. Verify the claim. Open the cited file. Quote the actual code.
   State whether the reviewer's description is accurate. Note
   missed context (helpers, callers, tests).

3. Classify only after verification: AGREE, DISAGREE, UNCLEAR.
   "Looks reasonable" is not verification.

4. For AGREE: apply the change, run tests, group commits by
   intent (not one per comment).

5. For DISAGREE: write a short reply that restates the concern,
   quotes the code that addresses it (or names the missed
   constraint), and proposes a path forward. Not defensive,
   not apologetic — precise.

6. For technically-incorrect feedback: say so with evidence
   (docs link or minimal repro). Politely implementing wrong
   feedback is rude to the next maintainer.

7. For UNCLEAR: ask the reviewer which interpretation they
   meant. Do not guess and implement.

Compose with /review on your own draft before posting for
human review.

保存为 ~/.lingcode/skills/receiving-code-review/SKILL.md——参见安装技能了解确切位置及技能的发现方式。

获取 LingCode →