企业官网建设流程全解析

如果你以为AI工程的核心是精通各种模型、亲手训练一个超大参数网络，那方向大概率偏了。做这一行这几年，我最深的感受是：真正的难点从来不在“模型”本身，而在模型之外的整个系统。所谓from scratch，不是让你从矩阵乘法开始重写Transformer，而是把一个模糊想法，从零变成可运行、可维护、可评估、可迭代的生产系统。这中间绕不开业务拆解、数据治理、方案选型、评估机制、部署运维——每一个环节都能让项目翻车，而它们恰恰是教程最爱跳过的地方。

这篇文章我想把从零搭建AI工程的完整链路摊开讲一遍。内容包括：怎么把业务需求翻译成AI任务，怎么搭数据管线，提示词工程、RAG、微调到底按什么顺序选，怎么建评估集防止模型越改越差，最后怎么把模型稳稳跑进生产环境。无论你是在企业里负责落地AI应用，还是准备独立做一个AI产品，这套框架可以直接拿去做项目骨架。

1. 先把认知框架搭好：AI工程到底是什么

1.1 它和算法开发、传统软件开发的本质区别

很多团队在立项时就栽了跟头，因为把AI工程当成了“写算法”或者“写接口”。传统软件开发，核心是确定逻辑，要求精确、可复现，写错了改代码就行；算法开发，核心是调指标，追求在测试集上分数更高。但AI工程面对的完全是另一种对象：模型输出天然带不确定性，你不能像 assert 一个函数返回值那样去验证它。

我把三者做了个对比，方便你快速定位自己处在哪一层：

这个差别非常关键。写个if-else出错，你能顺着堆栈找到原因；但AI模型答错了，问题往往出在上下文、数据质量、Prompt写法，甚至上游知识库更新，排查路径完全不在代码里。你没法用“修bug”的思维来处理AI系统，只能建立一套机制去约束不确定性，让它在绝大多数情况下表现稳定，在异常情况下能被及时发现。

1.2 一条完整的AI工程链路长什么样

我见过太多人一上来就扎进模型选型，跑通一个demo后兴奋不已，结果到了上线前才发现评估集没有、监控没有、数据没治理，整个项目卡在最后一公里。

建议所有从零起步的人，先建立这条链路认知：

1. 业务问题定义：搞清楚要解决什么问题，输入是什么，输出给谁用。
2. 数据盘点与采集：现有数据是否可用，缺什么，格式是否统一，是否合规。
3. 评估集构建：在动任何模型方案之前，先准备一批能衡量效果的样本。
4. 方案选型：按成本从低到高，依次考虑提示词工程、RAG、微调。
5. 服务封装与部署：把模型推理封装成稳定API，设置超时、限流、降级。
6. 监控与回归：盯住质量、成本、延迟，每次改动都跑回归测试。
7. 迭代优化：基于监控反馈持续调整数据、Prompt、检索策略。

这条链路里，模型选型反而是最好解决的，因为无论用成熟API还是开源模型，都有大量现成方案可以借力。真正花时间的，是每个环节都要用工程思维去约束不确定性。

2. 从零开始的实操起点：业务边界与数据准备

2.1 把模糊需求翻译成可执行的AI任务

“我要做一个智能客服”“我要做一个文档问答机器人”，这类需求听着合理，实际上没法直接开工。AI任务必须能回答四个问题：输入是什么，输出是什么，正确标准是什么，失败了怎么办。

我举一个实际拆解案例。之前接到一个“自动回答产品问题”的需求，当时没有直接去调模型，而是先拆步骤：

1. 意图分类：用户问的是价格、退货、物流还是使用方法。
2. 知识检索：根据意图，从商品FAQ库和售后知识库中检索相关内容。
3. 生成回答：基于检索到的内容，生成一段拟人化回复，并附上来源编号。

拆完之后，整个AI任务边界就清晰了。后面每一步都可单独测试，哪一步出了问题能快速定位。比如用户问退货政策，模型回答了物流时效，那就是意图分类错了，不是生成环节的问题。

