按照你实际提出的要求，复核 AI 的代码修改

复核 AI 生成的修改时，把三件事对应起来：要求的行为、实际改动的代码，以及支持这些改动的检查。清晰的完成说明是一个有用的起点；补丁和相关结果，才能帮助你判断可以接受什么。

不同修改不必采用相同的复核方式。文案调整和数据迁移需要不同的检查。下面的工作表可以帮助你选择与实际任务相符的检查，避免直接接受一句笼统的“测试通过”。

把请求整理成一张简明的复核表

阅读补丁前，先明确你要求的修改，以及它应保留的行为：

要求的结果：
[什么行为应该发生变化？]

修改边界：
[哪些文件、行为或组件属于这项任务？]

保持不变：
[哪些现有行为需要保留？]

所需检查：
[哪些示例、测试或检查可以支持这个结果？]

实际证据：
[记录你实际查看或运行了什么，并附上对应引用。]

复核决定：
[接受这一范围／要求修正／还需要另一项检查。]

把“所需检查”和“实际证据”分开。在有记录的结果出现之前，一份测试名称清单仍然只是计划。

从一个小补丁开始

下面这个原创、虚构的 Python 示例，用一个小函数演示这种方法。

假设一个任务列表有状态筛选功能。请求是：

“让 all 筛选项按现有顺序返回所有任务。保留按具体状态筛选的行为。空输入仍应产生空结果。把修改限制在 visible_tasks 内。”

初始函数如下：

def visible_tasks(tasks, selected_status):
    return [task for task in tasks if task["status"] == selected_status]

它把每项任务的状态与选定值进行比较。拟议修改为 all 增加一个独立分支：

 def visible_tasks(tasks, selected_status):
+    if selected_status == "all":
+        return list(tasks)
     return [task for task in tasks if task["status"] == selected_status]

在这个示例中，输入是由任务字典组成的列表，每个字典都有 status 值，all 则保留为筛选选项。这些假设很重要：补丁没有定义格式不正确的记录应该怎样处理，也没有定义任务本身的某个其他状态恰好叫 all 时该怎么办。

把每一项要求对应到证据

最后一行很容易漏掉。代码片段可能展示了合适的修复，但完整改动还可能包含无关的设置调整或生成文件。判断范围是否正确之前，先查看完整的改动范围。

使用具体的示例检查

对于这个虚构函数，以下检查表达了要求的行为：

tasks = [
    {"id": "b", "status": "waiting"},
    {"id": "a", "status": "done"},
    {"id": "c", "status": "waiting"},
]

assert [t["id"] for t in visible_tasks(tasks, "all")] == ["b", "a", "c"]
assert [t["id"] for t in visible_tasks(tasks, "waiting")] == ["b", "c"]
assert visible_tasks(tasks, "missing") == []
assert visible_tasks([], "all") == []
assert visible_tasks([], "waiting") == []

这些只是针对这个小函数的示例检查。在真实应用中，你可能还需要集成检查，确认 UI 发送了预期的筛选值，并展示返回的任务。函数级检查通过，并不能证明整个页面正确。

使用项目平常采用的验证工具。如果运行了某项检查，记录实际结果，以及它覆盖的是哪个版本的改动。如果只是阅读了代码，就写“已查看”，不要描述成测试运行成功。

在复核中写清下一步

下面是一份填写完整的虚构补丁复核，依据是阅读代码摘录，没有声称运行过测试：

要求的结果：
all 筛选项按输入顺序返回所有任务。
按具体状态筛选和空输入的行为保持不变。

已查看：
visible_tasks 中新增的两行分支。
按具体状态筛选的列表推导式没有变化。

仍需检查：
完整的仓库 diff。
针对实际实现运行示例断言。
调用方传入的筛选值，以及渲染后的任务顺序。

复核决定：
拟议分支符合所要求的函数级行为。
接受应用层修改前，先完成以上检查。

这份复核的用处在于明确了接下来的检查。它不需要表现得比已完成的工作更有把握。

处理意料之外的额外修改

假设同一个补丁还重命名了整个界面中的状态标签。请追问：哪一项要求使这个修改成为必要？它可能是真实依赖，也可能属于另一项工作。

可以这样给出有针对性的后续请求：

“新增的 all 分支符合要求的行为。标签重命名超出了原任务范围。请说明筛选修复是否依赖这个改名；如果不依赖，把它从这次修改中分离。然后报告针对剩余补丁完成的检查。”

这样既保留了有用的工作，也让复核回到最初请求。编程工具得到的是具体修正要求，而不是一句模糊的“再仔细一点”。

完成复核时，把已接受的行为、相关证据和尚余范围分别记录。指令已发送、补丁已提出、修改已检查、结果已部署，是流程中的不同阶段。如果你在 CueSpec 的任务视图中查看这些状态，可以参考 Docs 中对送达回执与任务完成的说明。