CustomGPT 这个词最近被聊得很多但大多数人聊的是“在官方产品里创建一个自定义机器人”而不是“自己用 API 搭一个可复用、可控制成本的机器人”。如果你也想做一个低成本 CustomGPT我的建议是先分清这两种形态。官方产品确实方便但如果你要批量处理、接私有知识库、集成进业务系统或者想长期控制预算API 自建往往是更稳的一条路。这篇文章不会教你写一个花哨的页面而是按我自己的落地顺序拆先判断做哪种形态再准备环境和密钥接着写最小可用流程然后解决最容易被忽略的成本和排查问题。整个过程以 ChatGPT 的 API 接口为例但思路对大部分模型提供商都通用。1. 先想清楚你要做的 CustomGPT 是哪种形态很多人一上来就问“怎么做 GPT”实际上真正要回答的是你要的是产品形态还是工程能力如果是想在聊天页面里给某个助手设定一套人设、上传几份资料然后分享给朋友用那直接用官方产品最省事。但如果你需要把机器人嵌入自己的系统、批量处理几千条文本、定时跑任务或者不想按人头订阅官方产品就不够用了。这时候你真正要做的是一个“基于大模型 API 的定制助手”也就是标题里说的 Affordable CustomGPT。1.1 官方 GPTs 不等于 API 自建官方 GPTs 的特点是配置化你只需要写系统提示词、上传文档、勾选几个能力就能得到一个独立助手。整个过程不需要写代码也不需要关心 token 消耗因为订阅费用已经覆盖了一部分使用量。但它的边界也很明显数据放在平台侧不一定适合敏感信息。调用方式受限不能直接当后端服务使用。定制深度取决于平台能力无法自己控制模型参数、上下文长度、输出格式。如果你的任务量很大订阅套餐不一定比按量付费更便宜。API 自建的 CustomGPT 则相反。你需要自己维护提示词、上下文、知识库和调用逻辑但换来的是可控性和灵活性。你可以决定用哪个模型、限制多少 token、怎么处理失败请求、怎么记录日志。1.2 真正的成本结构在哪里很多人以为“低成本”等于“不花钱”这是误解。自己做 CustomGPT核心成本不是工具费用而是三件事token 消耗、开发维护时间、数据处理成本。token 消耗是最直观的。每次请求都会把系统提示词、历史对话、用户输入和模型输出全部换算成 token。你写的提示词越长每次调用越贵上下文保留越多费用越高。开发维护时间容易被低估。自己搭一个简单问答机器人可能半天就够但要处理多轮对话、知识库更新、接口异常、并发控制就会变成一个小工程。数据处理成本通常出现在 RAG 场景。你要把文档切块、向量化、存到向量数据库这些流程需要存储和计算资源。文件量不大时成本可以忽略但文档一多向量化和检索本身也会吃掉时间和费用。所以“低成本”不是指“免费”而是指把每一分钱花在真正需要的地方。2. 搭一个最小可用 CustomGPT 需要准备什么在写代码之前先把环境想清楚。很多问题不是模型能力不行而是调用方准备不足。2.1 开发者账号、API Key 和基础安全要调用 API第一步是有一个可用的开发者账号并在官方平台创建 API Key。API Key 是调用凭证和账号余额、模型权限直接挂钩。不同平台的开通条件不同具体以官网要求为准。API Key 的保存位置是新手最容易踩坑的地方不要把 Key 写在前端代码里。不要把 Key 提交到 Git 仓库。不要在日志里打印完整 Key。推荐放在环境变量或本地配置文件中并在服务启动时加载。我自己的习惯是先把 Key 放到.env文件里用python-dotenv读取。如果是简单脚本直接在终端里export OPENAI_API_KEY...也可以但别写死在.py文件里。OPENAI_API_KEY你的密钥2.2 本地运行环境与依赖API 自建 CustomGPT 不需要很强的本地算力因为真正的大模型推理发生在远端。你只需要一个能发 HTTP 请求的环境普通笔记本就够。最低要求是有一台能装 Python 的机器建议 Python 3.10 以上。需要安装的主要依赖如下pip install openai python-dotenv fastapi uvicornopenai官方 Python SDK用来调用模型接口。python-dotenv读取环境变量。fastapi和uvicorn如果你之后想把助手包装成 HTTP 服务。低配置机器也能跑但注意不要同时开太多并发任务否则容易卡在本地进程或输出处理上。2.3 最小项目结构先不要一上来就搞数据库、消息队列、向量数据库。最小项目只需要三个文件customgpt/ ├── .env ├── main.py └── requirements.txtmain.py只做一件事接受用户输入调用模型接口返回结果。跑通之后再拆分系统提示词、知识库检索、接口服务这些模块。我一般会先用一个脚本验证“能不能调用成功”再谈项目结构。这个阶段最重要的不是优雅而是能看见返回内容。from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是门店客服助手回答要简洁、友好。}, {role: user, content: 你好请介绍一下你的功能。}, ], temperature0.3, max_tokens500, ) print(response.choices[0].message.content)这个脚本是后面所有功能的基础。如果它跑不通先不要急着加知识库和部署。3. 从零写一个可复用的 CustomGPT 核心流程当最小脚本能正常返回后下一步不是写更多代码而是把“定制”这件事做到位。3.1 用 System Prompt 定人设和边界CustomGPT 的“定制感”主要来自 System Prompt。它决定了模型怎么理解自己、怎么组织回答、哪些话能说、哪些话不能说。好的 System Prompt 不是写作文而是写规则。我会把下面几类信息明确放进去角色你是谁服务对象是谁。任务你主要负责做什么。输出格式需要 JSON、列表、还是自然段。边界哪些问题不回答或者回答后提示用户找人工。语气简短、专业、热情还是中立。比如一个“退货政策助手”的系统提示词可以写成你是电商平台的退货政策助手。 你的任务是回答用户关于退货时间、运费、退款流程的问题。 回答必须引用平台政策不要编造规则。 如果用户问超过退货政策范围的问题请回复请联系人工客服。 输出控制在 200 字以内。这里的关键是给模型足够明确的约束而不是让它自由发挥。很多输出质量不稳定的问题根因就是系统提示词太模糊。3.2 多轮会话与上下文组织如果要实现多轮对话不能只把当前用户问题发给模型还要把历史对话一起传进去。Chat Completions 接口的消息结构如下messages [ {role: system, content: system_prompt}, {role: user, content: 第一轮问题}, {role: assistant, content: 第一轮回答}, {role: user, content: 第二轮问题}, ]模型本身没有记忆。每次调用都是无状态的你传多少历史它就看到多少历史。这也是 CustomGPT 开发里最容易出问题的地方。上下文太长费用会快速上升。上下文太短模型可能忘记之前的信息。常见做法是保存最近 N 轮对话而不是无限累积。比如只保留最近 10 条消息超过就丢弃最早的内容。不要一上来就把上下文窗口拉满。先给一个小窗口比如最近 5 轮跑出效果后再慢慢加。这样既能控制成本也能观察模型在信息不足时表现如何。3.3 让知识库进入对话先做小规模 RAG如果你希望 CustomGPT 回答自己文档里的内容比如产品手册、公司政策、课程资料就需要让模型“读到”这些资料。最稳妥的方法是 RAG也就是检索增强生成。流程是把文档切分成小段。为每段生成向量表示存入向量数据库。用户提问时先用向量检索出最相关的几段文本。把这些文本作为上下文和用户问题一起传给模型。但第一次落地时不建议直接上向量数据库。文档少的话最简单的方法是先把所有相关文本切片然后用关键词或简单的相似度计算选出最相关的片段拼进 Prompt。def build_prompt_with_context(question, chunks, top_k3): scored [] for chunk in chunks: # 这里可以换成向量相似度也可以先用关键词匹配 score sum(word in chunk for word in question.split()) scored.append((score, chunk)) scored.sort(reverseTrue, keylambda x: x[0]) context \n.join([chunk for _, chunk in scored[:top_k]]) return f根据以下资料回答问题\n{context}\n\n问题{question}这个做法不够精细但足够让你理解 RAG 的链路。跑通之后再去替换成向量数据库比如 Chroma、FAISS 或云数据库复杂度会增加但原理是一样的。4. 成本控制为什么按量付费可能更省也可能更贵很多人在意 API 会不会太贵其实关键不是单价而是你怎么用。4.1 token 消耗的三个来源一次完整的 API 请求费用由三部分组成输入 token、输出 token、缓存或额外功能费用。输入 token 包括系统提示词、历史对话、检索到的资料片段和用户输入。这部分最容易失控。如果你的系统提示词有 2000 字每次用户只说一句话你也要为那 2000 字付费。输出 token 是模型生成的内容长度。max_tokens设置得越大单次上限越高但不代表每次都花满。真正影响费用的是模型实际生成的文本长度。额外费用可能来自联网搜索、工具调用、图片输入等。如果只是做文本对话这部分可以不开启。4.2 影响费用的关键参数下面这几个参数会直接影响价格和效果不是越大越好。参数影响建议model不同模型单价差异很大先选便宜模型跑通再换更强模型max_tokens限制单次输出长度根据任务类型设置不要无限大temperature影响随机性不影响费用稳定任务用 0.2 到 0.4messages历史消息越多输入 token 越多只保留最近 N 轮n生成的候选数量默认 1不需要多个候选stream是否流式输出体验更好但不直接降低总 token我见过很多费用异常的情况不是因为模型贵而是因为历史消息积压太多。用户问了几百轮每次都把全部历史传进去费用自然涨。4.3 上手就要做的四种限流措施不要等账单出来了再优化第一步就把限制加进去。第一限制单条历史长度。保存历史时对每条消息做截断过长的内容只保留开头或摘要。第二限制检索上下文大小。RAG 场景里检索结果不是越多越好。取前 3 到 5 段即可每段控制在 500 字以内。第三设置输出上限。根据任务类型设置max_tokens客服回复 200 到 500 就够内容生成任务可以到 1000 以上。第四加并发和频率控制。如果你做的是内部工具限制每分钟最多调用多少次避免某个测试脚本把预算耗光。MAX_OUTPUT_TOKENS 500 MAX_HISTORY_MESSAGES 10 messages messages[-MAX_HISTORY_MESSAGES:] response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, max_tokensMAX_OUTPUT_TOKENS, temperature0.3, )不要一开始就追求完整的企业级限流方案先让代码在最坏情况下也不会烧掉太多钱再逐步完善。5. 功能扩展把 CustomGPT 变成可调用服务单脚本跑通后下一步通常是把它变成一个可通过 HTTP 调用的服务这样其他系统就能接入。5.1 用 FastAPI 包装一个最小接口FastAPI 是一个适合做 AI 接口层的 Python Web 框架。它写起来简单自带参数校验和接口文档。from fastapi import FastAPI from pydantic import BaseModel from openai import OpenAI import os app FastAPI() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) class ChatRequest(BaseModel): message: str user_id: str default app.post(/chat) def chat(req: ChatRequest): # 实际开发中这里需要从数据库读取历史会话 messages [ {role: system, content: 你是项目助理。}, {role: user, content: req.message}, ] response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, max_tokens500, ) return {reply: response.choices[0].message.content}启动命令uvicorn main:app --reload --host 0.0.0.0 --port 8000这个接口只做了最基本的功能。要让它真正可用还需要加上历史会话存储、错误处理、日志记录和超时控制。5.2 日志、错误重试与超时配置接口化之后最重要的事情从“能不能回答”变成了“稳不稳定”。需要关注几类问题网络超时模型接口响应慢调用方等不住。频率限制同一时间请求过多接口返回限流错误。余额不足账号余额不够请求失败。输入异常用户传了空字符串、超大文本、非法字符。我一般会先看返回状态码再决定怎么处理。比如超时通常可以重试一次鉴权失败不要重试限流应该等待后再试。import time def call_with_retry(client, messages, max_retries2): for i in range(max_retries): try: return client.chat.completions.create( modelgpt-4o-mini, messagesmessages, max_tokens500, timeout30, ) except Exception as e: print(f第 {i1} 次调用失败: {e}) time.sleep(2) return None重试不是越多越好。网络抖动时重试一两次有效但如果接口一直超时说明可能是网络环境、账号权限或模型本身的问题继续重试只会浪费时间和费用。5.3 什么时候加入功能调用和队列当 CustomGPT 需要查数据库、查天气、调内部系统时可以使用 function calling 或工具调用。这个能力让模型不只是生成文本还能触发真实操作。但我不建议第一个版本就做工具调用。先把纯文本对话跑稳把日志和错误处理做好再考虑模型如何决定“什么时候调用某个函数”。工具调用会增加状态复杂度一旦模型误判可能会出现重复切换、参数遗漏、流程卡死等问题。如果任务量很大比如每天要处理上万条请求还需要引入队列。FastAPI 接口接收请求后先把任务写入队列由后台 worker 慢慢消费。这样既能削峰也能控制并发。6. 常见问题定位与排查顺序自己搭 CustomGPT 一定会遇到问题。我总结过一套排查顺序先看现象再看输入再看环境再看参数最后才怀疑模型本身。6.1 请求失败、超时、上下文过长如果请求直接报错先看错误信息里的错误类型。现象常见原因排查方向401 鉴权失败API Key 错误或权限不足检查 Key 是否复制完整是否过期404 模型不存在模型名写错或账号没权限确认账号可用的模型列表429 请求过多并发过高或触发限流降低并发增加重试间隔超时网络不稳定或响应过慢增加超时时间先跑单条请求测试上下文过长messages 太长裁剪历史消息压缩检索内容这里最容易忽略的是报错不一定是模型问题可能是你发的消息格式不对。比如消息类型不是字符串角色值写错或者塞了太大的图片。先把请求体打出来看一遍往往比猜更快。6.2 输出质量不稳定输出质量不稳定的原因通常不是模型变笨了而是输入变化了。用户问题表述变了检索到的知识片段不同。历史消息累积后模型被之前的错误回复带偏。temperature 太高回答随机性大。系统提示词互相冲突模型不知道该听哪句。如果只是偶尔不稳定可以尝试降低 temperature。如果是批量任务开几次结果不一致建议把 temperature 调到 0.2 或更低并固定系统提示词。如果输出为空先看日志里模型返回了什么。有时候是max_tokens太小模型刚生成几句就被截断有时候是增量输出没有被正确拼接只取了第一段。6.3 费用增长异常费用异常增长很少是平台乱扣费更多是你自己在不断重复消耗。优先检查这几个地方历史消息是不是无限增长。检索上下文是不是每次都把所有文档全部塞进去。是否有循环重试脚本失败后无限调用。max_tokens是否设置得过大导致输出浪费。是否在测试时走了更贵的模型比如大模型或带视觉的模型。我一般会在每次请求前后记录 token 数打一条日志。等出问题的时候直接翻日志看是哪类请求消耗最大。print(prompt_tokens:, response.usage.prompt_tokens) print(completion_tokens:, response.usage.completion_tokens) print(total_tokens:, response.usage.total_tokens)这个信息是排查费用问题的第一线索。7. 什么情况下别自己造什么情况下必须自己造最后说清楚边界。自建 CustomGPT 不是唯一答案也不是所有场景的最优解。7.1 适合直接用官方产品的场景如果你只是偶尔用一下创建几个角色助手回答日常问题没有必要自己写代码。官方产品的订阅或免费额度足够覆盖需求而且不需要维护服务。比如你想给团队内部做几个供员工使用的助手不要求对接内部系统不要求记录日志那直接用官方 GPTs 功能分享链接就行。省下来的开发时间远大于订阅成本。官方产品还适合做原型验证。在页面里试出合适的提示词再把这套提示词迁移到 API 自建服务里比直接写代码快很多。7.2 适合自建 CustomGPT 的场景一旦出现下面这些信号就应该考虑自建需要把回答结果写入自己的数据库。需要根据用户身份给不同权限和提示词。需要严格记录所有请求日志满足审计要求。需要批量处理文件、文本或历史数据。需要把助手嵌入现有 Web 应用、小程序或客服系统。需要控制模型、参数、上下文长度和失败处理逻辑。这些需求在官方产品里很难做到或者说做起来很别扭。API 自建虽然要写代码但每一步都是可控的。7.3 开源模型这条路也值得试如果你对数据隐私要求很高或者想进一步降低长期调用费用可以关注开源模型。比如通过 Ollama、vLLM 等方式在本地或自己的服务器上跑模型。本地跑模型的优势是数据不出内网调用成本主要变成硬件和电费。但要注意这种方式对硬件有要求。低配机器也能跑但模型体积要选小一点上下文长度要限制并发数不能太高。开源模型的劣势是安装维护成本高效果可能不如商业模型稳定。我的建议是先用自己的 API 自建方案跑通业务逻辑再评估是否迁移到开源模型。不要一开始就和硬件和部署较劲。踩过几次之后我发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。做一个 Affordable CustomGPT真正的门槛不在于“调用一次模型”而在于你能不能让这个调用过程稳定、可控、可复制。我更建议先把单任务跑稳再谈批量和接口。等你能准确说出每次请求消耗了多少 token、哪条日志对应哪次失败时这个 CustomGPT 才算真正落地了。