ai-engineering-from-scratch 这个标题拆开看其实挺有意思。ai-engineering，不是简单的“用AI”，而是把AI当作一个需要设计、需要测试、需要维护的工程对象；from scratch 又强调了从零开始搭建整套能力。我见过太多开发者的状态：会调API、会写提示词，但一上生产就露馅——回答不稳定、不可追溯、测不了、改不动。这篇文章就把我亲自动手从零搭一整套AI工程基线的过程写出来，不是教科书式的概念梳理，而是实打实的路线图、步骤和踩坑总结。
这个内容适合谁？想转行做AI应用开发的程序员，带着团队做AI落地的技术负责人，以及那些已经能跑通一个demo、但不知道如何把“会骗人的模型”变成“可交付的系统”的工程师。本质上，ai-engineering-from-scratch 要解决的是一整类问题：从单次调用里的随机性，到整个系统的确定性；从一个人的灵感，到一个团队的可维护性。说的直白点，这是一条从“调包侠”到“AI架构者”的成长路径。
1. 从零开始，到底要从哪里起步：先把AI工程的边界画清楚
很多人一听“from scratch”，第一反应是去补线性代数、微积分、反向传播推导，觉得不把Transformer论文手推一遍就不配做AI工程。这个方向不能说错，但大多数人的卡点根本不在数学，而在“不知道一个能上线的AI系统到底长什么样”。我自己的经验是，先把工程边界画清楚，再决定学什么，效率高得多。
1.1 为什么说“从零”不等于“从代码第一行开始”
AI工程最反直觉的地方在于：它建立在大量不确定性之上，却必须产出确定性的结果。传统软件工程里，if 就是 if，不会今天返回true明天返回false。可你往API里发同一段prompt，温度设成0.7，两次输出大概率不一样。所以从零开始做AI工程，第一步不是写模型，而是建立一个认知：你的目标不是消灭随机性，而是把随机性控制在一个可接受的范围里，并且让每一次随机都有测量。
我见过一个团队，花三个月把大模型推理服务、向量数据库、Agent框架全部搭好了，产品经理往里丢了一堆测试问题，发现答案一会儿好一会儿差，团队就崩溃了。为什么崩溃？因为没有人定义“好”的标准，没有人建评测集，没有人在改prompt之前先跑一遍基线。这不是AI的问题，是工程缺位。所以我的建议是，从零开始的起点应该是“评测”和“基线”，不是模型部署。
1.2 一张路线图：从调用者到架构者的四个阶段
为了让你更清楚地定位自己在哪、要去哪，我把AI工程能力拆成四个阶段：
- 第一阶段“调用者”：会调大模型API，能写prompt，能处理基本的解析和重试。交付物是一个能用的demo，但对“为什么这样写”没有系统判断。
- 第二阶段“优化者”：掌握评测方法，能建评测集，能做RAG检索的调优，知道什么时候该用向量检索，什么时候该走微调。交付物是一个可以稳定跑在测试环境里的应用。
- 第三阶段“架构者”：能设计多Agent协作方案，能管理上下文和工具调用，能构建完整的测试闭环和监控体系，能判断一个复杂业务场景该用单模型还是多模型、该做实时检索还是离线知识库。交付物是一个能上生产、出问题时能快速定位的系统。
- 第四阶段“研究者”：能自己训模型、改架构、设计对齐方案。这个阶段就不是大多数人需要的了。
如果你现在还在第一阶段，别急着上LangChain、AutoGPT那些重框架，先把“评测”这件事做起来。我后面会详细讲怎么做一个最小可用的评测闭环。
1.3 你手里已有的传统工程能力，千万别丢
一个特别容易被忽略的事实是：AI工程不是凭空出现的领域，它是在传统软件工程的土壤上长出来的。你的依赖管理、版本控制、日志监控、单元测试、CI/CD经验，在AI工程里全部有效，只是多了一层“模型的不确定性”需要额外处理。
说白了，会写Python、会管理服务、会做性能分析的人，学AI工程比纯算法背景的人更快。因为AI应用的大部分代码还是普通代码：数据清洗是普通代码，API通信是普通代码，缓存、限流、权限控制也是普通代码。真正需要“AI特殊处理”的只有一小块，比如模型输出的校验、评测集的设计、反馈数据的回流。我带着团队做项目的过程中发现，工程能力强的组和工程能力弱的组，在同一个模型、同一份需求面前，交付质量的差距能拉到三倍以上。所以不要妄自菲薄，把传统工程能力迁移过来，就是“from scratch”里最大的底气。
2. Prompt Engineering到Agent开发：中间隔着一整套思考方式
热词里频繁出现“prompt engineering”、“ai agent”、“多ai协作”，这些东西看着是几个独立概念，实际是一条逻辑链：Prompt是单次交互的边界设定，Agent是把多次交互编排成完整任务，多Agent协作则是把多个角色的任务编排成一个系统。想直接跳到Agent开发的，十个里有八个会翻车，因为基础边界没画清楚。
2.1 Prompt不是“写词”，而是在给模型划边界
我在刚开始写prompt的时候，总觉得“提示词写得越详细越好”，后来踩了坑才明白：提示词的核心不是字数多，而是“边界清晰”。好的system prompt应该像一份技术合同，写明角色、输入格式、输出格式、禁区、兜底策略。模糊的“你要表现得专业”不如精确的“如果问题涉及医疗诊断，必须声明这不是医疗建议，并建议用户就医”。
再分享一个我常用的三段式结构：角色与目标、输入与约束、输出与兜底。角色与目标决定了模型的语气和关注点；输入与约束告诉模型哪些信息可用、哪些策略必须遵守；输出与兜底决定了格式，以及模型不确定时该说什么。在我搭过的客服问答系统里，光是“输出与兜底”就干掉了一半以上的幻觉问题。因为模型在不知道答案时，会按兜底话术直接说“这个问题我暂时无法回答，已记录并转人工”，而不是硬编。
2.2 Agent的三个关键问题：任务拆分、记忆管理和工具调用
Agent开发是prompt engineering的升级版，因为从单次对话变成了多步决策。我自己的体感是，Agent落地成败就看三件事：
第一，任务拆分是否合理。现在的模型不擅长一口气处理超长复杂任务，但很擅长你替它把大任务拆成子任务。比如“分析上季度销售数据并生成PPT大纲”，你理想的流程是：先调SQL查询，再写Python做摘要，再生成PPT结构。Agent框架能帮你按顺序跑这些步骤，但“这个任务该拆成几步、每步依赖什么”是你在设计阶段就要想的。
第二，记忆管理是否有层级。工作记忆对应当前任务里的临时信息，短期记忆对应本轮对话的上下文，长期记忆对应从向量数据库里检索出来的持久知识。最容易翻车的地方是把所有东西都塞进上下文窗口，导致token爆炸、成本激增、响应变慢。我常用的策略是：每一步都只保留“执行当前子任务必要的信息”，任务间的中间结果用结构化数据存储，而不是随手拼进下一轮消息。
第三，工具调用的schema要像接口文档一样严格。模型会自己决定调哪个工具、传什么参数，所以你的工具描述必须给清楚：这个工具是干什么的、参数格式是什么、什么时候不建议调用它。我遇到过Agent把一个“用户名查询接口”的入参传成了一大段对话历史的搞笑事故，后来发现是工具描述里没写清楚“只接受精确用户ID”，模型觉得把对话内容传过去更保险。
2.3 为什么工程上必须追求“确定性”
做Agent最难受的体验就是：同一个任务跑十次，三次成功、五次带点小毛病、两次彻底失败。这在demo阶段你还能忍，上了生产完全不行。所以工程化Agent一定要给模型套上“确定性约束”：
- 温度参数：需要分类、抽取、格式化输出的场景，把温度设到0或接近0；需要创意的场景再调高，而且高温度场景必须配人工审核。
- 输出校验：给模型规定JSON输出，然后用Pydantic之类工具做严格schema校验，校验失败就重试或降级到规则兜底。
- 有界重试：重试必须有次数上限和退避策略，不能让Agent在同一个错误上无限打转。
- 可观测性：每一步的输入输出都要记录，不然一个Agent链条出问题，你根本不知道是哪一环开始错的。
这套“确定性约束”做完，你会发现多AI协作其实也没那么神乎其神。所谓的“多AI协作”，就是给不同模型分配不同角色，比如一个负责检索、一个负责生成、一个负责审核，然后用工程代码来控制它们之间的消息传递。本质上和你管理多个微服务没有区别，只是每个服务变成了一个带随机性的模型调用。“工程上怎么控住随机性”这个思路，一旦想明白，后面所有问题都好办。
3. 模型侧的能力补全：从理解原理到真正碰一碰权重
工程做到中期，你迟早会面对一个问题：手里的开源模型能力不够，或者连着API心里没底，或者想看看到底能不能通过微调解决业务痛点。到这个点，就要开始补模型侧的基础理论了。注意，我不建议迷信“必须读多少篇论文”，而是建议你对三个关键概念形成肌肉记忆级别的基础认知。
3.1 大模型基础理论里，必须先啃的三块硬骨头
第一块是Tokenizer。Tokenizer决定了一段文本会被切成多少个token，而你的成本、上下文长度、模型的“单位意思”都建立在它之上。一个特别容易踩的坑是：英文tokenizer处理中文时效率很低，一句话可能切成很多碎片，导致同样内容的token数是英文的好几倍。所以做中文AI应用时，一定要先测一下目标模型配套tokenizer的中文效率，再估算成本和上下文预算。
第二块是Attention机制。Transformer里的自注意力，本质上是让每个token跟序列里所有其他token算相关度。它的计算复杂度是序列长度的平方，这就是为什么上下文越长、推理越慢越贵。理解了这一点，你就明白为什么工程师总是想尽办法“压缩”上下文：不是模型不想记，是成本和延迟不允许。做RAG、做摘要、做记忆裁剪，本质上都是跟O(n²)这个复杂度搏斗。
第三块是训练目标。预训练让模型学会“接下一句话”，指令微调让模型学会“按指令做事”，对齐让模型学会“说安全合理的话”。业务里你的模型行为不对劲，很多时候不是模型坏了，而是它只接受了其中某一个阶段的训练，没有你期望的能力。你要微调领域知识，大概率是在指令微调阶段做；你要调整语气和风格，可能也要指令微调或RLHF那套对齐流程。想清楚模型的能力来源，你才能判断问题该用prompt解决，用RAG解决，还是用微调解决。
3.2 Token、上下文窗口、Attention成本：一次完整的预算计算
我举一个自己实际算过的例子，你感受一下为什么要理解这些参数。假设你选了一个上下文窗口为32k的模型，API按token计费。你的RAG逻辑每次检索8个chunk，每个chunk约500字符，大概能折成1000到1500个token；加上system prompt和用户问题，一次请求的输入大约在12000到16000个token之间。假设你的业务QPS是50，平均输入1.4万token、输出500token，那一小时的成本就是50 x 3600，再乘上每token的价格，账算下来非常惊人。
这就是为什么工程上你不可能“让模型读所有东西”，必须靠检索把输入控制在必要范围。同时也解释了为什么“长上下文越大越好”这个说法要看场景：上下文变大，意味着你的检索精度要求降低，但成本、延迟和注意力计算的压力全部上升。在绝大多数业务场景里，把上下文从32k压到8k，配上一套好的检索，比直接大上下文硬读效果更好，成本可能差四到五倍。
3.3 微调是不是从零做AI的必经之路
我的结论是：绝大多数业务场景不需要微调，用RAG加prompt就能解决八成问题。什么时候才需要微调？我列几个判断标准：模型经常在特定格式上犯错；你需要的输出风格和模型默认风格差异很大；你需要让模型学习某一类领域术语和判断逻辑；prompt已经把上下文窗口塞满了还达不到效果。
如果真决定微调，现在的技术栈已经很友好了。基于LoRA或QLoRA这类参数高效微调方法，你不需要重训整个模型，只训练一小部分适配器参数。比如一个70B模型用QLoRA在单张高端显卡上就可能跑得动，成本比全参数微调低几个数量级。这块我也不是理论派，实操时最大的体感是：数据质量远比训练代码重要。你花一周时间构造一千条高质量样本，比直接灌一万条从网上爬的脏数据有效得多。数据怎么构造、怎么清洗、怎么去重，才是微调项目里最耗时的部分。
如果想从根上理解模型，我建议找两本书啃一啃，一个是《Build a Large Language Model From Scratch》，另一个是《Build a Reasoning Model From Scratch》。这两本都是教你手写实现模型、手搭训练管线的路子。我不是让你照抄代码，而是跟着走一遍之后，你会对“模型为什么有这个行为”有真正的手感，而不是只把大模型当黑盒。这种体感在做工程决策时特别值钱。
4. 完整实操：搭一个带RAG和测试闭环的工程基线
光讲概念不讲操作，等于耍流氓。下面我把一个真实的“企业知识库问答机器人”从0到1搭完整，它就是典型的RAG加Agent链路，同时带着评测和测试闭环。这套方案我不按某一家云厂商的专有服务写，全部选通用组件，你可以直接落在自己的服务器上。
4.1 第一阶段：数据层（数据获取与清洗）
先解决一个很多人忽略的问题：知识库里的文档不是天生就是好语料的。企业内部常见的文档格式是PDF和Word，而PDF尤其难搞——有些是文字层的，可以直接抽取；有些是扫描件，需要OCR；还有一些是表格和图片混排，抽取出来全是乱的。
我踩过的流程是这样的：先用解析工具把PDF和Word转成纯文本，然后人工抽看20个样本，确认几个关键信息——标题、正文、表格、页眉页脚是不是都识别对了。如果扫描件比例高，就把OCR步骤接进来，但OCR也会错，特别是表格、公式、中文标点，所以对OCR文本要做一轮规则清洗，比如把全角半角统一、把多余换行改掉、把“|”这种表格残骸处理掉。
清洗完之后就是切块。切块的策略我建议先从一个简单方案开始：按固定字符长度300到500切，段与段之间留80到100个字符的重叠。这个重叠参数是防止一句话在切块时被从中间劈开，导致语义不连贯。更好一点的方案是按标题结构切，比如“章节标题下的内容作为一个候选块”，但不同文档的标题结构差异很大，规则容易脆。先用固定长度跑起来，后面再迭代结构切块。
4.2 第二阶段：检索层（Embedding加向量数据库）
检索层是RAG效果的分水岭。很多人以为把文档切开、塞进向量库就完事了，实际上一套靠谱的检索方案至少要解决几个问题：用哪个embedding模型、向量库选哪个、召回多少条、混合检索要不要上。
Embedding模型的选择上，中文场景优先考虑开源的中文向量模型，比如bge系列这些。评估embedding有一个简单粗暴的土办法：准备30个代表性的用户问题，用一个候选embedding模型把文档切块编码，然后看手动检出的文档片段排在第几位。如果每次都排不进前五，说明这个模型跟你的领域不匹配，换个更强的模型。
向量数据库的选择，我按团队能力给几条建议：项目很小时用轻量级方案（比如chroma或qdrant这类单机方案），部署简单、迭代快；数据量到百万级向量或者需要高并发时再上重量级方案（比如milvus之类）。别在项目第一天就上一套重型分布式向量库，运维成本会把你拖垮。
这里还有一个值得说的点：纯向量检索处理“关键词精确匹配”其实不太行，比如用户搜“2024年报销流程”，如果2024在文档里写成“二〇二四”，向量检索不一定能对上。所以工程上更稳的做法是“混合检索”：把BM25关键词检索和向量检索都跑一遍，两种结果合并、排重、加权排序。这个步骤能明显提升召回率的稳定性，我的项目里加上混合检索之后，“找不到答案”的比例降了差不多三分之一。
4.3 第三阶段：生成层（提示词模板与链路编排）
检索把相关材料找到了，接下来要决定怎么把它们喂给模型。这部分的工程关键有两个：提示词模板管理，以及链路编排工具。
提示词也得管版本，这点很多人忽略。我在团队里强制要求：所有prompt以文件形式存放在代码仓库里，而不是写在数据库配置或者产品后台里。改prompt必须走代码评审和回归测试，跟改代码一样。这样出了问题才能知道是什么版本引入了变化。
链路编排这块，我坦白说：Agent框架我试过好几套，从重度的LangChain到轻量的自写编排，最终的选择是“按需混搭”。如果业务链路特别固定——先检索、再生成、再校验，那用一段清晰Python代码手动串起来，比套一个框架更可控，也更容易排查错误。如果你需要灵活的任务动态规划，比如让模型决定下一步调用哪个工具，那再引入图编排类框架。千万别为了用框架而用框架，框架替你省的时间，最后都会变成排查时间还回去。
我自己最常用的是轻量编排加状态记录：每个环节把输入输出写进结构化日志，链路完成后再统一做质量校验。这套方案可读性强，出了问题也容易定位。
4.4 第四阶段：评估与回归（AI测试开发）
接下来是整篇文章我自己认为最值钱的部分：怎么测一个AI系统。传统测试断言的是“函数返回什么”，AI系统测试断言的是“模型回答是否符合质量标准”。这个“是否符合”需要用一套跟业务绑定的评估机制。
我建议你先手工整理50到100条评测样本。每条样本包含三部分：用户问题、理想回答应该覆盖的关键信息点、应拒绝的指令类型。例如“请假流程是什么”这条，关键信息点就是“至少提前一天”“通过OA提交”“主管审批”；再比如“你能帮我骂我的同事吗”这类，就归入应拒绝的类型。这样评测集就有两个维度：该覆盖的有没有覆盖，不该答的有没有乱答。
然后是评估方式。我采用“规则判官加模型判官”双通道。规则判官检查客观硬指标，比如是否按JSON格式输出、是否包含FAQ里的标准话术、响应时间是否超限；模型判官把一个评分任务发给一个更强或更公正的模型，让它按维度打分。双通道都有自己的偏科，合起来用效果才稳定。
再进一步，这套评测集要接入自动化流水线。我把它挂在CI上，每次改prompt、改chunk策略、改embedding、改模型版本时，自动跑一遍评测集，看核心指标有没有下降。指标用“正确回答率、幻觉率、拒答率、平均响应时间、单次成本”这五项就够了，先别整一堆听起来唬人但没法落地的指标。这其实就是“AI测试开发”这个方向上的基础范式，谁先把测试闭环跑起来，谁就真正摸到了AI工程的门道。毫不夸张地说，跑通评测闭环的那一天，是这个项目质量的真正起点。
5. 开发范式与人效问题：多人协作时怎么让AI工程不失控
做到这里，你的“AI应用”已经能稳定跑了。但团队一旦超过两三个人，新的问题就会出现：怎么让更多人协作不乱套？怎么让AI系统持续演进而不是变成一团浆糊？热词里的“harness engineering”、“loop engineering”、“ai native研发范式”其实都是在回答这些问题。
5.1 Harness Engineering：把AI能力套进约束框架里
我第一次听到harness engineering这个概念时，脑子里蹦出的画面是给AI套上“挽具”，让它被约束在安全轨道里跑。这个理解是对的，它就是把模型的能力范围、输入输出格式、权限边界、行为底线，全部用工程手段固定下来。
比如你要做一个AI助手，让它能查内部知识库、能提交工单、能读取用户基本信息。没有harness时，模型想调哪个工具都行；有harness时，每个工具调用都要经过鉴权、参数白名单校验、敏感字段脱敏，输出还要经过内容审计。有一回我负责的系统差点出事——模型根据用户输入顺手把另一个用户的历史工单拼进了回答里。就是harness的权限校验不够严导致的。后来把所有工具调用都强制走了一层上下文权限过滤，这类问题就再没出现过。
Harness engineering还包括“边界响应”设计：模型遇到权限内的请求要答好，遇到权限外的请求要明确拒绝，而不是“尝试答一下”。把这个写进system prompt只是第一步，更关键的是在工具层、鉴权层做硬拦截，不要相信模型的判断力。
5.2 Loop Engineering：为什么要把反馈回路显式化
AI系统和传统系统最大的不同是它会越用越“了解”你的业务吗？不一定。除非你显式地把用户反馈、人工修正、新问答数据收回来，再喂回评测集和知识库，否则模型系统一点都不会自进化。loop engineering就是把这条反馈回路的每一环都设计出来。
实际落地的反馈环至少有三层：第一层是用户交互反馈，比如“赞同”、“不赞同”、“重试”、“转人工”按钮，这些事件要落库；第二层是运营纠错反馈，客服或运营人员看到错误回答后进行人工修正，修正后的问答对要进入新的知识库候选；第三层是模型行为反馈，也就是评估指标的变化趋势，比如“幻觉率连续三天上升”，要触发告警和复盘。
这三层反馈如果不用代码和流程串起来，基本上只能靠人肉把反馈复制来复制去，最后就丢了。所以我在做任何AI项目时，都会在第一天就把“反馈事件采集”接口定义好，这个接口一定要带上session_id和message_id，后续所有分析都靠这个ID串起链路。没有追踪ID的AI系统，出事就等于大海捞针。
5.3 AI Native研发范式：从“人围绕代码”变成“人和模型围绕目标”
把视野拉远一点，AI工程对研发团队组织方式的冲击是真实的。以前是“人写代码，机器跑”；现在是“人定目标和约束，模型生成候选，人做评审和兜底”。这个变化看起来只是多了一环AI，实际上整个协作流程、任务分配、代码审查方式全变了。
我在团队里推行的AI Native研发范式有几个要点：需求评审时必须多写“约束”和“边界”，比如哪些场景不覆盖、哪些问题要拒答，因为模型对边界非常敏感，边界不写清楚它就自由发挥；方案阶段引入AI生成技术方案初稿，人负责修正和补充工程细节；编码阶段AI生成代码的比例可以很高，但单元测试和集成测试的覆盖必须由人把关；所有AI生成的代码入仓库前，必须有一个有经验的工程师做评审。
“AI测试开发”这个角色在流程里的位置也变了。传统测试是上线前的最后一环，AI项目里测试必须前置到每个模型改动、每个prompt变更的阶段。因为模型行为不像代码那样确定，你不实测就不知道它会不会因为一个标点符号的变化，突然在某个case上彻底跑偏。我一度让团队成员记录每一次prompt改动给线上指标带来的影响，三个月下来，这个“改动日志”成了团队最值钱的历史资产。
说到底，AI Native研发范式不是什么玄学，它就是一套“人机协作的工程化管理方法”。人负责判断什么是对的、什么边界不能碰，AI负责在高确定性约束下产出候选结果，再由工程系统保证整个过程可追踪、可回归、可回滚。
6. 常见问题与排查技巧实录
最后这部分，我把自己和身边团队踩过的高频问题整理成一个速查表。如果你照着做还碰到新问题，那恭喜你，你正在进入AI工程更深的地方。
6.1 现象：模型回答质量时好时坏
最可能的原因是：温度参数没有固定，或者prompt里存在随机性输入，或者评测样本太少导致你看到的“好和坏”只是随机波动。
排查步骤是：先把温度固定到0附近，再看是不是prompt里嵌入了动态内容导致格式不稳定，最后扩充评测集到50条以上，跑三轮取平均值。记住一个原则：每次只改一个变量。如果你同时改了prompt、换了模型、加了检索，出了问题你永远不知道是谁造成的。
6.2 现象：上下文越长，回答质量越差
你以为模型能记住所有信息，实际上注意力机制在长上下文里会被大量无关信息稀释。我自己的经验是，超过某个长度后，模型会“注意力迷失”，只盯着开头和结尾的内容，中间的关键信息经常丢。
解法有两个方向：一是做严格的上下文裁剪，只保留跟当前用户问题相关的内容；二是用检索增强替代“全量塞入”，让模型只看最相关的一小块文本。千万不要认为“模型上下文窗口大，RAG就不需要了”，这个想法会让你付出真金白银的成本代价。
6.3 现象：Agent在同一个任务上反复打转
Agent卡死循环是这个时代最经典的bug。排查方法分三层：先看工具描述是否把“何时不要调用”写清楚；再看重试逻辑是否设置了最大次数和退避；最后看是否有“看门狗”机制可以强制终止并转人工处理。
我这里有一个通用经验：给Agent的每一步都加“超时终止”和“死循环检测”。比如一个使用工具的任务最长执行时间设成1分钟，超过就强制结束并回退到安全话术。这个机制看着简单，救过我好几次命。
6.4 踩坑清单TOP 10
我在多个AI项目里沉淀下来一份“黄金教训”清单，列出来供你对照避坑：
- 模型版本不锁定。同一个模型在不同时间点可能被服务商悄悄更新，行为有细微变化，必须把模型版本显式固定在配置里。
- Prompt没有版本管理。改prompt就是改代码，没走评审和回归测试等于裸奔。
- 评测集数量太少。少于50条样本，指标波动根本分不清是改动引起的还是噪声。
- 没有缓存层。同样的用户问题重复打模型API，既慢又贵，加一个缓存层能省很多钱。
- 不记录输入输出。AI系统出问题时，没有日志就等于没有现场，排查无从谈起。
- 向量库升级后没有重新生成embedding。向量库版本一变，老向量可能跟新模型不兼容，检索效果莫名变差。
- 忽略API限流。生产环境流量一上来，没做限流和队列，服务可能被打爆。
- 多Agent之间没有“仲裁”。几个Agent各干各的，结果互相矛盾，需要一个统一的决策入口。
- 微调模型直接上生产。微调后的模型行为和基座模型可能有差异，必须跑完整评测集才能上线。
- 没有回滚策略。每次部署AI系统都要准备好上一版模型和上一版prompt，一旦新方案翻车，一分钟内就切回去。
上面这十条看起来都是老生常谈，但真的踩过才懂，每一条背后都是一次凌晨三点定位问题的经历。
我个人在实际操作中最大的体会是：“从零开始做AI工程”最忌讳的就是想把所有环节都设计成完美方案再动手。我的建议是，先搭一个只有“数据、检索、生成、评测”的最小闭环，哪怕丑一点、糙一点，然后让数据流跑起来。接下来每次只改一个环节，每改一次都跑一遍评测集，把每一项改动的收益和损失记录下来。你会发现，AI工程其实没那么玄，它就是用工程方法把“模型的不确定性”一层层锁进笼子里，直到这个系统在业务上真正可靠、真正可控。这个迭代的过程，才是from scratch真正的含义。