企业官网建设流程全解析

1. 什么是AI工程：AI工程师到底在做什么？

“AI工程”（ai-engineering）最近是我们圈子里最火的搜索词，朋友圈里到处是“转行AI”“三个月成为AI工程师”的帖子。如果你在正规的软件工程岗位干过几年，再去看那些帖子，会有点想笑——宣传稿里全是提示词模板、API调用的截图，把这件事说得跟写拼音输入法似的。但真正的AI工程是另一回事：它一半是传统的软件开发，一半是处理一个暴躁又偷懒的同事，哦不，模型本身。它没有作业本上的标准答案，只有不停爆发的意外。

我做了几年后端，转AI工程前，一直有个错觉：学会调用GPT的API就完事了。后来才发现，API调用只是最基础的一步，就像后端工程师会写数据库增删改查一样，根本不值钱。真正的AI工程要解决的问题，是怎么把一个大模型（或好几个大模型）高效、稳定、低延迟、低成本地嵌进一套生产系统里，让它在真实业务的流量下表现稳定，不瞎编，不卡死，不出事故。

这篇博文就是干这个的——我把过去踩过的坑、最终跑通的方案，以及我眼中“从零开始做AI工程”最该关注的三个维度（性能、成本、可靠性），一次性都写了。有方案选型，有完整的RAG架构细节，也有真实调试翻车记录。如果你准备往这个方向转，或者已经在做，但总觉得哪里不对劲，这篇文章会给你一套比较扎实的地图。

2. 认清AI工程和传统软件工程的本质差异

2.1 同样的“Hello World”，完全不同的生命周期

传统软件工程里，我写了三行代码，跑起来，输出是“Hello World”，它永远是“Hello World”，我能用单元测试把它锁死一百年。但AI工程完全不同——我做了一个客服机器人，系统跑起来，可能今天说“您好，欢迎光临”，明天说“请问有什么可以帮您”，后天对着用户是“您好”还是“您好，您是？”都是随机的。API的输入有随机性，模型版本更新有不可预测性，用户输入更是千奇百怪，这带来最本质的变化：测试必须从“断言输出”改成“断言行为边界”。

举个例子，传统后端写接口/user/info，我传入user_id=1，断言返回name=张三。这没毛病。但AI工程写一个prompt，用户输入“你们怎么退货”，这个输入可以变形为“退钱”“想退款”“你帮我退货”“怎么发起售后”，所有变体都要能落到同一个业务逻辑上。没有哪个断言能把所有排列组合写完，你能做的，是把所有相似的意图聚合，然后给输出定义一个“安全区间”——比如必须包含“退货政策”关键词、必须在30秒内响应、不能出现敏感词。

2.2 从“确定性”到“概率性”：思维上的根本转变

刚转行时，我犯过最幼稚的错误：用传统开发的逻辑去追一个“必现Bug”。有用户反馈，“我家地址是XX，你们快递怎么送错了”，回答却驴唇不对马嘴。我给模型提供商开了工单，把同一个请求重发了一百遍，结果五十遍正确、五十遍出错。那一刻我才意识到，这不是“Bug”，这是模型的概率性质——同样的输入，它就是有可能中招。

后来我理解了，AI工程的价值不在于消灭概率，而在于用工程手段把概率压到业务可接受的范围。这里有两个方向：一是提高单次调用的正确概率（换更强的模型、更好的提示词、加RAG检索），二是布置兜底逻辑（当模型输出明显异常，再用规则去纠正或触发人工）。这一个“概率思维＋工程兜底”的结合，才是AI工程师真正的核心竞争力。

3. “调用API”之外的真正核心：我的技术选型实战

“AI工程”这个概念火起来后，大量人把“调用OpenAI API”包装成AI工程。我毫不客气地说，这是在侮辱工程两个字。真实生产环境里，选型才是决定生死的第一步。

3.1 LangChain、LlamaIndex，还是自己拼？我的选择

几乎每个入坑的人都会遇到那几大框架：LangChain、LlamaIndex、AutoGen。我前期也跟风用了LangChain，真到生产环境才发现一个大坑——版本漂移极其严重，而且抽象层太厚。底层模型换一个版本，上层代码可能就要重构。那阵子开源社区流行一句话：“LangChain是给你给没想清楚的人用的，想清楚了的人都自己去写了”，话有点极端，但也不无道理。

我现在自己的实践，是写一个很薄的自维护 wrapper，模块化设计：调用LLM的逻辑、解析响应的逻辑、重试逻辑、缓存逻辑分开封装，总共不超过200行代码。核心代码自己掌握，出了问题一眼能定位，改起来也不会牵连其他模块。框架类工具并不是一无是处，它们适合快速验证原型，但投入生产环境前，你要问自己：这个抽象层，我Hold得住吗？

