从GitHub上刷到"ai-engineering-from-scratch"这个项目标题时，我第一反应是：终于有人想把这条学习路径彻底捋清楚了。这几年我见过太多人一上来就调通了一个大模型接口的Demo，觉得自己已经"会AI"了，结果一到真实场景就抓瞎：回答不稳定、知识不对、成本失控、上线之后没人敢用。所谓AI工程化，远不是写几行调用API的代码那么简单，它是一条从模型能力到稳定业务能力的完整链路，涵盖提示词设计、上下文管理、RAG检索、Agent编排、结果评估、成本控制、监控告警这些环节。这篇文章想把我在这个方向上从零摸爬滚打的经验完整分享出来，写给那些和我一样，不想停留在"调接口"阶段、想真正把AI做成可靠产品的人。

1. 先想清楚一件事：AI工程化到底在解决什么问题

1.1 为什么"调用API"不等于"AI工程化"

大模型的API接口就那几个参数：model、messages、temperature、max_tokens。你填一填，跑通一个对话Demo，可能只需要半小时。但这离"工程"还差得远。

工程是什么？工程是面对不确定性和复杂度，仍然能保证交付质量的手段。传统软件工程处理的是确定性逻辑，输入输出可预期，代码写对了，结果就是对的。AI应用最大的不同在于：输出不可预期。同一个提示词，模型今天这么答，明天换一种说法；喂了不同上下文，它可能答得像两个完全不同的助手。如果你只是写个脚本把用户问题转发给模型，再把模型回答转发给用户，那本质上你只是一个"API搬运工"。

所以AI工程化的核心任务，就是把这个不确定性一点一点关进笼子里。这个"关笼子"的过程包括：在提示词层面做约束、在检索层面做过滤、在Agent层面做任务分解与校验、在评估层面做自动化打分、在运维层面做监控与回滚。每一层都是在给不确定性上锁。

用类比来说，传统编程像盖楼，图纸清楚、结构固定，浇完混凝土你基本知道楼会是什么样。AI工程化更像管理一支能力很强、但偶尔走神的团队。你要做的不是替他们干每一件事，而是给他们清晰的分工、明确的口径、验证工作成果的标准，以及出了问题时的补救流程。

1.2 模型能力是一种原料，工程化才是生产线

我把大模型看作一个"通用接口"，它能力确实强，但它只会一件事：根据你的输入，概率性地预测下一个token。真正产生业务价值的，是你如何把业务目标翻译成模型能理解的任务，如何在它答错的时候兜住，如何把它的输出接入到真实的业务流程中。

一个完整的AI工程化项目，通常包含五个模块：

• 模型调用层：负责连接各家模型服务或私有化模型，处理鉴权、限流、重试、熔断这些基础问题；
• 上下文管理层：负责管理对话历史、向量索引、知识切片，解决"模型不知道你业务细节"的问题；
• 工具与Agent层：让模型能够调用外部工具，执行搜索、查数据库、操作软件等动作，把"会说"变成"会做"；
• 评估与反馈层：建立一套可以重复运行的评测集，持续监测模型输出质量，避免一次改提示词把所有场景全部搞崩；
• 部署与运维层：处理并发、延迟、成本、日志和告警，把AI应用当做一个真正的线上服务去运营。

如果你去拆解任何一个宣称自己"落地了大模型应用"的团队，最后你会发现，他们的工作重心绝对不会放在"调API"上，而是放在后面的四层。很多人学了半天只会第一层，遇到问题就只会改提示词，结果怎么改都不稳定，核心原因就是后面几层没有建立起来。

2. 从零开始的路线图：三个阶段、四类工具

2.1 阶段拆解：先学会问，再学会查，最后学会做

从零开始学AI工程化，我踩了不少弯路，回头看整个路径可以分成三个阶段，每个阶段解决一类核心问题。

第一阶段：提示词基本功。这个阶段的目标是学会与大模型高效对话。不是背模板，而是理解模型的注意力机制和生成偏好，知道什么样的信息结构能最大程度消除模型的歧义。我当时给自己定的练习目标是：能写出一个不需要第二遍解释、第一次执行就能得到符合预期结果的提示词。这听起来简单，实际很难，因为"符合预期"本身就需要你先把需求想得非常清楚，同时你还要能预判模型在哪些信息缺口上会自作聪明。

第二阶段：增强记忆与知识。也就是现在非常热门的RAG（检索增强生成）。这个阶段要解决的问题是：让模型利用你提供的私有文档来回答专业问题。你需要学习文档切分、向量化、存储、检索排序这一整套链路，还要在提示词层面给模型设置边界，让它在该说"不知道"的时候老实说不知道。

