企业官网建设流程全解析

聊起AI工程化这件事，最近感触特别深。前阵子一个朋友跑来问我：“你不是在做AI工程吗？帮我把公司那堆Excel整理成知识库呗。”我听完头都大了——这听起来像是个“喂数据”的活儿，实际上牵扯到数据清洗、切片策略、检索质量、模型选型、成本控制，哪一样拎出来都够折腾半个月。这也是我想写这篇东西的初衷：很多人以为AI工程化是从“今天开始调大模型API”起步，但真正从零走一遍之后会发现，工程化要解决的核心问题根本不在模型本身，而在模型周围那一整套系统设计、数据管道、评测机制和成本控制。

这篇内容适合谁看？适合那些已经在业务里看到了AI落地的机会，却不太确定从哪里下手的开发者、产品经理和技术负责人；也适合那些被“智能体”“RAG”“提示工程”这些词轰炸过一轮，但对它们之间到底是什么关系还比较模糊的人。我尽量用一套完整的方法论加一个贯穿全篇的真实场景来拆解，保证你读完能直接套用到自己的项目上。

1. 先说清楚：AI工程化到底在“工程”什么

1.1 “从零开始”这四个字害了不少人

我第一次听到“AI工程”这个说法的时候，也以为它是“从零训练一个大模型”的简称，毕竟名字里挂着“AI”，又挂着“工程”，听着就像炼丹炉旁边放了个工地。后来真上手做了几个落地项目才发现，我们绝大多数人说的“AI工程化”，是指把现成的模型能力稳定、可控、低成本地嵌进业务流程里。

这完全是两回事。前者属于算法研究员的地盘，要懂训练框架、数据配比、分布式策略，动辄几千张卡；后者属于系统工程师和应用架构师的地盘，核心能力是拆解业务问题、设计数据流、控制输出质量、观测线上表现。从零开始做AI工程，真正的起点不是“选哪个模型”，而是“我要解决谁的什么问题，这个问题凭什么值得用AI来解”。

这个认知不纠正过来，后面的所有动作都会跑偏。我见过太多团队，第一步直接拉了个大模型聊天窗口进内部系统，说“这就是AI落地了”，结果三个月后没人用，因为关键业务路径上一步都没打通。做AI工程，先得把“工程”两个字读重。

1.2 AI工程落地的最小完整闭环

从零搭建一套AI能力，无论场景多简单，最终都要跑通这条闭环：业务需求拆解、方案与模型选型、数据准备、应用组装（提示词、工作流、智能体）、离线评测、灰度上线、线上观测与迭代。

这七步缺一不可。缺了前两步，你只是在给团队制造一个昂贵的玩具；缺了评测，你根本不知道模型改版之后是变好了还是变差了；缺了观测，线上出了问题只能靠用户主动投诉来发现，等到投诉进来的时候，影响面往往已经不可控了。

我比较建议用“最小完整闭环”的思路来启动项目，也就是哪怕第一个版本只解决一个很小的场景，也一定要把评测和观测这两块胚子搭进去。原因我在后面会展开：评测和观测不是上线前的附加项，它们本身就是工程化的基础设施，是整个系统能不能持续演进的前提。

1.3 我见过的最典型失败路径

先说失败案例，因为踩坑经验比成功路径更值得参考。这几年我看到最多的一种“AI项目失败”长这样：

• 业务方说“我们要做个智能助手”，于是技术团队接入了大模型API，套了个好看的前端页面，能聊天就算交付；
• 没有定义“好用”的具体指标，没有离线测试集，Prompt全靠产品经理拍脑袋写；
• 上线后用户在真实问题里一问三不知，或者答非所问，团队不知道是知识库缺内容、检索没召回到、还是模型没理解意图；
• 最后归因到“大模型不行”，项目搁置。

这套路我闭着眼睛都能背出来。说白了，失败不是输在模型能力上，而是输在工程化缺失上：问题没有被明确定义，质量没有被量化度量，故障没有被有效追踪。这一篇后面讲的所有内容，本质上都是在对抗这条失败路径。

