角色扮演型 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。这一原则直接决定了三个评判方向前置是“给予”的不是“猜”的前提由 Instructor 在 prep 环节引入学习者永远不需要自己去猜。若某个设计让学习者在 prep 里去猜测或发明前提就违反了红线 S2。质量栖居在 beat 之中每个 beat 都是一个有意义的“做事”单元拥有具体、可观察的“done”定义从而构建起一条通向可命名终点的戏剧弧线并以反映真实表演的 debrief 收尾。不能把角色扮演降格成变相测验若“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之前必须先分清哪些字段是学习者可见的、哪些是设计私有的学习者可见字段学习者会读到这里的剧透属于 S4setting、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 优秀并在每条后标注了“低分信号”#维度核心问题低分信号low1projectNotLecture不是讲座场景是“活过的”而非“讲过的”prep 负责讲前提roleplay 阶段是真正的角色内做事“beat”其实是测验题或角色在讲解概念2taskEvaluability任务可评估性每个 roleplay beat 是否带有具体、可观察的successWhen——一个真实的、学习者必须说出或做出的场景内动作/决策并按场景标准评判缺少successWhen或它等同于“他们聊了聊”3typeFit形式匹配每个 beat 是否用对了交付形式表演/决策/成品与真实情境的实际展开方式匹配对话被压平成表单或测验本应是口头交流的场合却要求书面交付4granularity粒度每个 roleplay 阶段有 2-4 个有意义的 beat每个都是实质单元一行填充式 beat或一个应当按回合/阶段拆分的巨型 beat5coherence戏剧弧线连贯性beat 是否相互咬合成一条弧线钩子 → 风险上升 → 转折点/决策 → 解决并持续累积漂浮的、可任意排序的检查清单6topicFidelity主题保真是否严格停留在所请求的场景上没有漂移/替换被换成了通用的“常见”角色扮演7singleConcreteOutcome单一具体结果场景是否收敛到一个可命名的终点做出并辩护的决策、达成的谈判、完成的面试、被支持的朋友并由 wrapup 反思在场景中途戛然而止8difficultyProgressionAndFit难度递进与匹配风险/复杂度是否随 beat 上升并与熟练度层级匹配提供多少 prep/提示脚手架张力平缓、层级不匹配、或开场 beat 过于粗暴9learnerAgency学习者能动性场景是否自由优先free-first——学习者始终输入自己的回应绝无压制学习者的预设“正确台词”僵化分支或单一脚本化的“标准答案”10authenticWorkflow真实工作流流程是否像真实情境那样展开使技能可迁移到练习之外人为的、只在校园里才有的流程序列11stageIntegrity阶段完整性骨架是否严格为 prep → roleplay(s) → wrapup且各阶段 briefing/debrief 与其 beat 匹配prep 只做理解一个任务、不设关卡学习者可见文本无剧透频道分离场景事实 → narration、规则教学 → prep Instructor、辅导 → beathints、角色只说戏内的话prep 设关卡、开头就剧透、角色被写成教练、脚本相互矛盾12closureAndConsolidation收束与巩固wrapup 是否以轻量、具体、基于学习者真实表现的反馈亮点 一项改进收住整条弧线空洞的祝贺或场景没有 wrapup 就被切断红线体系一处违规即判定设计失败评审提示词将红线分为两类并明确要求“列出每一个被违反的代码”。共享设计红线B 系列——与普通 PBL 项目共享的通用问题B1 前向依赖一个 beat 依赖更靠后 beat 的结果。B2 前置缺失一个 beat 假设了先前阶段/prep 从未建立过的上下文。B3 漂浮 beatbeat 可被随意重排没有弧线、没有累积。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 beatroleplay 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 评测运行器中角色扮演场景项目有一条专门的评审链路这从侧面印证了本文档的定位分派runOne通过tc.pblConfig.scenarioRoleplay true判定用例为场景类运行器在报告中按normal/scenario两类分别汇总统计splitByCategory两类分数共享 12 个维度键但不可直接跨类比较。压缩视图projectForJudge在把项目喂给评审 LLM 前会剥离 id/时间戳等运行时噪音并完整保留scenario块与每个 beat 的successWhen/characterObjective/skillFocus/learnerBrief/narration字段——这正是场景评审提示词要逐项审查的字段集合。与运行时可完成性评审互补场景质量评审本文档之前还有一道“运行时可完成性”评审judge-prompt-completability.md它用 C1-C8 阻断码判断学习者能否在真实 PBL v2 运行时里走完全程例如 C7 专门检查“场景骨架是否非 prep → roleplay(s) → wrapup或某 roleplay beat 缺少可观察successWhen”。两道评审一前一后前者回答“设计得好不好”后者回答“在真实运行时里走不走得通”。输出每次运行的结果写入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.tsPBLMicrotaskhints辅导提示与characterObjective形成“频道分离”、successWhen推进闸门、characterObjective私有隐藏信息位、skillFocus单一技能标注、narration场景叙述、learnerBrief学习者简报。PBLMilestonebriefing/completionCriteria/debrief、scenarioStageprep|roleplay|wrapup三值标记。PBLScenarioConfigsetting、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_MODELanthropic:claude-sonnet-4-6 \ EVAL_PBL_API_KEYkey \ EVAL_PBL_THINKINGtrue \ pnpm tsx eval/pbl-v2-planner/runner.ts # 只跑 single-call 变体 EVAL_PBL_VARIANTSsingle-call ... pnpm tsx eval/pbl-v2-planner/runner.ts # 关闭 LLM 评审只统计结构成功率 EVAL_PBL_JUDGEfalse ... pnpm tsx eval/pbl-v2-planner/runner.ts # 只跑前 N 个用例 EVAL_PBL_RUNS4 ... pnpm tsx eval/pbl-v2-planner/runner.ts关键环境变量说明变量作用说明EVAL_PBL_MODEL生成模型格式provider:modelId支持google/anthropic/openaiEVAL_PBL_API_KEY/EVAL_PBL_BASE_URL生成模型密钥/网关OpenAI 兼容网关如 DeepSeek、Qwen只走/v1/chat/completionsEVAL_PBL_JUDGE_MODEL评审模型推荐独立的强模型避免“弱生成器给自家作业打分”缺省时回退到生成模型EVAL_PBL_THINKING/EVAL_PBL_THINKING_BUDGET思考模式开关 / token 预算预算默认 1024EVAL_PBL_VARIANTS变体选择looplegacy agentic 规划器与single-call结构化输出规划器EVAL_PBL_RUNS/EVAL_PBL_FILTER用例筛选按数量截断或按 id 子串过滤EVAL_PBL_CONCURRENCY/EVAL_PBL_STAGGER_MS并发与错峰默认 10 并发、间隔 1000ms避免同时打到网关内置测试用例eval/pbl-v2-planner/scenarios/test-cases.json中即包含 12 个场景类用例覆盖了文档红线清单对应的典型场景scenario-comfort-friend安慰压力很大的朋友练习倾听与共情、scenario-mock-interview与roleplay-job-interviewSTAR 结构面试、技术岗面试、roleplay-tcm-diagnosis中医望闻问切隐藏病因应置于characterObjective、roleplay-texas-holdem德州扑克需规则 收敛校验、roleplay-customer-service投诉处理、roleplay-negotiation-business商务谈判、roleplay-parent-teacher-conference家校沟通——这些用例为理解每条 S 红线的实际语境提供了可直接对照的素材。小结评审一份角色扮演场景设计的四步心法把整个评审提示词浓缩成可执行的流程先读结构确认骨架是prep → roleplay(s) → wrapup没有coreConcept落在场景阶段S1确认 prep 不设关卡、不猜前提S2。再查推进逐个 roleplay beat 检查successWhen是否命名了可观察的场景内动作S3同时确认学习者可见字段无剧透、隐藏事实只在characterObjective中S4。后看角色与形式角色有没有被写成教练、频道是否干净S5规则型场景的rules是否齐全S6表演型 beat 有没有被压平成书面/测验S7有没有假分支压制学习者S8。最后打总分沿 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考