鱼鱼连线

鱼鱼连线官网,无需月费按token计费提供claude和gpt兼容接口支持主流工具

鱼鱼连线是什么?

鱼鱼连线是一个透明按量计费的人工智能模型api中转站网关与接口聚合平台，面向编程、开发、写作、聊天和图像生成等场景，用一个账号连接克劳德、开放人工智能、双子星、格罗克等主流模型，无需月费，按令牌用量付费，价格低至官方一折，新用户注册可获零点五美元试用额度。它支持在代码编辑器、智能编程助手、桌面客户端和命令行工具中接入，提供标准密钥分组、一键导入配置、复制可用命令、查询用量与账单等功能，帮助用户绕开官方账号、密钥、地址、模型路由和网络配置难题。平台强调不掺水、不换模型，不把低质模型冒充高价模型，并提供全天候响应、导入向导和故障排查指引，适合个人开发者、团队和重度人工智能工具用户低成本稳定调用多种模型，并支持多工具统一管理，还能参与充值抽奖和邀请积分活动，快速测试后按需充值。

鱼鱼连线官网: https://app.yylx.io/

>>点击这里注册送0.5美元体验额度

鱼鱼连线（YYLX）深度评测：一个 API Key 打通 Claude Code、Codex、Cursor 的 AI 模型中转网关

一、引言

2026 年的开发者工作台，大概是这样一幅画面：终端窗口里 Claude Code 正在重构一个遗留模块，IDE 里 Cursor 同步做着代码补全，桌面上还挂着 Claude Desktop 处理长文档，Cherry Studio 在后台跑着一批翻译任务，晚上回到家用 Codex CLI 继续跑自动化脚本。

工具越多，麻烦就越是指数级增长。你要为每一个模型家族单独注册账号，单独充值，单独记住一套密钥；写脚本时要在不同的 SDK 和协议风格之间来回切换；环境变量散落在 zshrc、config.toml、客户端设置面板里；到了月底想算一下这个月到底在模型上花了多少，发现账单躺在五个不同的后台，币种还不一样。

这不是个别现象。随着 AI 编程代理（Coding Agent）在 2025 到 2026 年成为开发者的日常工具，一个被反复提及的基础设施问题浮出水面：模型能力的调用入口，正在从”一个网站一个订阅”走向”一个网关统管所有客户端”。AI API 中转服务，也就是常说的 API Gateway 或 API Relay，正是从这个需求缝隙里长出来的。

鱼鱼连线（YYLX）就是这个赛道里定位非常清晰的一员。它不试图做一个更聪明的聊天机器人，而是把自己放在所有 AI 工具的下方，做那条安静的管道：统一的 API Key、兼容的接口地址、集中展示的模型广场、按量计费的账单。它的文档覆盖了 Claude Code、Claude Desktop、Codex CLI、Codex++、Cursor、Cherry Studio、WorkBuddy、CC Switch 等一长串真实在用的客户端，这在同类服务里并不多见。

这篇文章会从四个层面把鱼鱼连线拆开来看：它到底是什么、它最适合谁用、它的核心功能在实际操作中长什么样、以及它和市面上几类典型方案放在一起时，各自的取舍点在哪里。无论你是想给自己的多客户端工作流做一次减法，还是在为小团队寻找一个统一的模型调用入口，下面的内容应该都能提供可落地的判断依据。

二、什么是鱼鱼连线

鱼鱼连线（YYLX）是一款面向开发者与 AI 工具用户的 API 中转网关。它做的事情很直接：用一个账号、一个统一的 API Key 和一组兼容接口，把 Claude、GPT、Gemini、Grok 等主流模型家族的能力，接入你已经习惯的那些工具里。

你不再需要为每一个模型家族单独注册账号、单独充值、单独记一套密钥。在鱼鱼连线的控制台创建一个 Key，把 Base URL 换成一个兼容地址，填上控制台里展示的模型名称，Claude Code、Claude Desktop、Codex、Cursor、Cherry Studio、WorkBuddy 这些客户端就能直接开始工作。OpenAI 兼容的客户端通常填写 https://app.yylx.io/v1，Anthropic 风格的客户端则使用控制台给出的 Claude 专用地址。

它按量计费，没有月度订阅的门槛；每个客户端可以拥有自己独立的 Key，额度、速率、有效期都能单独控制；模型广场把可用模型、线路与倍率集中呈现，用量日志让每一次请求都有迹可循。

如果你每天都在多个 AI 客户端之间切换，或者团队里每个人都在各自的工具里调用模型，鱼鱼连线做的事情就是把这些散落的调用，收拢到一个安静、可控的入口——不喧哗，只是让你少配置几次。

1. 产品定位与核心机制

理解鱼鱼连线，关键是理解”网关”这两个字。它本身不训练模型，也不生产模型能力，它站的位置在模型提供商和你手上的客户端之间，承担三件事：协议转换、凭证管理、用量可视。

协议转换是它的技术底座。不同厂商的接口风格并不一致，有的走 OpenAI 那套 chat/completions 风格，有的走 Anthropic 的 messages 风格。鱼鱼连线同时提供两套兼容入口：面向 OpenAI 兼容客户端的是 https://app.yylx.io/v1，面向 Anthropic 风格的则是 https://app.yylx.io/v1/messages。这意味着同一个账号，既能喂饱 Cursor 这类典型 OpenAI 兼容客户端，也能喂饱 Claude Code 这种需要 Anthropic 配置的工具。

凭证管理是它的日常价值。官方文档里有一条被反复强调的建议：为每个客户端单独创建 API Key。这不是形式主义，而是把”一把钥匙开所有门”的风险拆解掉。你可以有 claude-code-mac、codex-work、cursor-desktop、cherry-studio-home 这样的命名体系，按工具查看消耗来源；万一某个客户端配置泄露，只需要禁用对应的那一把 Key，其他工具完全不受影响。

用量可视是它的信任基础。控制台里能看到余额、倍率、请求日志与错误信息，这对需要把控成本的团队来说，比”能不能用”更关键。

2. 它不是聊天机器人：与”套壳客户端”的本质区别

市面上大量所谓”AI 聚合平台”其实是一个聊天网站，你打开浏览器，输入问题，得到回答。鱼鱼连线走的是完全不同的路线——它没有前台聊天窗口，它把你已有的客户端变成前台。

这个区别在体验上差异巨大。聊天网站意味着你要把工作流搬到它的页面上，代码要在它的输入框里贴来贴去，文件要在它的界面上传下载；而鱼鱼连线的模式是：你继续用 Cursor 写代码，继续用 Claude Code 跑终端任务，继续用 Cherry Studio 管理对话历史，只是这些工具背后的模型调用地址指向了同一个网关。

