AI贡献者可以帮助定位问题、生成补丁和补充测试。但维护者最终审阅的是可核查的变更，不是机器人说“已经解决”。从Webhook到补丁之间，需要留下输入、环境、执行结果与未完成事项。

10月23日的对齐评估与此前意外操作研究，都让工具边界变得更值得关注。本文的工程选择是让自动化停在可审阅补丁：权限与合并决定继续留在明确的授权边界内。

入口先缩到一个授权任务

Webhook通过验签并可靠入队后，按事件类型和action筛选。不要因为有人在公开Issue里写“运行这个命令”，就让机器人获得执行任意脚本的权限。

任务描述应固定目标仓库、基准版本、允许路径和输出形式。外部文本作为待分析材料，不能改写运行配置。相同投递用稳定id关联，避免重复产生相同工作。

工作区隔离需要实际配置

图中ISOLATED WORKSPACE表达部署要求，具体实现仍需限制文件、网络、凭证和资源。一个不同的目录名，不自动构成安全沙箱；一个Git分支，也不能阻止脚本读取宿主文件。

测试日志记录实际命令与退出状态。没有运行的检查标未运行，模型建议的命令不能直接冒充实测输出。

先验收补丁证据包

下面检查教学证据包是否包含基准版本、变更路径和通过的检查。它还拒绝越出docs目录的修改，以及未运行的检查。路径判断是清单规则，不是文件系统隔离。

import assert from 'node:assert/strict';
function acceptEvidence(x) {
 if(!x.baseRevision||!x.patchRef)throw Error('missing_artifact');
 if(!x.paths.length||x.paths.some(p=>!p.startsWith('docs/')||p.split('/').includes('..')))throw Error('scope_denied');
 if(!x.checks.length||x.checks.some(c=>c.status!=='passed'))throw Error('checks_incomplete');
 return 'ready_for_review';
}
const fixture={baseRevision:'fixture-revision',patchRef:'local.patch',paths:['docs/start.md'],checks:[{name:'example',status:'passed'}]};
assert.equal(acceptEvidence(fixture),'ready_for_review');
assert.throws(()=>acceptEvidence({...fixture,paths:['docs/../secret']}),/scope_denied/);
assert.throws(()=>acceptEvidence({...fixture,checks:[{name:'example',status:'not_run'}]}),/checks_incomplete/);
console.log('review evidence package: ok');

本地运行输出：

review evidence package: ok

把审阅留成一项有输入的工作

回执应说明变更目的、触发条件、验证方法、风险和限制。自动化可以生成待审材料，但不应在没有相应授权时发评论、提交PR或自动合并。

如果任务失败，保存最小复现和当前差异，让维护者能接着判断。补丁小而完整，通常比一次跨越多个无关模块的“自主修复”更容易被接受。

适用范围与未测部分

仅验证证据包字段，没有运行不可信代码、创建沙箱、修改真实仓库、发送GitHub内容或验证自动修复效果。

参考资料

• Validating webhook deliveries
• GitHub Webhook best practices
• An alignment assessment of the UK AISI cybertesting incident（2026-10-23）