1. 从零起步：AIGC应用到底在做什么

这两年凡是聊到AI，十句话里八句绕不开AIGC。但真到自己动手做一个应用，很多人会卡在第一步：不知道边界在哪里。我见过不少朋友，脑子里想的是"我要做一个类似智能助手的东西"，然后打开编辑器就懵了——从哪写起？调哪个接口？界面怎么搭？钱怎么算？

先把话说透：所谓打造自己的AIGC应用，本质上是三件事的组合——把用户的输入整理成模型能懂的格式（提示词工程），把模型返回的内容接住并处理（接口调用与结果解析），再把结果呈现给用户（前端与交互）。技术栈听着玄乎，拆开看就是"发请求、收数据、做展示"这一条链路，和早年间调用天气接口、地图接口没有本质区别，区别在于返回的东西是自然语言，不确定性更高，需要额外做容错和体验设计。

为什么现在是个好时机？因为门槛被拉平了。以前要自己训练模型，动辄几十张显卡、几周时间、几万块成本，个人根本玩不起。现在主流的做法是调用成熟的大模型服务，你只需要关心提示词怎么写、业务逻辑怎么串、用户想要什么。算力、权重、推理优化这些脏活，交给服务方去扛。对入门者来说，这是最务实的路径：先跑通一个能用的东西，再谈优化和自建。

这篇内容适合谁？三类人。第一类是有基础编程能力但没碰过AI接口的开发者，比如写过前端、写过后端脚本，想接个大模型试试水；第二类是产品、运营、设计岗的同学，想搞清楚一个AIGC应用内部的骨架长什么样，方便和开发对话，或者自己用低代码平台搓个原型；第三类是纯好奇的技术爱好者，不指望做产品，就想弄明白"我输入一句话，它凭什么能回我一段话"。

我会把这条链路从头到尾走一遍：选哪个模型服务、密钥怎么管、请求怎么发、提示词怎么调、流式输出怎么做、成本怎么控、上线前要防哪些坑。每一个环节我都会说明白"为什么这么选"，而不只是"这么写就对了"。因为入门篇最怕的就是照抄代码跑通了，一换场景就抓瞎——理解了取舍逻辑，你才有能力在遇到新问题时自己找答案。

这里先给一个心理预期：入门阶段不要追求"做一个大而全的AI产品"。我踩过的第一个坑就是想太多，一上来就设计用户系统、计费模块、对话历史管理，结果两周过去连一句正常的回复都没调出来。正确的顺序是：先让一句请求返回一句合理的话，再加功能。一次只加一层，每层都验证通过，这是最省时间的方式。

2. 开工前的选型：模型、语言、框架怎么定

2.1 模型服务选型的三个判断维度

选模型不是选"最强"的，是选"最合适当前阶段"的。我一般看三个维度。

第一是能力匹配度。你要做的应用是文字对话、内容总结，还是要处理图片、要写代码、要做结构化抽取？不同模型在不同任务上的表现差异很明显。有些模型擅长长文本理解，有些在代码生成上更稳，有些对中文语料的处理更自然。入门阶段建议先用通用能力强、文档齐全的模型跑通全流程，等你明确知道业务瓶颈在哪，再考虑换模型或者做多模型路由。

第二是接入成本。包括两个方面：一是接口协议是否标准，主流服务基本都提供HTTP接口，请求体是JSON，这点都差不多；二是文档和示例是否够用。文档质量直接影响你第一次跑通的时间，我见过有些服务文档写得含糊，参数含义要靠猜，调试成本翻好几倍。入门阶段别在这上面省时间，挑那种"复制示例改两行就能出结果"的。

第三是计费模式和预算。这个很多人忽略。大模型服务通常按token计费，输入和输出的单价可能不同，输出一般更贵。你要做的应用如果输出很长（比如写文章、生成报告），成本会比你想的高。还有一种情况是流式输出，虽然体验好，但用户中途关掉页面，已经生成的token照样计费。所以预算要留余量，别按理论最低值估算。

注意：不要同时接入三家服务商做"备份"。入门阶段先把一家吃透，知道它的脾气——响应多快、什么情况下会失败、返回格式有什么小坑。多路接入是稳定性的第二步，不是第一步。

2.2 开发语言与框架的取舍逻辑