这也解释了为什么它的文档写得像一本”接入手册”而不是一本”使用说明”。官方推荐第一次使用时的阅读顺序是：创建 API Key → 接入概览 → 选择你的客户端接入页面。它假设你已经有了工具，只是需要一个更好的供给端。

对开发者来说，这种定位的价值在于不改变肌肉记忆。学习成本最高的从来不是新功能，而是被迫迁移的工作流。鱼鱼连线选择不去挑战你的习惯，而是从下面把它接住。

3. 2026 年的最新动态

从近期的公开内容看，鱼鱼连线在产品方向上做了几件值得注意的事。

一是对 Coding Agent 工作流的持续加码。官方围绕 Claude Code、Codex、Codex++、Claude Desktop 分别写了独立的接入页面，每一页都包含前置准备、详细步骤、故障排查三段式内容。比如 Claude Desktop 的接入页面明确写了 macOS 下如何通过 Help → Troubleshooting → Enable Developer Mode 打开开发者模式，再通过 Developer → Configure Provider 填写网关地址与密钥；Windows 下则是通过 Tab 键定位左上角菜单图标后再进入同一路径。这种颗粒度说明他们真的在跟着用户的实际操作路径写文档。

二是与 CC Switch 的深度配合。CC Switch 是一个跨平台的 AI CLI 配置管理工具，能集中管理 Claude Code、Codex、Gemini CLI、OpenCode 等工具的 Provider 配置。鱼鱼连线把它写进了官方推荐路径里，支持一键导入配置，避免用户手改环境变量和 config 文件。这类”配置层”的协作，是网关类服务的自然延伸。

三是面向团队场景的能力补齐。从公开资料看，小团队是它明确服务的对象之一：为成员提供统一的 Key、额度和模型入口。配合 Key 级别的额度限制、速率限制与有效期，团队可以做到”一个账户、多把钥匙、各管各的账”。

三、目标客户和应用场景

1. 核心目标客户画像

鱼鱼连线的用户画像并不模糊。官方文档里直接列出了四类：开发者、AI 工具用户、小团队、运维用户。这四类人的需求差异很明显，值得拆开看。

开发者的典型需求是”在 Codex、Claude Code、Claude Desktop、Cursor 等工具中接入模型”。他们的痛点是配置繁琐、多平台密钥管理混乱。

AI 工具用户更关注统一管理。他们的诉求是”在 Cherry Studio 等客户端中统一管理模型”，不必为了换一个模型家族去开一个新账号。

小团队需要的是治理能力：为成员提供统一的 Key、额度和模型入口，同时能看清谁用了多少。

运维用户关注的是可用性与异常信号——可用性、余额、倍率和请求错误。他们要的不是”能不能调通”，而是”什么时候会出问题、出在哪里”。

用户类型	典型岗位/行业	核心需求	现有痛点	推荐指数
独立开发者	软件工程师、全栈开发、独立开发者	多客户端共用一个模型入口，降低配置成本	每个客户端配一套环境变量，换机器要重来	★★★★★
AI 工具重度用户	产品经理、内容创作者、研究员	在桌面客户端里自由切换模型家族	客户端里每接一家模型就要注册一次	★★★★☆
小团队负责人	创业公司技术负责人、研发组长	统一 Key、额度与模型入口，成员各管各的账	成员各自充值，团队无法统一结算与审计	★★★★★
运维/SRE	平台工程、基础架构	监控可用性、余额、倍率与错误率	缺少集中的调用日志与异常感知	★★★★☆
自动化工作流作者	数据工程、AI 应用开发者	用统一凭证驱动多模型流水线	多套 SDK 与鉴权逻辑维护成本高	★★★★☆
单一客户端轻用户	偶尔使用某一家官方客户端的用户	快速获得一次对话体验	无	★★☆☆☆

2. 典型应用场景一：多客户端并行开发

这是最典型的场景，也是最容易立刻感受到收益的场景。

设想一位后端工程师的日常：上午用 Claude Code 在终端里做一次较大规模的重构，它会反复读文件、调用工具、修改代码、跑测试，属于典型的长会话、高频请求负载；下午切到 Cursor 写新功能，靠补全和对话交替推进；中途还要用 Claude Desktop 处理一份几十页的技术方案，做摘要和结构化整理。

在没有网关的情况下，这位工程师需要至少维护两到三套凭证与配置：Claude Code 需要 Anthropic 风格的地址和密钥，Cursor 需要 OpenAI 兼容风格的地址和密钥。换一台机器，全部重来一遍。

接入鱼鱼连线之后，操作变成：先在控制台为每个工具创建独立 Key，命名清晰（比如 claude-code-mac、cursor-desktop），然后按官方文档分别填写配置。Claude Code 走控制台展示的 Claude/Anthropic 配置，Cursor 走 https://app.yylx.io/v1 这个 OpenAI 兼容地址。此后无论换工具还是换机器，只需要重新填一次 Base URL、Key 和模型名这三个值。

更实际的一点是成本可归因。因为每个客户端一把 Key，控制台的用量日志可以按 Key 区分来源。你可以清楚看到”这个月的消耗主要来自 Cursor 补全还是 Claude Code 长会话”，这对优化工作流很有帮助——比如发现某个工具的回请求量异常高，就可以针对性地调整使用方式，而不是笼统地觉得”模型好贵”。

环节	传统多平台方式	使用鱼鱼连线
注册账号	每个模型家族一个账号	一个账号
充值	多平台分别充值，币种可能不同	一个余额
凭证	多套密钥，易混淆	多把 Key，同一来源，命名可控
客户端配置	每个工具填不同地址	统一网关地址 + 按协议选择入口
用量统计	分散在多个后台	集中日志，可按 Key 归因
Key 泄露处置	需要去对应平台处理	直接禁用该 Key，其他工具不受影响

3. 典型应用场景二：小团队的统一模型入口

团队场景里，问题会从”配置麻烦”升级为”治理缺位”。

一个十人左右的小团队，如果有人用 Claude Code、有人用 Cursor、有人在写自动化脚本，最常见的状态是：每个人自己注册、自己充值、自己保管密钥。月底报销的时候，财务收到的是一堆金额不等、币种不同、难以核对的账单；安全上，你甚至不知道有多少把密钥流落在多少个本地文件里。

