迁移AI编码代理：先拆分提议与应用，再取消旧工作区

当你准备取消付费的AI编码工作区、改用免费替代方案时，最危险的不是模型质量，而是那个仍能执行合并的自动化钩子。付费产品往往把"提议、审查、应用"视为一个受信任的连续动作，而免费替代品并不会继承这份信任。免费模型照样能写出有用的补丁，但执行器绝不能拿到推送补丁的凭证。

这篇迁移日记给出了一套可操作的方法论：把提议、审批、应用三件事拆开，分别指定负责人，用一个"失败即关闭"的校验器守住闸门，直到在真实任务上验证通过后，才删除旧密钥。

真正的遗留物是合并权限，不是提示词

迁移时，大多数人盯着提示词和模型表现，却忽视了真正危险的东西——那个仍然"知道如何合并"的脚本、工作流或 webhook。这类自动化此前信任的是厂商身份、稳定的工作区，以及旧界面里的那个审查点击。

一旦完成切换，同一套自动化就会信任"任何能把 diff 丢进被监听路径"的进程。如果你的免费服务器能写入那个路径，你就等于在没有旧审查机制的情况下，重建了旧的特权。

作者强调，你实际上在迁移三样东西，而只有其中一样应该搬到更便宜的主机上：

• 提议通道可以迁移，因为一份草稿 diff 还不是对默认分支的改动。
• 审批记录应该留在审查者手里——放进 pull request 或模型无法编辑的受保护文件。
• 应用凭证应该留在受保护的 CI 上，或交给某个人，直到你对真实任务做过比对。

关键建议是：在改动任何环境变量或 webhook 之前，把这三者的"负责人"写进日记。没有指定负责人的切换会退化成一段聊天记录，而当付费工作区关闭时，这段记录也会随之消失。你会在第一个糟糕补丁出现时想起这些名字，而不是在欢快的上线通告里。

Webhook 与 Git 钩子的权限继承机制

Webhook 是服务端触发的 HTTP 回调，当特定 Git 事件（如 push、pull request）发生时，代码托管平台（GitHub/GitLab 等）会向预设地址发送请求。Git 钩子（hooks）则是本地或服务端的脚本，在 pre-commit、post-merge 等生命周期节点自动执行。两者的共同危险在于：它们绑定的是路径与凭证，而非具体的调用方身份。付费 AI 工作区通常通过 OAuth App 或 Fine-grained Token 限定了写入范围，取消订阅后这些 token 会失效；但如果你的迁移脚本复用了一个权限更宽泛的 GITHUB_TOKEN，或者 webhook secret 从未轮换，则任何能向该端点发送合法签名请求的进程，都会继承原有的推送特权。这就是为什么作者强调"负责人"必须先于环境变量变更而存在——一旦旧 token 被撤销、新 token 填入，审计链就会断裂，而权限漏洞却可能已经打开。

第一步：清点所有能应用 diff 的路径

从一个干净的检出开始，搜索那些能把生成文本变成提交或部署的"动词"。此刻还不评判模型质量，只是找出那个可能比厂商关系存活更久的副作用。本地脚本和编辑器任务同样要纳入——笔记本上的钩子和托管工作流一样能在取消订阅后继续生效。

具体操作包括:

1. 在工作流与脚本中搜索 apply、merge、push 行为，把文件清单存进日记的"apply paths"小节，让后续的决策表有证据而非记忆：

git grep -nE 'git apply|gh pr merge|git push|patch -p' -- .github scripts || true

2. 列出代理进程可能读取的每一个密钥名，并标出任何能推送、部署或改动防火墙的名字。只读日志的密钥暂时可留，但能推送的密钥必须在日记里加粗标注。只记录名称、负责人和引用它的工作流文件，不要把密钥值抄进日记：

git grep -nE 'GITHUB_TOKEN|DEPLOY_KEY|SSH_KEY|API_KEY' -- .github scripts .env.example || true

