企业官网建设流程全解析

1. 重新认识“AI工程”：为什么说它不等于会调大模型API

最近常有人问我“AI工程到底从哪开始学”，也看到不少朋友把“会用ChatGPT写提示词”“能跑通一个官方Demo”当成自己入了AI工程的门。这两个理解都有点偏差。

先说我的看法：AI工程（AI Engineering）的核心，是把大模型从一个“能聊天的API”变成“一个稳定、可维护、可评估、能迭代的业务系统”。它横跨模型交互、数据工程、应用架构、评估体系、监控告警、成本控制六块内容。会调API只是其中最小的一块，甚至可以说是最不稀缺的一块——因为任何一个人花半小时看文档就能调用API，但能不能让这个API在你自己的业务场景里稳定产出高质量结果，才是真正拉开差距的地方。

这个标题“ai-engineering-from-scratch”其实点出了一个问题：很多人在起步阶段就选错了学习路径。要么从底层算法开始死磕Transformer公式，半年过去还在原地，要么从提示词技巧开始，学着学着发现全是碎片知识。两种路径都忽略了AI工程最本质的特征：它不是靠某一个单点技巧就能搞定的，而是一整套“从模型能力到系统落地”的工程方法。

我建议所有把这个领域当长期方向的朋友，先建立一张认知地图。这张地图大概长这样：

这六个能力域不是并列优先级，而是有一条时间线的。我的经验是：先做模型交互和数据工程把“单点跑通”，再做评估和架构把“系统做稳”，最后做监控和迭代把“业务做好”。这篇文章接下来就按这条时间线拆开讲，尽量把所有关键细节和坑都摊开说清楚。

2. 起步阶段最容易走偏的地方：模型选型、提示词和RAG的正确打开方式

2.1 模型选型不是越低配越好，也不是越大越好

很多人接触到的第一课就是“选模型”。但你会发现教程里很少讲清楚选型的完整逻辑。我踩过最大的坑是：给一个客服问答场景选了一个超大参数模型，效果确实好，但每次请求的延迟让用户等到怀疑人生，成本也让老板脸色发青。

选模型至少要同时看四个维度：效果天花板、响应延迟、单位成本、生态成熟度。判断效果天花板要拿自己的真实业务问题去测，不要只看公开榜单。榜单上的成绩用的是通用评测集，而你的场景大概率是垂直领域，通用分数高不代表你的问题答得好。延迟和成本更不用多说，这两者是线上系统的硬约束。

我建议第一次做项目的人，不要一上来就追求SOTA。先用性价比最高的模型把整条链路跑通，预留模型切换的抽象层，然后在评估数据的指导下逐步升级模型。这么做的好处是：你可以先解决“系统能不能转”的问题，再解决“答案准不准”的问题，避免混合在一起时连哪里出了问题都分不清。

2.2 提示词工程是基本功，但它的边界比你想象的小

提示词工程确实可以在不修改模型的情况下大幅提升输出质量，但它有两个容易被忽略的边界。

第一，提示词解决不了知识盲区。模型没见过你业务里的私有文档，你写一万字的提示词它也编不出来。这个场景必须靠RAG（检索增强）或者微调来补。第二，提示词解决不了逻辑幻觉。你让模型做多步推理，它在中间某一步算错之后，后面的步骤都会跟着错，提示词里写“请小心计算”没有任何作用，得靠代码强制拆分步骤、校验中间结果。

那提示词工程到底该学什么？以实用为准，我认为是四个手艺：角色与约束的写法、示例选择的策略（Few-shot）、结构化输出约束（JSON/XML输出设计）、以及把复杂任务拆成多步调用的思维。这四个手艺的目标只有一个：让模型输出变得可预测。可预测是工程化的前提，因为你线上逻辑要根据输出做判断。

2.3 RAG做不好，绝大多数问题出在“检索”而不是“生成”

RAG是现在私有知识库场景的标准做法，但很多人的做法其实有问题：他们花大量时间调提示词，希望模型把检索出来的内容用好——但真正的瓶颈往往在检索端，相关文档压根没被检索出来。

