让第二个编码智能体审查，而不是投票

一个智能体完成变更之后，请把原始需求、精确的候选版本，以及一个可以调查的问题交给第二位审查者。比起“另一个 AI 也同意”，更有用的是能够追溯到代码和具体示例的问题结论。

先决定审查者必须返回什么：有明确范围的问题结论、相关产物、影响，以及下一项检查或修正。GitHub 的任务范围指南 建议提供清楚的问题、验收条件和相关文件指引。这些输入同样适用于审查请求。但它们不能证明两个智能体的错误彼此独立，也不能证明任何一方检查了正确的版本。

把一份需求与一个候选版本放在一起

下面是一份完整的虚构请求，编号为 PICK-4：

在项目选择器中隐藏已归档的项目。
让其余项目保持输入时的顺序。
不要重命名标题，也不要修改输入记录。
将变更限制在 visible_projects 内。

本练习的输入是包含 id、title 和 archived 的记录列表。
这个函数不决定谁有权访问某个项目。

原始函数返回所有记录：

def visible_projects(projects):
    return list(projects)

候选 C1 提出了以下变更：

 def visible_projects(projects):
-    return list(projects)
+    return sorted(
+        (p for p in projects if not p["archived"]),
+        key=lambda p: p["title"],
+    )

完整的共享示例有意不按字母顺序排列：

[
  {"id":"P3","title":"Zulu","archived":false},
  {"id":"P1","title":"Alpha","archived":false},
  {"id":"P2","title":"Beta","archived":true}
]

PICK-4 要求返回 ID 顺序 P3, P1。C1 去掉了 P2，却也对剩余两条记录排序，得到 P1, P3。这个小反例就能解决顺序问题，无须投票决定哪份报告听起来更有把握。

示例附有候选包、完整 patch 和四用例示例数据。候选名称是教学标签。标识文件绑定了它们的实际文件字节；这些标识不是 Git 提交，也不是采集到的真实项目历史。

给审查者一项可以检查的工作

比较针对同一个 C1 候选版本提供的两套输入材料。

材料包 A 以实施者的结论开场：

实施者说项目选择器已经修好：已归档项目被隐藏了，
列表更整洁了，变更也已就绪。请确认这样很好。

候选：随本请求提供的 C1/visible_projects.py。
所需功能：隐藏已归档项目。

这套材料遗漏了输入顺序约束，并要求审查者确认一个结论。候选引用是有用的，但审查者还没有拿到完整的决策依据。

材料包 B 以需求和证据开场：

按下方 PICK-4 审查 C1/visible_projects.py。不要编辑文件。

需求：
隐藏已归档项目。保留其余项目的输入顺序。保持标题和
输入记录不变。这是显示辅助函数，不是访问权限检查。

使用给定的 BASE-to-C1.patch 和 review-cases.json。确认你检查的是
哪些候选字节。把混合 P3/P1/P2 用例与所需的 P3/P1 输出比较，
然后考虑空输入和全部已归档的输入。

对每个实质问题，返回需求、代码位置、具体输入、实际或预测
输出、预期输出，以及影响。把阅读与人工推演，同实际运行的
检查分开。说明你无法确认的调用方或已渲染选择器行为。
如果某个产物无法访问，或属于另一个候选版本，报告这个缺口，
不要给出应用层面的接受结论。

材料包 B 让审查过程可以检查。它不是一项证明这种措辞能够提升某个模型表现的实验。新聊天或另一个模型，也不能告诉你宿主会提供哪些项目指令、记忆或外部引用。必要时要核实这些设置；不要仅因提示词没有附上第一份报告，就把审查称为盲审。

按报告中的具体主张处理冲突

下面两份报告完全是编写的虚构教学示例。它们不是真实模型回复，不是对智能体表现的观察，也不是独立审查实验的结果。

虚构报告 R1——接受 C1：

已检查的候选：C1/visible_projects.py。
方法：阅读所示 patch；未报告运行测试。

生成器排除了已归档记录。sorted 返回列表，而按标题字母顺序
排列让选择器更容易浏览。我建议接受这项函数变更。
我没有检查调用它的 UI，也没有渲染 UI。

证据：patch 中可以看到已归档筛选条件和标题排序。
剩余工作：发布前检查实际选择器。

虚构报告 R2——退回 C1，要求修正顺序：

已检查的候选：C1/visible_projects.py。
方法：阅读 PICK-4，人工计算给定的混合示例数据。
这份报告不声称运行了测试。

问题：按标题排序违反了 PICK-4 要求保留输入顺序的规则。
对未归档的 P3/Zulu、未归档的 P1/Alpha、已归档的 P2/Beta，
筛选后是 P3/P1，排序却把它改成 P1/P3。所需输出是 P3/P1。

