企业官网建设流程全解析

这两年我身边转AI工程方向的人越来越多，但一个很有意思的现象是：大部分人一开始根本不知道"AI工程"到底在学什么。去搜索榜单和教程，要么是教你训练一个模型，要么是在讲深度学习的数学原理，看完一头雾水，和真正要做的事离了十万八千里。

我自己的经历也差不多。一开始建了个叫ai-engineering-from-scratch的学习仓库，本意就是想把从零开始做AI应用需要掌握的东西整理成一条可执行的路径，结果越整理越发现，这个领域真正的难点不是"模型怎么训"，而是"系统怎么搭"。今天这篇就把我走过的路、踩过的坑、以及最终沉淀下来的方法论完整写出来，希望能给正在转方向或者准备做LLM应用的人一些参考。

1. 先搞清楚什么是AI工程：它与算法岗和普通开发的本质差异

1.1 为什么"AI工程"不是"人工智能"，也不是"编程"

很多人听到AI工程，第一反应是"那不是搞算法的吗"。实际上这是两个完全不同的工种。算法工程师的核心交付物是"模型"——一个在评测集上效果好、算力消耗可控的模型。而AI工程师的核心交付物是"系统"——一个把模型封装好、跑得稳、可维护、能应对真实用户请求的软件产品。

举个例子。你训练一个文本分类模型，准确率做到 97%，这在算法岗看来就是一件可以交差的事。但到了AI工程手里，问题才刚刚开始：这个模型怎么部署成在线服务？QPS 高了怎么扩容？模型返回的结果怎么校验？如果用户上传的内容模型根本没见过，是兜底还是拒掉？监控指标怎么设计？

这就是AI工程和传统算法的本质差异：算法解决的是"模型是否聪明"，工程解决的是"系统是否可靠"。

1.2 从零开始的"零"到底指什么

我在整理学习仓库时最纠结的一件事，就是这个"零"到底指零在哪里。后来我想明白了，它不是一个知识起点，而是一个能力状态。

零基础的人，先学的是Python基础、HTTP接口调用、JSON数据处理这些常规软件开发技能。这个阶段和做普通后端开发没什么两样。但真正的"零"指的是：对LLM应用的开发方式没有形成直觉，对模型能力和限制没有建立体感。

比如你第一次调GPT的API，你会惊讶地发现同一个Prompt连续调用两次结果完全不同。这和一个返回固定JSON的后端接口体验差别太大了。这种"不确定性"是AI工程所有复杂度的源头。如果你接受不了这个东西，后面每一步都会走得很别扭。

从零开始，意味着要先让自己适应"和不确定的系统共处"这个状态，然后才是具体技术栈的学习。

1.3 AI工程的三个能力圈

如果把我后来做的所有AI项目拆开来看，本质上都在处理三个圈的问题：模型能力、系统能力、评估能力。

模型能力指的是你理解和处理大模型本身的能力，包括怎么设计Prompt、怎么选择模型、怎么微调、怎么应对幻觉。系统能力指的是你把这个模型嵌入业务系统的能力，包括服务部署、数据管道、检索链路、并发处理。评估能力则最容易被人忽视——你怎么判断系统好不好？怎么建立回归测试？怎么量化"回答质量"？

三者的关系你可以这样理解：模型是发动机，系统是底盘，评估是仪表盘。过去做开发你只需要关注底盘，把逻辑写对就行。现在发动机的脾气你摸不准，仪表盘也经常显示"未知错误"，三个部分交织在一起，这就是AI工程比传统软件开发难的地方。

2. 从零到能接需求：我实际走的四段式路径

2.1 第一段：Prompt工程与API调用，建立手感

我刚开始学的时候贪多，什么LangChain、向量数据库、微调框架都装了，结果什么也没学会。后来我做了个减法——先用最原始的openaiPython包把对话跑通。

第一步就是实现一个命令行版聊天机器人，支持多轮对话。这个阶段的核心目标不是做产品，而是体会几个关键点：

• 温度参数对输出随机性的影响
• System Prompt和User Prompt在行为约束上的不同
• 同样的Prompt，换个模型，输出质量差多少
• 输入输出token数量对成本和延迟的影响

