当市场部阅读你的评估案例时：跨职能可见性问题

评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。

这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。

解决办法不是把文件锁得更死。解决办法是认识到评估集已经成为一个跨职能的产物，AI 团队低估了它的受众，并在采购部门发现它之前，构建好访问控制和脱敏层。

评估案例实际上包含什么

剥离外壳，一个评估案例是由四样东西粘合在一起的：一个输入、一个预期行为、一个实际行为和一个判定结果。这四个部分中的每一个都是泄露面，当案例被工程圈以外的人阅读时，这些泄露会产生复合效应。

输入几乎总是真实的真实用户消息。即使团队坚称评估集是“合成的”，那些能捕捉到真实回归（regression）的输入往往是直接从生产环境追踪记录中提取的——别扭的措辞、不完整的句子、称呼中的客户姓名、正文中的账号。合成输入对覆盖率很有用；生产输入才是真正决定通过或失败的关键。合成案例无法捕捉到真实案例所能捕捉到的回归，因此随着时间的推移，评估集会趋向于包含真实的生产数据。

预期行为在实践中是由 AI 工程师编写的小型产品规范。它编码了关于功能应该做什么的假设，而这些语言通常没有经过产品或市场的审查。“助理不应承诺具体的交付日期”是一个评估预期，被销售工程师读到后变成了“该产品无法提供交付日期报价”，进而变成了没有人写进产品页面的面向客户的功能限制。

实际行为是模型输出，这意味着它包含模型所说的一切——包括幻觉出的竞争对手名称、虚构的统计数据，以及评估正是为了标记的那些自信且错误的陈述。工程师将其解读为失败案例，视为需要防范的 Bug。而正在寻找素材的市场分析师将其作为截图，其解读则是“模型说了 X”——而缺少了“且评估将其捕获为错误”这一上下文。

判定结果是最容易被误读的元素。评分 3/5 且备注为“未能引用来源”，在工程师看来是可衡量的回归，用以推动 prompt 的更改。而对于准备续约幻灯片的客户成功经理来说，这被解读为“我们承认我们的产品在引用方面有 40% 的时间是失败的”——这与工程师对同一数字的意图有本质区别。

七个未被邀请的读者

AI 团队的评估仓库拥有比其 CODEOWNERS 文件所显示的更多的读者。他们每个人都会提取不同的产物，而每次提取都会产生 AI 团队并未承诺的下游义务。

• 销售工程师抓取案例作为现场演示素材。输入是真实的，模型行为也很有趣，因此这些案例比演示内容团队编写的任何内容都更适合作为演示 prompt。泄露点：潜在客户询问“你从哪里得到这个问题的”，答案是“来自真实客户的评估案例”。
• 市场部门提取失败案例用于内容创作。直觉上，失败案例比成功案例更有吸引力，因为“我们发现并修复了 X”比“X 正常运行”是一个更好的故事。泄露点：尽管团队内部仍在就底层行为进行争论，但失败案例已成为公开素材，且脱离了开发背景。
• 客户成功部门在续约对话中引用通过率和具体案例。评估套件的核心指标泄露到了采购对比中。泄露点：客户开始询问评估方法、评估集的组成以及每个客户的评估表现——而 AI 团队并没有为此构建分享层。
• 法务部门在 IP 和 PII 审查期间阅读评估集。这种阅读是恰当的，但法务部门通常发现得太晚，此时客户标识符已经嵌入到数十个案例中，清理工作成了团队的一种负担。泄露点：在最糟糕的一周，AI 团队突然面临合规债。
• 产品部门将评估集视为 AI 团队不愿分享的规范。评估案例中的预期行为是现有对功能表现最精准的描述，产品部门深知这一点。泄露点：在没有意识到自己正在制定产品政策的情况下，AI 团队随意编写的预期变成了产品决策的依据。
• 采购评估期间的销售工程是最危险的读者。潜在客户的 RFP（招标书）中包含“分享你的评估方法和代表性的测试案例”，销售工程团队中有人会进入代码库，发送他们认为最令人印象深刻的案例。泄露点：评估案例中编码的前瞻性产品计划被发送到了采购洽谈中。
• 竞争交易中的其他 AI 厂商是第二危险的读者。如果你的销售工程师在分享案例，你竞争对手的销售工程师就在阅读它们，而这些案例现在编码了你的竞争定位（“我们针对 Opus 4.6 而非 4.5 进行评估”）以及你对自己弱点的判断。

工程评估集 vs. 可共享评估集

正确的架构并不是对单一评估集实施更严格的访问控制。而是建立两个评估集，并在它们之间构建一个显式的、版本化的流水线。

工程评估集是团队的工作副本：原始的客户追踪数据、内部术语、未脱敏的失败案例、竞品参考、前瞻性的功能名称，以及工程师们留给彼此的杂乱诊断注释。这个集合专为捕捉回归而优化，供 CI、评判器以及团队自身的迭代循环使用。它绝不应离开工程仓库。要像对待生产数据库转储一样对待它——内部有用，外部危险。

