把接口调试集合交给 Bruno 前，我会先拆清环境和秘密边界

团队刚开始整理 API 调试集合时，最容易把个人习惯带进仓库：请求路径、示例 body、测试脚本可以共享，真实 token、临时 host、个人账号 Cookie 也混在一起。短期看省事，等到新人拉仓库、CI 跑接口烟测、生产问题需要复盘时，这些混杂内容会变成风险点。我更愿意先把集合文件、环境变量、秘密值和执行入口拆清楚，再讨论工具体验。

原创示意图：把 Bruno API 集合治理拆成集合文件、环境变量、秘密值、本地 CLI 和 CI 报告五个环节。来源：Codex image generation

为什么这次看 Bruno

Bruno 的定位很适合这类轻量团队工作流。官方介绍把它描述为 local first、Git friendly 的 API client，集合保存在本地文件系统里，不要求把请求同步到云端账号。它使用 Bru 这种可读的标记格式来保存请求、变量和脚本，Git diff 能直接看到接口集合的变化。GitHub 仓库也公开维护，许可证、源码和 releases 都能核验，适合作为合法开源工具写进团队实践。

这个方向对 CorianderLab 的价值在于可审计。接口集合一旦进入仓库，它就不再只是调试快捷方式，也会变成文档、回归样例和协作契约。谁改了请求头，谁加了前置脚本，谁调整了环境变量名称，都应该能从代码评审里看见。

我会先拆的四条边界

第一条是集合文件边界。可以入库的是请求目录、Bru 文件、示例参数、非敏感默认值和测试断言。它们对应团队共同理解的接口契约，适合跟随业务代码一起演进。每个请求最好带上稳定命名，避免把某个人当天临时调试的 URL 直接保存成长期资产。

第二条是环境变量边界。BASE_URL、API_VERSION、TIMEOUT 这类值适合用环境模板表达，让本地、测试、预发和生产有同一组变量名。模板里保留说明和示例值，真实值由个人本地环境或 CI 注入。这样新人能快速知道需要哪些变量，又不会把真实访问入口写进集合文件。

第三条是秘密值边界。token、password、private key、session cookie 都应该留在受保护的位置。Bruno 有 secret management 相关能力，CI 侧也可以使用平台自带 secret 注入。关键原则是让请求引用变量名，运行时再解析真实值。代码评审里看到的是变量引用和用途，仓库历史里不留下密钥正文。

第四条是执行边界。手工点击请求和 CLI 批量执行服务于不同场景。本地调试关注定位问题，CI 执行关注可重复、可失败、可报告。把 CLI 命令固定成脚本后，可以先跑健康检查集合，再跑高成本或有副作用的集合。失败结果进入构建日志，接口集合就从个人工具升级成团队回归入口。