3.2 模型选型：为什么我用多地打字卡在“延迟 vs 效果”的天平上？

再来说模型选型。一上来就用最强模型？那是烧钱的做法。我服务过一个小型企业客服，业务量高峰期每秒并发30+请求，如果用最强的模型，单次响应耗时轻松3-5秒，用户忍无可忍；换成中等模型，虽然逻辑推理没有那么复杂，但配合良好的提示词和检索增强，响应能压到1.2秒以内。在AI工程里，延迟比效果更影响业务体验，这一点很多人会踩坑。

我整理了一个模型选型的经验对照表，你可以参考：

实际上，没有“哪个模型更好”，只有“哪个模型在最合适的延迟和成本下，能满足你的业务”。做AI工程，必须对模型的边界（上下文长度、token费用、并发上限、响应格式稳定性）倒背如流，否则写着写着就会被眼前的“聪明”反噬。

4. 从零搭建一条生产级RAG流程：踩坑实录与完整剖析

4.1 数据清洗，才是RAG的隐形护城河

如今“RAG（检索增强生成）”几乎成了企业“AI落地”的同义词。但市面上99%的教程，都是从“怎么切分PDF”开始。确实，越基础的教程越不强调前期的数据清洗——这是所有翻车事故的开始。

我处理过一个客户案例，他们有一堆客服历史工单，想做智能问答机器人。直接把几百个PDF丢进去，压根没法用。原因很简单：

• 文档里有大量扫描件的OCR乱码；
• 表格、图表截断后上下文断裂；
• 多级标题嵌套，切出来一个“孤立文本块”，根本不知道在说什么问题。

我的清洗流程分五步走：

1. 文件格式识别，区分PDF、Word、Excel、扫描件；
2. 文本抽取，针对扫描件调用OCR引擎（我常用PaddleOCR，中文效果不错）；
3. 段落重组，按“标题层级”合并相关联的连续段落，而不是机械按字数切；
4. 去噪，去掉页眉页脚、导航文字、签名档等无关语料；
5. 过滤脏数据，利用正则和简单分类器，识别“无意义文本块”并剔除。

光是清洗这一步，就占了整个RAG项目的一半工作量。没有好的数据，后面调提示词都是白搭。

4.2 切分策略的“度”在哪里？从文本块大小到检索效果的实验记录

清洗完数据，挑战第二步：文本切分。这是我最想吐槽的部分，因为网上90%的教程都是直接固定设置为256或512个token，完全不动脑子。可事实上，切分太小，上下文割裂严重，模型可能只能看到“快递到了”，不知道说的是什么快递；切分太大，模型上下文窗口被噪音占满，检索质量反而下降。

我自己做了一个实验表，用来确定最佳切分大小，你可以直接当参考：

这个方法的核心思路，是“语义级切分”而非“字符级切分”。实在来不及分析文档结构时，也可以按照Markdown标题、换行等自然定界符来做，这比固定token合理得多。

4.3 检索翻车：为什么明明入库了，却查不到？

洗了数据，切了块，做好了向量化，你以为就完事了？天真。实际运行后我收到最多的问题就是：“资料明明在知识库里，检索就是查不到，答案也牛头不对马嘴。”

用向量检索，最大痛点是query与文档的关键词重叠太少。比如用户问“怎么申请退款”，而文档里写的是“退款政策详见第六条”，向量模型可能识别不出深层关联（取决于模型的语义能力），于是老老实实捡了一堆噪音返回。

怎么解决？我的组合拳是混合检索＋重排。

1. 混合检索：同时跑“向量检索＋BM25关键词检索”，两者结果各自取TopN（比如各取50条）再合并；
2. 重排（Rerank）：合并后，用重排序模型（如Cohere Rerank 或 BGE-Reranker）按相关性重新打分，只把Top 5喂给模型。

这是一套性价比很高的方案。直接暴力堆上下文窗口？在文档多、并发高的时候，响应延迟和成本会一起失控。重排实际上就是“精挑细选”，让我花在模型上的每分钱都物有所值。

4.4 防幻觉的最后一公里：缓存与兜底

即使做到了上面所有步骤，模型还是可能一本正经胡说八道。我把这称为“最后两成事故”，它靠RAG本身解决不了，必须靠工程兜底。

我的兜底策略分三层：