可共享评估集是一个经过筛选、脱敏、叙事清晰的子集，适用于非工程部门使用。这是一个较小的集合——大约是工程评估集的 10–20%——其选择标准是代表性而非覆盖率。客户标识符被剥离，内部功能代号被替换为面向公众的名称，竞争对手的引用被删除，失败案例则配有“系统是如何处理它的”背景说明，使案例读起来像是一个关于质量的故事，而非一个弱点。这个集合是销售、营销、客户成功和采购部门看到的。

这种拆分看起来成本很高，直到你意识到你已经在为此买单了——只是支付方式不均匀，通常发生在采购团队要求查看案例，而有人不得不手忙脚乱地手动脱敏一百个案例的那一周。可共享评估集将这种忙乱转变为一种持续维护的产物。工程评估集保持原始状态，因为使用它的人（工程师、CI、评判器）需要它的原始状态。

在两个集合之间运行着一条脱敏流水线。这条流水线主要是机械化的：用于识别已知客户标识符模式的正则表达式，用于识别人名和账号的命名实体识别，内部代号和未发布功能标志的黑名单，以及捕捉提及竞争对手名称和模型版本的竞品参考清理。现代 PII 脱敏工具已经足够出色，流水线处理每个案例仅需几秒钟；瓶颈不在于脱敏，而在于首先决定哪些案例有资格进入可共享评估集。

请求与审批工作流

即使有了可共享评估集，你仍会收到针对工程评估集资料的请求。销售团队有一个订单，潜在客户想看“你们进行回归测试的实际客户案例”。营销团队想要一个发生在知名客户身上的特定失败案例，因为这比筛选过的案例更有故事性。客户成功团队希望为续约演示稿提供按客户细分的通过率。

这些请求不能仅靠访问控制来处理，因为请求者通常有合理的需求，评估集也有合理的答案——问题在于叙事框架。AI 团队需要成为框架的所有者，而不是访问控制的瓶颈。

行之有效的工作流是一个轻量级的工单：请求者说明受众、使用场景和期望的框架；AI 团队选择案例（或编写一个具有代表性的案例），草拟围绕它的叙事，然后通过可共享评估集发布结果，或者附带书面理由将请求标记为不符合政策。这听起来很重，但在实践中，大多数团队每季度的工单量仅为 5–10 个，而 没有 这个工作流的代价是评估案例泄露，最终出现在客户的采购洽谈中。

该工作流还创建了审计线索。如果一个评估案例出现在面向客户的产物中，AI 团队可以追溯是哪个工单授权的、应用了什么级别的脱敏，以及批准了哪种叙事框架。如果没有这个工作流，AI 团队只能在 Twitter 上发现泄露。

版本化与新鲜度

评估案例会过时。一个在第一季度标记模型行为的案例，描述的可能是后来已修复的行为、已更改的行为或已上线的行为。销售工程师提取六个月前的案例，是在向潜在客户展示两个迁移版本前的模型快照，他们对当前模型质量的推论是错误的。

可共享评估集需要明确的版本控制：日期、模型版本、提示词版本和脱敏级别。当案例在外部共享时，它会携带这些元数据字段，使产物的新鲜度对使用者而言清晰可见。这在两个方向上保护了团队——旧的“我们在 X 方面失败”的案例不会困扰当前的产品叙事，旧的“我们在 Y 方面通过”的案例也不会在底层行为发生漂移后被引用为当前证据。

版本锚定惯例还允许团队在底层行为改变时退役可共享案例，而不是让 2024 年的演示稿引用一个模型今天无法重现的案例。

架构上的认知

评估集是一种跨职能产物，AI 团队低估了它的受众。通过评估门槛的案例文件，在被下一位工程师阅读之前，会被销售、营销、客户成功、法律和产品部门阅读。如果不构建访问和脱敏层的团队，将以惨痛的方式发现这些读者——在采购会议、竞争对手的幻灯片或客户的合规审查中。

解决方法是建立两个产物，并在它们之间建立显式的流水线，为异常情况建立请求工作流，并建立保持可共享产物清晰易读的版本控制惯例。成本适中。而不这样做的代价则体现在与客户的信任校准、销售团队突如其来的公关工作，以及缓慢滴漏的泄露中——在泄露对除了认出自己投诉的客户以外的任何人都失去吸引力很久之后，AI 团队仍会不断发现这些泄露。

像对待任何受众比作者预期更广的共享产物一样对待评估集：拥有发布的版本、声明的受众，以及由专人负责的脱敏层。按节奏发布可共享评估集（版本化、注明日期的、框架明确的）的团队可以掌控其 AI 功能的叙事。不这么做的团队，则只能在续约前一周，在客户的采购洽谈中，阅读其销售工程师东拼西凑出来的叙事。