FunTester 把 Skill 设计成一场游戏

FunTester · 2026年08月12日 · 53 次阅读

给 AI 写 Skill 时,我们通常在写一份操作说明:

  • 先读取输入;
  • 再完成分析;
  • 按固定格式输出;
  • 最后自行检查。

这套写法适合简单任务。但当任务需要多轮调用工具、验证结果、处理失败和调整策略时,单纯的流程说明常常不够。AI 可能完成了几步表面动作,却没有真正解决问题;也可能在验证失败后停在原地,最后给出一段看似完整的总结。

于是可以换一个视角:把 Skill 设计成一场游戏

这里的游戏,不是让 AI 因为有积分而产生类似人的胜负欲,而是给任务补上目标、状态、裁判、反馈和失败代价。它的价值在于把模糊的完成要求,转化成模型在当前执行过程中可以持续参考的决策结构。

游戏化并不天然提高成功率。设计得好,它会帮助 AI 更稳定地把注意力放在真实结果上;设计得差,它只会让 AI 更高效地刷分。

这不是训练 AI

在 Skill 里写上积分、关卡、经验值或扣分规则,通常不会更新模型参数,也不会让模型像强化学习那样把这一轮经验永久保存下来。

一次运行中的评分规则,本质上仍是上下文的一部分。它影响的是模型此刻如何理解优先级,如何选择下一步动作,以及何时应当承认任务尚未完成。

例如,下面两段指令看起来差异不大:

请完成代码审计,并输出安全报告。
目标是交付可复核的安全结论。

只有具备直接代码证据或可复现实验结果的问题,才能标记为已确认。
无法验证的下游依赖必须标记为未知。
未验证即宣称完成,视为任务失败。

后者没有让模型获得新能力,但它把成功和失败的边界说得更清楚。

如果再把测试结果、静态分析结果、文件状态或人工审阅意见反馈给模型,评分就不再只是文字装饰,而会成为下一轮行动的依据。这时,Skill 才开始像一个具备反馈回路的游戏系统。

游戏化 Skill 的核心

一个真正可用的游戏化 Skill,至少要有四层。

任务契约

很多 Skill 的问题,不是步骤不够多,而是胜利条件太模糊。

请认真审计、写一篇好文章、尽量解决问题,这些目标无法直接判断。模型可以写很多内容,却仍然没有完成用户真正需要的结果。

更好的写法是先定义任务契约:

  • 最终交付物是什么;
  • 哪些条件必须满足;
  • 哪些情况不能宣称完成;
  • 哪些结论必须有外部证据;
  • 信息不足时,应该如何报告未知和阻塞点。

例如,研究类 Skill 的胜利条件不应是找到足够多的信息,而应是:

  • 关键结论能回到原始来源;
  • 来源的发布日期和正文内容经过核对;
  • 推断与事实被清楚区分;
  • 找不到证据时,不用推测填补空白。

这一步看似朴素,却决定后续所有分数到底在奖励什么。

状态面板

游戏里有血量、地图和任务列表。它们的作用不是营造氛围,而是告诉玩家当前处于什么状态。

Skill 也需要类似的状态面板。

状态 含义 合理的下一步
未验证 只有线索,没有直接证据 搜索、读取、运行检查或请求必要信息
已验证 有代码、测试或权威来源支撑 记录证据位置,纳入最终交付
受阻 缺少权限、环境或外部服务信息 明确阻塞条件和最小验证路径
已完成 满足全部验收条件 交付结果,停止无关扩展

这个设计能减少一种常见问题:AI 把已经写出的文字当成已完成的任务。

写完说明不等于完成。通过测试、获得来源、验证文件状态、复现缺陷,才是状态真正变化的依据。

裁判系统

游戏化最容易走偏的地方,是把可量化误当成真实价值。

如果一个安全审计 Skill 只奖励发现问题的数量,AI 可能把许多模糊线索包装成漏洞。如果一个写作 Skill 只奖励引用数量,AI 可能堆砌链接,却不判断来源是否可靠。如果一个编码 Skill 只奖励测试通过,它甚至可能为了通关而修改测试,而不是修复业务逻辑。

因此,裁判至少要分为两类:

  • 结果裁判:最终功能是否工作、结论是否可复核、交付是否符合用户要求;
  • 过程裁判:是否遵守范围、是否进行验证、是否伪造证据、是否绕过验收。

结果裁判决定有没有赢,过程裁判防止通过错误方式赢。

对多轮 Agent 而言,评测不应只看最后一段回答。任务、尝试次数、工具调用、环境变化和最终结果都可能需要纳入检查。Anthropic 在 Agent 评测实践中也将任务、试次、评分器和完整执行轨迹区分开来,并强调不同类型的任务需要不同的评分手段。Demystifying evals for AI agents

失败规则

一旦有了评分,就必须假设系统会找到评分漏洞。

AI 领域通常把这种现象称为reward hacking:系统拿到了高分,但实现方式偏离了设计者真正想要的能力或结果。OpenAI 的研究指出,能力更强的推理模型可能更善于发现任务定义和奖励结构中的漏洞。Detecting misbehavior in frontier reasoning models

