企业官网建设流程全解析

最近“AI engineering”这个词，几乎到处都能看到。很多人以为它就是把几个大模型API串起来，跑个聊天机器人就算入门了。我自己从纯后端转过来，踩了不少坑之后才意识到：AI工程的核心不是“用哪个模型”，而是“怎么把一个模型能力打磨成稳定、可维护、能持续迭代的真实系统”。

这篇内容我想聊聊真正“from scratch”的路径。不是抄一段代码就算会，而是从知识地基、第一个项目、模型选型，一直到生产环境里那些没人提醒你的坑，完整走一遍。如果你是后端工程师、学生，或者刚接触AI想系统入门的开发者，这篇文章应该能帮你省下我当初浪费的那几个月。

1. AI工程不是“调API”，是“交付系统”：先建立全局视角

1.1 我理解的AI工程是什么

先给一个我自己的定义：AI工程，是研究如何用现有模型和工具，在真实业务场景里持续交付、运行、迭代AI能力的一整套方法。它不完全等于机器学习，也不等于软件工程，而是两者的交集，还额外带上了一层“模型行为不可完全预测”的特殊性。

传统的后端开发里，函数输入和输出基本可控，你写一个接口，传参进去，返回结果是可以预期的。AI工程不一样，你调用的模型本身是一个概率系统，同样的输入可能每次输出都不同，同一个Prompt不同措辞结果可能天差地别。这就决定了它不能用传统的“写完就完事”的思路来交付。

我做过一张对比表，自己常用它来理解AI工程和几个相邻领域的差异：

说白一点：研究模型的人，目标是让模型在排行榜上更高；做AI工程的人，目标是让模型在公司业务里好用、便宜、稳定、出了问题能快速定位。这两个目标经常是冲突的，比如榜单上最强的模型，不见得在你业务里成本可控。

1.2 从零到一要看懂的四层系统结构

我第一次搭AI应用的时候，脑子里只有“调用模型”这一个动作，结果项目一上线就各种问题：数据格式不对、回答乱编、一次请求几十块钱、用户反馈无法追溯。后来我把AI系统拆成四层看，整个思路就清晰了。

第一层是模型层，包括基座模型的选择和调用方式，是你能力的上限。第二层是数据层，包括业务数据怎么采集、清洗、切分、存储、检索，这层决定了模型能拿到什么信息。第三层是应用层，包括Prompt设计、业务逻辑编排、用户交互、权限和校验。第四层是评测运维层，包括离线评估、线上监控、日志分析、成本追踪、模型版本更新。

这四层不是从上往下做完就结束，而是一个循环：先是数据准备，然后选模型做应用，上线之后用评测运维得到反馈，反馈再改变数据和应用设计。

1.3 适合谁、需要什么前置基础

以我自己的带人经验来看，AI工程的门槛没有想象中那么高，但也没有低到“零基础也能当工程师”的程度。最适合开始的人是：有基本编程能力、有服务端开发常识、愿意动手折腾的开发者。Python要会用，命令行要能操作，数据库和接口的基本概念要有。

如果完全没有编程基础，也不是不能学，但建议先花2-3个月把Python基础、数据结构、面向对象这些补上。我见过最理想的状态，是懂一点后端（哪怕是写过学校项目、做过毕设），然后带着具体业务问题来学AI工程。带着一个要解决的实际问题去学，比照着教程敲代码效果好十倍。

2. 地基速成指南：用“够用就好”原则补足知识缺口

2.1 编程和数学：不需要成为算法高手

做AI工程到底要学多深的数学？我的答案是：够用就好，别被吓跑。你不是在推导Transformer的数学证明，你是在用现成的模型解决实际问题。

编程方面，Python是比较重要的，但也不是要你成为语言专家。需要熟练的是：类与对象、装饰器、列表推导、异常处理、虚拟环境、requests库调用接口、用JSON处理数据。这些每天都会用到。再加一个可选加分项：async/await，因为AI接口调用比较慢，异步并发在真实系统里几乎必用。

数学方面，优先级从高到低：

• 概率和统计基础：知道什么是采样分布、置信区间、标准差，因为你要理解“模型输出有随机性”这件事，要理解评估指标为什么要对多个样本取均值。
• 线性代数基础：知道向量是什么、点积是什么、矩阵乘是什么，因为向量检索和Embedding的概念都是从这来的。不需要会手算矩阵逆，但最好能理解“向量相似度”这个几何直觉。
• 微积分绕过：除非你要做模型训练或者读论文，否则日常AI工程里基本用不到梯度更新的手算推导。

2.2 大模型最小原理：用“图书馆管理员”类比来理解