我用一个简单的脚本记录每次调用的参数、耗时和返回结果，连续测了大概一周。就是这一周的笨功夫，让我对模型的行为模式有了最直接的体感。后来我在仓库里给这个阶段定了个硬性标准：必须能手动追查每一条用户请求对应的Prompt、完整返回参数和实际消耗成本。这个能力到后面做任何项目都是地基。

2.2 第二段：RAG，第一次理解"知识"和"检索"

我的第一个真实项目是做一个内部知识库问答。当时最自然的想法是给模型灌文档，却发现模型不知道我们公司的内部流程。这个痛点直接把我带进了RAG（检索增强生成）这个领域。

RAG的逻辑说起来不复杂：把文档切块，向量化，存进向量数据库。用户提问时，先根据语义找到相关片段，拼进Prompt再交给模型。但真正做起来你会发现每一步都是坑。切块切多大？500字还是1500字？向量模型选哪个？TopK取多少个？拼接顺序怎么排？引用和答案怎么分开？

我记得我第一次搭好的RAG系统，跑了一个demo，看起来头头是道。但一追问细节就露馅了，它引用的段落和它给出的结论经常对不上。后来我才明白，症结在于"召回质量"——模型压根没检索到真正相关的内容，只是靠语言模型硬凑了一个看似合理的答案。

这个阶段我的收获就四个字：检索为王。RAG的上限由检索决定，生成只是锦上添花。

2.3 第三段：Agent与工作流，控制复杂度

RAG跑通之后，自然就会想做更复杂的应用。比如一个能查天气、能查日历、能处理邮件的小助手。这时候模型需要"调用工具"，这就是Agent的概念。

我在这个阶段犯过最大的错误，是过度依赖Agent框架。当时LangChain特别火，我跟着文档把Agent怼起来，代码写了一堆，遇到报错完全不知道怎么回事。最后我把框架卸了，用纯代码加一个很薄的抽象层手写Agent循环，代码量反而少了一大半，而且每个环节都在自己掌控之中。

Agent的核心循环其实很简单：拿到用户请求，决定要不要调用工具，调用工具拿到结果，再把结果和自己已有的知识综合起来回答用户。真正复杂的是决策逻辑、工具描述和错误处理。我后来的建议是：先用纯代码实现一遍基础Agent，再去碰框架。你只有知道框架在背后做了什么，才能驾驭它。

2.4 第四段：评估与回归，工程化的分水岭

我认为技术上的转机，是开始搞评估。之前做AI应用，改一个Prompt感觉变好了，但没法证明。后来我意识到，没有评估体系的AI项目就是耍流氓。

我建了一个评测集：大概100条代表性的问题，覆盖正常问题、边界问题、坏输入。用脚本批量跑，跑完再人工给分数。虽然自动化还不够，但已经有了回归测试的雏形。有了这个评测集，我再去改Prompt、换模型、调检索参数，就有底气了。改一版，跑一遍，看到评分上升才敢上生产。

这个阶段让我明白，AI工程和传统工程在方法论上是一致的：一切要可验证、可回归、可追踪。做好评估，整个项目的成熟度就上了一个台阶。

3. AI工程的核心技术栈拆解：每个环节选什么、为什么

3.1 模型接入层：API优先，本地部署按需

模型接入是目前争议最大的环节之一。纠结的点无非是：用云端API还是本地私有化部署？

我的经验是：90%的场景先用API，用API把业务逻辑和产品流程验证清楚，再决定是不是要换成本地部署。原因很简单，API的开发效率和产品迭代速度是私有化部署比不了的。

你需要关心的能力包括：模型上下文长度、返回是否支持流式、是否能输出结构化数据（比如JSON模式）、是否有函数调用能力、价格和速率限制。我给自己定了一个原则：所有模型调用统一封装成一层，就叫ModelProvider，无论底层换成哪个模型厂商，对外接口不变。这一层抽象在后期换模型、做A/B测试时能省下巨大的时间。

3.2 编排与存储：不是所有数据都适合塞进向量库

很多人一上来就上向量数据库，觉得"RAG=向量检索"，这个认知其实有偏差。

向量检索擅长的是语义匹配，比如"文档里说没说过类似的话"。但很多场景根本不需要语义，精确匹配就够了。比如查订单号、查员工工号，你拿个倒排索引或者直接查传统数据库就完了。我有一次做一个工单查询助手，第一版用向量检索，效果差还慢，后来切成SQL查询加关键词匹配，准确率直接拉满。

