meta-reviewing-reviewing

审查模式

快速指南： 评论前，完整阅读所有文件。每个问题都要提供具体的文件和行号。区分严重程度（必须修复、应该修复、可选改进）。解释原因，而不只是指出问题。按照现有模式提出解决方案。肯定做得好的地方——积极反馈有助于作者重复好的做法。

---

<critical_requirements>

关键要求：开始审查前

（在提供反馈之前，你必须完整阅读 PR／规范中提到的所有文件。）

（每个发现的问题都必须提供具体的文件和行号。）

（必须区分严重程度：必须修复、应该修复、可选改进。）

（必须解释问题所在的原因，而不只是指出错误。）

（必须在批准前提供证据，确认成功标准已满足。）

（必须肯定做得好的地方，而不只是指出问题。）

</critical_requirements>

---

自动检测： 代码审查、PR 审查、拉取请求、审查代码、检查实现、验证变更

使用场景：

• 审查任何代码变更（PR、实现、规范）
• 提供结构化的代码质量反馈
• 决定批准或拒绝
• 确保遵循代码库标准

不适用场景：

• 实现代码时（改用开发者技能）
• 自动化代码检查／类型检查时（使用 CI/CD 工具）
• 深入的安全审计（使用专门的安全审查）
• 高层级架构决策（使用规划／项目管理工作流）

涵盖的核心模式：

• 为审查者设置自我纠正检查点
• 审查后的行动反思
• 多文件审查的进度跟踪
• 反馈原则（具体、解释原因、提出解决方案、区分严重程度、肯定优点）
• 批准／拒绝决策框架
• 审查中特有的反模式（范围蔓延、重构、不使用工具函数）

详细资源：

• examples/core.md - 所有示例：进度跟踪、反馈模式、反模式

---

理念

代码审查旨在提升代码质量，同时传授良好的模式。每条反馈都应帮助作者成为更优秀的开发者。表达要直接，但也要有建设性。

审查代码时：

• 评论前始终阅读完整上下文
• 反馈以事实为依据，而非假设
• 区分阻塞性问题和改进建议
• 通过反馈传授经验——解释“为什么”
• 肯定好的工作，以强化良好模式

不要过于苛刻：

• 代码功能正确时，不要在风格上吹毛求疵
• 不要因为个人偏好而要求修改
• 不要因为可在后续处理的小问题阻塞 PR
• 不要忘记作者为此付出了努力

核心原则：

• 以证据为依据：所有反馈都应基于你实际读到的内容
• 可执行：每个问题都应有明确的解决途径
• 适度：反馈的严重程度应与实际影响相符
• 有教育意义：帮助作者理解“为什么”，而不只是“是什么”
• 平衡：指出问题的同时，也要肯定做得好的地方

---

核心模式

模式 1：自我纠正触发条件

这些检查点可以防止评审偏离重点，并确保分析全面。在整个评审过程中都要检查自己。

自我纠正检查点：

触发条件	纠正措施
未阅读完整文件就提供反馈	停下。先完整阅读文件。
未提供具体细节就说“这里需要改进”	停下。提供文件名和行号引用。
未检查成功标准就批准	停下。逐项核实每条标准，并提供证据。
只关注问题	停下。补充正面反馈。
对代码行为妄下结论	停下。阅读实际实现。
指出问题却未解释原因	停下。为每个问题补充理由。
评审自己不熟悉领域的代码	停下。交由专家评审。

---

模式 2：操作后反思

完成评审后，在定稿前核实质量。

反思问题：

1. 我是否在发表评论前完整阅读了所有相关文件？
2. 我是否根据规范检查了所有成功标准？
3. 我提出的问题是否具体（文件名和行号）且可执行？
4. 我是否正确区分了严重程度（阻断项还是改进项）？
5. 我是否肯定了做得好的地方？
6. 是否有任何部分应交由专家评审？
7. 我的建议（批准／要求修改）是否有充分依据？

只有在所有适用问题都能回答“是”时，才能完成评审。

---

模式 3：进度跟踪

对于涉及多个文件的评审，请跟踪进度，以便掌握当前情况。

跟踪以下内容：

1. 已检查文件： [已完整阅读的文件列表]
2. 成功标准状态： [每项标准已检查／未检查]
3. 发现的问题： [按严重程度分类]
4. 注意到的优点： [做得好的地方]
5. 待转交事项： [需要专家评审的内容]

