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_KEYyour_key_here MODEL_BASE_URLhttps://your-endpoint.example.com MODEL_NAMEyour-model-nameimport 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, temperature0.7, max_tokens1024): 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, datajson.dumps(payload).encode(utf-8), headers{ Content-Type: application/json, Authorization: Bearer os.environ[MODEL_API_KEY], }, methodPOST, ) with urllib.request.urlopen(req, timeout60) 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, retries2, backoff1.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用量、失败原因没有这些数据出问题你只能靠猜。密钥是不是通过环境变量注入、没有进仓库有没有设置额度告警有没有对单用户做频率限制防止一个人把额度刷完体验侧等待时有没有加载态失败时有没有可操作的提示比如重试按钮而不是一句冷冰冰的报错结果能不能复制、能不能清空重来这些都是小事但用户对产品的判断就来自这些小事。我个人在实际操作中的体会是入门篇最容易犯的错不是技术难而是跳过验证直接堆功能。把一次调用返回一句合理的话这件事做到稳定、可观测、成本可控比多做三个花哨功能有价值得多。后面要加检索增强、加多轮记忆、加工具调用全建立在这条链路的稳定性上。链路不稳上面的东西都是沙子上的楼。最后分享一个具体的调试习惯准备五到十条固定的测试输入覆盖正常、边界超长、空、特殊符号、刁钻诱导编造三类情况。每次改提示词或换模型先跑这组用例再上线。这个习惯帮我省下的返工时间比任何技巧都多。
