企业官网建设流程全解析

1. 一个反直觉的现场观察：模型能力上去了，交付难度反而更大了

过去两年，我参与过不少把大模型能力落地到真实业务场景的项目。有一个现象越来越明显，甚至可以说有点反直觉：模型本身越强，项目交付的难度不降反升。按理说，模型能写代码、能查资料、能理解复杂指令，很多以前需要人肉堆时间的事情它都能干了，交付应该更轻松才对。但实际跑下来，情况恰恰相反。

我印象很深的一次，是帮一个团队把一套智能问答能力接进他们的内部工单系统。模型在测试集上的表现相当漂亮，回答准确率、意图识别率都超过了预期指标。团队上下都很兴奋，觉得这事基本成了。结果上线第一周，客服主管就找过来，说这东西“没法用”。不是答错，而是答得太“标准”了——用户问“我这个单子卡了三天了到底什么时候能好”，模型回了一段关于工单处理流程的规范说明，字正腔圆，但用户要的是“帮我催一下”或者“给我个大概时间”。模型没错，它只是没站在那个具体的人面前。

这就是我想在这篇里聊透的核心问题：为什么模型越强，越需要有人进现场。这里的“现场”不是指物理意义上的车间或门店，而是指业务真正发生的地方——用户真实提问的语境、数据实际流动的链路、决策最终生效的环节。模型能力越强，它被期望承担的责任就越大，而责任越大，就越需要有人去弥合“模型输出”和“业务结果”之间那道看不见的鸿沟。

这篇内容适合几类人看：正在做 AI 应用落地的工程师、负责把技术方案翻译成业务语言的产品经理、以及那些觉得“模型都这么强了为什么还要养一堆人”的管理者。我会从几个具体的切面，把“进现场”这件事拆开讲清楚，包括它到底在解决什么问题、具体怎么做、以及我踩过的那些坑。

2. 模型能力的边界，恰恰是现场问题的起点

2.1 强模型擅长“回答”，但业务要的是“解决”

先厘清一个基本认知：当前主流大模型的核心能力，是在给定上下文的情况下生成合理的文本或决策建议。它非常擅长“回答一个问题”，但业务场景里用户真正要的往往不是答案，而是“把事办了”。

这两者之间的差距，在简单场景里不明显。比如用户问“退货政策是什么”，模型答得清清楚楚，用户看完自己就去操作了。但在复杂场景里，这个差距会被急剧放大。用户说“我买的东西坏了想退”，这句话背后可能包含：判断是否在保修期、确认退货资格、生成退货单、安排物流、通知财务、跟进退款。模型可以告诉你“根据政策您符合退货条件”，但它没法替你点那个“确认退货”的按钮，也没法在物流系统里真的创建一个取件任务。

我见过太多项目，把“模型答对了”当成“问题解决了”。测试阶段看准确率，上线之后看解决率，中间差的那一大截，就是现场工作要补的。模型越强，人们越容易高估它的闭环能力，觉得它既然能理解意图，那顺便把后续动作也做了应该不难。但“理解”和“执行”之间，隔着系统权限、数据一致性、异常处理、责任归属这一整套东西，这些都不是模型在对话框里能搞定的。

2.2 上下文窗口再大，也装不下现场的“隐性知识”

现在模型的上下文窗口动辄几十万甚至上百万 token，很多人觉得“把资料都塞进去就行了”。但现场真正棘手的信息，往往不是那些能写成文档的东西。

举个例子，一个电商客服团队处理纠纷时，有一条不成文的规则：如果用户是第一次投诉且金额不大，优先安抚并快速补偿；如果是反复投诉的老用户，则要转给资深客服人工处理。这条规则没有写在任何 SOP 里，它是团队在长期实践中形成的默契。你问任何一个老客服，他都能告诉你“这个人一看就是来闹的”，但你说不清他是怎么“看”出来的——可能是订单历史、可能是措辞方式、可能是某个特定时间点的行为模式。

这种隐性知识，模型从公开数据里学不到，从你给的文档里也读不出来。它只存在于现场那些人的脑子里和肌肉记忆里。模型越强，你越会试图让它处理更复杂的判断，而这些判断恰恰最依赖隐性知识。这时候如果没有人进现场去把这些东西挖出来、结构化、再喂回给模型或流程，模型就会用一套“平均正确但具体错误”的逻辑去处理每一个个案。

2.3 评测指标和业务体感之间的裂缝

做模型评估的人都知道，离线指标和线上效果之间经常对不上。一个在测试集上 F1 值 0.9 的模型，上线后用户满意度可能只有 60%。为什么？因为评测指标衡量的是“模型输出和标准答案的匹配度”，而业务体感衡量的是“用户的问题有没有被妥善解决”。

