先确认对外提供的是什么
如果你准备让第三方通过自己的接口调用 AIGoCode，先核对许可，再安排上线。服务条款明确要求：未经事先书面许可，不得将本服务包装为下游 API 服务、聚合服务、转发服务或竞争性服务提供给第三方。使用政策也对 API、额度、账户、API Key 和模型访问能力的转售、出租、代理、共享及下游提供作出了规定。
对开发者来说，首先要说明实际的服务交付方式：谁持有凭据、谁发起请求、谁接收能力、对方最终拿到什么。是否把 Key 放在自己的后端，只回答了凭据存放问题，无法单独证明对外提供服务的用途已经获准。
下面是一份上线前的用途核对方法。它用于向 AIGoCode 说明你的方案，不自行认定某种产品形态已经获得许可。
一、画出从用户到模型的请求路径
不必先做复杂架构图，用一句话把路径写清楚即可。例如：“第三方客户请求我方接口，由我方服务使用 AIGoCode 凭据转发模型请求，再将结果返回客户。”
这个例子只是说明材料的写法，不代表该方案已被允许。描述中至少需要保留以下信息：
| 核对项 | 应写清的内容 |
|---|---|
| 使用方 | 谁拥有 AIGoCode 账户，谁是最终接收服务的第三方 |
| 入口 | 对方使用你的应用页面，还是能够调用你开放的接口 |
| 请求路径 | 请求由哪个系统接收，哪个系统访问 AIGoCode，结果交给谁 |
| 交付内容 | 对方拿到的是应用中的结果，还是可继续调用、转发或分发的能力 |
| 凭据 | 哪一方保管 Key，是否向第三方提供账户或凭据 |
特别留意产品文案与实际能力不一致的情况。即使页面称作“开发者工具”，如果实际开放了可由第三方调用的通用转发接口，向客服说明时也应写出这条路径，而不是只提供产品名称。
二、把凭据要求与服务许可分别检查
服务条款要求妥善保管账户密码、登录会话、API Key 等访问凭据，并禁止公开、共享、转售、转租、转授权或以其他方式向第三方提供 API Key。
因此，可以把核对分成两个问题：
- 凭据如何保管？ 是否会被写入公开代码、客户端可获取的配置或交给第三方使用？
- 能力如何对外提供？ 是否把 AIGoCode 的 API、额度或模型访问能力包装成下游 API、聚合、转发或其他对外服务？
即便不直接交出 Key，第二个问题仍需要根据实际用途确认；获得某项用途的答复，也不意味着可以忽略账户和凭据要求。具体的本地凭据整理可参考API Key 保存与泄露处理指南。
对于嵌入业务应用、定制功能、内部系统等具体方案，本文不提供“一律允许”的判断。应当完整描述用途并核对条款；存在不明确处时先取得适用范围的确认。
三、准备一份能得到明确答复的用途说明
建议向官方客服入口提供一份简短说明，避免只问“能不能商用”：
- 产品要解决什么任务，谁会使用它。
- 请求从哪里进入，最终调用由谁发起，结果会交给谁。
- 是否开放 API，是否允许客户继续转发、接入其他系统或提供给其下游。
- 是否涉及出售额度、转售模型访问、共享账户或交付 Key。
- 希望确认的使用范围，以及需要取得的书面许可。
无需把真实 Key 或生产密码放进这份用途说明。可以使用虚构标识描述请求路径，保留必要的业务信息，并询问还需要补充哪些材料。
这是一份建议的沟通清单，公开条款并未承诺固定的申请表、审批时限、许可价格或必然批准。不要把发出咨询、客服收到消息或接口测试成功当成书面许可已经取得。
四、把答复与实际上线范围对齐
收到答复后，建议由项目负责人核对：答复确认的是哪个产品、哪类用户、怎样的接口路径和交付方式。若需要书面许可，应确认已取得适用于该方案的许可，再安排相应上线。
项目以后从页面功能扩展为公开 API，或者增加了客户转发、分销、额度交付等路径时，建议重新核对原答复是否覆盖新的使用范围。这是项目管理建议，不代表 AIGoCode 提供某种自动续期或统一授权机制。
服务条款还说明，模型、接口、价格、额度、输出质量及第三方服务可能变化，并不保证持续可用。上线方案应结合当前产品页面、后台和适用条款检查，不能把一次请求成功推导成长期商业服务保证。
上线前保留这四项确认
- 已写清实际服务对象、请求路径和交付能力。
- 已分别核对凭据使用要求与下游服务许可。
- 对涉及下游 API、聚合、转发或竞争性服务的方案，已按条款取得适用的事先书面许可。
- 产品上线范围与已确认的用途一致；不清楚的部分仍先咨询。
如果当前任务只是选择客户端、协议和模型，可继续阅读第三方工具接入矩阵。技术接入配置和用途许可需要分别完成，本文依据的许可规则以服务条款与使用政策最新版本为准。