一个没有大模型背景的人做AI工程，总想先把Transformer论文读透，这是很大的误区。当年我也差点陷进去。读了三天论文，只会画注意力机制的图，但对自己要做的项目毫无帮助。

真正需要在工程层理解的，是这几个概念：

Token：模型读写的基本单位。中文里一个token不严格等于一个字，但对于预算和长度管理，你要大致了解“多少token大约对应多少字”。实际经验：1个中文汉字大约1.5-2个token，1个英文单词大约1-1.3个token。这个估算能力在做成本控制的时候非常关键。

Context Window（上下文窗口）：模型一次输入能同时容纳的token上限。这不是“给它更多文字它答得更好”，而是“超出的内容它根本看不见”。工程上，你要负责控制送入上下文的量。

Embedding（向量嵌入）：把文字变成一串数字向量，语义相近的内容向量距离更近。这套机制很像图书馆管理员的分类系统：每本书被分到书架上的位置，都依据书籍内容主题的相似程度。把书按内容语义摆放好后，读者说“我想找讲编程入门的书”，管理员就在附近架子上来回比较，挑出最匹配的一批书推荐给读者。

大模型本身也类似一个“很会说话的管理员”：你有检索到的一堆参考段落加上用户问题，模型负责组织成流畅且信息正确的回答。这里的关键点很反直觉——模型能记住的内容，是被Context Window限制的，不是“训练私藏”出来的。很多人误以为上传一次资料它就永久记住了，实际不是。你不把资料放在请求里，它就“忘记”了。

2.3 必须懂的工程基础设施：一次性把坑补齐

AI工程里，模型只是系统一部分，你是靠下面这些工程设施来交付的：

1. Linux基础：能登录服务器、装环境、看日志、用crontab做定时任务。
2. 容器化（Docker）：把应用和依赖打包起来，尤其在做本地模型部署的时候非常关键。
3. 数据库和缓存：至少知道关系型数据库怎么存数据、Redis怎么当缓存和队列用。向量数据库虽然是新东西，但它的底层思想和传统数据库索引是一脉相承的，先把传统那块补明白。
4. API设计：基础的RESTful接口设计、鉴权、限流、超时。一个AI应用本质还是把你封装的模型能力，通过HTTP暴露给前端。
5. 云服务基础：对象存储（S3协议）、函数计算/Serverless、GPU服务器租用。这些是部署的兜底选项。

我不建议一开始就背概念，更好的方式是边做边补：每遇到一个不认识的工程名词，花半小时查一下，亲手在云服务上开通一次服务。用一次比读十篇文章都记得牢。

2.4 我推荐的学习顺序与时间盒

分享一下我后来教新人的顺序，大概4到6周可以完成基础段：

• 第1周：Python补齐 + Linux命令 + Git。每天花两三小时，做一个小爬虫或者数据处理脚本巩固。
• 第2周：用提示词调用一个大模型API，写一个命令行版聊天脚本。顺便搞懂REST API调用、Key配置、环境变量、Token计数。
• 第3周：学习Embedding和向量检索，本地装一个轻量向量数据库，手动实现一个“给一批文档建索引，然后按问题搜相关段落”的脚本。
• 第4周：把第2周和第3周的东西串起来，用无框架的方式实现一个最简RAG系统。这个很关键，后面细说。
• 第5-6周：学习部署和评估：把系统扔到云服务器上，跑自动评测集合，记录延迟和成本。

这个顺序的核心是：先有一行能运行的代码，再往上叠工程能力。不要先学三个月的理论再动手。

3. 从零搭建一个能用的文档问答系统：完整实战

3.1 为什么我推荐“文档问答”作为第一个项目

市面上有很多AI项目的练手Demo，聊天机器人、摘要工具、代码助手，我为什么强推文档问答？

因为它的链路非常完整，覆盖了AI工程的所有核心环节：数据解析、切块、嵌入、检索、生成、评估、迭代。而且它具备业务价值——公司内部文档多，员工找资料难；客服知识库散落各处；学生看资料抓不住重点。你把它做好了，是能真正用的。它还有天然的评估方法：你可以准备一些“问题-答案”对来打分，不像纯聊天那样很难评价回答好坏。

我自己带的实习生，给他三个项目选，最后选了文档问答，六周后他搭出的系统直接被他学校同学用起来了。这就是它的优势：链路完整、需求真实、反馈直接。

3.2 系统拆解与总体流程

一个最小可用的文档问答系统，按数据流向拆成五个环节：

