角色扮演型 PBL 场景设计评审指南：OpenMAIC 的 12 维质量评分与 8 条红线判据

角色扮演型 PBL 场景设计评审指南：OpenMAIC 的 12 维质量评分与 8 条红线判据

【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAIC

角色扮演（Role-play）型 PBL 项目与普通 PBL 项目有着本质区别——学习者不是“学完一个话题”，而是进入一个具体情境、以角色身份与由 Simulator 扮演的角色互动。因此它的质量评审必须与普通 PBL 分开进行，使用独立的规则体系。本指南以 OpenMAIC 仓库中 eval/pbl-v2-planner/judge-prompt-scenario.md 这份专用于角色扮演场景的评审提示词为核心，完整讲解其设计哲学、12 个评分维度、8 条场景红线与输出协议，并结合仓库源码说明其在实际评测管线中的落地方式。读完本文，你将能够：准确判断一个自动生成的角色扮演场景是“可上线的设计”还是“必须返工的设计”，能够给出结构化的 1-5 分评分与红线清单，并理解这套评审逻辑在 PBL v2 评测框架中的位置。

为什么角色扮演场景需要一套独立的评审标准

OpenMAIC 的 PBL v2 评测框架（评测隔离运行器见 eval/pbl-v2-planner/runner.ts）内置了两套完全不同的 LLM 评审提示词：普通项目走 judge-prompt.md，而带顶层scenario块的角色扮演项目走judge-prompt-scenario.md。运行器中的judgeTemplate(isScenario)正是按project.scenario是否存在来决定读取哪套模板，并在生成的报告里将结果分为normal与scenario两类分开统计——正如 runner.ts 的注释所写：“角色扮演场景项目由一套独立的场景评分标准来打分，而非本套（普通）标准”。

这种拆分的原因在于评审对象完全不同：普通 PBL 评审的是“学习者要执行的项目”（调查、决策、构建、测试、反思），而角色扮演评审的是“学习者要表演的场景”。在角色扮演中，前置（prep）环节由 Instructor 向学习者交代前提（premise），学习者从不猜测前提是什么；质量完全体现在 beat（微任务）之中——每一个 beat 都是一次有意义的“做事”单元，有可观察的“完成”（done）标准，共同构筑一条通向可命名的终点的戏剧弧线，并以一场反映真实表现的复盘（debrief）收尾。评审的角色是“评审设计本身”，与它“是如何被生成出来的”无关。

从数据契约看，这套评审针对的结构在 packages/@openmaic/dsl/src/pbl.ts 中有精确定义：里程碑（PBLMilestone）可以携带scenarioStage?: 'prep' | 'roleplay' | 'wrapup'标记，角色扮演微任务（PBLMicrotask）则携带successWhen、characterObjective、skillFocus、learnerBrief、narration等字段；顶层PBLScenarioConfig聚合了setting（场景设定）、rules（规则）、learnerRole（学习者角色）与characters（角色列表，每个角色含persona、situation、boundaries、openingLine）。这些字段就是评审提示词全部规则的操作对象。

核心原则：场景是被“表演”的，而不是被“讲授”的

评审的第一条铁律是：角色扮演场景是学习者“表演”（perform）的——他们走进一个具体情境，与由独立 Simulator 在运行时扮演的角色进行角色内互动。它既不是一堂讲座（lecture），也不是一张书面练习单（written worksheet）。

这一原则直接决定了三个评判方向：

1. 前置是“给予”的，不是“猜”的：前提由 Instructor 在 prep 环节引入，学习者永远不需要自己去猜。若某个设计让学习者在 prep 里去猜测或发明前提，就违反了红线 S2。
2. 质量栖居在 beat 之中：每个 beat 都是一个有意义的“做事”单元，拥有具体、可观察的“done”定义，从而构建起一条通向可命名终点的戏剧弧线，并以反映真实表演的 debrief 收尾。
3. 不能把角色扮演降格成变相测验：若“beat”本质上只是知识点问答，或只是角色在讲解概念，那它就不再是角色扮演——这是红线 B9（隐形授课）与 S3（缺失成功判定）要拦截的核心问题。

如何解读一个 beat 的 “done”：两条轴，切勿字面理解

文档明确指出，一个 beat 的“交付物”几乎从来不是一个文件。评审时要沿两条轴来判断，切忌按字面意思把“完成”读成“产出了一个有形文件”或“匹配了预期答案”：

