很多人在国内想用海外模型，卡在两件事上：一是不知道哪些路子算合规、哪些随时可能被封；二是看到一堆中转、代充、订阅渠道，分不清该从哪一步开始判断。这篇不推具体渠道，只给一套能自己走的判断顺序——先分清用途和数据敏感度，再对照途径类型，最后确认哪些红线不能碰。
很多人卡在两件事上：一是不知道哪些路子算合规、哪些随时可能被封；二是看到一堆中转、代充、订阅渠道，分不清该从哪一步开始判断。这篇不推具体渠道，只给一套能自己走的判断顺序——先分清用途和数据敏感度，再对照途径类型，最后确认哪些红线不能碰。
顺序搞反是最常见的坑：先被某个便宜的渠道吸引，用起来了才想起来里面跑的是公司客户数据。所以下面每一节都按「先分类、再选路、后检查」的节奏来，你可以当成一份自查清单，从第一节往下逐条对。
第一步：先给用途和数据分类，再谈途径
选途径之前，先回答两个问题：你发出去的是什么数据，以及这是个人试用还是团队生产接入。这两栏写不清楚，后面选什么都是碰运气。个人试错成本低，团队接入一旦出问题，影响的是业务连续性和对外承诺。
| 数据敏感度 | 典型内容 | 能考虑的途径 | 不建议的做法 |
|---|---|---|---|
| 公开资料 | 公开文档、已发布内容、通用常识提问 | 官方订阅、官方 API、聚合平台都行 | 没有硬限制，但仍别用来源不明的免费代理 |
| 内部一般文件 | 内部流程草稿、非涉密技术笔记 | 官方 API、自建或托管推理 | 别走多人共用、无法追溯来源的渠道 |
| 涉个人信息或客户数据 | 客户名单、合同、身份信息、未公开财务 | 自建或托管推理、有明确数据处理条款的官方通道 | 不要经任何第三方中转，也不要贴进公开对话产品 |
- 按数据敏感度分三档：公开资料、内部一般文件、涉个人信息或客户数据，这三档能走的途径完全不同
- 按用途分两类：个人学习试用 vs 团队生产接入，后者的合规要求高一个量级，不能照搬个人经验
- 先写清楚这两栏再选路，否则容易用个人试用的方式去跑公司数据，这是最常见的踩线场景
- 团队场景额外加一条：确认谁有权发起调用、谁负责事后追溯，权限不清就先别接入
可用途径类型与各自的判断要点
途径大致分四类，各有各的判断重点。共同的一点是：任何一类都别只看「能不能用」，要同时看数据经几手、出问题谁负责、价格和额度是不是会随时变。数量和价格随时在动，一律到站内页面核对当时的数字，别记旧账。
- 官方直连 API
- 口径最清楚，但涉及账号地区、付款方式和跨境结算，得先确认你的主体和付款工具支不支持。
- 官方订阅类产品
- 适合个人日常对话，额度与地区价各家不同，到 /plans 和 /coding-plans 按当时的数字核对。
- 中转与聚合平台
- 便利性高，代价是数据多经一手，选之前先做可信度检测，参考 /sites 目录与 /tools/verify 的实测。
- 开源权重自建或托管推理
- 数据不出内网时优先考虑，但要看硬件和运维成本，用 /self-host 与 /rent-gpu-vs-api 先算账。
判断顺序建议是：先看这一类能不能满足你的数据边界要求，再看能不能满足用量和并发，最后才比较价格。反过来先比价，很容易选到一条数据链路说不清的渠道。
数据边界：哪些内容发出去之前要先过一遍
数据边界不只是「提示词里别写客户名」这么简单。你贴的附件、客户端本地缓存、第三方插件能读到的上下文，都在同一条链路上。做一次链路梳理，比背十条禁令有用。
- 列清单做一张「能发/不能发」清单贴在团队里，能发的写明白，不能发的（身份证号、合同原文、客户名单、未公开财务）直接禁止。
- 查链路从输入到返回逐段看：附件、缓存、插件、日志各读到什么，参考 /data-boundary-audit 的审计思路。
- 收权限团队共用账号或共用 Key 会放大风险，谁发的、发了什么难以追溯，权限要收窄，参考 /key-safety 与 /shared-key-risk-control。
- 留记录至少记录谁在什么时候用了哪条途径跑了哪类数据，出事时能复盘。
红线与早期信号：哪些用法风险高，怎么提前发现
红线本身不复杂，难的是提前发现。多数中断不是突然发生的，之前会有信号。看到信号先停手排查，别加量硬冲，这是省钱也省事的原则。
| 早期信号 | 可能原因 | 先做什么 |
|---|---|---|
| 突然被限速 | 触发了频控或风控 | 停掉批量任务，改用低频手动验证 |
| 要求补充验证 | 账号信息或付款方式存疑 | 按要求补充，同时在站内查同类渠道反馈 |
| 登录频繁掉线 | 地区或设备环境变化 | 固定环境再试，别反复切换网络登录 |
| 接口返回异常码 | 额度、权限或渠道状态变化 | 查 /ai-status 当期状态，再联系渠道方确认 |
- 高风险用法通常集中在：批量账号、异常高频调用、共享给多人、把模型能力包装成对外服务
- 出现限速、补充验证、掉线、异常码任意一条，就先停手排查，别继续加量
- 连带损失要提前想：账号被封往往连带付款方式、关联邮箱一起受影响，重要的东西别只绑在一个账号上
- 别把「一直没被封」当成「做法合规」，两件事不是一回事
照着走的选型顺序与落地检查表
把前面几节收成一条能照着走的顺序。核心是别跳步：先定用途和数据，再定途径类型，再看站内当时的价格与额度，然后做可信度和速度实测，最后定止损线。跳步的代价通常是接入了才发现数据不敢发，或者用到一半被断供。
- 定用途和数据用第一节的表格判断数据敏感度档位和用途类型，写下来。
- 定途径类型按第二节的四类途径对号入座，排除不满足数据边界的选项。
- 查当期数字到 /plans、/coding-plans、/price-watch 核对当时的价与额度，别用旧印象。
- 做可信度与实测参考 /sites 与 /tools/verify 看实测结果，再用 /tools/speed-test 量一次自己的网络基线。
- 定止损线备好备用途径、预算上限、谁拍板、出事找谁，参考 /first-call-prep-checklist 的思路。
- 小额上量用真实任务跑一遍再放量，看延迟、稳定性、账单口径是否对得上。
接入之后不是一劳永逸。价格、额度、地区限制都会变，定期去 /price-watch 和 /ai-status 按当期数据核对，比记几个月前的结论靠谱得多。
下一步先拿着第一节的表格把自己手头的用途和数据过一遍，再去 /sites 看渠道实测、去 /price-watch 核对当期数字，两件事做完再决定接哪条路。→常见问题
个人用海外模型，一定要走官方吗？
不一定。个人、低频、只处理公开信息时，中转或聚合平台更省事，但要先做可信度检测、确认它不转卖你的数据、价格口径说得清楚。涉及个人信息或准备长期依赖的，再考虑官方直连或自建，稳定性和可追溯性更好，代价是门槛更高。
用中转站访问海外模型，合规上要注意什么？
核心是数据别乱发、用途别越界。选之前看站点的资质说明、隐私条款和退款规则，去 /tools/verify 和 /sites 对照实测结果；不要把客户数据、合同原文往里丢；预算和止损线提前定，避免站点出事时余额和进度一起丢。
怎么判断一条途径是不是随时会断？
看几个信号：有没有明确的计费与退款条款、出问题时客服能不能说清、站点是否频繁换域名或改公告、额度是否突然收紧。任何一条都可能是风险信号，去 /detect-site-degradation 和 /announcement-change-response 的思路对照，别把全部业务压在一条路上。