1. 文档加载：读PDF、Markdown、TXT、Word等，提取纯文本。
2. 文本切块：把长文档按照一定长度切成分块，并保留元数据（来源、页码）。这一步直接决定检索质量。
3. 向量化存储：每个分块调用Embedding接口生成向量，写入向量库。
4. 检索：用户提问时，把问题转成向量，在库里找最相似的K个分块。
5. 生成回答：把“问题 + 检索到的分块 + 系统提示词”拼给大模型，生成最终答案。

3.3 可运行的代码骨架（无框架优先）

我建议你第一个版本不要用LangChain、LlamaIndex这类框架，直接用最原始的代码把流程跑通。用框架的问题在于，调试时你分不清是框架的封装问题还是你自己的理解问题。原生代码50行就能实现，逻辑一目了然。

这里我写一个极简版流程（用伪代码和Python片段混写，方便你理解整体结构）：

import openai from openai import OpenAI client = OpenAI() # 1. 读取文档 with open("company_handbook.md", "r", encoding="utf-8") as f: text = f.read() # 2. 简单切块：按固定长度（约500个字符） def split_text(text, chunk_size=500, overlap=50): chunks = [] for i in range(0, len(text), chunk_size - overlap): chunks.append(text[i : i + chunk_size]) return chunks chunks = split_text(text) # 3. 批量生成向量 def embed_texts(texts): resp = client.embeddings.create( model="text-embedding-3-small", input=texts, ) return [item.embedding for item in resp.data] vectors = embed_texts(chunks) # 此处省略：把chunks和vectors写入向量库 # 4. 检索：计算余弦相似度 import numpy as np def search(query, k=4): q_vector = embed_texts([query])[0] scores = [] for v in vectors: # 归一化之后点积就是余弦相似度 score = np.dot(q_vector, v) / ( np.linalg.norm(q_vector) * np.linalg.norm(v) ) scores.append(score) top_indices = np.argsort(scores)[-k:][::-1] return [chunks[i] for i in top_indices] # 5. 生成回答 def answer_question(question): related = search(question) context = "\n---\n".join(related) prompt = f"""你是公司内部助理。只能依据下面的资料回答，不要编造。 资料： {context} 问题：{question} 回答：""" resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], ) return resp.choices[0].message.content

这就是一个能跑起来的骨架，几百行以内搞定。跑通它，你对“数据链路”这件事的理解会直接超过那些只会调用ChatGPT网页的人。

3.4 最小评估闭环：别凭感觉判断好坏

很多人的第一个RAG项目死在同一个地方：没有评估系统，全靠自己问几个问题感觉“还行”。上线后换个场景立刻翻车。

最小可行的评估方案是：

• 准备30-50条真实问答对。从文档里提取，也可以找真实同事帮你提问，尽可能贴近实际使用。
• 对每个问题跑系统，记录三件事：检索到的内容是否正确、最终回答是否正确、是否引用了原文。
• 用三个指标打分：检索命中率（正确答案是否出现在召回的top4里）、回答正确率（人工判断回答是否准确）、幻觉率（回答是否含有资料中没有的内容）。

有了这三项，你改Prompt、切块策略、Embedding模型时，才有依据。否则每一次改动都是玄学。我会在后面章节详细展开评估闭环的搭建方法。

3.5 跑通后立刻要做的三件实事

第一个版本跑通后，你大概率会觉得“就这？”——对，因为它还不算一个产品。要让它向真实应用靠拢，马上做三件事：

第一，把元数据加进检索结果展示。每块资料带上来源文件名和页码，回答里出现“根据《入职手册》第3页”才有说服力，用户才会信任你的系统。

第二，做好用户输入的边界。禁止用户输入超长内容，限制单用户频率，把敏感词过滤加上。AI应用是公开服务，不做边界保护，上线当天就有风险。

第三，加上请求日志和回答追踪。存下每个问题的检索链路、模型输出、耗时和费用预估。这里没有它，后面所有优化和问题排查都寸步难行。

4. 模型选型和提示词工程：从“有输出”到“答得对”

4.1 基座模型怎么选：闭源API还是开源本地

很多人上来就问“哪个最好”，其实“最好”没有意义，“在限制条件下最合适”才有意义。我的分类判断标准有这么几项：

我的经验：项目第一版，优先用效果好的闭源API，先验证业务逻辑和用户体验。如果用户反馈好但成本高，再考虑用开源模型替换推理层。工程上这叫“用钱买时间”——第一版最怕的不是贵，是跑不起来。

4.2 提示词工程的三个层次

提示词工程不是靠“魔法咒语”，它有规律。我把它分成三个层次：

第一层：任务指令+角色约束。告诉模型你是谁、要干什么、输出什么格式。这是最低要求。

