企业官网建设流程全解析

先说个题外话。每次有人拿着“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 工程化决策树：先问自己五个问题

动手之前，我建议你先跑一遍下面这组决策问题。每条答案都会直接决定你的技术选型和路线图：

1. 你要解决的任务，现有商用模型（GPT级别）能做到什么程度？如果直接调用API，准确率已经达到80%以上，优先走API路线。
2. 你的数据是否涉及隐私或合规要求，必须本地部署？如果是，直接排除云API，锁定开源模型。
3. 你的任务是否极度垂直，通用模型表现明显拉胯？比如识别某种特种行业的图纸标注、理解某个老系统的专有协议——这类场景才值得考虑微调。
4. 你的调用量有多大？每天几百次请求，用API很划算；每天几百万次请求，可能就要考虑部署开源模型来降低成本。
5. 你的团队有没有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合同，第一反应是“直接解析成文本，丢给模型就行”。结果真正做下去才发现，很多合同是扫描件，要先OCR；OCR出来的文本存在大量乱码和错位；同一份合同在不同版本里排版不同，有的条款标题是“第三条”，有的是“3.”，还有的直接没有编号。如果这些脏数据不处理干净，后面无论用提示词还是微调，输出的结构都会乱成一锅粥。

我总结了一套实用清洗流程，供你参考：

1. 文本提取后先做编码检测，统一转成UTF-8，修复常见乱码字符
2. 按文档结构做版面还原：标题层级、段落边界、表格结构的还原比单纯“把字抽出来”重要得多
3. 建立“空值、重复、噪音”三张清单，逐项清洗
4. 抽查：清洗完成后随机抽200条，人工逐条检查质量，不要只看自动化指标

记住一个残酷的现实：模型输出的质量上限，不会超过你喂进去的数据质量上限。你把垃圾喂进去，得到的一定是看起来流畅但事实性一塌糊涂的垃圾。

2.3 标注平台与“人机协同标注”

数据标注是另一个容易埋雷的环节。早期我做AI项目总喜欢想方设法自动化标注——先用规则抽，再让大模型辅助预标注，最后留给人来校验。方向没错，但执行时要注意一个度的问题：纯靠模型自动标注、人工不看，数据质量一定崩；纯靠人工逐条标注，效率又太低、成本扛不住。

我比较推荐的做法是“模型初标 + 专家复审 + 争议仲裁”的三级流程：

• 第一级：用规则引擎或者大模型，在统一提示词框架下生成初步标注结果
• 第二级：由懂业务的人（不是只会点鼠标的标注员）对模型初标结果做抽检和修正，重点检查边界case
• 第三级：把专家之间标注结果不一致的样本单独挑出来，开会讨论并沉淀成标注规范

这个流程跑一段时间后，你会积累出一份非常宝贵的“争议样本集”。别小看这些样本——它们正是模型最容易翻车的地方，后面做评估集时用得上。

2.4 数据版本管理与隐私红线

工程化的数据管道，必须有版本管理意识。到今天我们的AI训练集、评估集、提示词版本全部都放在Git仓库里管理，哪怕一个提示词的微调，也要走提交记录。不然等你模型跑崩了，根本回溯不了是数据变了、代码变了还是提示词变了导致的。

隐私和安全这块没有讨价还价的余地。如果你的数据涉及个人身份证号、银行卡号、医疗记录，第一原则是绝不直接进API、进模型。即便要做脱敏处理，也要在架构里明确“原始数据不出内网”的红线，模型只能接触脱敏后的派生数据。合规问题一旦踩雷，项目做得再漂亮也救不回来。

3. 模型选型：不是“最好的模型”，而是“最合适的那一个”

3.1 评估你的真实约束：成本、延迟、私有化、效果

模型选型这件事，很多人的思路是“哪个评测榜第一选哪个”。这个思路在做工程的时候要吃大亏。因为评测榜上的分数，是在特定的、和你任务不完全一致的benchmark上跑出来的，而你的任务往往有自己的“口味”。

我从五个维度来做模型选型，你可以直接抄这个框架：

表格：模型选型五维评估框架

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落地流程，六步走：

1. 文档解析与清洗：PDF、Word、HTML各自有不同的解析工具链，把版面信息保留下来（标题、页码、表格结构）
2. 分块（Chunking）：这一步远没有想象中简单。固定字符切块（比如512字符一刀切）虽然简单，但会把语义完整的段落拦腰斩断。我的实践是按“标题语义块”切——一个小节作为一块，块太小就用相邻块做重叠拼接
3. 向量化（Embedding）：选嵌模型的时候看两个指标：检索召回率（Recall@K）和维度（和存储成本相关）。中文场景下，BGE、M3E等开源嵌入模型都值得纳入评测清单
4. 索引存储：主流选择是Milvus、Qdrant、Elasticsearch，小项目直接用pgvector也行。关键一步是建混合检索——向量相似度和关键词BM25加权结合，能大幅提升检索准确率
5. 生成：把检索到的Top-K片段拼进提示词，要求模型“只基于提供的上下文回答，不要编造信息”，并显式要求它引用上下文编号来方便溯源
6. 评估与迭代：每轮调整分块策略、检索参数、提示词模板后，都要跑同一批评估题做对比，看指标是升了还是降了

这套流程每一步都有很多细节，但最核心的一条是：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这些“体面指标”。在那之前，有三个更基础的指标更值得盯：

1. 可用率：模型这次调用到底有没有产出可以被下游直接消费的结果？比如JSON能不能被解析？字段齐不齐？——很多AI系统上线后跑没多久就嗝屁，问题不在“答得对不对”，而在“根本没答出可用格式”
2. 无效调用率：有多少请求模型“接住了”但答案是胡编的、超纲的、与上下文无关的？这个指标直接反映幻觉的严重程度
3. 干预率：有多少输出需要人工修改或驳回？干预率持续走高，说明系统在“帮倒忙”，还不如纯人工干

把这三个基础指标抓好，再去优化准确率才有意义。一个“准确率很高但三天两头输出坏格式、或者三天两头需要人工纠错”的系统，比一个“准确率略低但稳定可控”的系统要危险得多。

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工程体系的你，一些可以落地的启示。