做AI工程快第七个年头了，带过不少从零起步的新人，也亲手把一个又一个 Demo 推到线上。我越来越确信一件事：你看到这个 "ai-engineering-from-scratch" 标题时候心里想的"从零开始"，和真正要在生产环境里落地一套 AI 系统的"从零开始"，大概率不是一回事。多数人以为的起点是"从数学原理推一遍 Transformer"，是"自己从头实现一个模型"，而实际业务里的起点往往是"给一堆乱七八糟的数据写清洗脚本"、"设计一个能被稳定调用的接口"、"把模型输出的垃圾结果拦在用户看到之前"。

这篇文章不聊高深的模型原理，也不准备带你重造轮子，而是想以我个人的真实项目体感，讲清楚从零搭建 AI 工程体系的完整路径：该选什么工具、先做什么后做什么、哪些环节会被反复返工、哪些坑是文档里永远不会写的。无论你是刚入行的开发者、想转 AI 工程方向的后端同学，还是已经会用大模型 API 但总觉得"差点工程味"的人，这篇文章应该都能给你一条能直接落地的路线参考。

1. 先想清楚："AI 工程"解决的到底是不是"模型"问题

1.1 你以为的从零开始，和真正的从零开始

刚转 AI 工程那会儿，我也犯过同样的错误：花了三周啃深度学习理论，试图把反向传播、注意力机制从头推导一遍。结果第一次接到真实任务时，发现卡住我的根本不是模型理解，而是"用户上传的 PDF 里表格解析出来全是乱的"、"向量库里检索出来的内容驴唇不对马嘴"、"同一个 Prompt 上午好用下午就抽风"。

后来带人，我总会先问一个问题：如果现在让你把一个已经训练好的开源模型部署成线上服务，你能搞定吗？这里的"搞定"指的是——能承受生产流量、能处理异常输入、能监控效果、能在模型输出变差时快速定位原因。大多数"从零开始"的人，在这道题面前会卡住。这恰恰说明，AI 工程的核心难点不在模型内部，而在模型周围那一圈没人写进教程的工程基建：数据管道、检索链路、评估体系、部署运维、成本控制。

我见过太多人在这条岔路上浪费了好几个月。不是说算法原理不重要，而是对于"工程落地"这个目标来说，它既不是起点，也不是捷径。真正的主线是把一个已经存在的模型能力，稳定、可控、低成本地嵌入到业务系统里。想明白这一点，你的学习路径会完全不同。

1.2 最小可用的 AI 工程链路长什么样

从零起步，你不需要一开始就设计出什么宏大架构。我个人经验是，任何 AI 应用只要能跑通下面这条最小链路，就已经比 80% 的 Demo 强了：

输入数据 -> 数据清洗/格式化 -> 检索（可选） -> 模型调用 -> 输出解析 -> 结果评估 -> 返回给用户

别小看这条链，每个环节都有各自的坑。数据清洗决定模型"吃"进去的东西干不干净，检索决定模型有没有足够的信息来回答问题，模型调用决定延迟和成本，输出解析决定能不能把模型回复变成系统能用的结构化数据，结果评估则决定你后续迭代有没有方向感。

拿最常见的 RAG 知识问答来说，最小链路就是：文档切分 -> 向量化 -> 存储到向量库 -> 用户提问 -> 召回相关片段 -> 拼进 Prompt -> 调用大模型 -> 返回答案。这一条链路里，任何一环出问题，最后用户体验都是"答非所问"或"胡编乱造"。而你能做的排查，就是从链路末端往回逐个检查：是没召回到？是 Prompt 拼错了？还是模型本身理解错了？

1.3 三条经典切入路径，选一条先跑通

从零开始的人最容易犯的第二个错，是同时想做太多事。今天想搭问答机器人，明天想做内容总结工具，后天又想搞自动化 Agent。我的建议是：先选一条最简单的路径，把它从零到一完整打通，再横向扩展。

经验里最适合新手起步的三条路径：

