前阵子有个老同事找我说想入门AI但又不知道从哪下手。我问他手里有什么实际问题要解决他说“暂时没有就想先把 ai-engineering-from-scratch 这套东西搞明白”。这句话其实特别典型想做AI工程的人十有八九不是缺教程而是缺一个“从零到一的工程化起点”。我后面陪他完整走了一遍从需求定义、Prompt设计、Agent编排到部署和测试花了大概三周时间跑通了一个真实的小项目。今天这篇就把这条路径完整拆开讲讲哪些环节能省、哪些环节坚决不能省、哪些坑我踩完以后最想提前告诉你。这篇内容不是算法科普更不是让你先啃三个月数学再动手。它解决的核心问题是当你想把一个AI能力真正放进自己的产品、脚本或工作流里该怎么从一个模糊想法变成稳定可用的服务。适合三种人看刚接触AI、想从零搭建第一个应用的开发者团队里负责把大模型能力落地的工程师以及那些被“AI什么都行”搞得无从下手、想做点实际东西的产品和项目负责人。1. 先想清楚从零做AI工程到底在做什么1.1 先分清“炼丹”和“做工程”市面上很多AI内容讲的是“炼丹”训练模型、调参、看loss曲线。但绝大多数业务场景根本轮不到你训练模型你面对的是已经能用的通用大模型真正要解决的是怎么把它接入业务、控制输出、稳定运行。我把这个叫做“做工程”它和炼丹是两种完全不同的技能树。你可以这样理解炼丹的目标是发现“火药”的配方而工程的目标是把火药做成能稳定发射的“弹匣”还要算清楚每次扣扳机消耗多少成本、卡壳了怎么恢复。AI工程的重点不是模型本身而是模型周围那一圈东西输入输出契约、数据管道、缓存、重试、校验、监控、权限控制。这些听着不性感但恰恰是决定项目能不能落地的关键。我见过太多人一上来就追求“我要做一个全自动Agent”结果连“从一段文本里稳定抽出5个字段”这种基础任务都没做扎实。AI工程的第一步不是写Agent是先把小任务做成标准化接口。你先能用高概率拿到正确输出再谈自动化。1.2 从零到一我建议的六个步骤如果让我给一个新人画路线图我不会直接推荐框架而是让TA按照这六个步骤走一遍定义输入输出你的功能解决什么问题输入是什么格式输出是什么格式比如“从项目描述里提取风险点”输出就是风险列表。收集最小样本找20到50条真实数据不要用自己编的假数据。这一步会被很多人跳过但它是后面评估的地基。用Prompt搭基线不写工程代码直接在对话界面里试看模型大概能不能做到。建立验证集把20到50条样本分成开发集和测试集用来判断改动是变好还是变坏。工程化封装把上面的流程写成服务加上参数校验、缓存、日志和错误处理。部署与监控上线后持续收集真实请求定期回放错误案例。这个顺序需要严格遵守尤其不要跳过第2步。你可能会问为什么不让模型直接读用户真实请求上线以后再慢慢优化因为真实流量不可控等发现质量问题时你已经没有干净的样本来复现和修复了。先拿小样本跑通成本低、迭代快后面再扩大。1.3 为什么“从零开始”最容易翻车翻车原因通常集中在三个方面。第一是需求定义得太宽比如“做一个智能问答助手”到底回答什么领域的问题覆盖哪些格式不回答什么全都没说清。第二是数据格式不统一你让模型从合同里抽取甲方名称结果有的合同是扫描PDF、有的是表格、有的缩写模型再强也架不住输入乱。第三是效果评估缺失全靠人肉眼感觉“好像行”说不清哪里不行。我自己踩得最重的坑是对Agent期望过高。早期我以为只要把任务描述给模型再给它几个工具它就能自动完成复杂工作流。实际跑起来发现模型会在不该调用工具的时候调用会在循环里反复试错会把中间错误当成最终结果。工程化之后我才明白AI工程的核心不是“让模型更聪明”而是“让系统的确定性更高”。你要把不确定性圈在一个可控范围内让模型在边界内发挥而不是让它自由发挥。2. 核心工程环节从Prompt到Agent的开发细节2.1 Prompt Engineering不是写作文是设计接口契约很多人把Prompt工程理解成“把话说得更清楚”没错但工程化的Prompt不止是清楚它是一份接口契约。所谓接口契约就是模型输入输出的格式、约束、边界都必须明确像函数签名一样可维护。我常用的Prompt结构包含四部分System设定角色和全局规则User提供待处理内容和上下文Few-shot给出输入输出示例最后的Output Schema规定输出格式。举个例子做一个简历字段抽取功能System里写清楚“你是一个信息抽取助手只输出JSON”User里放简历文本和“请抽取姓名、工作年限、技能列表”Few-shot放一组“看着像但和你业务相关”的示例最后在代码里用JSON Schema校验输出。这里有一个实操细节如果业务允许尽量把温度参数调低我一般用0到0.3。温度越高输出越随机但结构化抽取任务完全不希望随机。只有在写文案、起名字这类创意任务里我才会把温度调到0.7以上。另外不要在同一轮Prompt里既让模型做抽取又让它做推理比如“抽取字段并判断风险等级”功能越单一越稳定。你把复杂任务拆成多个小Prompt每个只干一件事效果会好得多。2.2 AI Agent先别让它自主先用状态机控制Agent这个词现在很火但工程化的Agent不是“模型自己随便跑”而是一个受控循环模型根据用户目标决定调用哪个工具工具返回结果模型继续判断直到得到最终答案。这个范式没错错的是很多人在没有约束的情况下直接让循环裸奔。我的建议是第一版Agent不要做完全自主改成状态机。把流程拆成固定节点接收需求、调用检索工具、生成答案、校验答案、结束或重试。每一步都由代码控制模型只负责节点内的决策不负责跳转。你可以用简单的Python状态机实现也可以用LangGraph这类编排框架但核心思路一样让模型在状态机内部行动而不是让它控制全局流程。代码层面我习惯给每个工具做一个签名描述包括参数名、类型、含义。比如给Agent一个“查询项目风险”的工具就需要定义参数project_id、risk_type还要告诉模型什么时候用、什么时候不用。同时加两个保险最大调用步数例如20步超时时间例如30秒。这样即使模型发疯系统也能在指定步数内强制结束不至于烧钱烧到天亮。2.3 Harness Engineering给模型套上“执行骨架”Harness这个词在Agent圈里越来越常见你可以把它理解成“执行骨架”。它的作用不是替代模型而是在模型外面包一层系统性能力工具注册、参数校验、错误捕获、结果缓存、权限控制。为什么需要它因为大模型输出天然不稳定模型会生成一个看似合理但格式错误的工具调用或者把不存在的结果说得像真的一样。如果这些输出直接进入业务系统轻则报错重则产生错误账单。我做的Harness一般包含这几个模块工具注册表、参数校验器、执行器、结果校验器、重试器。工具注册表声明有哪些工具可用每个工具对应一段真实执行的函数参数校验器按JSON Schema检查模型生成的参数不合格就直接拒绝并让模型重试执行器真正调用工具结果校验器检查返回是否符合预期类型重试器控制次数和退避策略。这里有一个容易忽略的安全点工具权限一定要收敛。只给模型最小权限比如检索类工具可以开放写数据库、发消息、调支付这类操作必须加“人工确认”节点。我看到过不止一次模型被提示词注入后执行了不该执行的工具。Harness里加上权限白名单比事后补救安全得多。3. 工具链选型与AI工作流搭建3.1 从零搭AI工程先用最笨的工具跑通很多新手在选型上耗费大量时间今天看这个框架文档明天看那个Agent平台来回切换项目却迟迟没进展。我的经验是先别引入任何重框架直接用Python脚本加模型API把主流程跑通。流程真的复杂了再考虑LangChain、LangGraph、Dify这类工具。最笨的工具不代表最终方案它只代表你用来验证“这条路是否可行”的最小成本路径。我举一个实际场景给客服工单做自动分类。我先用Python列表存了50条历史工单每条标注好类别然后把“用模型分类”的代码写成普通函数循环跑一遍打印错误案例。整个过程不涉及数据库、不涉及队列只有输入输出和判断。两天后我确认准确率可以接受才开始加存储、加接口、加前端页面。这样做最大的好处是出问题时你能快速定位是模型问题还是工程问题而不是被框架日志淹没。3.2 多AI协作把任务拆给不同角色有些任务用一个大型Prompt就能完成但会把上下文塞得太长输出不稳定。这种情况下我倾向于把任务拆成多个角色让不同模型或同一个模型的不同会话分别负责再把结果串联起来。多AI协作不是让一堆Agent自由聊天而是像流水线一样每个节点有明确输入输出节点之间传数据不传废话。举个例子我做过一个“生成项目周报摘要”的工作流第一个模型只负责从材料里提取关键事项输出JSON第二个模型拿到JSON后只负责生成段落文字第三个模型做审核检查事实是否与原始材料一致。每个模型的任务都很窄上下文也不会无限膨胀。接口就是JSON谁都可以替换。这个思路叫“角色拆分”它比塞一个超长Prompt更可控也更省钱。3.3 让AI配合工作流而不是反过来我见过最多的失败案例是把AI当成流程的替代品直接让模型做整个流程的“大脑”。实际上成熟的做法是把AI嵌进现有工作流里做一个增强组件。比如客服工单处理先让规则引擎把简单问题自动回复再让AI处理复杂情况最后人工复核。AI只负责生成草稿不负责最终决策。你应该先把业务流程图拿笔写出来标出哪些步骤适合AI哪些步骤必须人工。适合AI的通常是重复性高、容错率相对高的环节必须人工的是责任重、错误代价高的环节。我个人的实践法则是“AI做初稿人做终审”。这样既保证了效率也留住了兜底。如果你发现流程本身还是一团乱麻别指望上AI能解决先梳理流程再谈智能化。4. 模型部署、测试与上线避坑4.1 模型部署的三个方案API优先、自部署补充从工程角度看部署模型有三种主流方案直接使用云厂商的模型API自部署开源模型二者混合。决策依据通常是成本、延迟、数据私密性和维护成本。API方案适合快速验证和中小流量不需要管GPU按量付费但单次调用成本会随着流量线性增长。自部署方案适合对数据私密性要求高、调用量大到API成本超过硬件成本、或需要定制模型能力的场景但要处理显存、并发、模型权重、升级等问题。我通常建议先用API把产品跑通等有稳定流量和成本模型后再考虑自部署。混合方案则是把高敏数据走私有模型普通内容走API。给你一个显存估算的经验一个7B参数的中等模型FP16精度下光权重就需要约14GB显存再加上KV Cache和运行时开销实际至少需要24GB的显卡才舒服量化到INT4可以让权重降到约4GB但你有额外部署和精度损失问题。具体选型要量力而行不要一上来就搞70B7B模型在很多任务上已经够用。4.2 AI测试开发把模型输出当被测对象AI测试和传统测试最大的区别是模型输出不是确定性的你不能用“等于预期值”来断言。但这不代表没法测。我通常会给模型输出建立一套“质量基线”然后用自动化手段回归。具体做法是准备一组验证集每条数据标注标准答案。跑完模型后用规则校验输出格式看JSON schema是否合法、必填字段是否缺失、枚举值是否越界。再把文本字段和标准答案做相似度或关键子串匹配。结构化的任务可以算准确率和字段级F1生成类任务可以抽样让人工评分。我还会用“模型判官”方式让一个更强的模型对输出按标准打分但每隔一段时间抽样人工复核防止判官模型自己跑偏。这里要重点提醒测试数据一定要来自真实场景用真实工单、真实简历、真实对话不要用你自己编造的整齐数据。模型在干干净净的输入上表现良好是假象一到真实噪声数据就崩。把脏数据、错别字、缺失字段塞进测试集才叫有效测试。4.3 上线后的监控、灰度与负反馈闭环上线并不是终点。模型升级、Prompt调整、用户输入变化都会影响效果所以必须有监控和迭代机制。我会在日志里记录每次请求的输入、模型版本、Prompt版本、输出结果、耗时和Token消耗。这样出问题时可以回放不用对着屏幕猜原因。灰度尤其重要。模型提供商更新一个版本哪怕宣称“能力增强”都可能改变你的输出格式。不要看邮件公告就自动切流先在测试集上跑一遍再按5%、20%、100%的比例放量。上线后建立负反馈闭环每周抽一部分badcase分析是输入脏、规则缺失还是模型问题修复后再跑回归。这里给一个上线检查清单是否记录Prompt版本是否设置单次调用超时是否对模型输出做了格式校验是否有失败重试和降级方案Token消耗是否设置了阈值告警如果这些全是“否”先别上线。5. 常见问题与排查技巧实录5.1 输出格式漂移、字段缺失怎么办很多人在用模型抽取信息时遇到这种怪事上周还好好的这周突然缺字段或者JSON后面多出一段解释。我先检查三件事温度是不是被改高了System Prompt里是否明确写了“只输出JSON不要任何解释”模型是否升级了。第一个问题最常见很多人为了“让回答更自然”把温度调高结果格式全乱。第二个问题是因为模型认为你需要解释你要在Prompt里反复声明输出格式最好的方式是开启模型的结构化输出或JSON Mode功能。字段缺失还有一个常见原因Few-shot示例太少或太特殊。我给模型提供的示例最好覆盖边界情况比如空值、超长值、多值字段。如果模型仍然不稳定就在代码里做兜底解析JSON失败时自动重新请求一次并带上错误信息。本质上是把“格式错误”当成一种预期内的异常而不是偶然事件。5.2 Token超限、上下文爆炸、成本失控上下文超限是Agent项目里最常遇到的硬问题。根本原因是把历史对话、参考资料不停往Prompt里塞Token只增不减。解法是给上下文瘦身只保留最近N轮对话更早的内容做摘要参考资料用RAG检索后截取相关片段不要全文塞入设置最大输出Token数防止模型长篇大论。成本失控也是这些项目的高发问题。我习惯在每次调用前估算Token假设系统Prompt和示例占1000Token用户输入平均500Token输出平均300Token那么一次调用就是1800Token。如果一天一万次调用就是1800万Token。价格乘以单价数字很直观。所以我对每个接口做了每日Token预算告警某类任务一旦超预算立刻排查是不是出现了Agent死循环或用户恶意灌长文。5.3 幻觉与事实错误兜底而不是根治大模型的幻觉不可能靠一句话根治工程上要做的是兜底和减害。做知识类应用时我一定用检索增强先检索知识库中的相关片段再把片段附在Prompt里并要求模型在回答中标明依据来源。如果模型说“根据文档”而文档里根本没有这句话就用规则或二次模型校验来判断一致性不一致就拒绝输出。另一个技巧是允许模型“不知道”。在Prompt里明确写“如果没有足够信息直接回答‘无法从现有资料中确定’不要推测”。很多人觉得这样不智能但实际业务里一个诚实的“不知道”远比一本正经的错误答案安全。关键流程还要加人工复核节点让模型生成的最终结论只能作为参考而不是自动生效。你要接受一个事实AI工程的目标不是消灭错误而是把错误控制在可观测、可回滚、可拦截的范围内。我个人跑完这套从零到一的项目后最深的体会是不要一开始追求全自动先做一个有人参与、但效率明显提升的半自动流程稳定以后再慢慢扩大自动化范围。每隔一段时间我都会回去重看自己的老项目最满意的不是用了多新的模型而是把那些细碎的错误一点点收进了框架里。最后分享一个小技巧给每一个Prompt都加上版本号和变更记录比如v1.2修正输出字段v1.3增加空值处理。这样模型升级后行为变化时你能迅速定位是Prompt的问题还是模型的问题而不是在混乱中反复重试。