一个合格的RAG链路至少包含：文档切分策略（Chunk Size与重叠设置）、向量化模型选择（Embedding Model）、检索方式（向量检索还是关键词+向量的混合检索）、重排序（Rerank）。切分策略直接影响召回率：切得太碎语义断裂，切得太整检索命中不精准。我见过很多团队在切分上拍脑袋，我建议花几个晚上做切分参数的对比实验，用一组标注好的问答对来看召回率变化，这一步的效果立竿见影。

更要强调的是：别再相信“向量检索是万能的”这句话。向量检索在语义相似上很强，但在精确词匹配上可能被关键词搜索吊打。生产级RAG一般做混合检索：先让向量和BM25各自召回一批文档，再用Rerank模型对合并结果重新打分排序。这个“三明治结构”才是目前在成本和效果之间比较均衡的实践方案，也是AI工程从Demo走向可用的关键分水岭。

3. 从“能跑通”到“能上线”的关键暗线：评估、监控、数据回流

3.1 没有评估体系，你根本不知道模型表现是好是坏

判断AI工程能力强弱，有一个非常直观的标准：看他有没有建立评估体系。没有评估体系的人在描述系统质量时只能说“感觉还行”，有评估体系的人能从数据集规模、通过率、延迟分布、成本曲线四个维度说出当前系统的状态。

评估体系的第一步是构建金标数据集（Golden Set）。不用贪多，先攒两百条覆盖业务典型场景的“输入-期望输出”对，重点是覆盖度。比如你做客服问答，就要覆盖售前咨询、售后投诉、价格计算、物流查询这些场景；每个场景还要区分简单问题和复杂问题。评估不用追求一次到位，可以从LLM-as-a-Judge开始，也就是用更强或者对齐过的模型来打分，但要控制好评估模型自己的偏差。

我把离线评估流程拆成五步：

1. 定义任务的输入输出格式
2. 按场景维度设计评测问题集，覆盖典型、边界、异常输入
3. 选择评估方式：规则校验、关键信息抽取比对、模型评分
4. 建立评价指标表格：准确率、召回率、格式合规率、失败率
5. 每次改动后跑同一套评测集，记录指标变化

这套流程的价值在一次真实场景里完全体现了：有一次我改了提示词，试着提升问答的详细程度，结果直观感觉回答“更饱满”了，但跑评测集发现格式合规率下降，导致下游解析报错率上升。如果没有评测，我可能就把这个改动带上线了。

3.2 线上监控和告警：模型不是“上线就不管”的代码

很多从传统后端转过来的工程师，天然会做服务的健康检查、错误日志、接口监控，但到了AI应用上容易忽略三个指标：Token消耗量、响应时延、以及回答质量的漂移。

Token消耗量就是钱。上线前一定要给每条请求设置Token上限，不要只设超时时间。我见过一个代价不低的案例：业务方在提示词里放了大段上下文和检索文档，单次请求消耗Token量惊人，一个月成本就超出了年度预算。而这个问题在开发阶段根本不会暴露，因为你自己测试时哪会测一万次。

时延监控更重要。大模型请求动辄两三秒，这不像传统API的几十毫秒，用户是能感知到“转圈”的。所以设计系统时要考虑：哪些环节可以缓存，哪些步骤可以并行，哪些模型调用必须串行。举例来说，如果你要模型先做意图识别再做答案生成，这两个调用其实是串行的，总延迟会叠加。我的建议是：优先做轻量模型分流，简单请求走小模型快速返回，复杂请求才调用大模型，延迟和成本都能显著下降。

质量漂移指的是模型行为会随版本升级、提示词修改、输入分布变化而变化。你周一上线的完美系统，到了周末可能因为用户提问方式的偏移而效果变差。应对方案并不复杂：定期用金标数据集做回归测试，把“评测”从开发期动作变成“每周例行动作”，一有变化就能发现。

3.3 数据回流：让系统自动变聪明的机制

AI工程和传统软件工程最大的区别，是它有“数据飞轮”这回事。每次线上调用留下的日志，反馈按钮里用户点的“赞”和“踩”，都被模型效果优化过程中的金矿。但大多数团队连日志结构都没设计好。

我建议从第一天就给日志设计三个字段：请求输入全文、模型输出全文、检索命中文档列表。不要心存侥幸，这三样缺一个，后续做分析和微调时都会很痛苦。输出层面还要加一个重要的东西：可追溯的版本号——模型版本、提示词版本、以及检索配置版本都要记录。没有版本号，你分析线上问题时就像在一堆没有时间线的照片里找某一天的场景。

