最近读 OpenAI Cookbook 里关于 evaluation flywheel 的文章，我最大的感受是：AI 应用从 Demo 走向生产，关键不是把 prompt 写得更长，而是把效果变成可以观测、可以衡量、可以持续迭代的系统。这篇文章讨论的是 resilient prompt，也就是「有韧性的提示词」。但它真正有价值的地方，不是教你写某个万能提示词，而是给出了一套 AI 应用质量迭代的方法：先分析失败，再量化失败，最后针对性改进。换成业务落地语言，就是：AI 项目的第一步，不是追求一个「看起来很聪明」的回答，而是先定义什么叫正确、什么叫错误、什么错误不能上线。

一、AI 项目真正的考验，不在 Demo，而在生产环境

做 AI 应用时，我们经常会遇到一种情况：Demo 阶段效果很好，给几个样例，模型回答得很漂亮，业务方也觉得「这个可以」。

但一到真实场景，问题就开始出现。

用户换一种问法，模型理解偏了；输入材料稍微复杂一点，回答格式乱了；遇到边界情况，模型给出一个看似合理但实际错误的建议；业务方问「这个结果为什么可信」，系统又给不出依据。

这时候很多人的第一反应是：是不是 prompt 写得不够好？是不是模型还不够强？是不是应该再多加几句限制？

这些当然可能有用。但 OpenAI 这篇 Cookbook 提醒我们，问题的核心不只是 prompt 本身，而是我们缺少一套系统化的方法，去分析它为什么错、错在哪里、错得有多严重，以及改完以后是不是真的变好了。

换句话说，AI 项目不能只靠「看起来不错」。如果要上线，就必须从主观感受，走向可评估、可衡量、可迭代。

二、什么是「有韧性」的 AI 输出？

OpenAI 在文章里提到一个概念：resilient prompt。

直译过来是「有韧性的提示词」。用更业务化的话说，它不是只在少数理想样例上表现好，而是在真实用户的各种输入、表达方式和边界情况下，依然能稳定输出高质量结果。

这点非常重要。

很多 prompt 在演示时表现很好，是因为我们给它的输入本身就很友好：问题清楚、材料完整、场景简单、没有歧义。但真实业务不会这么理想。

比如做合同审核，用户可能上传一份格式不规范的合同；做制度问答，用户可能问得很模糊；做信披文件审核，模型不仅要看文本，还要理解规则、引用依据、判断风险等级。

如果 prompt 只在「顺风局」里表现好，它就不算真正可靠。真正能上线的 AI 应用，必须经过真实样本和错误样本的检验。

三、评估飞轮：让 AI 应用持续进化的闭环

OpenAI 给出的思路，可以概括成三个步骤：分析、衡量、改进。

第一步是 Analyze，分析失败。先不要急着改 prompt，而是人工看一批模型输出，尤其是失败案例和低质量案例，弄清楚模型到底错在哪里。

第二步是 Measure，衡量失败。当你知道主要错误类型后，就要把这些错误变成可以统计的指标。比如格式错误占多少，事实错误占多少，业务规则理解错误占多少。

第三步是 Improve，针对性改进。基于前面的分析和指标，再去改 prompt、补示例、调整知识库、增加业务规则，或者优化整个系统流程。

这个过程不是一次性的，而是一个循环。每改一次，就重新评估一次；每上线一段时间，就继续从真实数据里发现新的问题。

这就是评估飞轮的价值：它把「我觉得变好了」变成「我们有数据证明它在哪些问题上变好了」。

四、评估系统的起点：人工看错例

很多人一听到评估，就会想到自动化指标。但 OpenAI 这篇文章反而强调，最开始要做人工分析。

原因很简单：如果你还不知道模型为什么错，就很难设计出有效的自动评估。

文章里提到两个方法：open coding 和 axial coding。

open coding 可以理解为「开放式贴标签」。先人工看一批失败案例，不要急着建立完美分类，而是看到什么问题就先记下来。比如：「没有引用依据」「回答格式不对」「推荐了不可用的时间」「重排预约时没有取消原预约」。

axial coding 则是把这些零散标签归类。比如把「没有引用依据」「引用位置错误」归为依据问题；把「格式不对」「字段缺失」归为输出格式问题；把「风险类型判断错」「规则理解错」归为业务判断问题。

这一步看起来不够自动化，但它非常关键。因为只有先把错误看清楚，后面才知道应该评估什么、优化什么。

五、落到业务场景：从 prompt 到评估基线

假设我们要做一个「信披文件智能审核」场景，很多人会从 prompt 开始：

请你帮我审核这份信息披露文件，指出其中的风险，并给出修改建议。

这个 prompt 可以作为 Demo 起点，但它远远不够支撑上线。

真正进入实施阶段，我们至少要继续问几个问题：

如果这些问题没有定义清楚，业务方说「这个 AI 不准」时，我们其实不知道该怎么改。是 prompt 问题？知识库问题？业务规则问题？还是评估标准本身没说清楚？

所以，一个更合理的落地流程应该是：

这时，prompt 优化才有方向。

六、一个可复用的 AI 场景评估表

如果你正在做一个 AI 场景落地项目，可以先用下面这张表梳理，而不是一上来就写 prompt。

这张表的价值在于，它把「模型准不准」拆成了更具体的问题。

一旦问题变具体，AI 项目就不再只是调 prompt，而是进入了真正的工程化实施。

七、我对这篇 Cookbook 的理解

OpenAI 这篇文章表面上是在讲 prompt resilience，但我觉得它真正讲的是 AI 项目如何从 Demo 走向生产。

Demo 阶段，我们很容易被几个漂亮回答打动。但生产环境关注的不是某一次回答有多惊艳，而是系统在大量真实输入下是否稳定、是否可解释、是否可复核、是否能持续改进。

所以，AI 场景落地里最重要的能力，不只是会不会写 prompt，而是能不能建立一套评估闭环。

没有评估，prompt 优化就像凭感觉改文案；有了评估，prompt 优化才变成工程问题。

结尾

如果用一句话总结这篇 OpenAI Cookbook，我会这样说：

AI 项目的第一步，不是写一个更长的 prompt，而是定义什么叫成功。

当我们能说清楚什么叫正确、什么叫错误、什么错误不可接受、什么指标达到才能上线，后面的 prompt、知识库、模型选择和流程设计，才会有真正的优化方向。

这也是我接下来学习 OpenAI 和 Anthropic 官方资料时最想持续关注的方向：不是只看工具怎么用，而是看这些能力如何变成真实业务里的可落地方案。

—— end ——

最后记得⭐️我噢，如果觉得文章还不错的话可以点赞转发推荐评论～