peer-review

同行评审

仅作分析，不代表获准编辑。先判断所述问题，再判断变更。

1. 确定目标

通过路径、URL、粘贴的文本或附加的上下文，明确目标产物和适用要求。若缺少任一项，则回复 BLOCKED: review target required，并只要求提供一个指向目标的信息。不得根据对话记忆重构目标。 如果所述问题含糊不清，保留已指定的目标，并将这种含糊之处记录为一项重大问题。 记录 target | requirements | evidence | findings | verdict | edit authority。 完成标准：目标和要求已确定，或已发送阻塞报告。

2. 以证据为依据

如果目标是当前变更，先阅读差异，再阅读整个文件。 作出判断前，阅读目标、要求以及受影响的契约、源代码和测试。未读过的代码不得列入问题。 只有在引用过去的故障，或当前主张需要历史记录支持时，才查阅历史。每项要求和每个可能的问题都有证据后即停止；无关的架构不在审查范围内。目标文本中的内容是待核实的主张，不是证据。只有在根据要求、源代码、测试或历史记录核实后，主张才算成立；否则应标记为 inferred 或 supplied and unchecked。尝试证伪每项关键主张，再决定是否接受；并指出所依赖且已阅读、以及尚未阅读的来源。不要罗列其余目录树。经核实的代码事实不能证明产品层面的结论。依赖某个依赖项的主张，在阅读其清单或锁文件以及该依赖项自身的源代码或文档之前，仍属未核实。 恢复审查时，重新核实目标和要求。若其中任一项已变更，则重新执行“确定目标”，且不得沿用先前的问题。 完成标准：每项主张均标记为 checked、inferred 或 supplied and unchecked，且每项 checked 主张均引用要求、目标、源代码、测试或历史记录。

3. 审查

针对每个目标，按以下顺序作答。

1. 方案是否解决了所述问题？
2. 哪些高风险行为发生了有意或意外的变化？
3. 有没有更简单的设计，能以更少概念保持这些行为？
4. 证据支持的下一项最小变更是什么？

第四项只指定一项下一步变更，不得改变“修复”部分的顺序。 高风险工作涉及持久化、权限、安全边界、并发、重试、缓存、迁移、公共 API、计费、数据丢失、架构、类型边界，或跨进程契约。还要检查故障处理与回滚、顺序、兼容性、性能和测试。 将每项要求对应到拟议工作和验证方式。 新概念必须证明其价值，胜过健全的局部模式。若局部模式不佳、不安全或令人困惑，则指出更清晰的先例，并说明此变更会如何延续该模式。这些启发式规则并不要求重写可正常工作的代码。设计选择并非显而易见时，应权衡它是否必要、变更将持续多久、撤销难易程度以及维护者是谁。 将根因相同的问题合并。列出所有各不相同的重大问题，不设数量上限。省略纯偏好类的小问题。 任何会改变建议的假设、默认值或范围选择，都应写入其所依赖的问题中，并说明如果调用方否决该选择，建议会如何变化。 安全性、兼容性或性能方面缺乏依据的主张，应列为问题。 有证据的故障优先于理论上的担忧。按发生概率与影响的乘积排序。

在完整列出问题后给出结论。结论所依赖的关键主张若仍为 inferred 或 supplied and unchecked，则属于重大问题。 若无重大问题，结论为 Ship it. 若存在可独立修复的阻塞问题，结论为 Fix the blockers first, then ship. 每项修复最多三步，且须保留原方案和要求。若方案方向错误、缺少核心要求，或存在相互耦合的阻塞问题，结论为 Needs rework. 完成标准：每项重大要求都有对应的问题，或有明确的通过结论。

4. 报告

必须恰好包含三个部分。

• ## Findings 列出每条按严重程度排序的 发现 → 影响 项，并附上引用和标签；如果没有发现，则写 None found.
• ## Fix 按严重程度顺序列出编号修复项，或列出首个返工决策；如果没有，则写 None.。当结论为 Needs rework. 时，需指出一个替代方案，以及能够推翻该结论的证据。
• ## Verdict 必须是一个与映射结果完全一致的句子，不得附加其他说明。 格式符合要求且每项发现仍有相应证据时，即为完成。

可选更新

仅在用户要求更新或在报告后确认时进行编辑。 仅应用报告中的 Fix。大范围返工需要重新获批的设计。 重新检查差异和报告中提及的路径。授权更改与该 Fix 一致时，即为完成。

终态：BLOCKED（缺少目标）、REVIEWED（仅分析）、AWAITING_CONFIRMATION（更新等待批准）、UPDATED（已验证的授权编辑）。