企业官网建设流程全解析

上周一个朋友拿着一个含糊到没法落地的需求来找我：“帮我做一个AI客服，能自动回复用户就行。”我问他：数据在哪？回答不好怎么算？模型跑挂了找谁？他全没想过。这大概是“从零开始做AI工程”最真实的起点了——所有人都在聊模型效果，但真正让一个AI功能稳定跑起来的，是模型之外那套完整的数据、训练、评估、部署、监控和迭代体系。这篇博文，我就围绕“ai-engineering-from-scratch”这个主题，完整复盘一套从0到1构建AI工程项目的全链路打法，覆盖AI模型部署、prompt engineering、AI Agent编排、效果评估这些核心环节。无论你是想独立做项目的工程师，还是刚接触AI的技术负责人，照着这条路线走，至少能少踩六成我当年踩过的坑。

1. 整体设计与思路拆解

1.1 AI工程到底是什么

先把一个误区说透：AI工程不是“跑通一个模型”。很多新手以为训练完模型、调通接口就算完事，但真实的生产环境里，模型只是链条上的一环。数据怎么持续供给、版本怎么管理、线上效果退化了怎么发现、模型答错时系统怎么兜底——这些才是工程的主体。

我常用一个类比：模型像发动机，AI工程是整车。发动机再猛，没有油箱、变速箱、刹车和仪表盘，它连小区门口都开不出去。数据管道就是油箱，推理优化是变速箱，兜底策略是刹车，监控告警是仪表盘。所以“从零开始做AI工程”，本质上是在造一辆能上路、能保养、能维修的车，而不是在实验室里点火听个响。

也正因为如此，AI工程要比传统软件开发多一层不确定性：传统软件的逻辑是可预期的，而模型行为在训练完成前无法完全预知。这要求工程方法从“一次性交付”转向“基线-优化-迭代”的循环思维。你不可能一开始就做到完美，但你可以一开始就设计好“如何知道自己正在变好”。

1.2 从零开始的核心顺序

我反复推演过好几条路线，最后收敛成一套相对稳妥的“六步走”：需求边界 → 数据基线 → 模型选型 → 训练/微调 → 部署上线 → 评估迭代。顺序绝不能乱。

先定需求边界，是为了避免“什么都想做但什么都做不深”。做AI和做人一样，最重要的是知道自己不做什么。一个客服系统，你非要它同时处理售后、营销、闲聊，那数据集会被撕成碎片，模型效果必然稀烂。我会在下一节展开怎么把模糊需求拆成可验证的子任务。

定了边界再做数据基线，是为了在投入训练成本之前，先用规则或提示词跑一个最简陋的版本，看看数据分布是否支持你的预期。这一步非常关键，很多人跳过它，直接上模型微调，结果发现输入数据本身质量极差，再好的模型也白搭。

然后是模型选型，判断是调用现成API、微调开源模型还是干脆训练小模型，取决于任务复杂度、数据规模和延迟预算。再往后是训练与微调、部署上线，最后是靠评估迭代形成闭环。整个顺序的核心逻辑只有一个：用最便宜的方式验证风险最大的假设。

1.3 为什么不要一上来就选大模型

这里必须泼一盆冷水：大模型不是万能解药。我见过太多项目，需求明明用几百条正则规则就能覆盖，非要上大模型API，结果延迟高、成本高、输出还不稳定；也见过连1000条干净样本都没有，就想全参微调13B模型，最后除了过拟合什么都没得到。

选不选大模型，我给自己定了一个判断矩阵：

打个比方：搬家不是非得雇集装箱卡车。搬几件行李，叫辆出租车就够了；只有搬整套家具，才需要大车。大模型就是那辆集装箱卡车——载重强、油耗也高。你如果只是要“判断用户情绪正负”，一个千行级参数的小模型或一套规则，可能比调用几百亿参数的大模型更快、更省、更可控。这就是为什么“从零开始”的第一步不是选模型，而是想清楚你到底需要多大的“运输能力”。

