给 AI 写 Skill 时，我们通常在写一份操作说明：
这套写法适合简单任务。但当任务需要多轮调用工具、验证结果、处理失败和调整策略时，单纯的流程说明常常不够。AI 可能完成了几步表面动作，却没有真正解决问题；也可能在验证失败后停在原地，最后给出一段看似完整的总结。
于是可以换一个视角：把 Skill 设计成一场游戏。
这里的游戏，不是让 AI 因为有积分而产生类似人的胜负欲，而是给任务补上目标、状态、裁判、反馈和失败代价。它的价值在于把模糊的完成要求，转化成模型在当前执行过程中可以持续参考的决策结构。
游戏化并不天然提高成功率。设计得好，它会帮助 AI 更稳定地把注意力放在真实结果上；设计得差，它只会让 AI 更高效地刷分。
在 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 可能这样写：
审计指定接口，寻找权限校验和业务校验问题，输出风险报告。
更接近游戏化闭环的写法，可以是：
总目标：交付一份可复核的审计结论。
胜利条件：
- 每条已确认问题都能定位到具体入口、调用链和控制缺口。
- 本地代码可以直接证明的风险，与依赖配置或下游服务才能确认的风险必须分开。
- 用户排除的接口和已知问题不能重新计入结果。
状态：
- 线索、已验证、待外部确认、误报、已完成。
得分：
- 已确认且有直接证据的问题：加分。
- 完整追踪入口、转换、授权、服务校验和下游边界：加分。
- 明确说明不确定性和验证顺序：加分。
失格：
- 没有证据就下确定性结论。
- 把局部控制绕过直接等同于资金损失。
- 把扫描器线索直接当作漏洞。
- 虚构测试、文件或调用结果。
注意，这份设计没有要求 AI 在最终回答中展示分数。分数只是内部的取舍工具。
对用户有价值的不是 AI 说自己获得了多少分，而是它交付的结论是否经得起复核。
并非所有任务都值得设计积分系统。
如果任务只有一个短回合，缺少工具和外部反馈，例如改写一句文案、翻译一小段文字、解释一个概念，复杂积分通常不会带来明显收益，反而会增加 prompt 的长度和噪声。
如果目标本身高度开放，例如早期创意探索、产品命名、品牌风格讨论，也不宜过早设定单一分数。否则模型会快速收敛到容易得分的保守方案，牺牲探索空间。
这类任务更适合设置探索约束，而不是胜负分数。例如：
换句话说，确定性任务需要裁判，开放性任务需要探索预算。
游戏化 Skill 是否真的提高完成率，不能靠一次体验下结论，应该把它当作一个可测量的工程假设。
最小验证方法并不复杂：
模型输出具有随机性，因此只比较单次结果很容易得出错误结论。更可靠的做法是保留执行轨迹，检查它在哪些环节更少放弃、更少猜测，或者反而出现了新的刷分行为。
OpenAI Graders 提供了字符串检查、相似度检查和模型评分等不同类型的评测器。工程上需要做的不是挑一个万能评分器，而是为不同目标选择合适的裁判，并用多个检查层降低误判风险。OpenAI Graders 文档
把 Skill 写成游戏，不是为了让 AI 看起来更积极，也不是为了在 prompt 里加入几句积分和关卡。
真正有效的设计，是让它拥有一个完整闭环：
任务契约 → 状态判断 → 行动 → 外部反馈 → 裁判检查 → 策略调整 → 可验证交付
只写积分，没有外部反馈，评分只是装饰。
只看最终输出，不检查过程，评分容易被绕过。
只奖励完成数量，不关心真实结果，系统最终会学会完成仪式，而不是完成任务。
因此，设计游戏化 Skill 时最重要的问题不是怎样让 AI 得到更高分，而是：
需要哪些证据，才能证明它真的完成了任务？
当这个问题被认真回答后，积分、关卡和回合才有意义。
相关阅读
##### FunTester 名片｜万粉千文，百无一用