前段时间总有朋友拿着一张网上的AI课程表来问我这个路线图靠谱吗我看了一眼Prompt工程、RAG、Agent、微调……列得倒是齐全但仔细一看全是“用某某平台做某某功能”的操作步骤一个问题都没解答这些东西到底是怎么组合成一个能稳定交付的系统的这也就是我今天想写的主题——ai-engineering-from-scratch。我不是来给你背课程大纲的我想聊的是从零开始搭建AI工程能力时真正决定成败的几个关卡以及我实际动手做项目时踩过、也填平过的那些坑。如果你正准备在业务里落地AI或者想让自己的AI技能从“能聊天”升级到“能交付”这篇内容应该能让你少走不少弯路。1. 先想清楚一个问题你搞的是“AI调用”还是“AI工程”很多人的第一个AI项目是拿着一个大模型API写一个能让用户提问、模型回答的页面。这当然算接触了AI但它顶多算“接口调用”离“工程”还有一段距离。我见过不少人卡在这一步觉得自己学了半年怎么还在原地踏步原因只有一个没有建立工程视角。1.1 一个撕开差距的真实案例2024年我帮朋友做过一个小项目提取客户发的邮件里的订单信息写入他们的ERP系统。最开始我们用最“快乐”的方法——把邮件全文塞给大模型提示词里写“把订单号、金额、客户名提取出来”然后解析返回的JSON。结果头两个星期我们都在干同一件事调提示词。今天发现模型把“金额”识别成了“含税金额”明天发现地址里有公寓号就多出个字段后天又发现退货邮件也被当作订单。每次修完都觉得“这次应该行了”每次都被新的边缘情况打脸。后来我把这套流程彻底重构只做了一件事把任务拆成“判断是否为有效订单→提取结构化字段→按规则校验→异常人工介入”四步每一步有独立的提示词、独立的校验逻辑、独立的失败策略。从那以后项目才真正稳定下来。这件事给我的教训很深刻AI工程的核心不是让模型“更聪明”而是让系统在模型没那么聪明的时候也能兜得住。1.2 “AI工程”和“AI调用”到底差在哪简单来说调用是问一次拿一次结果工程是把很多次调用组织起来做成一个可靠、可维护、可度量的流程。两者之间的差别也很大维度AI调用AI工程目标拿到回答拿到稳定可用的业务结果输入一段文本结构化的任务定义与约束输出模型的原始输出经过校验、纠错、格式化后的结果失败处理重新问一次自动重试、降级、转人工质量保障人工看结果评测集、回归测试、监控可维护性改提示词改代码、改提示词、改流程配置这也是为什么很多人在网上抄了“高质量提示词”放到自己业务里照样翻车。因为提示词只是工程里最小的一环系统设计、流程编排、校验兜底才是真正决定成败的东西。1.3 为什么“抄提示词”永远学不会AI工程我见过一位朋友花了大量时间收集各种提示词模板什么“律师式提示词”“CEO式提示词”“Step-by-Step万能公式”攒了满满一个笔记库。但他做一个实际的报销单识别工具时还是被字段错乱、格式不统一折磨得够呛。真相是提示词工具是人类思维方式的载体不是咒语。同样是要求模型输出JSON如果你的上游数据既有PDF又有图片、既有中文发票又有英文收据你得先处理格式统一和内容抽取而不是指望一句“请以JSON输出”解决所有问题。AI工程是把整个链路当成一个流水线来设计每个环节解决一个问题每类异常都有处理预案。2. 提示词工程把需求翻译成模型能执行的“工程说明书”很多人觉得提示词工程就是“会说话的艺术”但站在工程角度它更像是写需求文档目标清晰、边界明确、验收有标准。好的提示词不是让模型“发挥”而是让模型在限定范围内“执行”。2.1 一个好用的结构化提示词框架我平时写生产级提示词基本都会包含五块角色、任务目标、输入输出格式、约束条件、示例。以一个“从微信聊天记录里提取客户跟进状态”的任务为例提示词会是这样角色你是一位客户运营助理擅长从销售聊天记录中提取关键状态信息。 任务目标根据提供的聊天记录片段提取以下字段 - customer_attitude客户态度积极/中性/消极 - next_action客户或销售明确约定的下一步动作 - concern客户提到的主要顾虑若没有则填“无” 输出格式仅输出JSON形如 {customer_attitude:积极,next_action:下周三发送报价单,concern:对交付周期有疑虑} 约束条件 - 只依据聊天记录中的原文判断禁止脑补。 - 若字段信息不存在使用空字符串或“无”。 - 若聊天记录不属于客户沟通场景输出{valid:false}。 聊天记录 {这里放原始文本}这个框架看起来平淡无奇但工程上非常有用。角色设定减少风格漂移任务目标决定了提取哪些字段输出格式让下游程序能直接解析约束条件把边界问题挡在源头示例则起到“锚定”作用让模型知道你想要的JSON长什么样。这五个部分缺哪个都会在特定场景里出问题——我有一次偷懒没写约束条件模型居然把“希望尽快收到货”脑补成了“已投诉物流”差点让运营同事直接打电话去道歉。2.2 上下文管理和Token预算工程化必过的第一关生产环境里你不可能永远只把“一小段文本”塞进模型。真实情况往往是客户历史记录、商品信息、物流状态、聊天记录全要作为上下文。这时候Token预算就成了硬约束。我自己的实践是给上下文分档优先放系统级指令然后是当前任务输入最后才是历史信息。历史信息再按时间衰减和相关性过滤只保留最近几条或命中关键词的片段而不是把全部文本一股脑塞进去。这块有两个实操经验用Tokenizer先估算长度。OpenAI和各家模型都提供了Tokenizer工具先估算输入Token再设定预分配的上限比如上限8000 Token时系统指令给1000当前输入给5000历史信息压缩在2000以内。超长内容分批处理。真正长的内容比如整本手册、几十页聊天记录先做章节切分再逐段提取摘要最后合并摘要。直接全文硬塞成本暴涨不说模型对中间内容的注意力往往也是衰减的。2.3 提示词也要版本管理这个习惯可能很多人没有但在生产项目里极其重要。我见过最痛的一次事故运营同事为了“让模型更详细一点”直接在后台把提示词改了一句结果当天的客服智能质检全都跑偏报表数据乱成一团。原因很简单——没有人追踪提示词什么时候被改过、被谁改过、为什么改。从那以后我把所有提示词都当成代码来管放进Git仓库每次修改走评审发布时打版本号。提示词文件和对应的评测用例放同一个目录哪个版本配哪份用例一目了然。这个习惯救了我好几次尤其当模型厂商升级底层模型之后同样的提示词表现可能完全不一样能快速回滚到上一版就格外重要了。2.4 几种常见的“答非所问”其实是提示词设计问题模型答非所问很多人第一反应是“模型不行”但排查下来经常是提示词设计有漏洞任务目标模糊。比如“分析这段话”模型不知道你要的是情感倾向、主题分类还是行动建议自然只能给你一段泛泛而谈。缺乏约束条件。模型会默认补充它觉得合理的信息导致输出带上了“脑补内容”。输出格式与下游不匹配。有的模型对JSON格式理解得好有的模型更容易输出带注释的代码块都要在评测环节确认清楚。示例太少或太偏。一个示例能帮模型定调但如果示例场景和实际输入差异太大反而会把模型带偏。这些问题的共同根源是提示词没有把“验收标准”讲清楚。工程化提示词的闭环不是写出来、测一次、部署上线而是持续根据失败样本更新约束和示例每一次线上翻车都是提示词迭代的养料。3. Agent从“一问一答”到“多步任务闭环”如果说提示词工程是地基那Agent就是在这块地基上盖出来的房子。单次调用只能完成一个动作但真实业务几乎都是多步骤任务查资料、做判断、调工具、校验结果、产出报告。这就是为什么要引入Agent。3.1 为什么单次调用搞不定真实业务拿我们做的“自动竞品情报站”为例。用户输入“帮我看看最近一周xx赛道有什么值得关注的产品动态”如果只调一次大模型它要么凭训练数据里的旧信息瞎编要么只能给出毫无依据的泛泛而谈。真实解决方案必须做几步先去资讯源抓取内容、过滤和本文相关的关键词、逐篇提取要点、合并相似事件、最后生成一份周报。每一步都是独立的调用这些步骤之间还有先后依赖。单次调用是一个点Agent是把这个点串成一条线的编排器。这也是为什么聊Agent工作时业内有人会提到“harness engineering驾驭工程”——重点是怎么把模型的能力“装进”一个可控的执行框架里而不是让模型自由发挥。3.2 Agent的骨架规划器、工具集、记忆、执行器我习惯用一个生活化的类比来解释Agent结构它就像一个由项目经理带领的实习生小组。规划器项目经理负责把大目标拆成小任务决定先干什么、后干什么。工具集实习生手里的工具箱比如搜索引擎、数据库查询、文件读写、API调用。记忆项目组的白板和资料架用来记录已经做了什么、查到了什么、下一步要做什么。执行器真正调用模型、解析结果、决定下一步循环的“手脚”。理论上你可以用LangChain这类框架快速搭一套Agent但我实践下来建议一开始别急着上框架先用简单的代码把“规划→执行→检查→重试”这个循环跑通理解每一步的数据长什么样再决定要不要引框架。否则框架的抽象会把问题藏起来调试的时候你会非常痛苦。3.3 工具调用的工程细节格式契约、错误恢复、防循环Agent必然要调用工具而工具调用是工程坑的重灾区。我在项目里遇到过三个特别典型的问题第一格式契约不一致。模型返回的“工具调用参数”很可能是JSON字符串但如果模型多了一个换行、一个尾逗号或者把参数名改了程序直接崩掉。我现在的做法是在提示词里给定严格的JSON Schema同时调用后马上做一次“参数修正”解析失败就触发一次retry并附带错误信息让模型重新生成。第二错误恢复。工具调用失败比如搜索接口超时、数据库连接断开Agent不能干等着必须有降级策略重试一次换另一个工具试一次再不行就向用户说明“这一步没取到数据以下内容基于已有信息生成”。这个逻辑写起来不难但很多初版Agent完全没有一遇到小故障就整个任务失败。第三防循环。模型在Agent里很容易陷入“反复调用工具就是不产出结果”的循环每次调用还要花Token成本肉眼可见地涨。我通常会设置两个硬性保险最大迭代次数比如10步以及单任务Token上限。超过阈值直接终止输出当前已获得的中间结果并提示人工接手。工具调用的JSON Schema示例大致长这样{ name: search_web, description: 搜索互联网并返回与关键词相关的新闻标题、链接和摘要, parameters: { type: object, properties: { query: {type: string, description: 搜索关键词尽量精确}, time_range: {type: string, enum: [1d, 7d, 1m]} }, required: [query] } }这段Schema本身就是一种“和模型签订的契约”定义得越严格模型越不容易跑偏。3.4 多AI协作的两种模式串行流水线与并行会诊有人工智能项目往往会走到“多模型配合”这一步。我常用的有两种模式串行流水线和并行会诊。串行流水线适用于任务有明显先后关系比如“信息抽取→摘要生成→报告改写”每一步交给不同的模型或同一模型的不同角色提示词。并行会诊则适用于需要多角度判断的场景比如让两个模型分别做“风险识别”和“机会识别”再把结果合并给第三个模型做冲突消解和总结。这个思路来源于一个很朴素的直觉一只模型处理所有事就像一个人既当客服又当财务又当产品经理角色切换越多越容易乱。反而是“专人专事”的结构每个环节可控、可测、可替换整体稳定性高很多。4. 工程化的四块硬骨头评测、成本、可观测性、模型路由AI项目能不能长期运行拼的不是Demo效果而是这四个问题有没有认真解决。4.1 评测集没有黄金标准所有优化都是自我感动这是我踩过最大的坑之一。早期做一个文本分类工具每次改完提示词都觉得“效果变好了”但拿给同事看人家问“好在哪你拿多少测试样本做过统计”我当时一句话答不上来。后来老老实实建了一个评测集从那以后AI工程才算真正有了“方向盘”。评测集不用一开始就做得很大。我的经验是第一批人工标注50到100条代表性样本就够了覆盖正常情况、边界情况和典型错误情况。每条样本包含输入、期望输出、可选的关键理由。每次迭代提示词或改流程都在这个固定集上跑一遍算准确率、看失败案例分布再决定改哪里。为了不让评测变成“跑一次记个数”我还做了一个极简的回归脚本大致逻辑是for case in eval_set: result run_agent(case.input) if normalize(result.output) ! normalize(case.expected): failures.append({case, result}) report {pass_rate: pass_rate, failures: failures}这个脚本现在是我所有AI项目的“守门员”改动之前跑一遍心里有底。4.2 成本和延迟的权衡大模型不是唯一解药很多AI项目从Demo走向生产时第一个撞上的南墙是账单。用最强模型跑所有任务效果是没话说但成本让老板心疼。我一般会先给任务分个级简单任务如判断、分类、抽取用小参数模型就足够复杂任务如长文总结、多步推理才用大模型。举个例子一个智能客服项目里80%的简单问答走快速模型响应延迟大概1秒单次成本几乎可以忽略剩下20%的复杂问题才走大模型成本高但只占总调用量的小头。整体算下来成本比全都用大模型下降了60%以上而用户可感知的回答质量几乎没有区别。这里还有一个小技巧把大模型的输出缓存起来。对于相同或高度相似的问题先查缓存命中就直接返回既不花钱又只有几毫秒延迟。缓存命中率在工作流固定的项目里往往能到30%以上。4.3 可观测性给Agent加“行车记录仪”Agent是多步运行的系统一旦结果不对你很难一眼看出是规划错了、工具调用错了还是模型理解错了。我的经验是从第一天就给Agent加上“过程日志”核心是把每一步的以下信息记录下来当前步骤名称模型输入摘要提示词前300字模型输出全文工具调用参数和返回结果各步骤耗时和Token消耗最终结果和人工标注的满意度这些信息合在一起就像一个行车记录仪出了问题可以回放整个过程定位到底哪一环跑了偏。有一回我们的竞品情报Agent生成了一份离谱报告我打开日志一看发现是搜索工具返回了乱码内容模型没有识别出来直接基于乱码做了总结。没有日志的话光看结果根本猜不到这个原因。4.4 模型路由让简单任务用便宜模型复杂任务用强模型模型路由听起来高级落地其实就是一个前置判断逻辑评估当前请求的复杂度再决定用哪个模型。比如我常用两步判断法先用一个极快的模型给请求打标签——这是“简单问答”“信息抽取”还是“复杂分析”然后根据标签路由到大模型或小模型。也可以让用户主动选择“快速模式”和“深度模式”。这套逻辑的本质是不把昂贵算力浪费在简单请求上也不让复杂问题被弱模型糊弄过去。路由层本身不复杂但它对成本控制和响应速度的影响比优化十个提示词都明显。5. 从零到一完整走一遍做一个自动竞品情报站前面讲了不少方法论可能有点干我用一个完整的、我实际做过的项目把它们串起来你就能看到每一块是怎么咬合在一起的。5.1 需求拆解一个“高大上”目标拆成五个可执行子任务最开始的需求只有一句话“我要一个自动追踪竞品动态的机器人。”这句话没法直接写提示词。我把它拆成五个环节采集从指定资讯源抓取文章标题和链接。过滤判断文章是否和关注的竞品或赛道相关。要点提取从相关文章中提取产品动态、融资、人事、战略等事件。汇总去重将跨文章重复信息合并成事件条目。周报生成把事件按主题整理成一份带摘要的周报。每一个环节都是独立的模块有独立的输入输出定义也有独立的失败兜底。拆完之后“做一个竞品情报站”就变成了“实现五个小函数”难度瞬间下降了一个量级。5.2 提示词与工具实现可参考的最小模板以“过滤”环节为例提示词我写成了这样任务判断以下文章是否与“智能客服”赛道相关。 判断标准文章主体涉及客服机器人、自动应答、大模型客服应用、客服SaaS产品视为相关 仅泛泛提到“AI”或“客服”但不作为核心内容视为不相关。 输出JSON{related: true/false, reason: 一句话说明判断依据} 文章标题{title} 文章摘要{summary}配合这个提示词采集模块做好RSS抓取过滤模块调用模型做判断之后要点提取和汇总去重各自独立。整条链路没有用Agent框架就是一段Python脚本把各步骤串起来。生产环境里“轻量编排少量模型调用”往往比“重框架自由Agent”更稳定、更好维护。5.3 组装与联调最容易被忽视的“人机协作边界”很多人做自动化项目会陷入一个执念希望全链路无人参与一步到位。但现实是AI工程里最稳的设计是明确“哪些步骤必须有人审批/修正”。在我的情报站里采集、过滤、提取是全自动的汇总去重之后会生成一份“待人工确认”清单运营同事可以勾选、修改、删除事件后再生成最终周报。这个设计让自动化负责“把80%的重复劳动干掉”而人只需要在关键节点把关。结果就是项目既高效又可信大家也愿意接受AI的输出。5.4 上线后的数据与收益这个项目上线三个月后我拉过一次数据。每周平均采集文章400多篇过滤后保留大约40篇相关材料提取出20个左右的事件条目最终人工修正的时间从原来的每周3小时缩到40分钟。Token成本折算下来大约每周30元人民币左右这个数字在当时让我挺意外——工程的收益不只是“效果变好”更是成本可控、过程可查、结果可预期。6. 关于AI工程最后想说的几句实在话走到这一步你已经知道AI工程不是某个模型、某条提示词、某个框架能定义的。它是一个系统是由任务拆解、流程编排、评测反馈、成本控制和异常兜底共同构成的系统。这也是为什么我一直强调“from scratch”——从零搭建的价值在于你必须亲手理解每个环节为什么这么设计而不是拿一套现成方案直接套用。我现在的日常工作里仍有不少时间花在“看失败样本”上。模型每答错一次评测集就多一条用例提示词就多一条约束。这个循环给了我一种非常踏实的感觉AI项目的质量不是靠“最强模型”保出来的是靠一次次针对失败样本的迭代修出来的。无论你从哪个领域开始进入AI工程这个迭代习惯都是最值得尽早建立的能力。如果你也想从零开始搞一个AI项目我的建议很直白挑一个自己每天都在做的重复性任务拆成步骤搭一条最简单的自动化链路然后建评测集、记日志、看失败案例。不用等到“准备好”才开始先用最小闭环跑起来然后在一个月内不断修补它。你会发现所谓AI工程能力并不是某个顿悟时刻而是这一个月里每一次修补积累出来的手感。