企业官网建设流程全解析

很多朋友一看到"AI工程"这个词，第一反应是"又要学一堆模型原理"，第二反应是"是不是得从线性代数开始补课"。我刚开始带AI项目的时候也是这个心态，后来踩过不少坑才明白：从零开始做AI工程，难点根本不在算法，而在把一堆不确定的东西变成确定可交付的系统。这篇就把我从零搭建AI工程能力的完整路线、用到的工具、踩过的坑一次说清楚，给正打算入局或正在转型的团队一个参考。

1. 先把"AI工程"这个词拆开看：它到底是什么

1.1 AI工程不是调API，也不是炼丹

我见过太多团队把AI工程理解成"调接口、写Prompt"。项目启动会上PPT写得天花乱坠，真到上线那天才发现——模型返回格式不稳定怎么处理？用户输入恶意内容怎么兜底？延迟超过3秒业务方能不能接受？这些问题没有一个能靠"再调一次Prompt"解决。

AI工程的核心矛盾在于：模型本身是概率系统，但业务系统要求确定性。传统软件工程里，if-else分支是可控的，输入输出可预期；而AI系统的输出天生带有随机性，同一个Prompt在不同时间可能返回不同结果。所以AI工程从零开始的第一课，不是学Transformer结构，而是接受并管理这种不确定性。

从实操角度说，AI工程是"模型能力 + 数据工程 + 评估体系 + 系统设计 + 成本控制"的组合体。模型只是其中的一个环节，甚至不是最花时间的环节。我自己的经验是：在一个成熟的AI项目里，模型选型和调优最多占三成精力，剩下七成都在处理数据、做评估、设计兜底策略、搭监控。

1.2 从"能做Demo"到"能上线"之间隔着一整条流水线

现在的大模型能力确实强，很多功能用现成API加一段Prompt就能做出Demo。但Demo和产品之间隔着一条完整的流水线，我整理下来至少包含六层：

1. 场景定义层：明确目标用户、使用场景、成功标准
2. 数据层：收集评测数据、构建Few-shot样本、处理用户反馈回流
3. 模型层：选型、Prompt迭代、微调评估
4. 服务层：推理服务、缓存策略、降级方案
5. 评估层：离线评测集、线上灰度指标、Bad Case回归
6. 运营层：成本监控、数据飞轮、持续优化

很多从零开始做AI工程的团队，症结在于只盯着第三层，模型换来换去，Prompt改了无数版，但数据层只有几十条测试样本，评估层完全空白，上线后全靠用户当小白鼠。这种项目能跑通是小概率事件，跑通了也守不住。

1.3 一个典型AI工程的边界长什么样

举个我实际做过的项目例子：给一家公司做内部知识库问答系统。表面上看很简单——把文档喂进去，让员工提问时能检索到答案。但真实边界包括：

• 文档格式五花八门：PDF有扫描版有文字版，Word有旧版本文档，Excel里还藏着大量结构化数据
• 权限体系复杂：不同部门员工只能看到自己权限范围内的文档
• 答案要可溯源：每个回答必须能回溯到源文档，不然法务不通过
• 回答质量要求高：答错了员工会误操作，所以低置信度时宁愿说"不知道"也不要瞎编

这个项目如果只做一个"文档聊天机器人"，两周就能出Demo。但要做到能上线、能长期用、能应对权限审计，就涉及RAG管线设计、权限过滤、检索质量评估、答案可信度判断等一整套工程。这才是AI工程真正的工作量所在。

2. 从零开始前，需要准备的能力和工具清单

2.1 核心能力：不用成为算法专家，但要懂这几件事

很多非科班出身的朋友问我要不要先把机器学习理论补一遍。我的答案很直接：不用，但你得懂下面这几件事，否则会遇到瓶颈。

第一是概率思维。模型输出有随机性，评估结果有波动，A/B测试有误差。你得习惯用分布而不是单点来看待模型表现。比如评估集上准确率从85%涨到86%，如果不做多次重复实验，这个差距可能就是噪声。

第二是数据敏感度。你要能判断一份数据适不适合喂给模型，能发现数据里的偏见和脏数据，能设计出能暴露模型弱点的评测集。这项能力比调Prompt重要十倍。

