企业官网建设流程全解析

三月初，一个做客服系统的团队找到我，说他们花了两个礼拜搭的智能问答上线三天就被业务方退回来了。我第一反应是模型不行，结果翻完他们的方案发现，模型换过三个，提示词改了十几版，唯独没人回答过一个最基础的问题：这套东西在整条业务链路里到底站哪个位置。他们把它当成一个"能回答任何问题"的入口，而业务方想要的是一个"能在工单流转卡住时给出一句判断"的助手。位置错了，后面所有的调参、换模型、加检索，全是在错的坐标系里做优化。这件事之后我养成了一个习惯，每接一个新的AI需求，先在纸上画一条链路，标清楚哪个环节要人、哪个环节要机器、机器出错了谁来兜。这篇是我个人关于AI落地思路的部分整理，属于系列第一篇，不谈某个具体框架怎么装、某个API怎么调，只谈那些反复被验证、也反复被忽略的判断逻辑。适合正在做AI功能但总觉得"效果差一口气"的人看，也适合刚接手相关项目、还没被坑过的同学提前避一避。

1. 先定位AI在链路中的角色，再谈任何技术选型

我见过最多的返工，不是技术选错，是角色错位。团队一上来就讨论用哪个模型、上下文窗口多大、要不要上向量库，但没人说清楚这东西是替人做决定，还是帮人做决定。这两个字的差别，决定了后面所有的架构、评估方式和容错设计。

1.1 放大器、替代者、兜底者，三种定位的代价完全不同

我把AI在业务链路里的角色粗分成三类，你可以对照自己手上的项目看看落在哪一类。

放大器：人做主，AI提供素材、初稿、候选。比如写文案、生成报表解读、给客服提供回复建议。这类项目容错率高，输出错了人一眼能看出来并改掉，所以可以容忍较高的不确定性，模型选型上可以偏向表达质量而非绝对准确，甚至可以适度提高随机性来换多样性。

替代者：AI独立完成一个闭环动作，人只看结果不参与过程。比如自动给工单打标签、自动分流、自动生成对账单。这类项目对准确率的要求陡然上升，因为错误会直接进入下游系统。此时你要考虑的不是"回答得好不好"，而是"错了会不会造成不可逆后果"，凡是不可逆的动作，必须加人工确认或者二次校验。

兜底者：正常流程走不通时，AI接住那部分长尾。比如规则引擎匹配失败的查询、知识库找不到的标准问题。这类场景的特点是输入分布极不规范，你不能指望提示词覆盖所有情况，重点要放在"识别自己不会"这件事上，宁可拒答也不能瞎编。

下面这张表是我自己用来快速判断的，虽然粗糙但很实用：

我个人的经验是，绝大多数翻车的项目都把自己当成了"替代者"，实际能力只够"放大器"。业务方看到demo觉得惊艳，是因为demo是团队自己挑的样本；上线后真实请求一进来，错误率立刻暴露。所以定位这件事不能由技术团队单方面拍板，得拉着业务方一起确认：这个环节出错，代价是什么，谁来承担。

1.2 定位错了会引发哪些连锁反应

角色错位的代价是连锁的，不是单点的。我梳理过几个典型链条。

第一个链条是评估标准错配。如果实际是放大器定位，你却按替代者的标准去评估，会陷入无休止的准确率焦虑，明明产品已经够用了，还在为了两个百分点反复折腾；反过来，明明是替代者定位，却用"看起来还行"来验收，上线后错误直接进下游，补救成本是开发成本的好几倍。

第二个链条是交互设计错配。放大器定位的产品，界面应该鼓励人修改，把AI输出放在可编辑区域，标出来源段落；替代者定位的产品，界面应该强调确认动作，把AI的判断和依据摆在一起让人一眼扫完点确认。我见过一个工具把AI结论直接写进数据库、界面上只显示一个成功提示，结果出了问题连回溯都做不到。

第三个链条是容错设计缺失。定位为替代者却没有降级路径，模型超时或返回格式错乱时整个流程卡死。这类事故在我经手的项目里出现过不止一次，根本原因就是设计阶段压根没考虑"AI会失败"这个前提。

提示：判断角色定位有个简单办法，问一句"这个环节AI做错了，用户多久能发现"。如果答案是"永远发现不了"，那它就是替代者，必须加校验；如果是"一眼就看出来了"，那它是放大器，可以把精力放在体验上。

2. 模型能力的判断，别拿榜单当结论