第三阶段：Agent与自动化。在这个阶段，模型不再只是回答问题，而是一个会使用工具、能完成多步骤任务的智能体。你会给它配置工具，让它自己规划步骤，在不同的阶段调用不同的API、读取文件、判断结果。这里涉及ReAct模式、工具描述规范、多Agent协作和权限控制。

我自己踩过的一个坑是：太早进入第三阶段。那会儿连提示词都写不稳就急着搭Agent，结果Agent每一步都在犯低级错误，最后交给我一份完全没法看的结果。后来我老老实实回到第一阶段练了两周提示词，再回头看之前Agent的问题，一半以上其实都是因为提示词结构不合理造成的，跟Agent框架本身关系不大。

2.2 工具链清单：不用贪多，够用就行

工具这块我整理了自己最常用的四类，每类只保留一两个，尽量降低学习成本。

模型调试工具。首推各个模型厂商自带的调试台，比如OpenAI的Playground，或者DeepSeek、Kimi这些国内厂商的网页调试界面。直接在网页上调试提示词，比写代码来回跑要快得多。我习惯在调试台上测试同一个提示词在不同温度下的表现差异、验证输出格式的稳定性。等调试台上看不出问题了，再落到代码里。

开发框架。LangChain和LlamaIndex目前还是绕不开的两个名字，但我不建议一上来就上框架。更稳的路径是：先用原生方式手写一遍RAG链路，理解切分、向量化、检索这些底层逻辑，再去接触框架。直接上框架很容易被抽象层掩盖问题，一旦出Bug，你连问题出在哪一层都找不到。现在Dify、Coze这类低代码平台也很火，适合快速验证产品想法，但如果你想成为一个能解决真实问题的AI工程师，底层原理那一步省不掉。

本地模型工具。Ollama是我目前用过最省事的本地模型运行工具，一条命令就能拉起一个开源模型的API服务。它的价值在于调试时完全离线，不用考虑限流和费用，还能拿来做不同模型的对比实验。比如你想知道一个开源小模型和一个商业大模型在你的真实数据上差多少，用Ollama拉起开源模型，很快就能得到结论。

AI编程辅助。Cursor、Continue这些AI编程插件已经是日常标配。很多人把它们当单纯的效率工具，但我的看法是：一个每天用AI写代码的人，如果他连"AI如何理解需求、如何把上下文组织成可生成的代码块"这件事都搞不清楚，那他很难真正理解LLM应用的能力边界。你会发现，用AI编程工具这件事，本身就在训练你写清晰上下文、拆分任务的能力，这些能力可以直接迁移到Agent设计上。

2.3 学习资料的使用策略：官方文档优先，付费课程次之

AI工程化领域更新速度快到离谱，很多付费课程和畅销书里的内容，你拿到手的时候可能已经过时几个月了。我的策略是：官方文档和官方示例优先，其次是开源项目的README和源码，最后才是课程和博客文章。

具体的教训来自我早期买过的一套Agent实战课程。学的时候觉得讲得挺系统，等自己动手的时候发现，里面用的框架版本换了好几代，很多接口早就废弃了，照着写一段报错一段。后来我调整了策略，遇到问题直接去翻官方文档和GitHub Issues，反而解决得更快。官方文档通常能跟上最新版的变化，而且会包含很多课程里根本不会提到的边界情况和设计原因。课程和博客不是不能看，而是应该用来建立宏观认知框架，真正的细节一定要回到一手资料里去查。

3. 核心能力拆解：提示工程、Agent、AI编程工作流

3.1 提示工程：不是讨好模型，而是校准需求

提示工程（Prompt Engineering）是被误解最多的概念。很多人以为提示工程就是跟模型说好话、搞一堆花哨的模板，其实它的本质是：把你心里模糊的需求，变成一个模型不需要猜测就能执行的指令。

模型的能力边界是很明确的，它擅长的是"根据上下文做最可能的续写"，而不是"猜你想要什么"。如果提示词里存在信息缺口，它就会用自己的常识去补，补出来的东西自然不符合你的预期。所以我写提示词一直遵循一套固定的结构：

• 角色：你是一个擅长XX的资深分析师；
• 任务：请完成XX任务，需要得到XX形式的结果；
• 上下文：以下是需要处理的信息和背景资料；
• 约束：不要编造数据，所有数字必须来自资料原文；如果信息不足，请明确说明；
• 输出格式：用Markdown表格输出，包含A/B/C三列。