轴一：任务性质（Task nature）——决定“怎么算做好”

• 可评分开放型（gradable-open）：绝大多数 beat 属于这一类。一次得体的表演，或一个经过辩护的决定，在该场景的规则/领域标准下存在明确的“更好/更坏”之分（例如德州扑克决策的 +EV、面试回答的结构、共情回应的质量）。一个 beat 在“动作确实做了”时推进；而“做得有多好”则依据这些标准单独评判——绝不降格为“他们说了句话就算过”。
• 收敛型（convergent）：部分场景存在收敛的规则校验，例如一记“合法”的德州扑克动作（如合法加注、合法下注金额）。这类校验只回答“对不对”。
• 开放反思型（open-reflective）：例如“学习者当时的感受如何”这类时刻，价值在思考本身，没有对错。

轴二：交付形式（Delivery form）——决定证据长什么样

• 表演（performance）：主导形式。在互动中把目标动作做出来——先共情再提问、表达边界、做出并辩护决策、谈判、回答面试追问。
• 成品（artifact）：学习者提交书面产出，例如“给他们写一封信”。
• 显式决策（decision）：明确的一个决策点。

文档特别警告：把一个表演型 beat 强行改写成书面形式或测验，就是缺陷（对应红线 S7 表演扁平化）。

学习者可见 vs 设计私有的信息边界（剧透判断的基础）

在评审剧透问题（红线 S4）之前，必须先分清哪些字段是学习者可见的、哪些是设计私有的：

• 学习者可见字段（学习者会读到，这里的剧透属于 S4）：setting、rules、learnerRole、每个角色的name/persona/situation/openingLine、prep 的briefing，以及每个角色扮演 beat 的description/learnerBrief/narration。
• 设计私有字段（绝不展示给学习者、绝不叙述、绝不说出）：beat 的characterObjective。这是为“学习者必须揭开的某个事实”准备的预定隐藏位——一个隐藏的病因、一个秘密、对手的底牌放在characterObjective里是正确的设计，不是剧透，不得因此标记 S4。

两条配套的解读规则同样关键：

• successWhen是推进闸门（advance gate）——场景内可观察的动作，使 beat 得以推进。它不要求内嵌完整评分细则；“做得有多好”是在运行时依据场景标准单独评判的。因此，仅仅因为successWhen只命名了动作而没有写出质量门槛，不应标记 S3。
• 作者写好的briefing/debrief是设计期脚本；运行时 debrief 以学习者的真实表现为基础。一份读起来像是“学习者表现不错”的预写 debrief 是正常占位符，不是缺陷——评审 closure（收束）时看的是 wrapup 是否塑形为提供基于具体表现的反馈，而不是看占位措辞本身。

12 个质量维度：从 1 到 5 的评分标准

文档为每个维度定义了明确的 1-5 评分区间（1 = 差，3 = 可接受，5 = 优秀），并在每条后标注了“低分信号”：

红线体系：一处违规即判定设计失败

评审提示词将红线分为两类，并明确要求“列出每一个被违反的代码”。

共享设计红线（B 系列）——与普通 PBL 项目共享的通用问题：

• B1 前向依赖：一个 beat 依赖更靠后 beat 的结果。
• B2 前置缺失：一个 beat 假设了先前阶段/prep 从未建立过的上下文。
• B3 漂浮 beat：beat 可被随意重排，没有弧线、没有累积。
• B5 巨型 beat：一个 beat 捆绑了多个互不相关的场景内目标。
• B6 琐碎碎片化：一次单一交流被拆成过多微 beat。
• B7 冗余阶段：roleplay 阶段做同样的事或纯粹是填充。
• B8 无终局结果：场景从未收敛到任何可命名的终点。
• B9 隐形授课：“beat”其实是问答/概念复习，而非角色内做事。
• B11 主题替换：请求的场景被替换成了通用教学场景。
• B16 范围爆炸：阶段/beat 过多，无法在一次专注的坐席（约 15-45 分钟）内完成。

场景专属红线（S 系列）——本场景中最需要关注的：

