把“配置已改好”变成可核对的改动清单
准备让同事接手一份 OpenCode 配置时，只发一句“已经换成 AIGoCode”不够。更实用的交付物是两份去掉真实密钥的 JSON，以及一张说明新增、删除和值变化的清单。接收人由此能区分：哪些是本次有意修改，哪些是复制示例时顺带覆盖的内容。
本文提供一种人工复核工作流：先保存修改前后的脱敏副本，再用 AIGoCode JSON 对比 找字段差异，最后回到 OpenCode 验证。它不代替接入教程，也不把差异结果当作调用已经成功的证明。
第一步：留下两份可分享的副本
按照 OpenCode 接入文档，修改配置前先关闭正在运行的 OpenCode。Windows 全局文件在 %USERPROFILE%\.config\opencode\opencode.json，macOS/Linux 在 ~/.config/opencode/opencode.json。文档说明，这份全局配置会被不同启动方式共同读取，所以交接时也要记录实际修改的是哪一个文件。
建议在自己的电脑上保留修改前、修改后两份副本。分享或粘贴工具前，把两边 apiKey 都替换成同一段虚构占位文字，例如 REDACTED_KEY。这样既避免分享真实密钥，也不会让密钥字符串变化淹没其他配置差异。占位副本只用于比较，不能覆盖实际运行配置。
不要为了交接而收集他人的真实 Key。接收人应在自己的受控环境中，核对其 Key 所属分组与所选接入方式。本文没有执行读取或修改你电脑配置的操作。
第二步：先找变化，再判断是否符合原计划
AIGoCode Tools 目录 将 JSON 对比描述为“按字段路径检查两段 JSON 的新增、删除和值变化”。把它用于两份脱敏副本后，建议按下面的审核顺序整理结果。这张表是人工交付模板，并不是工具会自动判定配置正确的承诺。
| 需要复核的内容 | 在变化中查什么 | 交接说明怎么写 |
|---|---|---|
| 默认模型 | model 的旧值和新值 | 本次计划切到哪个来源和模型 |
| 服务商适配器 | provider 下的 npm | 接口格式是否随接入方式一起调整 |
| 请求地址 | options.baseURL | 地址是否对应当前教程的协议示例 |
| 可选模型项 | models 下的新增或删除 | 默认引用是否能在配置中找到对应项 |
| 其他配置 | 任何计划外新增或删除 | 是保留原状、主动清理，还是需要恢复 |
如果差异多到看不清，先缩小本次修改目标。不要把所有变化都解释成“接入所必需”，也不要只因 JSON 能解析就接受整份覆盖。
第三步：用当前文档核对协议相关字段
官方 OpenCode 页面分别提供 OpenAI、Claude 和 Gemini 的配置示例。当前 OpenAI 示例使用 @ai-sdk/openai 与 https://api.aigocode.dev/v1；Claude 示例使用 @ai-sdk/anthropic 与同一 /v1 地址；Gemini 示例使用 @ai-sdk/google 与 https://api.aigocode.dev/v1beta。
因此，比较时不能只盯着地址：即使两个示例地址相同，适配器也可能不同。默认模型写法还包含来源前缀，例如 OpenAI 示例为 aigocode/gpt-6-astra。模型项、适配器、地址和 Key 分组应按同一种接入方式整体核对，具体可用模型仍回到当前分组目录确认。
建议在交付说明中用三列记录“计划改动、实际差异、核对结论”。例如，本来只准备调整默认模型，却看到整个服务商配置被删除，就先解释或恢复这项计划外变化，再继续验收。这个例子是假设场景，不是已发生故障或实测结果。
第四步：把静态复核和实际验证分别签收
静态复核完成，说明你能解释文件变化；它还不能证明网络、密钥或模型调用可用。保存实际配置后，按官方说明重新打开 OpenCode，新建会话并发送一条消息。正常回复与 AIGoCode 用量记录中出现该请求，是文档给出的接入验证依据。
交接时可以分别记录：配置文件位置、修改目的、计划外差异是否处理、重开后的回复情况，以及用量记录是否对应本次请求。只分享必要的脱敏说明，不附真实 Key。
若验证失败，保留错误和这份改动清单，回到教程检查 Key 分组与请求地址；不要为消除差异而反复替换整份配置。对比负责把修改说清楚，实际调用则需要另行验证。