1. 先搞清楚：你的问题到底该用哪种方法解决

很多人一上来就问「我要不要微调」，其实这个问题问早了。预训练大模型是用互联网公开语料喂出来的，覆盖面广，但落到你自己的业务上，它不知道你公司产品的定价规则，不知道你上周写的那篇文章讲了什么，也不知道你们客服话术里那些约定俗成的说法。你直接问它，它只能泛泛而谈，甚至一本正经地编。

这时候摆在面前的路其实就五条：优化提示词、接外部知识库（RAG）、微调模型、换一个更合适的模型、上多模态模型。这五种方法不是互斥的，也不是越贵越好，关键看你的数据形态、更新频率、预算和响应要求。

我先把判断逻辑说清楚，你可以对号入座：

如果你的问题是「模型不懂我的表达习惯、输出格式不对、语气不对」，那优先做提示工程，成本几乎为零，改几行 system prompt 就能见效。

如果你的问题是「模型不知道我的私有文档内容，且文档还在持续更新」，那优先做 RAG，把文档切片存进向量库，每次提问先检索再生成。

如果你的问题是「某个垂直领域的术语、句式、判断逻辑，模型怎么提示都学不会，而且你有几千到几万条高质量标注数据」，那才考虑微调。

如果你的问题是「当前模型在代码或长文本上就是不行，换个模型立刻就好」，那别折腾，直接换模型，用统一通道横向对比几个模型的实际表现。

如果你的场景涉及图片理解、图文混合输出、语音转文字再推理，那才需要多模态模型。

这五条路里，前两条（提示工程、RAG）属于「不改模型参数」，第三条（微调）属于「改模型参数」，第四条（换模型）属于「换底座」，第五条（多模态）属于「换输入输出形态」。个人开发者和中小团队最常见的误区是：明明提示工程就能解决，非要去微调；明明 RAG 更合适，非要把文档塞进 prompt 里硬撑上下文。

接下来我会按「场景 → 可复制配置 → 验证动作」的方式，把五种方法逐一拆开。同时，因为你要横向对比不同模型、要管理多个 API Key、要在 RAG 和微调之间反复切换底座，我会用 TaoToken 的统一 Key 通道来集中管理调用，这样你换模型时不用改代码里的 base_url 和 key，只改一个 model 字段就行。

2. TaoToken 统一 Key 通道：一次配置，多模型切换

在展开五种方法之前，先把「调用通道」这件事解决掉。你如果同时试 Kimi、智谱、DeepSeek、Claude，每个平台都要注册、拿 Key、看不同的文档格式，代码里还得写一堆 if-else 判断走哪个 base_url。更麻烦的是，RAG 阶段你可能用便宜的小模型做检索摘要，微调后又换回大模型做生成，每次切换都要改环境变量。

TaoToken 的做法是提供一个统一的 OpenAI 兼容接口，你只需要一个 Key、一个 Base URL，通过改 model 字段来切换底层模型。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 地址后面不加 UTM 参数，直接用于代码里的 base_url。

具体操作分三步：

第一步，去控制台创建 API Key。打开 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，登录后在 API Keys 页面点创建，复制那串 sk- 开头的 Key。这个 Key 就是你所有模型调用的通行证，不要泄露到前端代码里。

第二步，确认你要用的模型 ID。在模型对话页面 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 里可以直接试聊，页面上会显示当前可选的模型标识。你也可以在接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 里查到完整的模型列表和对应的 model 字段写法。

第三步，把 Base URL 和 Key 写进你的项目配置。以 Python 的 openai SDK 为例，你不需要改任何业务代码，只改初始化部分：