语言层面没什么争议：用你手上最熟的那门。AIGC应用的核心是HTTP请求和JSON处理，任何主流语言都能干。Python生态在这块更厚一些，SDK、示例、社区问答都多；JavaScript/TypeScript的优势是前后端能共用一套语言，做Web界面时顺手；Go适合对并发和资源占用有要求的场景。入门阶段别为了"技术先进"去学新语言，学习成本会淹没项目本身的价值。

框架层面要分清两个层次。服务端框架负责接收请求、调度模型接口、处理鉴权；前端框架负责渲染对话界面。入门做原型，我强烈建议先用最小结构：一个HTTP服务 + 一个静态页面，甚至先不写界面，用命令行或接口调试工具验证链路。等链路稳定了，再套React、Vue这些框架做交互。原因很简单——界面会掩盖问题。你在页面上点一下，转圈三秒出了结果，你以为是接口慢，其实是前端状态管理写错了。先脱离界面验证，出问题定位快十倍。

如果你确实想快速出个能看的原型，可以考虑低代码方案：拖拽组件、配置接口地址、绑定字段。这类工具适合验证产品想法，不适合讲清楚技术细节，也不利于后续扩展。我的建议是两种都试一次——用低代码半小时看到效果，建立信心；再手写一遍核心链路，理解每一步在干什么。这两件事不冲突，反而是互补的。

2.3 密钥管理：入门阶段最容易埋雷的地方

这一条我要单独拎出来讲，因为见过太多人在这里翻车。调用模型服务需要一个身份凭证，通常是密钥字符串。绝对不要把它写死在代码里然后提交到公开仓库。这个错误的代价可能是真实的账单损失——有人会扫描公开仓库里的密钥然后盗用额度。

正确做法是走环境变量。本地开发时把密钥放在一个不被版本管理跟踪的配置文件里，通过环境变量注入进程；部署到服务器时用平台的配置管理功能注入。代码里只读环境变量，永远不出现明文。

# .env 示例（此文件必须加入版本管理的忽略列表） MODEL_API_KEY=your_key_here MODEL_BASE_URL=https://your-endpoint.example.com MODEL_NAME=your-model-name

import os api_key = os.environ.get("MODEL_API_KEY") if not api_key: raise RuntimeError("缺少模型密钥，请检查环境变量配置")

提示：密钥一旦泄露，立刻去控制台作废并重新生成，不要心存侥幸。另外给密钥设置额度上限，万一出事损失可控。

还有一点值得提醒：不要在前端代码里直接调用模型服务。前端代码是公开的，任何写进去的密钥都等于公开。正确架构是你的服务端持有密钥、负责调用，前端只和你的服务端通信。这多了一层转发，但这一层是必需的——它同时也是你加限流、加日志、加内容审核的地方。

3. 打通核心链路：第一次成功调用的完整过程

3.1 请求结构拆解：每一段在干什么

一次模型调用的请求体，核心就几个字段。我把它拆开讲透，因为后续所有问题几乎都能从这几个字段里找原因。

消息列表是主体。它不是一个字符串，而是一个数组，每个元素有角色和内容。常见角色有三种：系统角色用来设定模型的整体行为边界，比如"你是一个简洁的技术助手，回答不超过三句话"；用户角色是用户这次说的话；助手角色是模型之前的回复。多轮对话就是把历史消息按顺序全部带上，模型据此理解上下文。这里有个容易被忽略的点：模型本身没有记忆。你感觉它能"记住"前面聊的内容，是因为你每次都把历史重发了。这意味着对话越长，每次请求的输入token越多，成本越高。多轮对话的成本控制，后面会专门讲。

生成参数决定了模型怎么回答。温度值控制随机性，数值低的时候输出更确定、更适合事实性问答，数值高的时候更发散、适合创意和头脑风暴。最大输出长度限制回复的篇幅，防止跑飞。还有一个参数控制"多样性采样"，入门阶段可以先不碰，但要知道它的存在——温度调到很低时输出会变得机械重复，这时候调整采样参数比继续降温度更有效。

一次完整请求的样子大致如下：

