我刚入行那两年总被一个问题卡住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 工程要永远带着“批判性思维”。今天效果好的方案明天模型一升级可能就失效今天大家都在用的框架下个月可能就过时。真正能穿越时间周期的是你对原理的理解、对数据/评测体系的重视和快速迭代的工程习惯。这套基本功打扎实了不管底层换什么模型你都能站得住脚。