这两年我接触了不少做AI项目的团队也亲手带过几条从零开始的产品线最大的感受是“ai-engineering-from-scratch”这几个词看着像一个入门教程的标题实际上是一条特别硬核的工程链路。很多人以为从零开始做AI就是学会调API、写Prompt、把模型跑通最后发现Demo很美好、上线就翻车。真正的问题不在模型而在模型外围那一圈——数据怎么管、评测怎么做、怎么部署、怎么监控、怎么控制成本。这篇文章我想用自己的实操经验把“从零开始做AI工程”这件事拆开来讲。不是教科书式的流程罗列而是我真实走过的路和踩过的坑。适合正在准备做AI应用、想把大模型接入业务、或者刚从传统软件工程转过来的读者——你会发现AI工程和常规后端开发有本质区别而恰恰是这些区别决定了项目能不能走到上线。1. 为什么说“AI工程”和“写个调用模型的脚本”是两码事1.1 传统软件工程有“确定答案”AI工程没有我先说一个最容易被忽略的底层差异。如果你写过常规后端接口比如一个查询订单的接口输入订单号输出订单详情——这个函数的输入输出是确定的测试用例是可以穷举的回归测试跑一遍就知道有没有改坏东西。但AI系统不一样。你输入同一段Prompt模型可能给出不同回答你换一个Prompt措辞结果可能天差地别更麻烦的是你很难说清楚“什么叫回答对了”。一个客服问答系统用户问“你们发货要几天”模型回答“一般3到5天”和回答“我们通常会在48小时内发出偏远地区可能稍慢”哪个更好这没有唯一正确答案只有“更符合业务目标”的答案。所以我一直跟团队强调做AI工程等于在做一套概率系统而不是确定性系统。它和传统软件的关系类似于“自动驾驶”和“电梯控制程序”的关系——后者有明确的状态机前者的每一步都带着不确定性。传统开发思维里的“写一个函数、加一个断言、跑通就完事”在AI项目里完全不适用。1.2 AI工程的完整闭环数据、评测、反馈才是真正的骨架那从零开始做AI真正要搭的是什么是一个闭环而不是一条单向的流水线。我把这个闭环画成五个环节你可以对照自己项目看看卡在哪一环业务问题定义你想让系统做什么、输入输出是什么、哪些场景必须处理好、哪些错误不能犯。数据工程收集、清洗、组织、标注数据包括历史对话、文档库、日志、人工标注样本。模型与提示调优选择合适的模型、编排Prompt、搭建检索或Agent框架。评测体系建设评测集、定义指标、跑离线评测、做bad case分析。部署与监控上线服务、记录线上输入输出、收集用户反馈、回流数据、迭代模型。这五步里最容易被新手跳过的是“评测体系”和“反馈回流”。我见过太多团队花大力气调Prompt、换模型到最后问他们“你怎么知道现在比上周好”答不上来。这就是典型的只有过程、没有闭环。AI工程和传统工程更本质的区别也在这里传统工程交给用户的是一个“已完成的产品”而AI工程交付的是一个持续进化的系统。数据回流、线上反馈、模型迭代这些不是上线之后才考虑的事而是在第一行代码之前就要设计的机制。1.3 什么阶段需要读到这篇文章我这里说的“从零开始”不是指从神经网络原理开始学数学也不是指从Tokenizer开始实现一个大模型——那是研究人员的事。我指的是你们团队刚决定做一个AI功能但还没定技术方案你已经在用某个模型写Demo但不知道怎么把它变成稳定服务你被安排搭建内部AI工具需要一套从需求到上线的完整方法论你是传统后端/前端工程师想系统性地转做AI应用开发。这篇文章的知识点不是一段一段孤立的技术而是按真实项目的时间顺序组织的。你可以顺着读也可以跳到自己关心的章节。但如果你现在连“评测集”都还没开始建我建议你认真读一下第2章和第5章那是我认为最值钱的干货。2. 从零起步的完整链路需求-数据-模型-评测-上线2.1 第一关把模糊想法翻译成可验证的“任务定义”“老板说要做个智能客服”和“把这个智能客服做好”之间隔着一整条需求拆解的鸿沟。我见过最典型的失败案例是团队拿到的需求只有五个字“做个AI助手”然后所有人凭感觉理解后端觉得是FAQ匹配产品觉得是聊天机器人老板其实想要的是销售线索自动跟进。各做各的最后拼出来的东西四不像。所以从零做的第一步不是选模型而是写任务定义文档。不需要很长但要回答下面四个问题输入范围系统接收什么形态的输入纯文本、语音、多轮对话会包含哪些业务字段输出形态输出是自然语言回复、结构化JSON、还是直接调用某个动作比如建工单、查库存限制条件有哪些是不能碰的红线比如不能给用户承诺未确认的赔偿金额、不能伪造数据、必须引用哪个版本的文档。成功标准怎么算“好”是回答准确率、用户满意度、还是任务完成率我举个例子。同样是“做一个合同审核助手”弱定义是“帮法务看看合同有什么问题”强定义是输入一份PDF合同和合同类型输出一个JSON包含条款名称、风险等级高/中/低、风险说明、修改建议高风险的必须包含“可能存在法律责任”的表述。你看一旦定义到这个粒度后续的方案设计、评测建设、模型选型都变得有方向了。还有一个容易犯的错只关注“做出来”不关注“怎么验收”。任务定义里必须写清楚“可验证的验收方式”——最好是有具体例子。比如“对于包含违约金条款的合同输出中必须指出违约金比例是否合规”。这种例子不一定是全量标准但它是你评测集的种子。2.2 数据工程决定系统上限的那部分工作量在AI项目里你的系统上限不是由模型决定的而是由数据决定的。模型决定的是“地板”如果你连干净的数据和合理的评测集都没有再好的模型也发挥不出来。从零开始做数据工程我建议按“三件事”来做第一件事是收集。先别管质量把你能拿到的原始数据都拿过来历史客服对话、工单记录、操作日志、文档库、FAQ甚至是可以人工生成的模拟数据。这个阶段的目标是“覆盖尽量多的业务场景”因为后续你要靠这些数据去发现系统该处理什么。第二件事是清洗与组织。这里最坑的是脏数据和噪声。比如做客服模型历史对话里可能一半是“在吗”“你好”这种寒暄或者只有用户问题没有客服回复的记录。这种数据不洗干净模型就会被带偏。清洗至少要看字段是否完整、答案是否有实际内容、是否存在敏感信息需要脱敏。第三件事是分场景切片。不要只统计“总共有多少条数据”要把数据按场景切开来看。比如客服数据可以分成售前咨询、售后问题、物流查询、退款投诉。每个场景的条数、质量、难度都不一样。为什么要切片因为你后续建设评测集时也要按同样切片来抽样才能知道系统在哪个场景拉胯。总准确率90%看起来不错但一切片发现“退款投诉”场景只有50%那这个系统就不能上线。数据版本管理也是从零开始就要养成的习惯。至少要把数据放在Git能管的地方每次调整完数据要打版本号。原因很简单AI系统的行为是由数据和代码共同决定的如果你的数据改了一版评测结果变了你却查不出来是哪一批数据的变更导致的后面排错会痛不欲生。2.3 模型选型API调用、开源权重、微调的三级阶梯很多新手一上来就纠结“我要微调LLaMA还是直接用GPT”其实这是把选型问题想窄了。我自己的选型逻辑是三级阶梯从便宜到贵、从快验证到重投入第一级直接调用商用API比如OpenAI、Claude、通义、文心等只做Prompt编排。适合通用问答、文本改写、信息抽取、知识库问答。优点是成本低、见效快、不用养运维缺点是数据要出域部分场景不允许、延迟和单价可控性弱、长期成本会随调用量线性增长。第二级用开源权重模型部署私有服务比如Qwen、Llama、DeepSeek等。适合数据敏感、需要私有化部署、有GPU资源、对延迟有一定容忍度。优点是数据不出内网、单次调用成本低、可以针对自身业务做领域适配缺点是要自己处理并发、显存、推理优化、模型更新需要团队有工程能力。第三级在开源模型基础上做微调。适合有大量高质量业务数据、需要固定输出格式、通用Prompt怎么调都达不到效果。比如你做的是票据抽取输出字段非常固定靠Prompt容易飘那微调一个专用小模型是正路。我在实际项目中的经验是能用第一级就不上第二级能靠Prompt解决就绝不轻易微调。原因很简单Prompt改一次只需要几分钟而微调一轮从数据准备到训练评测最快也要几天慢则数周。很多团队死在“用战术上的勤奋掩盖战略上的懒惰”——连Prompt都没认真调过就直接跳去微调结果数据和工程问题一堆。为了帮你快速判断我做了一张选型决策表你可以直接照抄决策问题选API调用选私有部署选微调数据能否出域能不能不能调用频率和并发中低有峰值要控并发有峰值要控并发是否需要固定输出结构靠Prompt解决靠Prompt解决Prompt搞不定才考虑GPU资源和运维能力不需要需要需要且有训练环境延迟要求一般可接受优先满足同上长期成本模型按量付费固定硬件成本训练推理双成本记住选型不是一步定终身的。我的习惯是先上API把流程跑通等业务稳定、调用量大起来了再评估是否要迁到私有部署。这个过程叫“先验证后投入”能帮你避开90%的选型误判。2.4 评测先行没有评测集就不要谈优化如果你只从这篇文章里记住一件事我希望是这一件建设评测集应该在写业务代码之前而不是上线之后。为什么因为AI系统的优化是一个“来回试”的过程——你调Prompt、换模型、改RAG参数每一轮都必须有同一把“尺子”来量效果。尺子就是评测集。没有评测集你所有的“优化”都是凭感觉而凭感觉的优化常常是“觉得变好了上线后用户不买账”。一个及格的评测集我认为需要满足三个条件数量不能太少线上真实场景数据至少100条起步最好是300-500条。如果只有二三十条你就是在用噪声做判断任何一点随机波动都会被当成优化成果。覆盖业务切片就像前面说的按场景切片抽样。客服系统就按咨询类型分文档问答就按文档板块分。每个切片里都要有“简单题”和“难题”。标注判分标准不能只给题目不给答案。每条数据要有“标准答案”或者“可接受的答案范围”。比如“用户问你们有没有实体店回答里有‘有实体店’或‘线下门店地址见链接’都算对”。评测集要持续维护。我自己的做法是每个迭代周期都会往评测集里补充“线上翻车案例”——用户反馈不好、模型答错的问题一律进bad case池。这样评测集越来越贴近真实世界的难度分布系统的优化方向就不会跑偏。关于指标很多人只知道准确率但AI项目里单一准确率往往是误导。做客服问答你更关心的是“不回答错误言”避免误导用户与“覆盖率”能不能解决用户问题的平衡做内容抽取你关心的是字段级精确率和召回率做Agent任务你关心的是“任务完成率”和“平均步数”。所以定义评测指标时先问自己**这个系统犯哪种错误最贵**然后针对那个错误设计核心指标这样的评测才有意义。3. Prompt、RAG、Agent三种能力形态的选型决策3.1 Prompt工程不是“写提示词”是接口设计很多团队把Prompt工程理解为“把需求写得更清楚一点”这个理解太浅了。在我看来生产级的Prompt工程本质是在给业务写接口——输入输出协议、错误处理、异常分支都要在Prompt里定义清楚。一个生产可用的Prompt至少要包含这几个部分角色与目标让模型清楚自己是谁、要达成什么业务目标。输入格式说明业务数据怎么传入字段名、字段含义都要交代。输出格式约束要求输出JSON还是Markdown字段结构是什么枚举值有哪些。硬性边界红线哪些话不能说、哪些数据不能编造、不确定时怎么办比如“不知道就回答不知道不要猜测”。示例Few-shot给出2-3条输入输出对尤其要覆盖边界情况和典型错误。举一个我常用的结构化Prompt模板你可以在此基础上改成自己的你是[角色]负责[任务目标]。 输入数据{用户问题}业务信息{字段A}{字段B}。 请严格按照以下JSON格式输出不要输出任何多余文本 {结论: ... 风险等级: 高/中/低 理由: ... 引用来源: ...} 约束条件 1. 如果输入信息不足以判断风险等级必须为“中”理由中明确说明“信息不足”。 2. 禁止编造不存在的条款或数据。 3. 输出必须是合法JSON不得包含Markdown代码块标记。 示例 输入{...} 输出{...}写Prompt最容易犯的错是“引导过度”——把几十条规则全塞进去模型反而不知道听谁的。我的经验是核心约束控制在8条以内能合并就合并。约束数量一多优先级就变得模糊模型往往只会遵循前面两三条。所以写完之后别急着上线先拿几条边界case试一遍看看哪些规则被遵守了、哪些被忽略了。3.2 RAG把外部知识绑进系统时的关键设计当业务需要用“实时更新的知识”来回答问题时RAG检索增强生成就上场了。RAG的通俗理解是别让模型死记硬背给它配一本可以随时翻的书回答时先翻书再说话。它的基础流程是三段知识切片入库——检索召回——拼接生成。听起来不复杂但工程坑全藏在细节里第一是切片策略。很多团队直接把整篇文档切成固定512字块结果一块里装了两三个主题检索出来一堆半截话。我的做法是优先按文档结构切片——有标题就按标题、按段落、按章节尽量保持语义完整同一主题的内容不要被截断。切片长度要根据你用的模型上下文来定一般500-800字是稳妥区间。第二是检索质量。只靠关键词匹配的BM25召回语义理解差只靠向量相似度精确关键词匹配又弱。生产环境我推荐混合检索——关键词和向量召回各跑一遍再做一个重排rerank用重排模型在候选段落里挑最相关的几段。这才是我推荐的做法。很多人不做重排导致回答引用了不相关段落看起来像“一本正经地胡说八道”。第三是引用溯源。RAG系统上线最怕的是用户追问“你凭什么这么说”。所以Prompt里必须强制模型在输出里带上来源标识比如段落引用编号。前端展示时也建议把引用和正文对应起来既提升可信度也方便审计。没有溯源能力的RAG我建议直接不上线。第四是索引更新机制。知识文档每周都在变新增、删除、修改索引必须同步。常见做法是用消息队列监听文档变更事件增量更新向量索引同时做版本控制回答某个问题时用的是哪个版本的知识要有日志可查。我见过最快的翻车方式就是文档库改了三个月索引还是旧的模型还在用过期知识一本正经地“帮助”用户。3.3 Agent当多步骤任务出现时的工程复杂度Agent智能体是这三者里最“亮眼”也最容易失控的形态。它解决的问题是用户的需求不是一句问答能完成的而是需要拆成多个步骤、调用多个工具才能完成。比如“帮我把上周的销售数据汇总成一份周报并发到群聊里”这就涉及数据查询、文本生成、发送消息三个工具。Agent的核心设计点我认为有三个第一是工具接口要收敛。每个工具要像对外API一样定义清楚输入参数是什么、输出结构是什么、什么情况下会失败。不要给模型暴露一堆松散函数。工具多了模型会“选择困难”经常调用错工具或者传错参数。第二是状态管理要有度。多步任务中间Agent当前已经完成了哪一步、下一步该干嘛、上下文有哪些关键信息都需要显式管理。别让模型每次都在一堆原始上下文里“重新摸索”。我建议把核心状态提炼成槽位比如“已拿到销售数据”让模型知道自己干到哪了。第三是必须加护栏Guardrail。护栏不是可选项是必选项。包括最大执行步数比如最多调用5次工具、单轮任务预算上限Token和金额、敏感动作人工确认发送、支付、删除类操作必须停了等人点确认、超时熔断某一步卡住就中止整个任务。没有护栏的Agent就像没有刹车还上了高速的车。很多Demo能跑通是因为只配了一两个工具但你一上生产就会发现工具稍微多几个Agent就开始“乱走”——重复调用、死循环、成本飙升。所以我的原则是2-3个工具以内的任务先试试硬编码工作流工具多了再考虑上Agent框架。能用流程编排解决的就不要把控制权全交给模型。3.4 一张选型决策表如果你还不确定自己的场景到底该用Prompt、RAG还是Agent我整理了一张决策表直接按问题往下走就行你的场景特征建议方案原因知识固定、回答简单、单轮即可Prompt直出成本最低响应最快知识需要经常更新、回答需要引用来源RAG模型不记死知识每次从库里取最新回答依赖用户上传的私有文档RAG按文档检索需要动态定位相关内容任务需要调用多个内部系统Agent单轮问答解决不了多工具编排调用链固定、流程不变先上硬编码工作流减少模型自由度稳定可控调用链不固定、模型需自主决策Agent 严格护栏交给模型规划但用护栏兜底这个表是一个起点不是终点。实际项目里往往是“RAG里带几步Agent动作”“Prompt里内嵌少量检索结果”——混搭才是常态。关键不是选一个形态定终身而是知道每种形态的适用边界和成本按业务复杂度的增长逐步升级。4. 部署与监控AI系统上线后比功能更重要的事4.1 从离线模型到在线服务接口设计和延迟预算AI工程走到部署这一步很多细节会被传统后端经验直接套用但有个最大的差异AI服务的输出不是稳定结构接口层需要额外做一些“翻译和校验”工作。我的做法是对外暴露给业务方的接口尽可能返回结构化数据而不是“一段自然语言”。让模型输出JSON用函数调用或JSON Mode再在服务层用Pydantic做校验校验不通过就走重试或兜底逻辑而不是直接把脏JSON丢给前端。一个最简单的示例用FastAPI Pydanticfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from openai import OpenAI app FastAPI() client OpenAI() class AnalyzeRequest(BaseModel): text: str class AnalyzeResponse(BaseModel): conclusion: str Field(description分析结论) risk_level: str Field(..., pattern^(高|中|低)$) reason: str app.post(/analyze, response_modelAnalyzeResponse) async def analyze(req: AnalyzeRequest): # 调用模型要求只输出JSON prompt f分析以下内容的风险等级...\n{req.text} raw client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], response_format{type: json_object}, ) content raw.choices[0].message.content # 用 Pydantic 校验输出解析失败则返回兜底 try: result AnalyzeResponse.model_validate_json(content) except Exception: raise HTTPException(status_code502, detail模型输出格式异常) return result这种做法的好处是双重的一方面把概率系统的输出“翻译”成确定性的接口协议让调用方放心另一方面模型输出异常时你能第一时间暴露问题而不是让错误静默地传到用户那里。延迟预算也要在接口设计阶段就定好。一般交互式AI接口的目标是端到端1-3秒内返回超过3秒用户就会觉得卡。而大模型推理本身可能就要1-2秒所以你要提前算好是限制输入长度、用流式输出先吐一部分、还是对常用问题做结果缓存。这些不是在性能测试阶段才考虑的事而是接口设计的一部分。4.2 上线后的可观测性不能只看准确率传统后端的监控看QPS、延迟、错误率就完事了AI系统还要多一层内容质量观测。你光知道接口延迟正常没用你得知道“今天模型有没有开始胡说八道”。所以我建议从第一天上线就记录完整的结构化日志至少包含以下字段请求ID、用户ID、时间戳输入内容用户的原始问法、上下文模型输出全文Token消耗输入/输出分别记录模型和Prompt版本号耗时和重试次数触发规则是普通问答、走了RAG、还是Agent调用。这些日志的价值在出问题时才能体现。比如用户投诉“AI乱承诺价格”没有日志你就无法复现模型当时看到了什么输入、输出了什么内容、有没有引用到错误的文档。有了日志一查就知道是Prompt问题、RAG召回问题还是模型本身抽风。日志之外还要有一个人工反馈闭环。最简单的方式是在产品界面上加“有用/没用”按钮或者允许用户对回答打标签。这些反馈数据是金矿——它们是你下一轮bad case池的重要来源。没有用户反馈机制你的系统就只能“盲调”。我在项目里经常用Langfuse这类工具来追踪AI调用链和评测结果很方便地能把线上输入、Prompt版本、Token成本、评测分数关联起来。如果你团队没有预算上商业化工具至少也把JSON日志落全后续随时可以导出分析。4.3 成本治理Token账单和GPU利用率的双重考验做AI系统的成本和传统服务器租用完全是两个逻辑。传统服务器成本是固定的AI成本是随流量非线性增长的——你永远不知道用户下一个问题会触发多少Token。我踩过的坑是上线第一个月没做任何成本控制等账单出来吓一跳——因为每次调用都把整个业务知识库塞进上下文一个看似简单的问题实际消耗了几万Token。后来做了三件事成本直接降了50%以上这里分享给你语义缓存对高频问题做缓存——把用户输入向量化如果和之前问过的问题相似度超过阈值直接返回缓存结果不再调用模型。这个对FAQ类业务效果极好。模型分级路由不是所有问题都需要最强模型。简单逻辑走小模型如gpt-4o-mini复杂推理再上大模型。可以先用分类器判断问题难度再路由到不同模型。Prompt压缩定期检查Prompt里是不是塞了太多“永远用不到”的说明文字。每减少1000字Prompt批量调用时的成本下降就是实打实的。如果你用的是私有化部署还要盯GPU利用率。最大的浪费是大模型跑在单卡上、并发上不去。可以考虑vLLM这类推理框架做连续批处理continuous batching吞吐量能翻好几倍闲时再降副本数忙时提前扩容。4.4 回归测试机制模型升级为什么经常“改好了A砸了B”我认为这是AI工程里最痛的一个环节。你在开发环境调Prompt感觉“这次效果真不错”上线之后用户却开始骂——因为模型是概率的你的优化可能只对评测集和自测的十几个case有效对线上其他case无效甚至变差。所以模型的每一次改动Prompt调整、RAG参数变化、换模型版本、加数据都要变成一个“评审对象”而不是“直接上线”。我的做法是建立一套轻量回归门禁所有改动先跑一遍离线评测集输出分数和bad case列表和当前线上版本做对比重点看“是否引入了新错误”而不是只看总分涨没涨如果新增错误发生在高风险场景比如客服承诺、法律解释即使总分涨了也暂缓上线线上先以影子模式或小流量灰度发布观察日志和用户反馈再逐步放量。团队里可以约定任何Prompt修改都走同一个评测流程。哪怕只是加了一句“请用简体中文回答”也至少要过一遍关键case。因为模型对微小的措辞变化非常敏感很多“现场觉得没问题”的改动放到真实数据里就翻车。评测、评测、再评测这不是走流程是保命。5. 从零实操中我踩过的坑附规避方法5.1 评测集只有几十条数据优化了半天全是自我感动这是我最先踩的坑。早期做客服问答评测集一共30条某次调完Prompt准确率从70%提到了80%团队欢呼结果上线后用户反馈“跟之前差不多甚至更差”。回头一查那30条里本身就有认知偏差答案全是照着老FAQ写的根本覆盖不了线上新问题的多样性。后来我把评测集扩到300条并按“售前/售后/物流/退款”分片才真正看清系统的能力分布。准确率的满分没有意义分场景的准确率才有意义。如果退款场景只有50%你上线就要有客服团队兜底。评测集不是用来“展示成果”的是用来“照亮盲区”的。5.2 Prompt越加越长效果反而越来越差我有一段时间特别迷信“把约束写全”一个Prompt写了十几条要求含业务规则、输出格式、语气风格、禁止事项……结果模型开始频繁出错甚至输出完全偏离主题。后来复盘才发现约束太多模型分不清优先级尤其是规则之间有隐含冲突时它通常会选择最后几条或者最笼统的理解。现在的做法是把Prompt拆成“必备约束”和“可选风格”两层必备约束控制在6条以内把容易冲突的规则合并或去掉重复项。每次调整Prompt都跑A/B测试而不是“我觉得应该更清楚”。这条经验让我少走了很多弯路。5.3 没有“守卫”就上了Agent成本直接失控我亲眼见过一个团队做Agent数据报表助手本来预计单次任务消耗5000Token结果某个测试用户问了一个模糊问题Agent在“查数据-生成报表-发现不对-再查数据”的死循环里跑了40多轮单次消耗十几万Token而且界面一直没返回最终结果。原因是只写了“如果可以就继续直到完成”没有最大步数限制也没有失败终止条件。从那以后我负责的Agent项目全部强制加护栏最大执行步数8步、单任务Token预算上限、每轮工具调用的输入输出全部记录、超时自动熔断。Agent的护栏不是“安全要求”是“成本控制要求”。5.4 数据泄漏评测集和训练数据混在一起最后这个坑非常隐蔽但危害极大。我们做文档问答时把历史工单数据既用来更新RAG索引又用一部分做评测集。结果调出来的检索参数“看起来效果极好”但上线后遇到真实文档就拉胯。原因就是评测集里包含了检索库可见的数据——模型或检索器“见过”这些内容等于开卷考试。后来我们定了铁规矩评测集必须与训练/索引数据严格隔离评测集里的文档不从业务库里来而是单独人工构造一批“问-答对”。这样的评测结果才能反映系统面对新知识时的真实表现。这也是为什么我前面反复强调“评测先行”——如果你从项目第一天就把评测数据独立出来后续就永远不用纠结“我的高分是不是靠数据泄漏刷出来的”。如果让我给现在的自己一个建议那就是接到任何AI项目第一天第一件事不是选模型也不是写Prompt而是搭一个最简陋的评测集哪怕手写50个问题再画一张“输入—输出—失败场景”的表格。然后接下来的所有调优、选型、上线都拿它当基准。等过了一两个迭代周期你会发现这个简陋的评测集慢慢长成了整个项目最值钱的资产。