from openai import OpenAI client = OpenAI( api_key="sk-你的TaoTokenKey", base_url="https://taotoken.net/api" ) response = client.chat.completions.create( model="claude-sonnet-4-20250514", # 换模型只改这一行 messages=[ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": "用三句话解释什么是RAG。"} ], temperature=0.3 ) print(response.choices[0].message.content)

如果你用 Node.js，配置同样简单：

import OpenAI from "openai"; const client = new OpenAI({ apiKey: "sk-你的TaoTokenKey", baseURL: "https://taotoken.net/api" }); const completion = await client.chat.completions.create({ model: "gpt-4o-mini", messages: [{ role: "user", content: "你好，做个自我介绍" }] }); console.log(completion.choices[0].message.content);

如果你用 Claude Code 做长期编码，可以在 settings 里配置统一通道。Claude Code 的配置文件通常放在项目根目录的.claude/settings.json或用户目录下，写入以下内容：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的TaoTokenKey", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }

这里的三件套是：Base URL 填https://taotoken.net/api，Key 填你创建的 sk- 串，Model ID 填你要用的模型标识。三个字段缺一不可，少一个就会报 401 或 model not found。

如果你用 Cline 或 Roo Code 这类 VS Code 插件，在设置里选 OpenAI Compatible，Base URL 填https://taotoken.net/api，API Key 填你的 Key，Model ID 填模型标识。Cline 的 MCP 配置里如果涉及模型调用，同样走这个通道。

配置完成后，你可以用一条 curl 命令验证通道是否通：

curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-你的TaoTokenKey" \ -d '{ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": "回复OK两个字母"}], "max_tokens": 10 }'

如果返回的 JSON 里 choices[0].message.content 是「OK」，说明通道正常。如果报 401，检查 Key 是否复制完整；如果报 model not found，检查 model 字段是否在文档列表里；如果报 local proxy failed，检查你的网络环境是否直连了 API 地址，不要走任何本地代理配置。

通道打通后，下面五种方法你都可以用同一个 Key 来试，换模型只改 model 字段，不用重新注册和配置。

3. 五种方法逐一拆解：配置片段与验证动作

3.1 提示工程：不改模型，先榨干 system prompt

提示工程是最容易被低估的方法。很多人觉得「不就是写个 prompt 吗」，但实际项目中，一个结构化的 system prompt 能让输出质量提升一个档次。核心思路是把角色、任务、约束、输出格式、示例都写清楚。

假设你要批量生成小红书风格的种草文案，不要只写「帮我写一篇小红书文案」，而是这样：

system_prompt = """ 你是一个小红书美妆种草博主，粉丝画像为18-28岁女性。 写作要求： 1. 标题带emoji，不超过20字，有悬念感 2. 正文分3段，每段不超过3行 3. 语气亲切，像闺蜜聊天，多用「姐妹们」「真的绝了」 4. 结尾带3-5个话题标签 5. 不要出现医疗功效承诺 输出格式： 标题：xxx 正文：xxx 标签：xxx """ user_input = "产品：某品牌玻尿酸精华，卖点：补水、不黏腻、适合夏天" response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ], temperature=0.8 )

验证动作：同一段 user_input，分别用 temperature=0.2 和 0.8 跑两次，对比输出的创意度和稳定性。如果 0.2 太死板、0.8 太飘，就取 0.5 左右。提示工程的迭代周期以「分钟」计，改完立刻能看到效果。

提示工程的边界也很清楚：它不能给模型注入它不知道的事实。你问它「我们公司2024年Q3的营收是多少」，它只能编。这时候就需要下一种方法。

3.2 RAG：把私有文档变成可检索的外部知识库

RAG 的核心流程是：文档切片 → 向量化 → 存入向量库 → 用户提问时检索最相关的片段 → 把片段拼进 prompt → 模型基于片段生成答案。这样模型不需要记住你的文档，只需要在回答时「看着」检索到的内容说。

最小可跑的 RAG 用 Python 加 Chroma 就能搭起来。先装依赖：

pip install openai chromadb sentence-transformers

然后写索引和检索逻辑：

import chromadb from sentence_transformers import SentenceTransformer from openai import OpenAI # 初始化 embed_model = SentenceTransformer("all-MiniLM-L6-v2") chroma_client = chromadb.Client() collection = chroma_client.create_collection(name="my_docs") client = OpenAI( api_key="sk-你的TaoTokenKey", base_url="https://taotoken.net/api" ) # 假设你的文档已经切成若干段 docs = [ "产品A的退货政策是7天内无理由退货，需保持包装完整。", "产品B的保修期是12个月，人为损坏不在保修范围内。", "客服工作时间是工作日9:00-18:00，节假日除外。" ] # 写入向量库 collection.add( documents=docs, ids=[f"doc_{i}" for i in range(len(docs))] ) # 检索 query = "产品A怎么退货？" results = collection.query(query_texts=[query], n_results=2) context = "\n".join(results["documents"][0]) # 拼 prompt 调用模型 response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个客服助手，只根据提供的资料回答，不要编造。"}, {"role": "user", "content": f"资料：\n{context}\n\n问题：{query}"} ], temperature=0.1 ) print(response.choices[0].message.content)

