我刚入行那两年，总被一个问题卡住：AI 项目到底该怎么“认真”地做下去？模型会调参、会写 prompt，可一旦要落地成产品，就发现以前那套零散的技能完全不够用。数据、评测、接口、上下文管理、服务质量、成本控制，哪一环掉链子都会让整个系统推倒重来。后来我把“模型能力”和“工程能力”彻底分开看待，才慢慢摸出 AI Engineering 的门道——这不是换个框架调接口，而是一套从需求拆解到系统落地的完整方法论。这篇文章把“AI 工程从零开始”的套路完整梳理了一遍，适合正在观望入门、但不想只停留在调用 API 层面的读者，也适合已经在写 demo、却被生产环境反复折磨的开发者。很多东西是我自己在项目里一步步踩出来的经验，能帮你少走不少弯路。
1. 从零开始前，先搞清楚 AI 工程和普通软件工程的区别
1.1 同样写代码，为什么 AI 工程的思维方式完全不同
传统软件开发的核心是确定性逻辑：输入 A，经过函数处理，一定得到输出 B。你写的每个分支、每个判断都是可控的，bug 可以靠 review 和单测兜住。AI 工程则不一样，底层是不确定性的模型推理，同样的 prompt 可能输出不同结果，同样的输入数据在不同版本模型上表现可能天差地别。这种“非确定性”让很多习惯传统开发的程序员很崩溃——你没法像测一个排序函数那样去测一个聊天机器人。
我见过太多团队用传统流程倒推 AI 项目：先拉需求、画原型、排期开发，结果到了联调阶段才发现 prompt 效果不稳、模型返回格式乱七八糟，项目直接烂尾。本质原因是他们把模型当成了普通组件，忽视了 AI 系统的行为边界是“概率化”的，不像普通函数“要么对要么错”，AI 系统从来没有完美，只有“在多大置信度下可用”。
所以 AI 工程的第一步不是选模型，不是写代码，而是心态重置：接受不确定性，并用工程手段把不确定性圈在一个可控范围内。这包括设计清晰的输入约束、为模型输出设计校验机制、建立评估体系去测量“好不好”，而不是只看“能不能通”。这整套东西，正是传统软件工程没有覆盖的新功课。
1.2 AI 工程的核心能力栈：不只会调 API 才算懂
如果你把“AI 工程”拆开来看，本质上要面对三大能力挑战：
第一是模型与数据层。得理解 Transformer、embedding、token 这些基础概念，知道为什么数据质量会直接影响效果，也得懂怎么构建指令数据、怎么清洗、怎么构造 few-shot 样例。很多人一上来就调 API，等到回应质量上不去，根本判断不了是 prompt 的问题还是数据的问题。
第二是接口与交互层。这一层涉及 prompt engineering、上下文窗口管理、函数调用（function calling）、Agent 规划、工具编排等。模型本身的智商再高，没有这一层的工程化设计，你就是裸调一个聊天接口，无法嵌入业务。
第三是工程与运维层。这是最能拉开普通开发者和高级工程师差距的地方。包括 RAG 系统搭建、向量检索调优、缓存设计、成本优化、可观测性和评估迭代机制。AI 项目上线只是起点，后面整个“持续优化飞轮”才是真正的护城河。
如果把这三个层级当成学习地图，你会发现自己缺的不是某个教程，而是一张按优先级排好的路径。接下来我按这条路径逐步展开。
2. 理解基础：大模型工作的三块基石，理解这些才能走稳
2.1 Token 和上下文窗口：为什么你的模型总是“记不住”前文
很多新手第一次碰大模型时最困惑的就是上下文窗口。ChatGPT 看起来能记住一整场对话，实际上它只是在有限的窗口内反复“重读”你给的 token。不同的模型有不同窗口大小，比如 8K、32K、128K 甚至更多，但无论多大，它都有上限。
我做 AI 客服系统时犯过最蠢的错误：把客户整段历史工单全塞进 prompt，以为上下文越长越好。结果模型输出质量急剧下降，响应时间从 1 秒飙到 8 秒，每次调用成本翻了好几倍。后来才意识到，长上下文不是免费的——它消耗算力、影响速度，而且窗口中间的内容容易被模型“忽略”。
实操中能直接用的方法是：做一个明确的话题管理模块，把对话历史截断到最近 N 轮，对更早的内容做摘要压缩。这相当于帮模型划重点，让它把注意力集中在当前任务上，而不是大海捞针。至于 N 选多少、摘要怎么做，没有统一答案，建议以实验数据为准，我用过的稳定起点是保留最近 10 轮左右完整对话，更早的信息按内容类型丢给摘要模型处理。
2.2 Temperature、Top-p 这些参数到底怎么影响输出
模型输出不是一个固定答案，而是在概率分布中采样。Temperature（温度）控制采样的随机程度：温度越低，输出越确定保守；温度越高，输出越发散有创造性。Top-p 类似的，它限制采样范围，只在累积概率前 p 的token里采样。
参数的选择必须跟场景对齐。我说个真实例子：用来做信息抽取、数据清洗的任务，temperature 我会调到 0.1~0.3，因为我们需要稳定的格式和内容；用来做营销文案、头脑风暴，temperature 我会调到 0.7~0.9，保留创造力。千万别一个参数走天下，更别把默认值当最优值。
另外要记住，跟模型对话时你无法通过肉眼稳定判断参数是否最佳，唯一靠谱的路子是你的评估集。把一批典型输入固定下来，跑不同参数的对比实验，量化看输出质量。这块内容后面关于评测那一节我详细说。
2.3 Embedding 和向量：RAG、搜索、相似度计算的源头
AI 工程里大部分时间在跟“文本相似度”打交道。判断两个问题是不是一个意思、从知识库里找出跟用户问题最相关的片段，本质上都需要把文本变成向量，再计算距离。这一步的关键就是 embedding 模型。
Embedding 模型的选型直接决定 RAG 的上限。我用过不少开源和商用 embedding 模型，最大的体感差异是：中文场景闭源商用模型通常优于通用开源模型，尤其是专业领域的长尾词处理。所以如果你做的是垂直行业，强烈建议做一次领域数据上的召回评测，而不是只看某个模型在开源 benchmark 上的得分。现实场景中，模型选择错了后面整条链路怎么调都补不回来。
3. 动手第一个应用：提示词工程与 AI Agent 的高效构建方式
3.1 提示词工程不是“写好一句话”，而是系统化设计交互
刚开始学 prompt engineering，很容易把注意力放在“怎么写出一句神奇的话”上。实际做过项目就会明白，prompt 只是表面，真正决定效果的是你设计给模型的任务结构。最值得固定的套路我认为有三个：角色设定、任务分解和输出格式约束。
角色设定不要只是说“你是一个专家”，要给模型足够具体的任务背景，包括目标用户是谁、你有哪些信息、要达成什么结果。任务分解是把一个复杂需求拆成模型能一步步执行的子任务，比如“先分析用户情绪，再判断是否需要转人工”，每个子任务用明确的文字描述清楚。输出格式约束则是把答案锁进 JSON、Markdown 或特定模板里，方便下游程序解析。
这当中最常被忽略的是“模型不知道你不知道什么”。你以为自己已经说得够清楚了，对模型来说可能还缺了一堆背景。一个非常好用的调试技巧是：当模型输出混乱时，不要急着重写 prompt，先换成“自我解释”模式，让模型把你给的指令复述一遍、把它推测的任务目标说出来。这个过程能快速暴露 prompt 里的歧义。
3.2 从单次调用到多步骤：Agent 的规划、工具调用和状态管理
Agent 是当前 AI 工程最热的方向，本质上它让模型不再只是一问一答，而是可以拆解任务、调用工具、观察结果、修正路径。听起来很酷，但它带来的工程复杂度是成倍增加的。
先说最简单的 ReAct 模式：模型每走一步，先思考“我需要做什么”，然后选择调用一个工具或输出最终答案。这个循环只要设计得好，就能解决很多单轮 prompt 搞不定的任务。但坑也在这里：模型确实会“幻觉”，它会自己编造工具调用的结果，尤其在没有结果校验时。所以我做 Agent 有一条铁律：每一步工具调用的结果必须能溯源，要么打印日志，要么记录 trace，无论如何不能让模型自己在循环里“编故事”。
工具调用层面，一定要给模型提供定义清晰的函数描述，包括用途、参数、返回值。描述写得含糊，模型就乱猜参数。我在项目里见过模型把字符串类型的参数填成 JSON 对象，就是因为函数的参数 schema 写得不严格。函数定义阶段多花点心思，后面省的是无穷多的 debug 时间。
多 Agent 协作看着高级，但真实项目里我建议别一上来就搞。两个 Agent 来回对话一旦没有终止条件，不仅耗时、花钱，还容易陷入死循环。先把单 Agent 的工具链做扎实，再考虑用“规划器 + 执行器”的分层结构，多 Agent 协作放到后面有充分日志和评测体系支撑时再说。
3.3 AI 编程辅助工具在工程实践中的实际用法
现在很多团队已经离不开 AI 写代码。但 AI 编程不是“让 AI 把整个模块写出来”，我用的模式是：让 AI 帮我快速搭建脚手架、生成单元测试用例、解释陌生代码库，或者做重构前的风险评估。这些场景里 AI 提效非常明显。
还有一点值得多说：AI 生成的代码必须纳入人工 review 流程。我吃过一次亏，AI 帮我写了一个看起来非常完美的 RabbitMQ 消费逻辑，结果它在异常处理分支里吞掉了消息，导致数据丢了整整一天。AI 编代码跟人编代码一样会出 bug，而且它出错的方式往往更“隐蔽”，因为语法、命名、注释看起来都太规范了。所以 AI 编程的工程纪律是：AI 写代码，人做设计和终审，测试一道都不能省。
4. 用 RAG 解决“模型不懂你业务”的问题
4.1 为什么大模型非得配一个外部知识库
大模型的训练数据有截止日期，而且缺乏企业内部知识。想让模型回答问题既准确又贴合业务，最可靠的手段是 RAG，检索增强生成。它的原理不复杂：用户提出问题，先在知识库里检索相关片段，再把片段作为上下文丢给模型生成答案。
跟微调相比，RAG 最大的优势是可变性。知识库更新不需要重新训练模型，只要替换文档、刷新索引就行。绝大多数企业的 AI 应用场景，如果没到“语言风格和知识格式深度绑定”的程度，我都建议优先考虑 RAG。微调成本高、周期长，而且你永远要用一个评测体系去验证微调后的模型没变蠢，这在初期根本不划算。
我用 RAG 做过一个企业内部的规章制度问答助手。最初尝试直接扔给模型一堆文档让它在上下文里找答案，效果非常差，响应还慢。切到 RAG 架构之后，先用检索把范围缩小到 3~5 个片段，答案准确率一下子就上去了。这背后其实就是“先收敛，再生成”。
4.2 分块策略、Embedding 选型和混合检索的搭配逻辑
RAG 效果好坏，一半靠检索，一半靠生成，但检索的质量很大程度由分块策略决定。分块切太碎，上下文丢信息；切太粗，检索噪声变大。我总结过一套稳妥思路：先按文档结构切成有语义的单位，比如 Markdown 标题、PDF 段落，不要硬按固定字符数切。接着再考虑补充策略：标题加进块内容、前后段落适度重叠，这样能缓解硬切带来的语义断裂。
Embedding 选型这块我前面提到了要按领域实测，这里给个具体方法：找 100~300 条真实业务问题，人工标注出每道题对应的正确知识片段，然后用不同模型去检索，统计 Top 5 召回率。谁高用谁，就这么简单。不用迷信什么榜单，业务反馈才是唯一标准。
混合检索是另一个必须关注的优化点。向量检索擅长语义匹配，但有时候用户问的词是精确的名词、编号，字面匹配更重要。我现在的主力架构是“向量检索 + 关键词检索”并行，再用一个重排序模型（reranker）把两类结果统一打分。加一个 reranker 的效果通常立竿见影，但要注意它会增加延迟，得在产品体验和效果之间做取舍。
4.3 自建知识库问答系统的完整落地过程
我按自己多次实践过的步骤整理一遍，照搬大概率能跑通：
第一步，资料清洗。把所有原始文档转成统一的 Markdown 或纯文本格式，去掉页眉页脚、重复章节，把表格转成带上下文的说明文字。这一步最花时间，但投入产出比最高，脏数据进了知识库后面所有环节都会遭殃。
第二步，设计分块。按标题层级把文档拆成不超过 500~800 字的语义块，保留标题作为前缀信息。几十万字的文档切成几百个块，控制好你的向量化时间。
第三步，建索引。把每个块喂给 embedding 模型得到向量，存入向量数据库。现在工具很多，开源项目我建议试 Milvus，轻量场景直接用 Chroma 或 Qdrant 也行，关键是要能方便地做后续的过滤和混合检索。
第四步，写检索逻辑。用户问题进来先做改写，再走向量和关键词双通道召回，拼接结果后交给 reranker 排序，最后截取 Top 3~5 个块。
第五步，构造生成 prompt。把检索到的内容和用户问题放进模板，并且严格告诉模型“只能根据给定材料回答，不能编造”。少了这句约束，模型会自由发挥到你怀疑人生。
第六步，上线后做记录。每一条用户反馈都保存下来，给结果打标，定期回看失败案例。RAG 系统永远不可能一劳永逸，它是持续迭代的活。
5. 生产环境的 AI 应用：评估、迭代与运维实战
5.1 评估体系：没有量化，就没有优化方向
AI 应用最怕的就是“感觉还行，但说不出哪里不行”。没有评估体系，你无法知道 prompt 改动是变好了还是变坏了，更无法在模型版本升级时判断升级到底值不值。
构建评估体系，我的做法分三层。第一层是核心指标，比如回答准确率、格式达标率、不相关信息出现率。这一层必须做成自动化测试，把你积累的黄金评测集跑一遍，输出分数。第二层是业务指标，比如用户满意度、任务完成率、平均轮数，这些数据来自线上埋点。第三层是成本指标，单次请求成本、缓存命中率、平均延迟，AI 项目上线之后成本失控是常态，没有这层数据你连调优都不敢。
实际落地时，不需要一开始就建得很复杂。先搞一个最小的评测集，50~100 条典型输入就行，每次改 prompt 或者换模型就跑一遍。等稳定了，再用 LLM 作为评委自动打分，减少人工。记住一个原则：没有评估的优化都是碰运气，而运气在工程里是不靠谱的。
5.2 延迟、成本与稳定性：三个绕不开的工程瓶颈
AI 应用上线后，最直观的压力是延迟。一个大模型调用动辄 2~5 秒，再加上 RAG 的检索时间，用户早就等毛了。我在一个文档问答项目里试过把延迟从 8 秒降到 2 秒，主要做了三件事：
第一是缓存。常见问题的答案缓存下来，命中率能到 25% 以上，这部分请求几乎是秒回。第二是模型分级。重要请求用强模型，简单请求用轻量模型，能省不少成本和时间。第三是流式输出。让用户先看到字在动，体感延迟大幅下降。别小看流式输出，它不改变真实处理时间，但能改变用户的耐心。
稳定性方面，一个很容易被忽略的问题是“上游模型波动”。大模型 API 偶尔会出现超时、返回异常，如果代码里不做重试和降级，用户就会直接看到报错。我的稳定做法是：所有模型调用统一封装，默认超时时间和重试次数写死，并且准备一个小模型的降级方案。核心链路绝不能因为一次调用失败全盘崩溃。
5.3 大模型 API 之外：私有化、开源模型与成本控制的现实选择
不是所有场景都适合调云端大模型 API。数据敏感的企业、完全离线的内网环境、需要长周期稳定运行的业务，都得考虑私有化部署。开源模型这几年进步非常快，挑一个适合自己数据量版本的模型做微调后，不少场景的效果已经不输商用 API。
但私有化部署不是免费的午餐。你得准备好显卡资源、负责推理服务的运维，还要承担模型更新的成本。我见过一个团队为了“自主可控”非要在 4 张消费级显卡上部署一个超大模型，结果延迟高到不可用。这里给个实在的建议：先量化你的并发量和响应时延要求，再反推硬件配置与模型选型，不要为了私有化而私有化。
成本上还有一个容易忽略的点：长对话场景的 token 费用会随着轮数增长而爆炸。我在一个 Chat 机器人项目里，用户平均聊 20 轮，如果每一轮都携带完整历史，一天下来光是 token 费用就够开一台服务器了。解决方法是前面提到的历史摘要压缩，最近几轮保留原文，更早的压缩成摘要，这样才能控制住成本曲线。
6. 一些让你少踩坑的实战建议
6.1 项目冷启动：先做“最小可行评估”，再写正式代码
我给很多朋友推荐过同一条冷启动路径：拿到一个 AI 需求，先别急着设计架构、选型框架。花一两天时间，用现成大模型 API 加少量人工 prompt，把业务核心场景手动跑 20~30 条用例，看效果是否值得工程化。
这件事的价值在于帮你快速判断项目天花板。有些需求，模型本身根本做不好，那后面所有工程投入都是白费。反过来说，如果手工跑效果已经不错，再投入去写代码、建 RAG、做评估，方向就有了确定性。这也符合 AI 工程“先验证再建设”的核心理念。
6.2 项目中后期：用“用户反馈日志”驱动迭代，而不是拍脑袋改版
AI 系统上线不是终点。我问过很多团队，你们下次改 prompt 的依据是什么？答案往往是老板说不好用、客户提了个不满意反馈。这是非常差的迭代方式，因为个别反馈无法代表整体水平，而且容易让你被噪声带偏。
正确做法是所有线上请求全量落日志，包括输入的 prompt、模型输出、检索命中的知识片段、用户后续操作（是否点赞、是否复制、是否追问）。每天抽一部分做人工抽样评估，积累成你需要优化的证据。效果优化不是玄学，它是数据驱动的闭环。我自己的团队平均每周会拿 100~200 条线上真实数据做评估，拿评估结果反推修改方向，这是一个百试不爽的节奏。
7. AI 工程的下一步：怎么持续成长，而不是停在调接口
这个领域变化太快，我自己的学习方式也在不断调整。现在我会固定关注几类内容：一是在实际项目中不断积累评测数据，这是最宝贵的资产；二是定期追踪开源社区的模型更新和框架变更，但不会盲目追新，只有当前项目遇到痛点时才做选型切换；三是花时间参与一些高难度任务的拆解复盘，比如 Agent 在复杂场景下的容错设计、RAG 在超大数据量下的架构演进。
我个人还有个很深的体会：做 AI 工程，要永远带着“批判性思维”。今天效果好的方案，明天模型一升级可能就失效；今天大家都在用的框架，下个月可能就过时。真正能穿越时间周期的，是你对原理的理解、对数据/评测体系的重视和快速迭代的工程习惯。这套基本功打扎实了，不管底层换什么模型，你都能站得住脚。