不知道你有没有过这样的阶段拿到一个AI相关需求脑子里全是大模型、Agent、多模态这些发光的词结果一开工就被实际问题按在地上反复摩擦。我自己就是从一个完全不会做AI工程的普通开发者靠一个个项目硬啃过来的。这篇博文想聊的就是ai engineering from scratch——从零开始做AI工程这件事。它不是什么理论科普而是我这几年踩坑踩出来的完整路径怎么搭第一条能跑的AI管线、怎么把Prompt调教成可用状态、Agent到底该放权到什么程度、上线前哪些坑必须提前填。适合两类人看一是刚转AI方向、手里有模型能力但不知道怎么落地的工程师二是demo能跑、一上线就崩每天都在效果不行里打转的团队。看了这篇文章至少你能知道下一步该干什么。1. AI工程和传统软件工程本质上是两种搞法1.1 确定性消失之后研发流程得反着来传统软件工程里有一条铁律同一个输入代码跑一百次就必须是一百个相同的结果。需求拆解、接口设计、提测、上线每一步都有明确的完成标准。Bug是可复现的根因是可定位的改动是可预期回归的。AI工程打破了这个铁律。模型是概率系统同样的Prompt今天跑和昨天跑结果可能有细微差别换一个模型版本行为可能直接大变样。在这个前提下你没法像管传统项目一样管AI项目——开发完成了这个状态在AI项目里其实不存在因为效果永远有提升空间行为永远有不确定性。我见过太多团队用传统思路做AI定了需求、排了期、写了厚厚的验收文档结果开发阶段一切正常模型效果一测不达标整个组都不知道该怪谁。问题就出在流程上。传统开发是编码-编译-部署AI开发是数据-实验-评估-再实验你要在一条本来就充满不确定性的路上反复验证。谁先接受这个事实谁就能少走一大半弯路。1.2 我的第一个AI项目翻车复盘刚接手第一个AI项目时我的想法特别天真把模型API接进来写几段Prompt再包一层接口完事了。结果不到两周就被现实教育了。我做的是一套智能问答系统用户问业务问题系统调用模型回答。一开始没有评估集我只靠个人感觉调Prompt调了一个多星期自己问来问去觉得挺好的。上线第一天就出事了。用户问你们这个产品多少钱系统一本正经地编了一个价格——编得还挺像。用户接着追问它又编了一个完全不同的版本。幻觉问题直接击穿了用户信任当天就被投诉了。复盘下来我犯了三个基础错误。第一我没有定义清楚什么算回答正确——没有标准答案自然没法评估好坏。第二我没有设计兜底机制——明知道模型会有幻觉可能却没有加一层事实校验或者不确定就承认不知道的Prompt防线。第三我没有做回归——改一版Prompt可能旧问题又冒出来了根本不知道。这三个错误看起来低级但后来我接触了不少AI项目发现大家踩的坑惊人地一致。核心原因都一样脑子还停在写代码实现功能的惯性里忘了AI系统需要围绕效果、不确定性、持续迭代来设计。1.3 想通这三件事后面的路才能走顺第一个项目翻车后我花了很多时间研究AI工程的底层逻辑最后沉淀出三条我认为最重要的认知。第一模型是不确定系统你要为不确定性做设计。这不是让你去追求确定性而是要让系统在不确定中依然可靠。怎么做到靠校验、兜底、回退、人工审核这些机制兜住风险的底线。第二评估不是测试的替代品而是整个AI工程的第一公民。没有评估集你说模型效果不错就是自嗨。有了评估集你说这版比上版提升了5个点大家才有共同语言。第三一次性把端到端跑通比单个环节做到极致重要得多。很多人喜欢在数据清洗环节死磕两周或者在Prompt上打磨一个月结果整条链路跑不通。正确做法是先搭一个能用但糙的完整闭环让数据从输入流到输出再逐步迭代每一环。这三条认知构成了我做AI工程的基本框架后面所有方法都是在这个框架上长出来的。2. 从零搭建AI工程的最小可行闭环2.1 技术选型别一上来就上全家桶动手做AI工程第一件事不是选模型而是确定技术边界。我见过太多人一上来就想自己部署大模型理由是数据安全自主可控结果光显卡运维就把团队拖垮了。我整理过一份选型对比基本能覆盖大部分场景方案成本运维复杂度效果上限适用场景托管API按量付费低高绝大多数业务快速验证阶段开源模型自部署硬件成本高高中高数据敏感、需要深度定制开源模型API第三方较低中中预算有限、效果要求中等我的建议非常明确除非你有合规硬要求或者数据绝对不能出域否则一律先用托管API起步。为什么因为AI工程前期的核心矛盾是验证业务效果而不是解决基础设施。等你在托管API上把链路跑通、把ROI算清楚再决定要不要自部署完全来得及。还有一个容易被忽略的点向量数据库也别一开始就上重型的。如果你的场景是几千条文档一个轻量的向量检索方案完全够用等数据量真的涨到百万级再迁移到专用数据库。先轻后重永远是最省力的路线。2.2 五分钟跑通一条AI管线我每次启动新项目第一件事永远是搭一条最简管线无论业务多复杂管线骨架基本不变。它的核心就是五个环节输入规范化把用户输入统一成结构化的请求去掉噪音、补全缺失信息检索与上下文组织如果需要RAG从知识库找回相关片段按顺序拼装成上下文调用模型构造好Prompt和参数调用模型接口拿到生成结果输出校验与清洗做格式校验、敏感词过滤、关键信息检查返回结果把结构化的响应返回给上层业务用Python伪代码表示大概是这个感觉def run_ai_pipeline(user_input: str) - dict: # 1. 输入规范化 normalized normalize_input(user_input) # 2. 检索RAG场景 context retrieve_context(normalized, top_k5) # 3. 组装Prompt prompt build_prompt(normalized, context) # 4. 调用模型温度设低一点保证输出更稳 response call_llm(prompt, temperature0.2) # 5. 输出清洗校验关键字段 cleaned validate_and_clean(response) return cleaned你可能会说这太简单了。但我要说的是这套管线就是AI工程的原子结构所有复杂系统都是它的变体。把这一层跑通你才拥有一个可以讨论、可以优化、可以加策略的底座。这里有个我踩过的坑很多人会把步骤2和步骤3混在一起直接把检索结果丢给模型不做组织。结果模型抓不住重点输出质量飘忽不定。上下文组织其实很有讲究——检索回来的片段要按相关性排序、要加源标签甚至要控制总长度这些都会直接影响效果。2.3 评估集才是AI工程的第一块地基如果有人问我AI工程里最值得投入时间的事情是什么我会回答搭评估集。没有之一。我见过太多效果时好时坏的项目根子都在于没有一套固定的评估集。你用感觉调Prompt效果当然像过山车。搭评估集的方法不复杂但需要一点纪律收集50到100条真实用户问题不要自己编用线上真实数据每一条都标注预期行为——标准答案或者判断准则分成两组开发集用来迭代测试集用来验证避免过拟合到开发集每次改完Prompt或调整管线跑一遍完整评估记录分数变化我习惯用一个简单的评估表来管理问题ID用户输入预期行为实际输出判定Q001你们产品多少钱引导用户查看官网定价页直接说出一个虚构价格失败Q002我订单没收到怎么办引导用户提供订单号先安抚并索要订单号通过有了这张表你说这版效果更好了才站得住脚——好在哪里、好多少一目了然。而且评估集要持续扩充每周把线上收集到的badcase回流进去防止系统在迭代中越来越偏离真实场景。3. Prompt Engineering和Agent从调提示词到设计系统3.1 把Prompt当代码管不然后面全是坑很多开发者对Prompt的态度还停留在在代码里写一句话。我见过最离谱的案例团队把超长的业务Prompt硬编码在源代码里想改一个语气词都要发一次版。这完全是把自己往坑里带。Prompt是会持续演化的资产它值得被当代码一样管理。我的习惯是Prompt模板单独成文件不做字符串拼接式的散落管理每个Prompt都有版本号记录迭代历史每个Prompt都要写清楚它的目标、适用场景、已知边界每一次Prompt变更必须跑一遍评估集再决定是否上线举个例子我常用的客服场景Prompt模板会长这样你是一名电商客服助手负责回答用户关于订单、物流、售后的问题。 约束 - 只基于提供的上下文回答不编造事实 - 如果上下文里没有答案明确告诉用户需要核实后回复 - 回答控制在200字以内语气友好专业 参考示例 用户我的东西什么时候到 助手您好请提供一下订单号我帮您查询物流信息。 上下文 {context} 用户问题{user_input} 回答为什么我要在Prompt里设置参考示例因为few-shot示例对模型行为的约束力比你在角落里写一万遍你要友好都管用。这算是我调Prompt最实用的心得之一。把Prompt代码化之后你才能把它纳入正常的开发流程评审、测试、回滚、灰度。Prompt本身就是AI产品的一部分它出了故障影响面和代码Bug一样大。3.2 Agent设计给它多大自主权是个边界问题Agent是AI工程里绕不开的话题。所谓Agent就是让模型不再只是你说一句它回一句而是让它根据目标自主决策——自己决定调用什么工具、按什么顺序、怎么处理中间结果。听起来很美但落地时最大的问题就是三个字不可控。我的经验是先别急着追求自主。第一版Agent工具数量控制在两到三个行动空间用状态机去限定。我举一个工单处理Agent的例子。这个Agent的任务是处理用户提交的售后工单。我给它定义了四个动作读取工单信息、判断工单类型、生成回复草稿、标记转人工。它只能在四个动作里选想调用知识库以外的任何工具都会被系统拦截。同时每个动作都有超时机制——模型推断超过三秒就重试一次超过两次就直接降级到人工处理。关键动作还设置了审批节点Agent可以生成回复草稿但真正发给用户之前必须经过人工确认。这套设计下来Agent的自主其实被锁在了一个安全边界里它能自由决定路径但不能跑出边界。它灵活的同时风险是可控的。等你在边界内跑顺手了再慢慢放开边界也不迟。这里要特别提醒一点很多团队一上来就做大自由度Agent让它自己搜索网页、自己发邮件、自己操作数据库。结果就是模型在一个真实业务系统里自由发挥出一次事可能就是一个大事故。Agent工程化的第一步不是让它更聪明而是让它更乖。3.3 用一个多Agent协作案例把全链路串起来一个Agent往往解决不了复杂问题实际场景里更常见的是多Agent协作。我做过一个客服工单自动分类加信息抽取的系统刚好能说明这个问题。整个系统拆成三个模块分类Agent负责判断工单类型是物流问题、质量问题还是退换货抽取Agent负责从工单文本里提取关键字段比如订单号、商品名称、用户诉求编排层不调用模型是一个普通的代码模块负责调度两个Agent的结果并做一致性校验流程是这样的用户提交工单后编排层先调分类Agent得到一个类型标签同时调抽取Agent得到结构化字段。编排层再校验两边的结果是否一致——比如分类Agent判断是物流问题但抽取Agent没有提取到任何订单号编排层就判定为信息不全触发一个追问用户的兜底动作。这个设计里有几个关键点。第一Agent之间不直接通信所有信息都通过编排层中转保证数据流可控。第二每个Agent只负责一件事Prompt不会又长又杂效果更容易稳定。第三编排层承担了校验和兜底职责把模型的不可靠性挡在了业务逻辑之外。我自己在搭这套编排逻辑时用了AI编程工具辅助像CodeBuddy这一类可以直接生成工具调用的骨架代码和对应的单元测试省了不少写样板代码的时间。但注意工具生成的代码一定要看懂再用尤其是Agent边界的校验逻辑必须人工review。4. AI应用上线前必须过的三道坎4.1 评估指标选不好等于白做评估集搭好了用哪些指标评判效果同样决定了AI工程的成败。我看到太多团队用一个ROUGE分数就想衡量生成式AI的效果这是典型的自欺欺人。ROUGE这类指标适合翻译、摘要这种有标准答案的场景但到了开放生成场景就失效了——模型说出的话和参考答案文字上差很远但语义完全正确ROUGE照样给低分。我的做法是分两层评估第一层是自动化初筛用语义相似度跑一遍批量数据把明显不合格的样本筛出来。具体来说就是把模型输出和标准答案分别做向量化算一个余弦相似度低于阈值直接判负。这一层能帮你快速发现问题。第二层是人工终审对初筛通过的样本做抽样人工判断。人工判断的标准是这个回答是否解决用户的问题而不是这句和参考答案像不像。这里有一套我一直用的对照逻辑评估类型看什么指标解决什么离线自动化语义相似度、字段抽取准召率快速判断模型是否离谱离线人工回答质量、满意度得分判断体验有没有达标线上业务解决率、转人工率、用户满意度判断业务目标有没有达成核心就一句话指标必须关联业务目标。你做客服系统最终就看解决率和转人工率你做内容总结最终就看用户留存。离线指标再好业务指标没变化都是白搭。4.2 成本与延迟AI工程的隐形杀手模型效果再惊艳如果一次调用要等十秒、价格贵到单次成本超过业务利润项目就活不了。成本和延迟是AI工程里最容易被低估的两道坎。我随便算一笔账。假设你的业务每天处理一万次模型调用用一款中高端模型单次输入输出约2000 token单价按市场常见水平估算一天的成本就可能上千元。再加上并发高峰期的排队延迟用户等不起就会流失——这个流失速度会把省下的成本全部吃掉。我自己常用的优化三板斧缓存高频问题直接缓存答案模型都不用调。客服场景里前20%高频问题可能覆盖了80%的咨询量模型分级简单任务用小模型复杂任务才上大模型。分类、抽取这类任务用中型模型完全够用只有需要复杂推理的才用旗舰模型流式输出把生成结果流式返回给用户首字延迟能大幅降低体感好了不止一档延迟的优化不能靠感觉要量化。我每次上线前都会做一个压测明确并发数、延迟分位数、缓存命中率这三个数字。没有这些数字就不要说自己做好了性能优化。4.3 可观测性出了问题别只会翻日志AI应用出问题和传统应用完全不一样。传统应用报错你能从异常栈直接定位AI应用出错往往是模型回答质量崩了没有异常没有报错只有用户一句这回答不对。要让AI应用可排查你必须建立可观测体系。我的方案是三条第一全链路Trace。从用户请求进来我就生成一个request_id让它贯穿输入、检索、Prompt组装、模型调用、输出校验的每一个环节。一旦出问题我拿着这个id就能还原整个处理过程。第二结构化日志。每次模型调用都记录输入、输出、模型版本、Prompt版本、Token数、耗时。这张表就是AI应用的黑匣子。第三badcase回流机制。线上被用户标记为回答不满意的样本自动流回评估集。这样每次迭代后的评估都融合了最新的线上问题系统才会越迭代越稳。我见过太多团队AI应用上线后连日志表里记录了模型版本这么基础的事都没做。结果一出现问题根本没法定位是Prompt变了、模型版本变了还是上下文被污染了只能靠拍脑袋重试。这样的系统谈何可靠性。5. AI工程最经典的失败模式和我现在推荐的起步路径5.1 五个让项目死掉的反模式这些年看了太多AI项目成或败都有规律。先说最容易让项目死掉的五个反模式第一上来自训练模型。很多团队刚拿到AI需求第一反应就是我们要微调一个专属大模型。结果花了大量算力和人力微调完效果还不如直接用托管API加一段精心设计的Prompt。微调是锦上添花不是雪中送炭。你连Prompt都没调明白凭什么觉得微调就能解决问题第二没有评估集就上线。这是所有反模式里最致命的一个。没有评估集你就分不清模型升级到底是改进还是回退分不清Prompt调整是变好了还是变差了整个项目变成一个永远说不清的黑箱。第三Agent权限失控。给Agent过大的行动自由度让它能改数据、能发消息、能往外调接口等于把业务系统的钥匙交给了概率。一次事故可能就把整个团队几个月的心血全赔进去。第四只做离线demo不做线上闭环。很多团队把精力全花在离线演示上做出来的东西在新数据集上一跑就崩因为压根没经历过线上真实数据的毒打。AI系统需要在真实反馈中持续迭代没有线上闭环进度都是脆弱假象。第五把Prompt写死在业务代码里。这个前面说过了会造成迭代极其困难牵一发动全身。5.2 我现在的AI工程起步路径基于这些年的经验我现在做任何AI项目都按照下面这套路径走基本不会出大偏差选一个真实业务痛点定义清楚可量化指标比如客服首答解决率提升10%用托管API快速搭起最小闭环不上任何重基础设施立刻做评估集——至少要覆盖主流场景和已知边界场景每天在评估集上迭代Prompt和管线用分数说话而不是用感觉说话上线时把全链路日志和badcase回流通道建好第二天就去看线上数据用AI编程工具辅助写脚手架和重复代码把精力集中在评估和迭代上这套路径不一定最快但每一步都稳都留了后手不会让你在某个环节被卡死。最后说点个人的体会。AI工程和传统开发最不一样的地方是它没有一个做完的瞬间。你投入的每一份精力都会落在评估、迭代、监控这套持续运转的机制上。我现在做任何AI项目第一件事永远是先把评估集和日志架起来再去调模型——顺序一旦反了后面很大概率要返工。还有一个我想分享的小技巧与其花大把时间盲目调Prompt不如每天把线上收集到的badcase一条条过一遍加进评估集。那些你觉得偶尔出错的问题里往往藏着整套系统真正的提升空间。AI工程拼到最后拼的不是谁模型调得好而是谁的反馈循环跑得比谁快。