这套结构最大的价值是"可维护"。我改一个约束条件，就能预判输出会相应产生怎样的变化，这样提示词就可以当代码来管理。另一个关键认知是：提示词和模型是绑定的。同一段提示词在GPT-4上效果很好，换到开源小模型上可能完全跑偏。所以调试的时候，一定要明确自己绑定的模型名称和版本。

高级技巧方面，思维链（Chain-of-Thought）是我使用频率最高的。它让模型先把推理过程写出来，再给出结论，对数学、逻辑推理类任务提升非常明显。实操中我发现，不一定每次都要说"让我们一步一步思考"这种话，有时候只要加一句"请先列出你的推理步骤，再输出结论"就够了。还有一个小技巧：让模型在输出前先做一次"任务检查清单"核对，逐项自查以后再交付，错误率能下降一大截。

3.2 Agent：把"会说"变成"会做"

Agent是现在AI工程化最热门的领域。我对Agent的理解是：模型负责推理，工具负责执行，代码负责验证。它把大模型从文本生成器升级成决策器，让模型能够在真实环境里做事，而不只是说事。

当前最主流的Agent设计模式是ReAct，也就是推理与行动交替进行。核心流程是：模型观察当前状态，思考下一步该做什么，然后调用工具执行，观察执行结果，再继续推理，直到任务完成。这个模式中关键的技术点在于工具定义。

工具定义是很多人忽略的细节。你在给工具写描述的时候，不是写给程序员看的，是写给模型看的。描述里需要说明这个工具的用途、适用场景、输入格式、输出格式，最好再附带一两个示例。如果工具描述写得太简陋，Agent就不知道在什么情况下该调用它。我见过一个项目，工具名写的是"search"，描述只有一句话"搜索功能"，结果Agent几乎从没调用过它，因为模型根本不知道这个工具能搜什么、什么时候该用。

多Agent协作是另一个热度极高的方向。我的建议是先别急着上复杂框架。一个单Agent加两三个定义清晰的工具，已经能解决很多实际问题了。多Agent真正的价值在处理复杂任务的并行化和角色隔离，比如一个Agent负责收集资料，一个负责写作，一个负责核对事实。如果你对单个Agent的行为还没有把握就开始做多Agent编排，调试成本会成倍上升，因为你永远不知道问题出在哪个Agent的哪一步。

3.3 AI编程工作流：从写代码变成改代码

AI编程工具已经彻底改变了我的日常开发方式。现在我的主要工作已经不再是逐行写代码，而是Review AI生成的代码，这带来了两项新的核心技能。

第一项是"写清楚任务描述"的能力。我让AI写代码之前，会先把需求拆成明确的小任务，包括输入是什么、输出是什么、边界条件有哪些。这个描述写得是否清晰，直接决定了AI生成代码的质量。很多人抱怨AI代码写得烂，其实一半以上问题出在需求描述本身太模糊。

第二项是审查代码的能力。我现在会让AI先完成第一版，然后逐行Review合入逻辑、异常处理和边界条件。如果发现AI在同一个地方反复犯错，我会把这个约束写进项目的规则文档里，让后续所有代码生成都参考这份文档。比如我有个项目里有一条规则"所有数据库查询不得使用SELECT *，必须明确列出字段"，加进文档之后，AI生成的新代码基本都遵守了。

实用的小技巧：用AI生成单元测试。每次重构完核心模块，我会让AI先看一眼自己的代码，找出边界风险点，再帮它补一轮测试。AI生成的测试肯定有覆盖不到的地方，但结合我自己的人工Review，整体测试覆盖率提升还是相当明显的。这种做法等于是让模型参与了自己代码的质检，它对自己生成代码的逻辑推导往往能发现一些人类Review时容易忽略的边界情况。

4. 动手做一遍：一个AI知识库问答助手的完整落地

理论聊再多，不动手都是纸上谈兵。我用一个完整的案例来讲一遍从零构建AI应用的实操过程：给团队做一个"产品知识问答助手"，知识源是几十篇产品文档和FAQ。这个案例覆盖了RAG、提示词、评估、成本控制这几个核心环节，适合照着复刻。

4.1 需求定义：先别写代码，先把边界写清楚

任何AI项目，我都建议从需求定义开始，而不是从模型选型开始。产品知识问答助手听起来很简单，但第一步其实是确定回答边界。