验证动作：故意问一个文档里没有的问题，比如「产品C的退货政策是什么」，看模型是否会说「资料中没有相关信息」。如果它开始编，说明 system prompt 的约束不够强，或者检索返回了不相关的片段干扰了它。

RAG 的坑主要在切片策略和检索质量上。切片太碎，上下文不完整；切片太大，检索精度下降。一般中文文档按 300-500 字切，重叠 50 字。检索时可以先返回 top 5，再用一个便宜的小模型做重排序，把最相关的 2 条留给生成模型。

3.3 微调：有高质量标注数据时才考虑

微调是改模型参数，让模型在特定任务上的表现内化到权重里。它适合的场景是：你有几千到几万条高质量的「输入-输出」对，而且这些数据的模式是提示工程和 RAG 都覆盖不了的。比如你要让模型学会一种非常特殊的方言翻译风格，或者学会你们公司内部工单的分类逻辑。

微调的数据格式通常是 JSONL，每行一个样本：

{"messages": [{"role": "system", "content": "你是一个法律合同审查助手。"}, {"role": "user", "content": "审查条款：甲方应在收到货物后30日内付款。"}, {"role": "assistant", "content": "风险提示：付款期限较长，建议增加逾期利息条款。建议修改为：甲方应在收到货物后15日内付款，逾期按日万分之五支付违约金。"}]} {"messages": [{"role": "system", "content": "你是一个法律合同审查助手。"}, {"role": "user", "content": "审查条款：乙方有权单方面解除合同。"}, {"role": "assistant", "content": "风险提示：单方解除权过于宽泛，建议限定解除条件。建议修改为：乙方在甲方发生根本违约且未在30日内补救时，有权解除合同。"}]}

准备 500-1000 条这样的数据后，通过 TaoToken 的微调接口提交任务。具体提交方式在接入文档里有说明，核心是上传 JSONL 文件、指定 base model、等待训练完成、拿到 fine-tuned model ID。之后调用时 model 字段填那个新 ID 即可。

验证动作：微调完成后，用同一批测试问题分别问 base model 和 fine-tuned model，对比输出是否符合你的预期格式和判断逻辑。如果 fine-tuned model 在训练集上表现好但测试集上变差，说明过拟合了，需要减少训练轮数或增加数据多样性。

微调的成本不只是训练费用，还有数据标注的人力。个人开发者如果没有几千条现成的高质量数据，不建议一上来就微调。先用 RAG 加提示工程跑通业务，积累用户真实问答数据，再考虑用这些数据做微调。

3.4 换模型：用统一通道横向对比，别凭感觉选

换模型是最直接的方法，但很多人换模型是靠「听说某某模型很强」，而不是靠实测。正确的做法是：准备一组你业务里的真实问题，用同一个 prompt 分别跑几个候选模型，记录输出质量、响应时间、token 消耗。

用 TaoToken 的好处是，你不需要为每个模型单独写调用代码。下面这段脚本可以一次性对比三个模型：

models = ["gpt-4o-mini", "claude-sonnet-4-20250514", "deepseek-chat"] question = "用一句话解释什么是向量数据库，要求通俗易懂。" for m in models: resp = client.chat.completions.create( model=m, messages=[{"role": "user", "content": question}], temperature=0.3 ) print(f"--- {m} ---") print(resp.choices[0].message.content) print(f"tokens: {resp.usage.total_tokens}")

验证动作：把同一组 10 个问题跑一遍，人工打分（1-5 分），同时记录每个模型的平均响应时间和 token 成本。最后算一个「性价比」：质量分除以单次调用成本。很多时候你会发现，贵的不一定最适合你的场景，便宜的小模型在简单任务上完全够用。