第二层：加入检索上下文和示例（Few-shot）。给模型一到三个示例，它能立刻学会你要的格式和深度。工程里最常用的稳定技巧是：给一个“好答案”示例，再给一个“错误答案”示例，让模型模仿前者、避开后者。

第三层：结构化输出和工具调用。让模型输出JSON字符串，或者使用函数调用（Function Calling）来严格约束它的动作边界。

下面是一个结构化输出实例：

系统：你是文档问答助手。只允许输出JSON： {"answer": "回答内容", "source": ["来源文件"], "confidence": 0到1} 用户：根据现有资料，我们公司的年假政策是什么？ 回答：

模型返回的是一个可被程序解析的JSON，你就能把“回答”“来源”“自信度”直接写进数据库做展示和监控，而不是在一个长段落里做字符串截取。实际工程里，强烈推荐所有模型调用都输出结构化数据，哪怕你用了强力的提示词，也在程序里做好解析兜底。

4.3 微调的正确位置：先调提示词和RAG，再谈微调

这里要敲一个重点：90%的应用场景，不该一上来就微调模型。微调是最后的手段，不是起步手段。

微调解决的是“模型通用能力足够，但不熟悉特定领域术语和输出风格”的问题。而大多数系统里的回答不准确，根源根本不是模型不懂，而是检索到的上下文不对，或Prompt没把约束说清楚。你先对照评估闭环看错误类型：如果是检索质量导致的错误，去调数据切块、重排，而不是微调；如果是格式不符，改提示词；如果所有环节都做了仍然不对，这时候再认真评估微调的投入产出比。

微调本身也不是万灵丹，它需要高质量标注数据、训练算力、更复杂的迭代管理。我见过一个团队，花了两周微调一个开源模型，效果比Prompt优化只提升了百分之几，还引入了新问题。所以我的建议是：越往上层找问题越节省成本，调数据的成本，远低于调模型的成本。

5. 从Demo到生产级：性能、成本、稳定性和可观测性

5.1 性能与成本：缓存、并发、流式，一个都不能少

一个AI应用的性能瓶颈，通常不在服务器并发，而在模型推理的耗时。一次大模型调用动辄几秒甚至几十秒，所以优化方向非常明确。

先加语义缓存。把用户的问句转成Embedding，和过去的问句做相似度匹配，如果命中高相似度的问题，直接把上次的答案返回，不再调用模型。这一步通常能省30%-50%的调用量。实际实现时可以设置一个相似度阈值，比如0.95以上命中缓存。

再加流式输出。把模型吐字过程像打字机一样实时发给前端，用户的首字延迟从3秒降到200毫秒，体感提升巨大。后端用SSE（Server-Sent Events）协议，前端用EventSource，实现成本很低。

最后是并发控制。用Redis或MQ做令牌桶限流，防止单个用户发动大量请求打爆账号配额。工程上有句话叫“没有限流的AI应用，就像没有刹车的车”。

成本估算给个实例：假设你的应用每天处理5000个请求，每请求平均送进模型2000 token，输出500 token。用某商用API的粗略费率，2000输入token约人民币几分钱，整体算下来一天几十元。如果要降到一天十元，就得靠缓存、更短的工具链、或者换更便宜的模型分级。

5.2 稳定性和兜底策略：假设模型一定会出错

生产级系统有一个基本假设：外部模型随时可能超时、拒绝服务、乱回答。所有代码都要围绕这个假设设计。

• 设置超时时间：每层API调用都给超时上限，比如1分钟，超时后自动走备份方案。
• 做自动重试：对限流错误和临时网络错误，按指数退避重试，最多3次。
• 建降级方案：主模型失败时，切换到备用模型或提示用户“稍后再试”。一个核心功能不能绑死单一供应商。
• 加模型输出校验：如果要求模型输出JSON，但解析失败，回调一次重新格式化工序。程序里永远不要直接假设模型输出是合法JSON。

5.3 上线前必做评估与回测：避开几个致命陷阱

上线前我强烈建议做一次“离回归测试”。把离线问答集在每一次系统改动后完整跑一遍，记录指标变化。改动Prompt、调整切块参数、换Embedding模型，都要重新跑，看是否正确和是否引入退化。

有两个特别容易被忽略的陷阱：

第一是信息泄漏。如果你准备测试问答对时，是从和训练文档相同的内容里提取的，那测出来的成绩会虚高。尤其当文档本身就在模型训练数据里出现过时，哪怕检索环节没用上相关内容，模型也可能“没有资料也答得出来”。这会掩盖检索链路的问题。