我给这个项目定了两条硬性规则：与公司产品无关的问题，不回答；资料中没有明确依据的问题，不回答，只能说明"资料中未找到相关信息"。这两条规则的作用是提前把"不知道"的场景定义清楚，从源头压缩幻觉空间。

第二步是准备评估集。我收集了五十个真实用户问题，覆盖性能指标、功能对比、报错处理、操作指引这些典型场景，每个问题都标注了期望回答的来源文档。这个评估集就是整个项目的锚。后面我每次改提示词、调检索逻辑，都会把这五十个问题跑一遍，对比分数变化。没有评估集的AI项目，就像没有自动化测试的普通项目，上线全凭运气。

4.2 RAG链路搭建：切分、向量化、检索、合成

评估集就绪之后，开始搭RAG链路。这里我第一个踩的坑就是文档切分。

产品文档通常有完整的章节结构，直接用固定长度硬切，很容易把一个技术概念拆得七零八落。比如某个功能的说明散布在两个切片里，检索时任何一个切片都缺上下文，模型看到的就是一段不完整的话。后来我改成按标题层级切分：先抽取Markdown标题结构，按小节切分，每个切片控制在五百到一千字。同时把上层标题拼进切片的元数据里，这样检索返回时模型能知道"这段文字来自哪个章节"，回答时信息完整性好了很多。

向量化模型的选择上，我建议先用主流模型跑通流程，不用一上来就追求最顶配。中文场景我当时用的BGE系列开源模型，效果就够用了。真正影响检索质量的事情是混合检索：向量检索负责召回语义相近的内容，关键词检索负责精确匹配专有名词，比如产品型号、报错码这些，最后做加权融合排序。单路检索里那些"明明文档里有答案但就是搜不到"的问题，换成混合检索之后明显少了很多。

合成回答这一步，提示词结构比想象中更重要。我写的合成提示词里有一条特殊约束："如果检索到的资料与问题无关，或者资料之间相互矛盾，请明确告诉用户'当前资料无法支持回答这个问题'，不要强行拼凑答案。"这条约束在实测中大幅降低了幻觉概率。模型有了"拒绝"的权利之后，反而在它能回答的范围内表现得更准确。

4.3 上线前必须做的性能评估与调优

分享一个具体的调优案例。第一版跑评估集的时候，回答准确率只有60%左右，问题集中在两类：一类是检索没有召回正确资料导致"答非所问"，一类是资料里其实有答案、但模型没引用到导致"丢了信息"。

针对第一类问题，我把向量检索的候选数量从3提升到8，同时加入关键词匹配逻辑，准确率从60%提升到75%。针对第二类问题，我在合成提示词里增加了一条："回答时请先引用检索资料中的原文或准确转述，再补充说明。"并给模型提供了文档标题和原文片段，准确率涨到85%左右。剩下15%主要来自提问本身特别模糊，或者资料里本身就缺信息，这已经不是调参能解决的了，需要在业务侧补充资料或加一层问题澄清机制。

这个调优过程给我最大的提醒是：任何改动都要用评估集跑一遍，不能凭感觉觉得"好像变好了"。你改提示词的一个词，可能让A类问题变好，同时让B类问题变差。没有评估集兜底，你根本不知道自己哪一下改过了头。

4.4 成本与延迟的控制经验

成本控制在很多教程里都是被忽略的话题，但实际项目里这往往是老板最关心的事。我讲几个可落地的做法。

第一是语义路由。在进入RAG链路之前，先用一个轻量模型对用户问题做分类，判断这到底是不是一个需要检索知识库的产品问题。如果不是，直接走通用回复，不触发向量检索和大模型生成，能省掉大量无效调用。第二是模型分层。不同的任务用不同规格的模型：上下文总结、问题分类用便宜的小模型，复杂合成回答才用大模型。第三是缓存。高频问题一旦有一次高质量回答，就把结果缓存起来，重复提问直接返回缓存，不再调大模型。

延迟方面，最重要的三个手段是并发控制、流式输出和异步处理。流式输出对用户体感的提升最明显，模型还没回答完，用户已经能看到第一个字了，等待焦虑直接消失。很多人只关注"回答质量"，忽略了"回答速度"，其实在真实产品里，三秒内出结果和十秒后才出结果，用户对产品好坏的判断天差地别。

5. 踩坑实录：这些问题我猜你也会遇到

5.1 幻觉问题：不是模型不聪明，是你没给边界

幻觉是AI应用最常见的问题。我的结论是：幻觉本质上是"信息缺口"的表现。模型在你没有提供信息的区域，会用训练数据里的既有模式去填空。你与其期待模型变得"更诚实"，不如从工程上把信息缺口压缩到最小。