• RAG 知识问答：适合想解决"模型不知道企业内部资料"这类问题的场景。技术栈相对固定，链路清晰，评估起来也直观（答得对不对一眼就能看出来）。这是我最推荐的第一条路。
• 内容批量处理：比如摘要生成、信息提取、分类打标。特点是单条调用独立，不涉及复杂的状态管理，最适合用来练数据清洗和输出解析这两项基本功。
• 单 Agent 工具调用：让模型学会调用外部工具（查天气、查数据库、发邮件）。这条路径开始涉及"让模型做决策"，对 Prompt 设计和结果校验的要求更高，建议放到第二条或第三条再做。

这三条路径覆盖了 AI 工程最核心的几块拼图：数据、检索、生成、评估。跑通任何一条，你就不是"从零"，而是"有一了"。

2. 工具链选型：不同"从零"起点，对应不同的学习曲线

2.1 三档起步方式横向对比

工具选型这件事，被太多人讲成了"信仰之争"。其实不存在绝对最好的方案，只存在最适合你当前阶段的选择。我把常见起步方式分成了三档，各有各的适用人群：

我个人的建议是，如果你未来真想靠"AI 工程"吃饭，至少要走一遍第三档。哪怕最终项目里用了编排框架，也值得先用原生代码徒手搭一条链路，亲身感受一下"请求模型-解析结果-处理异常-封装接口"每一步到底发生了什么。这就像学做饭，用预制菜包能很快端出一桌菜，但想真的会做菜，总得自己切几回菜、炒糊几回锅。

2.2 我推荐的起步组合以及理由

如果让我给一个"既不那么累、又能学到东西"的起步组合，我会选：

• 编程语言：Python。生态最全，没有之一，AI 相关的库和示例几乎全是 Python 的。
• 模型调用：直接用官方 SDK 或原生 HTTP 请求，先不套编排框架。你只需要把 API Key 配好，发一个请求拿到回复，就完成了"模型调用"这一步。
• 接口服务：FastAPI。写起来简单，自带接口文档，异步支持也好，用来把链路暴露成 HTTP 服务再合适不过。
• 向量库：先别上分布式向量数据库，本地用 Chroma 或 FAISS 就行。它们的 API 足够简单，数据量在百万级以内完全够用。
• 开发调试：Jupyter Notebook 做探索，PyCharm 或 VS Code 写正式代码。

这套组合的理由不复杂：每个组件都足够"薄"，出现问题你都能直接看到底层实现。比如 Prompt 结果不对，你随手打印一下实际发给模型的消息内容，就能定位是模板问题还是模型问题，根本不需要去翻框架源码。

2.3 为什么先别急着上"全家桶"

现在行业里有个不太好的风气，一上来就是 LangChain + 向量数据库全家桶 + K8s 部署。对从零起步的人来说，这是在给自己制造不必要的复杂度。

我自己踩过一个大跟头。第一次做企业知识问答时，上来就用了当时最流行的编排框架，链式调用、记忆模块、各种回调，加了一堆抽象。结果上线第一周，用户反馈"答案不对"，我愣是花了两天才排查清楚问题出在召回环节——因为我得先搞明白框架内部的检索流程到底是怎么拼装上下文。那个框架当时的一个小版本升级，还顺手改了我依赖的接口签名，吓得我从此对"重量级抽象"都有了心理阴影。

不是说这些框架不好，它们确实能提升交付效率。但从学习和稳定性的角度，从零开始最忌讳的就是在一堆不确定之上再叠一堆抽象。先徒手跑通，再用框架提效，这个顺序一旦颠倒，排查问题就会变成灾难。

提示：判断一个工具是否适合你现在用，就看两件事——出了问题你能否在半小时内定位到根因，以及它的版本变动是否会打断你的迭代节奏。如果两者都是否，那你还没到用它的时候。

3. 搭建第一条完整链路：从数据准备到结果评估

3.1 数据准备：被吐槽但不做不行的脏活

很多人以为 AI 工程的数据准备就是把文件丢给模型就行。真实情况是，这一步能占到整个项目 40% 以上的工作量，而且直接决定上限。

我第一次做文档问答时，喂进去的是一批几十页的 PDF。偷懒没做预处理，直接把整页文本暴力切块。结果检索环节垃圾进垃圾出：模型拿到的是跨段落拼接的碎块，答案自然颠三倒四。后来老老实实写了清洗脚本，做了这几件事：