3. 翻看近期的代理运行记录，确认在合并事件之前是否出现人工审查标识。如果日志从"diff 写入"直接跳到"已推送"，说明闸门早已缺失。
4. 在同一条笔记里同时写明回滚负责人和密钥负责人，包括能联系到对方的渠道。一个没有回滚负责人的免费服务器，不能替代你的 on-call 团队本就理解的付费代理。任一名字空缺，就先停下迁移，修好 runbook。

第二步：冻结一份新主机必须遵守的提议契约

作者为"提议"和"应用"分别定义了契约。一份有效的提议应携带：任务 id、基准修订版本（base revision）、统一格式的 diff，以及取自团队既有列表的风险标签。一份有效的应用则必须引用相同的任务 id、该 diff 的哈希值，以及一个与审查绑定的人类操作者。

核心原则鲜明：模型可以写提议，但模型不能写审批——哪怕补丁看上去又小又显然。

校验器应当保持"无聊"，并在任何必填字段为空、或操作者就是代理本身时"失败即关闭"。文中给出的 Python 示例校验器读取两个 JSON 文件，拒绝模型写的审批，仅当哈希匹配时才允许应用：

**diff 哈希校验的安全边界**

文中校验器使用 `SHA-256` 对 diff 文本做摘要，核心假设是：被审查者签字的字节集合，必须与最终被执行的字节集合完全一致。这一机制能防御两类典型攻击：其一是"审后替换"——代理在审批完成后悄悄修改 diff 内容再提交；其二是"路径混淆"——把一个已批准任务的审批文件挪到另一个任务的提议旁边。但哈希校验有明确的盲区：它只验证字节的完整性，不验证字节的语义安全性。一个 SHA-256 完全匹配的 diff，完全可能包含逻辑漏洞、错误的数据库迁移方向或被遗漏的权限检查。这也是作者在"绿灯之后仍然存在的局限"中强调"必须保留可执行测试"的根本原因——哈希是必要条件，而非充分条件。`base_rev`（基准修订）的锁定同理：若默认分支在审批期间向前移动，同一份 diff 应用到新 HEAD 上可能产生完全不同的语义结果，因此必须在提议生成时就用 `git rev-parse` 固定快照。
# Example checker. Label: unexecuted until you run it on your own files.
import hashlib, json, pathlib, sys

REQUIRED = ("task_id", "base_rev", "diff", "risk")

def proposal_digest(proposal):
    missing = [k for k in REQUIRED if not proposal.get(k)]
    if missing:
        raise SystemExit(f"proposal missing {missing}")
    if proposal.get("approved_by"):
        raise SystemExit("model must not set approved_by")
    return hashlib.sha256(proposal["diff"].encode()).hexdigest()

作者特别提醒：这是示例，需要你在自己的文件上运行并适配，而非日记声称已执行过的策略引擎。他建议先制造一次"故意的不匹配"作为首次测试——你应该先看到闸门失败，再去信任它的通过。

一个容易被忽视的坑是存储路径。提议应存放在执行器可写的位置，审批则应存放在执行器无法推送的路径上。即使校验函数在你笔记本上看起来很严格，一个权限松散的共享目录也会让整个拆分形同虚设。用 code owners 或独立的审批仓库，并确认代理 token 在尝试写入时会被拒绝。

第三步：只把提议写手指向免费方案

信息披露：原文声明本文作为 MonkeyCode 产品推广的一部分撰写。

按作者描述，运营方把 MonkeyCode 定位为一个开源项目，提供免费模型访问和一个用于"提议写手"的免费服务器选项。这个写手不应持有任何推送凭证，使用前你应在项目文档里确认当前条款。文中还坦诚提醒：不要复用旧聊天记录里的 token 额度数字，因为额度会变，而本文草稿并未核实过。

这里有一个重要的认知区分：可用性不等于质量结果，也不等于日志保留时长的承诺。免费选项应当被当作运行提议写手的地方，而不是"可以跳过审查"的证据。你的仓库规则在免费主机上依然生效，哪怕它不再给你开账单。