实操上有三个手段。第一，提示词明确写清楚"资料不足时直接说不知道"。第二，RAG检索时把"找不到"当作一种正常结果处理，让模型有机会拒绝回答，而不是硬着头皮拼凑。第三，重要场景增加"依据二审"环节：让模型在回答里标注依据来源，再用代码逻辑去核对这个来源是否存在。最后这一步等于给AI输出加了质检，我见过一些金融、医疗场景的团队就是这么做的，准确率提升非常大。

5.2 上下文管理与Token失控：别舍不得花，也别瞎花

Token成本是新手最容易忽视的坑。我见过一个团队，每次请求都把全部对话历史塞给模型，用户聊五十轮之后，一次请求要消耗几万Token，成本高得吓人。

我的策略是给对话历史加一个"窗口"：只保留最近几轮完整对话，更早的内容压缩成摘要放进来。这个操作要配合场景判断：客服场景需要完整保留用户诉求，不能盲目截断；但知识问答场景，历史只是上下文参考，摘要就够了。所有涉及上下文截断的方案，都要回到那个核心原则：用评估集来验证截断后的回答质量没有明显下降。

5.3 评估的困局：没有评分标准，就没有优化方向

评估是AI工程化里最难也最容易被跳过的一环。AI应用的输出不像传统程序有明确的断言，怎么验证"答得好不好"是个真问题。我建议从三个维度打分：有用性，看回答和问题的相关性；准确性，看事实有没有依据；安全性，看成有没有不该有的内容。

初期用人工打分最简单，做张评分表，对每个用例打分记录就行。等用例积累到几十个以后，可以尝试用大模型给大模型打分，让一个裁判模型根据评分标准对回答质量打分。但这里要特别小心，模型自评有系统性偏好，比如容易认为"字数更多的回答"更好。所以模型打分之后，一定要定期抽检人机打分的一致性，发现偏差就调整评分提示词。

5.4 数据安全与合规：界碑要立在最前面

最后专门说一下数据安全。现在企业用AI最担心的就是敏感数据外泄。我的实践原则是：涉及用户隐私、商业机密、内部敏感信息的数据，一律不直接发给第三方模型API服务。能私有化部署就用开源模型做私有化，需要上云就用云厂商的脱敏网关。

同时还要在输入侧加一道脱敏：手机号、身份证号、银行卡号这类信息，在进入模型之前就替换成占位符，模型处理完之后再映射回来。这些安全设计必须在需求阶段就进入方案设计，而不是上线前补做。模型能力再强，也不能以牺牲数据安全为代价。

5.5 框架版本地狱：锁定版本，永远看官方文档

最后这个坑属于工程类通病，但AI领域尤其严重，因为框架迭代实在太快了。LangChain三天两头发新版本，接口说变就变。我推荐的做法是两套方案并行：正式项目里锁定框架版本，用requirements.txt和lock文件把版本钉死，升级时专门留出时间处理breaking change；学习阶段则尽量少依赖框架，用原生代码手写核心链路，等理解了原理再去感受框架的便利。

结尾

写到这里，我把从接到需求、梳理思路，到搭完RAG链路、跑完评估集、控制成本、守住安全底线这一整个闭环大概讲了一遍。我自己在这个"从零开始AI工程化"的方向上摸索了很长一段时间，最大的体会就是：这个领域没有一张现成的标准化图纸，但有一条很底层的方法论，就是永远把"产出可验证的结果"放在第一位。不管外面怎么吹一个新模型或者新框架多厉害，我都会拿自己那套评估问题去打一遍，看看它在我自己的数据上是不是真的变好了。

如果让我给准备入坑的朋友一个建议：从你手头一个真实的、烦人的、每天都在重复的任务开始，不要从某个框架的教程开始。把那个任务的解决过程当成你的第一个AI工程化项目，你遇到的那些问题会逼着你去补齐提示词、RAG、Agent、评估这些环节。这个项目完整跑通了，你才算是真正迈过了"会调接口"到"会做AI工程"的那道门槛。

最后再分享一个小习惯：我把自己的评估集存在一个单独的文件夹里，每次任何改动都同步更新用例、记录分数变化。这个习惯救过我很多次，每次有人跟我说"这个方案肯定更好"的时候，我就把前后分数对比甩给他看。在这个AI技术日新月异的环境里，有数据支撑的结论，才是真正靠得住的结论。