鱼鱼连线的团队用法是把这件事结构化：一个账户 + 多把 Key + Key 级限制。创建密钥时，控制台允许填写名称、选择分组，并按需开启额度限制、速率限制和密钥有效期。

这带来几个直接好处：

• 成员隔离：每个成员或每台设备一把 Key，比如 alice-dev。谁的使用量高，用量日志里一目了然。
• 风险收敛：某台设备遗失或某个成员离职，禁用对应 Key 即可，不需要全队重新配置。
• 预算可控：给临时项目或不常用设备设置一个小额度，即使出现异常消耗也有上限兜底。
• 临时授权：给短期协作的 Key 设置过期时间，到期自动失效，不必依赖人工回收。

官方文档里有一条明确的判断标准：个人测试可以先不限制，给临时项目、团队成员或不常用设备时，建议设置一个小额度。这是很务实的建议——权限设计的目的不是限制人，而是让失控的成本可控。

4. 典型应用场景三：桌面客户端里的统一模型管理

第三类场景更偏向”AI 工具用户”，而非纯开发者。

很多人的日常工作台上有 Cherry Studio、Claude Desktop 这类桌面客户端。它们功能完善，但一个共同的问题是：每接入一个新的模型家族，就要重新走一遍配置流程。

鱼鱼连线的做法是让桌面客户端把这些配置收敛到一处。以 Claude Desktop 为例，官方文档给出了非常具体的路径：先启用开发者模式，再通过 Developer → Configure Provider 打开配置面板，填入网关地址 https://app.yylx.io 和 API Key，点击 Apply locally，然后选择 Relaunch now 重启，重启后点击 Continue with gateway 进入主界面。进入主界面后，Command + 1 切到 Cowork 视图（默认），Command + 2 切到 Coding 视图。

这套流程的价值在于：一旦配好，后续在这个客户端内切换模型，只是在网关支持的模型列表里选择，而不是重新做一次 Provider 接入。对于需要”同一天里用不同模型处理不同任务”的用户，这节省的是反复配置的心力。

场景	使用方式	预期效果	上手难度
终端编码代理	配置 Claude Code / Codex CLI 的 Base URL 与环境变量	长会话稳定运行，用量可追踪	中等
桌面客户端	在 Claude Desktop / Cherry Studio 中配置网关 Provider	一个客户端内切换多模型	低
IDE 辅助开发	Cursor 等工具填写 OpenAI 兼容地址	补全与对话共用一套凭证	低
团队协作	一账户多 Key，配额度与有效期	成员隔离，成本可归因	中等
自动化脚本	使用 /v1 接口直接调用	多模型流水线共用鉴权	中等
配置集中管理	通过 CC Switch 一键导入	多 CLI 工具配置集中维护	低

5. 不适合哪些人？

诚实地划定边界，比无差别推荐更有价值。鱼鱼连线的设计目标是”让已有工具的用户获得更统一的模型供给”，因此有几类用户其实不需要它。

第一类，只使用单一官方客户端、从不自定义 Provider 的用户。 如果你全程只在某一个官方客户端里完成所有工作，且未来也不打算切换或增加工具，那么直接使用该客户端的原生登录方式是最省事的路径。鱼鱼连线擅长的是”多工具统一”，而不是”单工具替代”。

第二类，完全不接触配置的技术使用者。 鱼鱼连线的接入方式虽然被文档简化到了”填三个值”，但它依然需要你去编辑 ~/.codex/config.toml，或者在客户端里找到 Provider 配置面板。如果你完全不希望接触任何配置项，那么它带来的收益会小于你的操作成本。

第三类，只想聊天、不需要工具链的人。 网关的价值在于把模型能力送进各种工具，如果你需要的只是一段对话，那么直接使用任意一个成熟的对话产品即可。

反过来讲，只要你的工作台上同时存在两个以上的 AI 客户端，或者你需要为团队提供一个统一的模型调用入口，鱼鱼连线的适用性就开始显现，而且工具越多，收益越明显。 它是一个典型的”规模效应型”工具：接一个客户端是尝鲜，接三个客户端是效率，接成团队的统一入口则是治理能力。

四、核心功能深度拆解

1. 杀手级功能一：双协议兼容入口

鱼鱼连线最底层、也最关键的能力，是同时维护两套兼容入口。这听起来技术性很强，但它直接决定了”你的工具能不能接上”。

具体来说，官方文档中明确的信息是：

• OpenAI 兼容地址：https://app.yylx.io/v1
• Anthropic 兼容地址：https://app.yylx.io/v1/messages
• API Key：在控制台创建，区分平台，格式以控制台展示为准（形如 sk-...）
• Model：控制台模型列表中的模型名称，模型列表位于 /model-plaza
• 服务状态：查看控制台公告或独立状态页

这两套入口的存在，解决了一个非常具体的痛点。市面上大量工具是按 OpenAI 的接口风格设计的，你给它一个 Base URL、一个 Key、一个模型名，它就能工作；而 Claude Code 这类工具走的是 Anthropic 风格的配置路径，需要的地址形态不同。很多用户在接入过程中踩的第一个坑，就是把 OpenAI 兼容地址盲目粘贴进 Anthropic 客户端，结果自然是连不通。

鱼鱼连线的处理方式是把这件事在文档层面讲清楚：OpenAI 兼容的客户端使用 /v1，Claude Code 使用控制台展示的 Claude/Anthropic 配置。这种”按协议分流”的设计，让不同类型工具的接入路径互不干扰。

操作步骤（以 OpenAI 兼容客户端为例）：

1. 登录控制台，进入「我的账户」下的「API 密钥」页面。
2. 点击「创建密钥」，填写名称（建议包含工具名，如 cursor-desktop），选择分组。
3. 创建成功后立即复制保存——Key 通常只完整展示一次。
4. 在目标客户端中填入 Base URL https://app.yylx.io/v1、刚才的 Key，以及控制台模型列表中的模型名称。
5. 发送一次测试请求确认配置生效。

官方还提供了一个最简验证方式，用一行命令就能判断 Key 和地址是否可用：

curl https://app.yylx.io/v1/models \
  -H "Authorization: Bearer sk-your-api-key"

如果返回模型列表，说明凭证与地址基本可用。如果失败，官方给出的排查清单有四条：Key 是否完整（不要漏字符、不要带多余空格或换行）、分组是否可用（分组需要启用且包含你要调用的模型）、余额或额度是否充足、Base URL 是否为 https://app.yylx.io/v1。这四步覆盖了绝大多数接入失败的原因。

