企业官网建设流程全解析

1. 先把“为什么做AI”搞明白，再谈选什么模型

前阵子看到一场行业对话，某位硅谷技术领袖和一家顶级咨询公司的CEO聊AI落地。对话里有个观点特别扎心，也特别容易被忽略：AI落地的第一步，不是选模型。很多人一听就愣了，难道不是先定一个GPT还是开源模型，或者选某个国产大模型，然后才开始干活吗？还真不是。选模型是整个链条里最靠后的环节之一，第一步永远是业务问题定义和场景锚定。

我见过太多团队踩进同一个坑：看到别人用大模型做了个客服机器人，自己也想搞一个，于是第一件事就是拉微信群讨论“咱们用哪个模型”，甚至直接让技术团队去注册API、申请算力、跑benchmark。模型选了一两周，发现业务侧根本说不清楚要解决什么问题——是降低客服响应时长？还是提升用户自助解决率？还是减少人工坐席成本？这三个目标对应的方案完全不同，有的需要RAG知识库，有的需要Agent多轮交互，有的只需要一个简单的分类加模板生成，模型大小、推理成本、延迟要求全都不一样。

把业务问题定义清楚，是AI落地里最不起眼却最关键的一步。这个概念在咨询行业有个术语，叫“价值锚定”，说白了就是你要先找到那个能被AI真实改善、能算清楚收益的切入点。很多项目失败，不是因为模型不够强，而是因为从一开始就没想清楚“这个AI到底要替谁、在哪条流程上、省多少钱或涨多少效率”。没有锚点的AI项目，最终只会变成技术团队的Demo展示，热闹一阵，然后默默下线。

选模型之前，还有两件老大难的事要做：数据和组织准备。数据决定了AI的上限，组织决定了AI能不能被人用起来。这两件事不做扎实，用什么模型都是空中楼阁。我接下来把这三块拆开讲，每一步都是我自己做项目时踩过坑、填过土之后总结出来的实操经验。

2. 数据准备：AI只能吃你喂给它的粮食

2.1 数据质量比数据量重要得多

大家都听过一句话，叫“垃圾进，垃圾出”。这句话在大模型时代不仅没有过时，反而被放大到了极致。以前做传统机器学习，喂进去几千条特征工程做好的样本，效果就出来了。现在做大模型应用，动不动就要求几十万上百万条数据做微调或RAG检索库，但数据量上去了，如果字段含义混乱、格式不统一、噪声太多，模型会花大量精力去学那些没用的噪声，反而把真正的业务逻辑学歪了。

我自己做过一个项目，客户要给内部员工做一个规章制度问答机器人。最初收集了两万多份PDF和Word文档，看着挺壮观，结果业务侧一上来就问“年假到底能休几天”，系统的回答五花八门，有时说五天，有时说十天，有时扯到产假。排查之后发现，原始文档里有不同年份的制度版本、有总公司和分公司各自的补充细则、还有已经作废的试行办法混在一起。模型不知道该信哪个，自然乱答。我们花了两周时间梳理文档来源、版本、适用范围、生效状态，把可用的文档压缩到六千多份，再做字段标准化和清清洗，最后的效果就是完全不同的两个项目。

关于数据质量的实操建议，我归纳成四条：

• 数据必须带业务上下文：每条数据要能回答“这个内容在什么场景下有用、哪类人会看、回答的是哪类问题”。
• 标准要统一：日期、金额、名称、单位这些基础字段，必须统一格式和口径，否则检索和生成都会出错。
• 要去重和去旧：同一个问题有版本差异时，优先留下最新的、业务上实际执行的版本，旧内容要么归档要么打标。
• 要有专人负责数据维护：数据不是一次性整理好就完事，业务规则变了、文档更新了，回流机制要跟上，否则AI会越来越“过时”。

2.2 清洗流程要文档化，避免成为一次性工程