换模型时要注意上下文长度限制。有些模型支持 128K，有些只支持 32K。如果你的 RAG 检索片段很长，要确认目标模型的上下文窗口够用。另外，不同模型对 system prompt 的遵循程度不一样，换模型后要重新验证输出格式是否还符合要求。

3.5 多模态：图文混合场景才需要

多模态模型能同时处理文本和图像。典型场景是：用户上传一张产品图，模型识别图中的文字和物体，然后生成一段营销文案；或者用户上传一张表格截图，模型提取表格数据并做分析。

用 TaoToken 调用多模态模型时，messages 里的 content 不再是纯字符串，而是一个数组：

response = client.chat.completions.create( model="gpt-4o", messages=[ { "role": "user", "content": [ {"type": "text", "text": "描述这张图片里的内容，并给出三个营销文案标题。"}, {"type": "image_url", "image_url": {"url": "https://example.com/product.jpg"}} ] } ], max_tokens=500 )

验证动作：上传一张包含文字和物体的图片，看模型是否能准确识别文字并理解物体关系。如果识别不准，尝试换一个多模态模型，或者把图片先做裁剪和增强再传入。

多模态的坑在于图片大小和格式。大多数模型对图片有分辨率限制，太大的图会被压缩导致细节丢失。建议先把图片缩放到 1024px 以内再传入。另外，图片 URL 必须是公网可访问的，本地文件需要先转成 base64 编码。

4. 验证请求与成功结果：怎么确认你真的跑通了

不管用哪种方法，最终都要落到「发一个请求，拿到符合预期的结果」。我建议你建一个统一的验证脚本，把五种方法的调用都封装成函数，每次改完配置就跑一遍。

先验证通道本身：

curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的TaoTokenKey" \ -H "Content-Type: application/json" \ -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"ping"}],"max_tokens":5}'

返回 JSON 里如果有"content": "pong"或类似回复，说明通道正常。

再验证 RAG 链路：

# 检索测试 results = collection.query(query_texts=["退货政策"], n_results=1) assert len(results["documents"][0]) > 0, "检索为空，检查向量库是否写入" print("检索到：", results["documents"][0][0]) # 生成测试 resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "只根据资料回答。"}, {"role": "user", "content": f"资料：{results['documents'][0][0]}\n问题：退货要几天内？"} ] ) print("生成结果：", resp.choices[0].message.content)

如果检索有结果但生成结果答非所问，检查 system prompt 是否明确要求「只根据资料回答」，以及资料片段是否被正确拼接进了 user message。

微调验证则是对比 base 和 fine-tuned 的输出：

test_question = "审查条款：甲方应在收到货物后60日内付款。" for m in ["gpt-4o-mini", "ft:gpt-4o-mini:your-org:your-task:abc123"]: resp = client.chat.completions.create( model=m, messages=[ {"role": "system", "content": "你是一个法律合同审查助手。"}, {"role": "user", "content": test_question} ] ) print(f"--- {m} ---") print(resp.choices[0].message.content)

成功的标志是：fine-tuned model 的输出格式和风险提示逻辑明显更贴近你的训练数据风格，而 base model 可能只是泛泛而谈。

多模态验证最简单：传一张图，看返回的文本描述里是否包含图中实际存在的物体和文字。如果模型说「我无法查看图片」，说明你用的模型不支持多模态，或者 content 数组格式写错了。

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

这一节列的都是实际跑的时候会撞上的报错，我按错误信息来对号入座。

401 Unauthorized：最常见的原因是 Key 没填对。检查三件事：Key 是否完整复制（sk- 开头那一整串），Authorization header 里是否写了Bearer前缀（注意 Bearer 后面有一个空格），以及你调用的 base_url 是否写成了https://taotoken.net/api而不是其他地址。如果 Key 是在控制台刚创建的，确认没有多余空格或换行。