修正请求：保留遍历顺序进行筛选；保持函数边界和输入记录
不变。针对修正后的候选，检查相同用例、空输入
和全部已归档的输入。

应用层面的限制：未检查调用方或实际选择器视图。
不要凭这次仅针对函数的审查接受完整 UI。

两份报告都正确注意到已归档记录被移除了。它们的分歧在于，额外引入的排序行为是否可以接受。

结果不是“R2 赢了”。应把具体违反的要求和证据一并退回。如果两份报告都说“接受”，却都没有提供所需的顺序检查，意见一致也仍然意味着这项检查缺失。

没有代码结论，也可以是有效的结果。假设审查者被要求检查 C3，却只能打开 C1 的节选。它有明确边界的回复应是：“无法访问 C3 的完整候选。我可以评论给定的 C1 节选，但不能接受 C3。请提供带标识的文件和相关检查记录。”用手头可用的旧 patch 代替，会掩盖证据缺口。

修正候选，再标明检查了什么

C2 作出这项小范围修正：

def visible_projects(projects):
    return [p for p in projects if not p["archived"]]

完整的 C1-to-C2 patch 移除了排序。然后，虚构的负责人又提出一项独立请求：“在 notes.txt 中，把 Project picker review example. 改为 Project picker review teaching example. 不修改代码。”C3 包含这项仅修改说明文件的变更；它的 visible_projects.py 字节与 C2 完全相同。这项独立请求没有改变 PICK-4。三个候选都保留了虚构分支标签 picker-review，因此单凭这个标签不能识别被审查的字节。

配套的本地教学运行使用 Python 3.9.6。每个候选都运行了四个需求用例。C1 在两个用于区分输入顺序和字母顺序的用例中失败；C2 和 C3 的四个用例均通过。这些是对给定小型函数的实际执行。它们与上面的虚构报告分开，也没有运行项目选择器、浏览器或智能体。

Python 固定的 3.9 系列 unittest 文档 将 assertEqual 描述为相等性检查。这里相关的断言是返回的 ID 序列是否相等；仅检查成员是否存在，会漏掉顺序变化。文档所属系列与记录的本地运行时，是两个不同的标识。

让日志、图片和结论跟随各自的候选版本

假设一个审查目录包含以下材料：

未绑定候选的插图 和虚构证据账本 明确展示了来源关联缺失。预期结果的绘图可以帮助表达意图；它不能证明应用实际产生过这个结果。

C2 的函数证据仍然与 C3 有关，因为指定的函数文件、示例数据和被检查的行为都没有变化。这个理由不能把证据范围扩大到完整应用。如果 C3 改变的是调用方的排序、渲染路径或输入转换，旧的辅助函数检查就不能解决那些新行为的问题。

根据实际变更选择下一项检查。顺序修正后，用对顺序敏感的用例检查函数。接受应用之前，在获授权的环境中检查真实调用方，并验证渲染后的顺序。不要仅为延长证据清单而重跑无关检查，也不要复用与候选版本关系不明的图片。

给出限定范围的决定和可复用审查请求

这个完整示例的决定是：

根据 P3/P1/P2 展示的 PICK-4 顺序违规，退回 C1。
C2 修正移除了额外排序。C3 只改说明文件；它的函数字节
与 C2 一致，记录的本地用例对 C3 均通过。

就这四个范围内的用例，接受所示辅助函数的行为。
应用层面的接受仍保持未完成：未检查真实调用方、渲染后的
选择器或部署。绘制的预览是参考，不是一次运行结果。

下一项任务可以改用这份完整的审查请求：

按[当前需求]审查[精确候选/产物标识]。
先读原始需求，再读实施者的结论。
只读工作；本步骤不修复、合并、发布或扩大范围。

确认你检查的文件/字节，或其他可用的版本标识。
对每个实质问题，给出需求、位置、具体用例、预期结果、
观察结果或明确标注的人工预测，以及后果。
如果没有发现问题，说明检查过的范围。

把每份日志、截图和已有审查匹配到它所覆盖的候选。
复用任何检查时，解释哪些内容没有改变，以及哪些结论
仍然成立。产物无法访问或来源关联缺失时，继续保留未知。

返回有明确边界的接受/退回/需要证据决定，以及最小的
相关修正或下一项检查。与另一位审查者意见一致，
不能替代这些证据。单独陈述实际执行情况。

实施者随后就能处理一个具体问题，审查者也能检查修正后的候选。报告之所以有用，是因为其中的主张能够被检查，而不是因为一共有两份报告。