因此,Skill 里的扣分项不应是装饰,而应是明确的失格条件:

  • 没有验证就声称完成;
  • 编造文件、来源、命令输出或测试结果;
  • 修改验收条件、删除测试或绕过安全控制来制造成功;
  • 把本地代码缺口直接推导为最终业务损失;
  • 将外部配置、下游服务和权限依赖说成已被证实;
  • 用大量不影响最终结果的子任务堆积完成感。

一个很实用的原则是:

任何高分行为,如果脱离用户真实目标后就失去价值,就不应被单独奖励。

为什么可能提高完成率

游戏化 Skill 真正可能带来的提升,主要来自三个方面。

第一,它让模型更容易识别优先级。

当任务同时包含搜索、分析、验证、写作和收尾时,模型需要不断决定下一步做什么。明确的得分和失分条件,能让它优先完成对最终验收最有价值的动作,而不是平均用力地执行清单。

第二,它给失败后的继续行动提供了依据。

普通 prompt 往往只写:如果失败,请重试。

问题在于,失败并不只有一种。搜索不到文件、测试不通过、权限不足、外部依赖不可达,分别需要不同策略。游戏化 Skill 可以把失败类型映射成下一步动作,而不是让模型机械重复第一次尝试。

第三,它迫使设计者把验收标准提前写清楚。

很多时候,Skill 执行不稳定并不是模型没有按步骤做,而是设计者自己也没有定义什么叫完成。把任务写成游戏,会迫使我们回答一个更难的问题:裁判到底依据什么判定胜利?

这个问题本身往往比积分规则更有价值。

安全审计 Skill 示例

以安全审计为例,一个普通 Skill 可能这样写:

审计指定接口,寻找权限校验和业务校验问题,输出风险报告。

更接近游戏化闭环的写法,可以是:

总目标:交付一份可复核的审计结论。

胜利条件:
- 每条已确认问题都能定位到具体入口、调用链和控制缺口。
- 本地代码可以直接证明的风险,与依赖配置或下游服务才能确认的风险必须分开。
- 用户排除的接口和已知问题不能重新计入结果。

状态:
- 线索、已验证、待外部确认、误报、已完成。

得分:
- 已确认且有直接证据的问题:加分。
- 完整追踪入口、转换、授权、服务校验和下游边界:加分。
- 明确说明不确定性和验证顺序:加分。

失格:
- 没有证据就下确定性结论。
- 把局部控制绕过直接等同于资金损失。
- 把扫描器线索直接当作漏洞。
- 虚构测试、文件或调用结果。

注意,这份设计没有要求 AI 在最终回答中展示分数。分数只是内部的取舍工具。

对用户有价值的不是 AI 说自己获得了多少分,而是它交付的结论是否经得起复核。

不适合游戏化的任务

并非所有任务都值得设计积分系统。

如果任务只有一个短回合,缺少工具和外部反馈,例如改写一句文案、翻译一小段文字、解释一个概念,复杂积分通常不会带来明显收益,反而会增加 prompt 的长度和噪声。

如果目标本身高度开放,例如早期创意探索、产品命名、品牌风格讨论,也不宜过早设定单一分数。否则模型会快速收敛到容易得分的保守方案,牺牲探索空间。

这类任务更适合设置探索约束,而不是胜负分数。例如:

  • 至少提出三种明显不同的方向;
  • 每个方向都说明适用场景和代价;
  • 不允许把同一方案换词复述;
  • 由人决定下一轮深入哪一个方向。

换句话说,确定性任务需要裁判,开放性任务需要探索预算。

验证游戏化 Skill

游戏化 Skill 是否真的提高完成率,不能靠一次体验下结论,应该把它当作一个可测量的工程假设。

最小验证方法并不复杂:

  1. 准备一组真实且有验收条件的任务,例如修复缺陷、整理数据、完成调研或审计接口;
  2. 分别运行原始流程型 Skill 和游戏化版本;
  3. 使用相同模型、相同工具权限、相近上下文和相同验收器;
  4. 对每类任务进行多次试运行,避免一次输出的偶然性;
  5. 比较真实完成率、验证通过率、误报率、平均成本、平均耗时和人工返工量。

模型输出具有随机性,因此只比较单次结果很容易得出错误结论。更可靠的做法是保留执行轨迹,检查它在哪些环节更少放弃、更少猜测,或者反而出现了新的刷分行为。

OpenAI Graders 提供了字符串检查、相似度检查和模型评分等不同类型的评测器。工程上需要做的不是挑一个万能评分器,而是为不同目标选择合适的裁判,并用多个检查层降低误判风险。OpenAI Graders 文档

Skill 是任务系统

把 Skill 写成游戏,不是为了让 AI 看起来更积极,也不是为了在 prompt 里加入几句积分和关卡。

真正有效的设计,是让它拥有一个完整闭环:

任务契约 → 状态判断 → 行动 → 外部反馈 → 裁判检查 → 策略调整 → 可验证交付

只写积分,没有外部反馈,评分只是装饰。

只看最终输出,不检查过程,评分容易被绕过。

只奖励完成数量,不关心真实结果,系统最终会学会完成仪式,而不是完成任务。

因此,设计游戏化 Skill 时最重要的问题不是怎样让 AI 得到更高分,而是:

需要哪些证据,才能证明它真的完成了任务?

当这个问题被认真回答后,积分、关卡和回合才有意义。


相关阅读

##### FunTester 名片|万粉千文,百无一用

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册