企业官网建设流程全解析

过去一年，我被问得最多的问题不是“大模型能不能写诗”，而是“大模型到底能不能帮我们把活儿干了”。问这话的人有工厂的信息化负责人，有连锁门店的运营主管，也有整天泡在数据和报表里的中层管理者。他们真正想要的是一个懂业务、能上手的AI——不是那种能谈天说地的通用助手，而是放进业务流里顶得上一名熟手员工的工具。可惜的是，这类AI在展会上很少见，在PPT里也常常只是一页概念图。

也正因为如此，当我第一次听说“大模型产业应用城市纵深行”这件事时，第一反应不是研究它的技术栈，而是想搞清楚：这种带方法论走进城市、走进企业现场的巡回方式，到底能不能把“懂业务、能上手”从口号变成现实？带着这个疑问，我跟着跑了几座城市，进了一些企业的生产现场，跟一线的业务和技术人员聊了很多。今天这篇东西，就是这段时间下来最想分享的一些观察和方法。

1. 为什么大模型一进产业就失灵：三个扎心真相

1.1 通用能力很惊艳，业务规则一窍不通

很多人对AI的第一印象来自公开演示：让它总结一份合同，或者解释一个概念，表述流畅、条理清晰，看起来“已经很懂了”。但真把它放进产业的业务现场，情况立刻变脸。

举个例子，一家做仓储物流的企业曾尝试用通用模型做库存问答。模型接上了一个简单的库存数据库，问“某批次货还能不能发”，它给出的回答是“根据当前库存数量为1000件，可以发货”。听起来没错，但在真实业务里，这批货可能处于质检冻结状态，可能有未处理的异常审批，也可能因为下游客户账期问题被系统锁单。这些规则不在数据库的“库存数量”字段里，而在业务流程、系统状态和人脑的约定俗成里。模型不知道，于是答得越流畅，错得越离谱。

所谓“懂业务”，至少可以拆成三个层面：

• 懂术语和隐含规则：知道“批次”“冻结”“放行”“安全库存”这些词不只是名词，背后还有判断逻辑和例外情况。
• 懂数据结构：知道企业里哪张表、哪个字段对应哪个业务含义，数据质量差时该信谁。
• 懂流程约束：知道一次操作的前置条件是什么、后置动作有哪些、哪些环节必须人工确认。

大多数大模型在通用语料上表现优异，但面对企业内部的这套“潜规则”几乎等于零基础。这不是模型笨，而是它没见过这些知识，也没人教会它。

1.2 能说会道不等于能上手，生产环境的要求完全不同

产业侧对“能上手”的定义，和Demo、竞赛里的“跑通”完全不是一回事。

我见过很多项目在演示环节效果惊艳：能回答、有引用、界面好看。但到了真实生产环境，问题接踵而至。比如客服助手演示时能回答80%的问题，可真上线后发现，用户不会按演示时那些标准话来提问，问题往往夹着错别字、口语、方言和残缺信息；再比如文档抽取系统，测试集里准确率不低，但换一批格式不同的真实扫描件，解析结果就开始错乱。

“能上手”在生产环境里其实是一组工程指标：

• 输出格式要稳定：不能这次给JSON、下次给散文，否则下游系统没法接。
• 错误率要有底线：在允许出错的场景可以容忍小概率错误，但在涉及资金、安全、合规的场景，错误率必须压到极低。
• 延迟要有上限：业务人员等一个回答超过十几秒，基本就不会用了。
• 过程要可追溯：回答的依据来自哪里、谁调用了模型、结果是什么，都要能审计。
• 系统要可维护：模型版本更新了怎么办、知识库换了内容怎么办，都得起得到保障。

能“聊天”只是能力起点，“能上岗”才是产业应用真正的及格线。

1.3 三重错位：技术方、业务方、模型之间隔着一道翻译层

跑的城市多了，会发现一个规律：绝大多数失败项目不是模型能力不够，而是三拨人之间发生了严重错位。

第一重错位，技术方追求“能力上限”，业务方关心“一次都不能错”。算法工程师习惯看平均分、看Benchmark提升，但业务负责人更在意的是某一个关键环节千万别出错，因为出一次错就可能造成直接损失。

第二重错位，业务方把大模型当“人”来期待，而模型只是“概率引擎”。业务方经常会说“AI应该能理解”“AI怎么连这个都不知道”，但模型本质上是根据上下文预测下一个词，它没有真实的因果理解能力。