这里要特别提醒一个细节，数据清洗和准备这件事，看起来像是体力活，做一次就行了。但实操中你会发现，业务在变、数据源在变、组织架构也在变，三个月前做好的规则可能就不适用了。所以我在项目里强烈建议把清洗流程文档化，包括用了哪些过滤规则、哪些人工校验点、数据血缘怎么追踪、数据源和下游任务怎么映射。不是为了写文档而写文档，而是为了下一次新增数据源时不用从头再来。

我见过一个团队，数据整理全靠一个实习生在小黑框里跑脚本，脚本没注释，逻辑没文档，字段映射全在脑子里。后来实习生走了，整个数据管线就瘫了，AI项目被迫暂停，这就是典型的“一次性数据处理工程”。把清洗流程当软件工程来做，写清楚输入输出、依赖关系、异常处理，虽然前期慢一点，但后面会省下大量返工时间。

2.3 RAG场景的数据准备细节

如果你的场景是知识库问答，数据准备还要更进一步。原始文档很长，直接整篇丢进向量库，检索效果会很差——因为用户的问题往往是针对某一个小点，而向量检索是按整篇文挡的语义匹配，容易拉到一篇相关但太宽泛的内容。这时候需要先做段落切分，也叫chunking。切分长度没有标准答案，一百到五百个字之间都要试。

切分时有一个技巧：避免硬切，最好按照文档的自然结构切。比如每节、每章、每一条款单独成块，块内保留标题上下文。你可以在每条切片里补上“来源文档、章节号、生效时间、适用区域”这类元数据，检索时加上过滤条件，精准度会明显提升。另外，嵌入模型选择也有讲究，中文场景下建议用针对中文优化的开源嵌入模型，而不是直接把英文通用模型拿来用，否则检索出来的结果经常让人迷惑。

数据这件事，本质就是AI项目的原材料供应链。原材料不稳定，后端的模型调得再好、提示词编得再华丽，产品照样不稳定。很多团队把精力放在调prompt上，今天改一句话效果好了，明天又不行了，往往就是因为底层数据本身在抖动。把数据治理的功夫下在前头，后面的日子会好过得非常多。

3. 组织准备：技术没落地，往往是人没跟上

3.1 没有业务方深度参与的AI项目没有灵魂

我在实战里最深刻的体会是：AI项目失败的最大原因，不是技术瓶颈，而是组织冷漠。很多公司高层拍板要上AI，指令往下传，技术团队热火朝天干起来，业务团队却一脸懵——不知道AI要干嘛，不知道自己要提供什么支持，更不知道这个AI用好了能给自己减少什么工作。结果技术团队闭门造车做个系统出来，业务侧不用，项目就成了摆设。

组织准备的第一件事，是让业务方和技术方从第一天就绑在一起。具体来说，项目启动时必须明确一个业务负责人，这个人的核心KPI里要包含AI落地效果指标，而不是只让技术团队自己扛。没有业务负责人，流程梳理没人接，数据口径没人定，验收标准没人拍板，项目就是悬空状态。

我参与过一个客服智能助手项目，最开始让技术团队自己定义“成功指标”，他们提出了“首响时间缩短20%”。业务负责人看了一眼就否掉了，说首响时间缩短根本不是痛点，真正痛的是转人工率太高和客诉升级。这两个指标一改，整个系统的设计逻辑都变了，从“更快响应”变成“更准分流与辅助”，技术方案从单纯的生成式回复，变成了意图识别、RAG知识检索、人工坐席辅助的混合架构。可见业务参与有多重要。

3.2 AI项目必须配“翻译官”角色

还需要一个特别容易被忽视的角色：业务和技术之间的翻译官。这个角色现在常被叫做AI产品经理，但叫什么都行，关键是这个人必须能听懂业务侧在说什么，也能理解技术侧的限制。

比如业务提“我们要让系统更懂用户”，翻译官要把这个需求转换成具体的、可评估的技术指标：是提高语义理解准确率，还是增加对话轮次记忆，还是优化上下文长度管理。再比如技术说“模型幻觉问题无法根除”，翻译官要能向业务解释清楚什么是幻觉，在哪些场景风险可控、哪些场景不可控，需要设置哪些防御机制。缺少这个角色，业务和技术之间会进入“鸡同鸭讲”的循环，互相对不上频道，项目就会反复。