你可以用下面五个问题自检一个需求是否拆到位：

• 输入是自由文本，还是结构化数据？长度上限是多少？
• 输出需要固定格式，还是自由生成？是否要求附带依据？
• “回答正确”的标准是什么？谁来定义？
• 如果模型不置信，或者完全不知道答案，系统如何处理？
• 最终结果是否需要人工确认才能生效？

这五个问题想不清楚，后面做的所有技术选型都是空中楼阁。

2.2 数据：工程里最容易被低估的环节

数据工作通常比想象中耗时两到三倍。启动之前，先盘点三件事：存量、质量、合规。

存量方面，要看手头有什么数据可用。文档、FAQ、历史工单、商品类目表，这些都是天然的语料来源。质量方面，要处理格式不统一、编码混乱、日期格式各异、重复内容等问题。合规是最容易出事的一环，用户隐私、未公开信息、敏感字段，必须在进入管线前完成脱敏。

我见过一次典型翻车：把客户聊天记录直接喂给模型用于训练优化，结果模型在某个对话里生成了另一位客户的姓名和手机号。这就是数据管线没做脱敏导致的严重事故。你在开始任何AI项目前，第一件事就是建立数据准入规则：什么数据能进系统，什么数据绝对不能碰。

评估集的建设要趁早，别等模型选型结束再做。我的经验是，不用追求几千几万条，100到300条精选样本就足够启动。每条样本最好包含：

• 输入内容
• 期望输出
• 可接受的范围说明
• 边界情况标签，比如知识库没有答案的问题、包含敏感词的问题、超长问题

评估集不追求全量覆盖，但一定要覆盖主要业务场景和典型错误模式。有了它，后面每一次Prompt修改、每一次模型替换、每一次检索策略调整，都能有据可依。说句直白的话：没有评估集的AI项目，跟裸奔没什么区别。

3. 模型方案选型：先别急着微调

3.1 三层递进：提示词工程 → RAG → 微调

很多人一上来就问“要不要微调一个模型”，我的回答通常是：先别。选型要按成本从低到高、迭代从快到慢的顺序来，这个顺序是有依据的。

第一层是提示词工程。把需求写清楚，把约束写明，把输出格式定义好。大量业务问题在这一层就能解决，成本最低，迭代最快，改一句话就能生效。

第二层是RAG，检索增强生成。当业务需要依赖大量知识、事实准确度要求高、知识需要持续更新时，就给模型外挂一个可检索的文档库。模型每次回答前，先从库里检索相关内容作为参考，能显著降低幻觉风险。

第三层是微调。只有当模型的行为模式本身有问题，比如格式不稳定、风格不符合要求、领域术语使用混乱，才需要考虑微调。微调成本高、更新慢、回滚麻烦，一旦训完，后续基础模型升级时你可能被绑定在旧版本上。

你可以把这三层简单类比成带新人：

• 提示词工程，是给员工写一份清晰的岗位说明书。
• RAG，是给员工配一个随时能查的资料柜。
• 微调，是把员工送去集训，彻底改变他的工作习惯。

岗位说明能解决大部分问题，资料柜解决知识问题，集训是最后手段。所以我的选择顺序永远是：先Prompt，再RAG，最后才微调。

3.2 推理成本与延迟：动手算一遍，别拍脑袋

方案选型时，只看效果不看成本，是很多项目后期爆雷的原因。我建议所有人在选型阶段就建立一套成本估算方式。这里给一个可复用的计算方法。

假设某个业务每天有1万次调用，每次输入约4000 tokens，输出约500 tokens。用某款API，输入价格是3美元/百万tokens，输出价格是15美元/百万tokens：

• 输入成本 = 10000 × 4000 ÷ 1000000 × 3 = 120美元/天
• 输出成本 = 10000 × 500 ÷ 1000000 × 15 = 75美元/天
• 合计约195美元/天，一个月就是5850美元

如果引入RAG之后，每次输入从4000 tokens涨到8000 tokens，输入成本直接翻倍到240美元/天。这还只是单条链路的计算，如果检索结果拼装不当，上下文达到1.5万甚至2万tokens，成本涨得更快。