2. 需求定义与数据工程实操

2.1 把业务需求翻译成可评估问题

“智能客服能帮我回答问题”这种描述，直接当成机器学习任务来做，大概率会翻车。因为它没有定义清楚：什么算“回答得好”？哪些问题必须回答？哪些问题不该回答？我习惯的做法是把这类模糊需求拆解成三个层次：

一是意图识别。用户进来先判断他到底想干嘛，是“查订单”“问物流”还是“申请退款”，这是一个分类任务，可以用标注样本喂一个文本分类模型或大模型来做。二是检索回答。对于“你们发货多久到”“怎么退换货”这类标准化问题，可以走FAQ检索，从已有的问答对里找答案，而不是让模型自由发挥。三是兜底转人工。当模型置信度低或问题是敏感投诉时，系统必须能判断“我搞不定”，并把会话转给真人，而不是硬着头皮编答案。

完成拆分后，每个子任务都要有可量化的指标。意图识别看准确率和召回率；FAQ检索看Top-3命中率；兜底转人工看的是“误转率”和“漏转率”。有了指标之后，“效果变好了”就不再是一句空话，而是“意图识别准确率从82%提到91%”这样可验证的事实。这一步的产出物是一份一页纸的需求定义文档，里面包含任务边界、评估指标、可接受的最低表现、以及明确不做什么。我建议所有从零开始的项目都先写这份文档，它会在后续所有决策里帮你挡住无数诱惑。

2.2 数据采集与清洗的四个原则

数据工程是整个链路里最枯燥但最重要的一环。模型再强，也扛不住“输入垃圾，输出垃圾”。我践行的四个原则是：最大程度贴近真实分布、保证标注口径一致、剔除低质量和敏感样本、给数据做版本管理。

先说真实分布。很多团队喜欢从网上找现成数据集，但这会导致严重的分布偏移——训练数据是电商评论，实际线上来的却全是物流咨询，效果自然崩盘。最靠谱的样本来源是历史工单、客服聊天记录和后台搜索日志；没有历史数据时，可以用小范围灰度收集真实输入，再人工清洗标注，建立一个最小的冷启动样本集。

再说标注口径一致。同样是“用户骂了一句脏话”，一个标注员标成“负面情绪”，另一个标成“投诉”，模型就会学到错误边界。清洗样本时尤其要注意：有明显个人隐私信息的内容，必须在源头脱敏后再进入数据集；无意义的灌水消息、乱码、重复刷屏，也应该直接剔除，否则模型会被这类噪声带偏。最后是版本管理，我习惯给每批数据打上版本号和统计摘要（样本总量、类别分布、来源时段），方便后续排查“为什么这版模型变蠢了”这类问题。

2.3 数据标注与增强的实际操作

标注规范是数据质量的护城河。以“用户意图三分类”为例，我会写一份简单的标注手册，里面明确每个类别的定义、边界案例和特殊规则。比如“查订单”类的要点是用户提到了订单编号或物流状态，“退款”类的要点是出现“退”“款”“钱”等关键词或语义，而两者同时出现时，优先标“退款”——为什么？因为退款是高优先级动作，宁可多转也不漏接。

如果你需要几十个人协作标注，我建议至少做两件事：一是在标注完成后抽10%的样本做二次校验，计算标注一致性；二是定期把标注员之间的分歧样本汇总成一份“疑难案例集”，在评审会上讨论。别以为这些动作浪费时间，我一个项目里最大的效果提升，不是来自换模型，而是来自把标注口径重新统一之后数据质量的提升。

数据增强方面，对于分类和抽取任务，同义词替换、随机删除少量词、回译（中→英→中）都能扩大样本量。但我要提醒一句谨慎：生产环境中，过度增强会引入语义漂移。比如把“我要退货”回译成“我将要把购买的商品退回”，虽然意思接近，但句式风格已经偏离真实用户说话方式了。我现在的习惯是：增强数据占比不超过训练集的20%，且增强样本只作为辅助，绝不让它们掩盖真实分布的不足。