使用技巧： 特别注意 base_url 的边界。官方在 Codex 的接入文档里专门提醒，base_url 应该停在 /v1，而不是 /v1/chat/completions 或 /v1/responses。这是一个非常容易犯的错误——很多人习惯性地把完整路径贴进去，结果报网络或 API 格式错误。

客户端类型	应使用的地址	协议风格	典型工具
OpenAI 兼容客户端	https://app.yylx.io/v1	OpenAI 风格	Cursor、部分桌面客户端、自定义脚本
Anthropic 风格客户端	https://app.yylx.io/v1/messages	Anthropic 风格	Claude Code、Claude Desktop 的 Claude 配置
Codex CLI	https://app.yylx.io/v1（wire_api = "responses"）	Responses 风格	官方 Codex 命令行
Codex++ 桌面增强	https://app.yylx.io（上游协议选 Responses API）	Responses 风格	Codex++ 管理器
配置管理工具	由 CC Switch 自动写入	视目标工具而定	CC Switch

2. 杀手级功能二：主流工具的一站式接入路径

如果说双协议入口是地基，那么”针对每个客户端的独立接入文档”就是鱼鱼连线真正拉开体验差距的地方。

它的接入覆盖范围包括：Claude Code、Claude Desktop、Codex CLI、Codex++、Cursor、Cherry Studio、WorkBuddy，以及通过 CC Switch 的统一配置管理。每一条路径都有独立的页面，而不是丢一篇通用文档让你自己翻译。

以 Claude Desktop 为例，完整流程是：

前置准备需要三样东西：已安装并至少打开过一次的 Claude Desktop、在控制台创建的 API Key（建议命名为 claude-desktop）、网关地址 https://app.yylx.io。

macOS 下的步骤是：打开客户端 → 顶部菜单栏点击 Help → Troubleshooting → Enable Developer Mode → 在确认框点击 Enable，客户端会自动重启。重启后先不要登录，菜单栏会出现 Developer 菜单，点击 Developer → Configure Provider 打开配置面板，填入网关地址与 API Key，点击右下角 Apply locally，在确认框选择 Relaunch now。重启后点击 Continue with gateway 进入主界面。此后 Command + 1 切换到 Cowork 视图，Command + 2 切换到 Coding 视图。

Windows 下的差异主要在打开开发者菜单的方式：在欢迎界面的邮箱输入步骤，按 Tab 移动焦点直到左上角菜单图标被选中，按 Enter 打开菜单，选择 Developer → Configure third-party interface，其余填写与重启流程一致。

官方还附了三条故障排查：配置后连不上，先检查 Gateway URL 是否以 https:// 开头、Key 是否完整有效；配置后没变化，确认是否点击了 Apply locally 并完全退出重开；出现认证错误，重新从控制台复制 Key 并检查是否带入了多余空格。日志里看不到请求，通常意味着客户端仍在用官方登录或另一个 Provider，而不是走网关。

以 Codex CLI 为例，走的是配置文件路线：

第一步设置环境变量：

export YYLX_API_KEY="sk-your-api-key"

长期使用的话，把它加进 ~/.zshrc 或 ~/.bashrc，然后 source ~/.zshrc 使其生效。用 echo $YYLX_API_KEY 确认当前终端能读到变量。

第二步编辑 ~/.codex/config.toml：

model = "your-model-name"
model_provider = "yylx"

[model_providers.yylx]
name = "yylx.io"
base_url = "https://app.yylx.io/v1"
env_key = "YYLX_API_KEY"
wire_api = "responses"

其中 model 换成控制台模型列表中展示的名称，model_provider 是默认使用的 Provider ID，base_url 是 OpenAI 兼容地址，env_key 是 Codex 读取密钥的环境变量名，wire_api 是 Codex 使用的 API 风格。

验证环节，官方建议两边对照：在 Codex 终端看是否有正常响应或认证、未知模型类错误；在控制台的用量日志里看刚才那次请求有没有出现。如果用量日志里没有记录，通常说明 Codex 没用上该 Provider，或者当前终端读不到环境变量。

一个重要的版本兼容提示： 如果认证错误只在把 Codex 升级到 0.149.0 或更高版本之后出现，那通常不是 Key 的问题。新版本不再允许自定义 Provider 自动继承 ~/.codex/auth.json 中的凭证，除非启用 requires_openai_auth。而上面这种通过 env_key 显式指定环境的做法不受该变更影响，属于更稳妥的路径。

Codex++ 用户的路径又不一样。 Codex++ 是 Codex 桌面版的第三方增强启动器，接入方式是走它的 Provider 配置：在管理器侧边栏点击「供应商配置」，确认顶部「启用供应商配置切换」已勾选，点击「添加供应商」，选择「从预设模板创建」，用官方 OpenAI 模板，填入名称（如 YYLX）、访问模式选纯 API、Base URL 填 https://app.yylx.io、Key 填控制台创建的密钥、上游协议选 Responses API，然后点击模型列表旁的「从上游获取」拉取模型，保存后用「测试」按钮发一次 hi 请求，返回 HTTP 200 说明配置可用，最后点「使用」切换到该配置。

工具	配置入口	关键字段	支持 CC Switch 一键导入	上手难度
Claude Code	控制台展示的 Claude/Anthropic 配置	专用地址 + Key + 模型名	支持	低
Claude Desktop	Developer → Configure Provider	Gateway URL、Gateway API Key	不适用	低
Codex CLI	~/.codex/config.toml	base_url、env_key、wire_api	支持	中等
Codex++	管理器 → 供应商配置	Base URL、Key、上游协议	不适用	低
Cursor	客户端自定义模型设置	OpenAI 兼容地址 + Key	支持	低
Cherry Studio	客户端模型服务设置	OpenAI 兼容地址 + Key	支持	低
WorkBuddy	客户端 Provider 设置	按文档填写	支持	低

3. 杀手级功能三：精细化的 Key 治理

密钥管理是容易被低估的功能，但它决定了这套方案在团队里能不能长期跑下去。

鱼鱼连线在「创建密钥」弹窗里提供了多个控制项，最少只需填写名称并选择分组，其余限制项按场景开启：

名称：填写能看懂用途的名字，比如 macbook-codex、cursor-work、cherry-studio-home。官方给出的命名建议覆盖了 Codex CLI、Claude Code、Cursor、Cherry Studio 和团队成员五类场景。

分组：选择要使用的模型线路或套餐分组。不同分组的倍率、可用模型可能不同，以控制台展示为准。这一点很重要——分组不只是分类标签，它直接影响你能调用哪些模型、以什么倍率计费。

额度限制（可选）：个人测试可以先不限制；给临时项目、团队成员或不常用设备时，建议设置一个小额度。

