在几个仓库之间保留同一套编码代理配置

上午修改服务端，下午调整前端，随后回到公共组件库。几个仓库使用同一套编码代理，并不意味着它们应该共用所有设置。值得统一的是接入方式；需要分别保留的是项目约束、工作目录和验证步骤。下面把两种配置方式放在一起，看看差别实际落在哪里。

§ 接入配置：每仓库一份，还是用户级一份

逐仓库配置：每个项目分别设置服务地址、凭据来源和模型。独立性直观，也方便特殊项目使用不同供应商，但切换密钥或调整接入地址时，需要逐一检查，旧配置容易残留。

共享接入配置：在工具支持的用户级配置中维护共同设置，仓库只保留必要覆盖项。Vana API 的接入地址是 https://api.vanaapi.com，同时支持 OpenAI 兼容接口、Anthropic Messages 和 Gemini 原生协议，可以作为多个工具的共同接入服务。

这里统一的是服务入口，不是配置文件格式。Claude Code、Codex、Gemini CLI 仍需按照各自的配置方式接入；使用 OpenAI SDK 的脚本也应单独检查客户端参数。不要把一份工具配置直接复制给另一个工具。

逐仓库配置：把完整的通用规则复制到每个项目，初次设置简单，但时间一长，同一条规则可能出现几个版本。修改其中一份，并不会让其他仓库同步更新。

共享接入配置：把个人工作习惯留在用户级指令中，把构建命令、目录边界、测试要求留在仓库内。例如，前端仓库要求检查界面状态，组件库要求验证公共接口，两者不应被一份“通用测试命令”覆盖。

不同工具对指令文件的发现和优先级并不完全相同。共享原则可以一致，实际加载结果仍要逐个工具确认。

逐仓库配置：项目默认模型清晰，适合长期稳定的工作流。不过，仓库名称并不能决定任务难度；同一个仓库里，修改注释和调整模块边界需要的投入不同。

共享接入配置：先建立一个经过验证的默认选择，再为具体任务覆盖。例如，可以分别试用 Claude Sonnet 5.5 和 Gemini 2.5 Flash，比较它们在实际补丁上的测试结果、耗时和 token 消耗，而不是预设谁一定更适合某类工作。

统一入口能减少切换服务的配置成本，但不会消除模型之间的上下文、工具调用和输出行为差异。

逐仓库配置：如果配置文件进入版本控制，凭据就可能随提交扩散。即使文件被忽略，也要考虑日志、终端记录和复制项目时留下的副本。

共享接入配置：优先通过工具支持的环境变量或本机凭据存储提供密钥，仓库只记录不含秘密的配置说明。需要区分团队、环境或预算时，再单独规划凭据边界。

API 接入与本地执行权限是两回事。共用端点不应自动扩大代理读取文件、执行命令或访问其他仓库的范围。涉及生产环境和破坏性操作时，仍应保留明确审批。

逐仓库配置：项目边界容易辨认，但并不能保证代理理解当前分支、未提交修改和依赖状态。

共享接入配置：切换入口更方便，也更需要显式确认当前目录。进入另一个仓库后，应重新说明目标、检查工作区状态，并让代理读取该项目的指令。不要把上一项目的假设直接带进来。

如果一个任务跨越多个仓库，先分别列出修改范围与验证命令，再约定接口变化和提交顺序。共享配置不会自动提供跨仓库上下文，也不会自动解决依赖发布顺序。

逐仓库配置：可以按项目分别管理服务，但维护多套接入时，也需要分别核对计费方式和使用记录。

共享接入配置：Vana API 按实际 token 计费，没有月费。比较成本时仍应观察完整任务，包括重试、重复读取上下文和失败后的修复，而不只是一次请求。

可以先创建一个 Vana API 账户，在一个仓库里完成一次小修改，确认协议、工具调用和测试流程，再推广到其他仓库。最后留下两份简短记录：一份说明共同接入设置，一份说明各项目的例外。这样复用的是维护工作，而不是把项目差异藏起来。