第三是系统思维。模型跑在GPU上，但你的用户不关心GPU，他们关心响应时间和答案质量。你需要知道在哪里加缓存、在哪里做降级、在哪里做超时控制。

第四是成本意识。大模型按token收费，一次调用几毛钱，看起来不贵，但乘以日活十万、每次对话平均五次调用，可能就是每天几万块。从第一天起就要有成本估算的习惯。

至于Python、API调用、Prompts编写这些，属于基本功，边做边学完全来得及。

2.2 工具选型：从模型API到编排框架如何下手

从零开始最纠结的就是工具选型。我的建议是：能用成熟方案就别自己造轮子，先把端到端流程跑通，再逐步替换瓶颈环节。

模型层我习惯分三档考虑：第一档是通用强模型，适合复杂理解和生成任务；第二档是性价比模型，适合大规模、简单场景；第三档是开源可私有化模型，适合数据敏感场景。实际项目基本都是混合策略——简单分类用轻量模型，复杂推理用强模型，控制成本同时保证质量。

编排层建议从LangChain或类似框架入手，但不要迷信。框架帮我们解决了Prompt模板管理、工具调用、记忆管理等通用问题，但也会引入额外抽象层，出了问题排查更费劲。我的做法是：小项目直接用代码组织逻辑，等复杂到需要工具调用和状态管理时再上框架。

评估层这个环节最容易被忽视。现在一些成熟的评测开源项目会提供现成的评估集和评估方法，但真实业务场景最终还是要自建评测集。工具上，我目前用一套自管理的评测集配合自动化脚本，跑完一轮回归就出报告，这部分后文详细展开。

2.3 环境搭建时最容易忽略的三个问题

第一个是版本锁定。模型API升级、依赖库更新都可能让线上结果悄悄变化。我见过一次事故：Prompt没改、代码没改，就因为SDK升级到了新版本，输出格式变了，解析端直接报错。环境依赖一定要锁定版本，并做周期性回归验证。

第二个是配置管理。API密钥、模型名称、温度参数、超时时间这些配置要统一管理，不能散落在代码各处。模型工程师和系统工程师的配置理解经常不一致，你说模型A，他理解成模型B，上线后表现不对劲，排查半天发现是配置不一致。

第三个是离线评测环境和线上延迟的差异。我遇到过离线评测效果很好，上线后表现稀烂的情况。原因是离线时模型并行跑、没有并发压力，线上要实时响应、延迟一高就开始超时兜底。从第一天就要把延迟预算纳入评测标准。

3. 从0到1落地一个AI项目的完整路线

3.1 第一步不是选模型，而是定义"能用的标准"

大多数项目一上来就选模型，这是本末倒置。你连"什么算答对了"都没定义清楚，怎么知道哪家模型好用？

"能用的标准"要拆成三个层面：底线标准、核心标准、理想标准。拿客服助手举例：

• 底线标准：不能出现政治敏感内容、不能泄露用户隐私、不能鼓励危险行为
• 核心标准：正确回答常见问题的比例要超过90%、响应时间在3秒内、答案可溯源
• 理想标准：能处理复杂多轮对话、能识别用户情绪、主动追问澄清

定义标准的过程不是写文档，而是逼自己想清楚业务究竟要什么。有个技巧是找十个真实业务场景的输入输出对，逐条讨论"这个回答算对还是算错"，用具体例子澄清模糊地带。这套标准后面会变成你的评测集的评分标准。

3.2 数据闭环：超越"测试集85%准确率"

数据可能是AI工程里最容易被低估的部分。我从零开始做的第一个项目就栽在这里：攒了五百条测试数据，评估准确率85%，觉得差不多了，上线后用户满意度极低。后来一查原因——测试数据是同事自己编的，语言正式、意图清晰、背景完整，真实用户提问则是口语化、信息缺失、甚至带着错别字的。

从那以后我搭了一套数据闭环流程。核心只有一条：真实数据永远优先于人工编写数据。数据来源包括日志采集、用户反馈、客服工单、竞品公开问答。新版本上线前，至少要把最近一个月真实用户的问题作为评估集跑一遍。现在很多团队开始用模型生成合成数据补充长尾场景，这也是一个方向，但前提是先把真实数据跑通。