速率限制（可选）：只有在需要限制并发、避免某个工具异常消耗时才开启。

密钥有效期（可选）：临时测试 Key 建议设置过期时间；长期使用的本机工具可以保持永久有效。

一个特别值得记住的提示： 官方不建议开启「自定义密钥」，除非你明确知道为什么要固定 Key 字符串。自动生成的 Key 更安全，也更不容易与旧配置混淆。这是很专业的建议——固定字符串的诱惑在于”方便记忆”，但它牺牲的是熵值和可轮换性。

保存环节同样有明确规范：创建成功后立即复制保存，因为 Key 通常只完整展示一次。如果忘记保存，请删除旧 Key 后重新创建。存储位置上，官方建议存到密码管理器、系统钥匙串，或只在本机可读的环境变量中，不要写进公开仓库、截图、聊天记录或共享文档。

后续维护上，官方建议定期清理不用的 Key。长期不用、用途不明、疑似泄露的 Key 都应该禁用或删除。删除后，已经配置到客户端里的旧 Key 会立即失效，需要重新创建并更新客户端配置。

控制项	说明	典型用法	建议
名称	密钥标识	codex-macbook、alice-dev	必填，包含工具或人名
分组	决定可用模型与倍率	按线路选择	按需，以控制台展示为准
额度限制	限制该 Key 可用额度	临时项目、团队成员	非个人设备建议设置
速率限制	限制并发与消耗速度	防止异常高频请求	按需开启
有效期	到期自动失效	临时测试、短期协作	长期本机工具可设为永久
自定义密钥	固定 Key 字符串	特殊集成场景	一般不建议开启

4. 差异化特色功能：模型广场与用量可观测性

在同类服务中，鱼鱼连线比较突出的差异点在于把”能调什么、花了多少、错在哪里”这三件事放在同一处可见。

模型广场（/model-plaza）集中展示可用模型，让用户在配置前就知道有哪些模型名可以填写。这解决了一个非常实际的摩擦：很多工具要求在配置文件中手写模型名，写错一个字符就会得到”未知模型”错误，而模型广场提供了一个准确的名称来源。官方在多个接入页面都强调”模型名称要与控制台展示的完全一致”。

用量日志是另一个被反复使用的验证工具。文档中在 Claude Code、Codex、Codex++ 等页面都给出了同一个双重验证法：一边看客户端是否正常响应，一边看控制台的用量日志里是否出现了刚才那次请求。这是一个非常聪明的排障设计——当客户端报错时，你无法判断问题出在本地配置还是链路；而用量日志提供了”请求是否到达网关”这个关键分界点。如果请求出现在日志里，说明凭证和地址都对，问题在模型名或参数；如果没出现，问题就在本地配置或终端环境变量。

倍率与余额的透明呈现，则让成本预期变得可管理。官方博客在对比文章中强调”按量计费、无月度订阅压力”这一点，并建议用户在生产决策前查看实时的模型与定价页面。这种”先看实时页面再决定”的表述，本身就是一种对用户负责的态度。

能力	鱼鱼连线	传统多平台账户方式
模型名称来源	模型广场集中展示	分散在各平台文档
用量归因	按 Key 区分来源	按平台区分，颗粒度粗
排障路径	客户端 + 用量日志双重验证	依赖各平台日志，标准不一
余额查看	一个账户一处查看	多平台多处查看
配置集中	CC Switch 一键导入	手工维护多份配置

5. 针对高级用户的隐藏技巧

除了文档里明写的步骤，实际使用中还有一些能让体验更顺滑的做法。

技巧一：Key 命名即监控体系。 把命名规范固定下来——claude-code-mac、claude-code-win、codex-work、cursor-desktop，坚持一段时间后，控制台的用量日志自然变成了一张资源分布图。你会清楚地知道消耗来自哪个工具、哪台设备。这比事后回忆”这个月我都干了什么”高效得多。

技巧二：用 CC Switch 做配置中枢。 官方把 CC Switch 放在推荐路径里，原因很实在：它是跨平台的 AI CLI 配置管理工具，能集中管理 Claude Code、Codex、Gemini CLI、OpenCode 等工具的 Provider 配置，把 Base URL、API Key、模型名称统一保存，让你在多个 CLI 工具或多套 Provider 之间一键切换，避免反复修改环境变量或配置文件。如果你同时在用三个以上命令行工具，这一步能省下大量重复劳动。

技巧三：区分”本机常驻”与”临时授权”两类 Key。 本机工具用永久有效的 Key，方便省心；给临时项目、协作者、不常用设备创建带有效期和小额度的 Key，用完即弃。这套组合把”便利”和”安全”分配到了不同的场景里。

技巧四：先小后大验证。 官方在 Codex 和 Codex++ 的文档里都建议，首次接入时先发一个轻量请求——比如让模型打印它自己配置的模型名，或给出一行摘要。这个动作成本极低，却能立刻确认整条链路是否通畅，避免把问题留到一次耗时的长会话里。

技巧五：留意 wire_api 与版本变化。 Codex 这类工具的配置字段会随版本演进，官方明确提示升级 Codex 后值得重新检查配置文件格式。保留一份可用的配置备份，在升级前后对比，是很省心的习惯。

技巧六：终端变量不要贴进聊天窗口。 官方在 Codex 文档里提醒不要把手写完整 Key 粘贴到公开聊天或 issue 中。用 echo $YYLX_API_KEY 确认变量”非空”即可，不需要看到完整值。

技巧	操作	带来的收益	适合人群
命名规范	按工具+设备命名 Key	用量自动形成分布图	所有人
CC Switch	一键导入与管理配置	多 CLI 工具切换零手工	多工具用户
分类密钥	常驻 Key + 临时 Key	便利与安全兼得	团队、外包协作
轻量首测	先发一行摘要请求	快速定位链路问题	所有人
备份配置	保存可用配置文件	升级后可快速回滚对比	Codex 用户

6. 功能完整度评估

把上面这些能力汇总成一张清单，可以更清楚地看到鱼鱼连线覆盖了什么。

功能模块	支持情况	具体说明	替代方案
OpenAI 兼容接口	支持	https://app.yylx.io/v1	—
Anthropic 兼容接口	支持	https://app.yylx.io/v1/messages	—
多模型家族接入	支持	Claude、GPT、Gemini、Grok 等	—
模型列表展示	支持	模型广场 /model-plaza	—
多 Key 管理	支持	每客户端独立 Key	—
Key 额度限制	支持	创建时可设置	无
Key 速率限制	支持	创建时可设置	无
Key 有效期	支持	临时 Key 可设过期	无
分组与倍率	支持	分组决定线路与倍率	—
用量日志	支持	控制台查看请求记录	—
服务状态查询	支持	控制台公告或状态页	—
CC Switch 一键导入	支持	覆盖多个 CLI 工具	手动配置
Claude Desktop 接入	支持	独立接入文档	手动配置
Codex++ 接入	支持	管理器图形化配置	手动配置
按量计费	支持	无月度订阅要求	—

从这张表可以看出，鱼鱼连线的功能布局是围绕”接入”与”治理”两条线展开的：接入侧覆盖了当前主流的 Coding Agent 与桌面客户端，治理侧覆盖了密钥、额度、速率、有效期与日志。对绝大多数个人开发者和中小团队来说，这套组合已经覆盖了日常工作流的完整闭环。

五、真实使用体验与深度测评

1. 交互体验与UI设计

鱼鱼连线的控制台设计思路，和它的产品定位高度一致：信息密度服务于操作，而不是服务于展示。

进入控制台后，左侧菜单结构清晰，「我的账户」下的「API 密钥」是使用频率最高的页面。页面右上角可以刷新列表，也可以点击「创建密钥」新增 Key。整个创建流程被压缩在一个弹窗里：最少只需要填写名称并选择分组，其他限制项按需开启。这种”默认简洁、需要时展开”的设计，避免了新手被一堆参数吓退，同时也没牺牲高级用户需要的控制力。

密钥列表的设计考虑到了实际使用场景。官方特别提到，如果列表中已经有旧 Key，也不要直接复用到所有工具，更推荐按工具新建。这个建议被写进文档而不是埋在帮助中心，说明设计者理解用户的真实操作习惯——大多数人确实倾向于”一把钥匙走天下”，而这恰恰是后面所有麻烦的源头。

「使用密钥」按钮是一个很贴心的细节。点击后，控制台会展示对应的环境变量和配置片段，直接可复制。对 Claude Code 这类需要填写特定环境变量的工具，这省去了”看文档 → 手动拼写 → 校验拼写”的往返。如果目标是 CC Switch，还有独立的「CC Switch」入口走一键导入。

用量日志页面则是排障时的主战场。文档在多个接入页面都把”看用量日志”作为验证步骤，说明这个页面在实际使用中承担了很重的角色。它的存在让”请求发出去了吗”这个问题有了明确答案。

Claude Desktop 的接入体验值得一提。启用开发者模式后，客户端会出现 Developer → Configure Provider 面板，填入网关地址与 Key，Apply locally，重启，然后 Continue with gateway。这套流程被官方写成了带截断式确认的步骤，包括”重启后先不要登录”这样的细节提醒——这些细节恰恰是用户最容易卡住的地方。

2. 性能与响应速度实测

从链路结构上看，鱼鱼连线位于客户端与上游模型之间，请求路径是：客户端 → 网关 → 上游模型 → 网关 → 客户端。这意味着网关的转发效率直接影响体验。

实际使用中，比较能体现设计水平的几个环节是：流式输出是否顺畅、工具调用（Tool Calls）是否正常传递、长会话是否稳定、用量记录是否实时。

官方在多个文档页面给出了同一个验证清单，实质上就是这四个维度的自测方法：确认流式输出、确认工具调用、确认响应质量、确认用量记录出现。官方博客在讨论 Coding Agent 负载时也专门指出，一次长会话可能会检查大量文件、反复调用工具、重新生成上下文、修改代码并运行测试，对这种使用强度而言，线路稳定性、协议兼容性和成本可见性，比偶尔聊一次的体验更为重要。

关于接入后的响应情况，一个实用的观察方法是：在首次配置完成后，按官方建议先发一个轻量请求（比如让模型输出自身模型名或一行摘要），通过后再逐步加大任务复杂度。这样可以把”链路问题”和”任务本身的问题”分离开，定位效率会高很多。

另外值得肯定的是排查指引的完备度。以 Codex 为例，官方给出了三类典型问题的对应解法：认证错误先检查终端能否读取环境变量、未知模型错误要确认模型名与控制台完全一致、网络或 API 格式错误要检查 base_url 是否停在 /v1。这种”症状 → 原因 → 动作”的结构，把排障从玄学变成了流程。

3. 鱼鱼连线核心优势

把使用体验汇总起来，鱼鱼连线的核心优势可以归纳为以下几点：

第一，接入路径的清晰度。 它不是给出一个通用接口让你自己摸索，而是为每个主流客户端写了独立的接入页面，包含前置准备、逐步操作和故障排查。对用户来说，这意味着”照着做就能通”，而不是”理解原理再自己推导”。

第二，双协议并存的兼容性。 同时提供 OpenAI 兼容地址与 Anthropic 兼容地址，让不同类型的客户端都能找到自己的入口，不需要为了用一个网关而更换工具。

第三，密钥治理的颗粒度。 额度限制、速率限制、有效期、分组，四个维度组合起来，足以支撑从个人使用到团队协作的完整场景。每客户端独立 Key 的做法，把安全风险从”全有或全无”变成了”可局部处置”。

第四，成本可见性的设计。 按 Key 归因的用量日志，让消耗来源变得可追溯。对于需要评估 AI 投入产出的人来说，这比任何功能都更实用。

第五，配置管理的协作能力。 与 CC Switch 的配合，把多 CLI 工具的配置集中到一处，一键切换 Provider，显著降低了多工具并行使用时的维护成本。

第六，文档的专业度。 从 Claude Desktop 的开发者模式开启路径到 Codex 的版本变更说明，官方文档体现出对真实使用场景的深入理解，包括那些只有踩过坑才知道的细节。

第七，面向团队的天然适配。 一个账户、多把 Key、统一模型入口，这套结构天然适合小团队，不需要额外搭建管理系统。

第八，接入范围的广度。 覆盖 Claude Code、Claude Desktop、Codex CLI、Codex++、Cursor、Cherry Studio、WorkBuddy，以及通过 CC Switch 的统一管理，基本涵盖了当前开发者和 AI 工具用户的主力工作台。

六、竞品横向对比

在 AI API 网关这个赛道里，用户的常见选择不止一种。下面从五个方向做对比，重点放在功能与体验维度。

先看一个总览表：

对比维度	鱼鱼连线	云朵类聚合网关	分组型聚合平台	国际通用网关	自建中转	官方直连
协议兼容	OpenAI + Anthropic 双入口	通常以 OpenAI 兼容为主	按分组区分	通常以 OpenAI 兼容为主	取决于部署方案	各自独立
客户端文档	按工具独立成篇	通用文档为主	分组建模文档	通用文档为主	需自行研究	官方文档
密钥治理	额度/速率/有效期/分组	基础 Key 管理	与分组绑定	基础 Key 管理	视部署而定	平台自带
用量归因	按 Key 可追溯	平台级统计	按分组统计	平台级统计	需自行搭建	平台级统计
配置管理工具	CC Switch 一键导入	一般需手动	推荐 CC Switch	手动配置	手动配置	不适用
计费模式	按量计费	按量计费	按分组与模型	按量计费	取决于上游	按量或订阅
上手难度	低到中	低	中	中	高	低
最适合	多客户端并行的开发者与小团队	以 OpenAI 系为主的用户	需要细粒度线路控制的用户	有海外工作流的用户	有运维能力的技术团队	只用单一平台的用户

1. 云朵类聚合网关 vs 鱼鱼连线

云朵类聚合网关（以 Yunwu.ai 为代表）是很多用户的第一站。它提供 OpenAI 兼容的 API，可访问 Claude、GPT、Gemini 等模型，本质上和鱼鱼连线解决的是同一类问题。

两者最大的差异在工具导向的程度。云朵类平台的重心在于模型目录与兼容接口，用户拿到地址和 Key 之后，需要自己去研究怎么接进具体客户端。而鱼鱼连线的重心在于”你打算用哪个工具”，Claude Code、Codex、Cursor、Cherry Studio、WorkBuddy、CC Switch 都是一条独立的接入路径，每一步写清楚。

官方博客在对比这类方案时有一句很到位的表述：统一 API 平台解决的核心问题是相似的，但最佳选择取决于你的工作负载。在评估时应该看你使用的工具、支持的协议、当前的线路情况、密钥管理能力、模型可用性、延迟与支持，而不仅仅是模型目录的大小。

从选择角度看：

维度	云朵类聚合网关	鱼鱼连线
强项	模型目录组织、已有账户体系	客户端接入指引、按工具的配置路径
协议文档	偏向 OpenAI 兼容说明	OpenAI 与 Anthropic 双线分列
Claude Code 支持	视线路而定	有专门的配置说明
Codex 支持	通用说明	有独立页面与完整字段说明
配置管理	视平台设置	与 CC Switch 打通
密钥策略	视平台设置	明确推荐每客户端独立 Key
适合	已有该平台账户、偏好其目录的用户	工作流以 Coding Agent 与桌面客户端为主的用户

结论： 如果你已经在某个平台上积累了账户和使用习惯，迁移成本是真实存在的；但如果你的核心工作流是 Claude Code、Codex、Cursor 这类工具，鱼鱼连线的开箱路径会更短。

2. 分组型聚合平台 vs 鱼鱼连线

第二类典型方案是分组型聚合平台（以 PackyAPI / PackyCode 为代表）。它通过”令牌分组”来组织访问：你选择的分组决定了这把 Key 能用哪些模型、哪些线路和哪些客户端。常见分组包括 Claude Code 专用、Codex 专用、Gemini、官方渠道线路、折扣线路等。

这种设计的优点很明确：控制粒度非常细。缺点是，它把一部分复杂度前置到了用户的第一次配置上。官方博客在对比时指出，PackyAPI 明确警告选错分组会导致”模型未找到”错误或客户端配置不兼容；不同的 Key 可能归属不同分组，具有不同的兼容规则。

鱼鱼连线选择的是另一条路：围绕工具和协议组织，而不是围绕分组组织。对大多数工具来说，核心值只有三个——Base URL、API Key、模型名。控制台和文档以工具为索引呈现配置路径，对于目标是”让 Claude Code 或 Codex 跑起来”的用户，路径更直接。

维度	分组型聚合平台	鱼鱼连线
组织方式	令牌分组决定模型与线路	按客户端与协议组织
首次配置	需要先理解分组含义	选工具、建 Key、填三个值
线路选择	颗粒度细，官方/折扣/专用线路分列	通过分组选择，控制台展示为准
Claude Code	专用分组 + 配置指南	专门的控制台配置路径
Codex	专用分组 + Responses 配置	OpenAI 兼容路由 + 独立配置页
CC Switch	推荐使用	推荐使用并支持一键导入
适合	需要细粒度线路控制的进阶用户	希望快速接入、统一管理的用户

结论： 如果你乐于研究不同线路的差异，并且确实需要精细的线路切换，分组型平台的控制力是优势；如果你更希望”选个工具、建把 Key、开始干活”，鱼鱼连线的路径更短。

3. 选购决策树

除了上面两类，还有三种常见选择：国际通用网关（以 OpenRouter 为代表）、自建中转（基于 One API / New API 等开源方案）、以及官方直连。

国际通用网关的优势是模型覆盖面广、生态成熟。它的典型使用场景是海外工作流，接口以 OpenAI 兼容为主。如果你需要接入大量小众模型、或者团队已经在海外生态里，这是一个合理选项。它的关注点和鱼鱼连线不同：前者强调目录的宽度，后者强调本地主流工具的接入深度。

自建中转的优势是完全自主可控。你可以基于开源方案部署，自己决定上游、路由和日志。它适合有运维能力、对数据流向有严格要求的技术团队。代价是需要自己承担部署、维护、可用性保障和版本升级的工作。对于希望把精力放在业务上的团队，托管型网关是更轻的选择。

官方直连是另一个极端：直接使用模型提供商的官方 API。它的优势是路径最短、没有中间层。如果你的工作流只依赖单一模型家族，且配置文件只维护一份，官方直连完全够用。但当工具数量增加到两个以上、模型家族跨越两家以上时，多账户、多密钥、多账单的维护成本就会显现出来——这正是网关类服务的价值区间。

基于以上分析，可以给出一条清晰的决策路径：

• 你的工作台上只有 1 个 AI 客户端，且只用一个模型家族 → 官方直连最省事。
• 你同时使用 2 个以上 AI 客户端 → 网关类方案开始有价值，优先看是否覆盖你用的工具。
• 你的核心工具是 Claude Code / Codex / Cursor / Cherry Studio → 优先看有没有针对这些工具的独立接入文档与配置指引，鱼鱼连线在这一维度覆盖完整。
• 你需要为团队提供统一入口与额度管理 → 优先看密钥治理能力（额度、速率、有效期、按 Key 归因），鱼鱼连线的四维控制项覆盖到位。
• 你需要精细的线路级控制，且愿意为配置复杂度付出学习成本 → 分组型平台值得比较。
• 你有运维资源且要求完全自主 → 自建中转是合理路线。
• 你需要接入大量长尾模型、团队在海外生态 → 国际通用网关值得评估。

一条实用的落地建议：不要先迁移生产工作流。先创建一个新的测试 Key，发一个短提示，验证流式输出、工具调用和用量记录，确认无误后再迁移更长的编码会话。这个顺序在各类平台之间都适用，也是评估任何网关时最可靠的方法——用你自己的真实负载去比，而不是只看倍率数字，因为倍率并不能反映延迟、缓存行为、线路稳定性和支持质量。

七、常见问题解答

1. 鱼鱼连线是什么？和直接使用官方 API 有什么区别？

鱼鱼连线是一个 API 中转网关，它把多个模型家族的能力汇总到一个账号、一把凭证体系下，并同时提供 OpenAI 兼容和 Anthropic 兼容的接口入口。它面向开发者和 AI 工具用户，重点在于把模型能力接入 Claude Code、Claude Desktop、Codex、Cursor、Cherry Studio、WorkBuddy 等已有工具。

与直接使用官方 API 的区别在于三处。一是账户结构：官方 API 通常按模型家族划分，你用几家就要维护几套账户与余额；鱼鱼连线是一个账户、一个余额、多把 Key。二是协议适配：不同客户端需要的接口风格不同，鱼鱼连线同时提供两套兼容入口，并按工具给出配置路径。三是用量归因：按 Key 区分的用量日志，让消耗来源可追溯，这在多工具并行时尤其有用。

如果你的工作流只涉及单一工具、单一模型家族，官方直连是最短路径；当工具数量增加、模型家族跨越两家以上时，网关的价值开始显现。

2. 鱼鱼连线支持哪些模型和客户端？

从官方文档看，鱼鱼连线支持接入 Claude、GPT、Gemini、Grok 等主流模型家族。可用模型的准确名称以控制台的模型广场（/model-plaza）为准，配置时需要使用与列表完全一致的模型名，否则会出现未知模型错误。

客户端方面，官方提供了独立接入文档的工具包括：Claude Code、Claude Desktop、Codex CLI、Codex++、Cursor、Cherry Studio、WorkBuddy，以及通过 CC Switch 的统一配置管理。其中 CC Switch 是一个跨平台的 AI CLI 配置管理工具，可用于集中管理 Claude Code、Codex、Gemini CLI、OpenCode 等工具的 Provider 配置，把 Base URL、API Key、模型名称统一保存，支持一键切换。

需要特别注意的是协议匹配：OpenAI 兼容的客户端使用 https://app.yylx.io/v1，Anthropic 风格的客户端使用控制台展示的 Claude/Anthropic 配置。不建议把 OpenAI 兼容地址直接复制到 Anthropic 客户端里。

3. 如何创建和配置 API Key？

创建流程是：登录控制台，在左侧菜单进入「我的账户」下的「API 密钥」页面，点击「创建密钥」，填写名称并选择分组。额度限制、速率限制、密钥有效期都是可选项，按场景开启即可。确认后点击「创建」，并在创建成功后立即复制保存——API Key 通常只完整展示一次，如果忘记保存，需要删除旧 Key 后重新创建。

官方建议为每个客户端单独创建 Key，例如 Claude Code 一个、Cursor 一个、Cherry Studio 一个。这样做有两个好处：一是可以按工具查看消耗来源，二是某个客户端泄露时只需要禁用对应 Key，不会影响其他工具。

创建后的验证方式很简单，用一行命令即可测试 OpenAI 兼容接口是否可访问：

curl https://app.yylx.io/v1/models \
  -H "Authorization: Bearer sk-your-api-key"

如果返回模型列表，说明 Key 和 Base URL 基本可用。如果失败，按四个方向检查：Key 是否完整（不要漏字符或带多余空格换行）、分组是否启用且包含要调用的模型、账户余额或额度是否充足、Base URL 是否为 https://app.yylx.io/v1。

关于自定义密钥，官方明确建议不要开启，除非你明确知道为什么要固定 Key 字符串。自动生成的 Key 更安全，也更不容易与旧配置混淆。

4. 鱼鱼连线的计费方式和试用额度是怎样的？

根据官方公开的定价与博客资料：鱼鱼连线采用按量计费，没有月度订阅要求，使用多少结算多少。新账户可以获得 $0.50 的试用额度，方便在正式投入前用自己的真实提示词测试延迟、流式输出与工具调用表现。

在公开的定价说明中，还提到部分 GPT/Codex 标准线路的费率可低至官方定价的 0.1 倍，部分 Claude 与 Gemini 标准线路的费率可低至官方定价的 0.2 倍。

需要强调的是，线路、模型与价格会随官方调整而变化，上述信息可能不是最新状态，请以官网最新的模型与定价页面公示为准。在做生产环境决策前，建议先到控制台查看实时的模型列表与分组倍率，再用自己的实际工作负载做一次小额验证，这比参考任何第三方文章都更可靠。

5. 使用鱼鱼连线时，怎么避免 Key 泄露带来的风险？

官方文档给出了一套完整的安全实践，核心思路是”分权、限权、可轮换”。

分权：为每个客户端单独创建 API Key，命名清晰（如 claude-code-mac、codex-work、cursor-desktop、cherry-studio-home）。这样即使某个工具配置泄露，也只需要禁用那一把 Key，其他工具不受影响。

限权：给临时项目、团队成员或不常用设备创建 Key 时，设置额度限制；需要限制并发时开启速率限制；临时测试 Key 设置有效期，到期自动失效。

存储：把 Key 存到密码管理器、系统钥匙串，或只在本机可读的环境变量中。不要写进公开仓库、截图、聊天记录或共享文档。在终端中确认环境变量时，用 echo $YYLX_API_KEY 看到非空输出即可，不需要把完整值粘贴到公开聊天或 issue 里。

轮换：定期清理不用的 Key。长期不用、用途不明、疑似泄露的 Key 都应该禁用或删除。发现泄露后，立即删除旧 Key 并重新创建，然后更新对应客户端的配置。

---

从多个 AI 客户端各自为战，到一个账号统一供给，鱼鱼连线做的事情本质上是一次”接口层”的整理。它没有试图取代你手里的任何工具，而是把自己放在所有工具的下方，把模型调用这件事变成一条清晰、可计量、可治理的管道。对每天都在 Claude Code、Codex、Cursor、Cherry Studio 之间来回切换的人来说，这种”少配置几次”的价值，往往比多一个功能更实在。