选型环节我踩过最深的坑，是相信了公开评测榜单。榜单上的分数是在特定数据集、特定提示格式下测出来的，和你手上的真实输入差得很远。一个在通用问答上排名靠前的模型，放到你这种充满行业黑话和缩写的数据上，可能还不如一个参数量只有它几分之一的开源模型。

2.1 用二十条真实样本做一次"野测"

我现在固定会做一件事：从线上日志或者业务方手里，捞二十到三十条真实输入，不做任何清洗和美化，直接丢给候选模型跑。这二十条要有代表性，我一般按这个比例配：

• 六到八条是高频常规样本，用来确认基础能力是否够用
• 五条左右是边界样本，比如特别长、特别短、带错别字、中英混排
• 五条是"刁钻但合理"的样本，业务方最在意的那类难题
• 三条是明显不该被回答的样本，用来观察模型会不会瞎编

跑完之后不看总分，看分布。如果常规样本全对、边界样本一半崩，说明问题在预处理不在模型；如果刁钻样本全错、常规样本也错，说明模型压根不具备这个领域的基础认知，换提示词没用。我做过一次横向对比，四个候选模型在常规样本上差距不到十分之一，但在边界样本上差距能到三倍，最后选的是那个常规样本略差但边界表现稳定的。

这个测试还有个附加价值：它能暴露你的输入到底有多脏。很多团队在选型阶段用的都是人工整理的干净样本，等到接真实数据才发现，用户输入里混着表情符号、全角半角、复制粘贴的表格残片。这时候你会庆幸自己提前看到了。

2.2 把不确定性显式化，而不是祈祷它不存在

模型不会告诉你它有多确定，它只会给你一段流畅的文字。所以你必须自己造一个"不确定性的出口"。我常用的三种做法：

第一种是结构化输出加字段约束。要求模型输出固定字段，其中包含一个置信度或者"无法判断"的标记位。这里要注意，模型自报的置信度往往偏高，不能直接当概率用，但可以用来做相对排序——把置信度低的样本抽出来人工看，命中率比随机抽高不少。

第二种是多路一致性检查。同一个输入用不同温度或者不同提示模板跑三次，看结论是否一致。一致就放行，不一致就转人工。这个办法成本翻三倍，但对准确性要求高的抽取类任务很值，我一般只在关键字段上用，不是全量。

第三种是反向验证。让模型先给结论，再让它自己找反例，如果找得到就降级。这个技巧在事实性问答上比较有效，但要注意别让它变成自我否定，所以在提示里要限定"只找明确的矛盾证据"。

注意：这三种方法都会增加延迟和成本，别一上来全用。先跑基线，看错误集中在哪类样本，再针对性加校验。我见过一个团队把所有校验都堆上，响应时间从两秒变成十一秒，用户直接弃用。

3. 提示词的本质是接口设计，不是咒语

提示词这个词很容易让人误解，好像写几句神奇的话就能激发模型潜能。我的理解是，提示词就是人和模型之间的接口协议，它和函数签名、API参数是一类东西。既然是接口，那就有输入输出规范、有边界情况、有版本管理。

3.1 结构化提示的四个固定槽位

我写提示词基本固定成四块，顺序也基本不变：

角色与职责：一句话说清楚这个模型扮演什么、不做什么。关键是后半句，"不做什么"比"做什么"更重要。比如"你负责从工单描述中抽取故障类型和设备编号，不要推断用户情绪，不要给出解决方案"。

输入说明：明确输入的结构。如果输入是用户自由文本，要说明可能出现的噪声；如果输入是结构化字段，逐个说明含义。这一步很多人省掉，结果模型把某个字段当成了另一回事。

输出规范：给出精确的格式要求，能约束结构就别只靠自然语言描述。现在不少模型支持结构化输出模式，可以传一个字段定义，让它必须按这个结构返回，这比在提示里写"请输出JSON"可靠得多。

边界与兜底：明确什么情况下应该拒答、什么情况下应该返回空值、什么情况下应该走默认分支。这一块最容易被忽略，但恰恰是线上稳定性的关键。

我给一个简化版的模板，实际使用时会根据场景调整：