2. 从零起步的第一件事：把业务需求翻译成AI问题

2.1 先做流程拆解，而不是先找模型

很多团队犯的第一个错误，是拿到需求直接冲进模型选型，在GPT系列和开源模型之间反复横跳。但实际上，你连“这个需求要拆成几个AI子任务”都没想清楚，选型根本无从谈起。

我的习惯是先把流程图画出来。拿最常见的“客服工单系统”举例：一张工单从用户提交到最终关闭，中间要经历接收、预分类、意图确认、方案匹配、人工处理、结果回访。这时候你去找一找，哪几个环节符合“高频、规则覆盖不了、人做起来重复”这三个特征？通常答案会集中在“预分类”和“方案匹配”这两个环节。

先把流程图里值得用AI的节点圈出来，再去看每个节点的输入输出长什么样、评估指标是什么、出错之后谁来兜底。这套拆解做完之后，你手里的就不是一句“做个智能助手”，而是一张能直接指导技术方案的AI任务拆解图。这一步做到位了，后面基本不会出大方向问题。

2.2 判定“AI该不该上”的三条标准

不是流程里所有环节都值得上AI。我给自己定过几条判断标准，每次都先用它们过滤一遍需求，能省下大量预算和精力。

用这三条标准去过一遍需求，你会惊讶地发现有相当一部分“AI需求”其实是伪需求。比如把用户填写的固定表单字段自动录入系统，这就是个规则脚本的事，没必要让大模型参与，成本高、延迟大、还不一定稳定。而工单的“意图识别”就不一样了——用户表述千奇百怪，关键词表永远统计不干净，这才轮到AI上场。

2.3 一个贯穿全篇的案例：工单智能助手

为了让后面的内容不那么天马行空，我拿一个经典场景贯穿全篇，各位可以把自己手头的具体业务往里套。假设我们要给一家软件公司的售后支持团队做一个“工单智能助手”，核心功能有三块：

1. 工单自动预分类：进来一条用户反馈，自动判断它属于“技术故障”“使用咨询”“计费问题”还是“需求建议”；
2. 知识库答案辅助：根据工单内容，从内部FAQ和产品文档里检索相关片段，生成一个初步回复建议；
3. 兜底与人工接管：当分类置信度不够高或知识库找不到相关内容时，自动转入人工队列，并且给客服人员展示“AI推荐理由”。

这个场景的好处在于：它够具体，每一步都有明确的输入输出，也能定义出硬指标——分类准确率、答案引用命中率、转人工率、人均处理时长。后面讲提示词组装、RAG落地、评测建设、成本优化，我都拿这个案例来说话，大家跟起来会轻松很多。

3. 应用层组装：Prompt、工作流与Agent的演进主线

3.1 Prompt工程不是写提示词，是定义接口

很多人一听到Prompt工程，脑子里浮现的是“给AI写一段花言巧语让它听话”。真实情况完全不是这样。在工程化的语境里，Prompt本质上是模型与业务系统之间的接口契约，它的核心目标是：让模型的输出稳定、可解析、好处理。

我写系统提示词有一套固定结构，差不多四层：角色界定、任务定义、输入输出格式、约束与兜底行为。拿工单分类举例：

你是一名售后工单分类器。你的任务是根据工单内容，从以下类别中选择最合适的一个： [技术故障, 使用咨询, 计费问题, 需求建议]。 输入格式：用户提交的工单原文，放在<工单></工单>标签内。 输出格式：严格输出JSON对象，包含两个字段： - category：类别名称，只能从上面四个中选一个 - confidence：0到1之间的置信度分数 - reason：一句话说明分类依据，不超过30字 约束： - 如果工单信息不足以判断，category输出unknown，confidence输出0 - 不要输出任何JSON以外的内容

这里有个关键细节我给标出来了：允许模型输出“unknown”。很多工程团队会忘记给模型一条“不知道就直说”的出口，结果模型在所有输入上都硬给一个答案，分类错误率直接失控。在工程系统里，一个“我不确定”的答案，远比一个“自信满满的错误”有价值，因为它能引导系统触发兜底路径，把问题交给人工处理。