数据回流之后做什么？三个方向。第一，用错误样本做评估集的扩充，很多评测问题就是从线上真实失败案例里提炼出来的。第二，用高置信失败样本做提示词的迭代，新提示词针对这些失败案例进行优化。第三，积累足够多的特定领域样本后，可以考虑对模型做参数微调。但要记住，微调不是必须的，先确认提示词和RAG优化是否已经逼近极限，再决定要不要动这个更重的武器。

4. 一条可以照着走的“从零到一”学习路线与项目实践计划

4.1 先花40小时过基本功关卡

进入项目实操前，基本功必须过一遍，否则所有问题都会混在一起，难度呈几何倍数上升。

需要过关的清单：

• Python基础：能熟练使用requests、pydantic、asyncio，会组织项目目录结构
• API调用：理解流式输出、重试机制、超时配置，会解析结构化响应
• 数据操作：掌握JSON/CSV处理，能在几百条数据里做去重、清洗、转换
• Git版本管理：能独立开分支、提交、回滚，不污染主分支
• 基础评测能力：会写一个简单的脚本，批量调用模型并统计指标

我自己见过不少朋友跳过这些基础，直接读Agent框架源码，结果框架里的异步机制和工具调用逻辑理解不了，卡了几天，最后丧失信心。不是说基础必须全部精通才能动手，但这几项每项至少要有“能动手”的水平，否则实战时会不断回到基础问题上浪费时间。

4.2 用五个小项目建立“端到端”手感

理论学习再多，都不如亲手搭几个完整的项目。但项目选择有讲究，顺序也很重要。

我的推荐顺序：

1. 智能客服问答机器人：基于一份产品手册做RAG问答，这是RAG的入门标配。
2. 结构化信息抽取器：从非结构化文本里抽取字段并输出JSON，锻炼结构化输出能力。
3. 多步骤任务代理：让模型按计划调度工具完成任务，比如查天气、算时间再回答，理解Agent基础。
4. 文档分析报告生成器：输入多份文档，让模型生成总结报告，锻炼长文本和输出稳定性。
5. 评估工作台：把前三步的结果统一做离线评测，可视化指标变化，建立评估意识。

这五个项目建议每两到三周完成一个，关键是每一个都要求“端到端”——从数据准备、代码实现、评测到部署到一个能用链接访问的服务。注意，很多人做到第四个项目才发现认知升级了，原因是前三步只锻炼了“如何调用模型”，第四步才开始思考“如何驾驭模型”。

4.3 在项目中刻意训练两种工程思维

动手做项目时，要刻意练两件需要脑子的事：出错预判和数据敏感。

出错预判是指：每一次模型调用，你都要想“它如果返回了垃圾内容怎么办”。实际处理方式包括：格式校验不通过就重试、响应里抽不到关键信息就走兜底回答、上游服务超时就启用缓存。这些看起来很小，却是AI应用能在真实环境跑下去的支撑。

数据敏感是指：你要养成“打开日志看分布”的习惯。线上请求的成功率为什么下降？是超时变多还是内容报错变多？用户的输入长度分布有没有改变？模型输出的Token数是否和预期一致？AI工程里没有玄学，所有你感觉“不对劲”的问题，基本都可以通过数据定位到根因。

4.4 从个人项目走向真实业务的注意点

当你完成了个人项目，开始参与团队或真实业务时，有几个阶段性的建议：

千萬不要直接把个人项目的代码结构搬进生产环境。个人项目通常没有多少并发、没有鉴权、没有限流、没有可观测性，这些缺失在生产环境里是故障源头。你需要做的第一件事就是先补齐工程骨架：日志体系、配置中心、错误追踪。建议给模型调用统一封装一层客户端，这层客户端统一处理鉴权、重试、超时、Token统计、版本记录。这一步的精妙之处在于：后续换模型、换配置，你只需要改动封装层，而不用碰业务代码。

另外要养成“写设计文档”的习惯。哪怕是一个很小的模块，也写清楚：输入是什么、输出是什么、依赖什么模型、评测指标是什么、成本和延迟预算多少。这不仅是工程规范，也是AI工程协作的基础——因为AI系统的行为不确定性太高，文字沟通能让所有人对齐预期。

