1. “AI工程”到底是什么我把它拆成了五条可落地的路先说说我的背景免得误导人。我做了差不多十年后端和架构在LLM大语言模型火起来之后自然开始做AI方向的项目。但这篇不是讲理论也不打算给你画一张“AI工程师速成大饼图”而是想把我从零开始搭建AI工程能力时的真实路线拆给你看。很多人问“ai-engineering-from-scratch到底该怎么学”我的答案非常朴素别从论文学别从框架学从一条最窄的完整链路学——理解模型能力边界、写结构化提示词、设计一个能用的Agent、把模型部署成服务、再给它套上工程质量体系。你会发现这件事本质上是“系统工程”LLM只是其中一个零件。为什么我强调“从零”因为大多数教程默认你已经会Python、会调API、看得懂LangChain源码。但我接触过的很多朋友连“温度参数”对这个任务到底有什么影响都没概念。所以这篇会尽量把每一步背后的“为什么”讲透并给出可以直接复用的配置和流程。适合以下几类人想转AI工程但不知道从哪下手的开发、已经在用API但总觉得靠Prompt“撞运气”的初学者、做业务系统想引入AI能力但怕失控的技术负责人。2. 第一道门槛不是模型而是提示词工程的结构化2.1 提示词工程为什么值得当成代码来管很多人觉得提示词工程就是“话术写法”这低估了它。在我实际项目中提示词是最容易失控、最影响结果稳定性的环节。同一段Prompt换了模型版本可能表现差异很大同一份Prompt换一个用户案例可能从高精度跌到不可用。所以第一个习惯必须改把提示词当成代码管理做版本、做评审、做测试用例。我见过最普遍的问题就是“在聊天框里调出一个能用的Prompt然后直接复制到代码里”。这种玩法在小Demo里没问题但一旦进入生产环境模型升级一次业务就要跟着抖一下。更麻烦的是你根本说不清当前系统依赖的是Prompt里的哪些细节。2.2 结构化Prompt的四个基本部件我的经验是在生产系统里Prompt最好分成固定几块而不是一大段自然语言。我的模板是这样角色与能力边界告诉模型它是什么、擅长什么、不做什么。比如“你是电商客服助手只能基于给定的商品库和售后政策回答超出范围时给出转人工引导”。这能大幅减少它信口开河。任务描述明确输入是什么、要做什么动作、输出什么粒度。不要写“帮我分析评论”要写“对每条评论输出一段30字以内的摘要并按照情感倾向标记为正面/负面/中性”。约束与禁忌这是最容易被跳过的。比如“不得超过200字”“不允许编造订单数据”“当用户询问价格时引用价格表原始数字”。输出格式约定最好用JSON Schema或者XML结构便于程序解析。很多“模型回复没法用”的场景都是输出格式没约束好。上面每一块都用变量注入业务数据。换句话说Prompt里只有变量是动态的其余结构全部固定。这样我才能在不同场景之间快速复用也才能在模型异常时定位是哪一块出了问题。2.3 提示词也需要回归测试这是我最想强调的一点提示词是“有输入、有输出、可比较”的程序逻辑。我会给每个场景准备一份评测集大概几十到几百条真实输入并标注期望输出类型。每次改动Prompt之后批量跑一遍评测集看到关键指标变化后再决定是否上线。这比“感觉好很多”靠谱一万倍。例如做“商品评论情感分析”时我会准备一百条历史评论并标注正确的正面/负面/中性标签。模型升级或Prompt调整后统计准确率是否下降。如果出现回归我会用错误样本定位是“输出格式问题”还是“内容归纳问题”再针对性修改。这里有一个非常实际的建议建一个本地文件夹把每次Prompt版本、配套评测集、测试结果、模型版本号都存下来。你会发现AI工程的“可复现性”就是从这样一个简单习惯开始的。3. AI Agent从单一问答到自主执行任务中间隔着工程化思维3.1 Agent不是魔法而是四个部件的组合我特别烦市面上把AI Agent吹成“硅基生命”的话术。真正落地时Agent就是一个循环系统模型根据用户目标和当前状态决定下一步动作然后调用外部工具再根据工具结果继续推理直到任务完成。拆开看四个部件缺一不可大脑也就是大模型负责推理、分解任务、理解上下文。规划器决定“先做什么、后做什么、要不要换另一个方案”。这部分可以由模型承担也可以用工作流来固定。记忆短期记忆负责当前对话上下文长期记忆负责跨会话的用户偏好和历史结论。工具真正让Agent“能干实事”的部分包括检索数据库、调用内部API、执行代码、访问网页等。我在实际项目里发现很多人一开始就把精力花在搭建工具列表上买插件、接API很兴奋却忽略了“规划”才是真正影响任务成功率的关键。3.2 一个可复现的Agent设计案例自动售后处理我去年做过一个自动售后处理Agent任务并不复杂用户提交退款诉求时自动判断是否符合政策、计算可退金额、生成答复必要时转人工。为了让这个Agent稳定我只让模型做一件事——按固定流程“填空”第一步调用工具查询用户订单状态和商品信息。第二步调用售后政策匹配规则。第三步根据匹配结果生成答复文案。第四步如果政策无法覆盖标记为人工处理。流程固定后模型不需要“悟性”只需要每次完美执行这四个环节。我把工具接口做成标准的JSON调用模型每次输出一个动作指令代码解析后执行对应逻辑再把结果塞回上下文。整条链路跑下来成功率从依赖一次性大Prompt的不足六成提升到九成以上。这个案例很重要的一点是Agent每一步决策都被记录下来能追溯“它为什么决定这么干”。这对排障、审计、甚至后续优化都极其关键。3.3 Agent踩坑记录循环失控和上下文膨胀我踩过最大的坑是模型陷入死循环如果一个步骤执行失败它可以脑补“换个方式重试”但有时候它会伪造工具结果认为自己已经完成。所以我在工程设计上加了三个护栏执行次数上限无论任务多复杂单轮最多执行八步超过就主动询问用户或转人工。工具结果校验工具返回是代码解析的真实结果不是让模型复述“觉得自己调到了什么”。模型只能看到结果文本但不能决定结果内容。上下文窗口管理长期任务中模型上下文会越积越长不仅慢而且贵。我采用的做法是定期“总结中间结论”把旧细节压缩成摘要只有最近两步的完整记录保留在上下文里。这些护栏听起来不酷但没有它们Agent根本不敢放入生产。4. 模型选择与部署策略不是越大的模型越好而是越匹配越好4.1 先回答最经典的问题用API还是本地部署我接触的很多团队一上来就纠结“要不要自建模型”仿佛不私有化部署就不是AI工程。但我觉得这个问题没有标准答案需要结合数据敏感性、调用量、延迟要求和成本预算综合考虑。下面是我常用的对比维度维度API方式本地私有化部署启动速度开通即用需要GPU资源和部署调试时间单次调用成本按token计费主要由硬件折旧和电力构成数据隐私依赖服务商政策数据完全在内网闭环并发上限受厂商RPM/TPM限制可自主扩容受硬件约束维护成本极低需要持续跟进模型漏洞和版本延迟表现通常数十毫秒到数秒取决于显卡和模型大小可调优举个典型例子我做过一个内部文档问答系统数据包含大量内部经营数据管理层明确要求不能出内网那必须走本地部署。另一个内容生成的对外工具对数据敏感度不高而且调用量波动大高峰期靠API弹性更划算。4.2 本地部署时你最该关注的不是“跑起来”而是“跑得稳”很多人本地跑模型只关心“能不能加载”“回复对不对”但生产环境真正要关心的是三个指标上下文长度业务是否需要长文档解析如果要对几千行日志做分析模型最大上下文不够再好的能力也没用。量化等级常见有FP16、INT8、INT4粒度越小显存占用越低但精度会有损失。我的经验是对话类场景用INT8基本感知不到差距但复杂逻辑推理的Agent任务用FP16更稳。推理吞吐量并发请求上去后很容易出现队列堆积。单看首字延迟不够要看整体吞吐每秒处理多少token。批量并行处理类任务吞吐比单次快慢更重要。关于GPU选型我不建议新手一开始就上大显存卡。先用API验证业务再拿小模型试运行确定确实需要本地化时再投入硬件这个顺序最省钱。4.3 一个最小可用的私有化部署参考流程以7B级别模型为例我常用的部署方案如下准备一台至少有24GB显存的GPU机器推理框架我用vLLM因为它在高并发下能维持较高的吞吐率。模型权重用Hugging Face下载注意核对官方配置文件和tokenizer。启动服务时启用--max-model-len限制最大上下文长度避免极端请求直接耗尽显存崩溃。前端把并发请求控制在一个阈值内超过阈值的请求先排入队列。无论是哪种框架都要加上这套策略否则显卡会瞬间断电。写一个基本的故障监测脚本实时记录请求失败率和平均首字延迟。如果你只是想快速验证模型能力本地部署用ollama会更省事一条命令就能把模型拉起来但生产环境我还是建议vLLM这类框架它提供的监控接口和批处理能力是工程化必需的。5. 生产级AI应用的架构设计别再把LLM当“整个大脑”5.1 把工作流从Prompt里解放出来我的核心体会是能由代码和规则确定的事情不要让LLM用“推断”决定。比如判断一个用户输入是询价、投诉还是闲聊传统意图识别模型也可以做甚至简单的关键词规则就够。把这类判断交给LLM成本高且不稳定。我采用的方式是在LLM外面包一层“工作流编排层”。系统先根据业务规则判断该走哪条流水线LLM只负责流水线中真正需要语义理解的环节。比如发票审核系统中金额与合同的校验用规则代码只有“非格式字段是否有歧义”才交给模型判断。这个思路可以理解成把LLM当成一个能力超强的外包员工而不是CEO。它擅长阅读、归纳、改写、生成但不擅长严格按照事务逻辑一步步跟踪状态。事务状态必须由代码掌控。5.2 多模型协作比单个大模型更便宜的实战方案在很多业务里我们不需要一个巨型模型时刻在线。我在一个知识库问答项目中拆分了三条模型调用路径简单事实查询由一个小型模型处理速度快、成本低。复杂推理问答只有前一步判断问题较复杂时才升级到大模型。最终回答润色统一用中等模型把前两个模型的结果整理成用户可读的语言。这样多级协作不仅节约成本还能用“小模型兜底高频动作、大模型处理边缘case”的方式提高整体稳定度。注意这里的“协作”不是模型自主互相聊天而是由工作流代码主动调度这种可控的协作远比“让模型自主协作”可靠也不会陷入无休止的对话循环。5.3 数据回流AI工程里最容易被忽略的一环很多AI应用上线后就“静止”了。但AI系统的特点是用户真实需求永远比你预想得更复杂。所以我在每个AI服务里都会强制记录三类数据输入输出日志包括原始输入、模型回复、耗时和token用量用于排查问题和核算成本。用户反馈信号比如显式的点赞点踩、转载行为以及隐式的“用户是否重新提问”等信号。异常样本与失败样本超时、超预算、无法解析、被兜底规则接住的请求这些都是最有价值的优化矿藏。这些数据积累到一定量后就变成了我说过的评测集和微调候选集。有了它们AI应用才能持续演进。很多团队说“我们的AI越用越笨”大概率是因为没有做数据回流模型和Prompt停留在上线那一天。6. AI质量保障传统测试方法对LLM失效后的新套路6.1 为什么不能只靠断言判断模型回答对错传统软件测试可以轻松写“期望返回500实际返回500则通过”。但LLM的输出天然有随机性同一句话大概率每次答案不同只是意思相近。如果靠字符串比对所有用例都会挂。这时候换一个思路我们真正要验证的不是“输出了一样的字”而是“输出是否满足业务定义的语义要求”。我把质量评估拆成三层格式层输出的JSON是否合法字段是否齐全有没有HTML标签乱入。内容层关键要素是否正确比如抽取联系人电话号码是否精确匹配原文本。逻辑层回答是否自洽语气是否符合角色设定有没有超出知识边界瞎编。6.2 用评测集和LLM-as-Judge构建回归机制针对内容层和逻辑层我用的方法是“用LLM来评LLM”。给评测模型一套评分标准让它对回复逐项打分。这个过程可以做得很细例如设置“是否有事实性错误”“是否完整回应了用户痛点”“是否包含合理免责声明”等维度。实际操作时我会先准备一个三十到一百条的真实用户输入作为评测集每条输入提前写好“标注答案”或者“期望的回答要素”。然后每次模型版本或Prompt有变更就批量跑一遍观察整体得分变化。这个过程自动化后我可以放心进行模型升级试水再决定是否放量。6.3 生产兜底设计比让模型更聪明更有效再好的评测也不会覆盖所有线上情况所以必须给系统留“人类后门”。我用的兜底机制包括置信度阈值当评测模型或规则引擎判断当前回复与用户问题匹配度偏低时自动降级为人工回答模板。人工接管通道只要用户反馈“回答没用”超过一定次数对话自动转人工并携带完整上下文客服不需要用户复述。多模型投票对高风险、低频率但代价大的操作比如合同审查用两个不同模型分别出答案一致则通过不一致则人工复核。这组兜底机制的价值在于它承认了LLM会犯错这件事并把错误控制在业务可承受范围内。工程上这不是失败而是成熟。7. 写在最后关于“从零开始”的几句真心话我见过很多想进入AI工程方向的朋友最初都卡在“想一口吃成胖子”上想学全栈AI、掌握提示词、Agent、RAG、模型微调、部署运维结果一个月后还在收藏资料。我自己也走过这样的弯路。后来我的策略变了先找一个足够小、但能完整走完全流程的业务场景哪怕只是“文档问答助手”也要亲自把提示词、评测集、Agent流程、部署、日志、兜底全部走一遍。这样做完一个场景对AI工程的理解会比刷十篇教程都深刻。因为你会在真实过程中碰到token超限、并发拥塞、响应字段解析失败、模型一本正经胡说八道等一堆都在文档里读不到的问题。正是这些问题的解决方案构成了你“从零到一”的核心能力。最后分享一个我每次新项目都会用的时间分配一半精力花在业务理解和流程设计上三成花在数据准备和质量评估上只有两成花在写代码和调模型接口上。你会发现AI工程更像是一门“系统设计数据治理”的学科而不仅仅是“调AI”的学科。希望这篇能帮同行少走一点弯路也欢迎读到这里的你在实际项目中验证这些思路。