3.2 从单次调用到工作流：多步AI协作的骨架设计

单次Prompt调用解决不了复杂问题，这是所有人在推进AI工程时迟早会撞上的墙。工单助手就是个典型：分类、检索、生成回复建议，这三步严格来说是三个不同任务，硬塞在一次调用里，提示词会膨胀得无法维护，模型输出也容易顾此失彼。

正确做法是把它们拆成串联工作流。第一步，用小模型做意图分类；第二步，根据分类结果查询知识库，把召回到的相关片段作为上下文；第三步，用大模型基于这些片段生成回复建议。这个流程里的每个节点，Prompt都能保持短小清晰，任何一步出问题，都能单独排查和修正。

多AI协作这个词现在很热，但本质上它就是上面这种分工思想。我在实际项目里常用的套路是：前置的抽取和分类用便宜快速的小模型，需要推理和生成的环节用能力强的大模型，最后再放一个“复核批评”模型，专门检查上一个模型输出的合规性和事实性。三个模型各司其职，比单一模型一把抓要稳定得多，成本还更可控。这就是多AI协作的工程价值，不是把多个模型堆在一段对话里轮番表演。

3.3 Agent化：什么时候该让模型自己决定下一步

聊完了工作流，必须得说Agent（智能体）。这两年Agent概念火得不行，好像所有AI应用不挂个Agent就不算工程化。我的观点可能跟主流有点不一样：Agent不是AI应用的第一步，而是AI应用演进的最后一步。

工作流和Agent的核心区别在于是“流程固定”还是“流程让模型自己定”。工作流适合那些步骤稳定、边界清晰的场景，比如工单分类，永远都是“先分类再检索再生成”，固定路线跑起来又快又可控。Agent适合的是那些状态多变、工具众多、用户目标不明确的场景，比如“帮我安排一次出差”这种任务，它可能需要订机票、查酒店、排日程，每一步要调哪个工具完全取决于前一步的结果。

在工单助手的场景里，我不会一上来就上Agent。先把固定工作流跑稳了，评测指标达标了，再考虑在局部加一点Agent化的能力，比如当知识库检索不到时，让模型决定是改写检索词再试一次，还是直接转人工。这个“局部Agent化”的思路，比一上来就做一个自由发挥的Agent要稳妥得多，因为它保留了工程上的可观测性和控制力。

4. 数据与知识库：RAG落地的真实成本和几个易错点

4.1 先回答：这个场景真的需要RAG吗

RAG（检索增强生成）现在是AI应用里的明星技术，但它被用滥了。很多人一听说要做知识库问答，张口就是“用RAG”，完全没想过还有一种更省钱的答案叫“基于检索的模板生成”。

RAG的本质是“检索+生成”：从知识库里检索相关片段，再让模型基于这些片段做总结和生成。这个环路里模型的自由度越大，幻觉风险就越高，需要做的评测和防控就越多。如果你的业务本质上是“在精确的记录里找标准答案”，比如查询产品价格、查某条工单的处理记录，那直接用检索把答案呈现出来就够了，没必要让模型重新生成一遍——生成得越多，出错的可能就越大。

所以在动手做RAG之前，先回答三个问题：答案是否需要推理总结？知识是否相对静态？用户提问是否多样到规则匹配覆盖不了？如果三问里有两问是“否”，那RAG大概率不是你的最优解，先用传统搜索和模板方案顶着，成本低得多。

4.2 Chunk、Embedding与召回评估

确认场景真的需要RAG之后，核心工作就变成了三件事：切片、向量化、召回评估。

切片指的是把长文档拆成小块再入库。这一步看起来简单，翻车率极高。我的经验是：优先以“语义完整块”为边界去切，比如按段落切、按小节点切，而不是无脑按固定字数切。固定500字一刀切下去，很容易把一个完整的函数说明拦腰截断，检索时根本召不回关键信息。如果文档比较长，我一般会把块大小控制在200到500个token之间，overlap（重叠）设个20到50个token，兼顾检索精度和上下文连续性。