3.3 变革管理：培训、信任、反馈闭环

组织准备里还要包括变革管理，说白点，就是让终端用户愿意用、敢用这个AI系统。这里有一大堆活儿要做。

第一是要做大规模培训。先去了解系统能干什么、不能干什么、回答错了应该怎么反馈、哪些数据是AI自动生成需要人工复核。很多系统上线后无人使用，核心原因是用户不知道怎么用，或者用了一次发现回答不理想，就再也没有第二次尝试了。

第二是要建立反馈闭环。系统上线不是结束，而是数据飞轮转动的开始。用户点了“赞”或“踩”，人工坐席修改过哪段回答，这些数据要回流到系统里，变成评估集和微调样本。没有闭环，AI系统上线半年和上线第一天没有任何区别，永远停留在初始水平。

第三是管理层要带头用。我见过一个有趣的案例，某公司的采购合同审核AI上线后，员工普遍觉得模型不靠谱、不用它。后来CTO亲自演示，把自己手里一份真实合同丢进去，系统指出了三个潜在风险点，其中一个连法务负责人都没注意到。这次演示之后，整个部门的接受度立刻上去了。人性就是这样，看到比自己厉害的工具，才愿意把手里的活交出去。

组织准备这件事，本质上是在做“人”的工作。技术团队容易忽略，管理层容易低估，但它往往才是决定AI项目能不能从Demo走向生产的关键变量。没有组织准备，再强的模型也只是一堆代码；有了组织准备，普通的模型配置也能发挥出巨大的业务价值。

4. 模型选型：当前面都就位了，这个问题才真正开始

4.1 选模型的本质是选“约束条件下的最优解”

很多人把选模型当成一个纯技术问题，其实它更接近一个工程决策问题。你需要同时考虑效果、成本、延迟、合规、可维护性五个维度，而且这些维度之间经常互相冲突。

如果你做一个内部知识库问答系统，数据不出域是底线，那显然不能直接调用云端API，只能选能私有化部署的开源模型，像主流的Qwen、ChatGLM、Yi、Llama这一系。如果你做一个客服摘要工具，数据可以上云，但每天调用量几十万次，那云端API按token计费的成本就非常高，可能你得选一个中等参数规模的开源模型自建推理服务，用一张或几张GPU就能扛住。如果你做的是棘手的安全审查场景，那模型的能力必须顶配，成本放在第二位的考虑。

我用一张表来梳理常见的决策维度：

4.2 开源和闭源的取舍要看手里的牌

现在模型市场很有意思，闭源API模型能力很强、开箱即用，但长期成本高且控制力弱。开源模型参数在7B到72B、甚至更大都有，可以在自己的服务器上跑，但部署和优化需要人力和机器。

我的建议是：如果团队没有专职的算法工程师，或GPU资源有限，优先用闭源API模型，把精力集中在业务流程和数据上面。这不是“技术退化”，是合理的资源配置——你不需要自己做发动机，把车开好就行了。如果团队有不错的工程能力，或者数据敏感度要求高、调用量大，那就果断走开源路线。

开源路线也不是买到手就能用。第一步要做推理服务部署，至少要把吞吐量调到基本可用；第二步要基于业务数据做评测，不达标就考虑微调；第三步要建立监控体系，盯住回答质量、延迟、报错率。这中间还要经历无数次的prompt迭代和few-shot样例调整，不是一件轻松的事。

4.3 选型前你必须做一次自己的评测

这一点特别重要，模型选型不能只看公开榜单，排行榜第一的模型不一定适合你的场景。公开榜单的测试集大多是通用的，比如常识问答、代码生成、数学推理，这些任务和你实际的业务任务差别很大。你拿一个古诗词生成第一的模型去做合同风险识别，很可能一塌糊涂。