我参与过一个法律咨询场景的项目。模型在“法条引用准确率”这个指标上表现极好，几乎不出错。但用户反馈很差，原因是模型总是给出“根据某某法第几条，您的情况属于某某范畴”这种回答，而用户想要的是“那我接下来该干嘛”。法条引用准确，不等于用户知道下一步行动。评测指标没覆盖“可操作性”这个维度，因为它在离线阶段很难量化。

现场工作的一个重要部分，就是不断把业务体感翻译成可观测的指标，再反过来指导模型优化和流程设计。这件事没有捷径，必须有人真的去听用户怎么骂、看客服怎么救火、跟业务方一起复盘每一个失败案例。模型越强，它输出的内容越像“对的”，你就越容易忽略那些“对但没用”的回答。

3. 进现场到底在做什么：四个具体动作

3.1 动作一：把“用户原话”和“模型输入”之间的损耗找出来

用户不会按照模型期望的格式说话。一个真实的用户可能发来一段语音转文字后错别字连篇的消息，可能夹杂着表情包和截图，可能上一句还在问退货下一句就开始骂物流。这些信息在进入模型之前，要经过一轮“翻译”和“清洗”，而每一轮处理都会丢失信息。

进现场的第一个动作，就是完整地跟踪一条真实请求从用户发出到模型响应的全链路，把每个环节的信息损耗记录下来。我通常会做一张表，左边是用户原话，右边是最终喂给模型的 prompt，中间标出每一步做了什么处理、丢了什么信息。

这张表做出来，你就能清楚地看到：模型拿到的信息，和用户真正表达的信息，中间差了多少。很多时候模型“答非所问”，根因不在模型，而在前面的信息处理环节把关键上下文弄丢了。模型越强，它对上下文完整性的要求越高，因为它会基于你给的信息做更复杂的推理，信息缺失导致的错误也会更隐蔽。

3.2 动作二：在真实系统里跑通“最后一公里”

模型输出一段文本，到这段文本真正产生业务影响，中间隔着系统集成。这部分工作极其琐碎，但极其关键。

比如模型判断“该用户符合退款条件”，接下来要调用退款接口。这个接口可能有权限校验、可能有金额限制、可能要求先解冻某个状态。这些约束条件在模型训练数据里是不存在的，只有实际去调的时候才会暴露。我遇到过模型建议“为用户重置密码”，但重置密码的接口需要短信验证码，而用户手机号已经停用了——模型不知道这个约束，它只是根据“用户忘记密码”这个意图给出了标准建议。

进现场就是要把这些系统约束一条条摸清楚，然后决定哪些交给模型判断、哪些用规则兜底、哪些必须人工介入。我的经验是，凡是涉及资金、权限、不可逆操作的环节，都不要让模型直接触发，而是让它生成“建议动作”，由规则引擎或人工确认后再执行。模型越强，它给出的建议越像真的，你就越需要一道硬性的安全闸门。

3.3 动作三：收集“模型不知道自己不知道”的案例

模型有一个特点：它对自己不知道的东西，往往不会说“我不知道”，而是会编一个看起来合理的答案。这在开放域问答里可能只是个小瑕疵，但在业务场景里可能是灾难。

进现场的一个核心任务，就是建立一套机制，持续收集那些“模型自信地答错了”的案例。这些案例不会出现在标准测试集里，因为测试集的题目是预设的，而现场的问题是随机涌现的。我通常会在系统里加一个“反馈”入口，让一线人员能一键标记“这个回答有问题”，然后定期把这些案例捞出来分析。

分析的时候重点看两件事：一是模型错在哪个环节，是信息缺失、推理错误还是知识过时；二是这个错误如果没被发现，会导致什么后果。后者决定了你要花多大精力去修它。有些错误只是让用户多问一句，有些错误可能导致资金损失或合规风险，优先级完全不同。

3.4 动作四：把现场经验反哺成可复用的资产

进现场不是一次性的活动，而是一个持续循环。每次从现场带回来的发现，都应该沉淀成某种可复用的东西：可能是一条新的评测用例、可能是一个 prompt 模板的修正、可能是一条业务规则、也可能是一个新的工具接口。

我习惯用一个简单的文档来管理这些沉淀，每条记录包含：现场发现、根因分析、修复动作、验证结果。这个文档本身就是项目最宝贵的资产之一，因为它记录了模型在真实环境里“成长”的轨迹。模型越强，迭代速度越快，这个沉淀机制就越重要，否则你会在同一个坑里反复摔跤。

4. 一个真实项目的现场排查记录

