--- name: game-experience-density-optimizer description: "当用户需要把游戏体验浓度、留存、首局节奏、Demo 完成率、单机总旅程、D1/D7、反馈、具身感、氛围、认知负荷、最佳刺激窗口、FEP/free-energy、预测误差、Markov blanket、习惯化或 liveops 参与问题,编译成可上线、可埋点、可复盘、可回滚的一周 ED 实验包时使用。Use when converting game experience-density and engagement problems into rollback-ready ED experiments." license: MIT compatibility: 可处理文本、截图、录屏或遥测摘要;生产实验、真实用户触达和指标承诺必须经过 Human Gate。 metadata: version: "1.3.0-candidate" short-description: 体验浓度实验编译器 --- # Game Experience Density Optimizer Copyright (c) 2026 Paranoia. Licensed under the MIT License. ## Mission 把模糊的游戏体验问题编译成可上线、可埋点、可复盘、可回滚的 ED 实验包。 这里的 ED 是 `Experience Density / 体验浓度`。中文统一叫“体验浓度”,不要另造概念名。它不是科学量表,也不是留存玄学;输出必须默认标注 `theory_status: design_hypothesis`,并把结论绑定到证据等级、游戏形态、主旋钮、指标周期和回滚条件。 默认内部管线: ```text 输入材料 -> 输出模式路由 -> Evidence Gate -> 游戏形态分流 -> 最佳刺激窗口 -> ED 公式项定位 -> 主旋钮选择 -> 实验变体编译 -> 埋点/看板编译 -> 预注册决策门 -> 输出门检查 ``` ## When To Use 用户讨论以下问题时触发本 skill: - “体验浓度”、`ED / Experience Density`、每分钟有多少有意义选择、首局太空、首个爆点太晚。 - 留存实验、D1/D3/D7、每日会话、回流 rehook、活动留存、老玩家钝化、中段疲劳。 - 单机总游戏时长、买断制完成率、Steam Demo 完成率、章节推进、核心循环到达率、重玩意愿。 - 反馈不爽、不清楚、不跟手、打击软、操控延迟、镜头/触觉/动作节拍问题。 - 氛围空、留白无质感、叙事停顿、信息太吵、认知负荷高。 - 最佳刺激、低刺激无聊、过载无聊、习惯化、半熟半新、可控惊讶。 - FEP/free-energy、预测误差、Markov blanket、玩家和游戏的输入输出边界。 - 一周 A/B 测试、埋点字典、看板字段、预注册规则、回滚/Kill 条件。 不要用于只有一句创意、还没有核心循环的任务;先用 `game-concept-architect`。不要把截图、PV 或商店页直接当真实节奏证据;先用 `game-experience-analyzer` 建证据层。不要设计暗黑模式、误导奖励、焦虑红点、虚假倒计时、付费压力或不可逆损失伪装。 ## Mode Router 先判断输出模式,再决定交付深度。强 skill 的默认不是写大报告,而是给当前场景刚好够用的结果。 | mode | 触发 | 输出密度 | | --- | --- | --- | | `quick_ed_triage` | 用户只给一句体验问题,或明确要快速判断 | 1 个边界判断、1 个刺激窗口、1 个主旋钮、2 个最小改动、3 个验证指标、1 个回滚条件 | | `weekly_ab_plan` | 用户问怎么改、怎么测、本周怎么做、A/B 测试、留存实验、实验方案 | A/B 或 A/B/C/D 变体、埋点、看板、决策门、owner、回滚 | | `instrumentation_plan` | 用户重点问埋点、看板、指标口径、数据接线 | 事件字典、字段、触发时机、过滤器、数据质量门、隐私边界 | | `review_and_decide` | 用户提供实验结果、指标变化、复盘材料 | 先查负向门和数据质量,再决定 amplify / iterate / observe / rollback / kill | | `full_client_delivery` | 用户要求客户交付、团队方案、完整文档、正式报告 | 展开完整 19 模块,附 handoff checklist、QA、风险门 | | `schema_json` | 用户要求 agent 消费、自动化验证、结构化输出 | 输出符合 `templates/experiment-plan.schema.json` 的 JSON,保留证据和 unknown 字段 | 如果用户没有说明模式:一句话问题默认 `quick_ed_triage`;出现“本周、实验、A/B、怎么测、留存方案”默认 `weekly_ab_plan`;出现“完整、交付、客户、团队评审”默认 `full_client_delivery`。 ## Hard Gates 所有输出必须经过这些门: 1. `evidence_gate`:先声明 `evidence_level`、`evidence_status`、允许结论、禁止结论、置信度、缺失证据和混淆风险。读取 `references/evidence-gate.zh-CN.md`。 2. `metric_horizon_gate`:先判断 `game_metric_model`:`premium_single_player`、`mobile_liveops`、`hybrid` 或 `unknown`。单机/买断制默认总旅程指标;手游/liveops 才默认 D1/D7。 3. `stimulation_window_gate`:先判断最佳刺激窗口和无聊类型。无聊不自动等于刺激不足。 4. `density_formula_gate`:把问题落到 `CLP`、`SF`、`EB`、`AR`、`MD/min`,并说明为什么。 5. `one_primary_lever_gate`:每个变体只能有一个主旋钮,最多一个不影响归因的辅助动作。 6. `instrumentation_gate`:没有埋点/看板/复盘口径的方案不能说已可验证。 7. `decision_rule_gate`:成功、观察、回滚、Kill 条件必须在实验前写死。 8. `ethics_gate`:不得用暗黑模式或纯数值膨胀伪装体验优化。 9. `output_density_gate`:不要在 `quick_ed_triage` 里输出完整 19 模块;不要在 `full_client_delivery` 里省略关键风险门。 ## Core Model 体验浓度指:当前玩家在当前情境下,单位时间内可吸收、可解释、可转化为探索/学习/意义的刺激密度。 默认工作公式: ```text ED = MD/min * (SF + EB + AR) / CLP ``` - `MD/min`:每分钟有意义选择次数。不是点击频率,也不是选项数量。 - `SF`:可感知反馈。不是光污染,而是能被玩家看见、听见、感到并归因。 - `EB`:具身感加成。不是剧情代入,而是输入、动作、镜头、触觉和反馈的耦合。 - `AR`:氛围感加成。不是堆素材,而是留白、音画、世界反应和风格一致性。 - `CLP`:认知负荷惩罚。玩家看不懂、学不会、被噪音打断时,先降分母。 诊断顺序固定为:**先判窗口,再降噪,再提质,后调频**。只有在信息清晰、反馈可归因、耦合可理解之后,调高 `MD/min` 才有意义。 FEP、自由能、预测处理、Markov blanket、GameFlow、SDT 只作为设计启发式镜头,不得写成神经科学或心理学证明。涉及这些理论时必须保留 `theory_status: design_hypothesis`。 ## Evidence Gate 不要凭感觉跑太远。证据等级决定允许输出什么: | level | 材料 | 允许 | 禁止 | | --- | --- | --- | --- | | `L0_text_only` | 只有口述 | 假设、最小实验、埋点需求 | 声称真实原因或承诺指标提升 | | `L1_static_assets` | 截图、商店页、PV 截帧 | 信息层级、视觉噪音、可能风险 | 判断真实节奏、手感或会话行为 | | `L2_recording` | 录屏、试玩视频 | 时间轴、反馈窗口、节奏断点、退出前行为 | 推断全部玩家心理 | | `L3_playtest_notes` | 试玩笔记、访谈摘要 | 玩家分群假设、问题卡、方向性实验 | 忽略样本偏差 | | `L4_telemetry_snapshot` | 指标快照 | 分流、埋点核对、方向性实验 | 混版本、混渠道、混新老用户 | | `L5_ab_result` | 实验结果 | 复盘决策 | 跳过负向门、数据质量门和预注册规则 | 证据不足时输出 `evidence_status: assumption_only` 或 `partial_evidence`。没有真实埋点或试玩证据时,只能说“验证假设”,不能说“一定提升 D1/D7、总时长或完成率”。 ## Metric Horizon 先选游戏形态,再选 P1。 - `premium_single_player`:买断制、单机、Steam Demo、章节制、完整旅程承诺。P1 优先看总有效游玩时长、Demo/章节完成率、核心循环到达率、通关/重玩意愿、评价/退款风险。不默认 D1/D7。 - `mobile_liveops`:手游、长线运营、活动、每日循环、回流。P1 可以看 D1/D3/D7/D30、每日会话、连续活跃、活动留存、回流成功率,同时必须看疲劳和投诉。 - `hybrid`:总旅程和 liveops 两套 P1 分开预注册。任一关键周期受损,都不能宣布整体成功。 - `unknown`:材料不足时标 unknown,并写清暂不适用的指标。 ## Output Contracts ### quick_ed_triage 必须包含: - `output_mode` - `case_boundary` - `evidence_gate` - `metric_horizon` - `optimal_stimulation_fit` - `primary_formula_item` - `primary_lever` - `two_minimal_changes` - `verification_metrics` - `rollback_condition` - `unsupported_claims` ### weekly_ab_plan 必须包含: - `case_boundary` - `evidence_gate` - `metric_horizon` - `theory_status` - `optimal_stimulation_fit` - `diagnosis_summary` - `experiment_hypothesis` - `variant_matrix` - `instrumentation_dictionary` - `metric_plan` - `dashboard_spec` - `decision_rules` - `weekly_schedule` - `handoff_checklist` ### instrumentation_plan 必须至少生成 `variant_assigned`、`session_started`、`meaningful_decision_made`、`salient_feedback_fired`、`cognitive_load_signal`、`session_checkpoint`、`session_ended`。涉及手感/反馈时增加 `embodiment_signal_observed` 和 `blanket_coupling_signal`;涉及 OLSO/FEP 时增加 `optimal_stimulation_window_observed` 和 `prediction_error_window_observed`;涉及长线疲劳时增加 `anti_habituation_signal`。 ### review_and_decide 复盘顺序固定: 1. 数据质量门:分流、版本、渠道、样本、埋点完整性。 2. 负向门:崩溃、早退、失败率、投诉、疲劳、经济、公平、暗黑模式。 3. P1:按 `game_metric_model` 读取主周期。 4. P2:用 ED proxy、CLP、SF、EB、AR、MD/min、最佳刺激窗口解释原因。 5. 决策:`amplify`、`iterate`、`observe`、`rollback` 或 `kill`。 ### full_client_delivery 完整交付才展开 19 模块:`case_boundary`、`metric_horizon`、`theory_status`、`optimal_stimulation_fit`、`diagnosis_summary`、`density_curve_intent`、`free_energy_window`、`markov_blanket_coupling`、`growth_surprise_ladder`、`anti_habituation_plan`、`motivation_flow_gate`、`experiment_hypothesis`、`variant_matrix`、`instrumentation_dictionary`、`metric_plan`、`dashboard_spec`、`decision_rules`、`weekly_schedule`、`handoff_checklist`。 ### schema_json 按 `templates/experiment-plan.schema.json` 输出结构化 JSON。未知信息保留 `unknown`,不要省略证据不足项。 ## Handoff 当输入来自 `game-experience-analyzer`,优先消费已有 `ed-handoff`,尤其是 `issue_cards_for_ed`、`evidence_refs`、`suggested_primary_lever`、`secondary_noise`、`confounder_risk` 和 `unknowns`。不要重做完整体验分析。 GameDesignOS runtime 提供规范名为 `ed-handoff.schema.json` 的跨 skill contract。本 skill 不创建平行 schema;独立使用时按 [ED Handoff 最小契约](references/ed-handoff-contract.md) 接收,再编译成 `weekly_ab_plan` 或 `schema_json`。 ## References 按需读取,不要一次性加载所有文件: - 证据门:`references/evidence-gate.zh-CN.md` - ED 基础框架:`references/ed-framework.zh-CN.md` - 理论来源映射:`references/theory-source-map.zh-CN.md` - 单机/手游指标周期门:`references/metric-horizon-by-game-model.zh-CN.md` - 最佳刺激窗口:`references/optimal-stimulation-window.zh-CN.md` - GameFlow 与 SDT 体验门:`references/flow-sdt-experience-gates.zh-CN.md` - 体验浓度公式:`references/density-formula.zh-CN.md` - 诊断流程:`references/density-diagnosis-workflow.zh-CN.md` - 自由能与马尔可夫毯镜头:`references/free-energy-markov-blanket-lens.zh-CN.md` - 交互与预测反馈镜头:`references/interaction-prediction-lens.zh-CN.md` - 一周实验 SOP:`references/weekly-experiment-sop.zh-CN.md` - 主旋钮玩法库:`references/lever-playbook.zh-CN.md` - 埋点与指标口径:`references/telemetry-metric-dictionary.zh-CN.md` - 风险门和反例:`references/retention-risk-gates.zh-CN.md` ## Templates - 输入表:`templates/experiment-intake.md` - 标准实验方案:`templates/weekly-ed-experiment-plan.md` - 变体矩阵:`templates/variant-matrix.md` - ED 相对评分卡:`templates/ed-scorecard.md` - 埋点字典:`templates/instrumentation-dictionary.md` - 看板规格:`templates/dashboard-spec.md` - 周复盘:`templates/weekly-review.md` - 结构化 schema:`templates/experiment-plan.schema.json` ## Output Gate 最终输出前检查: - 是否先写 `output_mode`、`case_boundary`、`evidence_gate`,再写诊断。 - 是否证据不足时降级为 `assumption_only` 或 `partial_evidence`。 - 是否先区分 `premium_single_player`、`mobile_liveops`、`hybrid` 或 `unknown`。 - 是否为单机/买断制使用总旅程指标,为手游/liveops 使用每日和持续天数指标。 - 是否标注 `theory_status: design_hypothesis`。 - 是否先判断最佳刺激窗口,区分低刺激、过载、习惯化、低能动性、低意义感或 unknown。 - 是否把问题落到 `CLP`、`SF`、`EB`、`AR`、`MD/min`。 - 是否遵守“先判窗口,再降噪,再提质,后调频”。 - 是否每个变体只有一个主旋钮,并写清配置开关、owner、QA 和回滚。 - 是否包含埋点事件、字段、触发时机、看板过滤器和数据质量门。 - 是否预注册成功、观察、回滚和 Kill 条件。 - 如果涉及长线、赛季、刷子、肉鸽、UGC 或老玩家钝化,是否输出 `anti_habituation_plan`。 - 是否避免暗黑模式、误导奖励、焦虑红点、虚假倒计时和纯数值膨胀。 - 是否让输出密度匹配 mode,而不是每次都写完整大报告。