向量化其实就是给每个块生成一个特征向量，后续用向量相似度来找相关内容。但向量检索有一个老毛病——对专有名词和编号不敏感。处理这批工单的时候，用户可能输入“ERR-4032”这种错误码，向量化之后它的语义和“error code 4032”可能距离很远。我最常用的解法是引入混合检索：向量检索跑一遍，BM25关键词检索也跑一遍，两部分结果做合并排序。这个方案在真实场景里对召回率的提升非常显著。

召回评估是RAG的“体检标准”，也是最容易被跳过的环节。我的习惯是每次调整切片策略或向量化方案，都准备三四十条高频提问，人工检查：正确的那几篇文档，到底有没有出现在召回的前五位里。忘掉那些花哨的分数，这个最朴素的“命中率”指标，比任何指标都更能反映RAG链路好不好用。

4.3 知识库迭代比模型迭代更见效

跑了一段时间RAG之后你会发现一个规律：优化知识库带来的收益，往往比换模型大得多。原因很简单，生成模型的能力已经很强了，真正的瓶颈在于“该有的知识库里没有”或者“有但检索不到”。

知识库迭代要分清优先级。第一优先级，解决“检不到”——最常见的原因是文档缺失或切片格式错误，这个靠补文档就能解决；第二优先级，解决“检不准”——调整切片策略、优化检索排序，让正确内容出现在更靠前的位置；第三优先级，才是调整生成风格和回复话术。我见过团队花两周时间调Prompt想提升回复质量，结果问题的根子出在知识库根本检索不到对应内容，调Prompt就是隔空打拳。

另外提醒一句，知识库不是建好就完事了。产品文档更新的时候，你的知识库同步更新了吗？旧版本的内容清理干净了吗？版本混放在同一个向量库里，会让召回结果变得极其混乱。把这个“知识库运维”当成一件常态性工作来做，而不是一次性项目，这是很多团队容易忽略的隐性成本。

5. 工程化的下半场：评测、观测与成本治理

5.1 评测集建设：上生产前必须有的“考卷”

如果项目只能保留一套工程实践，我的选择一定是评测集。没有评测集的AI项目，就像没有考卷的学生测评——你根本不知道模型这版改动是进步还是倒退。

评测集的建设原则是“从真实数据里来”。上线前，先收集几百条历史工单，人工标注好正确答案，按场景分成几类：分类准确率、知识库召回命中率、生成答案的事实准确率、输出格式合法率。每一类对应独立的评测维度，改任何一个环节，都跑一遍全量评测，拿数据说话。

大模型评测有一个常用但必须小心的手段：LLM-as-judge，让一个模型来给另一个模型的输出评分。这方法效率很高，但本身有偏差，大模型往往对“格式完整”“语气得体”的答案给高分，对“内容明显错误但写得流畅”的答案也可能判过关。所以在用模型判分的同时，一定要定期抽三五十条让人工复核。我用过最有价值的校验方式是：拿评测集中的“标准错误答案样本”反复测试评审模型，确保这些明显的错漏能被打出低分，否则这个裁判机制本身就是摆设。

5.2 从日志到链路追踪：给AI应用装上仪表盘

AI应用比传统软件更需要观测，因为它涉及多个不确定性环节：“用户输入到了哪一步？模型调用是否超时？检索召回了什么？生成结果被采纳了吗？”这些链路信息在传统日志里几乎看不见，但恰恰是排查问题的关键。

我的建议是给每一次请求分配一个链路ID，然后把整条链路的输入、输出、耗时、Token消耗、每个子节点的状态都记录下来，存成结构化日志。线上用户反馈“回答质量变差了”，通过链路ID能把那次完整请求捞出来，从分类到检索再到生成，逐段排查是哪一环出了问题。这个过程有点像给AI应用装了一块仪表盘——让每次失败都有迹可循，而不是两眼一抹黑。