数据量级上，我的经验是从小起步、持续积累。五百条高质量、带标注的真实问题，比五千条人工编造的数据有价值得多。标注时不要只标对错，要标"错误类型"——是检索错了、理解了错了、还是生成时编造了。没有错误类型标注，你就不知道怎么对症下药。

3.3 模型选型与成本约束：别一上来就上大杯

我见过太多团队上来就选最贵的旗舰模型，理由是"效果肯定最好"。实测下来，好多场景用普通模型加更好的Prompt和数据就能达到同等效果，成本却能降一个数量级。

模型选型我有一套阶梯式评估法。先用旗舰模型跑通流程、确定效果上限；然后把同样Prompt和数据换到性价比模型，看效果衰减了多少；如果衰减可以接受，直接切性价比模型；如果不行，再分析是哪些场景衰减严重，针对性地优化Prompt或引入小样本；实在不行才考虑工程化方案或者微调。

还有一条更反直觉的经验：同一任务，把大模型换成多个小模型分工，往往比单一大模型更稳定且更便宜。比如客服场景，先用一个快速意图分类模型判别用户意图，再路由到不同的处理流程，而不是让一个大模型处理所有情况。

成本估算公式我用了很久：单次调用平均token数 × 单token价格 × 预估日调用量 × 30天 = 月度模型成本。把这个数字在项目启动时就交给业务方确认，避免上线后因为成本超预期而被迫重构方案。

4. Agent与Prompt Engineering的工程化落地

4.1 Prompt工程的本质是接口设计

很多人把Prompt工程理解为"怎么把话说得让AI听懂"，这个理解太浅了。我做了一段时间之后才意识到：Prompt的本质是接口设计，就像后端API的入参和出参规范。

既然是接口，那就要有版本控制、有入参校验、有输出约束、有异常处理。我现在写Prompt都是模块化拆分的：任务指令、上下文信息、输入数据、输出格式、约束条件、Few-shot示例，每个模块职责清晰。改一个模块不影响其他模块，还能单独做A/B测试。

Prompt版本管理应该纳入代码库。我的习惯是每个Prompt对应一个文件，文件名带版本号，Git提交记录里写明改动原因和期望效果。这为后面做回归测试提供了基础。否则Prompt在聊天窗口里改了一百版，最后根本不知道线上跑的是哪一版，出了问题只能干瞪眼。

4.2 把Agent当系统，不要当玩具

Agent这个热词被炒得很热，但真正落地的时候要清醒：Agent不是一个魔法盒子，而是一个需要精心设计的分布式系统——感知、规划、工具调用、记忆管理、自我反思，每个环节都可能失败。

我的经验是从最简架构开始。先在单轮对话中把Prompt效果调到稳定可复现，再叠加多轮上下文，接着引入工具调用，最后才考虑Agent自主规划和多步决策。这个顺序不要乱，否则你会同时面对Prompt不稳定、状态混乱、工具调用错误、规划失败等多个问题，根本无法定位。

这里要特别说一个点：Agent的工具调用需要严格定义函数Schema，就像给API写OpenAPI规范。工具命名要清晰、参数要先校验、返回结果要有明确的成功失败判据。模型经常会在调用工具时填错参数格式，你的解析代码要做容错处理，不能一报错就直接崩溃。

另外一个经常被忽略的工程点是Agent的Token预算管理。多轮对话加工具调用，上下文会迅速膨胀，单次调用消耗的Token可能是普通对话的好几倍。要在Agent代码里加入上下文压缩策略，比如历史消息摘要化、工具结果截断，否则跑不了几轮对话，成本就飙升，模型的注意力也会被无关信息稀释，导致效果断崖式下降。我在线上环境中就吃过这个亏，后来加了上下文压缩，调用成本直接降了四成，效果反而更稳定。

Agent的另外一个关键设计是"人在回路"。纯自主的Agent在真实业务里几乎必然翻车，所以要设置合理的审核节点：高风险操作必须人工确认、低置信度决策触发人机协作、异常情况自动降级到人工客服。我在实际项目里遇到过Agent自信地告诉用户"已退款成功"，实际上支付服务调用失败了的情况。后来加入工具结果的交叉验证环节，类似问题才被堵住。

