企业官网建设流程全解析

现代生成式 AI 这个词这两年几乎被用烂了，但真正动手把大模型能力接进自己项目里的人，感受往往和看新闻完全不同。我最初接触这套东西的时候，以为无非是调个接口、传段文字、拿回结果，结果第一个真实需求就把我按在地上摩擦——要做一个能根据用户零散描述自动生成结构化文案的内部工具，输入是几句口语化的需求，输出得是分好段落、带小标题、语气统一的成品。听起来简单，可一旦开始选模型、设计提示、处理上下文、控制成本、兜底异常，问题就一个接一个冒出来。这篇内容就是把我从零搭这套生成式 AI 应用的完整思路拆开讲清楚，涉及 ChatGPT 系列模型和 OpenAI 平台上的各类模型怎么选、提示怎么设计、调用怎么组织、效果怎么稳住。适合已经会写代码、想把大模型真正用进产品里的开发者，也适合刚接触这块、想少走弯路的技术同学。我不会只给你一堆 API 参数，而是把每个决定背后的原因讲透，让你看完能直接照着搭出自己的第一版。

1. 先搞清楚"生成式 AI 应用"到底在解决什么问题

很多人一上来就问"用哪个模型最好"，这个问题本身就问偏了。模型选型是结果，不是起点。真正要先回答的是：你的场景里，输入是什么形态、输出要满足什么约束、容错空间有多大。这三件事决定了后面所有的技术选择。

1.1 从"输入输出契约"反推技术方案

我习惯把任何一个生成式 AI 需求先写成一个契约：输入是一段什么内容，输出必须满足哪些硬性条件。比如前面说的文案生成工具，契约大概是这样的——输入是 20 到 200 字的自然语言需求描述，输出是 300 到 500 字、包含 3 个小标题、语气偏正式的中文文案。这个契约一写出来，很多问题就自动浮现了：输出长度有下限，意味着模型不能太"懒"；有结构要求，意味着光靠一句"帮我写个文案"肯定不行；语气要统一，意味着得给风格示例。

把契约写清楚的好处是，你能提前判断哪些环节需要额外工程手段。输出长度不够，可能需要提示里明确字数区间，甚至加一个后处理校验；结构不稳定，可能需要用结构化输出格式约束；语气漂移，可能需要 few-shot 示例。这些判断如果等到调完接口发现效果不对再回头补，成本会高很多。

我见过不少团队跳过这一步，直接拿一个 demo 提示去试，觉得"效果还行"就上线，结果真实用户输入千奇百怪，输出质量断崖式下跌。契约思维的本质是逼你在动手前想清楚边界，而不是被 demo 的偶然好结果骗过去。

1.2 生成式能力和传统程序逻辑的边界在哪

这是我最想强调的一点。生成式 AI 擅长的是"在模糊输入下产出合理内容"，它不擅长的是"精确计算、严格状态管理、确定性判断"。很多项目失败的根源，是把本该用传统代码做的事交给了模型。

举个具体例子。假设你要做一个根据用户填写的表单生成周报的工具。表单里有姓名、部门、本周完成事项、下周计划。姓名和部门这种字段，绝对不该让模型去"生成"，直接字符串拼接就行，模型只负责把"完成事项"和"计划"这两块自由文本润色成连贯的段落。如果你图省事把整个周报都丢给模型生成，它可能会把姓名写错、把部门编造出来，这种错误在真实业务里是灾难性的。

所以我的原则是：确定性内容用代码拼，模糊内容用模型生成，两者在提示里明确分工。提示里可以这样写——"以下姓名和部门信息由系统提供，你必须原样使用，不得修改；你需要做的是把完成事项和计划润色成通顺的周报正文"。这样既利用了模型的润色能力，又规避了它乱改事实的风险。

1.3 一个容易被忽略的前置问题：内容安全与合规

动手之前还有一件事必须想清楚：你的应用会不会生成不该生成的内容。这不是危言耸听，真实场景里用户输入什么都可能发生。我的做法是在提示层面加约束，在输出层面加校验，两道防线。

