把 Skill 设计成一场游戏

文章主旨：

把 AI Skill（提示词任务系统）设计成“游戏”，核心不是用积分激励模型，而是通过明确任务契约、状态面板、裁判系统与失格规则，将模糊的完成要求转化为可维护的决策结构，从而提升多步任务的真实完成率与可复核性。

关键要点：

1. 仅靠流程说明不足以支撑复杂多步任务，AI 可能做出表面动作却未真正解决问题；游戏化的价值在于补充“目标—状态—裁判—反馈—失败成本”的完整闭环。
2. 积分、关卡只作为上下文影响模型当轮的优先级选择，不会更新模型参数，也不会把经验永久保存；真正起作用的是清晰的成功/失败边界与外部反馈。
3. 可用的游戏化 Skill 至少包含四层：任务契约（明确交付物与验收条件）、状态面板（未验证/已验证/受阻/已完成）、裁判系统（结果裁判与过程裁判分离）、失败规则（阻止 reward hacking 和表演式完成）。
4. 游戏化并不适合所有任务：短回合任务（改写、翻译、概念解释）与高度开放性任务（创意探索、品牌命名）不应使用复杂积分，后者更适合设置“探索预算”而非胜负分数。
5. 验证游戏化 Skill 是否有效，应视为可测量的工程假设：用相同模型、工具、验收器做多次对照实验，保留执行轨迹，比较真实完成率与误报率，而非依赖单次输出。

内容结构：

一、问题的提出：流程化 Skill 的局限

传统 Skill 是“读取输入—分析—固定格式输出—自检”的操作说明，适合简单任务。但当任务需要多轮调用工具、验证结果、处理失败与调整策略时，仅靠流程说明不够，AI 容易停留在表面动作，或在验证失败后原地停滞，最终给出看似完整的总结。

二、游戏化的本质：一种决策结构

将 Skill 设计成游戏，不是为了让 AI 产生类似人的胜负欲，而是为任务补上目标、状态、裁判、反馈和失败代价。设计良好的游戏化能帮 AI 把注意力放在真实结果上；设计差的只会让 AI 高效刷分。作者强调了两段指令的对比：前者只写“请完成代码审计并输出报告”，后者明确“必须有直接证据才能标记为已确认、无法验证的项必须标记为未知、未验证即宣称完成视为失败”，说明边界清晰比话术更重要。

三、澄清：游戏化并不是“训练 AI”

在 Skill 中加入积分或扣分不会更新模型参数，评分本质仍是上下文的一部分，影响的是模型当前如何理解优先级、如何选择下一步，以及何时承认任务未完成。如果能把测试结果、静态分析、文件状态或人工审阅意见反馈回模型，评分才会成为下一轮行动的决策依据，Skill 才具备反馈回路。

四、游戏化 Skill 的核心四层

1. 任务契约：很多 Skill 的问题不是步骤不够，而是胜利条件模糊。“认真审计”“写一篇好文章”无法被判断。任务契约应明确定义：最终交付物是什么、哪些条件必须满足、哪些情况不能宣称完成、哪些结论需要外部证据、信息不足时应如何报告未知与阻塞点。以研究类 Skill 为例，胜利条件不是信息数量，而是关键结论可回溯到原始来源、日期与正文已核对、推断与事实分离、证据缺失时不用推测填补空白。

2. 状态面板：状态面板不是氛围装饰，而是让 AI 明确“当前处于什么状态”。文中用表格展示了四种状态及其下一步：未验证（只有线索，需搜索/读取/运行检查）、已验证（有代码、测试或权威来源支撑，记录证据位置纳入交付）、受阻（缺少权限或外部信息，需明确阻塞条件与最小验证路径）、已完成（满足全部验收条件，停止无关扩展）。该设计可减少“把已写出的文字等同于已完成”的常见问题——写完说明不等于通过测试或复现缺陷。

3. 裁判系统：游戏化最容易走偏的地方是把“可量化”当成“真实价值”。只奖励漏洞数量，AI 会把模糊线索包装成漏洞；只奖励引用数量，AI 会堆砌链接而不判断可靠性；只奖励测试通过率，模型甚至可能改测试来通关。因此裁判须分两类：结果裁判（最终功能是否工作、结论是否可复核）；过程裁判（是否遵守范围、验证、伪造证据或绕过验收）。多轮 Agent 的评测不应只看最后一段输出，任务、尝试次数、工具调用、环境变化和完整轨迹都应纳入检查；不同类型任务需要不同评分手段。