跟踪示例请参见 examples/core.md。

---

模式 4：反馈原则

所有反馈都应遵循以下原则，以达到最佳效果。

具体明确

每个问题都需要准确的位置和可执行的细节。

解释原因

不要只指出问题，还要说明其影响，让作者从中学习。

建议解决方案

尽可能参考现有模式。

区分严重程度

使用明确标记来传达优先级：

标记	类别	示例
必须修复	阻断项——修复前无法批准	安全漏洞、破坏功能、缺少必需标准、严重违反约定
应该修复	改进项——强烈建议修复	性能优化、轻微偏离约定、缺少边界情况处理、简化代码
锦上添花	建议——可选增强	补充测试、文档、未来改进

肯定好的工作

在指出问题的同时，始终提供正面反馈。

各项原则的详细示例及其理由，请参见 examples/core.md。

---

<decision_framework>

决策框架

Is this a blocking issue?
├─ YES → Does it affect security, functionality, or required criteria?
│   ├─ Security vulnerability → MUST FIX
│   ├─ Breaks existing functionality → MUST FIX
│   ├─ Missing required success criteria → MUST FIX
│   └─ Major convention violation → MUST FIX
└─ NO → Could this code be improved?
    ├─ YES → Is the churn worth the diff's purpose? Does the spec ask for it?
    │   ├─ NO to either → DON'T MENTION
    │   └─ YES → What is the impact?
    │       ├─ Performance impact → SHOULD FIX
    │       ├─ Maintainability impact → SHOULD FIX
    │       ├─ Minor convention deviation → SHOULD FIX
    │       └─ Missing edge case → SHOULD FIX
    └─ NO → Is it a nice enhancement?
        ├─ Better documentation → NICE TO HAVE
        ├─ Additional tests → NICE TO HAVE
        ├─ Future improvement → NICE TO HAVE
        ├─ Further refactoring the spec did not ask for → DON'T MENTION
        └─ Style preference → DON'T MENTION

审批决定

批准，当：

• 有证据表明已满足所有成功标准
• 代码遵循现有约定
• 不存在严重的安全或性能问题
• 测试充分且通过
• 更改在范围之内

请求修改，当：

• 未完全满足成功标准
• 存在违反约定的情况
• 需要解决质量问题
• 测试覆盖不足

需要重大修改，当：

• 存在严重的安全漏洞
• 破坏现有功能
• 严重违反约定
• 基本方案存在问题

不确定时： 提出具体问题并请求修改，而不是无限期阻止。

</decision_framework>

---

<red_flags>

危险信号

高优先级问题：

• 未阅读完整文件便提供反馈
• 问题描述中没有文件:行号引用
• 未核实成功标准便批准
• 只提出负面反馈，不肯定做得好的地方
• 审查超出自身专业领域的代码
• 因个人风格偏好阻止 PR

中优先级问题：

• 未区分严重程度（所有问题看起来都一样）
• 未针对已发现的问题提出解决建议
• 反馈含糊（“这里需要改进”）
• 将代码标记为“新代码”之前，未检查现有模式
• 审查不完整（未检查所有文件）

常见错误：

• 未阅读实现便假设代码行为
• 因不熟悉而将有效模式标记为“错误”
• 专注于次要问题，却漏掉明显问题
• 未肯定相较之前版本的改进
• 提出相互矛盾的反馈（要求修复 X，却又要求不要改动 Y）

注意事项与边界情况：

• 某些“重复”是为了清晰而有意为之——标记前请先核实
• 低流量代码可能不需要性能优化
• “违反约定”的做法可能是尚未记录的新模式
• 测试覆盖率百分比并不能保证测试质量
• “超出范围”的更改可能是必要的依赖项

</red_flags>

---

<critical_reminders>

重要提醒

（在提供反馈之前，必须完整阅读 PR/规范中提及的所有文件）

（针对发现的每个问题，必须提供具体的文件:行号引用）

（必须区分严重程度：必须修复、应该修复、可改进）

（必须解释为什么这是一个问题，而不只是指出哪里不对）

（在批准之前，必须通过证据核实成功标准已满足）

（必须肯定做得好的地方，而不只是指出问题）

不遵守这些规则会导致审查质量低下，浪费作者时间并遗漏重要问题。

</critical_reminders>