5. 我在实操里反复遇到的坑，以及给初学者的实用建议

5.1 三个高频踩坑案例

第一个坑是数据泄漏。我做RAG项目时，把知识库文档切成碎片存进向量库，但评估时发现效果异常好——后来查清楚了，因为测试集中的一些样例问题，和知识库里某些文档片段几乎是原文复述关系。这不是模型变聪明了，这是把“答案”提前喂给了检索器。解决办法是评估集的构建要独立于知识库，测试数据至少要经过人工改写，和知识库保持一定“距离”。

第二个坑是对“基准模型”没有概念。初学者往往上来就折腾复杂提示词、高级RAG策略，却从没跑过“零提示词直接问答”这个最简单的对照试验。其实类似场景，直接用模型内置知识就可能达到70%的正确率，简单RAG可能到80%，复杂RAG加上重排序可能到85%。每一个优化到底贡献了多少，你没有基准线根本说不出来。我建议所有优化工作开始之前，先跑三个基线：裸模型、裸模型加简单提示词、简单RAG。这条基准线你往后每次迭代改进都要对比着看。

第三个坑是成本失控。AI应用的成本不像传统服务器那样比较固定，它跟你的输入长度、输出长度、调用次数、模型单价都强相关。我的建议是直接做一个“成本观测看板”，每次发布前估算单请求成本，上线后看实际平均成本，每次改配置都要重新估算。不要等到月底账单出来再惊讶，那时候已经超支多少才是真正的重点。

5.2 给零基础者和非技术背景者的话

如果你是非技术背景想进入AI工程，有几条实操建议可以帮到你。

第一，从工具链使用者起步，不一定要从头手写所有实现。市面上有Dify、Flowise、LangFlow这类可视化AI应用编排工具，也有LangGraph、LlamaIndex这类框架，先用它们把“RAG问答”“工作流编排”跑通，形成体感。

第二，一定要学动手能力而不是只学概念。每个知识点的标准是：你能不能用代码把它做出来？概念背得再熟，遇到报错日志不会排查也没用。遇到错误，先把完整报错信息复制粘贴到大模型工具里问一遍，让它给你解释，同时让它推荐排查方向。

第三，进这个领域至少要有“死磕一个问题30小时”的心理准备。AI工程不是那种看两小时教程就能上手的技能，它的不确定性高，排查链路长。有一次我排查一个线上超时问题，前前后后折腾了快两个工作日，最后发现是某个第三方向量库的线程池配置太小。这类问题不会出现在任何教程中，只能靠你自己足够耐心、系统性地排查。

5.3 关于工具与教程的选择建议

选择工具时，我的原则只有一条：优先选生态最成熟的主流选项，先不要在没有社区验证的新框架上去“探索”。理由很简单，AI工程的技术栈更新速度太快，如果你用了够冷门且社区太小的工具，碰到问题连可参考的案例都找不到，这会大量消耗你的时间。

我给现阶段技术栈的推荐是：

• 语言：Python首选，因为AI生态和库的支持比较充分
• 模型：优先用主流模型API，兼顾能力与生态成熟度
• 向量库：主流开源或云服务均可，数据量小直接用轻量级方案
• 编排框架：从最简单的直接手写调用链开始，相信我，它能在早期避免许多框架黑盒问题
• 评估工具：先自己写脚本记录评测数据，再考虑使用开源的评测平台

这份选型可以支持一个人从零开始做到自己公司的业务落地，且每一步都有丰富的公开案例可以参考。

5.4 最后，把“from scratch”这件事的心态收个尾

我见过太多人在AI工程这个方向上，因为一开始就试图把所有东西都搞懂、都学会，结果反而一直没有真正上路。这个领域的边界是持续扩展的，今天的基础框架可能过几个月就进入了新的阶段。真正有效的心态，不是“全部学会再动手”，而是“建立核心框架，然后通过实战项目不断迭代自己的认知”。

从我的实践经验来看，一个从零开始的人，只要按照“基础能力 -> 端到端小项目 -> 评估与迭代 -> 真实业务”这条路径走，大约三到四个月就能具备独立搭建一个AI应用的能力。这个速度和天赋无关，只跟“频繁动手+系统复盘”直接相关。如果你正在起点犹豫，那不妨这周就把第一个Hello World级别的模型调用写出来，剩下的一切会水到渠成。