正确做法是把你的业务问题浓缩成一百到两百条评测集，这些评测集要覆盖真实用户最常问的、最容易出错的问题，还要涵盖边界场景。然后用同样的评测集跑两三个候选模型，逐个比较回答质量，同时记录推理速度和成本。这样才能真正知道哪个模型最适合你的项目。评测集不是拍脑袋写的，要对真实用户请求进行采样，建议找业务运营拉出过去三个月的客服记录或用户反馈，合并同类项、去重之后提炼出高频问题列表，再让业务方帮忙补充一批刁钻问题、歧义问法、敏感内容，这样出来的评测集才有代表性。

在项目初期花三到五天做这个评测，后面能省下几个月的返工。我见过一个团队，上线后才发现模型不支持多轮记忆，被迫改架构，原因就是选型时只看了公开榜单。这个坑，越早避掉越好。

5. 实操蓝图：从零到一的AI项目七步走

5.1 第一步，明确业务收益

所有项目启动会，第一件事都应该是定义业务收益。注意，是要可衡量的业务收益，而不是“提升智能化水平”这种比较虚的目标。你要写清楚：项目上线后，预期能带来多少成本节约、多少效率提升、或者多少收入增长，同时明确通过什么指标来验证。

比如电商客服场景，可以定义为“人工坐席介入率降低15%”，同时设定“客户满意度不低于现有水平”。这两个指标一正一负，既能防止系统乱答伤害体验，又能确保项目真正减少人工成本。有这个锚点，后续所有工作方向都有了依据。

5.2 第二步，盘点数据资产

系统梳理现有数据源的分布、格式、权限、更新频率，明确哪些数据可以用来支持AI应用，哪些数据需要治理才能用，哪些数据因为权限和合规原因根本不能碰。这一步要产出数据清单和差距分析报告。一旦发现核心业务数据严重缺失，需要提前规划数据补采。

5.3 第三步，技术架构设计

基于业务问题确认边界，然后画出技术架构图。通常情况下，AI应用都包含三部分：前端交互层、AI推理层、数据存储与检索层。前端负责用户输入输出，推理层负责意图理解、生成、编排，数据层负责知识库、历史会话、业务数据的存储和检索。架构设计这一步不要过于技术化，重点是确认每个环节的数据流向和接口协议。

如果你的场景需要RAG，需要提前想清楚文档切片策略、向量库选型、检索过滤逻辑。如果你的场景是Agent形态，需要梳理工具调用、状态管理、多轮记忆存储。这些决策要写进设计文档，作为后续开发的依据。

5.4 第四步，选择模型和部署方式

这步就是我上面讲到的选型决策：基于效果、成本、数据安全、延迟四个方面，确定是用API还是开源私有化。然后用自建评测集跑一轮评测，最终确定模型供应商或开源基座。部署方式上，如果自建，需要规划GPU资源配置和推理服务的并发能力，建议用兼容性好的推理框架，方便后续切换模型。

5.5 第五步，搭建评测体系和反馈闭环

上线之前就搭好评测流程。将真实业务问题整理成评测集，约定好评分标准，每次模型改动、prompt调整、数据更新都要跑一遍评测，防止回退。定期从线上抽取用户反馈、人工修正记录，回流到评测集中，持续扩充边界场景。

5.6 第六步，小范围灰度上线

不要一步推到全量用户，先选一个业务团队或一部分流量做灰度。灰度期间要重点观察使用率、正确率、反馈量、资源消耗这四类指标，同时收集用户的具体意见。灰度观察期建议至少一到两周，不要只看一两天就下结论，因为业务数据每周都有周期性波动，一周以上的数据才能看出真实趋势。

5.7 第七步，迭代优化

灰度通过后再逐步放量，放量之后进入常态化运营阶段。数据分析团队定期看效果指标，业务团队持续反馈问题，模型团队持续做检索优化、prompt迭代、微调更新。这样整个系统才不是“上线即巅峰”的静态系统，而是越用越好的动态系统。

6. 避坑实录：我见过的那些翻车现场

6.1 把Demo当成生产系统

