做AI工程这两年我最大的一个感受是网上铺天盖地的教程都在教你怎么训模型、怎么调 prompt真正告诉你“一个 AI 功能从想法到上线中间到底要经历什么”的内容少得可怜。“ai-engineering-from-scratch”这个题目字面意思是“从零开始做 AI 工程”。我理解它想表达的不是“从零开始学机器学习”而是“从零开始把一个 AI 想法变成可运行、可维护、可评估、真正有人用的系统”。我见过太多团队和个人算法能力不差模型也跑得通但一到“工程化”就卡壳要么评估标准模糊改了一版提示词不知道是变好还是变坏要么数据链路断的模型训练完喂进去的都是脏数据要么上线之后没有监控用户反馈啥也拉不回来。这篇文章我想好好聊聊一个零基础的团队或个人要把 AI 工程这件事从零搭起来到底该先把哪些地基打牢。我不会讲那些“会用某个框架就行”的速成套路而是把我实际踩过的坑、反复验证过的方法、认为真正值得投入时间的地方全部摊开来讲。1. 先想清楚AI 工程和“调模型”之间隔着一整条生产链路很多人以为 AI 工程就是“训练一个模型再用它”这是最大的误解。真实世界里的 AI 工程是一套从需求定义到数据准备、模型构建、部署上线、监控迭代的完整系统模型训练只是其中一环。1.1 为什么“能跑通的 Demo”距离“能上线的产品”那么远我在不少项目里见过同一个场景Jupyter Notebook 里模型表现惊艳demo 演示时掌声一片结果一上生产环境就原形毕露。不是模型变笨了而是训练环境里根本没有那些生产环境的约束——真实数据的分布不一样、请求并发量一上来延迟就失控、用户输入的方式和测试集不一样这些问题单靠调模型参数是解决不了的。把 AI 工程拆开看它其实是几条链路并行数据链路从数据采集、清洗、标注、版本管理到训练集/评估集构建。传统软件开发不碰数据也能写代码AI 工程不行数据的质量直接决定模型质量上限。模型链路选型、训练/微调或提示词调优、评估、版本管理。这一环是很多人最熟悉的部分但往往也是被过度关注的部分。服务链路模型部署、推理加速、请求处理、缓存降级、监控告警。这个部分常常被低估——模型再好接口不稳定、响应慢业务方照样不买单。反馈链路线上日志回捞、用户反馈收集、bad case 分析、数据回流再训练。这是很多团队最缺失的部分但没有闭环的 AI 工程就是一次性工程做一版就死了。理解了这几条链路你就明白为什么我会说“能跑通的 Demo”离“能上线的产品”还有很长一段路。Demo 只需要证明“模型能做这件事”产品需要证明“这件事在真实环境里能稳定、可靠、持续地做”。1.2 AI 工程师和算法工程师、数据工程师的分工边界这两年团队招人最头疼的就是岗位边界。算法工程师、机器学习工程师、AI 工程师、数据工程师听起来像一回事实际上干的事差很多。角色核心关注点典型产出物日常工具链算法工程师/研究员模型精度、方法创新论文、实验报告、新模型结构PyTorch、TensorFlow、NotebookAI 工程师全链路落地、稳定性、效果可评估可上线的服务、监控系统、评估体系Docker、K8s、MLflow、监控告警数据工程师数据流转、存储、治理数据管道、数仓、特征平台Spark、Flink、Airflow、SQL数据分析师业务洞察归因分析报告、指标看板SQL、BI 工具、Python一个 AI 工程师更像是“翻译官”和“总包工头”把业务需求翻译成 AI 能解的问题把算法能力包装成业务能用的服务。算法工程师关心“能不能更高”AI 工程师关心“能不能更稳”。两者不矛盾但一个从零开始做 AI 工程的团队最缺的往往是后者。1.3 一个从想法到落地的完整路径长什么样我建议所有新团队把 AI 项目拆成五个阶段来过一遍不要跳过任何一步需求定义业务方到底要解决什么问题成功的标准是什么没有 AI 时现状如何。数据盘点与准备现有数据在哪里、什么格式、多少量、质量如何没有数据先想怎么造。方案选型与验证基于数据规模、成本预算、效果要求决定用开源模型、商业 API 还是传统机器学习方案。工程化落地把验证通过的方案包装成稳定服务配套监控和回滚机制。上线监控与迭代建立线上评估机制形成数据回流闭环持续优化。这套流程走了几轮之后你会发现真正耗时间的往往不是“调模型”而是“把数据搞清楚”“把评估做准”“把服务做稳”。理解了这一点AI 工程就算入门一半了。2. 从零入手的第一步把“做什么”和“怎么算做得好”定死很多项目翻车不是技术不行而是直接从“我们做一个智能客服”跳到“我们来微调一个大模型”中间跳过了最关键的“怎么算做得好”。2.1 需求澄清别把业务诉求当成技术方案曾有一个业务方找到我张口就是“我们需要一个能自动写文案的 AI”。这听起来很清楚但一问细节就露馅了是写什么类型的文案推广海报文案还是公众号长文目标受众是谁有什么风格偏好分发渠道是哪个平台平台对字数、敏感词有什么限制如果这些问题没搞清楚技术方案就只能靠猜。我的习惯是把需求拆成三层来对齐业务目标层这件事做成了业务上怎么体现比如客服机器人是降低人工咨询量是提升响应速度还是提升满意度。用户场景层用户会在什么场景下使用、输入什么内容、期望得到什么形式的回复。技术边界层输入输出是什么格式、延迟要求多少秒、出错时允许怎么兜底。这三层里任何一层没对齐后面做出来的东西都会跑偏。尤其是业务目标层它决定了你后面怎么设计评估指标——评估标准必须从业务目标里推导出来而不是从模型输出里随便挑一个顺眼的。2.2 把业务目标翻译成可测量的技术指标这里给一个我的实操例子。之前做客服助手项目业务方最初给的指标是“提升客户满意度”。这个指标太虚了没法直接用来评估一个模型好不好。我们做了一轮翻译客户满意度低的原因主要是等待时间长、问题解决率低。所以把这个目标拆成两个技术可测的指标问题一次解决率用户发起的咨询在不转人工的情况下得到有效解决的比例。平均处理时长从用户提问到得到有效回答的时间包括排队时间、模型调用延迟、兜底转接的时间。再往下拆模型的评估指标就清楚了对“问题能否被正确识别并匹配到合适答案”的准确率、对话轮次的平均次数、意图分类的准确率与召回率等。这个翻译过程就是 AI 工程里最基础也最重要的“指标化”工作。你连“做得好”都没定义清楚后面调提示词、选模型、对比版本都会变成拍脑袋。2.3 评估集没有评估集就不要开始任何调优我认为 AI 工程和传统软件工程最大的不同点在于前者必须有一个“评估集”作为工程的基准线。没有评估集的 AI 工程几乎等于盲人摸象——每次改动模型或提示词你都只能凭感觉判断效果变化。评估集不是简单的测试集它至少包含三层标准集覆盖核心场景的、有标准答案的数据集用来衡量模型效果是否达标。边界集覆盖边界情况的极端样例比如超长输入、网络用语、同形字干扰、不文明表达用来压测模型鲁棒性。红队集故意设计来“攻击”系统的样例用来探测模型弱点。在我们客服助手的项目里标准集是历史工单里抽出来的常见问题边界集里放了很多带有错别字的长问题、口语化严重的问法、一次问多件事的组合提问。这些数据看着不起眼但在上线后起到的作用比标准集还大——因为它们才是真实世界里最常见的输入形态。2.4 一份“可执行技术规格书”的最小检查清单从需求到技术方案我习惯写一份一页纸的技术规格书包含以下要素用户输入样例 5~10 条以及每条对应的理想输出。边界情况和失败兜底策略模型答不出来怎么办超时怎么办违反安全规范怎么拦截效果指标主指标 1~2 个辅助指标 2~3 个每个指标定义清楚统计口径。成本和性能约束单次调用的预算上限、接口延迟上限、并发峰值预估。数据隐私和合规要求涉及哪些敏感字段是否需要脱敏数据存储位置有没有限制。这份规格书写完不要急着去找模型。先拿给业务方逐条过确认他们对“成功”的理解和你一致。通常这一轮就能发现很多之前心照不宣的误解省下后面返工的钱。3. 数据这一关喂给模型的东西决定工程的上限模型选得再好提示词写得再漂亮数据脏乱差一样歇菜。这是我被现实教育过很多次以后才彻底明白的。3.1 一次真实的“数据翻车”复盘我踩过最大的数据坑是做意图分类项目的时候。当时为了赶进度从网上爬了一大批公开对话数据加上自己标注了一部分凑了十万条样本。在全球标准测试集上效果不错准确率九成左右。结果一上线真实准确率直接掉到六成多用户疯狂投诉。后来排查发现三个致命问题数据分布和真实场景不一致训练数据里用户提问都规规矩矩真实用户大量使用口语、方言、错别字、中英混杂模型根本没见过这些输入形态。数据泄漏爬来的公开数据里有些本身就是测试集的一部分评估结果虚高。重复数据严重清洗时没做去重某几种常见问法出现了几千条模型严重过拟合到这些模式上其他问法基本不会了。从那以后我立了一条规矩训练数据必须和真实业务数据同源评估集必须和训练集严格隔离任何外部数据进来都要先做去重和泄漏检查。3.2 从“野数据”到“干净的工程数据”要过五关我在实际项目里总结了一套数据清洗的流程基本可以照着抄格式统一把所有来源的数据转成统一的 schema常见字段对齐例如文本统一编码格式时间戳统一时区。去重去噪严格去重尤其是用余弦相似度搭配阈值去近似重复去掉无意义文本例如纯广告、乱码、长度过短的碎片。敏感信息过滤用正则加模型双保险把手机号、身份证、银行卡、地址等敏感信息脱敏掉。标签质量校验对标注数据做交叉验证随机抽 10% 校验标注一致性不合格就退回重标。分布统计统计类别分布、长度分布、高频词汇看数据是否出现严重倾斜。这五关做好了数据才算具备进入训练管线的资格。过程很琐碎但它决定了你后面的模型能走多远。3.3 标注环节怎么管理才能不返工说到数据就逃不开标注。很多团队觉得标注就是“找人点一点”实际上标注管理做不好数据质量无从谈起。我建议标注环节注意这几件事标注规范文档先行写一份带正例负例的规范文档所有标注人员必须先读、先试标、通过了再正式开始。标注一致性检查同一批数据分给两个人标比对一致率低于 85% 就要回去重新讨论标准。疑难样本沉淀标注过程中发现拿不准的样本单独建一个“疑难池”定期和业务方一起讨论讨论结果回流到标注规范里。标注数据版本管理标注数据要像代码一样做版本管理。今天改了一条标准昨天标的那批数据要不要重新处理必须记录清楚。很多团队模型效果差不是模型不行而是训练数据的标签本身就是错的。你用错误的标签训练再好的模型也只是在拟合错误。3.4 LLM 时代的数据工程有什么新变化以前做 AI 工程大量时间花在整理标注数据上。大模型普及之后情况变了很多但“数据决定上限”这个核心逻辑没变。现在多了两类新的数据工作一类是少量示例库的设计。改用大模型做任务后你不再需要海量标注数据做训练而是需要精挑细选的少量示例放进提示词里让模型参考。这些示例怎么选、怎么排版、怎么覆盖不同类型就成为新的工程点。选得好效果立竿见影选不好给再多示例也是噪声。另一类是合成数据。用大模型生成训练数据或评估数据在数据不足时非常有效。但合成数据有个陷阱它会把模型本身的偏见过滤出来用的时候必须验真。我见过一个团队用 GPT 系列模型生成了一批“反事实样本”做数据增强结果模型学到了一堆不可能出现的场景反而干扰了正常判断。数据工作模块总结起来就一句话先盘数据再谈模型。你连自己手里的数据长什么样都不知道就急着上大模型最终只能得到一个“在自己的数据上两眼一抹黑”的昂贵玩具。4. 模型选型与提示词调优同样逃不掉“工程化思维”模型环节是多数人最兴奋的部分也是我最想泼冷水的地方。因为越容易让人兴奋的地方越容易忽略工程纪律。4.1 先算账再选模型三个决策依据团队跑来问我“该选什么模型”的时候我一般会反问三个问题你的数据量有多少质量如何如果只有几百条标注数据微调大模型大概率不如用现成 API 加少量示例效果好。你的效果要求有多高如果任务对准确率要求极高且领域专业性强可能需要微调开源模型甚至训练专属小模型如果只是通用场景的问答、摘要商业 API 往往够用。你的成本预算和部署环境是什么商业 API 按次付费开源模型要自己买 GPU 或租云资源。不仅要算训练成本更要算推理成本——线上跑一天花的钱往往比训练一次还多。我做过一个判断框架供大家参考场景特征推荐路线数据少、场景通用、预算有限商业 API 少量示例先跑通数据中等、领域特定、有隐私要求开源模型微调 私有化部署数据海量、实时性要求高、成本敏感蒸馏一个小模型部署或混合架构数据敏感、禁止出域必须本地部署参数规模只能压缩这套框架不能解决所有问题但至少能帮你避免“用大炮打蚊子”和“为了省钱把效果搞得不可用”两个极端。4.2 提示词工程不是玄学而是一门需要留痕的工程很多人对提示词工程的理解是“把指令写得更清楚一点”这太浅了。提示词工程真正的工程点在于提示词是代码需要版本管理、测试用例和回归验证。我自己做提示词调优的标准流程是这样的写初版提示词把任务描述、示例、输出格式全部结构化写清楚。跑回归集用前面建的评估集跑一遍记录指标基线。单点修改一次只改一个变量要么是示例数量要么是输出格式约束要么是风格描述改完跑一遍回归集对比。做 A/B 记录每个版本的结果存下来附上指标变化形成提示词版本历史记录。固化版本当某个版本指标稳定达标就冻结它为正式版本走代码一样的变更流程。我所在的团队用的是非常朴素的方案每条提示词对应一个 markdown 文件存进 Git 仓库文件名带版本号里面标注了作者、修改日期、评估集链接、指标结果。没有用那些花哨的提示词管理平台但该留痕的、该能追溯的一样不缺。4.3 结构化输出让模型的“自由发挥”变成“规定动作”接入大模型之后被问得最多的一个问题是“模型输出的内容格式不稳定有时候多个 JSON 字段有时候又丢了我解析老是报错怎么办”这个问题属于 LLM 应用里最经典的工程坑。模型的输出本质上是概率采样不可能保证每次都严格符合格式约定。解决办法是引入结构化约束对于支持 function calling 或 JSON mode 的 API优先开启强制结构化输出模式让输出在生成阶段就受到格式约束。对于不支持强约束的开源模型可以在提示词里给一个输出模板让模型照着填内容再用解析器加兜底逻辑去容错。如果这两个都不理想还有一个暴力但有效的办法在后端加一层轻量校验和修复模型输出的 JSON 若解析失败就用一个小的修正脚本自动修复括号、引号之类的固定语法问题。结构化输出这件事别等到线上跑崩了再补要在一开始就设计进去。模型输出的不可控性是可以管理的但前提是你把管理逻辑放在系统设计里而不是事后祈祷。4.4 RAG 和微调的选型别上来就微调这两年我还观察到一种普遍冲动团队一拿到业务数据就想微调一个大模型觉得这样才算“自己的模型”。大多数时候这是错的。微调的适用条件是你有足够高质量的数据通常要几千条以上、任务有明确的风格或格式要求例如模仿某种文风、模型已有的能力不够覆盖你的场景。而 RAG 的适用条件是答案是事实性的、知识可能随时更新、数据量大且分散在文档里。RAG 更像是给模型装了一个“外部知识库接口”不用改模型本身就能把新知识塞进去。我的实践体会是先 RAG 后微调多数场景用 RAG 就够不够再加微调。先跑出一个效果尚可的基线再判断短板到底在哪里——是知识缺失、答案风格不对还是格式约束不严缺知识补 RAG风格不对才考虑微调。不要一上来就调模型调完回不去后悔都来不及。5. 上线不是终点部署、观测、反馈闭环才是 AI 工程的日常模型跑通了评估也达标了这时候才算走到了传统工程人最熟悉的领域但也是一个 AI 项目最容易猝死的地方。5.1 部署方案选择别让运维问题吃掉算法红利部署环节有几种常见路线选错了后面会非常痛苦商业 API最简单不用管 GPU、不用管扩缩容但单次成本偏高有数据出境和隐私合规风险。云函数/Serverless适合轻量推理、请求量波动大的场景自动扩缩容、按调用计费。但要注意冷启动延迟大模型加载时间如果太长就不适合。自建推理服务用 vLLM、TGI 或 Triton 架在自己的 GPU 机器上适合高并发、成本敏感的场景。但运维压力大要考虑 GPU 利用率、弹性伸缩、多模型调度。对大多数从零开始的团队我的建议是先用商业 API 或 Serverless 跑通等用户量和调用量真正上来了再逐步迁移到自建推理服务。别一开始就买一堆 GPU 卡囤着——那是把运维复杂度提前拉满AI 工程还没走稳GPU 集群已经把你拖垮了。5.2 大模型特有的可观测性比传统日志多记了几样东西传统后端的日志记录“谁在什么时候调用了什么接口、花了多久、返回了什么”。AI 服务在此基础上要额外记录几类信息否则出了问题根本无法定位输入输出全量留痕prompt 原文和模型 output 必须落库保存注意脱敏。模型出问题的时候没有这两样东西排查就是大海捞针。token 用量记录输入输出 token 数、模型名、推理耗时这些直接关联成本必须按接口维度统计。置信度或概率分如果接口支持记录模型的置信度信号便于后续做阈值兜底。用户反馈信号用户点了“有帮助/没帮助”对这个回答进行了怎样的后续操作复制、追问还是直接放弃这些信号是后续迭代最重要的燃料。我现在的项目里统一用了结构化日志每条日志都带 request_id可以串联起“用户请求 - 检索结果 - prompt 拼装 - 模型输出 - 后处理结果”的全链路。排查问题时按 request_id 一查到底效率比之前的“对着时间戳猜”高太多了。下表是我整理的核心监控指标供参考指标说明建议告警阈值接口 P95 延迟用户感知到的核心体验指标根据业务设定一般 2~5 秒内错误率4xx/5xx 及模型服务异常比例超过 1% 告警token 成本按小时统计总 token 消耗超出预算 20% 告警空回复率模型没有产出有效答案的比例超过 10% 就要查用户负反馈率用户点“没帮助”或对话中断的比例持续上升即告警5.3 兜底降级AI 答不上来的时候系统该怎么办所有 AI 系统都逃不了一个尴尬场景模型遇到了没见过的问题或者干脆输出了一堆胡言乱语。此时系统如果直接把这段垃圾抛给用户用户对产品的信任度会直线下降。我的经验是必须有至少三级兜底低置信度拦截模型输出的置信度低于阈值时不直接展示转而去检索知识库找最接近的答案。知识库兜底检索也没有匹配结果时调用一个通用回复模板提示“该问题已转人工客服”之类的引导话术。人工介入通道把“人工客服”的入口始终放在界面上并在后台记录这条未解决会话作为后续迭代的训练数据来源。兜底逻辑的意义不只是“别让用户看到烂答案”更在于形成一条“模型不会的题”的收集通道。每一次兜底都是一次数据采集后面模型的改进方向就在这些数据里。5.4 反馈闭环没有回流的 AI 工程是“一次性玩具”很多团队做完一版 AI 功能就撤了这是最可惜的。AI 系统的特点是“越用越准”前提是你把线上反馈接回数据管线形成循环。我推荐的闭环做法是线上所有接口日志按天回流到数据仓库。每日产出“bad case 清单”针对负反馈集中出现的问题进行聚类分析。每周挑选典型 bad case 加入评估集重新跑一遍提示词或模型的回归测试决定是否需要更新版本。每月做一次模型版本迭代每次迭代必须有评估集指标对比指标不降级才允许上线。这个闭环跑起来之后AI 系统会进入一个缓慢但持续的进化状态。相反没有闭环的系统第一天上线是什么水平一年后基本还是什么水平甚至因为业务数据变化而越来越不准。6. 从零到一的最小工程实践把前面所有知识点串起来前面讲了方法论最后用一个我们实际做过的“企业文档问答助手”项目把从零到一的完整过程串一遍。这个项目非常适合作为从零开始做 AI 工程的练习模板因为它的链路足够全又不至于复杂到失控。6.1 阶段一需求定义与评估集构建第 1 周需求方是企业的 HR 部门诉求是“员工经常在钉钉群问各种行政问题比如年假怎么请、报销流程是什么我们想做一个机器人自动回答”。我们和业务方一起定义了“成功”的标准主指标常见问题一次答复准确率 85%。辅助指标平均响应时间 5 秒无歧义问题准确率 80%。兜底指标模型答不上来的时候转人工且用户投诉率不上升。评估集构建用了一个很朴素的办法从企业内部的行政问答记录里抽了 500 条真实问题加上业务方补充的 100 条边界问题例如“我去年剩的调休今年还能用吗”“出差打车发票丢了怎么办”整理成标准评估集。另外准备了 50 条故意刁难的“红队问题”先不公开留着压测。6.2 阶段二数据盘点与向量化第 2 周我们把 HR 提供的文档员工手册、报销制度、休假管理办法全部收齐做了解析和清洗。这里遇到一个典型问题文档格式五花八门有 Word 有 PDF 有 PPT解析出来乱七八糟有一份 PDF 里表格直接解析成了纯文本字段全乱了。处理方案是先人工把高频问题对应的答案段落摘出来做成“答案片段库”共有 80 条条款每条配上了来源文档和页码。同时对全文做了切块向量化存入向量数据库。使用混合检索策略先走关键词召回兜底再做向量检索补充。这个策略很重要因为行政类问答中“年假”“报销”这类词非常明确关键词召回效果反而更好。6.3 阶段三模型选型与提示词设计第 3 周数据规模不大就 80 多条核心条款加文档全文效果要求是快速回答结构性问题我们直接选了商业 API 加 RAG 的方案没有做微调。提示词设计上我们明确了几件事模型被限定为“只能依据提供的知识库内容回答不能编造”如果检索不到相关片段必须回复“该问题我无法回答建议转人工”禁止自由发挥输出格式固定为“直接答案 对应条款来源”方便用户核验。这一版跑下来标准集准确率约 78%没有达标。分析 bad case 后发现主要问题有两个一是员工的问题经常带具体日期、具体金额之类的个性化信息模型被这些信息干扰反而忽略了真正的问题二是部分问题答案散落在多个条款里模型只参考了其中一条。针对这两个问题我们做了两轮调整第一轮在检索阶段加了“问题类型识别”先判断用户问的是“流程类”还是“制度类”再选择相应的检索范围第二轮在提示词里明确要求“如果问题涉及多个条款必须全部列出不要自行合并或省略”。调整后标准集准确率提升到 88%达到目标。6.4 阶段四服务化与监控部署第 4 周模型验证通过后我们把整个流程封装成一个查询服务部署在云函数上。整体流程是请求进来 - 意图识别简单分类模型- 检索合并 - prompt 拼装 - 调用大模型 - 结构化解析 - 返回结果。这套流程架构并不复杂都是现成组件拼的但把几个容易出问题的地方都预埋了处理检索结果为空时直接返回预设的兜底话术不走模型调用省一次成本。模型输出 JSON 解析失败时后端有自动修正逻辑修正不了才走兜底。每次调用全链路日志落库包含输入、输出、检索结果、耗时、token 用量、置信度。信息通过接口写回数据仓库第二天早上自动跑分布统计观察是否有用户提问类型变化和负反馈上升。6.5 阶段五上线后的第一轮迭代第 5~6 周上线第一周系统表现基本符合预期但监控数据暴露了一个很有趣的问题有 20% 左右的问题集中在“报销发票怎么贴”这个非常具体的操作上。这些问题是评估集里没有覆盖的场景模型给的是制度层面的回答——正确但不解决用户的操作困惑。于是我们做了一轮针对性优化人工整理了“发票粘贴规范”的图文说明把操作类问答单独加了一个知识库模块。第二周后这类问题的准确率从 45% 提升到 92%整体准确率也被拉到了 89%。这个例子很好地说明了反馈闭环的价值——上线不是终点数据回流才能让系统越用越准。最后聊点实在的做 AI 工程和做普通工程心态上最大的不同做传统软件工程核心追求是“确定”——代码逻辑确定、输入输出确定、行为确定。做 AI 工程核心能力变成了“在不确定中建立确定性”模型的输出大概率是好的但偶尔会发疯数据大部分是准的但总有脏数据混进来指标今天达标了明天用户问法一变可能就不达标了。你没法根除这些不确定性只能通过系统性设计去约束它、管理它、兜住它。我自己的体会是AI 工程做得越久越会回到那些最朴素的东西上目标定义清楚吗数据靠谱吗评估能复现吗兜底有吗反馈闭环转起来了吗这五件事比任何花哨的模型技巧都更重要。个人建议从零开始做 AI 工程的朋友第一年不要贪多就盯住一个小场景把数据链路、评估体系、服务部署、反馈闭环这四个模块完整地走通一遍走完你会发现自己比那些“看过十篇大模型教程”的人强太多了。这条路不性感但它真的有用。
从零开始AI工程实践：模型之外的数据、评估与部署链路详解
做AI工程这两年我最大的一个感受是网上铺天盖地的教程都在教你怎么训模型、怎么调 prompt真正告诉你“一个 AI 功能从想法到上线中间到底要经历什么”的内容少得可怜。“ai-engineering-from-scratch”这个题目字面意思是“从零开始做 AI 工程”。我理解它想表达的不是“从零开始学机器学习”而是“从零开始把一个 AI 想法变成可运行、可维护、可评估、真正有人用的系统”。我见过太多团队和个人算法能力不差模型也跑得通但一到“工程化”就卡壳要么评估标准模糊改了一版提示词不知道是变好还是变坏要么数据链路断的模型训练完喂进去的都是脏数据要么上线之后没有监控用户反馈啥也拉不回来。这篇文章我想好好聊聊一个零基础的团队或个人要把 AI 工程这件事从零搭起来到底该先把哪些地基打牢。我不会讲那些“会用某个框架就行”的速成套路而是把我实际踩过的坑、反复验证过的方法、认为真正值得投入时间的地方全部摊开来讲。1. 先想清楚AI 工程和“调模型”之间隔着一整条生产链路很多人以为 AI 工程就是“训练一个模型再用它”这是最大的误解。真实世界里的 AI 工程是一套从需求定义到数据准备、模型构建、部署上线、监控迭代的完整系统模型训练只是其中一环。1.1 为什么“能跑通的 Demo”距离“能上线的产品”那么远我在不少项目里见过同一个场景Jupyter Notebook 里模型表现惊艳demo 演示时掌声一片结果一上生产环境就原形毕露。不是模型变笨了而是训练环境里根本没有那些生产环境的约束——真实数据的分布不一样、请求并发量一上来延迟就失控、用户输入的方式和测试集不一样这些问题单靠调模型参数是解决不了的。把 AI 工程拆开看它其实是几条链路并行数据链路从数据采集、清洗、标注、版本管理到训练集/评估集构建。传统软件开发不碰数据也能写代码AI 工程不行数据的质量直接决定模型质量上限。模型链路选型、训练/微调或提示词调优、评估、版本管理。这一环是很多人最熟悉的部分但往往也是被过度关注的部分。服务链路模型部署、推理加速、请求处理、缓存降级、监控告警。这个部分常常被低估——模型再好接口不稳定、响应慢业务方照样不买单。反馈链路线上日志回捞、用户反馈收集、bad case 分析、数据回流再训练。这是很多团队最缺失的部分但没有闭环的 AI 工程就是一次性工程做一版就死了。理解了这几条链路你就明白为什么我会说“能跑通的 Demo”离“能上线的产品”还有很长一段路。Demo 只需要证明“模型能做这件事”产品需要证明“这件事在真实环境里能稳定、可靠、持续地做”。1.2 AI 工程师和算法工程师、数据工程师的分工边界这两年团队招人最头疼的就是岗位边界。算法工程师、机器学习工程师、AI 工程师、数据工程师听起来像一回事实际上干的事差很多。角色核心关注点典型产出物日常工具链算法工程师/研究员模型精度、方法创新论文、实验报告、新模型结构PyTorch、TensorFlow、NotebookAI 工程师全链路落地、稳定性、效果可评估可上线的服务、监控系统、评估体系Docker、K8s、MLflow、监控告警数据工程师数据流转、存储、治理数据管道、数仓、特征平台Spark、Flink、Airflow、SQL数据分析师业务洞察归因分析报告、指标看板SQL、BI 工具、Python一个 AI 工程师更像是“翻译官”和“总包工头”把业务需求翻译成 AI 能解的问题把算法能力包装成业务能用的服务。算法工程师关心“能不能更高”AI 工程师关心“能不能更稳”。两者不矛盾但一个从零开始做 AI 工程的团队最缺的往往是后者。1.3 一个从想法到落地的完整路径长什么样我建议所有新团队把 AI 项目拆成五个阶段来过一遍不要跳过任何一步需求定义业务方到底要解决什么问题成功的标准是什么没有 AI 时现状如何。数据盘点与准备现有数据在哪里、什么格式、多少量、质量如何没有数据先想怎么造。方案选型与验证基于数据规模、成本预算、效果要求决定用开源模型、商业 API 还是传统机器学习方案。工程化落地把验证通过的方案包装成稳定服务配套监控和回滚机制。上线监控与迭代建立线上评估机制形成数据回流闭环持续优化。这套流程走了几轮之后你会发现真正耗时间的往往不是“调模型”而是“把数据搞清楚”“把评估做准”“把服务做稳”。理解了这一点AI 工程就算入门一半了。2. 从零入手的第一步把“做什么”和“怎么算做得好”定死很多项目翻车不是技术不行而是直接从“我们做一个智能客服”跳到“我们来微调一个大模型”中间跳过了最关键的“怎么算做得好”。2.1 需求澄清别把业务诉求当成技术方案曾有一个业务方找到我张口就是“我们需要一个能自动写文案的 AI”。这听起来很清楚但一问细节就露馅了是写什么类型的文案推广海报文案还是公众号长文目标受众是谁有什么风格偏好分发渠道是哪个平台平台对字数、敏感词有什么限制如果这些问题没搞清楚技术方案就只能靠猜。我的习惯是把需求拆成三层来对齐业务目标层这件事做成了业务上怎么体现比如客服机器人是降低人工咨询量是提升响应速度还是提升满意度。用户场景层用户会在什么场景下使用、输入什么内容、期望得到什么形式的回复。技术边界层输入输出是什么格式、延迟要求多少秒、出错时允许怎么兜底。这三层里任何一层没对齐后面做出来的东西都会跑偏。尤其是业务目标层它决定了你后面怎么设计评估指标——评估标准必须从业务目标里推导出来而不是从模型输出里随便挑一个顺眼的。2.2 把业务目标翻译成可测量的技术指标这里给一个我的实操例子。之前做客服助手项目业务方最初给的指标是“提升客户满意度”。这个指标太虚了没法直接用来评估一个模型好不好。我们做了一轮翻译客户满意度低的原因主要是等待时间长、问题解决率低。所以把这个目标拆成两个技术可测的指标问题一次解决率用户发起的咨询在不转人工的情况下得到有效解决的比例。平均处理时长从用户提问到得到有效回答的时间包括排队时间、模型调用延迟、兜底转接的时间。再往下拆模型的评估指标就清楚了对“问题能否被正确识别并匹配到合适答案”的准确率、对话轮次的平均次数、意图分类的准确率与召回率等。这个翻译过程就是 AI 工程里最基础也最重要的“指标化”工作。你连“做得好”都没定义清楚后面调提示词、选模型、对比版本都会变成拍脑袋。2.3 评估集没有评估集就不要开始任何调优我认为 AI 工程和传统软件工程最大的不同点在于前者必须有一个“评估集”作为工程的基准线。没有评估集的 AI 工程几乎等于盲人摸象——每次改动模型或提示词你都只能凭感觉判断效果变化。评估集不是简单的测试集它至少包含三层标准集覆盖核心场景的、有标准答案的数据集用来衡量模型效果是否达标。边界集覆盖边界情况的极端样例比如超长输入、网络用语、同形字干扰、不文明表达用来压测模型鲁棒性。红队集故意设计来“攻击”系统的样例用来探测模型弱点。在我们客服助手的项目里标准集是历史工单里抽出来的常见问题边界集里放了很多带有错别字的长问题、口语化严重的问法、一次问多件事的组合提问。这些数据看着不起眼但在上线后起到的作用比标准集还大——因为它们才是真实世界里最常见的输入形态。2.4 一份“可执行技术规格书”的最小检查清单从需求到技术方案我习惯写一份一页纸的技术规格书包含以下要素用户输入样例 5~10 条以及每条对应的理想输出。边界情况和失败兜底策略模型答不出来怎么办超时怎么办违反安全规范怎么拦截效果指标主指标 1~2 个辅助指标 2~3 个每个指标定义清楚统计口径。成本和性能约束单次调用的预算上限、接口延迟上限、并发峰值预估。数据隐私和合规要求涉及哪些敏感字段是否需要脱敏数据存储位置有没有限制。这份规格书写完不要急着去找模型。先拿给业务方逐条过确认他们对“成功”的理解和你一致。通常这一轮就能发现很多之前心照不宣的误解省下后面返工的钱。3. 数据这一关喂给模型的东西决定工程的上限模型选得再好提示词写得再漂亮数据脏乱差一样歇菜。这是我被现实教育过很多次以后才彻底明白的。3.1 一次真实的“数据翻车”复盘我踩过最大的数据坑是做意图分类项目的时候。当时为了赶进度从网上爬了一大批公开对话数据加上自己标注了一部分凑了十万条样本。在全球标准测试集上效果不错准确率九成左右。结果一上线真实准确率直接掉到六成多用户疯狂投诉。后来排查发现三个致命问题数据分布和真实场景不一致训练数据里用户提问都规规矩矩真实用户大量使用口语、方言、错别字、中英混杂模型根本没见过这些输入形态。数据泄漏爬来的公开数据里有些本身就是测试集的一部分评估结果虚高。重复数据严重清洗时没做去重某几种常见问法出现了几千条模型严重过拟合到这些模式上其他问法基本不会了。从那以后我立了一条规矩训练数据必须和真实业务数据同源评估集必须和训练集严格隔离任何外部数据进来都要先做去重和泄漏检查。3.2 从“野数据”到“干净的工程数据”要过五关我在实际项目里总结了一套数据清洗的流程基本可以照着抄格式统一把所有来源的数据转成统一的 schema常见字段对齐例如文本统一编码格式时间戳统一时区。去重去噪严格去重尤其是用余弦相似度搭配阈值去近似重复去掉无意义文本例如纯广告、乱码、长度过短的碎片。敏感信息过滤用正则加模型双保险把手机号、身份证、银行卡、地址等敏感信息脱敏掉。标签质量校验对标注数据做交叉验证随机抽 10% 校验标注一致性不合格就退回重标。分布统计统计类别分布、长度分布、高频词汇看数据是否出现严重倾斜。这五关做好了数据才算具备进入训练管线的资格。过程很琐碎但它决定了你后面的模型能走多远。3.3 标注环节怎么管理才能不返工说到数据就逃不开标注。很多团队觉得标注就是“找人点一点”实际上标注管理做不好数据质量无从谈起。我建议标注环节注意这几件事标注规范文档先行写一份带正例负例的规范文档所有标注人员必须先读、先试标、通过了再正式开始。标注一致性检查同一批数据分给两个人标比对一致率低于 85% 就要回去重新讨论标准。疑难样本沉淀标注过程中发现拿不准的样本单独建一个“疑难池”定期和业务方一起讨论讨论结果回流到标注规范里。标注数据版本管理标注数据要像代码一样做版本管理。今天改了一条标准昨天标的那批数据要不要重新处理必须记录清楚。很多团队模型效果差不是模型不行而是训练数据的标签本身就是错的。你用错误的标签训练再好的模型也只是在拟合错误。3.4 LLM 时代的数据工程有什么新变化以前做 AI 工程大量时间花在整理标注数据上。大模型普及之后情况变了很多但“数据决定上限”这个核心逻辑没变。现在多了两类新的数据工作一类是少量示例库的设计。改用大模型做任务后你不再需要海量标注数据做训练而是需要精挑细选的少量示例放进提示词里让模型参考。这些示例怎么选、怎么排版、怎么覆盖不同类型就成为新的工程点。选得好效果立竿见影选不好给再多示例也是噪声。另一类是合成数据。用大模型生成训练数据或评估数据在数据不足时非常有效。但合成数据有个陷阱它会把模型本身的偏见过滤出来用的时候必须验真。我见过一个团队用 GPT 系列模型生成了一批“反事实样本”做数据增强结果模型学到了一堆不可能出现的场景反而干扰了正常判断。数据工作模块总结起来就一句话先盘数据再谈模型。你连自己手里的数据长什么样都不知道就急着上大模型最终只能得到一个“在自己的数据上两眼一抹黑”的昂贵玩具。4. 模型选型与提示词调优同样逃不掉“工程化思维”模型环节是多数人最兴奋的部分也是我最想泼冷水的地方。因为越容易让人兴奋的地方越容易忽略工程纪律。4.1 先算账再选模型三个决策依据团队跑来问我“该选什么模型”的时候我一般会反问三个问题你的数据量有多少质量如何如果只有几百条标注数据微调大模型大概率不如用现成 API 加少量示例效果好。你的效果要求有多高如果任务对准确率要求极高且领域专业性强可能需要微调开源模型甚至训练专属小模型如果只是通用场景的问答、摘要商业 API 往往够用。你的成本预算和部署环境是什么商业 API 按次付费开源模型要自己买 GPU 或租云资源。不仅要算训练成本更要算推理成本——线上跑一天花的钱往往比训练一次还多。我做过一个判断框架供大家参考场景特征推荐路线数据少、场景通用、预算有限商业 API 少量示例先跑通数据中等、领域特定、有隐私要求开源模型微调 私有化部署数据海量、实时性要求高、成本敏感蒸馏一个小模型部署或混合架构数据敏感、禁止出域必须本地部署参数规模只能压缩这套框架不能解决所有问题但至少能帮你避免“用大炮打蚊子”和“为了省钱把效果搞得不可用”两个极端。4.2 提示词工程不是玄学而是一门需要留痕的工程很多人对提示词工程的理解是“把指令写得更清楚一点”这太浅了。提示词工程真正的工程点在于提示词是代码需要版本管理、测试用例和回归验证。我自己做提示词调优的标准流程是这样的写初版提示词把任务描述、示例、输出格式全部结构化写清楚。跑回归集用前面建的评估集跑一遍记录指标基线。单点修改一次只改一个变量要么是示例数量要么是输出格式约束要么是风格描述改完跑一遍回归集对比。做 A/B 记录每个版本的结果存下来附上指标变化形成提示词版本历史记录。固化版本当某个版本指标稳定达标就冻结它为正式版本走代码一样的变更流程。我所在的团队用的是非常朴素的方案每条提示词对应一个 markdown 文件存进 Git 仓库文件名带版本号里面标注了作者、修改日期、评估集链接、指标结果。没有用那些花哨的提示词管理平台但该留痕的、该能追溯的一样不缺。4.3 结构化输出让模型的“自由发挥”变成“规定动作”接入大模型之后被问得最多的一个问题是“模型输出的内容格式不稳定有时候多个 JSON 字段有时候又丢了我解析老是报错怎么办”这个问题属于 LLM 应用里最经典的工程坑。模型的输出本质上是概率采样不可能保证每次都严格符合格式约定。解决办法是引入结构化约束对于支持 function calling 或 JSON mode 的 API优先开启强制结构化输出模式让输出在生成阶段就受到格式约束。对于不支持强约束的开源模型可以在提示词里给一个输出模板让模型照着填内容再用解析器加兜底逻辑去容错。如果这两个都不理想还有一个暴力但有效的办法在后端加一层轻量校验和修复模型输出的 JSON 若解析失败就用一个小的修正脚本自动修复括号、引号之类的固定语法问题。结构化输出这件事别等到线上跑崩了再补要在一开始就设计进去。模型输出的不可控性是可以管理的但前提是你把管理逻辑放在系统设计里而不是事后祈祷。4.4 RAG 和微调的选型别上来就微调这两年我还观察到一种普遍冲动团队一拿到业务数据就想微调一个大模型觉得这样才算“自己的模型”。大多数时候这是错的。微调的适用条件是你有足够高质量的数据通常要几千条以上、任务有明确的风格或格式要求例如模仿某种文风、模型已有的能力不够覆盖你的场景。而 RAG 的适用条件是答案是事实性的、知识可能随时更新、数据量大且分散在文档里。RAG 更像是给模型装了一个“外部知识库接口”不用改模型本身就能把新知识塞进去。我的实践体会是先 RAG 后微调多数场景用 RAG 就够不够再加微调。先跑出一个效果尚可的基线再判断短板到底在哪里——是知识缺失、答案风格不对还是格式约束不严缺知识补 RAG风格不对才考虑微调。不要一上来就调模型调完回不去后悔都来不及。5. 上线不是终点部署、观测、反馈闭环才是 AI 工程的日常模型跑通了评估也达标了这时候才算走到了传统工程人最熟悉的领域但也是一个 AI 项目最容易猝死的地方。5.1 部署方案选择别让运维问题吃掉算法红利部署环节有几种常见路线选错了后面会非常痛苦商业 API最简单不用管 GPU、不用管扩缩容但单次成本偏高有数据出境和隐私合规风险。云函数/Serverless适合轻量推理、请求量波动大的场景自动扩缩容、按调用计费。但要注意冷启动延迟大模型加载时间如果太长就不适合。自建推理服务用 vLLM、TGI 或 Triton 架在自己的 GPU 机器上适合高并发、成本敏感的场景。但运维压力大要考虑 GPU 利用率、弹性伸缩、多模型调度。对大多数从零开始的团队我的建议是先用商业 API 或 Serverless 跑通等用户量和调用量真正上来了再逐步迁移到自建推理服务。别一开始就买一堆 GPU 卡囤着——那是把运维复杂度提前拉满AI 工程还没走稳GPU 集群已经把你拖垮了。5.2 大模型特有的可观测性比传统日志多记了几样东西传统后端的日志记录“谁在什么时候调用了什么接口、花了多久、返回了什么”。AI 服务在此基础上要额外记录几类信息否则出了问题根本无法定位输入输出全量留痕prompt 原文和模型 output 必须落库保存注意脱敏。模型出问题的时候没有这两样东西排查就是大海捞针。token 用量记录输入输出 token 数、模型名、推理耗时这些直接关联成本必须按接口维度统计。置信度或概率分如果接口支持记录模型的置信度信号便于后续做阈值兜底。用户反馈信号用户点了“有帮助/没帮助”对这个回答进行了怎样的后续操作复制、追问还是直接放弃这些信号是后续迭代最重要的燃料。我现在的项目里统一用了结构化日志每条日志都带 request_id可以串联起“用户请求 - 检索结果 - prompt 拼装 - 模型输出 - 后处理结果”的全链路。排查问题时按 request_id 一查到底效率比之前的“对着时间戳猜”高太多了。下表是我整理的核心监控指标供参考指标说明建议告警阈值接口 P95 延迟用户感知到的核心体验指标根据业务设定一般 2~5 秒内错误率4xx/5xx 及模型服务异常比例超过 1% 告警token 成本按小时统计总 token 消耗超出预算 20% 告警空回复率模型没有产出有效答案的比例超过 10% 就要查用户负反馈率用户点“没帮助”或对话中断的比例持续上升即告警5.3 兜底降级AI 答不上来的时候系统该怎么办所有 AI 系统都逃不了一个尴尬场景模型遇到了没见过的问题或者干脆输出了一堆胡言乱语。此时系统如果直接把这段垃圾抛给用户用户对产品的信任度会直线下降。我的经验是必须有至少三级兜底低置信度拦截模型输出的置信度低于阈值时不直接展示转而去检索知识库找最接近的答案。知识库兜底检索也没有匹配结果时调用一个通用回复模板提示“该问题已转人工客服”之类的引导话术。人工介入通道把“人工客服”的入口始终放在界面上并在后台记录这条未解决会话作为后续迭代的训练数据来源。兜底逻辑的意义不只是“别让用户看到烂答案”更在于形成一条“模型不会的题”的收集通道。每一次兜底都是一次数据采集后面模型的改进方向就在这些数据里。5.4 反馈闭环没有回流的 AI 工程是“一次性玩具”很多团队做完一版 AI 功能就撤了这是最可惜的。AI 系统的特点是“越用越准”前提是你把线上反馈接回数据管线形成循环。我推荐的闭环做法是线上所有接口日志按天回流到数据仓库。每日产出“bad case 清单”针对负反馈集中出现的问题进行聚类分析。每周挑选典型 bad case 加入评估集重新跑一遍提示词或模型的回归测试决定是否需要更新版本。每月做一次模型版本迭代每次迭代必须有评估集指标对比指标不降级才允许上线。这个闭环跑起来之后AI 系统会进入一个缓慢但持续的进化状态。相反没有闭环的系统第一天上线是什么水平一年后基本还是什么水平甚至因为业务数据变化而越来越不准。6. 从零到一的最小工程实践把前面所有知识点串起来前面讲了方法论最后用一个我们实际做过的“企业文档问答助手”项目把从零到一的完整过程串一遍。这个项目非常适合作为从零开始做 AI 工程的练习模板因为它的链路足够全又不至于复杂到失控。6.1 阶段一需求定义与评估集构建第 1 周需求方是企业的 HR 部门诉求是“员工经常在钉钉群问各种行政问题比如年假怎么请、报销流程是什么我们想做一个机器人自动回答”。我们和业务方一起定义了“成功”的标准主指标常见问题一次答复准确率 85%。辅助指标平均响应时间 5 秒无歧义问题准确率 80%。兜底指标模型答不上来的时候转人工且用户投诉率不上升。评估集构建用了一个很朴素的办法从企业内部的行政问答记录里抽了 500 条真实问题加上业务方补充的 100 条边界问题例如“我去年剩的调休今年还能用吗”“出差打车发票丢了怎么办”整理成标准评估集。另外准备了 50 条故意刁难的“红队问题”先不公开留着压测。6.2 阶段二数据盘点与向量化第 2 周我们把 HR 提供的文档员工手册、报销制度、休假管理办法全部收齐做了解析和清洗。这里遇到一个典型问题文档格式五花八门有 Word 有 PDF 有 PPT解析出来乱七八糟有一份 PDF 里表格直接解析成了纯文本字段全乱了。处理方案是先人工把高频问题对应的答案段落摘出来做成“答案片段库”共有 80 条条款每条配上了来源文档和页码。同时对全文做了切块向量化存入向量数据库。使用混合检索策略先走关键词召回兜底再做向量检索补充。这个策略很重要因为行政类问答中“年假”“报销”这类词非常明确关键词召回效果反而更好。6.3 阶段三模型选型与提示词设计第 3 周数据规模不大就 80 多条核心条款加文档全文效果要求是快速回答结构性问题我们直接选了商业 API 加 RAG 的方案没有做微调。提示词设计上我们明确了几件事模型被限定为“只能依据提供的知识库内容回答不能编造”如果检索不到相关片段必须回复“该问题我无法回答建议转人工”禁止自由发挥输出格式固定为“直接答案 对应条款来源”方便用户核验。这一版跑下来标准集准确率约 78%没有达标。分析 bad case 后发现主要问题有两个一是员工的问题经常带具体日期、具体金额之类的个性化信息模型被这些信息干扰反而忽略了真正的问题二是部分问题答案散落在多个条款里模型只参考了其中一条。针对这两个问题我们做了两轮调整第一轮在检索阶段加了“问题类型识别”先判断用户问的是“流程类”还是“制度类”再选择相应的检索范围第二轮在提示词里明确要求“如果问题涉及多个条款必须全部列出不要自行合并或省略”。调整后标准集准确率提升到 88%达到目标。6.4 阶段四服务化与监控部署第 4 周模型验证通过后我们把整个流程封装成一个查询服务部署在云函数上。整体流程是请求进来 - 意图识别简单分类模型- 检索合并 - prompt 拼装 - 调用大模型 - 结构化解析 - 返回结果。这套流程架构并不复杂都是现成组件拼的但把几个容易出问题的地方都预埋了处理检索结果为空时直接返回预设的兜底话术不走模型调用省一次成本。模型输出 JSON 解析失败时后端有自动修正逻辑修正不了才走兜底。每次调用全链路日志落库包含输入、输出、检索结果、耗时、token 用量、置信度。信息通过接口写回数据仓库第二天早上自动跑分布统计观察是否有用户提问类型变化和负反馈上升。6.5 阶段五上线后的第一轮迭代第 5~6 周上线第一周系统表现基本符合预期但监控数据暴露了一个很有趣的问题有 20% 左右的问题集中在“报销发票怎么贴”这个非常具体的操作上。这些问题是评估集里没有覆盖的场景模型给的是制度层面的回答——正确但不解决用户的操作困惑。于是我们做了一轮针对性优化人工整理了“发票粘贴规范”的图文说明把操作类问答单独加了一个知识库模块。第二周后这类问题的准确率从 45% 提升到 92%整体准确率也被拉到了 89%。这个例子很好地说明了反馈闭环的价值——上线不是终点数据回流才能让系统越用越准。最后聊点实在的做 AI 工程和做普通工程心态上最大的不同做传统软件工程核心追求是“确定”——代码逻辑确定、输入输出确定、行为确定。做 AI 工程核心能力变成了“在不确定中建立确定性”模型的输出大概率是好的但偶尔会发疯数据大部分是准的但总有脏数据混进来指标今天达标了明天用户问法一变可能就不达标了。你没法根除这些不确定性只能通过系统性设计去约束它、管理它、兜住它。我自己的体会是AI 工程做得越久越会回到那些最朴素的东西上目标定义清楚吗数据靠谱吗评估能复现吗兜底有吗反馈闭环转起来了吗这五件事比任何花哨的模型技巧都更重要。个人建议从零开始做 AI 工程的朋友第一年不要贪多就盯住一个小场景把数据链路、评估体系、服务部署、反馈闭环这四个模块完整地走通一遍走完你会发现自己比那些“看过十篇大模型教程”的人强太多了。这条路不性感但它真的有用。