第三重错位，数据基础与模型要求不匹配。大模型训练时见惯了结构良好、表述规范的互联网内容，而企业内部有的是扫描件、手写备注、命名混乱的表格、多人维护的Excel。数据不洗干净，模型再强也白搭。

城市纵深行这类活动，本质上就是在补这道“翻译层”——把业务方的真实需求翻译成技术任务，再让技术方用业务方听得懂的话验收结果。

2. 城市纵深行到底在做什么：一场把AI拉回地面的巡回实验

2.1 为什么以“城市”为单元而不是行业或线上

最开始我也纳闷，为什么做大模型产业应用要按城市来跑？按行业不是更聚焦吗？后来走了一圈才明白，城市是最适合产业调研和落地的颗粒度。

一个城市往往有相对完整的产业链结构。比如某东部沿海城市以机械加工和电子制造为主，周边聚集了原材料供应商、零部件厂、整机厂和物流服务商；某中部城市有密集的零售网点和餐饮连锁。以城市为单元，可以一次性摸清一个区域的产业结构、共性问题和技术基础，比单纯按行业跨区域远程调研更有实操价值。

线上访谈有个很大的问题：看不到现场。业务人员嘴上说的“数据很乱”，真实乱到什么程度、数据散落在哪些系统里、流程里有哪些口头约定，这些不踏进办公室和车间根本判断不了。而且产业落地最需要的不是“概念共识”，而是“资源在场”——本地服务商、本地客户、本地算力环境，凑齐了才能快速做试点验证。

说白了，城市是产业生态的最小完整单元，以城市为单元的纵深走访，比线上问卷和跨行业论坛更能触及真实问题。

2.2 调研、诊断、共创、验证：一套进现场的作业流程

城市纵深行的作业方式，跟传统的“专家讲座+企业拜访”有很大区别。它更像一套标准化的进现场作业流程，核心是五个环节。

第一，需求地图。到一座城市后，先根据产业特点梳理出重点企业清单和对应的业务场景。比如有制造业城市，重点看工艺、质检、供应链；有服务业城市，重点看客服、营销、运营分析。

第二，实地访谈。让业务分析师、算法工程师、数据工程师、解决方案架构师一起进企业，而不是只派一个售前去收集需求。业务分析师负责引导业务方把模糊愿望说清楚，算法工程师判断模型能不能做，数据工程师检查数据质量，解决方案架构师考虑怎么接进现有系统。

第三，场景筛选。用“业务价值乘以技术可行性”这两个维度给所有候选场景打分。价值高、可行性强且数据条件成熟的项目优先试点；价值高但可行性弱的，先搞清楚卡点是什么；价值低的不论技术多炫，直接放弃。

第四，快速POC。选定一个最合适的场景，用企业真实数据做最小原型。POC的目标不是做出完美产品，而是回答三个问题：效果达不达标？成本可不可控？用户认不认？

第五，复盘与模板沉淀。每个城市的结论不只属于某一家企业。某个行业里典型的“业务诉求-技术方案-数据要求-评测指标”组合，会被沉淀成可复用的模板，带到下一座城市验证。

这套流程看起来不复杂，但很多项目恰恰是缺少这种纪律性，才会陷入“到处讲概念、到处落不了地”的困境。

2.3 翻过“需求翻译”这道墙：业务语言如何变成模型任务

产品和技术人员经常听到业务方说“我们希望AI帮我们管好售后”。这句话听着简单，翻译成模型任务却是另一回事。

管好售后可能包含：对历史工单自动分类、对重复问题生成标准回复建议、对高投诉风险工单做情绪预警、对售后记录做摘要沉淀。这四个是四个完全不同的技术任务，需要的数据、模型方案和评测标准都不一样。

能不能把“想用AI管好售后”翻译成“给2万条历史工单打上分类标签，并生成一份可运营的摘要”，决定了项目能不能落地。这是整个产业应用链条里最考验功力的一步。

我把“需求翻译”总结成一张常用表，现场调研时基本按这个逻辑走：

这张表的价值在于，它让业务方和技术方在同一个维度上对话。业务方不需要懂模型技术，但他能看懂“准确率”“漏判率”；技术方也不再纠结于抽象能力，而是盯着具体任务验收。

3. 四个真实可复用的落地切片：大模型在不同行业的“上手姿势”

3.1 制造场景：把老师傅的“手感”沉淀成可检索的工艺知识

制造业是大模型产业应用里讨论最多、落地最难的方向之一。一个很典型的场景是工艺知识的传承问题。

