无论你使用的是云端大模型还是本地私有化部署，代码数据安全都不应完全依赖工具的默认设置。OpenCode 作为编码助手，必须能够读取当前文件甚至相邻文件的上下文才能给出准确建议，这也意味着开发者需要主动划定“哪些代码可以进入模型视野”。
1. 敏感代码不进云端上下文
在 2.2.1 和 2.3 节中提到的排除列表（Exclusion List）不是可选项，而是必选项。以下文件类型应坚决排除在索引和补全上下文之外：
- 密钥与凭证：
.env、*_key.json、.pem、.p12、Kubernetes Secret 清单。 - 个人隐私数据：包含用户手机号、身份证号、地址的枚举类或测试数据文件。
- 核心算法：加密 Salt 生成、签名算法、风控规则引擎等核心商业逻辑。如需 AI 辅助，建议先在本地脱敏为伪代码后再提问。
操作建议：在 IDE 的排除设置中使用通配符批量屏蔽（如
*/.env、/secrets/），并定期执行grep -r "sk-"或grep -r "password"扫描仓库，确认没有敏感字符串被意外索引。
2. API Key 与 Token 的保管
- 禁止硬编码：绝对不要在项目配置文件（包括
.vscode/settings.json、.idea目录下的 XML）中明文写入云端模型的 API Key。应使用环境变量（如OPENCODE_API_KEY）并在插件设置中以${OPENCODE_API_KEY}形式引用。 - 最小权限原则：为不同项目或团队成员分配独立的 Key，并开启服务商侧的用量上限与 IP 白名单。一旦某位成员离职或设备丢失，可单独禁用该 Key，而不影响整体服务。
- 定期轮换：建议每 90 天更换一次云端 API Key，并在公司内部建立轮换日历提醒。
3. 本地部署并非“绝对安全”
私有化模型虽然避免了代码外发，但仍需注意以下风险点：
- 模型推理日志：vLLM、Ollama 等框架默认可能开启访问日志，其中会记录请求体片段。应在服务端关闭详细日志（
--disable-log-requests或调整日志级别为WARNING），或确保日志存储路径受严格权限控制。 - 显存/内存残留：GPU 显存中的 KV Cache 不会长期保留上下文，但在多租户共享服务器上，建议通过容器或命名空间隔离不同用户的推理实例。
- 缓存文件：部分 IDE 插件会在本地磁盘生成索引缓存，离职或设备报废前需手动清理 IDE 缓存目录（VS Code 的
~/.config/Code/User/globalStorage/或 JetBrains 的~/.cache/JetBrains/）。
4. 团队与工作区隔离
若企业账号包含多个工作区（如“核心业务组”与“开源社区组”），务必确认当前 IDE 窗口登录的是正确的工作区。OpenCode 的计费、权限和审计日志通常按工作区维度统计，串区可能导致：
- 开源项目的代码上下文被误计入商业工作区的索引；
- 商业项目的 API 调用消耗开源社区的共享额度。
5. 审计与应急响应
- 定期审查 IDE 的 OpenCode 插件日志：部分版本在输出面板（Output → OpenCode）会记录请求的文件路径与大致 Token 数，借此可发现异常的文件访问。
- 发现误传后的处理：若确认敏感文件已被发送至云端模型，应立即：
- 吊销当前 API Key；
- 联系服务商确认该数据是否进入训练集（多数主流服务商承诺 API 数据不用于训练，但仍需工单确认）；
- 在代码仓库中轮换已泄露的密钥或凭证，切勿仅修改插件配置了事。
总结
OpenCode 的安全水位取决于最短的木板。再完善的本地模型，也可能因为一份被误索引的 .env 文件而泄露；再严密的云端协议，也挡不住在代码里写死的 API Key。将“代码分级”和“最小可用上下文”作为团队规范，比任何技术设置都更有效。