3. 模型选型与训练微调

3.1 三类路线：从头训练、微调、提示工程

在数据准备好了之后，才轮到模型这一步。我梳理了三类路线，它们分别对应不同的投入产出比：

绝大多数“从零开始”的项目，最优解其实是第三条路起步，第二条路提效，第一条路基本不用想。你就算有10亿token的领域语料，也没有几百张显卡的算力预算来完成一次从头预训练，这个账每个人都会算。

为什么要按这个顺序走？因为风险是递增的，成本也是递增的。先用提示工程验证“模型本身能不能理解这个任务”，如果连让模型看几个示例都做不对，那问题大概率出在数据或任务定义上，而不是训练得不够多。等提示工程跑通、拿到了第一批真实调用日志，再决定是否要用这些高质量数据做参数高效微调。这个“先提示、后微调”的顺序能帮你省下大量无效训练成本。

3.2 微调实操：数据准备、超参与显存估算

假如你已经决定走微调路线，我们从数据格式开始。指令微调最常用的格式是：

{ "instruction": "请判断用户的意图，只输出：查订单/退款/其他", "input": "我的快递两天没动静了，什么时候能送到？", "output": "查订单" }

训练时把instruction和input拼成用户侧文本，output作为标准答案。这里有个容易踩的坑：别把标答混进输入侧，否则模型会学到“抄答案”而不是“学推理”。

微调方式上，我不建议一上来就全参微调，优先考虑LoRA或QLoRA这类参数高效微调方法。LoRA只训练一小部分低秩矩阵，显存占用低、效果在很多场景接近全参微调。以7B模型为例，全参微调在16GB显存的显卡上基本就是奢望，而LoRA可以把单卡训练跑下来。我常用的LoRA关键参数是：rank=8到16，训练3到5个epoch，学习率取1e-4到2e-4，先用一个小数据集跑通流程，再逐步加数据。

显存怎么估算？核心公式是：模型权重占用 + 优化器状态占用 + 激活值占用。用AdamW优化器训练时，每个参数会额外占8字节左右的优化器状态（一阶动量加二阶动量）；梯度又占4字节。简单算下来，一个7B模型的全参训练光是权重、梯度和优化器状态就可能超过100GB，而LoRA的量化版QLoRA能把训练显存压到10GB以内。这就是我强烈推荐LoRA的原因。

3.3 评估集设计：别让模型“作弊”

任何时候都不要用训练集来评估模型，这句话我讲了无数次，还是不断有人踩。更隐蔽的问题是：很多团队把爬来的同一批数据既做验证集又做训练集，导致模型“记住”了答案而不是“学会”了能力，线上表现一落千丈。

我建议至少在项目启动时单独留存一份“封印”测试集，覆盖尽量多样的真实输入场景，整条链路跑通之前绝不碰它。评估时不要只看一个综合指标，要按子类别拆开看。比如意图识别任务，分别计算“退款类”的召回率和“闲聊类”的误召回率，因为这两类错误的代价完全不同。漏掉一个退款申请可能导致客诉升级，而把闲聊当成业务问题只会多消耗一点资源。这种代价不对称，光看总准确率根本反映不出来。

大模型场景下，还可以用“LLM-as-judge”的方式做辅助评估——用一个更强的模型给答案打分。但要注意，这个裁判本身也可能有偏置，所以关键样本上还是需要人工复核。评估集不是一次性工具，它应该随着线上真实数据回流定期更新，防止模型的“舒适区”和真实世界脱节。

4. 部署上线与推理优化

4.1 选型推理服务：自建还是调API

模型训练完，接下来就是AI模型部署。这里先做选择题：推理能力是自建还是买现成的？