某家机械加工企业，核心工艺知识分散在两类地方：一类是老师傅脑子里的经验，另一类是散落在各个Word文档、PDF文件甚至纸质表单里的工艺规程。老师傅一旦退休，很多“什么时候该调参数、哪种情况可以放宽公差”这类隐性知识就流失了。企业想做大模型问答系统，让新员工能快速查询工艺参数和操作要点。

这个项目第一版效果很差。文档解析后检索经常命中错误段落，新员工问“某型号零件的热处理温度”，模型返回的是无关表格。后来排查发现，原始文件中存在大量扫描件、手写批注，还有同一个术语在不同部门的不同叫法。团队花了两周做数据清洗、术语对齐、解析模板优化，才把检索命中率拉上来。

最终系统上线后，新员工查一个工艺参数的平均时间从二十分钟降到了三分钟左右。但这里要泼一盆冷水：模型只是“辅助检索”，不是“自动决策”。老师傅对特殊情况的判断，比如“这批材料硬度偏高，温度可以下浮十度”，模型无法承担这个责任，系统设计上也刻意把这类建议框在了参考范围内。制造业落地的边界感，比技术能力更重要。

3.2 服务场景：把SOP“翻译”成模型能执行的对话流程

服务业的典型问题不是没有知识，而是知识太多、员工记不住。很多连锁企业都有厚厚的服务标准手册，从迎宾话术到售后处理流程一应俱全，但一线员工遇到不常见的问题时，手册搬不出来，只能凭感觉应对。

某连锁品牌做了一个“服务SOP智能助手”，但方案不是简单地把手册丢给模型，而是先把SOP拆成了结构化流程：判定条件—执行动作—话术模板。比如客户投诉商品质量问题时，系统先判断是否在质保期、是否有购买记录、是否已有人工介入，再给出对应的处理动作和话术建议。大模型被限定在这个流程框架内做生成，而不是自由发挥。

这个细节很关键。让模型完全自由地根据手册回答问题，它很容易“发挥过头”，说出手册里不存在的承诺。加了流程约束之后，合规性显著提升，员工也敢用了。服务业落地的核心不是让模型更像人，而是让模型在规则内帮人做选择。

3.3 文档与数据场景：最容易出成果、最容易被低估的切入点

说一个容易被忽视的真相：大模型在产业里最容易出成果的，往往不是那些听起来很“智能”的场景，而是文档处理和结构化数据抽取。这类场景不性感，但数据相对规整、价值容易量化、效果能快速验证。

某企业有几千份采购合同，以往靠专人逐条摘录付款条款、违约责任、截止日期等关键字段，一份合同平均要折腾十几分钟。上了大模型抽取方案后，配合PDF解析、版面分析和表格识别，多数合同的字段抽取准确率达到了95%以上，人工只需要复核少数异常样本。

这类项目的优势在于投入产出比非常清晰：节省了多少人时、出错率下降多少，都是可以摆在台面上的数字。它的门槛也没有想象中那么高，关键是做好三件事：解析质量（PDF里的表格和扫描件识别准不准）、字段定义（需要抽取哪些业务要素）、校验机制（模型给出的字段值在业务规则上是否合理）。

很多企业总觉得只有“对话机器人”才算AI应用，其实把文档里的数据整理出来，本身就是很有价值的AI落地。千万别小看这种“不性感”的场景。

3.4 经营分析场景：让AI做副驾，不让AI背方向盘

经营分析是大模型应用里讨论热度很高的方向，也是最容易翻车的方向。管理层希望用自然语言直接查数据：“上季度华东区退货率环比变化是多少？主要受哪些品类影响？”

这类需求的技术实现路径并不复杂：大模型把自然语言问题转换成查询意图和参数，交给数据平台执行，再把结果解释成自然语言。难的是业务口径。同一个“退货率”，运营部和财务部可能定义不同；同一个“华东区”，可能包含或不包含某些省份。如果模型没有绑定准确的口径定义，给出的数字再漂亮也是错的。

踩过坑之后，我更倾向于把大模型定位成“决策副驾”而不是“决策者”。系统可以给出数据结论、可以提示“该品类退货率上升，建议重点关注”，但最终是否采取行动、怎么调配资源，必须由人来拍板。模型产生幻觉的概率客观存在，归因分析的逻辑也可能不完整，所以任何涉及业务判断的输出，都要保留人工复核和数据出处。

