三年前我第一次以AI工程师的身份独立负责一个项目的时候，差点把整个项目做没了。不是模型训练不出来——恰恰相反，测试集上的准确率、召回率、F1分数都漂亮得能拿出去炫耀。但模型一上真实数据就崩，业务方看着我的眼神从期待变成了怀疑。复盘时我才意识到，问题根源不在"AI"，而在"工程"：数据分布变了没人知道，训练和推理的预处理逻辑不一致，评估集是精挑细选的干净样本，线上却是满地垃圾输入。这段时间我最大的收获，就是彻底想明白了一件事：AI工程不是"把模型训出来"，而是"在充满不确定性的条件下，稳定可靠地把模型建出来、部署上去、持续维护好"。
这篇文章想写的，就是我对"ai-engineering-from-scratch"这件事的完整理解——从零开始做AI工程，到底意味着什么，需要具备哪些能力，按什么顺序成长，以及过程中最容易被忽视的致命细节。无论你是刚转行的新人、带团队的负责人、还是已经调过不少模型但总觉得"差口气"的工程师，都应该能从里面找到对应自己阶段的东西。
1. 为什么把"AI工程"单独拎出来说——从一段失败的面试经历讲起
1.1 那段让我重新审视AI工程概念的经历
有一次我面试一个候选人，简历很亮眼：计算机视觉方向、发表过论文、熟练使用PyTorch和TensorFlow、做过三个"AI项目"。我问了一个自认为很基础的问题："你训练好的模型，是怎么部署到生产环境里的？"
他愣了一下，回答说："我都是把模型文件发给后端，他们自己处理。"
我又问："那线上效果变差了，你怎么判断是数据问题、模型问题还是特征问题？"这次沉默的时间更长了。
这位候选人的技术水平不算差，但他从未完整经历过一个AI系统的生命周期。这恰好点中了"AI工程"区别于"AI研究"或"调模型"的核心：要的是从业务问题到系统稳定运行的全链路能力，而不是某一个环节的熟练技巧。
1.2 AI工程与"调模型"的本质区别
很多人对AI工程的第一印象是：找个开源模型、准备数据集、跑一轮训练、拿到指标、发个总结。这套流程下去，产出的是一个"能跑的模型"，但不是一个"能用的系统"。
"能跑的模型"和"能用的系统"之间的差距，用一句话概括就是：前者在固定环境下做固定的事，后者必须在不固定环境下持续做正确的事。模型训练时，你的数据是静止的、标签是确定的、硬件环境是固定的；但一旦进入生产，数据会漂移、用户输入会千奇百怪、依赖库会升级、GPU可能会挂掉、QPS会突然飙升——这些都是工程问题。
我之前在团队里做过一次小范围讨论，让大家把自己理解的"AI工程"写在一张纸上。收到的答案五花八门：有人写"训练和调参"，有人写"数据清洗"，有人写"模型部署"，甚至有人写"搞AIGC的"。这些都不算错，但都只是整个拼图的一块。
在我看来，AI工程是"以模型为核心、以数据为燃料、以稳定性为目标"的软件系统工程。它覆盖需求分析、数据工程、模型训练、评估验证、部署监控、迭代更新六个环节，任何一个环节掉了链子，整个系统都会反馈到线上效果上。
1.3 什么人才算真正会AI工程
根据我带团队和面试候选人的经验，真正"会AI工程"的人通常具备三个特征，这三条可以当作自测标准。
第一，能讲清楚"为什么这个方案能解决这个业务问题"，而不是"因为别人都这么做"。例如做文本分类，你是直接用预训练模型微调，还是先跑一个朴素贝叶斯基线？前者的效果大概率更好，但如果业务场景是标签随时变化的长尾分类，固定结构的分类头可能不如"Embedding+向量检索"灵活。能根据业务约束选技术方案的人，才是工程师；只会套SOTA模型的人，是工具人。
第二，能从端到端的视角串联问题。模型在离线评估时F1是0.9，上线后掉到0.6，你能不能快速定位是哪个环节出了问题？这需要你对数据流转的每一步都有清晰认知——从原始日志到特征工程再到训练集，从模型输出到业务决策再到反馈回流。
第三，有"防呆"意识。训练脚本要可复现，实验记录要留痕，模型版本要可回滚，线上推理要有监控告警。这些不产生任何纸面指标，但它们决定了项目能不能长期跑下去。
2. AI工程与传统软件工程的分野：五个决定性的差异
2.1 不确定性是第一公民
传统软件工程里，if-else的逻辑是确定的：输入A，永远得到B。但AI系统的行为是由数据和参数共同决定的，同样的代码、不同的训练数据，产出的是两种不同的模型；即便是相同的代码和相同的数据，受随机初始化影响，跑两次也可能得到略有差异的结果。
这个差异带来的直接后果是：你不能用传统软件工程的"确定性思维"来管理AI系统。传统软件出bug了，查堆栈、找逻辑漏洞就行；AI系统出问题了，可能没有任何"错误"，只是概率分布悄悄变了。我见过太多从传统后端转过来的工程师，在AI项目上抓狂，因为他们习惯性地找"哪里出的错"，而AI系统的错误经常是渐变式的、统计层面的。
应对这种不确定性的工程手段是：为所有可能变化的环节设置"可观测点"，包括数据分布、特征分布、输出分布、模型性能指标。没有观测就没有掌控。
2.2 数据比代码更值得用心
传统软件工程的核心资产是代码，数据只是输入输出。AI工程把这件事完全倒过来了：模型参数是从数据中学习出来的，代码（包括训练脚本、数据处理逻辑）只是在"帮助数据发挥效用"。同样的代码，数据质量不同，产物天差地别。
有个经典的比喻：数据是原料，代码是加工流水线，模型是成品。原料变质了，流水线再先进也产不出合格品。在我自己的项目里，最花时间、最磨耐心的永远是数据处理那一关：格式统一、缺失值处理、去重去噪、标签校准。这些工作听起来毫无技术含量，但它的ROI比调任何超参数都高。
数据工程的另一个隐形要点是"数据血缘"——你要能说清楚每一批数据的来源、用途和流向。生产环境里的线上推理结果经过采样回流成下一轮训练数据，这个闭环一旦断裂，模型就会慢慢偏离真实分布。
2.3 评估体系从布尔变成概率
传统软件用单元测试、集成测试来做通过/不通过的判断，边界是清晰的。AI系统的评估本质上是统计学活动：用一批带标签的数据去估计模型在真实场景中的表现，这个估计天然带有误差和置信区间。
所以AI工程的"测试"应该分两层。第一层是技术层的离线评估，包括精确率、召回率、AUC、人工抽检等；第二层是业务层的指标验证，比如"这个模型真的帮客服减少了转派率吗"。很多项目死在第二层——离线指标合格，但业务方不认可模型的实际价值，因为离线评估的假设和真实业务场景根本不匹配。
我常用的做法是：离线评估不只看单一指标，而是按业务的分支场景拆分。例如一个工单分类模型，按问题类型、按客户等级、按文本长度分别评估，你会发现不同切片上的表现差异巨大。只看平均指标的团队，迟早会翻车。
2.4 迭代模式发生根本变化：训练-评估-数据-再训练
传统软件迭代是代码维度的：改需求、改代码、发布、验证。AI系统多了一条数据维度的循环：收集新数据、清洗标注、合并旧数据、重新训练、评估发布。而且这条循环的频率和成本都远高于传统上线。
这意味着AI工程的规划和排期方式也要改变。你不能用"六周迭代一个版本"这种纯软件节奏去管理AI项目，因为你永远不知道下一轮数据质量怎么样、训练过程中会不会遇到收敛问题。我习惯把AI项目的排期设计成"数据先行、模型并行"，即先把数据管线跑通、把标注规范定好，然后模型训练可以快速跟进；数据管线永远是主线任务。
2.5 基础设施与依赖管理更复杂了
传统后端只需要管理代码依赖和运行环境，AI工程的基础设施涉及更多层次：数据存储与版本管理、特征存储、训练资源调度、模型仓库、推理加速（GPU/CPU混合部署）、线上监控告警系统。这些组件任何一个出问题，都会影响全局。
印象很深的一次事故：我们的推理服务一直跑得好好的，某天忽然超时率飙升。排查半天发现不是模型变慢了，而是上游数据源把返回格式从JSON换成了XML，解析代码没做兼容，导致每次请求都要多耗几百毫秒。这个问题的本质是"模型外部的依赖变化"，但它最终影响的是AI系统的服务质量。所以AI工程师必须对整条链路的依赖关系了如指掌，并且给关键依赖设置熔断和降级策略。
3. 从零起步的进阶路径：我建议的入门顺序与理由
3.1 阶段一：数学与编程——"够用"就好，但必须真够用
聊到从零开始学AI，很多人第一反应就是啃高数、啃线性代数、啃概率论。我不反对打基础，但反对"从入门到放弃"式的死磕。以工程应用为目标，数学知识的"够用线"其实是可以划出来的：
- 线性代数：会矩阵乘法、理解向量的几何意义、明白特征值和特征向量的直觉概念。这是理解Embedding和降维的基础。
- 概率统计：理解分布、期望、方差、最大似然估计、贝叶斯思想。这是理解损失函数和模型不确定性的基础。
- 微积分：重点是链式法则和梯度下降的直觉理解，不需要会手推复杂偏导。
编程方面，Python是绝对的主力语言，但"会写Python"和"能用Python做工程"是两码事。工程意义上的Python能力至少包括：面向对象组织代码、环境管理（conda/venv）、依赖管理（requirements/pyproject）、单元测试、日志规范、性能调优（向量化、并行）。这些技能是进入真实项目的敲门砖。
我的建议是不要用超过两周的时间集中补数学，而是在后续的项目实践中边用边补。对成年人来说，带着具体问题学概念，效率远高于空对空啃教材。
3.2 阶段二：用一个小项目建立端到端感觉
理论学再多，不跑通一个完整项目，你永远不知道自己哪里不会。我见过太多人卡在这个阶段：数据集下载了、教程跟着跑了、代码能执行了，但让他独立处理一个新问题，大脑一片空白。
破除这个卡点的方法是主动做一个"麻雀虽小五脏俱全"的端到端项目。别用Kaggle上已经处理好的竞赛数据集，自己从原始数据开始走一遍全流程。什么样的项目算合格？举个例子：收集一批客服对话记录或评论数据，自己定分类体系、设计标注规范、清洗文本、训练一个分类模型、做成一个带简单Web界面的Demo、再设计几组边界测试用例验证它。
这个小小的项目，本质上把AI工程的所有核心模块都过了一遍。做完后你对"从数据到模型再到服务"全流程就有了肌肉记忆。这个阶段不需要追求模型效果多强，而是要体验和理解每个环节的输入输出和常见问题。
3.3 阶段三：把模型变成产品——工程化能力的分水岭
训练好模型只完成了40%的工作，后面还有60%属于工程化。这个阶段要刻意练习几个关键能力：
第一，模型服务化。把训练好的模型封装成HTTP接口还是用gRPC？用FastAPI还是Flask？如何处理批量请求和并发？这些决定线上服务的质量和吞吐。
第二，实验管理。训练过程中的数据版本、代码版本、超参数、评估结果，都要能追溯。项目跑三个月后，你还能不能复现第一次实验的效果？我用过MLflow，也写过最简单粗暴的Excel表格记录实验，经验是：工具不一定要多高级，但"版本可追溯"这件事必须做到。
第三，部署与监控。模型上线只是开始，你需要设计监控指标：请求量、延迟、模型输出的置信度分布、预测结果的类别分布。任何一个指标异常，都可能是数据漂移的前兆。
这个阶段很难靠看视频学会，强烈建议参与一个真实项目或者做一个超写实的模拟项目。
3.4 阶段四：用提示词工程和Agent扩展能力边界
如果说前三阶段是经典机器学习工程的底盘，那现阶段最重要的变量就是大语言模型带来的范式扩展。提示词工程（Prompt Engineering）和智能体（Agent）不是空中楼阁，它们是构建复杂AI应用的新方式。
提示词工程的关键能力有两个：一是把业务需求翻译成对模型的清晰指令（包括角色设定、任务描述、输入输出格式、约束条件、示例），二是设计多轮交互的链路——当单一Prompt回答不了复杂问题时，把任务拆解成多个子任务，每个子任务单独调模型，再汇总结果。
Agent则进一步把"模型调用"变成"模型自主编排"。在设计Agent系统时，我的核心原则是：明确Agent的工具边界，设计好任务路由和中间校验，避免"自由发挥"导致不可控。之前做一个内部问答助手时，我让Agent自主决定是否调用检索工具，结果它经常在简单问题上过度调用外部工具，导致响应慢、费用高。后来改成规则路由：先根据问题类型判断是否需要外部知识，再决定是否触发检索。这个教训说明：Agent再聪明，工程上也要有边界和兜底。
对大模型项目的工程化，我单独说几条经验：一是上下文窗口是稀缺资源，尽可能精简；二是输出的JSON解析一定要容错，模型偶尔会返回不规范格式；三是成本控制要前置，每次调用的Token开销要计入监控指标。
4. 一个真实项目的完整拆解：从业务问题到线上推理
4.1 业务问题定义与数据可行性判断
理论篇幅够多了，我们来走一个真实的项目。就用最经典的"客服工单自动分类"来拆解，这个场景我做过不止一次，非常典型。
第一步永远是定义问题，而不是选模型。业务方会告诉你："我希望系统自动把工单分给对应部门。"这句话信息量严重不足。你要追问的是：工单有多少个类别？类别之间的边界清晰吗？有没有历史人工分派记录可以当标签？分错类别的代价有多大（分配错了可能延误客户，也可能只是内部转派）？新类别出现的频率高吗？
回答完这些问题，你会得到一个关键结论：这个任务到底适合规则系统、传统机器学习、深度学习还是大模型。如果工单类别只有5类、边界清晰、文本是标准格式化内容，那BERT可能都大材小用，正则加关键词就够用了；如果类别有几十类、边界模糊、自由文本为主，那才轮到深度模型上场。
接着做数据可行性判断。我会找历史三个月的工单数据，统计文本长度分布、类别分布、以及"是否有足够多的样本支撑每个类别"。如果一个类别只有50条样本，那你首先要解决的问题是数据增强还是类别合并，而不是盲目上模型。
4.2 数据清洗与特征设计的实操细节
项目走到数据处理环节时，活儿才真正开始累。工单文本通常长这样："订单xxxx延迟送达，客户非常生气，要求马上处理并赔偿。"里面混着订单号、时间、情绪词、品牌词、标点符号不统一。我的清洗管线一般分几步：
- 规范化：统一全半角、大小写、去掉HTML标签和多余空格。
- 脱敏：把手机号、地址、订单号等个人信息替换成占位符，既保护隐私，也避免模型记住这些"虚假特征"。
- 分词：中文场景先用jieba或者基于预训练模型的分词器，但要注意专业术语可能被切碎。比如"退款原路返回"可能被切成"退款/原路/返回"，语义会变。
- 停用词：注意不是所有停用词都该删。"不""没"这种否定词一旦删掉，类别判断会被彻底带偏。我通常只删除高频无实义的虚词。
特征设计方面，除了文本向量化之外，我会加几个"浅层特征"辅助分类：文本长度（长文本可能是投诉，短文本可能是简单咨询）、是否包含金额信息、是否包含情绪强烈的词、是否包含具体商品名。这些特征对提升边界情况的判断非常有帮助。当然，如果用大模型做分类，浅层特征可以直接省略，模型自己会理解，它们的意义更多是给传统机器学习模型提供"人工先验"。
4.3 基座模型选型：为什么我最终选择微调而非从头训练
项目性质定下来后，就到了极其重要的选型环节：用预训练模型微调（Fine-tuning）还是从头训练？
"从零开始训练模型"这个说法在AI工程里很有迷惑性。坦白讲，真正的从零开始训练一个通用的深度模型，在绝大多数商业场景下都是错误的决策。预训练模型的参数里已经蕴含了海量的语言知识，你在它基础上做微调，只需要很少的数据就能适配新任务。从头训练意味着你要重新让模型学一遍语法、语义、常识，这需要的数据量和算力是一般团队承受不起的。
我在这类工单分类项目上的选择是：先用一个中小规模的预训练模型（比如BERT系列的base版本）微调，跑通基线；如果效果不够，再考虑更大规模的模型或引入领域语料继续预训练（Continue Pretraining）。
具体操作上用的是HuggingFace生态。加载模型和分词器，把工单文本转成input_ids和attention_mask，用交叉熵损失训练分类头。训练时要注意三个细节：学习率要比从头训练小得多（一般用2e-5到5e-5），训练轮数不能太多（容易过拟合），批量大小受显存限制时用梯度累积。
4.4 评估闭环：离线指标与人工抽检的双轨机制
模型训练完，别急着说自己完成了任务——评估环节至少做三轮。
第一轮是在留出测试集上看核心指标。对分类任务，precision、recall、F1都要看，别只看准确率。特别是类别不均衡的时候，准确率会骗人：如果90%的工单是账单类，你全部预测成账单类，准确率就90%了，但剩下的那10%工单全错。
第二轮是分切片评估。把测试集按文本长度、类别、是否含金额信息等维度切分，逐一观察指标。这一步能暴露模型的"隐性短板"。我遇到过的情况是：模型在短文本上表现很好，但在长文本工单上准确率只有60%。后来分析发现，长文本里包含多个子问题，模型只能识别最后一个主题，需要调整为多标签分类或加一个"主问题抽取"的前置步骤。
第三轮是人工抽检。让业务方挑100条线上真实工单，用模型预测完，人工逐一打分。这一步虽然费力，但比任何指标都可靠，因为只有懂业务的人才知道"分到A类但理由完全不对"和"分到B类但处理方式相同"之间的微妙差别。
4.5 推理服务化：成本、延迟与稳定的平衡
模型部署阶段，我优先考虑的是延迟和成本。一个BERT-base分类模型，单条推理延迟在CPU上可能50-100毫秒，在GPU上10毫秒以内。工单分类对延迟不敏感，几百毫秒可以接受，所以可以选择CPU部署，大幅节省成本；但如果是实时对话系统，就得考虑GPU推理和批量优化了。
服务化我用FastAPI封装，把模型加载、预处理、推理、后处理封装成一个类，提供一个统一的predict接口。代码逻辑上有一个关键点：预处理逻辑必须和训练时完全一致。这句话我强调一万遍都不为过——加载同一个分词器、执行同样的清洗和编码步骤，然后才进入模型。我曾经因为线上少做了一步"统一大小写"，导致模型输入分布和训练时不一致，整体F1直接掉了10个百分点。这个坑我在后面排查章节会细讲。
服务稳定性的几个工程配置：模型加载后常驻内存、接口做超时控制、批量请求做排队或并发限制、模型输出做格式校验。对生产系统，我还会给模型预测加一个置信度阈值：低于阈值的工单不自动分类，直接流转人工。这个"人在环路"的设计，是有效的兜底方案。
5. 工程落地中最容易踩的四个坑及其排查思路
5.1 数据泄露：训练集里混进了未来信息
这类问题是最隐蔽的，它会让你的离线评估虚高到不可思议。我有一次给一个时间序列预测项目做评估，模型在测试集上误差几乎为零。看着那完美的曲线，我第一反应不是高兴，而是怀疑——正常模型不可能好到这个程度。
排查后发现，训练集和测试集是按时间划分的，但特征工程里包含了一个"最近N天均值"的滚动窗口特征。这个特征在计算时用到了测试期之前14天的数据，而那些数据根本不该在真实预测场景中出现——因为在线上预测时，你不可能用到"未来14天之后才能计算出来的统计量"。严格说这是特征工程对时间边界的破坏，本质就是数据泄露。
处理办法是建立"时间旅行检查"：模拟真实的预测时刻，只允许使用该时刻之前可用的信息。时间序列项目里，划分训练/验证集时必须按"预测截止日"做严格切割，特征计算也必须在切割点左侧完成。
5.2 线上线下不一致：训练和推理的裂缝
这类坑几乎每个AI团队都踩过，表现形式多种多样：训练时做了标准化、正则化、停用词过滤，上线时忘了实现；训练时用的分词器是旧版本，上线时环境里自动装成了新版本；训练时文本先清洗后编码，线上却是先编码后清洗。
排查思路其实很简单：选一条训练样本，完整记录从原始文本到模型输入张量的每一步中间结果；再到线上服务里用同一个输入走一遍推理链路，拿到对应的中间结果；然后逐层比对。哪一步开始不一致，问题就锁定在哪一步。
我在项目里要求所有预处理逻辑都封装在训练脚本和推理服务共享的同一个模块里。这样从根源上防止两边漂移。另外，代码版本和模型版本要绑定管理：一个模型检查点对应一组精确的代码版本、数据版本和环境依赖版本。
5.3 评估集太"干净"：指标好看但上线就崩
第三个高发坑是评估集和真实分布的偏差。团队在构建测试集时，往往会不自觉地进行"人工美化"：选的都是表述规范、类别清晰的样本，用集体讨论的方式定标签。但线上迎来的可能是错别字连篇、中英文混杂、情绪化口语，甚至广告垃圾信息。
一个真实的教训：我做一个评论情感分类模型，离线AUC约0.95，看起来很棒。上线一周后业务方反馈大量"中性但被识别为负面"的误判。抽检后发现，线上评论里大量"这个产品一般般吧，但也不是不能用"式的转折表达和反讽，在干净评估集里根本没有代表性样本。这属于评估集没有覆盖真实分布的边缘情况。
正确的做法是：评估集必须包含一定比例的"脏数据"——原始未清洗的、少量噪声的、类别边界模糊的样本。我建议从真实生产日志里按随机策略采样构建"仿真评估集"，而不仅仅依赖人工精标的数据。
5.4 依赖与环境的可复现性：为什么模型隔三个月就跑不出原指标
这个问题在"从零开始做AI工程"的团队里尤其普遍。项目初期，团队在各自的电脑上训练模型，环境配置靠"口头交流"；三个月后发现同样代码在不同机器上跑出来的效果对不上，甚至同一台机器上重新装环境后也复现不了。
我经历过最夸张的一次：某天模型效果突然下降，排查了两天才发现是pandas库从1.3升级到了1.5，改变了某个字符串处理的默认行为，导致特征构造产生了细微差异。这类问题的根源是"环境不可复现"。
解决思路有两个层面。第一，环境锁定：用requirements.txt锁定所有Python包版本，用Docker把CUDA、cuDNN等系统级依赖也固定下来，训练和推理尽量都在容器里进行。第二，实验记录：每一个训练任务都要记录代码版本hash、数据版本、关键依赖版本、超参数配置和最终指标。这些记录要能做到"任何一次实验都能被重新执行"。工具上我推荐MLflow或简单的JSON配置记录方式，重点不是工具，而是养成习惯。
6. 我个人沉淀的几条AI工程心法
6.1 工程思维优先，研究思维靠后
做AI工程的时候，默认心态不应该是"我要把这个模型做到SOTA"，而是"我要在这个业务约束下找到足够好的方案"。SOTA只适合比赛和论文，真实项目面对的是成本、延迟、可解释性、维护性的多重约束。
刚入行时，我特别容易沉溺于调参和换模型的快感——每次指标涨0.01都能开心半天。但后来发现，真正决定项目成败的往往是那些"无聊"的环节：数据规范是否清晰、评估逻辑是否合理、监控是否到位、回滚是否顺畅。这些工作不性感，但它们是系统的地基。
6.2 对"一键训练"脚本保持警惕
我看过很多团队的训练脚本，run.py一敲，数据加载、预处理、模型定义、训练循环全在里面，500行起步。看起来方便，但对团队来说是灾难：任何人改任何一处，都可能悄无声息地影响整个流程，而且很难追溯每次实验到底改了什么。
我的实践是把训练流程拆成清晰模块：数据处理、模型定义、训练循环、评估器、配置管理。配置文件单独存放，每次训练自动保存配置快照。这样每个环节可以独立修改和测试，也方便快速定位问题。
6.3 把数据漂移监控当成"生产系统的安全气囊"
模型上线后，我至少要监控五个维度的变化：输入文本长度分布、词汇分布、预测类别分布、平均置信度、业务侧结果指标。任一维度出现持续漂移，都要触发告警并启动"重训或人工干预"的预案。
有一次我注意到某分类模型的"娱乐类"预测比例从8%涨到了15%，同时平均置信度在下降。排查后发现是社交平台改版导致文本表达风格骤变。因为监控及时，我们提前两周重新收集数据、准备微调，避免了线上效果断崖式下跌。
6.4 小团队如何分配精力：数据7成、建模2成、部署1成
如果团队只有两三个人，精力分配我建议走"三七开"——七成精力放在数据层面（采集、清洗、标注、分布分析），两成放在建模调优，一成放在部署运维。这不是说部署不重要，而是数据一旦扎实，模型训练就是水到渠成的事；数据稀烂，建模做得再精细也是白费。
最后再说一个项目收尾时的小习惯：无论项目多忙，我都要求团队把数据处理和建模流程写成文档，哪怕只是三页纸的wiki。很多项目烂尾，都烂在"人走了、知识也走了"。文档化的过程会让隐性知识沉淀成团队资产，下一次做类似项目时，你会发现自己站在了前一个项目的肩膀上。
我自己从"调包侠"到真正理解AI工程，走了不少弯路。如果让我给刚起步的朋友一句建议，那就是：别急着追求更复杂的模型，先把你已有的模型全链路跑得滴水不漏——从数据到训练到评估到部署到监控，每一步都经得起追问。这一步迈过去，你才算真正进入了AI工程的大门。