一个阶段结束时，机器人不应该把队列清空后就退出。未解决的问题、待补充的信息和结果未知的动作，才是最需要交接的部分。交接清楚，下一个维护者才不用重新猜测每条记录。

GitHub的Webhook投递建议强调事件与投递标识。它们适合串起处理过程，但最终交接还应回到Issue本身：现在处于什么状态，证据在哪里，下一步由谁处理。

先给每条未完事项一个明确状态

NEED INFO表示缺上下文，NEED REVIEW表示已有材料但还要判断，BUG CONFIRMED表示复现已经确认。它们不是严重程度排名，也不意味着确认Bug后就可以自动修改生产系统。

状态变化保留时间与依据。重复投递不会产生新的问题，重新打开的Issue也不应丢掉此前讨论；历史记录和当前状态要能关联。

负责人不是模型随手填的名字

图中的OWNER表示已确认的负责入口，可以是维护队列或已接受任务的角色。没有明确接受人时就标未分配，不能因为在Issue里@过某个人，就把他写成已经承诺处理。

NEXT ACTION应包含具体动作与完成条件，例如补充环境信息、运行最小复现、审查某份补丁。需要外部授权的动作留在待确认状态。

用清单验证交接完整性

下面拒绝没有下一步或证据引用的教学交接条目，并把未分配事项留在待分配队列。它不发送消息，也不替任何人接受任务。

import assert from 'node:assert/strict';
function handoff(items) {
 const assigned=[],unassigned=[];
 for(const x of items) {
  if(!['need_info','need_review','bug_confirmed','unknown_result'].includes(x.state))throw Error('unknown_state');
  if(!x.next||!x.evidence)throw Error('incomplete_handoff');
  (x.owner?assigned:unassigned).push(x.id);
 }
 return {assigned,unassigned};
}
assert.deepEqual(handoff([{id:1,state:'need_info',next:'request environment',evidence:'issue/1'},
 {id:2,state:'bug_confirmed',next:'review fixture',evidence:'test/log',owner:'maintainer-queue'}]),
 {assigned:[2],unassigned:[1]});
assert.throws(()=>handoff([{id:3,state:'need_review',next:'',evidence:'issue/3'}]),/incomplete_handoff/);
console.log('handoff queue: ok');

本地运行输出：

handoff queue: ok

把结果未知单独交出去

写操作超时、队列确认丢失或补丁写入结果不明，不能用普通失败替代。交接里说明已经查询过什么、仍需核对什么，避免接手者直接重做。

交接完成的标志，是下一位能够据此继续判断；不是表格里所有格子都有漂亮颜色。项目暂停时也一样，应保留版本、未解决问题与可用替代路径。

适用范围与未测部分

只验证本地交接清单，没有读取真实Issue、指派人员、发送通知或执行补丁；测试中的队列与编号是夹具。

参考资料

• GitHub Webhook best practices
• Investigating unintended model actions（2026-10-09）