用一句话总结：让AI帮你把方向盘握得更稳，但别让它替你踩油门。

4. 从模型选型到效果评估：“能上手”的四个关键环节

4.1 先量化业务目标，再谈模型选型

很多项目一开始就跑偏，原因是上来就讨论“用哪个大模型”，而不是“这个项目凭什么算成功”。没有验收标准的项目，最后一定会陷入无休止的调参和扯皮。

我建议在项目启动前，先用一页纸把业务目标写清楚，至少包含六项内容：场景描述、目标用户、使用频次、输入输出样例、质量红线、衡量指标。比如客服场景的指标可以是“首响时间降低30%，一次性解决率提升10%”；文档抽取场景的指标可以是“字段准确率大于95%，单文档处理时间小于30秒”。

有了这些量化目标，模型选型反而变得简单：通用模型先跑一轮，看准确率差几个点；如果差距不大，先不用上垂直模型；如果差距巨大且无法通过提示词和RAG弥补，再考虑微调或换更大参数量的底座。业务目标一页纸是选型的“锚”，没有它，所有讨论都是空谈。

4.2 底座模型、垂直增强与知识增强的组合判断

模型选型本质上不是选“最好的模型”，而是选“成本、效果、安全、运维复杂度”四者的平衡点。我简单列一下常见路径的对比：

实操中，我的默认建议是“通用底座加RAG加流程编排”。原因很简单：大多数企业的业务知识是动态变化的，RAG可以随时换知识、加文档，不需要反复重训模型。只有当你发现“同一个问题，加再多知识也答不对”时，再认真考虑微调。先易后难，永远是产业项目的第一原则。

4.3 数据准备与评测回流：把“毛坯模型”调教成“打工AI”

产业AI落地最花时间的环节，往往不是调模型，而是处理数据。

数据准备阶段有三件事跑不掉：一是把散落在各种系统、文档里的业务数据汇聚起来，做格式统一和字段对齐；二是清洗敏感信息，把个人信息、商业机密提前脱敏；三是把“业务规则”显性化，比如把“超过质保期不保修”这类规则写成模型可读取的判断条件。

评测回流则是最容易被忽略、长期价值最高的一环。项目启动第一天就应该搭一个评测集，哪怕只有五十到一百条真实业务case，也要覆盖正常情况、边界情况和典型错误情况。每次模型更新或知识库调整，先在评测集上跑一遍，通过再上线。上线后还要建立badcase回流机制，定期把线上失败案例加入评测集，避免模型越改越“偏科”。

没有评测闭环的AI项目，就像没有质检流程的工厂，次品率完全靠运气。

4.4 与存量系统集成：少造轮子，多接水管

产业应用很少是“一个孤立对话框”，它必须融进企业已有的系统生态：OA、ERP、工单系统、企业微信、BI平台等。集成得好不好，直接决定一线用户愿不愿意用。

我的经验是四个要点。第一，统一走API网关，权限控制统一在网关层做，不要在每个应用里自己实现一遍。第二，所有模型调用都要有日志，谁调的、调的什么、返回了什么，至少保留一段时间，方便审计和问题回溯。第三，能缓存就缓存，高频重复问题直接命中缓存，既能降成本又能降延迟。第四，保留人工兜底通道，模型结果需要人工确认或转人工处理时，流程要顺畅，不能让用户卡在“AI回答不了”的死胡同里。

把模型当成一个需要接入的“能力服务”而不是“独立产品”，集成思路就清晰了。

5. 实战中踩过的坑：常见问题与排查思路

5.1 答非所问先别怪模型：八成问题出在检索和数据

很多团队一遇到模型答非所问，第一反应是换模型、改提示词。但我排查过多个类似问题后，发现大部分根因在模型之前的数据链路上。

印象最深的一次，某知识库问答系统效果骤降，排查后发现是源文档有问题：一部分扫描件内容在OCR时发生了错乱，一部分表格转成文本后结构完全丢失。模型根本没检索到正确内容，自然答不对，可它还是“一本正经”地给出了一个看起来合理的错误答案。

排查这类问题，我建议按这个顺序：先看检索结果——命中的文档到底对不对；再看召回片段——喂给模型的上下文是否完整；最后才怀疑模型本身的生成能力。数据链路问题不解决，换再强的模型也白搭。

5.2 线上结果不稳定：版本、参数与上下文带来的三个隐形变量

产业用户最难容忍的不是模型偶尔出错，而是“昨天还行，今天突然不行了”。这种情况下，问题往往出在三个隐蔽的地方。

