过去一年，很多 AI 产品团队都有过类似经历。刚开始做 AI 功能时，大家最关心的是 Prompt，一个提示词改得好不好，往往直接决定 demo 是否惊艳、回答是否顺滑、效果是否像一个真正可用的产品功能。
于是团队会花大量时间调 Prompt：这个词要不要更明确，角色设定是不是不够强，输出格式要不要约束得更死，要不要加几个 few-shot 示例，系统提示词是不是应该更长一点。这些努力当然有价值，很多 AI 产品早期能跑起来，靠的就是 Prompt 工程带来的快速试错能力。
但随着产品真正进入线上环境，一个问题会越来越明显：Prompt 已经不够了。不是说 Prompt 不重要，而是它无法独自承担 AI 产品的质量责任。
Prompt 解决的是如何让模型这一次答得更好，AI 产品真正需要解决的是如何证明系统在大量真实场景下持续变好。这两个问题之间，隔着一整套 评测工程化能力。
Prompt 不够用
Prompt 最大的价值，是让团队可以快速探索模型能力。一个好的 Prompt，确实能显著改善输出质量，让模型更守格式、更贴近业务语境、更少废话，也更像一个具体场景里的产品功能。所以在 AI 产品早期，Prompt 是非常有效的工具。
问题在于，Prompt 很容易给团队一种错觉：只要继续调 Prompt，产品质量就会持续变好。但真实情况往往不是这样。
很多时候，一个 Prompt 修改之后，团队会拿几个熟悉的 case 试一下。如果这几个 case 表现更好了，大家就会觉得这版 Prompt 优化成功了。可问题是，这几个 case 变好了，不代表整体质量变好了。常见问题减少了，不代表长尾问题没有增加；回答更详细了，不代表事实更准确了；格式更稳定了，不代表用户体验更好了；模型更聪明了，不代表产品更可靠了。
AI 产品最麻烦的地方在于，它的输出不是简单的确定性逻辑。你改了一句话，可能会影响模型在很多场景下的行为。有些影响是正向的，有些影响是负向的，更多时候，影响是你一开始看不见的。
这就是为什么只靠 Prompt 调参，很快会进入瓶颈。它能帮你优化局部体验，却很难回答一个更关键的问题：这次改动到底让产品整体变好了，还是只是让手里的几个样例变好了。
如果团队回答不了这个问题，AI 产品迭代就会变成一种经验驱动的试运气。看起来一直在优化，实际上没有人知道质量曲线到底往上走，还是在原地震荡。
所以，Prompt 的问题不是没用，而是它只能承担探索阶段的工作。当产品进入稳定交付阶段，真正重要的就不再只是怎么写 Prompt，而是 怎么验证 Prompt、模型、数据和工具链改动之后，系统整体是否仍然可靠。
质量不可见
传统软件的质量问题，通常比较容易定义。一个按钮点不动，就是 bug；一个接口返回错了，就是 bug；一个字段计算不对，就是 bug；一个流程走不通，也是 bug。虽然传统软件也很复杂，但它至少有一个前提：大多数情况下，输入、逻辑和输出之间的关系是确定的。
AI 产品不一样。AI 产品的质量问题，很多时候不是明显坏了，而是看起来还行。用户问了一个业务问题，模型给出了一段流畅回答，语气自然、结构完整，看起来很专业，但里面某个关键事实是错的。或者模型正确回答了主问题，却遗漏了一个重要限制条件，如果用户不了解背景，可能根本意识不到它漏了东西。
再比如，同一个任务换一种问法，模型表现就明显下降；同一个 Prompt 换一个模型版本，原本稳定的格式突然变差；同一个 RAG 系统更新知识库之后，检索命中率提升了，但回答开始变得冗长、保守，甚至自相矛盾。
这些问题都不是简单的功能能不能跑。它们更像是 行为质量问题：模型有没有理解任务，回答是否准确，信息是否完整，格式是否可控，引用是否可靠，工具调用是否正确，安全边界是否稳定，在真实用户表达下是否仍然有效。
这类问题有一个共同特点：单靠肉眼试几个样例，很难判断整体质量。这就是 AI 产品真正难的地方。
它不是没有质量问题，恰恰相反，它到处都有质量问题。只是很多质量问题被自然语言的流畅性遮住了。大模型很擅长生成看起来正确的内容，这会让 AI 产品出现一种特殊风险：产品已经失败了，但失败方式并不显眼。
传统软件失败时，用户可能看到报错；AI 产品失败时，用户看到的可能是一段很自信、很完整、很像答案的错误内容。这也是为什么 AI 产品不能只做功能测试。
你不能只验证系统能不能返回结果、接口有没有成功、页面有没有展示、流程有没有结束。你还必须验证返回的结果到底好不好，在什么场景下好，在什么场景下坏，这次更新之后哪些能力提升了，哪些能力退化了，退化是否可以接受，能不能在上线前发现。
换句话说，AI 产品的核心质量挑战，是质量不可见。而评测工程化的第一件事，就是让质量变得可见。
从感觉到验证
很多团队在 AI 产品早期，评估效果靠的是感觉。PM 试几个问题，工程师跑几个样例，老板看一次 demo，用户反馈几条 bad case，然后大家凭经验判断这版是不是更好。这种方式在探索阶段可以接受，因为那个阶段目标是快速找到方向。
但一旦产品开始承载真实业务，这种方式就不够了。感觉不可重复，今天试的 case 和明天试的 case 不一样，判断结果就会变；感觉不可比较，A 版本和 B 版本到底谁更好，很容易陷入争论；感觉不可追溯，这次改动影响了哪些能力，团队很难系统复盘；感觉也不可规模化，当场景变多、用户变多、模型链路变复杂，靠几个人手动试用根本覆盖不过来。
所以，AI 产品要想持续迭代，必须从感觉判断转向 可重复验证。所谓评测工程化，本质上就是建立这样一个机制：每一次改动之后，团队都能用相对稳定的方法，判断系统整体质量有没有变好。
这套机制至少包含四个要素。
数据集
没有数据集，就没有稳定的评测对象。AI 产品需要沉淀一批代表真实场景的样本，包括核心用户问题、高频业务任务、历史失败案例、边界输入、复杂表达、安全风险样本和高价值业务场景。
这些样本不是随便找几个问题放在那里。它们应该代表产品真正要解决的问题：AI 客服产品要有真实用户咨询样本，AI 数据分析产品要有真实业务问题和对应数据表，AI 编程助手要有真实代码任务和测试用例，企业知识库助手要有真实员工查询和权威答案来源。
数据集的价值在于，它把抽象的产品质量落到了具体样本上。从此以后，团队讨论的不再是我感觉这版好一点，而是这版在核心场景集上提升了多少，在历史失败集上是否复发，在边界样本上有没有退化。
这是 AI 产品质量管理的地基。
基准
有了数据集，还需要判断标准。否则同一个回答，有人觉得好，有人觉得不好；同一个模型版本，有人认为更专业，有人认为更啰嗦；同一次改动，有人看到准确率提升，有人看到体验下降。
所以团队需要定义基准：什么叫回答正确，什么叫任务完成，什么叫引用可靠，什么叫格式合格，什么叫安全拒答正确，什么叫用户体验可接受。不同产品的基准不一样，客服产品可能关注解决率、误导率、转人工率；搜索问答产品可能关注事实准确性、引用相关性、覆盖完整性；Agent 产品可能关注任务完成率、工具调用成功率、步骤成本；内容生成产品可能关注风格一致性、结构完整性、可编辑性；代码生成产品可能关注测试通过率、编译成功率、代码安全性。
好的基准不是为了得到一个漂亮分数，而是为了让团队知道：每一次改动到底带来了什么收益，又付出了什么代价。
回归
AI 产品最常见的问题是修好 A，弄坏 B。Prompt 更严格了，幻觉减少了，但拒答变多了；模型升级了，推理更强了，但格式遵循变差了；检索优化了，召回更多了，但回答变得更长、更散；Agent 步骤减少了，速度变快了，但任务完成率下降了；安全策略加强了，风险降低了，但正常请求也被误伤了。
如果没有回归测试，这些问题往往要上线后才会暴露。评测工程化要求团队把历史问题沉淀下来，每次出现 bad case，不只是临时修掉，而是把它加入评测集。
这样下一次改 Prompt、换模型、更新知识库、调整工具链时，系统能自动检查：这个问题有没有复发，老能力有没有退化，关键路径还能不能跑通，护栏指标有没有被破坏。
回归的意义不是追求永远不出错，而是让团队不要反复掉进同一个坑。
自动评测
如果每次改动都要人工完整评审，评测体系很快会变成瓶颈。所以评测必须逐步自动化。有些问题可以用规则判断，比如 JSON 是否合法、字段是否完整、长度是否超限、是否包含引用、格式是否符合要求。
有些问题可以用程序判断，比如代码能不能运行、SQL 能不能执行、计算结果是否正确、工具参数是否合法、API 调用是否成功。还有些问题可以用模型辅助判断，比如回答是否相关、信息是否完整、是否遵守语气、是否存在明显幻觉、是否符合评分标准。当然，高风险、高主观的问题仍然需要人工抽检。
自动评测不是为了完全替代人，它的价值是把大量重复判断自动化，让人从逐条打分转向定义标准、校准样本、分析失败原因。
当数据集、基准、回归和自动评测连在一起，AI 产品才真正具备持续迭代能力。团队每一次改动都不再只是试试看，而是可以进入一个更稳定的循环：修改系统、运行评测、比较结果、定位退化、修复问题、沉淀样本、再发布。
这就是评测工程化。
最终是工程问题
很多团队一开始会低估评测工程化的重要性，原因很简单：早期 AI 产品看起来没那么复杂。一个模型、一个 Prompt、几个示例、一个简单界面，最多再加一点 RAG，这种阶段确实可以靠少数人的经验推进。大家一起试一试，觉得效果不错，就可以继续往前走。
但只要产品开始进入真实场景，复杂度会迅速上升。用户输入会变复杂，业务场景会变多，知识库会持续更新，模型版本会不断变化，Prompt 会被频繁调整，RAG 策略会迭代，工具调用会增加，权限和安全边界会变复杂，成本、延迟、稳定性都要一起考虑。
这个时候，AI 产品已经不再是一个 Prompt 调一个模型。它变成了一个 复杂系统，而复杂系统不能靠手工感觉来管理质量。
这和传统软件的发展路径很像。早期软件项目，也可以靠开发者自己点点页面、跑几个流程；但当系统变复杂、团队变大、发布频率变高，软件工程最终一定会走向测试自动化、持续集成、持续交付。不是因为团队喜欢流程，而是因为复杂系统如果没有工程化质量保障，就无法稳定迭代。
AI 产品也是一样。AI 产品需要自己的 Eval Pipeline：每次 Prompt 改动，要评测；每次模型升级，要评测；每次知识库更新，要评测；每次工具链调整，要评测；每次安全策略变化，也要评测。否则上线就会变成赌博。
更关键的是，AI 产品的质量变量比传统软件更多。传统软件主要验证代码逻辑，AI 产品还要验证模型行为、语义理解、生成质量、上下文处理、检索质量、工具调用、安全边界和用户体验。这些东西无法只靠单元测试覆盖，它们需要一套新的质量体系。
这也是为什么评测工程化最终会成为 AI 产品团队的基础设施。它不是高级团队才需要的锦上添花，而是 AI 产品从 demo 走向生产环境之后，必然要补上的能力。
没有评测工程化，团队会陷入一种低效循环：线上发现问题，临时改 Prompt，修好一个 case，上线后又坏另一个 case，继续人工排查，继续临时修补。看似一直在迭代，实际上是在重复救火。
有了评测工程化，团队才能进入另一种循环：发现问题，沉淀样本，明确标准，系统验证，防止复发，持续优化。前者是经验驱动，后者是 工程驱动。
这就是 AI 产品成熟度的分界线。
分水岭是 Eval 系统
未来，Prompt 当然仍然重要。好的 Prompt 仍然能提升模型表现，好的上下文设计仍然能改善用户体验，好的任务拆解仍然能降低模型出错概率。
但 Prompt 本身很难成为长期护城河。因为 Prompt 会越来越容易被复制，模型能力会越来越接近，通用技巧会越来越普及，很多今天看起来高级的 Prompt 方法，明天可能就会变成默认能力。
真正难复制的是另一类东西：真实业务场景里积累下来的评测数据，团队对质量标准的定义，历史失败案例的沉淀，线上反馈到离线评测集的闭环，模型升级前后的系统比较能力，持续发现退化、定位问题、稳定发布的工程体系。
这些东西不会因为换一个模型就自动获得，也不会因为多写几个 Prompt 就自然出现。它们需要团队在真实产品迭代中一点点建设。
这也是为什么 AI 产品竞争到最后，分水岭不会只是 谁更会写 Prompt。更关键的问题会变成：谁更知道自己的产品在哪些场景下有效，谁更快发现系统在哪些地方退化，谁更能判断一次改动到底值不值得上线，谁更能把线上失败转化成下一轮质量资产，谁更能稳定地利用新模型，而不是被新模型的不确定性反复拖累。
AI 产品的长期竞争力，不是来自一次漂亮的 demo，而是来自持续、稳定、可验证的质量提升。所以，Prompt 工程不会消失，但它会被放进更大的体系里，这个体系就是评测工程化。
Prompt 解决的是局部优化，评测工程化解决的是持续进化。Prompt 让模型在某些样例上表现更好，评测工程化让团队知道产品是否真的变好。
当 AI 产品越来越深入真实业务，真正重要的能力会从调出一个好结果，转向 证明系统持续产生好结果。
这就是为什么 AI 产品最终都会走向评测工程化。因为没有它，AI 产品只能靠感觉迭代；有了它，AI 产品才开始拥有真正的工程确定性。