local proxy failed：这个报错通常出现在你的代码或工具里配置了本地代理，但代理服务没启动或端口不对。解决方法是检查环境变量HTTP_PROXY和HTTPS_PROXY是否被设置成了本地地址，如果是，临时取消这些环境变量再试。另外，Claude Code 或 Cline 的设置里如果有 proxy 字段，清空它，让请求直连https://taotoken.net/api。

reading choices 报错：完整报错通常是Cannot read properties of undefined (reading 'choices')。这说明 API 返回的 JSON 里没有 choices 字段，一般是请求本身失败了但代码没检查错误状态。在调用后先打印完整 response，看是否有error字段。常见原因是 model 字段填了一个不存在的模型 ID，或者 messages 格式不对（比如 role 写成了user以外的值）。用 TaoToken 时，model 字段必须和文档里列出的标识完全一致，大小写敏感。

OAuth 相关报错：如果你在 Claude Code 或 Codex 里看到 OAuth token 过期或认证失败的提示，说明工具在尝试用 OAuth 方式登录，而不是用 API Key。这时候需要检查配置文件里是否同时存在 OAuth 配置和 API Key 配置，两者会冲突。以 Codex 为例，auth.json里如果既有 OAuth 的 refresh token 又有 API Key，工具可能优先走 OAuth 导致失败。解决方法是清空 OAuth 相关字段，只保留 API Key 和 Base URL。Codex 的auth.json通常长这样：

{ "api_key": "sk-你的TaoTokenKey", "base_url": "https://taotoken.net/api" }

如果你用 CC Switch 来管理多个配置，确保切换到的配置里 Base URL、Key、Model ID 三件套完整。CC Switch 的配置文件里每个 profile 都要独立写全这三个字段，不能只写 Key 指望它继承其他字段。

模型返回空内容：有时候请求成功了，但choices[0].message.content是空字符串。这通常是因为 max_tokens 设得太小，或者模型在生成第一个 token 前就被截断了。把 max_tokens 调到 100 以上再试。如果还是空，检查 temperature 是否设成了 0 且 prompt 本身有歧义，模型可能「不知道说什么」。

RAG 检索结果不相关：这不是报错，但比报错更隐蔽。如果你发现模型回答的内容和你的文档对不上，先打印检索返回的 documents 列表，看最相关的片段是否真的相关。如果不相关，检查 embedding 模型是否适合中文（all-MiniLM-L6-v2 对中文支持一般，可以换text-embedding-3-small或bge-large-zh），以及切片大小是否合理。

6. 按场景选型：个人开发者与中小团队的落地建议

回到最初的问题：五种方法，到底选哪种？我的建议是按这个顺序试：

先花半天做提示工程，把 system prompt 写到不能再好。如果输出质量达标，收工。

如果提示工程解决不了「模型不知道我的私有数据」，花一天搭一个最小 RAG，用 Chroma 加几十条文档跑通检索和生成。如果 RAG 能解决 80% 的问题，收工。

如果 RAG 的检索精度不够，或者你的场景要求模型必须内化某种特殊风格，再考虑微调。微调之前先确认你有至少 500 条高质量标注数据，否则先积累数据。

如果以上都试了还是不行，换模型。用 TaoToken 的统一通道，把候选模型跑一遍对比测试，用数据说话。

如果场景涉及图片或语音，直接上多模态模型，不用在纯文本模型上浪费时间。

对于中小团队，我建议把 TaoToken 的 Key 放在服务端环境变量里，不要写在前端代码或客户端配置里。团队里每个人用同一个 Key 调不同的模型，通过 model 字段区分任务：便宜的小模型做检索摘要和分类，贵的大模型做最终生成。这样既能控制成本，又能保证效果。

长期做编码或 Agent 开发的，可以了解一下 Coding Plan，把日常的代码补全、重构、测试生成都走统一通道，不用在多个编辑器插件之间来回切换配置。模型对话页面适合快速验证某个模型对特定问题的回答质量，接入文档则保留了完整的参数说明和错误码对照。

最后说一个我踩过的坑：不要同时改多个变量。如果你一边调 prompt，一边换模型，一边改 RAG 切片大小，出了问题你根本不知道是哪个变量导致的。每次只改一个东西，跑验证脚本，确认结果变化可归因，再改下一个。这样你的调试效率会高很多。