另外一个很多人忽视的基建：用户反馈埋点。在工单助手界面里加“有帮助/没帮助”两个按钮，成本很低，但这两数据是线上质量评估最珍贵的信号。把反馈数据和链路日志关联起来分析，你很快就能知道到底是哪类工单、哪种提问方式最容易让用户点“没帮助”，后续迭代的方向自然就有了。

5.3 成本账：Token、缓存与模型分级调用

AI工程的成本结构跟传统后端不一样，它的主要成本不是服务器CPU占用，而是Token消耗。很多人做完一个PoC项目没有感觉，一上生产才发现，每月账单数字吓人一跳。

成本治理有三大手段。第一，精简系统提示词。同一个任务，Prompt里塞了一堆历史遗留的废话规则，Token消耗可能比有效内容还高。花一天时间做“提示词瘦身”，在不影响评测指标的前提下压缩长度，是最立竿见影的省钱手段。第二，引入缓存。同一类工单的相似问题，模型输出结果往往也相似，在相似度达到一定阈值时直接返回缓存结果，可以省掉大量重复调用。第三，模型分级调用。把分类、抽取这类简单任务路由给价格低的小模型，把最终生成这类复杂任务留给强模型，整体成本可以压缩一半以上。

举个具体的数字：假设你的助手每天处理5000张工单，单张工单平均消耗3000个输入Token和500个输出Token，一个月就是4.5亿个输入Token和750万个输出Token。在小模型和大模型的单价差异下，分级调用一个月能省出的金额，够买一台不错的开发服务器。这笔账，做AI工程的人必须学会算。

6. 从0到1的路线图与我的几条实在建议

6.1 按这个节奏推进，别跳步

我整理了一条从零到一推进AI工程的节奏建议，这套节奏在多个项目里验证过，直接拿来用就行：

• 第1到2周：完成业务流程图拆解，选定首个落地场景，定义具体的评测指标。这一阶段的主要产出是一张场景价值表和一份评测集初稿；
• 第3到4周：基于Prompt和简单工作流把端到端MVP跑通。记住，这一版不用追求效果完美，目标是“链路完整、数据能回流”；
• 第5到8周：把评测集跑出基线数据，然后开始调优。每次改动只动一个变量，通过评测数据验证改动有效性；
• 第9到12周：小范围灰度上线，上线后重点看用户反馈数据和成本数据，而不是只看模型效果；
• 之后进入常态迭代阶段：按“召回问题优先、生成问题其次、结构和成本最后”的顺序持续优化。

这个节奏的核心思想是先打通链路，再提升质量，最后才谈成本和体验优化。顺序反了，容易陷入“调了一个月Prompt，链路还没跑通”的尴尬局面。

6.2 资源有限时，优先做这三件事

如果你团队就两三个人，时间又紧，我建议把资源压在下面三件事上：第一件，建一个能跑出数字的评测集，哪怕只有三十条样本，也比没有强；第二件，把全链路日志和用户反馈埋点做扎实，这是后续所有优化的数据地基；第三件，把成本监控接好，别等到月度账单出来才心痛。

这三件事听着不性感，但它们决定了你的AI项目能不能活下去。在AI工程这个领域，最贵的东西不是大模型的API费用，而是团队把精力花在一个又一个无法验证的猜测上。

6.3 我自己走完这一圈，留下的最大感受

我把这套方法论走完一遍之后，最大的感受是：AI工程化其实不像AI，更像传统软件工程的一次进化。它需要你精确描述问题、严谨设计链路、持续构建评测、认真观测线上。那些看似神秘的“智能体”“RAG”，本质上都是一步步可拆解、可验证的工程组件。

也正因为如此，这门手艺是完全可以“从零开始”学会的。只要你能把业务需求翻译成AI问题，能用评测数据而不是感觉来驱动迭代，能接受“小步快跑、用数据说话”的方式，你就已经走在这条正确的路上。模型会越来越强，成本会越来越低，但工程化的底层能力，才是真正能跟得上时代的东西。