第一个是模型版本漂移。有些平台会将请求路由到不同版本的模型，回答风格和准确率都会有波动。生产环境必须锁定模型版本，不能跟着上游“自动升级”。第二个是参数被改动。某个环节的温度参数被调高了，回答多样性增加的同时也增加了出错概率；确定性任务建议把温度设成0或很低。第三个是上下文过长。随着对话轮次增加和检索片段堆积，注意力被稀释，模型很容易“忘掉”最初的问题或遗漏关键信息。解决思路是在每次请求前对上下文做摘要和裁剪，只保留关键信息。

可重复性才是生产环境的第一需求，宁可答案“无聊”，也不要时好时坏。

5.3 算不清账，项目就做不长：成本与价值的量化方法

产业AI里有个经常被忽略的问题：项目能不能持续，取决于成本收益算不算得清。

Token成本特别容易被低估。举一个粗略的估算方法：如果每个客服对话平均消费5000个Token，日活跃用户数假设为2000人、人均每天5轮对话，那么一天的Token消耗就是5000乘以2000乘以5，也就是5000万Token。再按商业API价格粗算，一个月的模型调用成本是一个不小的数字。如果不做缓存、不做剪裁，这笔费用还会继续膨胀。很多项目上线前没有算过这笔账，等到账单出来才发现难以为继。

那怎么算“值不值”？很简单，把“省下的人工成本”和“效率提升带来的收益”算清楚。如果AI每月成本是5万，但能减少一个全职岗位的重复劳动，或者把处理效率提升30%，项目就有了存活的基础。成本不是选型时拍脑袋决定的，而是上线前必须做好的功课。

6. 跑了几座城之后，我关于产业AI落地的一些体会

6.1 先窄后宽：好项目都是从一个最小的业务切口长出来的

以前我也迷信“大而全”的平台化方案，但看过那么多落地案例后，印象最深的反而都是小切口。某企业从“报销单智能审核”开始做，三个月后扩展到采购合同、客服工单和经营分析。切口小，业务方容易理解，数据范围可控，评测标准也容易定，成功率自然高。

这不意味着只做小项目。一个负责任的技术方，应该在小项目立项时就想清楚它的后续路线图：这个点验证成功后，下一步能连到哪些周边场景？能沉淀哪些可复用的是数据资产和模板？先窄后宽，宽才有方向。

6.2 人比模型重要：懂业务的人在场，比调参更有用

走访中我反复验证了一件事：凡是顺利落地的案例，甲方内部一定有一个既懂业务又愿意学习AI的人。他们不一定懂模型细节，但能清楚定义问题，“我们的痛点是退货原因靠人工猜”“核心诉求是把质检流程里的主观判断标准化”。技术团队再有经验，也代替不了这种“甲方自己人”的洞察。

所以如果让我给准备上马AI项目的企业一句忠告，那就是：别只派IT部门对接，业务部门必须深度参与；别把AI项目当成一个“技术项目”，它本质上是一个“业务改进项目”。人对了，模型差一点也能把事做成；人不对，模型再强也只是个昂贵的玩具。

6.3 给想动手的人三条可执行建议

如果你所在的企业正准备上一个大模型应用，我建议从这三个动作开始。

第一，选场景时，优先选数据最完整、流程最标准、价值最明显的环节，哪怕它听起来不够“高级”。文档抽取、知识检索、工单分类这些场景，比“全公司通用的智能助手”更容易落地。

第二，先别追求端到端全自动。模型能辅助人工把速度提上去，就已经创造了价值。把容错空间留出来，让关键环节保留人工复核，既降低风险，也更容易获得业务方信任。

第三，从第一天开始建评测集。哪怕只有几十条真实业务case，都是项目后续迭代的地基。没有评测集的AI项目，就像没有出厂质检的产品，更新一次吓一次。

说实话，跑完几座城市之后，我对“大模型落地难”的看法改变了很多。以前以为是算法不够强，后来发现真正难的从来不是模型本身，而是把人脑子里那些“不成文的规矩”变成模型能理解的数据和流程。这活急不得，但也没有想象中那么玄。只要有人愿意蹲在车间、门店、仓库和会议室里，把业务问题一个一个翻译成技术问题，再让技术问题交付成业务价值，懂业务、能上手的AI就会离我们越来越近。路是一步一步走出来的，城市纵深行只是把这条路的起点，摆到了更多企业门口。