respond-to-code-review

回复代码审查意见

根据实际审查意见和当前代码开展工作。修改代码或回复前，先核实相关说法。

范围

• 如果用户只要求检查或总结意见，就收集并评估意见，然后报告结果。不要编辑代码或发布回复。
• 如果用户要求处理或回复意见，就应用已核实的修复、运行相关检查，并在获得授权后回复。
• 根据链接、编号、当前分支或仓库上下文，确定对应的拉取请求或合并请求。仅在仍有多个合理目标时才询问。
• 使用团队现有的已认证工具。如果 GitHub CLI 缺失且可能有帮助，请阅读可选的一次性设置指南；向用户提供该指南，不要擅自假设用户希望安装。

工作流程

**每次使用都必须执行：**在收集反馈前，确定审查平台并阅读其操作流程：GitHub、GitLab 或 Bitbucket。即使以前使用过此技能，也要阅读对应的参考文档；其中包含该平台的意见收集、回复和解决步骤。跳过其他平台的参考文档；仅在需要设置时阅读一次性设置指南。

1. **收集所有反馈。**阅读审查总结、行内评论及回复、未解决的讨论串和 CI 状态。检查上次推送后是否有更新的评论。不同仓库使用的人类和机器人审查者各不相同；切勿假设已配置 Copilot、Codex、Claude 或其他机器人。
2. **核实每项发现。**检查相关代码，并尽可能复现问题行为或运行针对性检查。对于有关库或 API 的说法，请查阅最新文档。将每项发现标记为有效、已处理、不明确或缺乏依据；对于未作修改的内容，说明证据。
3. **按需进行针对性修复。**遵循仓库的分支、提交和测试规则。确保每项独立修复都便于审查。不要为了满足评论而更改无关行为；相关检查通过前，不要声称问题已修复。
4. **回复审查意见。**发布一条汇总回复，涵盖每项发现、修复、证据以及未修改项目的理由。即使意见来自多位审查者，默认也采用此方式。仅在用户要求，或平台、仓库要求针对讨论串逐条回复或解决时，才逐条回复。避免重复回复。
5. **检查就绪状态。**确认最新检查结果和审查状态。只有在用户授权合并时才进行合并，包括用户已在对话中授权的情况。仅处理意见并不代表获得了合并授权。

如果检查代码和文档后仍无法厘清某项发现，或审查者之间存在矛盾，或与用户的决定相冲突，请说明冲突并询问缺少的决定。切勿仅为关闭讨论串而应用未经核实的建议。

等待审查

仅等待已受邀或根据仓库已知配置预期会参与的审查者。收到表情回应、审查评论或审查请求状态变更，表示有活动；请多等一会儿并再次检查。明确拒绝表示等待结束。若没有活动，间隔约 3–4 分钟最多检查三次，然后报告尚未收到审查并停止轮询。条件允许时，使用计时器或后台监控，不要阻塞任务。如果没有评论，切勿声称机器人审查已通过。如果用户希望启用可选审查者，请参阅审查机器人设置；设置与回复现有反馈是分开的。

回复格式

对于每项发现，请注明其位置或审查者引用，并选择以下一项：

• **已修复：**说明所做的更改、测试或检查证据，以及（如有）提交。
• **已处理：**说明现有代码或较早的提交如何处理该问题。
• **未更改：**说明具体原因及相关代码或文档依据。
• **需要决策：**说明尚未解决的问题，以及它对 PR 或 MR 的影响。

回复应简洁，便于快速浏览。只有在问题已处理且团队工作流程允许后，才解决相关讨论串。