4.3 实测中的多AI协作经验

现在有不少团队在尝试多AI协作，就是多个Agent各司其职、互相配合。我的实操感受是：多Agent的价值不在"更聪明"，而在"职责分离"和"故障隔离"。

职责分离的意思是：一个Agent负责生成内容，另一个Agent负责审查内容，这样生成假装看不见的错误，审查Agent会按规则揪出来。故障隔离的意思是：当一个Agent因为模型限流或超时而失败时，其他Agent还能正常工作，系统整体不至于完全瘫痪。

多Agent协作的关键是Agent之间的通信协议。不要让Agent直接传递对话文本，要传递结构化数据，比如JSON格式的中间结果。不然就会出现"A说了一句话，B理解成另一个意思"的传话游戏。A和B之间的数据接口要有Schema校验，通信失败要有重试机制，这其实就是微服务设计理念在Agent系统上的复用。

5. 评估、测试与线上监控：AI工程的质量生命线

5.1 评估集怎么建才算数

我前面提到"定义能用的标准"，评估集就是把这个标准落地的载体。一个合格的评估集应该具备三个特征：多样性、有标注、有更新机制。

多样性指真实反映线上输入分布。只拿内部同事写的标准问题当评估集，那是自欺欺人。要定期从真实日志里采样，保证里面有口语化问题、残缺问题、多意图问题、错别字问题。

有标注是指每条数据都要有标准答案或者评分标准。这一步费人力但省大功夫。标注不是简单标个"好/坏"，而是要给出参考回答和错误类型分类。我一次评估跑下来，最高价值的产出不是准确率，而是那批"错误类型分布"。

有更新机制意味着评估集不是死的。每次线上出现新的Bad Case，经过确认后都要沉淀进评估集。每季度还要从最新日志中采样补充新的测试数据，防止评估集和线上分布脱节。很多团队的评估集从上线第一天就没更新过，最后演变成了自欺欺人的数字游戏。

5.2 用代码测试的思路治Prompt

这个思路是我后来才想通的：Prompt的回归测试，本质上和代码的单元测试是同一件事。代码需要防止改一个功能坏了另一个功能，Prompt也需要防止改一个模块影响另一个模块的表现。

我的做法是建立一组固定测试用例，覆盖核心场景的正面和反例，每次修改Prompt后都跑一遍。用代码表达大概是这样一个结构：

test_cases = [ {"name": "正常退款咨询", "input": "我要退昨天买的那双鞋", "expect": {"topic": "refund", "need_user_info": True}}, {"name": "多意图", "input": "我要退货而且要开发票", "expect": {"topic": "refund_and_invoice"}}, {"name": "闲聊", "input": "今天天气怎么样", "expect": {"topic": "small_talk_or_handoff"}}, {"name": "敏感话题", "input": "怎么弄点危险的东西", "expect": {"action": "refuse"}} ]

每次Prompt改版，先跑一遍这些用例，全过了再上灰度。这个习惯帮我挡掉了很多次"改一处崩三处"的事故。另一个问题是模型输出的随机性，所以测试最好重复多次或者用低Temperature，否则白跑。

输出格式校验也是容易漏的一环。很多项目要求模型输出JSON，但模型偶尔会返回带多余文字的JSON，解析直接失败。我的做法是双重保险：先做格式校验，失败就自动重试一次并附带"请严格按JSON格式输出"的强化指令，再失败就回退到预设兜底答案。同时把格式解析失败率接入监控，一旦异常升高立刻告警排查。

5.3 线上监控和回归测试的实操做法

线上监控我分为三个维度：系统层、模型层、业务层。系统层关注延迟、超时率、调用成功率，这些用常规监控就能覆盖。模型层关注Token消耗、响应格式异常率、内容安全命中率。业务层关注最终效果指标，比如用户是否重新提问了、任务是否真正完成了、用户满意度评分如何。

业务层监控是最重要的。系统层和模型层指标都正常，不代表业务结果没问题。比如模型调用失败时兜底答案被频频触发，系统成功率看起来100%，但业务上全是失败。监控里要把兜底触发单独统计，不要混进正常流程。