• 格式统一：把 PDF、Word、网页抓下来的文本全部转成统一的 Markdown 格式，去页眉页脚、去重复空白。
• 结构保留：按标题层级切分，而不是按固定字符数切分。表格单独提取，图片里的文字做 OCR。这一步对后续检索质量影响巨大。
• 去重去噪：用文本哈希做相似去重，把重复段落、导航文案、版权声明这类噪音清掉。
• 分块策略：固定字符数切分的块大小需要实测。我常用的配置是 500-800 个 token 一块，块间重叠 50-100 token。重叠的目的是避免关键信息正好被切在两块交界处。

这里有个工程细节值得单独说：分块不是越大越好。块太大，向量化后语义容易被稀释，召回精度下降；块太小，单块包含的上下文不够，模型回答容易缺前因后果。500-800 token 是我在多个项目里验证过的相对均衡的范围，但最终还是要拿你自己的数据跑几组对比实验再定。

3.2 检索层：为什么召回比生成更像核心

在 RAG 链路里，"召回质量"对最终效果的影响，经常比"模型本身"还大。原因很简单：模型只能基于你给它的信息作答，你连正确上下文都没找回来，再强的模型也只能瞎编。

一个典型的检索链路包括三块：向量化 -> 向量检索 -> 重排序。

向量化就是把文本变成向量。这一步的选型很关键，早期我用的是开源 embedding 模型，后来发现同样的检索逻辑，换成更强的新版模型（比如现在常用的 BGE 系列或各家的商用 embedding 接口），召回准确率能提升好几个点。而且这个提升是"白捡"的，你只需要改一行配置。

向量检索阶段，最常用的方式是 Top-K 召回。K 值的设置需要权衡：太小容易漏（该召回的内容没召回到），太大容易吵（无关内容混进来干扰模型）。我的经验是初始设为 5-10，再根据实际效果微调。另外可以加一个相似度阈值的硬过滤——低于阈值的片段直接不要，这能在源头上减少"垃圾进、垃圾出"的情况。

重排序是经常被忽视但性价比极高的环节。先用向量检索捞出 Top-50 候选，再让一个专门的重排序模型精排，取最相关的 Top-5。实测下来，这个两步检索方案能让最终答案质量稳定很多，尤其当你的知识库规模上去之后，单靠向量相似度已经不够可靠了，因为向量检索追求的"语义相近"有时候和"事实相关"并不是一回事。

3.3 生成层：Prompt 工程不是玄学，是结构化设计

Prompt 工程被很多人搞得很玄，其实本质就是一件事：把你希望模型做的事，用模型最容易理解的方式结构化地表达清楚。

一个生产级的 Prompt 模板至少包含这几个部分：

[角色设定] 你是一位精通企业制度的知识助手，只能基于给定资料作答。 [任务说明] 请回答用户的问题。若资料中没有明确答案，请直接说明不知道。 [上下文] 以下是检索到的相关资料： {context} [用户问题] {question} [输出规范] 回答中必须标注引用的资料编号（如 [1]），禁止编造细节。

这套模板背后有几个设计逻辑：角色设定限制模型的回答风格；任务说明 + "不知道就直说"能显著降低胡编概率；上下文区域是留给检索结果的插槽；输出规范则是为了后续解析和溯源。这些不是可选项，生产环境里每一块都在发挥作用。

另外，我强烈建议在开发阶段就养成一个好习惯：做 Prompt 版本管理。每一次改 Prompt，都记录改动内容和对应测试结果。这个习惯能让你后期迭代时少走无数弯路，否则你会陷入"改了跟没改一样"的迷宫。

模型参数也不是随便设的。temperature（采样温度）建议初始设为 0.2 左右，越低输出越稳定，适合问答类任务；越高越有创造性，适合写作类任务。max tokens 要控制，防止模型一口气输出冗长内容增加成本。这些参数都应该通过配置管理，而不是写死在代码里。

3.4 评估闭环：没有评估的 AI 工程是沙上建房

到了这个环节，我要强调一个很多新手最容易忽略的事实：AI 系统的输出是有概率性的，改了 Prompt 或换了模型，效果可能变好也可能变坏，但没有评估体系，你连"变好变坏"都判断不了。

我见过的最常见翻车现场是：开发了一个月的 RAG 系统上线，用户反馈"最近答案变差了"，团队一脸茫然，因为没人记得上一次改动到底动了哪几句话。这种情况的唯一解药，就是建立一套哪怕很简陋的评估流程。

第一步，准备一个小而精的测试集。不需要追求几百上千条，一开始 20-30 条覆盖典型场景的问答就够。每条记录包含：用户问题、预期答案要点、涉及的资料片段编号。

第二步，写一个自动化评估脚本。核心指标可以根据任务类型选：问答类可以看"答案是否包含预期要点"和"是否忠实于资料"；生成类可以看文本相似度指标；更精细的做法是用一个评估模型来当裁判（LLM-as-judge），让它按照你制定的评分标准打分。

# 一个最简化的评估骨架，帮助你理解思路 def evaluate(question, expected, answer): # 检查预期要点是否出现在答案中 hit = all(kw in answer for kw in expected["keywords"]) # 检查答案是否引用了正确的资料编号 citation_ok = expected["source_id"] in answer return {"hit": hit, "citation_ok": citation_ok, "pass": hit and citation_ok} # 跑完整个测试集，统计通过率 results = [evaluate(**case) for case in test_set] pass_rate = sum(r["pass"] for r in results) / len(results)

别小看这 20 条测试集。它能防住绝大多数"改了 A 结果 B 坏掉了"的回归，也是在业务方质疑"这系统到底行不行"时，你能拿出的最硬气的证据。我对所有从零开始的项目都会强调：评估集可以小，但必须有；不带着评估目标去做 AI 工程，等于蒙眼开车。

提示：评估集不是一次性资产，要跟着业务演进持续补充。每发现一类新错误，就把这类的经典 case 加入测试集。一个月后，这套评估集合就是你项目最值钱的部分之一。

4. 部署上线才是真正"工程"的开始

4.1 接口封装与鲁棒性设计

模型跑通只是开始，把链路变成可以被其他系统稳定调用的服务，才是工程味道最浓的部分。这一步的重点不是"跑通"，而是"在极端情况下依然能给出可用响应"。

我的标准做法是用 FastAPI 把链路包成一个 HTTP 服务。接口设计上有几个约定俗成的原则：

• 输入校验：请求体用 Pydantic 模型定义，字段类型、必填项、长度限制都明确声明。不要相信任何外部调用方会乖乖按你的文档传参。
• 超时控制：大模型调用必须设置超时时间。线上我曾经遇到第三方模型服务变慢，请求迟迟不返回，把整个服务的线程池都拖垮了。加上合理超时（比如 20 秒）之后，问题立刻缓解。
• 失败重试：对瞬时错误（网络抖动、限流）做一次重试，但重试要有退避策略，别在对方已经过载时雪上加霜。
• 异常兜底：任何环节出问题，接口也要返回一个结构化的错误信息，而不是 500 + 一堆堆栈。前端拿到错误后可以提示用户，而不是页面直接白屏。
• 流式输出：如果面向终端用户，强烈建议接口支持流式返回（SSE），用户在 1 秒内就能看到模型"打字"，体验远好于等 10 秒然后一次性蹦出全部内容。

# FastAPI 接口的骨架示例 from fastapi import FastAPI from pydantic import BaseModel, Field app = FastAPI() class QueryRequest(BaseModel): question: str = Field(..., min_length=1, max_length=2000) top_k: int = Field(5, ge=1, le=20) @app.post("/api/query") async def query(req: QueryRequest): # 这里接上你自己的检索 + 生成链路 answer = run_pipeline(question=req.question, top_k=req.top_k) return {"answer": answer}

这一步做好的意义在于：你的项目从"我本机跑得通"，升级成了"别人也能稳定调用"，这是工程化和玩具之间的分水岭。

4.2 性能与成本：缓存、限流与模型分级