PROMPT_TEMPLATE = """你是{domain}领域的字段抽取助手。 职责：从下面的工单文本中抽取"故障类型"和"设备编号"两个字段。 不要推断故障原因，不要生成处理建议。 输入文本可能包含错别字、口语化表达、无关寒暄，请忽略无关内容。 输出规范： - fault_type：从给定枚举值中选择，若无法判断填 unknown - device_id：仅提取形如字母加数字的编号，没有则填空字符串 - confidence：0到1之间的数值，表示你对本次抽取的整体把握 边界规则： - 文本为空或与故障无关时，两个字段都填空，confidence 填 0 - 出现多个设备编号时，只取最靠前的一个，并在 confidence 上降低 0.2 工单文本： {text} """

这个模板里最关键的是"边界规则"那一段，它把决策责任从模型的自由发挥转移到了明确的规则上。我改过很多版提示，最后发现提升最大的往往不是增加描述细节，而是补上这些边界。

3.2 从能跑到稳定跑，中间隔着回归集

提示词改一次，效果可能整体变好，也可能在某个子类上悄悄变差。没有回归集，你根本发现不了后者。我的做法是维护一个小文件，里面存三十到五十条输入和期望输出，每次改提示词之前先跑一遍，记录通过率。这个文件不需要多精致，一个表格就够，关键是坚持用。

有个细节值得说：期望输出不要写成绝对精确匹配，尤其是生成类任务。我一般分两档，结构化字段做精确匹配，自由文本用关键要素检查——事先列出这句话必须包含哪几个信息点，缺一个就标记为不通过。这种检查虽然粗，但比人眼扫一遍靠谱，也比引入模型当裁判便宜。

3.3 提示版本管理，别靠记忆

提示词散落在代码各处是灾难的开始。我现在把提示统一放在一个配置里，带版本号和修改说明，每次改动记录改了什么、为什么改、回归集通过率变化。听起来很重，实际上就是多写几行注释的事，但出问题时能救命。有一次线上效果突然下降，查了半天发现是有人顺手改了一句提示里的措辞，如果没有版本记录，这种问题能查一整天。

4. 知识注入的路线选择，先算账再动手

模型不知道你公司内部的事，这是必然的。让它知道的办法有三条路：检索增强、微调、塞进长上下文。我见过太多团队在这三条路之间反复摇摆，其实先算一笔账，答案往往很清楚。

4.1 三条路的成本结构与适用边界

检索增强的核心是把知识存在外部，用时再取。优点是知识更新即时，改一条文档就生效，不用重新训练；缺点是依赖检索质量，检索没召回，模型再强也答不对。适合知识频繁变动、条目数量大、需要给出来源的场景。

微调是把知识或者风格固化进模型参数。优点是不增加推理时的上下文长度，响应快、成本低；缺点是更新麻烦，每次改知识都要重新训练，而且容易把事实记混。适合风格对齐、格式固定、知识相对稳定的场景，比如让模型学会你们内部报告的固定写法。

长上下文是把相关资料整段塞进提示。优点是实现最简单，不用建索引不用训练；缺点是成本和延迟随长度线性上涨，而且模型在超长上下文中间部分的信息利用率会下降。适合资料总量不大、单次查询只需要少量文档的场景。

我习惯用这张表快速判断：

实际项目里这三者经常混用。我自己比较常用的组合是：主体走检索增强，输出风格靠少量样本示例来约束，个别特别长的规范文档直接塞上下文。混用不是坏事，但每一块都要清楚它解决的是哪个问题，别混着混着变成了"哪个都试了一点，哪个都没做好"。

4.2 检索环节翻车最多的地方

检索增强听起来简单，实际上坑集中在几个地方。第一个是分块，块切得太大，召回的内容里一半是噪声，模型被干扰；块切得太小，一句话被切成两半，语义断了。我一般的起点是五百字左右一块，重叠部分留六十到一百字，保证跨块的句子不会被切断。这个参数没有普适最优，必须拿真实问题试。

第二个是查询改写。用户的提问往往很短很口语，直接拿去做向量检索，召回质量很差。我通常加一步改写，让模型把口语问题扩展成几个检索用的关键词，或者生成两三个不同角度的子查询，分别检索后合并结果。这一步对召回率的提升在我自己的测试里相当明显，代价是多一次模型调用。

第三个是重排。向量检索拿到前二十条，再用一个更小的重排模型按相关性排序，取前五条送进上下文。重排模型比通用大模型便宜得多，但效果比纯向量相似度好不少，尤其是处理那种"字面相似但语义无关"的干扰项。

第四个是空召回的处理。检索不到内容时，如果直接把空结果丢给模型，它会开始编。必须有一个显式的判断：召回分数低于阈值就告知用户"没有找到相关资料"，而不是硬答。这个阈值要拿真实数据标定，不能拍脑袋。