如果需求是实时客服、数据敏感、需要完全离线部署，那自建几乎是必选项。自建方案里我常用的推理框架有vLLM、Text Generation Inference（TGI）和Ollama。vLLM胜在高吞吐，它实现了连续的动态批处理，能把GPU利用率拉得很高；Ollama胜在简单，本地调试和内部工具用起来很舒服。

部署之后立刻要关注的是吞吐量和延迟的关系。单张A100显卡部署7B模型，理论并发并不等于实际并发，因为显存里除了模型权重还要装每个请求的KV Cache。这个计算很实在：输入输出token越多，KV Cache占用越大。所以做服务时必须给单请求的max_tokens设上限，否则一个超长输出请求就可能吃光整卡内存，拖垮所有其他请求。

4.2 量化与推理加速的基础知识

想要在更便宜的显卡上跑更大的模型，第一个想到的应该是量化。FP16转INT8，模型体积直接减半，显存占用下降明显，推理速度通常也会提升。但量化不是没代价：精度会有些许损失，尤其是对敏感的小任务，可能从“可靠”跌到“偶尔出错”。我的建议是，先跑FP16版本，确定正确性没问题后，再用INT8或BF16做优化对比，确保关键指标下降在可接受范围以内。

除了量化，连续批处理（continuous batching）是现代推理框架的标配能力。以“等一班车坐满才发车”来类比传统批处理，连续批处理则是“边发车边让新乘客上车”——一个请求跑完了，立刻把位置让给排队的下一个请求，GPU的每一块算力都被尽量填满。选择vLLM这类框架就是因为它们把这套机制内置了。至于投机解码等更进阶的加速手段，可以后置到优化阶段再研究，第一版能稳定跑起来比什么都重要。

4.3 工程架构：不止是一个接口

自建推理服务后，你很快会发现，对外暴露一个模型接口是远远不够的。我推荐一个分层架构，从上到下依次是：接入层、路由层、推理层、存储层。

接入层负责鉴权、限流和统一日志，这层决定了你能不能在出问题时迅速定位到“谁在什么时间调了什么参数”。路由层做更细的决策：哪些请求走规则引擎，哪些走小模型，哪些走大模型，哪些直接转人工——这套决策逻辑才是AI产品的核心业务代码。推理层就是真实的模型服务，需要做到多副本部署、自动扩容。存储层记录每一次请求的输入、输出、打分、耗时和用户反馈，这些数据是后续迭代的生命线。

别小看这层架构设计，没有路由层和存储层，你的模型就只是一个无法持续优化的黑盒子。我在早期项目里偷懒省略过存储层，后来线上效果劣化时拿不出任何可分析的数据，只能靠猜，那是整条链路里最被动的时刻。

5. 评估迭代与Agent工程实践

5.1 线上效果怎么衡量

离线评估再漂亮，也不等于线上收益。我见过太多模型在测试集上刷到99%，上线后用户却大量投诉，原因就是离线评估无法覆盖真实交互中千奇百怪的输入。所以线上效果必须单独设一套衡量体系。

第一种方式是小流量AB实验。把用户请求随机分流到新旧两个模型，比较用户行为指标，比如问题解决率、转人工率、用户主动终止率。这里有个细节：模型指标和业务指标要分开看。模型准确率升了但转人工率没降，说明你优化的方向可能根本不在用户痛点上。第二种方式是抽样人工审计。我要求运营或产品同学每周随机抽50条真实对话，人工打标“好/中/差”，这比任何自动指标都更接近真实体验。第三种是让用户反馈回流。页面上的点赞/点踩按钮，客服会话结束后的满意度评分，是成本最低的标注来源。这些反馈数据必须进入数据管道，成为下一版训练集的养料。

5.2 把“从零开始”延伸到Agent应用

现在的AI工程很难绕开AI Agent。一个Agent的本质很简单：模型负责理解和决策，工具负责执行，记忆负责跨轮上下文，编排逻辑负责把这些串起来。用一个智能客服Agent示例来说，当用户问“我前天买的鞋子到哪了”，编排流程是这样的：先由意图识别模块判断这是“查物流”，然后调用订单查询工具拿到物流单号，再检索物流API得到轨迹信息，最后让语言模型用自然语言把结果组织成一句友好回复。整个过程里，模型没有直接拍脑袋生成答案，而是基于工具返回的真实数据来回答。

