“ai-engineering-from-scratch”这个标题按我的理解不是指某个开源仓库也不是指一套教学课程而是“从零开始搭建一套AI工程实践体系”这件事本身。我手头正好在跑一个跨三四个业务线的内部AI项目这半年里踩过的坑、沉淀下来的方法跟这个标题完全对得上。如果你正打算把AI能力引入自己的工作流或者你所在的团队正准备把AI从一个“智能玩具”变成真正可交付、可维护、可度量的工程能力那这篇文章可以当成一份参考地图来看。我会把我实际用过的方案、写过的Prompt模板、搭过的评测流程和一些翻车现场尽量原原本本地写出来。1. 先想清楚AI工程的本质是什么1.1 工程化和“调用API”之间的鸿沟很多人第一次接触AI工程会觉得这事无非就是调接口——把用户的问题抛给大模型拿到结果返回给用户完事了。我一开始也这么想。直到我把第一个原型方案丢给业务方他们问三个问题我当场哑火“每次输出质量怎么保证”“模型升级了之后结果飘了怎么发现”“你那个Prompt到底是哪个版本在线上跑着”这三个问题恰恰是AI工程最核心的命题可重复、可度量、可维护。别小看这三个词。写一段能用的Prompt半小时就够搭建一套能让Prompt稳定产出、能被自动验证、能随模型迭代持续演进的工程体系可能需要两到三个月。这个差距就是“玩AI”和“做AI工程”的分水岭。生活化类比一下你请了一个非常有才华但有点健忘的实习生你得给他写操作手册、设质检节点、留变更记录才能放心让他独立干活。AI工程做的其实就是这样一套“管理机制”只不过对象不是人是模型和代码。1.2 把它落地成一套可运转的流水线我的经验是一个合格的AI工程实践体系至少应该包含五层需求层把业务问题翻译成模型能理解的指令、控制层决定模型什么时候用工具、走哪些分支逻辑、质检层验证输出是否符合预期、观测层记录每一次调用的链路和数据以及迭代层根据bad case持续优化提示词与流程。这五层不是按顺序搭建的更像是在同一张白纸上同时铺开。但有一个先后次序很重要先解决“怎么度量好坏”再动手优化。因为如果你连“什么算好”都没定义清楚后续做的每一次调整都是在盲改。我见过很多团队卡在这一步模型换了个参数感觉回答好像变好了但问好在哪里说不出来。没有度量就没有迭代没有迭代AI项目注定死在demo阶段。1.3 从零起步记住你是“一个人工程队”真正的from scratch不是指代码从零写起而是指你所在的环境可能一片空白没有专门的模型平台没有评测团队没有专门的算力资源。这种情况下我的建议非常朴素能用现成的就用现成的把精力省下来放到“编排”和“验证”上。我当前项目的起点其实特别简陋一张Excel表记录测试用例一个Python脚本批量调用模型接口再加上一个Git仓库管理所有Prompt和流程代码。就这么三样东西支撑起了后面所有复杂功能的迭代。先跑通再跑好这是所有AI工程实践的起跑线。2. 打好地基Prompt Engineering的工程化姿势2.1 从“写一段话”到“维护一套配置”绝大多数Prompt教程都在教你怎么“写”但工程上真正难的是怎么“管”。我维护的Prompt不是一段散装文本而是一个结构化的配置项。每个Prompt都有版本号、变更记录、测试结论和被哪些场景引用。这听起来繁琐但当你的Prompt数量超过30个之后没有这套管理线上出了问题你连回滚都不知道回滚到哪去。我常用的Prompt结构分为五块角色定义、任务目标、输入数据格式约定、输出格式约束、以及若干个“必须避免”的负面约束。角色定义不只是“你是一个助手”这种废话而是要定义这个角色掌握什么上下文、持有什么立场、擅长什么表达方式。任务目标要写清楚输入是什么、输出给谁用、用在哪里。负面约束通常是我在bad case中积累出来的比如“不要在回答中说‘根据我的理解’”这类约束越攒越有价值。2.2 一份可复用的Prompt模板实例下面是我目前在信息抽取类任务上稳定使用的一份模板去掉了业务敏感信息可以直接套用## Role 你是资深数据标注专家擅长从非结构化文本中提取结构化信息输出严格遵循JSON格式。 ## Task 输入是一段用户与客服的对话记录。请提取用户诉求、订单编号、情绪倾向positive/neutral/negative、是否提出赔偿要求。 ## Input {对话文本} ## Output Format 仅输出一个JSON对象不要包含任何解释性文案格式如下 {request: string, order_id: string, sentiment: string, claim: boolean} ## Constraints - 若文本中未出现订单编号order_id填unknown。 - sentiment仅识别明显情绪不要过度推断。 - 若用户未提出赔偿claim一律为false。 - 严禁添加对话中不存在的实体。这份模板看着平平无奇里面有几个细节值得注意。第一Output Format放在Constraints之前模型会优先关注输出格式后面再读约束条件来限制内容第二负面约束里写的是“严禁添加不存在的实体”而不是“请准确提取”——负面命令比正面命令在大模型上通常更有效第三每个字段都给了缺省值规则这能有效降低模型的自由发挥空间。2.3 为什么需要“评测集”和“双人复核”Prompt改动最怕的就是“拍脑袋”觉得New版本更顺眼就上线结果线上数据反而变差。我在每个Prompt旁边都固定挂一份评测集大概50到100条覆盖各种边界的输入改完Prompt先在这份评测集上批量跑一遍对比新旧版本的结构准确率、字段缺失率和Bad Case数量再决定要不要切流量。有人会觉得50条够吗说实话对于大多数内部场景50条精心挑选的边界case比500条随便抓的日志更有参考价值。边界case怎么挑翻历史日志里那些“离谱”的输出以及业务方反馈过的所有问题记录。这些东西才是评测集的真正身价所在。另外核心链路最好设置“双人复核”——一条请求打两次模型或者两个不同参数配置的模型有分歧时走兜底规则。这个方法能把错误率再往下压一个量级代价是成本翻倍值不值要看业务场景。至少金融、政务这类场景我强烈建议上双路比对。3. Agent实战从单次调用走向多步决策3.1 先设计工作流再谈Agent自由发挥我看过不少人做Agent上来就把一堆工具丢给模型让模型自己“规划”。结果没跑几步就失控模型开始调用不存在的工具、参数格式错乱、陷入重复循环。工程上我更推荐“半自主”的路线先把业务流程画清楚哪些步骤必须走固定逻辑哪些步骤可以由模型自由选择然后把它们组合成一个可编排的Structured Agent。上周我做了一个竞品信息汇总的功能工作流是这样设计的先由一个分类模型判断用户意图查询类/对比类/建议类再按类型走不同分支。查询类直接检索知识库后生成回复对比类先调用内部搜索工具拉取多条竞品信息再用一个独立的总结模型归纳差异点。这个流程里模型没有权限自己决定“要不要查一下别的”所有的路由都是我写死在代码里的。这大大降低了不可控性也更容易定位问题。3.2 Agent循环的“方向盘”和“刹车片”Agent运行时的两个关键控制点是工具选择约束和循环上限。工具选择约束指的是在每一轮模型调用前你要用代码过滤掉当前状态下不应当出现的工具而不是把所有工具都摆上去让模型挑。这一步能砍掉一大半“乱调工具”的问题。循环上限我一般设置成3到5轮并且只在必要场景放开。记忆里有个惨痛教训第一个Agent原型没设循环上限模型在某个分支上反复调用信息查询工具把几百次请求打出去了账单直接爆炸而且返回结果全是重复内容。后来我加了两道保险单次调用全局轮数上限以及相邻两轮输出完全相同时强制终止。另外Agent的中间思考过程一定要落日志哪怕不展示给用户。排查问题的时候没有中间日志的Agent就是一个全黑的黑盒你只能瞎猜。3.3 工具的定义比你想象的更重要工具能不能被模型正确使用很大程度上取决于工具描述写得清不清楚。别小看这个。我原先写的工具描述就一句话“查询用户订单信息。”结果模型经常传错参数或者在不该调用的地方调用了。后来我把描述改成下面这样工具名称: query_user_order 用途: 查询当前会话用户的历史订单信息。仅当用户明确提到“订单”“购买记录”“买了什么”等词时使用。 参数说明: - user_id: 字符串从session上下文中获取禁止使用示例值。 - page: 整数默认0每页最多20条。 返回值: JSON数组包含订单号、商品名、金额、下单时间。 注意事项: - 不要连续重复调用本工具上一次结果若无异常应基于其结果继续作答。 - 查询失败时返回空数组不要伪造订单内容。改完之后调用准确率从70%出头直接升到90%以上。本质原因不是模型变聪明了而是我把“什么时候用什么、参数怎么填、失败怎么办”这些原本要靠模型猜的信息全部显性化了。给模型写的工具说明务必要以“一个不看代码的人如何正确使用它”为标准来写这个标准我一直沿用到现在。4. 用AI做工程编程与测试的落地姿势4.1 AI辅助开发的正确打开方式AI编程这两年特别热但很多人用AI写代码的效率并不高原因在于直接把需求丢给工具让它“生成一个完整模块”——需求边界不清晰时AI产出的代码往往看着完整实则一堆隐含假设。我总结下来AI辅助开发效率最高的工作流不是“帮我写代码”而是“帮我完成已经被拆解清楚的任务单元”。举个实际例子。我需要给数据清洗模块增加一个新功能自动识别时间格式并做归一化。我没有让AI一次性写整个模块而是先自己列出了任务列表识别常见时间格式、定义归一化输出标准、处理无法解析的情况、补充单元测试。然后一项一项交给AI实现每完成一项我立刻Review并跑测试通过后再进下一项。这种方式看似多花了交互成本但每一步都清晰可控最终代码质量明显比一次生成高得多。拆解任务这个动作本质上是把“模糊的意图”变成“精确的指令”这是AI编程最核心的杠杆点。4.2 AI应用的测试传统方法不够用了传统软件测试的核心是断言给定输入期望输出等于预期值。但大模型是概率系统同一个Prompt同一输入两次输出可能完全不一样。这就意味着AI应用测试必须分层设计。我目前的测试体系三层第一层是结构化校验检查输出JSON格式、字段完整度、枚举值合法性这层用普通代码就能做到第二层是黄金样本回归维护一批标准输入和预期输出每次模型或Prompt变更后批量跑一遍人工比对差异并在评测集中记录第三层是LLM-as-Judge用一个大模型去评估另一个大模型的输出质量通常从相关性、完整性、安全性、忠实度四个维度打分。这层有争议但实际用下来配合好评估标准定义能自动化筛掉大部分低质量变更。4.3 探索性测试路径和自动化工具AI应用还有个非常灵验的测试方法我称之为“对抗性探索”把自己想象成一个故意刁难的用户输入一些模棱两可、包含错别字、信息缺失甚至带恶意诱导的内容观察系统如何反应。这类case是评测集里最有价值的部分之一因为它们最能暴露系统边界。自动化工具方面我目前用得最顺手的是自建的一个评测脚本集合一个Python脚本读取CSV格式的测试用例文件循环调用模型接口把结果写回另一个CSV再用规则脚本自动打标。整体流程不到两百行代码但已经是整个AI工程体系的“质检关闸”。别一上来就想着上重型测试平台先把手动的评测集跑自动化再逐步加复杂度这个路径最稳。5. 评测驱动没有指标的AI工程都是耍流氓5.1 先把“好”的标准写在纸上我见过太多AI项目死在“感觉不错”四个字上。业务方说感觉不错开发也感觉不错但等模型升级或者换了Prompt之后没人知道为什么输出变了更没人能阻止它变坏。要打破这个局面唯一的方法就是在动手写第一行Prompt之前先定义好评估指标。对于大多数文本生成场景我推荐从四个维度定义准确性事实和逻辑是否与参考一致、完整性是否覆盖所有用户问题点、合规性是否包含敏感/不适当内容、表达质量是否流畅、是否答非所问。每个维度可以按1到5分打分也可以简化成“通过/不通过”。关键不在于指标多精致而是大家看到同一个case时能达成一致的评分结论。评分标准不一致的时候就需要细化描述比如“准确性1分答案中至少有1处直接与参考事实冲突”。5.2 基线、阈值和胜利的定义评测不是拿一次结果刷个分就算完。我的迭代节奏是先锁定一个“基线版本”当前线上使用的模型版本Prompt版本把它在评测集上的得分记作基线分。后续任何改动都必须在同一份评测集上跑要求是总分不能低于基线且核心维度不能有明显下降。只有同时满足这两个条件改动才会被允许上线。阈值怎么定我的经验是不要定得太理想。一个比较务实的做法是先跑三次基线取中间值作为基准分然后设一个浮动范围。比如基线准确率是92%我允许新版本在90%到94%之间波动一旦超过这个范围必须停下来分析原因而不是一刀切地“必须超过基线”。这里有一个很容易被忽略的细节每次跑评测集模型温度参数必须保持一致否则结果波动会让对比失去意义。5.3 一个可抄作业的评分脚本方案分享一个简易可用的评测数据处理思路。我给每条测试用例配置了三个字段输入、预期结果摘要、关键实体列表。模型产出后脚本自动做三件事第一检查输出JSON格式是否合法第二检查关键实体是否全部出现第三按编辑距离或关键词匹配打一个粗略相关性分。这个过程没法做到100%准确但能在人工介入前先自动筛掉明显不合格的输出把人工从几十条case里解放出来只看少数可疑项。脚本结构大致是读CSV、逐行调用模型、结果写入结果表、跑三类自动检查、输出汇总报告。整个脚本量不大几百行足够。等业务规模大了再考虑引入向量化相似度评估或者专用评估模型初期不需要那些花架子。6. 避坑实录我踩过的7个典型问题6.1 Prompt越写越长效果反而变差不是所有信息都对模型有帮助。我一开始总想把所有约束、背景、示例全塞进去结果Prompt超过两千字后模型开始抓不住重点或者过度关注尾部的示例。后来我养成了一个习惯每次Prompt改动后做一次“逐段删减测试”——删掉一段内容在评测集上跑一次如果分数没降甚至升了这段就永久删除。实测下来我的线上Prompt普遍比最初版本精简了40%到60%效果反而更稳定。6.2 RAG检索结果太碎模型输出成了“缝合怪”接入知识库之后最明显的问题是检索回来的切片经常是断章取义的片段模型把几段不相关的内容硬拼在一起输出看似有理有据实际满是逻辑漏洞。后来我调整了切片策略按语义完整段落切分而不是按固定字数硬切同时对检索结果做了相关性阈值过滤低于阈值的段落不送入模型。这两个小改动直接让输出质量上了一个台阶。6.3 Agent陷入死循环打爆了接口账单前文提过没设循环上限的Agent原型几百次请求直接打没了。这件事之后我给所有Agent都加了硬性轮数上限并且每轮之间做去重检查。还有一个隐性风险Agent在调用外部API失败时会“坚持不懈”地重试而API超时时间设置得过长的话用户端会直接卡死。我的处理是所有外部调用统一设置短超时默认3秒失败后最多自动重试1次再失败就交给兜底策略。6.4 测试过了线上却是另外一副面孔评测集里的case跑得好好的线上用户一用就出问题。排查下来发现线上真实输入和评测集输入的分布差异巨大评测集里的输入大多是规则完整的句子线上却是一堆口语化、带错别字、夹杂表情符号的碎片文本。这个问题的解法说来也简单评测集要优先收集线上真实日志而不是自己编的“理想输入”。我花了一周时间把线上两周的日志清洗后按场景分桶随机抽样补进评测集之后再改动Prompt线上效果的稳定性肉眼可见地提升了。6.5 被“高分”迷惑忘记了业务真实体验有一个阶段我的评测集准确率刷到了96%但业务方反馈依然觉得“不好用”。后来和业务方深聊才知道他们真正在意的不是信息全不全而是回复的语气是否礼貌、是否像真人、是否给了明确的可操作建议。这些维度我原先的评测集根本没覆盖。这件事让我意识到评测指标必须和业务方一起定义不能光盯着技术指标自嗨。6.6 模型版本升级老Prompt开始“犯病”基础模型做了一次版本升级后线上准确率骤降了五个百分点。查了半天发现新版模型对指令的响应风格变了我的Prompt里原有的几个负面约束反而被理解成了过度约束导致模型不敢正常发挥。这个教训的解法就是每次底层模型升级必须在评测集上全量回归不能默认“升级就是变好”。升级之后还要重新评估Prompt是否需要微调这个成本省不掉。6.7 多人协作改Prompt线上配置乱了套当团队里不止一个人维护Prompt时版本管理就成了事故高发区。我经历过一次线上使用了错误版本的Prompt排查了三天才发现是某次覆盖操作导致配置回退。后来我规定Prompt的每一次变更都必须走代码仓库的Merge Request流程并且绑定对应的评测集跑分记录。谁改的、为什么改、改了之后分数变化如何全部留痕。从那以后这类事故再没发生过。7. 小团队的实战起点你不需要重型平台很多人觉得AI工程是件很“重”的事需要专门的基础设施、平台和团队。以我的经验来看小团队甚至个人开发者用最简单的三件套就能起步一个Git仓库管理Prompt、评测集和处理脚本一个定时任务晚上自动跑一遍评测集输出一份回归报告一个共享文档记录bad case和优化思路。这三样东西的成本几乎为零但已经能解决AI工程里最痛的几个问题。等这套模式跑通之后再逐步加东西请求链路日志、线上流量的采样分析、更智能的自动评测模型。别一上来就追求完美AI工程和传统软件工程一样是逐步演进出来的不是一步到位设计出来的。我自己就是从一张Excel表起步的现在回头看当初最笨的办法反而帮我建立了最扎实的反馈闭环。8. 再聊几句实在话写到最后说点这半年最深的感受。AI工程和别的软件开发有一个本质区别传统软件的逻辑是人写的所以你理解每一行代码的含义AI应用的行为是模型涌现出来的你只能间接地通过Prompt、数据和流程去引导它。这导致AI工程天然需要更强的实证精神——任何一次改动不管感觉多么“对”最终都要靠评测数据来说话。再分享一个百试不爽的小技巧在开始任何AI工程优化之前先把你最不满意的10个bad case打印出来钉在工位上。每次想“优化”的时候先回答一个问题这次改动能不能至少改善其中3个case同时不弄坏另外7个能就动手不能就再想想。这个简单的强制问答替我省掉了无数无效的调参时间。AI engineering from scratch本质上就是把“不确定”变成“可控”的过程。这条路没有捷径但每一步走扎实了后面就会越来越顺。希望这篇实践笔记能给你搭好第一级台阶。