先说个题外话。每次有人拿着“ai-engineering-from-scratch”这个标题来找我聊我第一反应都是先反问一句你说的“from scratch”到底是“从零训练一个大模型”还是“从零把AI用起来解决实际问题”这两个方向差着十万八千里。前者的工程量、资金消耗、技术密度基本是一个国家级实验室或者头部大厂才玩得起的事情后者才是绝大多数工程师、技术团队、甚至独立开发者真正需要的路径。我为什么这么在意这件事因为过去两年我见过太多人一上来就冲“从零训练模型”这个方向去最后卡在数据清洗和算力账单上动弹不得。而那些真正把AI工程落地的人做的其实是另一件事把大模型当成一个全新的计算元件重新设计数据管道、评估体系、推理服务、人机协作流程。这才是“ai-engineering”的核心——不写Transformer但要把Transformer用成可靠的生产工具。这篇文章就是按后者的逻辑写的。我不会教你背TensorFlow的API也不打算复现一篇论文。我想聊的是从工程视角出发把AI从“demo能跑”推进到“系统能扛”的完整路径。适合谁看适合那些手里已经有一个具体问题比如自动分类工单、提取合同关键信息、做智能客服想知道怎么用AI把它做成稳定产品的人。也适合团队里负责技术选型、做架构决策的工程师。1. 先想清楚你到底在“造”什么还是在“用”什么1.1 两类“from scratch”的本质区别我见过太多项目死在第一步没想清楚自己要解决的是“模型问题”还是“工程问题”。如果你要做的是像LlaMA、DeepSeek这类基础模型那“from scratch”意味着你要处理高质量语料收集、tokenizer训练、预训练稳定性、分布式并行策略、对齐微调等一系列问题。那是一个以“月”为单位的纯烧钱游戏单次预训练成本动辄数百万美元普通人基本不用惦记。但如果你是想做一个“AI客服系统”“AI文档审阅助手”“AI数据分析师”那你要解决的核心问题根本不是模型本身而是数据从哪来、怎么清洗和切分、用什么模型/接口、怎么控制幻觉、怎么评估效果、怎么应对高峰流量。这种情况下你的“from scratch”是从零搭建这套工程体系而不是从零写一个神经网络。把这两条路混为一谈是项目失败的头号原因。我见过一个团队花三个月用LoRA微调了一个开源模型结果发现换用GPT-4o或Claude这类现成API效果反而更好、成本更低、上线周期只要两天。他们的微调不是做得不好而是从一开始就走错了赛道——他们要的是“合同风险识别”不是“发明一个新模型”。1.2 工程化决策树先问自己五个问题动手之前我建议你先跑一遍下面这组决策问题。每条答案都会直接决定你的技术选型和路线图你要解决的任务现有商用模型GPT级别能做到什么程度如果直接调用API准确率已经达到80%以上优先走API路线。你的数据是否涉及隐私或合规要求必须本地部署如果是直接排除云API锁定开源模型。你的任务是否极度垂直通用模型表现明显拉胯比如识别某种特种行业的图纸标注、理解某个老系统的专有协议——这类场景才值得考虑微调。你的调用量有多大每天几百次请求用API很划算每天几百万次请求可能就要考虑部署开源模型来降低成本。你的团队有没有GPU运维能力如果没有即使开源模型更省调用费你也要掂量掂量自己扛不扛得住推理服务挂了没人修的后果。这份决策树的价值在于它把“技术方案选型”从“我喜欢哪个框架”变成了“哪个方案在约束条件下最优”。约束包括成本、团队能力、数据合规、延迟要求、效果指标。记住工程不是炫技是在约束下做取舍。1.3 先定义“done”是什么样子做AI工程最容易踩的一个坑项目已经跑了一个季度团队还在争论“什么叫做好”。给我一张需求清单“让AI自动提取合同里的付款条款”——这句话可以被十个人理解成十个版本。付款条款是只包含账期和金额还是包含逾期罚则输出是结构化JSON还是自然语言摘要准确率要求是95%还是80%处理不了的时候是抛异常还是给默认值这些必须在写第一行代码之前定义清楚。我的习惯是建一个“验收清单”逐条写清楚输入格式PDF、Word、扫描件最大页数限制输出格式字段级的JSON schema每个字段的类型和取值范围效果指标字段级准确率、端到端通过率、人工介入率性能指标单条处理延迟P95不超过多少秒批量处理吞吐量兜底行为置信度低于阈值时怎么处理是转人工还是拒答这套“done的定义”本质上就是给AI系统立了一个靶子。后面所有数据准备、模型调优、架构调整都得对着这个靶子打。没有靶子AI项目的“无限可能性”就会变成“无限拖延”。2. 数据管道AI工程的地基也是最脏最累的环节2.1 数据不是“越多越好”而是“越对齐越好”很多人在AI项目里最执着的事就是攒数据。跟客户聊需求开口就问“你们有多少数据”好像数据量越大模型效果就自动越好。但我在实际项目里最大的感悟是数据量和模型效果之间没有什么必然的正比关系。真正起决定性作用的是数据跟你的任务目标对齐到什么程度。举个例子。你做一个法律文书摘要系统搞来了10万篇判决书原文但判决书里一半信息是案号、法院名称、当事人信息真正需要摘要的核心争议焦点只占文本的很小比例。你拿这10万篇原文去微调或者做few-shot效果大概率不如你手写一份“如何抽取争议焦点”的详细说明书再把50篇高质量标注样本丢给大模型做参考。所以做AI工程的第一课不要急着收集数据先定义你要“喂”给模型什么信息。对齐度不高的海量数据只会让模型学到一堆没用的统计相关性还会显著拖慢训练速度、增加token成本。2.2 数据清洗脏数据会以十倍的代价回来找你做数据管道的第二个认知清洗环节占整个AI项目的工作量少则40%多则70%。这不是夸张。我做过一个合同条款抽取项目最初拿到一批PDF合同第一反应是“直接解析成文本丢给模型就行”。结果真正做下去才发现很多合同是扫描件要先OCROCR出来的文本存在大量乱码和错位同一份合同在不同版本里排版不同有的条款标题是“第三条”有的是“3.”还有的直接没有编号。如果这些脏数据不处理干净后面无论用提示词还是微调输出的结构都会乱成一锅粥。我总结了一套实用清洗流程供你参考文本提取后先做编码检测统一转成UTF-8修复常见乱码字符按文档结构做版面还原标题层级、段落边界、表格结构的还原比单纯“把字抽出来”重要得多建立“空值、重复、噪音”三张清单逐项清洗抽查清洗完成后随机抽200条人工逐条检查质量不要只看自动化指标记住一个残酷的现实模型输出的质量上限不会超过你喂进去的数据质量上限。你把垃圾喂进去得到的一定是看起来流畅但事实性一塌糊涂的垃圾。2.3 标注平台与“人机协同标注”数据标注是另一个容易埋雷的环节。早期我做AI项目总喜欢想方设法自动化标注——先用规则抽再让大模型辅助预标注最后留给人来校验。方向没错但执行时要注意一个度的问题纯靠模型自动标注、人工不看数据质量一定崩纯靠人工逐条标注效率又太低、成本扛不住。我比较推荐的做法是“模型初标 专家复审 争议仲裁”的三级流程第一级用规则引擎或者大模型在统一提示词框架下生成初步标注结果第二级由懂业务的人不是只会点鼠标的标注员对模型初标结果做抽检和修正重点检查边界case第三级把专家之间标注结果不一致的样本单独挑出来开会讨论并沉淀成标注规范这个流程跑一段时间后你会积累出一份非常宝贵的“争议样本集”。别小看这些样本——它们正是模型最容易翻车的地方后面做评估集时用得上。2.4 数据版本管理与隐私红线工程化的数据管道必须有版本管理意识。到今天我们的AI训练集、评估集、提示词版本全部都放在Git仓库里管理哪怕一个提示词的微调也要走提交记录。不然等你模型跑崩了根本回溯不了是数据变了、代码变了还是提示词变了导致的。隐私和安全这块没有讨价还价的余地。如果你的数据涉及个人身份证号、银行卡号、医疗记录第一原则是绝不直接进API、进模型。即便要做脱敏处理也要在架构里明确“原始数据不出内网”的红线模型只能接触脱敏后的派生数据。合规问题一旦踩雷项目做得再漂亮也救不回来。3. 模型选型不是“最好的模型”而是“最合适的那一个”3.1 评估你的真实约束成本、延迟、私有化、效果模型选型这件事很多人的思路是“哪个评测榜第一选哪个”。这个思路在做工程的时候要吃大亏。因为评测榜上的分数是在特定的、和你任务不完全一致的benchmark上跑出来的而你的任务往往有自己的“口味”。我从五个维度来做模型选型你可以直接抄这个框架表格模型选型五维评估框架维度评估问题对决策的影响效果在你自己准备的代表性样本上实测准确率/相关性如何最重要但别只看均值看最差样本的表现成本单次调用的token成本或自部署的硬件折旧电费运维人力决定你的商业模式是否跑得通延迟P50/P95响应时间是否满足业务要求实时交互场景卡的紧离线批处理可以放松安全合规数据能否出域模型厂商的数据留存政策是什么决定能不能用商用API还是必须私有化部署可控性模型可微调程度、输出格式稳定性、工具调用能力决定你是否能把它集成进现有系统而不翻车3.2 商用API vs 开源模型一个实测对比拿我最近做的一个“招投标文件关键信息抽取”项目来看。一开始团队倾向于部署开源模型理由是“不按调用量付费长期看成本低”。我们选了当时效果排前列的一个开源模型在100份招投标文件上做实测。结果呢结构化输出格式不稳定字段经常缺失JSON偶尔还带多余的说明文字。我们花了大量精力做json修复和格式对齐还是达不到客户要求的98%准确率。后来我们拿了同样100份文件去测试最顶级的商用API准确率直接提升到99%以上返回格式干净得几乎不需要后处理。虽然单次调用有成本但省掉了格式修复、人工复核、字段告警这些系统性成本。算下来商用API的总拥有成本反而更低。这个案例想说明的道理是选型不能“省了小钱花了大钱”。顶层模型贵出来的那点钱如果能把格式问题、效果问题一次解决省下来的工程人力成本早就回本了。3.3 开源自部署的适用边界我不是说开源模型一无是处。有三个场景开源模型是绝对的首选数据完全无法出域私有化部署是唯一合法路径调用量极大日均千万级且你对效果要求没那么苛刻比如固定领域的分类、抽取你的团队有扎实的推理优化能力能用vLLM、TensorRT-LLM这些工具把开源模型的吞吐量压榨到极致但自部署的隐形成本你要做好心理准备一块A100或者H100的采购/租赁费用是实打实的模型版本升级后要重新做评测和回归推理服务出问题的时候你要有能力看CUDA报错、调显存、处理并发。3.4 微调到底该不该做我把微调的决策放在最后一个讲是因为它的滥用最严重。很多团队做微调的动机是“手里有数据、有GPU不用有点浪费”。但微调不是万金油它有三个严格的适用条件第一效果瓶颈已经明确出现在“知识或风格”层面而不是“调用逻辑”层面。比如你发现GPT-4已经能把合同条款抽取得很好但生成的语言风格不够正式这时用几十条“正式风格样本”做SFT是有效的。第二你有足够干净、足够对齐的训练样本。微调这玩意儿样本质量差的时候效果反而比不微调还差。第三你有能力做微调后的回归评测。微调的最大风险是“灾难性遗忘”——模型可能在你想要的方向上变好了但在其他基础能力上悄无声息地崩了。没有评测体系护航的微调本质上是盲人骑瞎马。在我的实践里八成以上的业务场景根本不需要微调。先试提示词工程再试RAG检索增强生成最后才考虑微调。这条路走下来时间和金钱成本都最省。关于RAG我在下一节详细展开。4. RAG与提示词工程当前AI应用落地最核心的“两手”4.1 为什么RAG是中小团队的救星接着说RAG。如果你没有大规模训练数据、没有GPU集群、没有算法团队但你有一个实际的业务问题RAG就是那个让你用最低门槛做出靠谱AI应用的技术体系。它解决的问题非常朴素模型脑子里的知识是“通用”的但你的业务知识是“私有”的。RAG就是先把私有知识切碎、索引、存进向量数据库用户在提问时先把问题和私有知识做相似度检索把最相关的片段“塞”进上下文再让模型基于这些片段做回答。这样做的直接好处有三个答案有依据、知识能秒更新、幻觉显著降低。“答案有依据”意味着模型的每个结论都可以追溯到具体的文档片段这在合同审查、法律咨询、医疗问答这类场景里是命门级的诉求。“知识能秒更新”意味着你不需要重训模型往库里更新几篇文档模型第二天回答的就是新知识。“幻觉显著降低”是因为模型不再是凭空生成而是基于检索到的片段做推理——虽然不是100%消除幻觉但已经把幻觉制约在了片段范围内。我个人的经验做过几十个AI应用之后RAG在我的项目组合里出现的频率超过60%。与其盯着“微调一个行业大模型”这个宏大的目标不如先把RAG的每一个环节做扎实。4.2 一个可复现的RAG工程流程这里直接给出一套我验证过多次的RAG落地流程六步走文档解析与清洗PDF、Word、HTML各自有不同的解析工具链把版面信息保留下来标题、页码、表格结构分块Chunking这一步远没有想象中简单。固定字符切块比如512字符一刀切虽然简单但会把语义完整的段落拦腰斩断。我的实践是按“标题语义块”切——一个小节作为一块块太小就用相邻块做重叠拼接向量化Embedding选嵌模型的时候看两个指标检索召回率RecallK和维度和存储成本相关。中文场景下BGE、M3E等开源嵌入模型都值得纳入评测清单索引存储主流选择是Milvus、Qdrant、Elasticsearch小项目直接用pgvector也行。关键一步是建混合检索——向量相似度和关键词BM25加权结合能大幅提升检索准确率生成把检索到的Top-K片段拼进提示词要求模型“只基于提供的上下文回答不要编造信息”并显式要求它引用上下文编号来方便溯源评估与迭代每轮调整分块策略、检索参数、提示词模板后都要跑同一批评估题做对比看指标是升了还是降了这套流程每一步都有很多细节但最核心的一条是RAG的效果上限取决于检索质量。检索不到、检索出来一堆垃圾后面生成环节再强也白搭。4.3 提示词工程硬核的“软件设计”很多人把提示词工程看成“跟AI说说好话”的玄学这完全是误解。在我看来提示词工程本质上是“面向大模型的软件设计”。你的提示词就是一份需求规格说明书模型的输出就是对应需求的实现。提示词写得烂代码输出自然烂。写高质量提示词有几个我总结下来的要点明确角色与目标“你是专利审查助手你的任务是从给定的专利申请文本中提取技术特征、解决的技术问题和有益效果”给出输出格式蓝图直接给它一个JSON schema或者Markdown模板模型会严格跟着结构走提供few-shot示例给1-3个“输入-输出”对模型很快就能学会你要的抽取逻辑设置负面约束“不要输出与给定文档无关的信息”“当无法从文档中确认信息时输出null”给模型“思考时间”在触发多步推理时要求模型“先拆解步骤再给出答案”能明显提升复杂任务的准确率我强烈建议团队把提示词当成代码来管理。版本化、评审、回归测试缺一不可。事实上一个好的提示词版本库配合一套覆盖边界场景的评估集抵得上半个算法团队。5. 评估体系没有评测的AI工程等于闭着眼睛开车5.1 为什么评估是AI工程里最被低估的环节我可以负责任地说在几十个实际AI项目中凡是效果稳定的、敢上生产环境的背后一定有一套严谨的评估体系凡是效果时好时坏、上线后被业务方追着吐槽的几乎都没有认真做评估。原因很简单。传统软件的bug是可复现的——代码写错了每次跑都会报错修好就好了。但大模型的行为是概率性的——同一个提示词这次答对了下次可能就答错了。你不能用“测试用例跑一遍全绿”来衡量AI系统的质量你需要的是持续的、统计意义上的效果监控。5.2 三明治评估法自动评估人工抽检线上监控我自己在项目里跑得最顺的一套评估玩法叫三层评估第一层是离线自动评估。我准备了一个100-500条的“黄金评估集”覆盖典型场景、边界场景、陷阱场景。每次改提示词、换模型、调RAG参数就跑一遍自动评估用LLM-as-Judge让一个强模型当裁判打分来批量打分快速拿到回归结论。第二层是人工抽检。自动评估不等于可信评估。每周抽20条模型输出由业务专家打分。这一步的关键是发现自动评估发现的漏网之鱼——尤其是那些“看起来专业实际上胡说八道”的幻觉样本。第三层是线上监控。系统上线之后把每次用户请求的输入、输出、检索片段全部记录下来用规则做实时“冒烟监控”比如输出为空、JSON解析失败、内容长度异常、检索得分为0。这些指标一旦异常立刻告警。这套“三明治”的妙处在于它把“评估”从开发期的临时动作变成了上线后的长期制度。5.3 硬指标和软指标抓准确率之前先抓三个基础指标我经常跟团队说不要一上来就盯着准确率、F1这些“体面指标”。在那之前有三个更基础的指标更值得盯可用率模型这次调用到底有没有产出可以被下游直接消费的结果比如JSON能不能被解析字段齐不齐——很多AI系统上线后跑没多久就嗝屁问题不在“答得对不对”而在“根本没答出可用格式”无效调用率有多少请求模型“接住了”但答案是胡编的、超纲的、与上下文无关的这个指标直接反映幻觉的严重程度干预率有多少输出需要人工修改或驳回干预率持续走高说明系统在“帮倒忙”还不如纯人工干把这三个基础指标抓好再去优化准确率才有意义。一个“准确率很高但三天两头输出坏格式、或者三天两头需要人工纠错”的系统比一个“准确率略低但稳定可控”的系统要危险得多。6. 推理与部署从模型到产品最后一步才是魔鬼6.1 架构模式不要把“调用大模型”做成单体模块我发现很多AI应用从架构上就埋着雷。它们把模型调用写成了一个“大怪物函数”业务逻辑、上下文组装、重试逻辑、输出解析全炖在一起。开头跑demo没问题一旦上线出了问题无从下手想改一处逻辑牵一发动全身。我现在做AI系统架构倾向于把链路拆成一串清晰的模块输入预处理模块格式校验、清洗、上下文组装模块检索、历史记录、提示词模板、模型调用模块统一管理API/自部署带重试、超时、熔断、输出解析模块JSON修复、字段校验、后处理、反馈采集模块记录用户行为回流评估。每个模块是独立的、可测试的、可替换的。这种架构最大的好处是当“模型响应质量变差”时你能快速定位是哪一环出了问题是检索拉垮了提示词被改崩了还是模型接口侧升级导致输出走了样。没有这种模块化排查一次问题就是一次全链路的灾难。6.2 稳健性设计重试、超时、熔断、降级AI服务的稳定性问题本质上和传统微服务有很多相似之处但多了一个变数模型输出的不可预测性和高延迟波动。先说超时设置。我见过很多团队把超时时间设成30秒甚至60秒理由是“让模型好好思考”。结果是用户在前端干等着体验崩塌。我的建议是交互场景的端到端延迟必须控制在5秒以内模型调用超时设成10秒已经是极限剩下的时间要留给检索和后处理。超时即熔断返回“系统繁忙请稍后重试”比让用户无限等待要体面得多。再说重试策略。模型调用失败时直接重试往往会再次失败。更稳妥的做法是“退避重试”第一次失败等1秒再试再失败等2秒最多重试3次。重试之间可以做节点切换如果用了多个模型供应商也可以做降级——从大模型降级到规则引擎挡不住所有请求但至少把核心业务保住了。最后说降级预案。AI系统必须想清楚“AI挂了怎么办”。降级不只是返回错误码而是要准备一条“无AI”的备用路径。比如智能客服挂了就退回FAQ关键词匹配文档抽取挂了就退回人工处理队列。很多团队把全部业务押在AI上一旦模型供应商故障或者自部署服务宕机业务就完全瘫痪。这不是工程化的做法。6.3 成本治理token是钱延迟是命部署之后还有个长期课题成本治理。大模型API的计费是按token走的这意味着你的每一版提示词、每一次检索拼接、每一轮多轮对话都可能带来真金白银的消耗。我做一个多轮客服AI的时候发现对话超过5轮之后历史记录占用的token就已经超过了单轮回答本身。后来改成只保留最近的3轮对话压缩历史总结成本直接砍掉近40%。另外缓存是一个经常被忽视的成本杀手。对于用户高频提问的重复问题比如“你们的退货政策是什么”你完全可以在RAG检索层做一层缓存——命中缓存就直接返回。实测下来简单缓存策略能降低30%以上的模型调用量。成本治理的原则很简单每个token都要花在刀刃上。衡量“刀刃”的方法是——删掉这块上下文模型回答的质量会不会明显变差如果不会它就是冗余token删。7. 从0到1的落地路线图我的一次完整实战复盘7.1 项目背景与初始拆解讲了这么多方法论最后拿一个真实项目做完整复盘。那是给一家制造企业做“设备故障工单智能诊断助手”。业务背景是工厂每天产生大量设备故障工单老师傅挨个看、挨个分诊效率低且经验都集中在少数人身上。我们的任务不是“做个AI回答一切问题”而是让AI基于企业积累的历史工单库对新工单做三项事情故障类别判断是机械故障、电气故障、还是操作失误根因线索提取从故障描述文本中提取关键现象和设备型号处置建议生成参考历史相似工单的处理方案生成初始建议初始拆解之后我们发现这个任务有一个非常有利的条件企业有十几年的历史工单数据总共几十万条里面既记录了现象描述也记录了最终处置结果。这些数据天然就是“问题-答案对”做RAG或者微调都行得通。7.2 数据清洗与知识库构建的波折这个项目最痛苦的环节不是模型还是数据。几十万条工单下载下来我们发现质量参差不齐有手写扫描转文字的错别字、“电机”“电动机”“马达”同一设备三种写法、大量口语化描述“这机器喀啦喀啦响吓人”和正式术语混杂。我们做了轮清洗与标准化统一了设备名称的同义词映射把手写识别错字做了修正基于人工抽检和规则把口语化描述做了规范改写。清洗完有效工单从几十万掉到十几万——但这个牺牲是值得的因为喂给RAG的语料质量直接决定了后续检索和生成的底线。知识库构建时我们采用了“两级结构”第一级是设备型号-故障现象-处置方案的结构化条目方便精确检索第二级是完整历史工单原文方便模型参考相似案例的推理过程。检索时同时查两级库取Top-K做重排后拼进上下文。7.3 模型链路与效果迭代模型链路最终定的是商用大模型API做生成 开源Embedding模型做向量检索 Elasticsearch做关键词语义混合检索。为什么没有全用开源模型私有化部署因为试验阶段我们发现开源模型在处理“模糊的、口语化的故障描述”时分类准确率比商用API低了将近10个百分点。从全局成本看与其花大量时间调优开源模型不如先用商用API把效果做到位后续如果调用量大了再考虑替换。第一次上线后效果指标达到了目标线故障类别判断准确率91%、处置建议采纳率被工程师实际采用的比例76%。但很快我们发现一个隐蔽的问题模型生成的处置建议在面对历史库中没有出现过的“新故障类型”时会一本正经地给出一段看似专业但实际是幻觉的处置步骤。这个风险对设备维护场景是不可接受的。于是我们在链路里加了“置信度闸门”模型在生成处置建议时必须先输出它对检索到的相似案例的匹配度打分。打不到阈值就走“仅输出现象分析和可能原因不给具体处置步骤并建议转人工专家”的兜底路径。改造之后“错误处置建议被工程师当真”的概率显著下降工程师甚至反馈“AI承认自己不确定”反而增加了协作信任度。7.4 上线之后反馈闭环才是生命的开始系统上线三个月后我复盘发现真正让系统变好的不是我们上线前的调优而是上线后持续建立的反馈闭环。我们在工程师处理工单的界面上加了一个“采纳/修改/弃用”三档反馈按钮每次工程师对AI建议采取动作都会被记录并回流到下周的评估集。这个闭环的价值在于它让模型的每一次错误都变成了一次可供学习的数据。第二个季度我们把反馈数据消化进知识库——把被反复修改的残缺工单重新整编成更规范的结构化条目。模型的效果指标虽然没有“爆炸式”增长但“工程师弃用率”从第一季度的24%降到了第二季度的17%这个慢变量才是系统真实价值的体现。8. 最后分享几个实战认知做AI工程这几年尤其是亲手把一个又一个“从零开始”的项目推上线之后我心态发生了很大变化。以前拿到一个新项目最兴奋的是“这次又能用什么新模型、新技术”现在拿到项目第一反应是“这块业务约束是什么、数据在哪、成功标准是什么”。技术变成了手段工程变成了习惯。如果说有什么经验最值得你带走我会选这四条第一AI工程的核心瓶颈永远是数据和组织不是模型。模型能力现在每年都在跳跃式提升但你的数据清洗流程、评估体系、团队协作机制不会自动变好它们需要你刻意建设和维护。第二“效果不好”不一定是模型的问题。先查你的检索是不是拉胯了提示词是不是有歧义评估集是不是有脏数据输出解析是不是丢字段。这些问题解决掉之后你会发现模型“变聪明”了。第三控制幻觉不是让模型“更听话”而是给你的系统设计“承认无知”的路径。置信度闸门、兜底回答、人工转接这些都是幻觉控制的实际手段。一个知道自己不知道什么、并能优雅地转交的系统远比一个假装全知但经常胡说的系统更专业。第四别把评估和监控当成上线前的“一次考试”要当成贯穿项目全生命周期的“长期体检”。模型会升级数据会漂移业务会变化没有持续评估护航的AI系统就像没有保养的汽车——开起来没事但迟早出事。最后分享一个小技巧单独维护一个项目的GPTs接口每次做完一次实验或调整就让AI用验收清单检查一遍自己改了哪些东西、动了哪些数据、可能影响哪些评估指标。相当于给AI项目配了一个“工程助理”。很多技术团队管这个叫做测试用例我更喜欢叫它“项目的记忆”。因为真正做AI工程的人最怕的就是项目跑着跑着团队里没人能说清楚系统当前是怎么工作的、为什么这么工作。做AI工程从来不是代码敲得有多炫、模型调得有多猛而是你有没有本事把一个不完美但足够可靠的系统放到真实世界里去服务真实的需求然后持续地、耐心地让它变得更好。这条路不难理解但需要一步一个脚印地走。希望这篇文章能给正在从零开始建AI工程体系的你一些可以落地的启示。