模型 API 的按量计费让"成本"第一次如此直接影响架构设计。很多新手上线后不看成本曲线，月底一算账直接傻眼。这里分享几个我实测有效的降本组合拳：

• 语义缓存：把"相同或相近的用户问题"的答案缓存起来。常见做法是把问题的 embedding 向量存一份，新请求来的时候先跟历史问题算相似度，相似度超过阈值直接返回缓存答案。对于高频重复的咨询场景，缓存命中率能到 50% 以上，成本直接砍半。
• 限流控制：给接口配了限流策略，每个用户每分钟最多 N 次请求。既防恶意外部消耗，也防内部误调用。
• 模型分级：不同任务用不同规格的模型。比如意图识别、关键词提取这类简单任务用便宜的小模型，只有最终答案生成才调用最强的大模型。一套流程下来，平均单次调用成本能降一个量级，而用户感知几乎没有变化。

另外一个常被忽略的性能点是并发管理。对外提供服务的接口，内部对模型 API 的调用要控制并发数，不要无脑并发。我见过把模型 API 并发配额直接打满导致被限流的案例，加个简单的信号量或队列，稳定住调用速率，反而整体吞吐更健康。

4.3 可观测性：你必须看得见系统在干什么

上线前的最后一块拼图是可观测性。AI 系统的排查难度远高于普通后端服务，因为输出不仅取决于代码逻辑，还取决于你永远没法完全预知的模型行为。没有观测手段，出问题时就只能靠猜。

我的最小可观测性方案包含三层：

• 结构化日志：每次请求在入口生成一个 request_id，整条链路的所有日志都带这个 ID。日志里至少记录：问题原文、检索到的片段ID和相似度、最终拼接的 Prompt（或其摘要）、模型返回的原始输出、耗时、token 消耗。这样任何一个用户反馈"回答不对"，你都能通过 request_id 把整个链路重放一遍。
• 性能指标：用 Prometheus 之类工具统计接口 QPS、P95 延迟、token 消耗量、模型 API 的错误率。设好告警，延迟或错误率一旦异常立刻触发。
• 离线抽样分析：定期抽样一部分历史请求做质量复检，确认系统在真实流量下依然保持可用水平。这一步能弥补在线评估覆盖不到的长尾场景。

做完这三层，遇到线上问题你将不再是无头苍蝇，而是可以像查普通后端 bug 一样，一步步锁定"是哪一环的锅"。

5. 让系统活过三个月：版本、回归与迭代

5.1 Prompt 和数据都是要进版本库的

代码有 Git 管着，但我在大量项目里发现，Prompt 模板和数据集往往是"活在 Excel 和聊天记录里"的。这绝对是隐蔽的技术债，而且一定会还。

我现在的要求很简单：Prompt 模板以文件形式放进 Git 仓库，跟代码一起走 Code Review；测试集用 JSON 或 YAML 文件存好，同样入库到独立目录；任何改动导致测试集评估指标变化的，必须记录在提交信息里。

这套做法的直接收益是，当你发现"上周那个版本的效果其实更好"时，只需要git checkout对应的版本就能一键复现，而不是从聊天记录里翻一个也许已经失效的草稿。

5.2 回归测试比模型精度更能保命

大多数 AI 项目不会"一次性上线完美系统"，而是持续迭代码、调 Prompt、换模型。每次改动都潜藏着回归风险：你为了修 A 类问题改了 Prompt，结果 B 类问题的表现突然变差了。

解决回归风险的方式，就是把评估脚本接入持续集成流程。代码仓库里加一个 task，每次有改动就自动跑一遍评估集，指标通过率跌过阈值就不允许合并。这相当于给 AI 系统装上了一条安全带。

我第一次执行这个策略时，恰好抓住了自己前几天的一处"优化"带来的回退：改了一个 Prompt 措辞，整体通过率从 82% 掉到了 70%，但当时靠肉眼试用完全没察觉。有了回归测试后，这类问题在第一时间就会被机器拦住，而不是等用户来骂。

注意：回归测试的评估集要覆盖"历史所有修过的问题类型"，而不只是"当前最满意的样例"。否则你只是在反复验证已经能答好的题，真正的问题反而漏掉了。