import os import json import urllib.request def call_model(messages, temperature=0.7, max_tokens=1024): url = os.environ["MODEL_BASE_URL"].rstrip("/") + "/v1/chat/completions" payload = { "model": os.environ["MODEL_NAME"], "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } req = urllib.request.Request( url, data=json.dumps(payload).encode("utf-8"), headers={ "Content-Type": "application/json", "Authorization": "Bearer " + os.environ["MODEL_API_KEY"], }, method="POST", ) with urllib.request.urlopen(req, timeout=60) as resp: return json.loads(resp.read().decode("utf-8")) result = call_model([ {"role": "system", "content": "你是一个简洁的技术助手。"}, {"role": "user", "content": "用一句话解释什么是token。"}, ]) print(result["choices"][0]["message"]["content"])

这段代码刻意用标准库写，不依赖任何第三方包，目的是让你看清请求的原始形态：拼URL、拼JSON、加请求头、发POST、解析响应。你理解了这一层，换任何语言、任何SDK都能对应上。

响应体里通常包含三块有用信息：生成的内容、token用量、结束原因。token用量一定要打印出来看，它是你算成本的唯一依据。结束原因告诉你为什么停：正常结束、达到长度上限、被内容策略拦截。这三个值对应三种完全不同的处理逻辑，后面排查问题时是第一条线索。

3.2 提示词怎么写才不返工

提示词是AIGC应用里最像"手艺"的部分。同一个请求，换个写法，结果质量能差出一个档。我总结了一套实用套路，按顺序套基本不会太差。

先给角色和任务，再给约束，最后给格式。顺序有讲究：任务在前，模型知道要干什么；约束在中，模型知道边界；格式在后，模型知道怎么交付。反过来写效果会打折。例如做内容摘要，不要只说"帮我总结一下"，而是"你负责把长文压缩成要点。只保留事实性信息，不加入评价。输出为三个以内的短句，每句不超过二十字"。约束越具体，输出越可控。

用示例代替描述。这条是最有效的技巧。想让模型输出某种特定格式，与其用一大段文字描述格式，不如直接给一个输入输出的例子。模型从例子里学格式的能力很强。做结构化抽取时尤其明显——你给一个"输入文本 → 输出JSON"的样例，准确率会明显上升。

把负面要求换成正面要求。很多人爱写"不要啰嗦、不要加客套话"，模型对否定指令的遵循度有限，有时候反而会被"啰嗦"这个词带偏。改成"直接给出结论，每句都要包含具体信息"这种正面表述，效果稳定得多。

留出兜底路径。真实应用里，用户的输入千奇百怪，总有模型处理不了的情况。提示词里加一句"如果信息不足，请明确说明缺少什么，不要猜测"，能显著减少编造内容的情况。编造内容（业内常说的"幻觉"）在入门阶段不需要根治，但必须能被识别——你的应用要对"我无法确定"这类输出有处理路径，而不是直接展示给用户。

实操心得：提示词不要一次改十个地方。每次只改一处，跑十个用例对比结果，这样你才知道是哪个改动起了作用。凭感觉大改，最后效果好你也不知道为什么好，换个场景就复现不了。

3.3 流式输出：体验提升最明显的一个改动

不带流式的调用，用户点完按钮要盯着空屏等好几秒甚至十几秒，体验很差。流式输出让内容一个字一个字地出来，同样的总时长，感知速度快了不止一倍。这是入门阶段性价比最高的一个优化。

实现上，服务端向模型发起流式请求，模型会以数据块的形式持续返回增量内容；你的服务端把这些块原样转发给前端，前端每收到一块就往页面上追加。要注意两个技术细节：一是服务端必须关闭响应缓冲，否则数据攒着不发，流式就变成了"一次性慢速返回"；二是前端追加内容时要注意换行和空白的处理，很多早期版本在这里出现排版错乱。

# 服务端转发流式响应的核心思路（框架无关的伪代码） def stream_to_client(user_input, client): messages = [{"role": "user", "content": user_input}] for chunk in model_stream(messages): text = extract_delta(chunk) if text: client.write(text) client.flush() # 关键：立刻推给前端，不要缓冲

还有一个实际问题：流式输出的计费和统计。因为数据是边生成边返回的，用量统计通常在流的最后一块里给出，也可能需要你自己累加字数估算。如果你的应用有配额限制，务必在流结束后把用量落库，否则用户刷新页面就绕过了限制。

流式还有一个隐藏好处：它能提前中断。用户发现回答跑偏了可以直接点停止，你也能主动掐断，避免继续消耗额度。这个能力在长输出场景下很有价值，非流式调用就做不到——一旦发出请求，只能等它跑完。

4. 从能跑到好用：成本、稳定性与上线前的功课

4.1 成本控制的四个杠杆

很多人第一次看到账单会愣一下，其实成本是可以算清楚的。核心变量是token数量，而token数量取决于你的输入长度、输出长度和调用次数。四个杠杆，按效果排序。

第一个杠杆：裁剪历史消息。多轮对话里，历史消息全带上是最简单的做法，但成本会随轮次线性上涨。可行的优化是只保留最近若干轮，或者把更早的对话压缩成一段摘要放进系统消息。摘要的做法是让模型自己总结前文，再把摘要作为上下文。这中间会有信息损失，但对大多数客服、问答类应用完全够用。

第二个杠杆：控制输出长度。输出token通常比输入贵，而且输出长度是你最能控制的部分。给最大输出长度设一个合理上限，同时在提示词里明确要求精简。我见过一个应用把上限设成四千，结果用户问一句"你好"，模型也洋洋洒洒写一大段，纯属浪费。

第三个杠杆：请求前先做判断。不是所有请求都需要调用大模型。简单分类、格式校验、关键词匹配这些能本地做的，就别浪费一次调用。比如用户输入为空、超长、明显是测试内容，直接在前置逻辑里处理掉。

第四个杠杆：缓存。相同或高度相似的问题，答案可以缓存一段时间。这在FAQ类场景特别有效。要注意的是缓存键的设计——不能只按用户输入原文做键，还要考虑上下文是否一致，否则多轮对话里会串答案。

4.2 失败处理：把异常当常态来设计

入门阶段最常见的认知偏差是"接口应该是稳定的"。实际不是。超时、限流、返回格式异常、内容被拦截，这些都会发生，而且不算罕见。你的应用必须把它们当正常路径来处理。

超时要有自己的阈值，不要用默认的无限等待。设一个合理上限，超了就重试或者给用户明确提示。限流要看服务方的并发和频率限制，在客户端做令牌桶或者简单排队，别一上来就打满。重试要区分情况：网络抖动可以重试，参数错误重试多少次都没用，反而浪费额度。格式异常要能兜住——模型有时会返回非预期的结构，解析时用防御性写法，别直接取值导致整个请求崩掉。

import time def call_with_retry(fn, retries=2, backoff=1.5): last_err = None for i in range(retries + 1): try: return fn() except TimeoutError as e: last_err = e time.sleep(backoff ** i) # 指数退避，避免瞬间打满 except ValueError: raise # 参数类错误不重试 raise last_err

注意：重试必须有次数上限和退避间隔。见过有人在循环里无脑重试，一次故障直接烧掉大半额度。

4.3 上线前必须过的几道检查

从"我本机能跑"到"别人能用"，中间隔着一串检查。我列一份自己每次都会过的清单。

输入侧：长度上限有没有？空输入怎么处理？超长输入是截断还是拒绝？用户输入里带有的特殊字符会不会破坏你的提示词结构？最后一条容易忽略——如果用户输入被直接拼进提示词，某些精心构造的输入可能让模型偏离原本的指令，这就是常说的提示词注入。入门阶段不用做到滴水不漏，但至少要把用户输入和系统指令在结构上分开。

输出侧：返回为空怎么办？被内容策略拦截怎么提示用户？流式中途断开，前端能不能正确收尾而不是卡住？这些细节决定用户觉得你的应用"稳不稳"。

运行侧：日志有没有记录请求耗时、token用量、失败原因？没有这些数据，出问题你只能靠猜。密钥是不是通过环境变量注入、没有进仓库？有没有设置额度告警？有没有对单用户做频率限制，防止一个人把额度刷完？

体验侧：等待时有没有加载态？失败时有没有可操作的提示（比如"重试"按钮）而不是一句冷冰冰的报错？结果能不能复制、能不能清空重来？这些都是小事，但用户对产品的判断就来自这些小事。

我个人在实际操作中的体会是，入门篇最容易犯的错不是技术难，而是跳过验证直接堆功能。把"一次调用返回一句合理的话"这件事做到稳定、可观测、成本可控，比多做三个花哨功能有价值得多。后面要加检索增强、加多轮记忆、加工具调用，全建立在这条链路的稳定性上。链路不稳，上面的东西都是沙子上的楼。

最后分享一个具体的调试习惯：准备五到十条固定的测试输入，覆盖正常、边界（超长、空、特殊符号）、刁钻（诱导编造）三类情况。每次改提示词或换模型，先跑这组用例再上线。这个习惯帮我省下的返工时间，比任何技巧都多。