1. 置信度闸门：让模型在输出核心回答时，同时输出一个“依据引用”（取自哪份文档的哪一段）；如果引用缺失或自相矛盾，就降级为预设话术，比如“抱歉，我没找到相关信息，请转人工”。
2. 规则引擎复核：核心字段（如金额、日期、订单号）用正则二次校验，防止模型改数字；
3. 人工B计划：被闸门拦截的失败请求，自动生成工作流派给人工客服处理。

听起来不浪漫，但这就是工程。AI工程不是追求“机器永远全对”，而是建一个“事故预防系统”，让机器犯错时不至于让用户崩溃。

5. 我踩过的生产事故：一次让你少走三年弯路的复盘

5.1 事故一：莫名其妙的高延迟，根因惊出我一身冷汗

上线第一周，用户投诉“响应太慢”，后台监测发现有个接口P95延迟从800ms飙升到7秒。翻遍日志，发现原因是——模型提供方会对超大Prompt做“排队”，我没有做超时控制和功能降级，一个用户请求卡住了，后面所有请求全在等同一个连接。那次事故教给我三件事：任何上游不可控，都必须加熔断器；每一个外部API调用都必须设置超时上限；连接池要监控，不能盲目复用。

5.2 事故二：Token刷爆预算，一夜花了上万

这是最记忆犹新的一次。原因是代码里一个疏忽：拼接上下文的时候给了列表去重，但没限制最大token数。一个长对话用户的上下文越滚越大，直接推送了2万token给模型，相当于把一天的调用量集中到几次请求上，账单瞬间炸裂。现在我的代码里永远有两把锁：

• 调用前强制计算input_token + output_token，超阈值直接截断；
• 用消息摘要，把历史最老的对话做摘要压缩，而不是无限堆原始记录。

5.3 事故三：幻觉诞生了“无法退货”的噩梦

又一次客服机器人事故，模型对着用户说“您的商品超过退货期限，无法退货”，但业务规则明明是可以退的。为什么？因为模型从某一份“过期的旧版退货政策”里检索到了错误信息喂给了用户。

这就是RAG的老大难：知识更新了，但向量库里旧数据没有剔除，检索时旧的还是能排前面。后来我加了一套“时效性权重”，对文档元数据打了业务生效时间，检索后重排时，把过期文档降权。同时，每天跑一次定时任务，对“已生效/已废弃”的文档做索引管理。别小看这个，在真实业务里，这比任何高级Prompt都更有效。

6. “从零开始”的正确路径：我给初学者的避坑建议

6.1 别从“框架”学起，而是从“原理”学起

看到这里，你肯定发现，我全文都在强调底层逻辑。对于刚入门的人，我的建议永远是分四步走：

1. 先学会直接调用API。把OpenAI或国产模型（如通义千问、文心）的官方接口文档翻一遍，调用一下，理解token、temperature等参数的实际影响。
2. 自己手工写一个RAG流程。只用Python脚本和几十行代码，把数据清洗、切分、向量化、检索串起来。逼自己掉进坑里，比看任何教程都管用。
3. 再学评估。搭一套自己的评估集（50-100条业务问答），每改一次提示词或切分策略，就去跑一遍评估集，看准确率涨了还是跌了。只要没有这一步，你连调优都不知道往哪个方向调。
4. 最后再看框架。有了前两步的手感和对核心逻辑的理解，再去看LangChain源码，你会有一种恍然大悟的感觉，也知道哪些模块有价值、哪些模块是冗余封装。

6.2 保持理性：击退“追新恐惧症”

AI领域几乎是按“周”在刷新的。今天“Prompt Engineering”，明天“Function Calling”，后天“Agent”。我最想对新手说的一句话是：不要被新概念卷走，把80%的时间花在基础工程能力上。

所谓基础工程能力，就是数据清洗、接口调用、并发处理、链路监控、成本统计、缓存这些老掉牙的东西。真正复杂的AI产品，往往不是靠一个酷炫的Agent框架，而是把基础的“检索、调用、复核、降级”围绕业务场景拼得滴水不漏。新框架再猛，也只是给你拼图提供了一条捷径，拼图逻辑还是得靠你自己想通。

6.3 如何持续验证你的“AI工程”水平

最后分享一个我的个人习惯：每个月都构造一个小型但全新的业务场景，给自己24小时，从数据到上线做一个MVP。比如这个月做“会议纪要生成器”，下个月做“Excel数据分析助手”，再下个月做“电商评论情感分析”。场景越细，越能暴露你的盲区。什么框架都行，自己顺手就好。每做一次，你会明显感觉到对“AI工程”的理解又深了一层——就像从泥潭里爬出来，回头一看，原来沼泽长什么样，你已经看得清清楚楚。这就是从零开始最大的收获。