4.3 别忽略知识本身的脏乱

我想单独强调一点，很多检索效果差的根因不在技术，在文档本身。同一件事在三份文档里有三种说法，表格被复制成了乱码，过期的制度没删，这些都会直接污染召回结果。我接手过一个项目，团队花了三周调检索参数，最后发现问题是一份两年前的旧文档排在前面，因为它的标题措辞和新问题更接近。删掉旧文档，效果立刻回升。

所以做知识注入之前，先花时间做一轮文档治理：去重、标注生效时间、统一术语、把表格转成结构化描述。这部分工作在很多人眼里是脏活，但它对最终效果的贡献，往往超过换一个更贵的模型。

5. 多步推理与工具调用，先问值不值得

Agent这个词现在被用得很泛，好像不带多步规划就不算AI应用。我实际的观察是，绝大多数业务场景用一条确定的流程就够了，硬上自主规划反而让稳定性和可调试性都下降。

5.1 先做固定流程，再考虑自主决策

固定流程的意思是，步骤是人定的，模型只负责每一步里的判断。比如一个文档审核流程：先抽取关键字段，再逐条比对规则，最后汇总差异。这三步的顺序是写死的，模型在每一步内部做它擅长的事。这种结构的好处是每一步都能单独测、单独换模型、单独加校验，出问题能定位到具体环节。

自主规划的意思是，把目标和可用工具交给模型，让它自己决定调用顺序。这在开放式任务里确实有优势，比如"帮我调研某个话题并整理成报告"，你没法预先规定它查几次、查什么。但代价是可预测性变差，同一输入两次运行可能走不同路径，成本和耗时的波动也大。

我的判断标准是：如果任务的成功路径能被一个熟练的人用文字写清楚，那就做成固定流程；只有当路径本身需要根据中间结果动态决定、且分支数量多到写不完时，才考虑自主规划。按这个标准，我经手的项目里大概只有两成真的需要。

5.2 工具的粒度决定成败

一旦确定要用工具调用，工具怎么切就是关键。切得太粗，一个工具干五件事，模型不知道该传什么参数；切得太细，模型要在十几个工具里选，选择错误率上升，调用轮次也变多。

我倾向的粒度是：一个工具对应一个明确动作，参数不超过四个，返回值结构固定。工具描述里要写清楚"什么时候用"和"什么时候不要用"，后半句尤其重要。比如一个查询订单的工具，描述里应该写"当用户询问具体订单状态时使用；当用户询问退款政策时不要使用，改用政策查询工具"。

还有一个容易忽略的点：工具报错时返回什么。如果工具抛出一个技术异常，模型看到一堆错误堆栈，往往不知道该怎么办，要么重试要么放弃。更好的做法是把错误翻译成模型能理解的话，比如"未找到该订单，可能是编号有误，请向用户确认编号"。这样模型就能自然地追问，而不是卡死。

提示：做工具调用时，务必给整个流程设一个最大轮次上限。我见过模型在两个工具之间反复横跳，一直不收敛，如果没有轮次上限，一次请求能烧掉几十次调用。

6. 评估体系，没有它就谈不上优化

效果好不好，不能靠感觉。我见过太多团队在"感觉还行"和"感觉不太行"之间反复横跳，改了半天不知道是变好还是变坏。评估这件事前期投入大，但它是后面所有优化的地基。

6.1 建一个小而狠的评测集

评测集不需要大，五十到两百条足够起步，但每一条都要有明确的期望。我的构建方法是三层抽样：

第一层从线上真实请求里随机抽，保证覆盖面；第二层从历史错误案例里抽，这些是最有价值的，因为它们代表了当前系统的短板；第三层人工构造边界样本，覆盖那些线上还没出现但理论上会出现的输入。

每条样本要记录输入、期望输出、判定方式、以及一个备注说明它考察的是什么能力。判定方式分三档：精确匹配用于结构化字段，关键要素检查用于自由文本，人工判断用于主观质量。前两档可以自动化，第三档定期抽检。

有个细节：评测集要冻结。一旦建好就不要因为某次改动而调整期望值，否则你永远在给自己放水。确实需要扩充时，新增样本单独标记，不修改老样本。

6.2 线上指标和人工抽检要配合着看