正确姿势是多种检索方式结合：结构化数据走数据库/SQL，非结构化数据走向量检索，两者都有时先精确定位再向量补充。存储选型别被"新技术"带偏，要看数据形态和查询模式。

3.3 Agent框架：LangChain、AutoGen、还是自研

Agent框架的选型，我的态度经历了从狂热到冷静的过程。早期我几乎什么Agent都用LangChain封装，后来Debug到怀疑人生。现在我的判断是：

• 如果你要快速验证一个多Agent协同的想法，可以试试AutoGen或者LangGraph
• 如果你的Agent流程相对固定，比如就三五个工具、几步调用，别上框架，直接纯代码写循环
• 如果流程复杂且要大量定制，自研比硬套框架更可控

原因在于，Agent框架本质上是个"流程引擎"，但Agent应用最复杂的部分往往是"决策逻辑"，而框架把决策逻辑藏在了抽象之下，出了问题你很难定位。读过一遍框架源码再决定要不要用，是性价比最高的路线。

3.4 可观测性与成本治理

AI应用比传统后端多了一个维度要盯：token消耗。普通的接口监控只会记录请求量和延迟，而AI应用还需要记录模型名、输入token数、输出token数、成本估算。

我后来把我的监控体系拆成三块：系统监控（CPU、内存、延迟）、业务监控（成功率、调用量、平均得分）、模型监控（token消耗、成本、输出格式异常率）。成本治理方面，做一层简单的缓存逻辑，重复的请求直接返回历史答案，能把开销降不少。最极端的case是，我们一个高频查询接口加了缓存之后，成本直接降了70%。

4. 从零搭一个可用的AI应用：一个客服知识库的完整过程

4.1 需求与架构设计

为了避免通篇讲理论，我用一个实际项目串一遍。项目背景：某产品团队需要一个内部客服助手，能回答关于产品使用、售后政策、常见故障的问题，同时要支持追问，并给出答案引用的原文段落。

架构我画得很简单（不用复杂框架）：

用户输入 -> 问题改写（判断是否缺少上下文，结合历史对话补充） -> 知识检索（向量检索 + 关键词检索混合） -> 重排序（给检索结果精排） -> 组装上下文 + Prompt -> LLM生成答案 -> 后处理（正则提取引用编号，校验引用是否存在） -> 返回用户

这里面每一步都有为什么。问题改写是为了让追问在脱离历史语境时还能被理解；混合检索是为了提高召回率，因为向量和关键词各有擅长；重排序是为了让进入Prompt的片段质量更高，这是RAG精度提升的关键一环。

4.2 数据清洗与分块

知识库的数据源是产品文档、客服对话记录、历史工单，格式乱七八糟。我花了两天清洗，只做三件事：去噪（去掉页眉页脚、广告、无关评论）、标准化（统一产品名词，比如"登录问题"和"账号登录不了"归一化）、结构优化（把原本的大表格拆成一条条的FAQ）。

分块策略上，我测试了三种切法：按固定字数切、按段落切、按语义切。最后效果最好的是"按标题层级加段落约束"的方式——把文档的章节作为前缀信息保留，正文超过一定长度再切成子块，确保每个子块自带上下文标题。后来验证，这种方式能让检索命中率高出一截，因为模型理解"这个片段在哪个章节下"比理解"这个片段说了什么"更容易。

4.3 检索链路与提示词迭代

检索链路我一开始只用了向量召回TopK=10，直接塞进Prompt。效果是经常答非所问。后来我加了重排序：先用向量检索召回50个候选，再用重排序模型精排取前5。这个改动让"答案相关度"的评分提升非常明显，代价是多花了几十毫秒，对问答场景完全可以接受。

Prompt的设计也经历了三个版本。V1只是简单说"你是客服助手，请根据知识库回答"。V2加了角色约束和回答风格要求。V3终于想通了——Prompt的核心不是告诉模型"你是什么"，而是告诉模型"你应该遵守哪些回答策略"。比如：

当用户询问的内容能在提供的资料中找到答案时，优先引用资料原文作答，并在回答末尾标注引用编号。如果资料无法覆盖用户问题，直接说明"未找到相关信息"，禁止编造。