提示层面，系统消息里明确写清楚"只围绕给定主题生成内容，遇到与主题无关或不当的请求，礼貌拒绝并引导回正题"。输出层面，对生成结果做关键词过滤和格式校验，不符合预期就触发重试或降级到预设文案。这套机制看起来笨，但在实际运行里能挡掉绝大多数意外情况。别指望模型自己永远听话，工程上的兜底永远不能省。

2. 模型选型：不是越贵越好，而是匹配场景

OpenAI 平台上模型不少，名字还经常更新，新手很容易懵。我按实际使用经验给一个判断框架，而不是罗列一堆参数让你自己纠结。

2.1 按任务复杂度分层的选型思路

我的经验是把任务分成三档，对应不同档位的模型。

这个分档不是绝对的，但能帮你快速定位。我踩过的坑是：一开始所有任务都用最强模型，账单吓人不说，延迟还高，用户体验反而差。后来把意图识别这种轻活拆给小模型，整体成本和响应速度都明显改善。

2.2 上下文窗口不是越大越划算

很多人看到大上下文窗口就兴奋，觉得可以把整本手册塞进去。实际用下来，上下文越长，两个问题越明显：一是成本线性上升，二是模型对中间部分的注意力会下降，也就是常说的"中间遗忘"。

我的做法是分层处理长文档。先用一个轻量步骤把长文档切成段落并打标签，检索时只把最相关的几段拼进上下文，而不是整篇塞入。这样既控制了 token 消耗，又让模型聚焦在真正相关的内容上。如果你的场景确实需要全局理解，再考虑用大窗口模型，但要接受相应的成本和延迟代价。

2.3 结构化输出能力要单独验证

如果你的应用需要模型返回 JSON 之类的结构化数据，选型时一定要单独测这一项。不同模型对格式约束的遵循程度差别不小。我的验证方法是准备 20 条真实输入，要求模型按固定 schema 输出，统计格式正确率和字段完整率。格式正确率低于 95% 的模型，在需要严格解析的场景里就要谨慎，或者必须配合后处理修复。

这里有个实用技巧：优先使用平台提供的结构化输出能力（比如指定 JSON schema），而不是只在提示里写"请返回 JSON"。前者是硬约束，后者是软约束，稳定性差一个量级。

3. 提示设计：决定效果上限的核心工程

模型选对了，提示写不好照样白搭。提示设计是这套东西里最像"手艺"的部分，但也不是玄学，有明确的可操作方法。

3.1 系统消息、用户消息、示例的分工

一条完整的请求通常由三部分组成：系统消息定角色和规则，用户消息给具体任务，示例（few-shot）定风格和格式。三者分工要清晰，别混在一起。

系统消息我一般写三块内容：角色定位（你是一个什么助手）、行为规则（必须做什么、禁止做什么）、输出格式要求。用户消息只放本次任务的具体输入。示例放在系统消息之后、用户消息之前，给两到三个高质量样例。

这里有个细节很多人忽略：示例的质量比数量重要得多。两个精心挑选、覆盖不同情况的示例，效果往往好过五个随意凑的。我选示例的标准是——一个典型正例、一个边界情况、一个需要特殊处理的例子。这样模型能学到的不只是"长什么样"，还有"遇到不同情况怎么变"。

3.2 用"约束清单"代替模糊描述

"写得好一点""语气专业一些"这种描述，模型理解起来非常不稳定。我的做法是把模糊要求翻译成可检查的约束清单。比如"语气专业"可以拆成：不使用口语化感叹词、不使用网络流行语、句子平均长度控制在 25 字以上、每段有明确主题句。这些约束写进提示，模型的可执行性会强很多。

再比如输出长度，别写"不要太长"，直接写"正文控制在 350 到 450 字之间"。数字约束比形容词约束可靠得多。我实测下来，凡是能用数字、列表、明确条件表达的约束，都尽量量化，效果稳定性提升非常明显。

3.3 提示迭代要有记录和对比

提示不是一次写成的，是改出来的。我强烈建议建一个简单的测试集：20 到 30 条真实输入，覆盖典型场景和边界情况。每次改提示，都跑一遍测试集，记录输出质量。没有这个测试集，你改提示全靠感觉，改好改坏都不知道。

我的记录方式是给每条输出打两个分：格式合规（是/否）和内容质量（1 到 5 分）。改完提示对比前后分数，只有明显提升才保留改动。这套笨办法帮我避免了很多"感觉变好了其实变差了"的误判。