延迟同理。输入越长，首字延迟越高。在交互式场景里，用户能接受的响应时间通常在2到3秒以内。你一定要在选型阶段就确认：当前方案的上下文长度、模型推理速度，能不能满足线上体验要求。

这里有一个成本优化的实用技巧：对高频问题做缓存。把常见的用户问题和对应答案缓存起来，下次直接命中缓存，不再调用模型。我实测下来，在FAQ类场景里，缓存命中率能做到50%到70%，成本直接砍掉一大半。

4. 评估体系：质量、成本、延迟一个都不能松

4.1 建评测集：别用感觉判断模型好坏

“感觉还行”是AI项目里最危险的一句话。人的感觉会受到上次对话影响，会被模型的表达流畅度误导，而且不同人感觉标准完全不同。团队里改Prompt的人只要凭感觉动手，上线质量就一定飘忽不定。

我的做法是，要求每个项目在动手前先建立三维评估框架：

• 正确性：回答事实是否正确，是否忠实于给出的材料。
• 完整性：用户问题中的要点是否全部覆盖，有没有遗漏关键信息。
• 格式合规：输出是否是约定格式，能否被下游正常解析。

对于生成类任务，可以先组织人工评估，确定一个基线分数。比如人工评审100条测试样本，记录每条回答是否合格，算出基线通过率。之后再逐步引入模型评分作为回归信号，减少人工成本。但模型评分只能作为参考，初期阶段人工抽检一定不能省。

我推荐一个最笨但最有效的做法：把评测结果记录成表格，每次改动后对比分数变化。这样你很快就会发现，某些Prompt优化只是让模型读起来更顺，实际正确率并没有提高，甚至下降了。

4.2 回归测试与防退化

AI系统退化是悄悄发生的。上游文档更新了、Prompt里调整了一句话、模型商发了新版本，都可能让效果变差，而且很难直观察觉。最典型的场景是：上周还正常的系统，这周用户反馈变多了，但没人说得清是哪里变了。

解决办法只有一个：把评测集当代码一样管起来。

• 评测集按版本入库，任何改动前跑一遍全量回归。
• 记录每个版本的评估分数、成本、延迟，形成历史基线。
• 设置准出标准，比如新版本的正确率不得低于当前线上版本，否则禁止上线。

这里有个心态上的转变：AI系统和传统系统不同，你没法保证它永远不变差，只能保证变化是可见的、可回滚的。有了回归机制，你才敢大胆优化Prompt、调整参数。没有回归机制，团队会越来越不敢动系统，最后连改一个标点都如履薄冰，项目自然就僵住了。

5. 部署与运维：从本地Demo到生产系统

5.1 接口设计与服务封装

很多人的Demo跑得很好，一到生产环境就崩。原因很简单：本地是单用户、低并发、无超时，生产环境是多用户、高并发、第三方服务随时可能故障。模型部署不只是加载一个模型，而要把推理能力封装成稳定服务。

我给出一个最小可用的FastAPI接口示例，包含输入校验和基础返回结构：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI() class QARequest(BaseModel): question: str user_id: str = "anonymous" class QAResponse(BaseModel): answer: str sources: list[str] = [] confidence: float = 0.0 @app.post("/api/qa", response_model=QAResponse) async def qa(req: QARequest): # 输入长度校验，防止用户传入超长文本拖垮资源 if len(req.question) > 2000: raise HTTPException(status_code=400, detail="question too long") # 实际项目中，这里应该调用内部推理服务 # 并捕获模型调用异常、设置超时时间 try: answer, sources, confidence = call_model_service(req.question) except TimeoutError: raise HTTPException(status_code=504, detail="model inference timeout") return QAResponse(answer=answer, sources=sources, confidence=confidence)

这里有几个工程细节值得注意。返回结构里一定要带上sources和confidence，线上排查问题时，这两项是救命稻草。接口层要做超时控制和异常捕获，不能让模型调用把整个服务拖死。还要做流控，限制单用户的请求频率，防止恶意刷接口或者内部调用异常。

