企业官网建设流程全解析

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 uvicorn

• openai：官方 Python SDK，用来调用模型接口。
• python-dotenv：读取环境变量。
• fastapi和uvicorn：如果你之后想把助手包装成 HTTP 服务。

低配置机器也能跑，但注意不要同时开太多并发任务，否则容易卡在本地进程或输出处理上。

2.3 最小项目结构

先不要一上来就搞数据库、消息队列、向量数据库。最小项目只需要三个文件：

customgpt/ ├── .env ├── main.py └── requirements.txt

main.py只做一件事：接受用户输入，调用模型接口，返回结果。跑通之后再拆分系统提示词、知识库检索、接口服务这些模块。

我一般会先用一个脚本验证“能不能调用成功”，再谈项目结构。这个阶段最重要的不是优雅，而是能看见返回内容。

from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是门店客服助手，回答要简洁、友好。"}, {"role": "user", "content": "你好，请介绍一下你的功能。"}, ], temperature=0.3, max_tokens=500, ) 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，也就是检索增强生成。流程是：

1. 把文档切分成小段。
2. 为每段生成向量表示，存入向量数据库。
3. 用户提问时，先用向量检索出最相关的几段文本。
4. 把这些文本作为上下文，和用户问题一起传给模型。

但第一次落地时，不建议直接上向量数据库。文档少的话，最简单的方法是先把所有相关文本切片，然后用关键词或简单的相似度计算选出最相关的片段，拼进 Prompt。

def build_prompt_with_context(question, chunks, top_k=3): scored = [] for chunk in chunks: # 这里可以换成向量相似度，也可以先用关键词匹配 score = sum(word in chunk for word in question.split()) scored.append((score, chunk)) scored.sort(reverse=True, key=lambda 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 影响费用的关键参数

下面这几个参数会直接影响价格和效果，不是越大越好。

我见过很多费用异常的情况，不是因为模型贵，而是因为历史消息积压太多。用户问了几百轮，每次都把全部历史传进去，费用自然涨。

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( model="gpt-4o-mini", messages=messages, max_tokens=MAX_OUTPUT_TOKENS, temperature=0.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_key=os.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( model="gpt-4o-mini", messages=messages, max_tokens=500, ) 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_retries=2): for i in range(max_retries): try: return client.chat.completions.create( model="gpt-4o-mini", messages=messages, max_tokens=500, timeout=30, ) except Exception as e: print(f"第 {i+1} 次调用失败: {e}") time.sleep(2) return None

重试不是越多越好。网络抖动时重试一两次有效，但如果接口一直超时，说明可能是网络环境、账号权限或模型本身的问题，继续重试只会浪费时间和费用。

5.3 什么时候加入功能调用和队列

当 CustomGPT 需要查数据库、查天气、调内部系统时，可以使用 function calling 或工具调用。这个能力让模型不只是生成文本，还能触发真实操作。

但我不建议第一个版本就做工具调用。先把纯文本对话跑稳，把日志和错误处理做好，再考虑模型如何决定“什么时候调用某个函数”。工具调用会增加状态复杂度，一旦模型误判，可能会出现重复切换、参数遗漏、流程卡死等问题。

如果任务量很大，比如每天要处理上万条请求，还需要引入队列。FastAPI 接口接收请求后，先把任务写入队列，由后台 worker 慢慢消费。这样既能削峰，也能控制并发。

6. 常见问题定位与排查顺序

自己搭 CustomGPT 一定会遇到问题。我总结过一套排查顺序：先看现象，再看输入，再看环境，再看参数，最后才怀疑模型本身。

6.1 请求失败、超时、上下文过长

如果请求直接报错，先看错误信息里的错误类型。

这里最容易忽略的是：报错不一定是模型问题，可能是你发的消息格式不对。比如消息类型不是字符串，角色值写错，或者塞了太大的图片。先把请求体打出来看一遍，往往比猜更快。

6.2 输出质量不稳定

输出质量不稳定的原因通常不是模型变笨了，而是输入变化了。

• 用户问题表述变了，检索到的知识片段不同。
• 历史消息累积后，模型被之前的错误回复带偏。
• temperature 太高，回答随机性大。
• 系统提示词互相冲突，模型不知道该听哪句。

如果只是偶尔不稳定，可以尝试降低 temperature。如果是批量任务，开几次结果不一致，建议把 temperature 调到 0.2 或更低，并固定系统提示词。

如果输出为空，先看日志里模型返回了什么。有时候是max_tokens太小，模型刚生成几句就被截断；有时候是增量输出没有被正确拼接，只取了第一段。

6.3 费用增长异常

费用异常增长，很少是平台乱扣费，更多是你自己在不断重复消耗。

优先检查这几个地方：

1. 历史消息是不是无限增长。
2. 检索上下文是不是每次都把所有文档全部塞进去。
3. 是否有循环重试脚本，失败后无限调用。
4. max_tokens是否设置得过大，导致输出浪费。
5. 是否在测试时走了更贵的模型，比如大模型或带视觉的模型。

我一般会在每次请求前后记录 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 才算真正落地了。