这两句话让回答的幻觉率明显下降。Prompt迭代的核心不是堆花哨的提示，而是定义清晰的边界和兜底策略。

4.4 上线后的效果评测与阈值调优

系统上线前，我建了一个60条问题的评测集，覆盖三类：标准问题（知识库有的）、边界问题（知识库没有但类似的）、兜底问题（完全无关的）。上线后每周跑一遍，记录三类问题的得分变化。

评测结果反过来逼出了很多调优决策。举个例子，标准问题的准确率已经到92%了，但兜底问题的差评率很高，因为模型经常在没找到资料时硬答。我把"未找到相关信息"的阈值逻辑做了调整：当重排序得分低于某个阈值时，强制走兜底回答，不允许模型自由发挥。这一个改动让兜底问题的满意度从50%拉到了85%。

这件事给我的启发是：AI应用的体验不是靠"模型更强"撑起来的，而是靠"何时该答、何时不该答"的判断撑起来的。

5. 上线后才会遇到的真实问题清单

5.1 模型本身的输出不稳定

我有一个很深刻的经历：早上部署完测试一切正常，下午同样的请求返回的内容却变了，引用格式还错乱。排查了很久才发现，是模型厂商那边默默更新了版本，行为发生了变化。

应对方式就两件事：一是接模型的时候固定版本号，不追最新，除非验证过；二是对模型的输出做强校验。比如要求模型返回JSON，就加一层解析校验，解析失败就自动重试一次，重试还失败就走兜底。永远不要假设模型会自己说到做到，输出侧的防御必须做足。

5.2 延迟、并发、成本之间的平衡

真实用户的耐心是很有限的，3秒以上就会流失。我遇到的典型场景是：RAG链路里模型本身耗时1.5秒，加上检索、重排序、后处理，整体到了2.8秒，还在可接受范围。但一旦并发上来，服务器扛不住，延迟直接翻倍。

我给出的建议是：

• 能缓存的结果尽量缓存，特别是高频问题
• 流式输出能显著改善用户的"感知延迟"——用户的第一个字先出来，后面逐步补齐
• 模型并发做排队管理，避免瞬时请求打爆服务
• 用性价比更低的模型处理简单问题，把贵模型省给复杂问题

这些在传统开发里不算新东西，但在AI应用里容易被忽视，因为大家的注意力都被"模型有多聪明"吸走了。

5.3 数据回流与质量闭环

真正让AI应用越用越好的关键，是建立数据闭环。用户对回答点了"不满意"，这条记录去哪儿了？我后来的做法很朴素但有效：每一条不满意反馈都进入人工复核队列，定期拉出来分析，判断是"检索没召回""模型理解错"还是"知识库就没有"。这些归因结果直接驱动下一步动作。

坚持了一个季度后，我们的知识库新增了80多条由反馈驱动的内容，准确率又上了一个台阶。AI应用不是一锤子买卖，而是持续迭代的内容产品。没有数据回流机制，你永远在盲目优化。

5.4 什么时候该反向决策：少用AI

这个可能听起来比较反直觉，但做AI工程最重要的能力之一，是判断什么场景不该用AI。我有一个血的教训：把一个工单的"分配合法性校验"逻辑交给LLM做，结果模型偶尔脑子抽风，把正常的工单判成异常，差点让客户投诉。

后来我把所有"非黑即白"的判断全部换成规则引擎，只有真正需要理解和生成的地方才保留LLM。比如"这个工单描述属于什么类别"用LLM没问题，"这个工单符不符合条件"必须用规则。用LLM的成本和不确定性都比规则高，能简单就简单，这是AI工程里一条反直觉但很重要的原则。

写在最后

从零开始学AI工程，技术栈本身并不神秘，核心是熟悉API、RAG、Agent、评估这条主线。真正让人崩溃的是在一个没有评估、没有防线的状态下盲目堆功能，最后被各种不确定性折磨得焦头烂额。

我个人的经验就是：把复杂留给自己，把稳定留给用户。先把基础链路跑通，再逐步加复杂模块；先人工逐个看案例，再建立自动化回归；先解决"答错不答"的问题，再追求"答得好"。这条路不短，但走完一遍，再去看任何AI项目的需求，心里就有底了。

如果你也在走这条路，欢迎照着我踩过的脚印走一遍流程。