构建Agent时，最有价值的设计是把工具调用结果和模型生成的答案分开记录。一旦出现问题，你可以分清到底是工具返回的数据错了、模型理解错了还是编排逻辑错了。我见过很多项目在Agent出bug时互相甩锅，最后打开日志才发现是上游接口超时。没有清晰的边界和日志，这种排查几乎不可能。

5.3 Prompt工作流与多Agent协作

Prompt engineering在Agent应用里依然扮演着核心角色。一个生产级prompt不只是“请帮我写个文案”这么简单，它需要包含角色设定、任务目标、输入字段限制、示例输出、禁忌行为。我通常会在prompt里强制模型输出JSON结构，方便程序解析，并在失败时走重试或规则兜底。千万别让模型输出一段自由文本然后靠正则去猜，那会把你逼疯。

多Agent协作是现在很热的方向，比如让一个Agent当规划者拆解任务、一个Agent当执行者调用工具、一个Agent当审查者检查结果。我的经验是先别急着上多Agent：每一步之间都传递不可靠的文本，错误会被逐级放大。更稳的打法是先用单Agent把单个任务的准确率做到95%以上，再考虑把多个单Agent串起来做流水线。如果一定要上多Agent，务必给每个子任务设置独立的验收标准，而不是只看最终输出。

6. 常见问题与经验快查

6.1 高频踩坑清单

这几年来，我把最容易反复出现的坑整理成了一张速查表，每次项目复盘都会对照一次：

6.2 我的三个小经验

第一个经验是：先做一个笨方案，再谈智能。我做过一个需求分析项目，第一版用20条正则规则跑起来，效果虽然粗，但让业务方看到了完整的交互链路；后来换成模型，才有一模一样的产品流程做对照。没有笨方案做基准，你压根说不清楚“模型比规则好在哪里”。

第二个经验是：日志和数据回流是整个项目最重要的投资。我刚做AI时觉得模型、算法才是难点，直到线上出了问题却翻不出有效日志，才明白没有数据闭环的AI项目就像一个没有后视镜的车。现在我写接口时，第一个需求永远是“把每次请求的输入、输出、性能指标原样留一份”。

第三个经验是：上线之前先写好降级方案。模型不可能永远稳定，API也一定会超时。你的系统必须能在模型不可用时自动切换到规则兜底或直接转人工。很多项目只盯着模型指标，却忘了给服务设计逃生通道，结果每次模型抖动都变成一次事故。

6.3 首个项目规模怎么定

从零开始做AI工程，我特别不建议第一个项目就选高难度、高风险的开放域任务。最理想的项目有三个特征：范围小、可量化、无致命后果。比如“工单自动分类”“相似问题去重”“文档摘要生成”这类任务，失败成本低、评估路径清晰，很适合练手。等你完整跑过一遍需求定义、数据构建、模型微调、部署监控、迭代回流的闭环，再挑战咨询客服、Agent编排、实时对话这些高复杂度场景，心态和方法都会从容很多。

我个人在实际操作中的体会是：AI工程从零到一的真正难点，从来不在于某一个算法的精妙，而在于你能不能把数据、模型、部署、评估、迭代这五个环节做成一个互相咬合的飞轮。模型可以换、框架可以换，但飞轮的每一环都得转起来。这个项目后续还可以这样扩展：如果你已经顺利跑通了单模型的闭环，下一步可以试着把两个Agent串联起来做更复杂的业务流程；如果你在微调中积累了高质量领域数据，还可以把这些数据顺着回流管道沉淀成一套专属评估集，让每次模型迭代都有一把更精准的尺子。先在一个小范围里把飞轮转到顺，再谈更大的野心。