离线评测跑得好，线上未必好，因为真实分布会漂移。所以线上要有自己的观测指标，我一般盯这几个：拒答率、人工转接率、用户显式反馈（点赞点踩）、平均响应时长、单次请求成本。这几个指标组合起来能反映大部分问题。拒答率突然升高，可能是检索出了问题或者输入分布变了；人工转接率升高但拒答率没变，可能是模型答得"看起来对但其实没用"。

人工抽检我建议固定节奏，比如每周抽五十条，重点看两类：模型高置信度但实际错误的（这类最危险），以及用户反复追问的（这类说明第一次回答没解决问题）。抽检结果要回灌到评测集里，形成闭环。

6.3 用模型当裁判要谨慎

用大模型给输出打分确实省人力，但有几个坑。一是位置偏好，让它比较两个答案时，它会偏向排在前面的那个，解决办法是把顺序随机化跑两次取平均。二是长度偏好，它倾向于给更长的答案更高分，所以最好在评分标准里明确"简洁性也是评分项"。三是它和你的人工标准不一定对齐，所以上线前要拿一批人工标注过的样本校准一遍，看相关系数够不够高。

我的做法是模型裁判只用于批量初筛，把明显有问题的筛出来，剩下的还是人工看。完全依赖模型裁判做验收，风险太大。

7. 成本与延迟，被低估的工程约束

模型能力再强，如果一次请求要八秒、成本是原来方案的十倍，业务方也不会接受。这两条约束在设计阶段就該摆到桌面上，而不是上线前才发现超预算。

7.1 算清楚一次请求到底花多少

成本主要由输入长度决定，很多人只算了用户问题那几个字，忘了系统提示、检索到的文档、历史对话全都要算进去。我一般这么估：系统提示按八百字算，检索上下文按三千字算，历史对话按一千字算，那么单次输入就是五千字量级，输出按五百字算。有了这个基数，再乘上日请求量，就能估出月度成本。

延迟同理，要拆开看：检索耗时、模型首字延迟、生成长度。首字延迟决定用户感知的快慢，如果超过两秒，用户会觉得卡；总时长决定他愿不愿意等，超过十秒基本就流失了。优化的顺序通常是先砍上下文长度，再考虑换更小的模型，最后才上缓存。

7.2 缓存和降级的组合拳

缓存分两种。精确缓存是输入完全一致才命中，实现简单，命中率取决于业务是否有重复请求，客服场景里重复率往往不低。语义缓存是意思相近就命中，命中率高但要用相似度阈值控制，阈值太低会返回错误答案，我一般设在比较保守的位置，宁可少命中也不能错命中。

降级策略我一般分三级：正常走完整流程；超时或模型不可用时，降级到只返回检索到的原文片段，让用户自己看；再不行就返回预设话术引导人工。关键是每一级都要有明确的触发条件，并且提前测过，别等真出事才临时加。

8. 复盘时反复验证的几条经验

写到这我发现有些东西值得单独拎出来说，它们不属于某个技术环节，而是贯穿整个项目的判断习惯。

先做窄，再做宽。不要一上来就覆盖全品类，挑一个高频、边界清晰的场景做透，把评估跑通、把降级跑通、把成本算清楚，再往外扩。我见过一个团队同时铺了八个场景，每个都做到六十分，没有一个能用，最后全部回滚。

错误要能看见。所有AI输出都应该可追溯，能查到它当时用了哪些上下文、走的哪条路径、命中哪个版本的提示。这不是为了甩锅，是为了排查。没有可观测性的AI系统，出了问题只能靠猜。

别追求把错误率降到零。有些错误是模型能力边界决定的，投入十倍成本只能降一个百分点，这时候更划算的做法是把这类输入识别出来转人工，而不是硬啃。判断标准是：这类错误的处理成本，是否低于继续优化的成本。

业务方要参与定义成功。技术团队自己定的验收标准，业务方往往不认。让他们在项目开始就说清楚"什么样的回答算合格"，最好能给几个正例反例，这比任何技术指标都有用。

留一个人工兜底的入口。哪怕系统准确率到九十五，也要给用户一个"找人工"的按钮，并且保证这个按钮好用。这不只是体验问题，也是风险控制。

最后分享一个我自己用的小办法：每个AI项目结项时，我会写一份"失败清单"，记录这个项目里所有被验证走不通的路——试过但没用的提示技巧、评估过但不合适的模型、设计过但太复杂的架构。这份清单比成功经验更有价值，因为下个项目遇到类似情况时，能省掉重复试错的几天。这个系列后面还会继续写，下一篇打算聊评估集的具体构建方法和那些判定标准的取舍，那部分细节多，单独展开更清楚。