第二是测试集太单一。只测“找得到答案”的正样本，不测“文档里根本没有答案”的负样本。真实用户经常问库里没有的内容，系统要学会说“不了解”，而不是硬编。评估集里至少要加30%的负样本。

5.4 可观测性：从日志到trace到评估分数的闭环

生产环境里，AI应用比普通应用难排查。因为传统后端报错可以看堆栈，而AI应用的“报错”通常是“答错话”，词法上完全正常，语义上严重偏离。

我的做法是建立完整链路记录：每次请求，把“原始问题、判断后的意图、检索到的分块、送入模型的完整Prompt、模型返回结果、延迟、成本、版本号”记录到日志系统。一旦出现用户反馈或评估准确率下降，就从这些问题日志出发，重放链路，看哪个环节出了问题。

如果有能力，还可以给每个请求分配一个trace_id，贯穿客户端、应用、模型层，配合现有的日志平台（ELK等）做统一检索。这一套体系不需要一开始就做很重，先从“每次请求存一条JSON日志”开始就可以。

评估闭环的终点，是定时跑离线测试集并生成趋势图。准确率掉了一定第一时间知道，而不是等用户投诉了才知道。这是AI工程和“随手写个脚本调模型”最本质的区别之一。

6. 从零自学AI工程的踩坑实录：我亲历的几件事

6.1 坑一：沉迷刷模型论文，忽略工程落地

刚入行的时候，我花了很多时间读模型论文和层架构，甚至能画清楚多头注意力机制的计算流程。听起来很专业，但用处不大。真正催熟能力的是：把一个失败的Demo修到“能给别人用”，把一个慢到卡死的检索系统调到“响应低于1秒”，把一次事故排查到“日志里每一行都看得懂”。工程能力的增长，来自一个又一个系统上的真实问题，而不是看论文心得。

6.2 坑二：不看数据质量，直接把“垃圾”灌进系统

我做过一个文档问答系统，上线后回答质量惨不忍睹。我一开始以为是模型问题或者Prompt问题，改了一整天没效果。后来把文档内容打印出来仔细看——大量表格被抽取成混乱文本、PDF中编码错误导致的乱码、重复段落占据大片空间。系统检索到的所谓“相关段落”，根本是不可读的脏数据。

那次之后我养成了习惯：项目开始前至少花20%时间做数据清洗和分析。先随机打印几十条切块后的文本看一遍，确认干净再进Embedding。数据质量是整个系统质量的下限。

6.3 坑三：一上来就搭全家桶框架

我第二版RAG系统，用了某全家桶框架，配置了一堆组件，写的时候感觉很专业，但出问题之后排查了半天找不出是哪个环节的锅。后来干脆把框架拆掉，用原生代码重写核心链路，瞬间清爽。

我现在的态度是：能用标准库和云服务解决的优先原生处理；确实需要框架的场景，也要分模块引入，并且把每一层的日志和接口都记录清楚。框架是用来提高效率的，不是用来掩盖理解空缺的。先理解流程再选框架，永远别倒过来。

6.4 坑四：没有评估体系，就反复改需求

有一段时间，合作伙伴给了一堆新需求，今天说“回答要更像人话”，明天说“要有正式感”，我每次都临时调Prompt。结果每次调整只能让一部分问题变好，另一部分变差，全靠个人主观判断。后来把评估集建立起来，每次改动跑一遍分数，才能可视化地回答：“这个改法让整体指标提升了三个百分点还是倒退了两个百分点”。

评估体系是AI工程的“测试用例”。你没有它，就无法证明自己在变好，也无从定位问题。

6.5 踩过几次坑之后，我给新人的几条建议

挑三条最核心的：

1. 第一个项目一定要小：文档问答这种规模就够了。不要一上来做多Agent复杂编排、全自动流水线、跨系统集成。小系统里把每个环节吃透，后续做复杂项目才不会心虚。

2. 始终把“数据-评估-迭代”作为主线：流程永远是先处理数据，再定义评估，再迭代系统。模型只是其中一个组件，不是全部。

3. 建立自己的“AI工程工具箱”：把常用的切块函数、评估脚本、缓存模块、request重试逻辑沉淀成自己的代码片段库。以后做新项目，会发现从零开始的时间在指数级减少。

我自己到现在还保留着最初那个几百行的原始RAG脚本，随时回去看一下，能提醒自己：AI工程的核心不是热闹的新技术，而是扎实地把数据送进去、把答案送出来、把系统守住。从零开始的确要花不少时间，但每一步都是实打实地长在自己身上的能力。这套路走完之后，你面对任何新模型、新框架，都不会再焦虑——因为底层的工程思维，是不变的。