让评审和异常处理有明确的下一步

执行者会遇到环境抖动、失败的构建、合并冲突和遗漏的界面细节。人不在电脑前时，它仍需要知道下一步该检查什么、何时继续、何时停下。

每次检查都有对象

作者让工程伙伴每 30 分钟查看共享数据库，并对相关变更请求检查以下三类问题。30 分钟是案例的配置，不是每个项目必须采用的频率。

发现异常后，作者会让伙伴向执行任务发送跟进要求，并把账本状态改回处理中。没有发现阻塞时，进入待评审阶段并启动代码检查，继续寻找质量问题和遗漏。

图片与代码都需要验收

下图的任务卡显示已完成，并列出变更编号、修改文件数和增删行数。它证明这里存在一条执行记录；单靠卡片，还不能知道两个需求入口是否真的符合要求。

案例中另一条对话更适合拿来练习验收。伙伴已经打开静态截图检查移动端界面，但仍在等待 CI，并明确表示带有 # / +N 的外圈效果还不能算完成。

我觉得这种回复比笼统地说“已完成”有用。它把已检查的部分和仍待完成的部分放在同一条任务里，人回来时可以接着判断。

对于视觉改动，练习中要同时检查修改前后截图、目标页面、操作状态和实际交互。一张正确的静态图不能替代点击结果，一次构建成功也不能证明视觉已经符合要求。

自动合并与人工合并分开配置

这里有三份需要一起看的资料。

不能把正文中的条件性自动合并，套到一个明确禁止伙伴合并的工作台里。首次练习采用人工合并更容易核对职责；将来要开放自动合并，需要明确哪些改动适用，以及原来的禁止规则如何更新。

遇到卡住，先说明卡在哪里

作者的伙伴会读执行记录，发送继续处理的消息，也能在方向不对时打断任务。环境偶发故障可能在此过程中被处理，但没有足够安全权限的情况仍需要人介入。

要求“再尝试十轮”是原文举出的沟通方式，不能把它当成突破权限限制或保证成功的办法。练习时可以设最多尝试次数，同时记录每次调整的原因；相同错误反复出现而没有新证据时，应停止重复运行并上报。

紧急任务才提高检查频率

原文的 P0 流程会临时每五分钟查看执行记录和进度，发现无效等待就调整执行方向。它用在紧急代码调研或关键缺陷处理上，作者同时提醒这种做法会更快消耗 token。

把 30 分钟改成 5 分钟，一小时的计划检查次数会从 2 次变为 12 次。这只是次数演算，不能直接说总费用一定增加六倍，因为每次阅读的记录长度和实际动作不同。

本次按紧急任务处理。每五分钟检查一次当前执行记录，说明进展、阻塞和下一步。最多运行三十分钟；如果已经完成验收，或缺少需要人工提供的权限，就结束这条临时检查。不要把加急规则扩展到其他任务。

这份提示词里的三十分钟上限和退出条件是本课练习约束，原文没有给出相同参数。

本课练习

让一个任务分别返回代码检查结果和界面检查结果。人为留下一项未完成的验收点，观察负责协调的伙伴会不会继续要求补齐，并把任务保持在正确状态。

通过标准是未完成项没有被“运行结束”掩盖；正常流程和紧急流程都有停止条件，最终合并由已指定的主体决定。