4.1 背景：智能工单分类上线后准确率暴跌

去年我参与了一个智能工单分类项目。背景是一家公司的客服中心每天收到大量工单，需要人工分派给不同的处理组。他们想用模型自动分类，减少人工分派的工作量。离线测试时，模型在历史工单数据上的分类准确率达到了 92%，团队觉得可以直接上线。

上线第一天，准确率掉到了 67%。而且更奇怪的是，错误分布很不均匀：某些类别的准确率几乎没降，另一些类别直接崩到 40% 以下。

4.2 排查过程：从数据分布到现场语境

第一步，我们对比了离线测试集和线上真实工单的分布。发现线上工单里有一类“综合咨询”占比很高，而这类在历史数据里很少。原因是业务最近调整了入口，把原来分散的几个咨询入口合并了，导致大量混合意图的工单涌入。

第二步，我们抽样看了那些被分错的工单。发现很多工单的文本非常短，比如“问一下那个事”“还是上次那个问题”。这些工单在历史数据里几乎不存在，因为以前入口分开时，用户会被引导填写更具体的信息。入口合并后，用户直接在一个框里输入，信息量骤减。

第三步，我们去现场看了客服的实际操作。发现人工分派时，客服并不是只看工单文本，还会看用户 ID、历史工单记录、甚至当前的处理队列长度。一个老客服看到某个用户 ID，就知道他上次的问题是什么，这次大概率还是同类问题。这些信息模型完全拿不到。

4.3 修复方案：不是换模型，而是补上下文

找到根因后，修复方案就很清楚了。我们没有去换更大的模型，而是做了三件事：

1. 在工单文本之外，把用户历史工单摘要拼进模型输入。这样模型能看到“这个用户上次问的是退款，上上次问的是物流”，对当前意图的判断会准很多。
2. 对短文本工单增加一个澄清环节。如果模型置信度低于阈值，不直接分类，而是自动回复一句“请问您咨询的是退款、物流还是其他问题”，让用户点选。这个动作把一部分模糊工单变成了清晰工单。
3. 保留人工兜底通道。对于模型置信度极低或用户明确要求人工的工单，直接转人工，不强行分类。

调整之后，线上准确率回升到了 88%，虽然还没到离线测试的 92%，但已经远超可用的门槛。更重要的是，错误分布变得均匀了，不再有某个类别突然崩掉的情况。

4.4 这个案例教给我的三件事

第一，离线指标和线上效果之间的差距，往往不是模型能力问题，而是数据分布和上下文问题。模型没变，但输入变了，输出自然就变了。

第二，现场观察能发现数据里看不出来的信息。如果我只盯着工单文本分析，永远想不到“用户 ID 和历史记录”这个维度，因为它在数据表里是分开存储的，只有看到客服的操作界面才会意识到它的重要性。

第三，修复方案不一定要动模型。补上下文、加澄清环节、保留人工兜底，这些工程手段往往比换模型更有效、更可控。模型越强，你越应该把精力花在“让模型看到它该看到的东西”上，而不是一味追求更大的参数量。

5. 进现场需要什么能力：不是技术，是翻译

5.1 在业务语言和技术语言之间来回切换

进现场的人，最重要的能力不是写代码，也不是调参，而是翻译。业务方说“这个回答不够智能”，你要能翻译成“模型在意图识别环节缺少用户历史上下文”；工程师说“这个 prompt 效果不好”，你要能翻译成“业务上用户其实期望的是先确认再回答”。

这种翻译能力，靠看文档是学不会的。你得真的坐在客服旁边听他们怎么接电话，真的跟业务方一起过一遍完整的用户旅程，真的自己动手去调一次接口看看会报什么错。模型越强，技术门槛越低，翻译能力反而成了最稀缺的资源。因为模型能做的事越多，业务方对它的期望就越模糊，越需要有人把模糊的期望拆解成具体的、可执行的技术动作。

5.2 对“不完美”的容忍度和对“风险”的敏感度

进现场的人还要有一种微妙的平衡感：一方面要接受模型不可能 100% 正确，另一方面要清楚哪些错误绝对不能接受。

我通常会把错误分成三类：可恢复错误（用户多问一句就能解决）、可补偿错误（造成不便但可以通过补偿挽回）、不可接受错误（涉及资金、隐私、合规）。对于前两类，可以用模型加人工兜底的方式处理；对于第三类，必须用硬规则拦住，不能让模型有直接触发的权限。

这种分类没有标准答案，每个业务场景的边界都不一样。你得跟业务方、法务、风控一起坐下来，一条条过。这个过程很磨人，但它是进现场工作里最有价值的部分之一。

5.3 把“个案”抽象成“模式”的能力

现场每天产生大量个案，如果每个个案都单独处理，人会累死。进现场的人需要有一种能力：从一个具体的失败案例里，抽象出它属于哪一类模式，然后针对这个模式去设计系统性的解决方案。

比如你发现模型把“我要投诉”错误地分类成了“咨询”，这背后可能是一个模式：所有带有负面情绪词的工单，模型都倾向于往“咨询”类分，因为训练数据里负面情绪样本太少。找到这个模式，你就可以针对性地补充训练数据或调整分类阈值，而不是一个个去修。

模型越强，它犯的错误越“高级”，越不是简单的规则能覆盖的。这时候抽象能力就特别重要，因为你需要从看似不同的错误里找到共同的根因。

6. 那些没人告诉你的现场实操细节

6.1 第一次进现场，先别急着问问题

很多人第一次去业务现场，恨不得拿着笔记本把每个细节都记下来，见人就问“你们平时怎么操作的”。我的经验是，前两个小时什么都别问，就坐在旁边看。

看用户怎么输入、看客服怎么响应、看系统怎么反馈、看异常怎么处理。你会发现很多“文档里写的流程”和“实际发生的流程”完全不是一回事。等你看了足够多的真实操作，再带着具体问题去问，效率会高很多，对方也会觉得你“懂行”，愿意跟你说真话。

6.2 录音和截图要谨慎，但笔记要详细

现场观察时，录音和截图涉及隐私和合规问题，不是所有场景都允许。但笔记一定要做详细，而且要用自己的话记，不要只记“用户说退款”，要记“用户说‘我上周买的那个蓝色的，就是那个带花纹的，坏了，能换吗’，语气比较急，客服先安抚了一句才继续问订单号”。

这些细节在后续分析时非常有用，因为模型的输入往往就是这些原始文本，你记的细节越丰富，越容易复现问题。

6.3 跟一线人员建立“反馈通道”，而不是“汇报关系”

进现场的人很容易被一线人员当成“上面派来检查的”，从而只说好听的。要打破这层隔阂，最好的办法是让他们知道你真的会改。

我通常会在现场待一段时间后，挑一个他们反馈最多的小问题，快速修掉，然后告诉他们“你们上次说的那个问题，我们改了，你们试试看”。一旦他们发现反馈真的有用，后续就会主动跟你说真话。这个信任关系建立起来，比任何调研方法都管用。

6.4 别把“现场”局限在物理空间

“进现场”不一定非要跑到业务方的办公室。对于很多线上业务，现场就是用户的真实使用环境。你可以通过录屏、会话回放、用户行为日志来“远程进现场”。关键是你要看到未经修饰的、真实的用户行为，而不是经过整理的报表或摘要。

我经常做的一件事，是随机抽一批真实会话，从头到尾看一遍，不做任何筛选。这个过程很枯燥，但往往能发现报表里完全看不到的问题。

7. 模型越强，人的位置在哪里

回到标题那个问题：为什么模型越强，越需要有人进现场？

我的理解是，模型强在“处理”，人强在“判断”。模型可以处理海量信息、生成流畅文本、识别复杂模式，但它不知道什么信息重要、什么文本该说、什么模式值得关注。这些判断依赖于对业务目标的理解、对用户处境的共情、对风险边界的把握，而这些恰恰是现场才能提供的。

模型越强，它能处理的事情就越多，需要人做的判断也就越关键。以前模型只能做简单分类，人只需要检查分类结果；现在模型能生成完整方案，人就需要判断这个方案在具体场景里是否可行、是否合规、是否真的解决了用户的问题。判断的难度和重要性都上升了。

所以“进现场”不是对模型能力的不信任，恰恰相反，它是让模型能力真正发挥出来的必要环节。没有人进现场去理解业务、补全上下文、建立反馈循环，再强的模型也只能在测试集上好看，到了真实环境里就会各种水土不服。

我自己的体会是，做 AI 落地项目，最怕的不是模型不够强，而是没有人愿意去现场。大家都想待在办公室里调 prompt、看指标、写报告，觉得那些“脏活累活”不值得做。但恰恰是这些现场工作，决定了项目最终能不能真正产生价值。模型可以迭代，可以换，但现场那些隐性知识、那些真实反馈、那些只有人才看得见的细节，是任何模型都替代不了的。

如果你正在做类似的项目，我的建议很简单：先别急着优化模型，先去现场待两天。看看用户到底怎么用，听听一线到底怎么骂，把那些“模型不知道它不知道”的东西找出来。你会发现，很多你以为需要换模型才能解决的问题，其实只需要有人去现场看一眼。