4. 调用组织：把单次调用变成可靠系统

单次调接口跑通 demo 很容易，难的是让它稳定、可维护、成本可控。这一层是工程能力的体现。

4.1 重试、超时与降级的三层兜底

网络请求永远可能失败，模型输出永远可能不合规。我的标准配置是三层兜底。

第一层是超时控制。给每次请求设一个合理超时，比如 30 秒，超时就中断，避免请求堆积拖垮整个服务。第二层是重试。对超时和临时性错误做有限次重试，比如最多 2 次，且重试之间加退避间隔，避免瞬间打爆接口。第三层是降级。重试仍失败或输出不合规时，返回预设的兜底内容，保证用户至少能看到一个合理结果，而不是报错页面。

这三层缺一不可。我见过只做重试不做降级的实现，结果模型持续返回不合规内容时，用户看到的就是无限转圈。降级方案哪怕粗糙，也比没有强。

4.2 输出校验与自动修复

模型返回的内容不能直接信任，尤其是结构化输出。我的做法是拿到结果先做 schema 校验，字段缺失或类型不对就触发一次"修复调用"——把错误信息和原始输出一起发给模型，让它只修复格式问题，不改变内容。这个修复调用通常一次就能解决大部分格式问题，比整体重试更省成本。

对于自由文本输出，校验重点是长度、敏感词、格式标记是否完整。不通过就走降级或重试。这套校验逻辑要写成独立模块，别散落在业务代码里，否则后面维护会很痛苦。

4.3 成本控制的几个实操手段

成本这块，除了前面说的按任务分档选模型，还有几个立竿见影的手段。一是缓存，相同或高度相似的输入直接返回缓存结果，很多场景下重复请求比例不低。二是精简提示，把系统消息里用不上的规则删掉，示例控制在必要数量，长期看能省不少 token。三是限制输出长度，在提示里明确上限，避免模型啰嗦。

我做过一个粗略统计，光是把提示里的冗余描述精简掉三成，加上对高频输入的缓存，整体调用成本能降下来相当可观的比例。这些优化不改变效果，纯粹是工程层面的收益，值得花时间做。

5. 实测中那些文档不会告诉你的坑

这部分是我最想分享的，因为都是真金白银踩出来的。

5.1 模型对"否定指令"的遵循不稳定

提示里写"不要使用感叹号"，模型有时候还是会用。这不是模型不听话，而是否定式指令本身就难遵循。我的解决办法是改成正面指令："所有句子以句号结尾"。正面描述"要什么"比负面描述"不要什么"可靠得多。凡是能转成正面表述的约束，都转。

5.2 长对话里的指令遗忘

多轮对话场景下，系统消息里的规则在轮次多了之后会被"稀释"。我的应对是把最关键的规则在每轮用户消息前简要重申一次，或者用平台提供的会话状态管理能力把系统规则固定在更高优先级。实测下来，关键规则重申能明显降低后期轮次的违规率。

5.3 中文场景下的标点和格式细节

中文生成里，模型有时会中英文标点混用，或者段落之间空行不一致。这些细节在 demo 里不明显，上线后用户一眼就能看出来。我的做法是在提示里明确"使用中文全角标点，段落之间空一行"，并在输出后做一次轻量清洗，统一标点和空行。这种后处理成本极低，但对成品观感提升很大。

5.4 别用模型做它不擅长的事

最后再强调一次边界问题。数值计算、精确日期推算、复杂状态判断，这些交给代码。模型负责语言组织和模糊决策，代码负责确定性和精确性。把这条线划清楚，项目成功率会高很多。我见过让模型算折扣价格的实现，结果偶尔算错，这种错误在业务里是不可接受的。能用代码算的，绝不用模型算。

这套东西搭下来，我的体会是：生成式 AI 应用的门槛不在调通接口，而在把不确定性管住。模型本身是个概率系统，你要做的是用工程手段把它约束在一个可接受的范围内。选型匹配场景、提示量化约束、调用三层兜底、输出严格校验，这四件事做到位，一个能真正上线的生成式 AI 应用就成型了。后面再想提升，无非是在测试集上持续迭代提示、按数据反馈调整模型档位，都是在这个框架里做增量优化。