• S1 骨架错误：不是严格的 prep → roleplay(s) → wrapup，或任一场景阶段设置了coreConcept。
• S2 prep 设关卡或猜测：prep 有“先做再前进”的任务、有超过一个微任务、或要求学习者猜测/发明前提而不是被告知前提。（一条只说“你已经读完了背景”的completionCriteria不是关卡——prep 允许拥有自己的 briefing/completionCriteria 文本。）
• S3 缺失/空白的成功判定（仅 roleplay beat）：roleplay beat 缺少successWhen，或其successWhen没有命名任何可观察的场景内动作（字面就是“他们聊了聊/讨论了”）。successWhen命名了具体动作但没有写出质量门槛是允许的（质量单独评判）。prep 和 wrapup 正确地没有successWhen——永远不要为它们标记 S3。
• S4 剧透（仅学习者可见字段：setting/rules/learnerRole/ 角色的persona/situation/openingLine/ prepbriefing/ beat 的description/learnerBrief/narration）：其中之一揭示了本应稍后揭开的事实，或预述了更靠后 beat 的情境。放在私有characterObjective中的隐藏事实是正确的，不算S4。
• S5 角色即教练 / 频道混流：角色被写成在“辅导”学习者——给学习者打分、要求他们论证推理、给出策略/元提示、叙述场景、或说“轮到你了”。戏内的评估动机（面试官私下评估候选人、对手读牌）是角色的正当驱动力，不是S5；违规在于指向学习者的元交流。角色暗示它能看到不应看到的隐藏信息（例如学习者的底牌）也是 S5。
• S6 规则缺失：基于规则的场景（游戏/面试/辩论/结构化谈判）缺少 Instructor 在 prep 中讲解前提所需的具体rules。
• S7 表演扁平化：本应是现场口头交流的 beat 被强制改成书面成品或测验，且没有任何戏内理由（交付形式不匹配）。
• S8 假分支 / 能动性被压制：预设的“正确”台词或僵化分支覆盖了学习者自己的自由回应。

判定逻辑：任意一条红线被违反，即意味着设计失败、必须修复；overall（总体分）是整体的 ship/no-ship 判断，任何红线都应把它强力拉低。

输出协议：严格的单 JSON 对象

评审的最终输出被严格限定为恰好一个 JSON 对象，不允许任何散文、不允许代码围栏。完整结构如下（其中scores的 12 个键与上文维度一一对应，redLines可同时包含 B 码和 S 码，无违规时为[]）：

{ "scores": { "projectNotLecture": 4, "taskEvaluability": 4, "typeFit": 5, "granularity": 4, "coherence": 4, "topicFidelity": 5, "singleConcreteOutcome": 4, "difficultyProgressionAndFit": 4, "learnerAgency": 4, "authenticWorkflow": 4, "stageIntegrity": 4, "closureAndConsolidation": 4 }, "redLines": ["S3"], "overall": 3, "rationale": "整体判断：场景骨架与表演节奏成立，最大弱点是某 roleplay beat 的 successWhen 仅描述‘聊了聊’而无可观察动作，违反了 S3，需修复后再上线。" }

注：上述 JSON 的分数与红线为格式示例，rationale字段要求 2-3 句话：给出整体判断、指出最大弱点、说明任何红线及其原因。

这一输出会被评测运行器直接消费：judgeProject使用parseJsonResponse解析模型输出，校验scores是否为对象、overall是否为数字，并将redLines规整为数组（见 runner.ts）。解析失败的输出会被静默降级为“未打分”，不中断整个评测。

从评审到报告：场景类项目在评测管线中的落点

在 PBL v2 评测运行器中，角色扮演场景项目有一条专门的评审链路，这从侧面印证了本文档的定位：

1. 分派：runOne通过tc.pblConfig.scenarioRoleplay === true判定用例为场景类，运行器在报告中按normal/scenario两类分别汇总统计（splitByCategory），两类分数共享 12 个维度键但不可直接跨类比较。
2. 压缩视图：projectForJudge在把项目喂给评审 LLM 前，会剥离 id/时间戳等运行时噪音，并完整保留scenario块与每个 beat 的successWhen/characterObjective/skillFocus/learnerBrief/narration字段——这正是场景评审提示词要逐项审查的字段集合。
3. 与运行时可完成性评审互补：场景质量评审（本文档）之前，还有一道“运行时可完成性”评审（judge-prompt-completability.md），它用 C1-C8 阻断码判断学习者能否在真实 PBL v2 运行时里走完全程（例如 C7 专门检查“场景骨架是否非 prep → roleplay(s) → wrapup，或某 roleplay beat 缺少可观察successWhen”）。两道评审一前一后，前者回答“设计得好不好”，后者回答“在真实运行时里走不走得通”。
4. 输出：每次运行的结果写入eval/pbl-v2-planner/results/<model>/<timestamp>/下的report.md、results.json与逐项目 JSON，可通过eval/pbl-v2-planner/serve.ts启动本地比对查看器（默认端口 5179）逐案例浏览。

