企业官网建设流程全解析

1. IntelliJ IDEA 补全插件报 401 与 local proxy failed 的真实场景

在 IntelliJ IDEA 里用 Continue、Cline 这类 AI 补全插件时，很多人第一次接自定义 API 通道都会撞上两个报错：一个是401 Unauthorized，一个是local proxy failed。这两个错误看起来都像"连不上"，但根因完全不同，一个多半是 Key 的问题，另一个往往是端点或本地代理配置写错了。我自己在 IDEA 里折腾这套配置时，前后踩了三四次坑才把补全跑稳，所以这篇就把从报错到稳定补全的完整排查过程写清楚。

先说清楚这套东西是什么、能做什么、适合谁。IntelliJ IDEA 是 JetBrains 家的 Java/Kotlin 主力 IDE，插件市场里有 Continue、Cline 这类 AI 编程助手，它们本身不带模型，需要你填一个 API 通道（Base URL + API Key + Model ID）才能工作。TaoToken 在这里扮演的就是这个"通道"角色：它提供兼容 OpenAI 风格的接口，你把它填进插件的配置里，IDEA 里的代码补全、对话、解释代码这些功能就能跑起来。适合的人群很明确——已经在用 IDEA 写 Java/Spring 项目、想给编辑器加上 AI 补全、但不想自己维护模型服务的开发者。如果你只是偶尔问两句代码，用网页版对话就够了；但如果你希望补全直接出现在编辑器里、按 Tab 就能接受建议，那插件 + 自定义通道这套组合才是正解。

场景还原一下：你在 IDEA 里装好 Continue 插件，打开它的配置文件，把 Base URL 填成https://taotoken.net/api，Key 填进去，模型选了个gpt-4o之类，然后回到编辑器敲代码，期待补全弹出来。结果右下角弹红字401，或者插件日志里刷local proxy failed。这时候你第一反应可能是"Key 是不是过期了"，但实际情况可能是端点少写了/v1，也可能是插件把请求转发到了本地某个没起来的代理端口。下面按顺序把这两类问题拆开。

需要提前说明的是，401 和 local proxy failed 的排查顺序建议是：先确认 Key 和 Base URL 的拼写，再看插件的代理设置，最后才怀疑网络。因为前两者是配置问题，改一下就好；后者才涉及环境。很多人一上来就怀疑网络，结果绕了一大圈发现是 Key 复制时多了个空格。

2. 接入前的准备：TaoToken 的 Base URL、Key 与模型 ID 三件套

在动手改 IDEA 插件配置之前，先把"三件套"准备好：Base URL、API Key、Model ID。这三样缺一不可，而且每一件都有容易写错的地方。

Base URL 这块，TaoToken 的 API 地址是https://taotoken.net/api。注意这里有个高频坑：很多 OpenAI 兼容的客户端和插件，会在你填的 Base URL 后面自动拼/v1/chat/completions，所以如果你填的是https://taotoken.net/api，最终请求会变成https://taotoken.net/api/v1/chat/completions，这是对的。但如果你手贱填成了https://taotoken.net/api/v1，那就会变成https://taotoken.net/api/v1/v1/chat/completions，直接 404 或者 401。所以记住：Base URL 填到/api为止，不要自己加/v1。

API Key 的获取入口在控制台的 API Keys 页面，地址是https://taotoken.net/console/api-keys。进去之后新建一个 Key，复制出来。这里有个细节：Key 通常是一长串字符，复制的时候容易带上首尾空格或者换行。IDEA 插件的输入框一般不会自动 trim，所以你粘贴完最好手动检查一下光标位置，确认没有多余空白。我试过因为 Key 末尾多了一个空格，排查了二十分钟才发现。

Model ID 这块，你要填的是模型的实际标识符，比如gpt-4o、claude-3-5-sonnet这类。不同插件对 Model ID 的校验严格程度不一样，有的会下拉选择，有的要你手填。手填的时候注意大小写和连字符，gpt-4o和gpt4o是两个东西。如果你不确定某个模型的确切 ID，可以去模型对话页面先试一下，确认这个模型在你的账号下可用，再填进插件。

把这三件套准备好之后，建议先别急着改 IDEA，而是用一个最简单的 curl 请求验证一下通道本身是通的。这样能把"通道问题"和"插件问题"分开。命令大概是这样：

curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 你的API_KEY" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "say hi"}] }'

如果这条命令返回了正常的 JSON，里面有choices字段，说明 Key 和 Base URL 都没问题，问题出在插件配置上。如果这条命令也报 401，那就是 Key 本身的问题，先去控制台确认 Key 是否有效、是否被禁用。这一步能帮你省掉大量在 IDEA 里反复改配置的时间。

另外提一句，如果你打算长期在 IDEA 里用 AI 补全，尤其是高频补全场景，可以了解一下 Coding Plan 这类套餐，地址是https://taotoken.net/coding-plan。它的定位是给长期编码、Agent 类用法准备的，比按次调用更适合天天写代码的人。不过这是后话，先把连通性跑通再说。

3. 在 Continue / Cline 里填写配置：可复制的 settings 片段

这一节是核心，直接给可复制的配置。IDEA 里 Continue 和 Cline 的配置方式不太一样，我分开说。

先说 Continue。Continue 在 IDEA 里的配置文件通常是~/.continue/config.json（Windows 是C:\Users\你的用户名\.continue\config.json），新版也可能用config.yaml。如果你用的是 JSON 版本，模型配置大概长这样：

{ "models": [ { "title": "TaoToken GPT-4o", "provider": "openai", "model": "gpt-4o", "apiKey": "你的API_KEY", "apiBase": "https://taotoken.net/api" } ], "tabAutocompleteModel": { "title": "TaoToken Autocomplete", "provider": "openai", "model": "gpt-4o", "apiKey": "你的API_KEY", "apiBase": "https://taotoken.net/api" } }

这里有几个关键点。第一，provider填openai，因为 TaoToken 是 OpenAI 兼容接口，Continue 会按 OpenAI 的协议去请求。第二，apiBase填https://taotoken.net/api，不要加/v1。第三，tabAutocompleteModel是专门管 Tab 补全的，如果你只配了models没配这个，对话能用但补全不弹，这也是一个常见困惑点。

如果你用的是 YAML 版本，等价配置是这样：

models: - title: TaoToken GPT-4o provider: openai model: gpt-4o apiKey: 你的API_KEY apiBase: https://taotoken.net/api tabAutocompleteModel: title: TaoToken Autocomplete provider: openai model: gpt-4o apiKey: 你的API_KEY apiBase: https://taotoken.net/api

再说 Cline。Cline 在 IDEA 里一般是通过设置界面填的，但它的配置最终也会落到一个 JSON 文件里。如果你要手动改，路径通常在插件的数据目录下。Cline 的配置字段和 Continue 略有不同，它用的是apiProvider、apiKey、baseURL这套命名：

{ "apiProvider": "openai", "apiKey": "你的API_KEY", "baseURL": "https://taotoken.net/api", "model": "gpt-4o" }

注意 Cline 里字段叫baseURL而不是apiBase，这是两个插件容易混淆的地方。如果你把 Continue 的配置直接抄到 Cline 里，字段名对不上，插件读不到，就会 fallback 到默认端点，然后报 401 或者连到错误的地方。

还有一个高频坑是 CC Switch 这类配置切换工具。如果你用 CC Switch 管理多个通道，它生成的配置里 Base URL 和 Key 是分开存的，切换的时候如果只切了 Key 没切 Base URL，就会出现"Key 是新的、端点是旧的"这种错配，表现就是 401。所以用切换工具的话，每次切完确认一下三件套是不是成套的。

配置改完之后，IDEA 里需要重启插件或者重载窗口。Continue 一般改完配置会自动重载，Cline 可能需要你点一下重新连接。如果改完没反应，先别怀疑配置，试试File > Invalidate Caches或者直接重启 IDEA。

4. 用一次补全请求验证连通性：从日志到成功结果

配置填好之后，怎么确认它真的通了？不要靠"敲代码看补全弹不弹"这种模糊判断，要用可观测的方式验证。

第一步，打开插件的日志。Continue 在 IDEA 里的日志一般在View > Tool Windows > Continue或者 IDEA 的 Event Log 里。Cline 的日志在它的侧边栏面板里。你要看的是请求发出去了没有、发到哪个 URL、返回了什么状态码。

第二步，触发一次补全。在 Java 文件里敲一个方法名，比如public String getUser，停一下，看补全有没有弹。同时盯日志。如果日志里出现类似这样的记录：

POST https://taotoken.net/api/v1/chat/completions Status: 200 Response contains choices

那就说明通了。如果出现Status: 401，往下看第五节。如果出现local proxy failed或者ECONNREFUSED 127.0.0.1:xxxx，那是代理问题，也在第五节。

第三步，如果补全没弹但日志显示 200，那可能是补全触发条件的问题。Continue 的 Tab 补全默认需要你停止输入一小段时间（debounce），而且有些文件类型默认不触发。你可以在配置里调tabAutocompleteOptions的debounceDelay，或者手动按快捷键触发一次补全（Continue 默认是Ctrl+J或Cmd+J，取决于平台）。

第四步，验证对话功能。补全和对话是两条独立的链路，补全通了不代表对话通。在 Continue 的侧边栏里发一句"解释一下这段代码"，看有没有正常回复。如果对话报错但补全正常，说明models和tabAutocompleteModel里有一个配错了。

实测下来，最省事的验证方式是先用 curl 确认通道通，再在插件里触发一次补全看日志。两步都过了，基本就稳了。如果 curl 通但插件不通，问题一定在插件配置的字段名、路径或者代理设置上，跟通道本身无关。

这里补充一个细节：IDEA 的补全请求和对话请求走的可能是不同的超时设置。补全对延迟敏感，如果模型响应慢，补全可能直接超时被丢弃，日志里看不到明显报错，只是"没弹出来"。这种情况可以把补全用的模型换成响应更快的，或者调大超时。对话则对延迟宽容一些。

5. 常见报错排查：401、local proxy failed、reading choices、OAuth

这一节把几个高频报错逐个拆开，对照真实日志说。

401 Unauthorized。这个错误的字面意思是"你的身份没通过"。在 TaoToken 场景下，可能的原因有三个：Key 填错（多了空格、少了一段、复制串行）、Key 被禁用或删除、Base URL 写错导致请求发到了别的端点。排查顺序：先去控制台https://taotoken.net/console/api-keys确认 Key 存在且启用，然后重新复制一次，粘贴到插件里，手动检查首尾。如果还报 401，用 curl 测一下，curl 也 401 就是 Key 的问题，curl 通就是插件配置的问题。特别注意：如果你把 Base URL 填成了https://taotoken.net/api/v1，请求会变成/api/v1/v1/...，有些网关会直接返回 401 而不是 404，容易误导。

local proxy failed。这个错误的关键词是 "local proxy"，说明插件试图通过本地代理转发请求，但代理没起来或者端口不对。常见触发场景：你在插件里配了http.proxy或者系统环境变量里有HTTP_PROXY/HTTPS_PROXY指向127.0.0.1:某端口，但那个端口上没有服务在跑。排查方法：检查 IDEA 的Settings > Appearance & Behavior > System Settings > HTTP Proxy，确认是No proxy或者配置正确。同时检查环境变量，echo $HTTP_PROXY（Windows 是echo %HTTP_PROXY%），如果有值且指向本地端口，先清掉再试。另一个可能是插件自己的代理设置，Continue 和 Cline 都有独立的代理配置项，确认那里是空的。

reading choices 报错。这个通常表现为Cannot read property 'choices' of undefined或者reading 'choices'。根因是插件期望返回体里有choices字段，但实际返回的不是标准 OpenAI 格式。可能的原因：Base URL 指向了一个返回 HTML 错误页的地址（比如填错了域名），或者模型 ID 不存在导致网关返回了错误结构。排查：用 curl 发一次同样的请求，看返回的 JSON 结构里有没有choices。如果没有，看返回的error字段说了什么。常见的是模型 ID 写错，网关返回{"error": {"message": "model not found"}}，插件解析不到choices就报这个错。

OAuth 相关报错。如果你在插件里选了某个需要 OAuth 登录的 provider，但实际想用的是 API Key 方式，就会走到 OAuth 流程然后失败。解决方法是把 provider 明确设成openai（API Key 模式），不要选那些带 OAuth 的选项。Cline 里如果 provider 选错，会弹浏览器让你登录，这显然不是你要的。

把这几类错误对照下来，你会发现一个规律：401 和 reading choices 多半是配置字段的问题，local proxy failed 是代理问题，OAuth 是 provider 选错。按这个分类去排查，比盲目改配置快得多。

6. 稳定补全的收尾：把配置固定下来并持续验证

把补全跑通只是第一步，要让它稳定，还得做几件事。

第一，把配置固定下来。如果你用 Continue，把config.json或者config.yaml纳入版本管理（注意别把 Key 提交上去，用环境变量或者本地覆盖文件）。这样换机器或者重装 IDEA 时，配置能快速恢复。Cline 的配置也类似，找到它的配置文件位置备份一份。

第二，给补全单独配一个响应快的模型。补全和对话对模型的要求不一样，补全要快，对话要准。你可以在tabAutocompleteModel里用一个轻量模型，在models里用能力更强的模型。这样既保证补全不卡，又保证对话质量。

第三，定期验证。通道和 Key 都可能因为各种原因失效，建议每隔一段时间用 curl 跑一次连通性检查，或者留意插件日志里有没有突然出现 401。早发现早处理，别等到写代码写到一半补全不弹了才去查。

第四，如果你在团队里推广这套配置，把 Base URL、Key 获取方式、配置片段整理成一份内部文档。新人照着填就行，省得每个人都踩一遍 401 和 local proxy failed 的坑。文档里重点标注三个易错点：Base URL 不加/v1、Key 粘贴后检查空格、provider 选openai而不是 OAuth 类。

最后说一个我自己的习惯：每次改完插件配置，先不急着写业务代码，而是新建一个空 Java 文件，敲几行简单的方法签名，看补全弹不弹、日志正不正常。这个"冒烟测试"花不了一分钟，但能避免你在正式写代码时被配置问题打断思路。补全这东西，稳定比强大更重要，一个每次都弹的普通模型，比一个时灵时不灵的强模型体验好得多。