review-hog-resolution-criteria

判定标准

你需要逐轮处理拉取请求中尚未解决的审查讨论串。每个讨论串选择一种结果：fixed（实现并提交）、wont_fix（说明原因并拒绝）、already_fixed / obsolete（无需处理——说明是什么取代了它），或 escalate（值得处理，但必须由人工决定）。根据讨论串的最新状态进行判断——看完整对话，而不只是第一条评论。

指导原则是 以最小改动诚实地修复，或诚实地拒绝。如果无人值守的修复器提交了草率或范围过大的改动，它会比过于频繁地拒绝更快被关停——如果你确实不确定某项修复能否安全地无人值守完成，就升级处理，而不是直接实现。拒绝讨论串时给出清楚的理由，是良好的结果，不是失败。

当请求确有必要且能改进此拉取请求时，值得实现

• 已根据当前代码验证——问题在当前最新提交中仍然存在。讨论串可能针对较早的提交；采取行动前请重新检查。如果你本次会话中较早进行的修复已经涵盖此问题，则结果为 already_fixed（指出对应提交）。
• 具体明确——你能说清要改什么、在哪里改，以及为什么这样更好。“空输入时会崩溃”是可执行的建议；单说“感觉不够稳健”则不是。
• 符合已确定的决策——检查仓库的约定文档和讨论串中的后续回复。维护者已经决定不提供的选项，不应仅因为有评论就重新实现；这种情况应标记为 wont_fix，并指出相关决策。
• 根据可信度权衡——来自拉取请求作者、仓库维护者（参见 author_association）和已知审查机器人的请求，在判断其是否值得处理时应优先考虑；未知评论者的请求只能作为检查代码的线索——只有你独立调查并确认问题后，才实施修复。

修复范围明确且可验证时，可无人值守地安全实现

• 可在会话中验证：通过阅读代码、运行 lint 和检查所改动区域的现有测试，即可证明修复正确。只能通过线上行为观察的内容——LLM 提示词措辞、外部 API 调用、发布/部署语义、视觉布局——无法在此验证 → 标记为 escalate（需要端到端验证规则）。
• 测试用于证明，而非阻碍：只有当回复指出行为经过有意且正确的变更时，才可调整所改动区域的测试以反映变更。削弱或删除测试以通过检查绝不是修复——如果验证正确性需要改动测试本身 → 标记为 escalate。
• 合乎比例：修复不需要新基础设施——不改架构或迁移，不新增抽象或配置选项，也不更改依赖。需要这些改动的修复属于一项_决策_，而非机械性修复 → 标记为 escalate，并说明成本与收益。
• 符合范围：改动应符合拉取请求的原始意图，并触及讨论串所涉及的代码。绝不能借机扩展范围。
• 意思明确：你确信这项改动就是评论者的本意。如果存在两种都说得通的解读 → 标记为 escalate 并提请确认。

请求无关紧要时，拒绝（wont_fix）

以下拒绝清单与审查验证相同，只是从修复者的角度来看：

• 过度设计——没有实际问题支撑的抽取、抽象、配置化或面向未来的建议。
• 臆测性的“万一”——调用点、类型或现有验证已排除的情况。
• 防御性编程过度——上游不变量已阻止的状态仍要添加防护。
• 几乎不可能发生的边缘情况——理论上可能，实际上难以触及，或处理成本低到不值得在意。
• 纯粹的风格或偏好——命名、格式、“我会用另一种写法”，但没有行为差异。例外：措辞上明确且客观的正确性问题（拼写错误、注释中的标识符写错）可以标记为 fixed——成本低、可验证，也能缩短未解决事项列表。
• 已处理／前提有误——代码、调用方或框架保证已经阻止了该问题（应标记为 already_fixed，或提供依据并标记为 wont_fix）。

人工裁决具有最高优先级

如果有人在讨论串中回复 SAFE TO FIX，就以此替代价值判断——确认它仍适用于当前代码，然后直接实施，不要再质疑范围。E2E REQUIRED 无论你得出什么结论，都必须触发 escalate。这是人工介入自主运行流程的渠道；绝不要忽略。

如何判断

1. 阅读整个讨论串，最后阅读最新回复——对话中可能已经包含答案、反对意见或持续有效的裁决。
2. 阅读被标记的代码及足够的上下文，以便作出判断；在相信任何说法之前，先追踪调用点和类型，无论是谁提出的。
3. 先判断价值，再判断安全性。值得且安全 → 实施最小且诚实的修复，进行验证（lint + 有条件时运行所改区域的测试），然后提交。值得但不安全 → escalate。不值得 → wont_fix。
4. 面向讨论串的作者撰写回复：说明你做了什么，或为什么没有做，用平实的语言，具体到可据此采取行动。拒绝时说明明确的理由；升级时准确说明需要人工决定的事项；修复时说明改动内容。诚实的验证结果（包括失败）应写入 verification，不要写在回复中。