这是最常见也是最致命的问题。很多人第一次接触大模型，写个脚本调用API，生成结果看起来很惊艳，就觉得项目可以交付了。但Demo和生产之间有巨大的鸿沟：生产要考虑并发、安全、日志、监控、回滚、权限控制，要面对真实用户五花八门的输入，要应对模型抽风时的兜底方案。

我见过一个内部的文档问答工具，开发人员做Demo时发现模型回答得很好，直接在业务大会上演示了三十秒，从此被业务部门频繁询问。技术团队承受不住压力，加班加点上了生产，结果遇到几个用户在输入框里粘贴了一段乱码，导致系统崩溃，还引发了敏感内容展示的问题，最后整个项目叫停。Demo演示成功和项目上线成功之间，隔着一个完整的工程体系。

6.2 提示词工程师当久了，就忘了数据治理

很多人遇到效果不好，第一反应就是调prompt。昨天加一句“你是一个专业的客服”，今天改成“请用简洁的语句回复”，反复调试，效果时好时坏。这是典型的战术勤奋掩盖战略懒惰。我做过很多次故障排查，最终发现大部分问题都出在数据上：检索到了错误文档、知识库中有过时内容、数据切分不合理。提示词只是帮模型在表达上做了优化，不可能解决知识层面的错误。

给一个排查顺序建议：先查数据，再查检索，然后查排序，最后才查prompt和模型本身。按这个顺序排查，大部分问题都能找到真正的原因，而且解决起来更持久有效。

6.3 忽视成本，钱烧完了项目也就死了

大模型应用有个非常烧钱的隐患：token消耗。很多团队上线前估算一个月两万元成本，上线后发现一个月花了二十多万元。原因主要有几个：每次对话把大量历史记录塞进上下文，token随轮次线性增长；系统自动生成了几条候选回复让用户选，实际生成量远大于展示量；定时轮询任务频繁调用模型接口，产生了大量无效调用。

成本控制要从设计阶段就做好：限制上下文长度，做会话摘要压缩历史；减少候选回复数量，尽量单次生成；缓存重复问题，相同或相似的问题直接命中缓存，不重复调用模型。上线后还要实时监控token消耗和调用次数，成本异常时及时预警。有一位前辈总结得特别到位：云上大模型API是按token计费的，AI应用的每一行对话都是钱，架构师脑子里必须时刻有一个价格计算器。

6.4 评估指标选错，系统好坏都看不出来

有些团队上线AI系统后，只看“回答率”“调用量”这类数字，数字好看就觉得自己成功了。实际上可能用户调用了十次，七次回答是错误的，但系统没有收集用户反馈，导致劣质答案一直在输出。真正要看的指标至少包括用户采纳率、人工修正率、真实解决率、用户满意度，每个指标都要有数据的定义和采集方式。

把评估指标设计好，本质上就是在定义“什么叫AI落得落地”。定义不清楚，项目价值和投入产出永远是一笔糊涂账。

7. 写在最后的几点心得

经常有人问我：“现在AI技术迭代这么快，我应该追最新模型吗？”我的回答是：新技术当然值得关注，但千万不要被技术牵着走。对绝大多数企业来说，真正的壁垒不是模型本身，而是你对业务问题的理解深度、数据资产的沉淀厚度、组织协同的顺畅程度。这三件事，比选哪个模型重要得多。

从我自己的实践体会来看，一个成功的AI项目，百分之三十的时间花在业务定义和数据梳理上，百分之二十花在组织对接和流程设计上，真正花在选模型、调模型上的时间，也许只有百分之二十，剩下的时间都在做测试、反馈、灰度、稳定性优化。这个配比，比大多数人想象的要厚重得多。

最后再分享一个小技巧：如果你们公司刚起步，既没有算法团队也没有充分的数据治理，千万不要贪多求全。选一个业务流程短、数据质量好、业务价值明显的场景做切入点，比如内部的制度问答、售后的工单分类、合同的初筛审查，把这个场景做透、做稳、做出可量化的价值，再考虑横向复制。AI落地不是造火箭，是一场需要持久作战的转变。第一步迈对了，后面的路就会越来越宽。