场景字段契约：评审对象的结构依据

评审文档所审查的所有字段，都定义在 OpenMAIC 的 PBL v2 数据契约中（packages/@openmaic/dsl/src/pbl.ts）：

• PBLMicrotask：hints（辅导提示，与characterObjective形成“频道分离”）、successWhen（推进闸门）、characterObjective（私有隐藏信息位）、skillFocus（单一技能标注）、narration（场景叙述）、learnerBrief（学习者简报）。
• PBLMilestone：briefing/completionCriteria/debrief、scenarioStage（prep|roleplay|wrapup三值标记）。
• PBLScenarioConfig：setting、goal、rules、learnerRole、characters[]（每个角色含persona、situation、boundaries、openingLine）。

运行时侧，lib/pbl/v2/types.ts 中的PBLScenarioActGoals展示了这些设计字段的最终去向：在场景类项目的完成报告中，每个 roleplay 幕（act）的successWhen以只读形式作为“本幕的目标”呈现，skillFocus作为目标旁的小标签，并由最终评估器依据真实对白转录给出achieved/partial/missed三态判定——也就是说，评审文档要求“成功判定必须可观察”的设计原则，在运行时被兑现为基于实际表演转录的目标覆盖度评估，而非简单打卡。

评测运行与自定义配置

如果你需要在 OpenMAIC 仓库内复现这套评测（含场景评审），运行器提供了完整的参数化配置（用法见 runner.ts 文件头部注释）：

# 完整运行（两变体：loop 与 single-call） EVAL_PBL_MODEL=anthropic:claude-sonnet-4-6 \ EVAL_PBL_API_KEY=<key> \ EVAL_PBL_THINKING=true \ pnpm tsx eval/pbl-v2-planner/runner.ts # 只跑 single-call 变体 EVAL_PBL_VARIANTS=single-call ... pnpm tsx eval/pbl-v2-planner/runner.ts # 关闭 LLM 评审（只统计结构成功率） EVAL_PBL_JUDGE=false ... pnpm tsx eval/pbl-v2-planner/runner.ts # 只跑前 N 个用例 EVAL_PBL_RUNS=4 ... pnpm tsx eval/pbl-v2-planner/runner.ts

关键环境变量说明：

内置测试用例（eval/pbl-v2-planner/scenarios/test-cases.json）中即包含 12 个场景类用例，覆盖了文档红线清单对应的典型场景：scenario-comfort-friend（安慰压力很大的朋友，练习倾听与共情）、scenario-mock-interview与roleplay-job-interview（STAR 结构面试、技术岗面试）、roleplay-tcm-diagnosis（中医望闻问切，隐藏病因应置于characterObjective）、roleplay-texas-holdem（德州扑克，需规则 + 收敛校验）、roleplay-customer-service（投诉处理）、roleplay-negotiation-business（商务谈判）、roleplay-parent-teacher-conference（家校沟通）——这些用例为理解每条 S 红线的实际语境提供了可直接对照的素材。

小结：评审一份角色扮演场景设计的四步心法

把整个评审提示词浓缩成可执行的流程：

1. 先读结构：确认骨架是prep → roleplay(s) → wrapup，没有coreConcept落在场景阶段（S1）；确认 prep 不设关卡、不猜前提（S2）。
2. 再查推进：逐个 roleplay beat 检查successWhen是否命名了可观察的场景内动作（S3），同时确认学习者可见字段无剧透、隐藏事实只在characterObjective中（S4）。
3. 后看角色与形式：角色有没有被写成教练、频道是否干净（S5），规则型场景的rules是否齐全（S6），表演型 beat 有没有被压平成书面/测验（S7），有没有假分支压制学习者（S8）。
4. 最后打总分：沿 12 个维度给出 1-5 分，任何红线都会把overall强力拉低；然后只输出一个严格格式的 JSON 对象。

这套规则的价值在于：它把“这个场景好不好”这一主观问题，拆解成了可复核、可自动化的 12 个维度和 8 条红线，使 LLM 评审结果可被信任、可被回溯，也让场景生成器的迭代有了明确、可执行的改进方向。

【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAIC