用途：从审查意见本身出发，判断其是否被代码与需求支持，再决定是否需要超出即时修复的后续动作。适用于用户想确认 PR 评论、commit 反馈是否成立，或询问遗漏原因与是否该做结构清理的场景。
主要能力：先锚定实际改动，阅读评论、相关 diff 或 commit、周边代码，必要时查看受影响的测试或文档，并区分审查者偏好与正确性、清晰度、可维护性、契约问题。然后逐条把意见分类为：成立、部分成立、不被支持，并用代码、行为、测试或明确需求作具体证据。对不成立的意见，除非简短澄清有帮助，否则停止深入分析；对成立的意见，用最小解释归因遗漏，常见分类包括合理的实现遗漏、需求或上下文缺口、测试缺口、清晰度缺口、文档缺口，证据不足时直接说明当时难以发现，不臆造根因。
后续判断：若属正常实现遗漏，建议只处理成立的审查并停止；若问题源于命名误导、职责不清、缺失不变量或缺失文档，才考虑针对性跟进，且优先最小动作，例如重命名误导性符号、补充聚焦的文档注释或模块说明、收紧边界或拆分一个过载职责、增加覆盖遗漏场景的测试。重构门槛要高，一次别扭的审查轮次本身不足以支撑。
输出结构：Review Assessment（逐条给出成立/部分成立/不被支持及证据）、Why It Was Missed（仅针对至少部分成立项）、Additional Action（以“仅处理成立审查”或“增加针对性跟进”开头，列出最小有用动作及理由）、Watch Items（暂不足以行动的可疑点）、Verdict（三选一：仅处理成立审查；处理审查并加小型配套跟进；处理审查并在确认约束后考虑针对性重构）。
沟通规则：把审查评论当作待评估假设而非需辩护的事实；先谈有效性再谈流程与根因；直接但无强证据时不把遗漏描述为失职；不为表现主动性而建议文档、注释、重命名或重构；更广改动要有理由，说明能预防什么以及仅即时修复为何不够。
限制：资料未提供具体安装命令、运行环境、依赖或计费信息。