5.3 给未来留后路：模块替换的抽象边界

最后聊一点架构层面的经验。AI 领域的技术迭代快得离谱，今天用得顺手的模型，下个月可能就被新版本碾压；今天用的向量库，明天可能出现更合适的替代品。如果你的代码把这些组件全焊死了，每次替换都是大工程。

我的习惯是给关键组件画一条清晰的抽象边界：数据加载、向量化、检索、生成、评估，各自封装成独立模块，模块之间用简单的接口协议通信。这样换模型时，只需要改"生成模块"的内部实现，其余全不用动；换向量库时，只需要保证"检索模块"对外的接口签名不变。

举个例子，我把"调用模型"封装成一个generate()函数，内部可以用 A 厂商的 SDK，也可以换成 B 厂商的请求，但只要参数（Prompt、模型名、temperature）和返回（文本、token 数）保持一致，外部完全无感。实测在没有预料到的情况下，这个设计帮我省了大量替换成本。

6. 零基础入门的学习路线与心态调整

6.1 一条我验证过多次的三个月路线

如果你完全从零开始，我的建议是按周为单位推进。路线太松容易流失，太紧容易劝退。以下是参考节奏：

• 第 1-2 周：用 Python 调通一个大模型 API，写几个简单的问答、摘要脚本，熟悉"输入一段文本 -> 得到一段文本"的基本流程；学习数据清洗与文本处理基础。
• 第 3-4 周：搭一条最小 RAG 链路：文档切分、向量化、向量检索、拼 Prompt、生成回答。不需要网络架构，本地脚本跑通即可。
• 第 5-6 周：做一个 20 条 QA 的小测试集，写一个自动化评估脚本，开始量化你的系统表现；尝试改进检索或 Prompt，观察评估指标的变化。
• 第 7-8 周：把链路用 FastAPI 包成 HTTP 接口，加上超时、重试、日志，学会本地启动服务并在 Postman 里调通。
• 第 9-10 周：部署到一台服务器上，接上正式数据源，配置基础监控；处理数据量变大之后的检索性能问题。
• 第 11-12 周：回归测试接入持续集成，整理全部文档，复盘整个过程中的失败 case，形成自己的迭代检查清单。

这个节奏不是绝对最优，但胜在"每个阶段都有看得见的产出"，不容易让人中途放弃。

6.2 别踩这五个坑

顺着前面的经验，我再把新手最容易掉进去的五个坑集中说一遍：

• 沉迷原理不肯动手：AI 工程是实践学科，看十篇讲 RAG 原理的文章，不如亲手跑通一次链路。原理可以在踩坑中学，先动起来。
• 没有评估就开始优化：不量化效果地调 Prompt，本质是在掷骰子。再忙也要先留出半天搭一个最小评估集。
• 盲目追新框架：技术更新换代很快，但底层逻辑（数据、检索、生成、评估）很稳定。框架只是工具，别让换工具变成你的主线任务。
• 忽视成本和延迟：Demo 阶段随便调用无所谓，一旦要考虑上线，就要在每个环节问一句：这步值得花这么多 token 吗？能缓存吗？
• 不写文档不记日志：AI 系统的状态和信息流比传统后端复杂得多，靠脑子记很快会崩溃。宁可代码写得糙一点，也要把观测和记录做好。

6.3 说点工程之外的大实话

做了这么多年，我越来越觉得 AI 工程的内核其实是传统软件工程和数据工程的老规矩——模块化、可测试、可观测、可维护——只不过披上了一层"模型输出不可完全确定"的新外衣。那些能在 AI 工程里走得远的人，未必是算法最强的人，但一定是工程习惯极好的人：他们重视数据、拥抱评估、敬畏线上。

从我自己带新人的经验来看，从零到一跑通一条链路最多只需要两三个月，真正拉开差距的是从一到十的那个阶段：当你的系统开始承载真实用户的真实问题时，"工程"这两个字的重量才会完全显现。希望这篇文章能帮你把那条最初的路子走直一些，省下来的时间，都值得用在打磨真正属于自己的那条链路上。