5.2 监控指标与报警阈值

部署上线只是开始，监控才是长期运营的核心。我推荐从六个指标切入，这六个维度基本能覆盖一个AI服务的健康状态：

很多团队只盯准确率，忽视了成本与延迟。但实际运营中，一次模型商调价或者一个Prompt改长，导致成本上涨50%，往往比正确率下降更容易让项目死亡。监控不是用来摆设的，报警之后必须有人响应、有处理预案。建议在项目启动时就约定好：收到告警看哪些日志，谁来决策是否回滚版本。

6. 你大概率会踩的坑：问题速查与解决办法

6.1 幻觉：模型一本正经地胡说八道

模型不是数据库，它是一个接话高手。知识库里没有的内容，它可能编一个像模像样的答案出来。我踩过的坑是，早期一个问答项目没做RAG，直接用模型答产品问题，结果用户在问一款已停产设备时，模型信誓旦旦地给了保修政策，实际早就失效了。

应对幻觉，我的经验是三层防线：

1. 给材料：用RAG把检索到的文档片段作为依据，强制模型只根据材料回答。
2. 允许说不知道：Prompt里明确写“如果材料中没有答案，直接回答不知道，不要编造”。
3. 返回来源：回答时附上引用来源编号，人工审核可以直接定位依据。

Prompt里可以这样约束：

你是一个客服助手。请仅根据提供的资料回答用户问题。 如果资料中没有相关信息，请直接回答"根据现有资料无法确认"。 回答必须附上资料编号，格式：[来源1]、[来源2]。 不要推测，不要编造。

另外，评测集里一定要加“知识库没有答案”的干扰样本，专门测试模型会不会硬编。如果连“我不知道”都不肯说，说明Prompt约束力度不够，还需要加强上下文约束或者调低温度参数。

6.2 Token成本失控：长上下文的隐形刺客

很多人在Demo阶段图省事，把整本手册塞进上下文窗口，跑通一次觉得效果不错，结果上线后账单爆表。这类问题每天都在发生，而且越晚发现越难收场。

我在一个项目里曾经遇到，研发同学把一份3万字的内部文档直接拼进提示词，每次调用光输入就消耗约2万tokens。一天几千次调用，成本直接失控。后来改成RAG方案，先检索再拼装，每次调用只保留最相关的3到5个片段，上下文从2万降到3000 tokens，成本砍掉80%以上，效果反而更稳定。

给一个“成本防爆”清单：

• 检索只取Top-k，默认k取3到5，不要贪多。
• 高频问题做结果缓存，缓存命中率能到50%以上。
• 长文本先做摘要，只把摘要和关键片段送入模型。
• 定期统计日均token消耗，按阶段评估成本变化。

6.3 版本管理与可复现性

做AI系统最痛苦的事不是开发，而是回溯。上线一周后效果变差，你问团队“这周改了什么”，得到的回答往往是：好像改了Prompt，又好像调了参数，数据好像也更新了。这种状态基本等于盲人摸象。

解决方案是给每个项目维护一个manifest配置文件，把每次实验的环境、模型、Prompt、数据、参数全部记录清楚：

model: gpt-4o-mini model_version: 2024-06-01 prompt: prompts/qa_v3.txt dataset: eval_sets/qa_20241001.json rag: index: faq_20240901 top_k: 5 temperature: 0.1 max_tokens: 500 created_by: team-member-name

这个文件的作用，是让你在任何时候都能精确复现当时的行为。效果下降了，先看manifest，对比当前版本和基线版本差在哪，快速定位改动点，而不是靠猜。

最后再分享一个小体会。做AI工程这几年，让我最受益的不是会调多少模型，而是把每个改动都当成实验来对待。评估集、基线、manifest这些机制，初期确实会占一点时间，但它们能在你需要解释“为什么效果变差”的关键时刻，把人从火坑里捞出来。如果你也是从零开始做AI工程，我的建议是：别急着追求复杂的模型方案，先把业务边界、数据、评估、链路搭好，剩下的交给时间。