4. 失败规则：一旦有评分，就必须假设系统会找漏洞，即 reward hacking——拿到高分但偏离真实目标。扣分项应当是明确的失格条件，包括：未验证就声称完成；编造文件、来源、命令输出或测试结果；修改验收条件、删除测试或绕过安全控制来制造成功；把本地代码缺口直接推导为最终业务损失；将外部配置、下游服务或权限依赖说成已被证实；用大量不影响最终结果的子任务堆积完成感。可用原则是：任何脱离用户真实目标后即失去价值的高分行为，都不应被单独奖励。

五、为什么游戏化可能提高完成率

提升主要来自三个方面。第一，帮助模型识别优先级：任务同时包含搜索、分析、验证、写作与收尾时，明确得失分条件能让模型优先做对最终验收最有价值的动作，而非平均用力。第二，为失败后继续行动提供依据：普通 prompt 只写“如果失败请重试”，但失败类型不同——搜索不到、测试不过、权限不足、依赖不可达，需要不同应对策略。第三，迫使设计者提前澄清验收标准，回答“裁判依据什么判定胜利”，这个问题的价值往往高于积分规则本身。

六、示例：安全审计 Skill 的对比设计

普通写法是“审计指定接口，寻找权限与业务校验问题，输出风险报告”。更接近游戏化闭环的写法则是设定：总目标（交付可复核的审计结论）；胜利条件（每条已确认问题均可定位到入口、调用链与控制缺口；本地可证明的风险与依赖外部配置才能确认的风险必须分开；用户排除的接口不计入）；状态分类（线索、已验证、待外部确认、误报、已完成）；得分项（有直接证据的问题加分、完整追踪边界加分、明确说明不确定性与验证顺序加分）；失格项（无证据下确定性结论、将局部绕过等同于资金损失、将扫描器线索当漏洞、虚构测试或调用结果）。作者特别说明：分数只是内部取舍工具，用户需要的不是 AI 自报得分，而是交付结论经得起复核。

七、不适合游戏化的任务

两类任务不宜设计积分系统：一是短回合、缺少工具与外部反馈的任务（改写文案、翻译、解释概念），复杂积分只会徒增 prompt 长度与噪声；二是高度开放、目标未收敛的任务（早期创意探索、产品命名、品牌风格讨论），单一分数会迫使模型收敛到易得分的保守方案，牺牲探索空间。后者更适合设探索约束，例如：至少提出三种明显不同的方向、每个方向说明适用场景与代价、不允许换词复述同一方案、由人来决定下一轮深入方向。概括而言：确定性任务需要裁判，开放性任务需要探索预算。

八、如何验证游戏化 Skill

游戏化是否真实提高完成率，不能凭一次体验下结论，应视为可测量的工程假设。最小验证法：准备一组真实且带验收条件的任务；分别运行原始流程型 Skill 与游戏化版本；使用相同模型、工具权限、相近上下文与相同验收器；每类任务多次试运行以避免随机性；比较真实完成率、验证通过率、误报率、平均成本与人工返工量。由于模型输出有随机性，单次对比不可靠，应保留执行轨迹，检查在哪些环节更少放弃、更少猜测，或反而出现新的刷分行为。工程上可选字符串检查、相似度检查或模型评分等各类评测器，关键是针对不同目标选合适裁判，用多层检查降低误判风险。

九、结论：Skill 是任务系统而非积分系统

Skill 写成游戏，不是为了让 AI 看起来积极，也不只是为了加入几句积分和关卡。真正有效的设计是完整闭环：“任务契约 → 状态判断 → 行动 → 外部反馈 → 裁判检查 → 策略调整 → 可验证交付”。只写积分而无外部反馈，评分只是装饰；只看最终输出而不检查过程，评分容易被绕过；只奖励完成数量而不关心真实结果，系统最终学会的是“完成仪式”而非完成任务。设计时最重要的问题不是如何拿到高分，而是：需要哪些证据，才能证明它真的完成了任务？当这个问题被认真回答后，积分、关卡与回合才有意义。

文章总结：

这是一篇面向 AI 工程与 Skill 设计者的方法论文章，语气客观务实、案例具体，强调用“证据驱动”取代“表演式完成”来设计 AI 任务系统；核心建议是：先定义真正的完成信号，再谈积分和游戏化机制，并强调对方案进行多轮对照验证。

FunTester

查看原文：把 Skill 设计成一场游戏

文章来源：

FunTester

扫码关注公众号