1. 先理解“AI工程”到底在做什么拿到“ai-engineering-from-scratch”这个题目我第一反应是现在市面上太多人把“调一个API、写一段提示词、跑通一个Demo”误当成AI工程了。从零开始做AI工程首先要纠正的就是这个认知偏差。我理解的AI工程是一套把模型能力稳定落地的系统方法。它包含数据怎么准备、模型怎么选、提示词怎么管、Agent怎么编排、效果怎么评估、线上怎么监控、成本怎么控制。关键词是“稳定”不是“跑通一次”。跑通一次只需运气稳定输出需要工程。这几年我带过不少从算法、后端、测试转过来的朋友也带过完全零基础的新人。我发现起点差不多的两个人半年后差距可以拉得非常大。差别不在谁更聪明而是谁把AI当成“工程问题”来处理而不是当成“魔法问题”来碰运气。一个把提示词当一次性试验品一个把提示词当成需要版本管理、回归测试、线上监控的软件资产一个让Agent自己瞎跑一个从第一步就给Agent设计状态机和护栏。结果自然天差地别。这篇文章我想把从零开始做AI工程的那条主线完整讲一遍。适合两类人一是刚入行、想系统建立AI工程能力的新人二是已经做过一些AI项目、但总觉得效果不稳定、想补齐工程短板的后端或算法同学。我不讲天花乱坠的架构只讲我实际落地验证过的思路、步骤和坑。2. 第一步不是写Prompt而是把最小闭环跑通很多人犯的错是项目一启动就扎进Prompt调参调了三个小时看起来不错然后发现数据格式不对、模型接口限流、输出解析不了整体又要返工。正确做法是先跑通一个最小的完整链路哪怕做得烂也要先打通。2.1 先定“输入什么、输出什么、由谁调用”开始写任何代码之前我会先画一个最简单的手绘链路通常是这样的输入数据 → 模型调用 → 输出解析 → 结果校验 → 存储/返回这个链路里的每一环都值得早期跑一遍。比如你要做一个文档摘要工具输入是PDF或网页正文输出是Markdown格式的摘要。那么先把“取出文本—送进模型—拿回结果—解析结果”跑通哪怕摘要质量一般链路通了才是地基。我处理这个问题时会做一个很小的demo工程目录大概是input/放原始样本output/放模型输出和解析结果main.py主流程config.py模型参数配置test_samples/固定评测样本这里有个细节模型调用的输入输出要尽早“固定成数据结构”。不要直接用裸字符串到处传否则后面做评估、做缓存、做重试时会非常痛苦。我会用TypedDict或者Pydantic定义输入输出结构哪怕现在只有两三个字段也把结构立住。2.2 模型选型不要迷信“最强”要迷信“最稳”从零开始的新手常犯的第二个错是直接上最强模型。模型强没错但成本和延迟也高而且很多场景用中等模型就够了。我自己的选型顺序是先确定任务复杂度。是简单的抽取、分类还是复杂的推理、多步决策准备20条代表性样本跑两三个候选模型做对比。不看单条效果看稳定性和错误类型。再看延迟、成本、限流。很多场景下“稍微弱一点但快和便宜”的模型是更好的工程选择。最后才锁默认模型并把模型名写进配置不要散落在代码里。推荐一个稳妥的组合思路核心推理用强模型简单任务用弱模型两者之间用路由规则连接。这个我在后面的Agent章节会再展开。2.3 固定随机性从“靠运气”到“靠参数”第一次跑通链路后很多人的代码有个通病同样的输入运行两次结果不一样。这在实验阶段没关系但一旦进入工程阶段就麻烦因为你会分不清“返回结果变了”到底是代码改动了还是模型随机性导致的。我现在写模型调用代码时会注意这几个参数temperature决定随机性。抽取、分类、格式化输出我一般设 0 到 0.3创意写作才设到 0.7 以上。max_tokens/max_output_tokens必须设上限否则长输出会无限消耗预算。seed部分模型支持相同seed加上相同输入能得到更稳定的结果在测试阶段很好用。output_format/response_format支持JSON模式就尽早用能省掉很多解析错误。工程经验原语先求稳再求好。模型调用代码先固定temperature为低档等业务效果不满意时再往高调而不是反过来从高往下调。3. 提示词工程把玄学变成可管理的技术我见过最多的高光与翻车都发生在提示词环节。一个优秀的提示词确实能让模型能力提升一个档次但只靠“写得好”解决不了工程问题。提示词必须能版本管理、能测试、能回滚。3.1 从散文到结构化提示词的三段式骨架早期我写提示词是写散文效果随缘。后来总结经验一套稳定提示词通常包含三个部分缺一不可。第一部分是角色与目标。告诉模型“你是谁、要完成什么”。不要只写“你是一个助手”要写清楚任务的边界和服务对象。举例我需要一个“能够从客服对话中抽取用户情绪标签并给出摘要的系统”而不是“分析这段对话”。第二部分是上下文与约束。把输入内容、格式要求、禁忌项都写清楚。例如对于抽取任务写明“只输出JSON不要输出任何解释性文字”。约束越明确解析越省心。第三部分是输入与示例。给模型提供结构化入口并附上一两个“输入—输出对”作为示例。少样本示例的位置和数量本身就需要作为实验变量来对待不是塞得越多越好。结构化的好处是改版时可以很快定位是角色定义的问题、约束的问题还是示例的问题。散文式提示词一改就是整段重写没法精细化迭代。3.2 提示词的版本控制怎么落地我在实践里把提示词当作代码一样管理配置仓库里存放的是一个“提示词模板”不是最终拼好的字符串。模板使用变量占位例如SYSTEM_PROMPT 你是一个{role}你的任务是{task}。 约束条件 1. {constraint_1} 2. {constraint_2} 输入内容 {input} 请直接输出结果不要输出多余解释。 每次修改提示词我会附上变更说明并在测试样本集上跑一遍回归。这里的核心动作是“改动前后必须可对比”。如果不做回归测试你根本不知道一次Prompt改动是提升了还是回退了。另外我强烈建议把“提示词V1.0”这类命名方式彻底换成 Git 思路每次改动留下diff记录配合测试样本集。理由很简单模型版本会升级、业务需求会变但历史提示词为何那样写、当时规避了什么问题必须保留可追溯记录。否则三个月后改回来又踩同一坑。3.3 不知道怎么写从“追查错误”反推提示词经常有朋友问我我不是很会写提示词有什么套路我的答案是先不看提示词写得漂不漂亮先看模型回答的错误类型。错误是格式问题就在提示词里加格式约束错误是逻辑问题就加思维链或分步骤指令错误是理解偏差就增加示例。用这种方法提示词工程就不是玄学而是一套以错误驱动迭代的工程方法。4. Agent化从单轮问答演进到多步自治系统当链路跑通、提示词稳定之后就会遇到更高阶的问题单轮问答满足不了业务需求了。你需要让AI自主完成多步任务比如查资料、算数据、调接口、综合判断。这就是Agent的用武之地。4.1 最小闭环的ReAct模式最简单的Agent骨架可以理解为一种循环思考Thought→ 行动Action→ 观察Observation→ 再思考。实现上我先画出Agent的状态集合idle空闲等待任务thinking模型正在规划下一步tool_calling正在调用某个工具tool_result拿到工具返回结果done任务完成error任务失败需要人工介入每个状态对应一个处理函数状态之间通过事件驱动。很多Agent“跑飞”的根本原因就是没有状态机概念模型想干什么就干什么最后逻辑乱成一团。def agent_loop(task: str, max_iterations: int 10): state idle context [] for _ in range(max_iterations): context.append({role: user, content: format_task(state, task)}) response call_model(context) action parse_action(response) if action[type] finish: return action[answer] elif action[type] tool: result call_tool(action[tool_name], action[arguments]) context.append({role: tool, content: result}) state tool_result else: state error raise AgentLoopError(max iterations exceeded)我设置max_iterations上限的初衷很简单没有上限的循环既烧钱又可能失控。同时要考虑工具调用频率限制必要时在工具层做节流和超时。这个就是“护栏”的最基本形态。4.2 多Agent协作该分工时再分工很多人一听“多Agent”就很兴奋觉得让几个AI吵来吵去会碰撞出火花。我的经验是多Agent协作的结构好坏远远重要过数量多少。最常用的结构是“规划者—执行者—审核者”三角色。规划者拆任务执行者调用工具实现子任务审核者检查最终结果质量。这个结构天然适合“写代码—跑测试—CodeReview”这类工作流。Harness Engineering这类概念实践换个角度看其实也是在强调“用结构化流程约束AI逐环节干活”。多Agent协作的三个工程要点信息传递必须有明确格式。不要Agent间传散文要传结构化对象任务ID、输入参数、预期输出、依赖关系。每个Agent只做一件事。不要一个Agent既规划又执行又审核任务边界模糊是混乱之源。失败要能向上抛。执行者失败时规划者要能根据错误信息重新规划而不是把错误堆在上下文里继续往下走。上下文长度是Agent开发中最容易被低估的瓶颈。Agent越跑上下文越长噪音越多最终表现为“答非所问”。我的应对策略是定期压缩历史保留结论性摘要而不是完整过程建立“记忆库”保存关键结论下次直接从记忆库恢复现场。4.3 工具调用是最需要打磨的接口Agent再好落地时总要落到工具上。我开发的经验是工具设计必须做到名称清晰、参数说明完整、返回结果结构化、超时可控。一个反例是早期我给Agent写了个“获取天气”的工具参数只写了城市结果模型传了个“上海浦东新区”工具解析不了后来把参数改成“城市名例如北京、上海”错误率立刻下降。模型极度依赖工具描述里的“上下文提示”所以工具描述要写得像给机器人看的产品说明书。另一个重要机制是“工具结果的预清洗”。不要直接把工具原始结果全部塞给模型先截断、改格式、剔除敏感字段。否则一个超长网页内容可能直接把上下文打爆。5. 评估、测试与监控AI工程的定盘星不夸张地说评估环节决定了一个AI项目能否长期跑下去。没有评估体系的AI工程和开盲盒区别不大。5.1 离线评估集怎么搭建离线评估集是AI工程质量的生命线。我的建议是这件事从项目第一天就开始攒不要等项目做完了再补。评估集结构可以包括样本类型作用占比建议标准样本覆盖业务主流程的典型用例50%-60%边界样本输入为空、超长、格式异常等20%对抗样本意图模糊、包含误导信息10%-20%回归样本历史上修复过的Bad Case作为回归补充每天我会把线上反馈中暴露的问题加入评估集。加入的规则是这条Case必须能复现且单靠提示词修改无法快速解决时才进入评估集避免评估集变成垃圾场。5.2 评估指标怎么选不同任务适合不同指标我的选择矩阵大致如下分类/抽取任务准确率、精确率、召回率、F1。摘要/生成类任务人工打分为主辅助用ROUGE、BLEU做参考但别迷信。检索增强任务召回率、命中率、排序指标。Agent任务任务完成率、平均步数、工具调用成功率、人工审核通过率。有一点要特别强调AI测试开发不是“跑通就行”。我在线上监控里最看重的是“成功率变化趋势”和“成本曲线”这两个指标比任何单条case的对话效果都更能反映健康度。建设一套AI系统的监控初期只盯四个数字是有很强代表性的请求量平均响应延迟输出成功率模型返回、解析通过的比例单位请求成本这四个数字稳定了再往上加业务指标用户满意度、留存、转化才靠谱。5.3 回归测试每次改动都要过一遍有了评估集之后我会把回归测试跑在每次改动前。做法不复杂先跑旧版本记录结果。再跑新版本记录结果。自动比对关键指标低于阈值的直接拦截。回归测试建议做成一条命令可以执行的任务最好加入CI流程中。如果项目没有CI至少在发布前手动跑完这一条命令并保存结果截图。这个东西是后期省时间最划算的投入。6. 常见问题与排雷实录最后分享一些实际踩过的坑都是项目里反复出现的类型。6.1 感觉模型效果“不稳定”怎么办“不稳定”通常有三种来源模型版本变了。同一家API上游模型悄悄升级后行为出现变化。解决方法是锁定模型版本号并在提示词变更时同步记录模型版本。输入数据变了。线上数据分布与训练时差异大导致表现下降。解决方法是定期抽检线上输入样本更新评估集。参数设置不当。temperature设高了业务结果自然飘。解决方法是先固定低温和seed排查。6.2 模型输出解析失败是模型的问题还是我的问题大多数情况是“你的问题”。检查顺序如下提示词里是否明确要求了输出格式是否启用了JSON模式等结构化输出支持输出中是否包含多余标记例如代码块包裹解析容错是否考虑了字段缺失有没有设置重试机制我自己的兜底方案是“两步解析法”第一步尝试结构化输出解析解析失败后调用一个修复模型对原始输出做规范化再解析。代价稍高但成功率明显上升适合重要链路使用。6.3 成本居高不下怎么控制成本控制的核心是分级使用模型。简单任务用轻量模型复杂任务才走强模型。在代码层面我会埋设一些日志点记录每个请求的模型名、token数和耗时每周复盘一次。发现某个环节高频调用强模型后我会尝试用弱模型先过滤只把置信度低的样本升级给强模型这是成本控制最有效的实践之一。6.4 哪些知识是“从零开始”最该补的如果你问我“从零开始做AI工程”最该补哪些基础知识我的清单是大模型基础原理至少知道token是什么、上下文窗口如何影响任务设计。Python数据操作dict、list、JSON解析这类基本功必须熟练。API调用与异常处理重试、超时、限流是每个AI工程人每天面对的事。数据结构化设计输入输出都要结构化这是工程稳定性的根基。基础测试理念评估集、回归、人工审核这些概念比具体框架更重要。至于框架和工具一个月换一个都很正常但上面这些底层能力是长期有用的。写在最后的一点个人体会我至今还记得自己踩过最狠的一次坑一个看起来完成度很高的RAG项目上线三天后回答质量断崖式下跌当时所有人都怀疑是提示词出了问题查了很久才发现是上游文档库的版本更新导致部分文本变成乱码。那之后我把“输入数据变更”列进监控项评估集里也专门加了“乱码输入”的对抗样本。做AI工程时间越长我越觉得它不像“写魔法”更像“调理流水线”。流水线稳不稳不取决于某一个环节多炫而取决于每个环节有没有明确的输入输出、有没有质量检测、有没有异常处理。特征漂移、数据质量、成本核算、回归测试这些看起来不够“AI”的东西反而决定了AI能不能真正为业务创造价值。最后分享一个自己的小习惯每当新需求过来我会先问三个问题——输入稳定吗输出可验证吗失败可恢复吗三个问题都能给出明确答案的项目通常都做得比较稳。如果哪个答不上来就先把这个洞补上再谈效果优化。