具体的切换节奏是:

1. 挑选三个你已经接受过的任务：一个低风险编辑、一个依赖升级、一个触及认证/计费/数据迁移的改动。
2. 保存付费运行的文件清单、基准修订和 diff 哈希，切换周内不要临时发明新任务。
3. 让同一任务跑一遍免费模型，只允许进程写出提议文件。
4. 比对路径和锁定的基准修订，而非周边解释——措辞会漂移，但范围不能变。
5. 等待期间不要从笔记本应用任何东西，让 CI 拒绝任务，直到审查者写出匹配的审批。

作者给出一条硬规则：出现在已保存清单之外的文件，就是"停"，即使预期文件上的测试全绿。范围漂移正是一次未审查的编辑如何通过一个"从未看过那个额外路径"的徽章。此外还要先锁定基准修订（git rev-parse origin/main），否则一个移动中的默认分支会让两边主机都显得"出错"。

Code Owners 与受保护分支的权限隔离原理

GitHub 的 CODEOWNERS 文件允许为特定路径指定强制审查者：任何涉及该路径的 Pull Request，在被列出的人员批准之前，分支保护规则会阻止合并。文中建议把"审批文件"存入 Code Owners 保护的路径，背后逻辑正是利用这一机制：即使代理 token 拥有仓库写权限，只要审批路径被 CODEOWNERS 保护且启用了"Require review from Code Owners"，代理就无法在没有人类审查者介入的情况下将包含审批文件的提交合并进主分支。更彻底的隔离是使用独立的"审批仓库"：提议仓库和审批仓库分开，代理 token 仅对提议仓库有写权限，对审批仓库只有读权限，执行器在合并前跨仓库验证签名。这样即使提议侧主机被完全攻陷，攻击者也无法伪造合法的审批记录。

第四步：删除付费密钥前，先读决策表

作者提供了一张决策表，并要求把它当作"闸门"而非事后浏览的摘要。任一单元格状态未知，就意味着应用流量必须继续留在旧路径上。

检查项	付费侧现状	免费侧要求	是否迁移应用？
Diff 写手	厂商代理身份	仅提议路径	仅迁移提议
审批写手	旧 UI 中的人类	代理无法推送的路径	否，直到强制生效
基准修订	工作区快照	base_rev 已锁定并核验	否，若 tip 会漂移
推送密钥	厂商作用域或受保护 CI	免费服务器上不存在	否，若密钥被复制
回滚负责人	旧 runbook 中已命名	同一负责人，更新链接	否，若名字空缺
三任务哈希比对	过去常被跳过	切换前已记录	否，直到日记中有记录

只有当"Diff 写手"和"推送密钥"两行都满足时，才迁移提议写手；只有当其余每一行都在三个保存任务上满足时，才迁移应用任务。作者的收尾话很冷静：多留一周付费密钥，比逆转一次没有审查者看过的合并要便宜得多。

绿灯之后仍然存在的局限

一个匹配的哈希只能证明"被批准的字节就是被提议的字节"，并不能证明这些字节上线是安全的。免费模型完全可能编辑了预期文件，却破坏了某个调用方、迁移或你忘记命名的权限检查。因此必须在任务上保留可执行测试，并保留一条可信路径，直到这些测试在新写手上也转绿。

示例校验器信任的是你的仓库权限来保护审批路径不被代理 token 触碰。如果那个 token 能推送该路径，闸门就是摆设，这种情况下根本不该迁移应用任务。

作者也划出了不适用人群：当前代理若能绕过 pull request 直接部署到生产；没有指定审查者会读高风险 diff；任务涉及密钥、客户数据或未公开漏洞细节；团队仍从笔记本应用补丁且无受保护 CI——这些场景都不应贸然切换。更便宜的账单不会放松你为付费代理已经接受的数据规则。

这篇日记不排名产品、不报告基准测试、不给出 token 价格或硬件规格。你那三个真实任务，才是决定"应用任务是否该迁移"的唯一证据。