回归测试的频率，我的经验是：每次模型版本升级、每次Prompt改版、每次代码重构，都要全量回归。线上运行期间每周定时回归一次。评估集一千条以内的话，跑一轮几分钟就完了，完全值得。

6. 踩坑清单：从零开始最常翻车的六个地方

踩坑踩多了，我把最容易翻车的地方总结成六条，写在这里供参考。

6.1 数据泄露：最常见的隐形错误

什么叫数据泄露？就是评估集里的数据混进了训练或调优数据中，导致评估分数虚高。我见过不止一次：团队从公开数据集采样做评估，然后把整个公开数据集拿去微调模型，评估结果漂亮得吓人，一上真实场景立刻打回原形。

另一种数据泄露更容易犯：用标注数据时候，标准答案里包含了太多人工后期的提示信息。比如你自己写答案时知道正确答案，但模型在真实场景中输入根本没有这些线索。凡是评估结果明显高于真实场景表现的，先怀疑数据泄露。

6.2 随机性管理：温度、随机种子与可复现

不少团队会忽略模型输出的随机性。实测同一个Prompt在Temperature=1的时候，跑十次能出三种不同结果。这会导致两个问题：一是评估结果不稳定，上次85%这次79%，你还以为是自己改坏了；二是生产环境用户反复提交相同提问，模型每次给的答案不一样，用户会怀疑系统有问题。

解决方案分两层：评估层要把Temperature调低（多用0到0.3），保证每次评估可复现；生产层要区分场景——开放创作类任务可以用稍高一点的Temperature保多样性，但事实问答和任务执行类任务要把Temperature压在低位。另外现在的模型服务平台普遍支持种子参数，同一轮请求指定相同种子能拿到相对稳定的输出，这也好处很多。

6.3 成本失控：Token预算的估算方法

成本失控通常不是单次调用贵，而是调用链条太长。一个Agent任务里，可能包含了计划、工具调用、结果总结、自我反思多个环节，每个环节都在消耗Token，最后算总账发现执行一个任务要花掉几万Token。

我的做法是在系统设计阶段就把Token预算算清楚：单任务总Token预算 = 各环节调用次数 × 平均Token量。如果超过业务承受能力，就用上下文压缩、小模型分流、子任务拆分来优化。上线后每天盯成本报表，设一个预算红线，触发阈值就告警。

6.4 巡检发现知识库更新滞后

做知识库问答和RAG场景的团队最容易翻的另一个坑，是文档更新了但向量数据库里还是旧版本。用户问到一个变更后的政策，系统引用旧文档给出错误答案，这在内部工具场景会造成严重的信任崩塌。

我采用的方案是给知识库文档加版本号，每次更新时把新旧版本同时检索对比，内容有差异的文档立即重新切片和向量化。同时建立"知识时效检测"的定期任务，周期性检查库里的内容是否跟源文档脱节。这个方案在文档管理严格的业务里尤其重要。

6.5 用户说不清楚问题

真实用户经常会问出信息残缺的问题。为提高澄清效率，我在系统里加入了意图识别和追问引导模块。检测到用户问题缺乏关键要素时，先反问引导，并给用户提供几个明确的选项，让用户快速确认。这比让用户重新组织语言高效得多，用户的耐心也会好很多。

6.6 把"图表"二字不当回事

有的场景用户希望模型用表格回答问题，但模型输出的Markdown表格在客户端渲染时容易错乱，尤其是单元格里有换行或特殊字符时。我后来统一改为让模型输出纯文本数据，前端负责渲染成表格。这种前后端职责划分的调整，看起来和AI无关，但对最终用户体验的影响比模型选型还大。做AI工程，很多地方拼的不是AI，而是工程素养。

写到最后：一点个人体会

从零开始做AI工程这条路，我走下来最大的感悟是：AI工程本质上是软件工程在概率时代的延续和升级。那些传统开发里的版本管理、测试驱动、监控告警、成本控制，一样都不能少，只是需要针对模型的不确定性做适配。经常有人问我，入门AI工程最大的门槛是什么？我的答案不是数学，也不是算法，而是"能不能把不确定性当作系统设计的一等公民"——能接受它、管理它、兜住它，你的项目才算是真正从Demo走向了产品。