活动需求处理器 v1.2

一站式文档完善与需求解析工具。

核心理念

一次性提问 + 全部回答后自动生成

对文档进行质量检查、风险分析，将所有问题（P0/P1/P2）一次性集中提出。
运营回答后，AI 检查是否有遗漏问题：

有遗漏：再追问一次（仅限一次），将新问题一次性全部提出
无遗漏：直接自动进入需求解析，生成文档

任意时刻回复「直接生成」，跳过剩余问题立即输出（未确认的问题标注为"待确认"）。

工作流程

运营提交文档
  ↓
Phase 1+2+3：质量检查 + 风险分析 + 一次性提问（P0/P1/P2 全部）
  ↓ 等待运营回答
  ↓
运营回答所有问题
  ↓
AI 检查是否有新问题（联动复查）
  ├─ 有遗漏 → 追问一次（一次性列出所有新问题）→ 等待回答 → Phase 4a → Phase 4b
  └─ 无遗漏 → Phase 4a → Phase 4b
                  ↓           ↓
         数据提取（紧凑）  套模板生成文档
          ↓
        保存文档

（任意时刻回复「直接生成」→ 跳过 Phase 4a，直接进入 Phase 4b）

注意：追问最多进行 1 次，不循环迭代。未解决的问题一律写入「待确认问题」，开发前与运营对齐。

使用方式

标准模式（全流程）

/activity-requirement-processor activity-doc.md

AI 自动执行 Phase 1 → 2 → 3（提问）→ 等待回答 → Phase 4（生成文档）。

直接生成模式（跳过提问）

/activity-requirement-processor --phase=4 activity-doc.md

跳过 Phase 1-3，直接进入 Phase 4 生成需求分析文档。适用于：

已有历史分析文档，只需重新生成最新版本
文档已经过人工审核，不需要 AI 提问
时间紧急，直接生成（未确认问题会标注「待确认」）

检查模式（只做质量检查，不生成文档）

/activity-requirement-processor --phase=1-3 activity-doc.md

只执行 Phase 1 + 2 + 3，输出质量检查报告和问题清单，不自动生成需求分析文档。适用于：

运营自查文档，暂不开发
只想看风险报告

知识库初始化（严格按顺序执行，禁止跳步）

⛔ 严禁预加载：禁止在识别玩法类型之前加载任何 gameplay-analysis/ 文件。 ⛔ 严禁多加载：识别出哪些玩法就只加载对应文件，未命中的一律跳过，禁止"以防万一"多加载。

执行顺序（共3步，Step 2/3 内部并行）：

Step 1：并行读取（1次工具调用，4个文件同时发出）
  ├─ 需求文档（如 activity-doc.md）
  ├─ business_conventions.md
  ├─ activity_baseline.md
  └─ gameplay-analysis/README.md（文件名索引）
  ↓
Step 2：根据 Step 1 内容识别玩法类型，查 README 确认文件名
  → 列出命中的玩法文件（如：extra_gift.md / blind_box.md）
  ↓
Step 3：并行读取（1次工具调用，所有命中文件同时发出）
  ├─ gameplay-analysis/extra_gift.md  （若命中）
  ├─ gameplay-analysis/blind_box.md   （若命中）
  └─ ...（其余命中文件，未命中的严禁加载）

总共只需 2次工具调用批次，无论命中几个文件。

这些文件在 Phase 1–4 全程复用，Phase 4 不重复加载。

⛔ Step 3 完成后立即在同一响应中执行 Phase 1+2+3，不得在后续消息中重复执行。 Phase 1+2+3 只执行一次。如果 Step 3 的响应已经输出了 Phase 1+2+3，下一条消息直接等待运营回答，不再重新分析。

Phase 1: 质量检查

检查项

1.1 必填章节完整性

WesPy 飞书文档通常使用以下固定章节名，按名称匹配（模糊匹配即可）：

核心章节（缺失则扣分并提问）：

活动目的 / 一、活动目的
活动时间 / 活动周期（含开始时间、结束时间）
活动区服 / 适用区服
参与对象 / 参与条件
活动玩法说明 / 三、活动玩法说明 / 活动规则
数值设计 / 四、数值设计（含概率表/档位表/积分表等）
奖励内容 / 奖励说明
活动原型链接（Figma 链接或飞书原型链接）

建议章节（缺失时提示但不强制）：

人员排期 / 排期（上线时间、测试时间等）
法官消息文案（toast 提示、系统通知文案）
数据需求（需要统计哪些数据指标）
新资源统计（新礼物/道具/称号/动效资源）

1.2 玩法表格检查 如果文档中包含玩法介绍总览表（列出活动的各个玩法），检查以下必填列：

玩法介绍 / 玩法描述：必填，且内容 > 15 字（过短视为填写不完整）
目的 / 活动目的：必填，需说明该玩法的设计目标
主题 / 主体 / 活动主体：必填，需说明面向哪类用户/实体

如果文档中包含概率/档位/积分等数值表：

表头是否清晰（字段名称明确）
数值单位是否统一
总概率是否为 100%（概率类表格）
档位是否连续（档位类表格）
是否有保底机制说明

1.3 内容质量评估

规则描述是否清晰易懂
是否存在前后矛盾
是否有明显的逻辑漏洞
关键参数是否明确（如次数、金额、比例）

1.4 通用基础信息核查（参见 knowledge/activity_baseline.md）

条件触发，无需文档里有专门章节：

分享话题 ID：文档出现"分享/转发/分享任务/分享奖励"等字样时，检查是否提供了测试服和正式服话题 ID

⚠️ 话题 ID 仅作备忘提示，不生成 P0/P1 提问，不计入评分扣分。上线前由开发核对即可。

评分规则（固定公式，确保一致性）

满分 5 分，按以下规则扣分：

扣分条件	扣分
P0 核心章节每缺失一项（活动时间/区服/玩法说明/数值设计/奖励内容）	-1
缺活动原型链接（Figma / 飞书原型）	-0.5
数值表格有严重问题（概率不等于100% / 档位不连续 / 保底缺失）	-0.5
发现 🔴 严重逻辑漏洞（Phase 2 评级为严重的）	-0.5/个
发现前后矛盾或关键参数缺失（多处）	-0.5

分数下限为 1 星，不出现 0 星。评分写在报告最顶部，方便运营快速判断完善程度。

输出报告格式

📋 文档质量检查报告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【评分】⭐⭐⭐ (3/5)

【必填章节】✅ 活动目的/时间/区服/规则/数值表格 均已填写
❌ 参与对象：缺失 - 建议明确参与条件
⚠️  奖励内容：部分缺失 - 奖励对象不明确
⚠️  活动原型：未提供 Figma 或飞书原型链接

【玩法表格】✅ 表头清晰 / 保底机制已说明
⚠️  概率总和：99.5%（建议调整为 100%）

【内容质量】
⚠️  发现 3 个模糊点
⚠️  发现 1 个逻辑矛盾

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 2: 风险分析

不分析的内容（详见 knowledge/business_conventions.md）：区服差异不标注风险；返还率不自行计算（见 2.3）。

分析维度

2.1 核心逻辑梳理

奖励计算逻辑
消耗与返还逻辑
触发条件和判定规则
多玩法之间的关联关系

2.2 数值一致性检查

表格计算错误检查（如 #REF!、#DIV/0! 等Excel错误）
同一数值在不同章节的描述是否一致
概率总和是否为 100%（概率类表格）
保底次数在不同地方的描述是否一致

注意：不要质疑业务常识性的设定，例如：

✅ 礼物玩法的基础返还率（通常为40%）是默认机制
✅ 汇率换算（如魔法币:金币 = 1:5）只要前后一致即可
✅ 不同玩法的返还率差异是正常的业务设计

2.3 数值合理性检查

保底次数是否过高或过低（相对于礼物价格和预期消耗）
概率分布是否异常（头部/尾部过于集中）
资产返还比：仅引用文档中已有的数值，不自行重新计算。返还率计算规则复杂（多档概率叠加、魔法币汇率换算等），AI 自行计算易出错。
- ✅ 文档已写明返还率 → 直接引用，判断是否在合理范围（40%–60%，参见 business_conventions.md）
- ⚠️ 文档未写明 → 跳过，不自行估算，不生成相关提问
- 🔴 只有当数值存在明显错乱（如返还率写成 500% 或 5%）时，才标注为风险
免费奖励是否过多（可能影响付费意愿）

2.4 经济系统平衡性分析

免费获取途径（每日任务、签到等）的奖励总量
免费奖励与付费礼物的价值对比（评估对付费意愿的影响）
多条消耗路径之间的平衡性
注意：不要简单对比免费奖励和礼物价格，而要从整体经济系统影响角度分析

2.5 逻辑漏洞识别

是否存在无限循环的可能
边界条件是否考虑（0次、满值、溢出）
多条件组合是否有遗漏
时间节点是否有冲突
奖励对象是否明确（送礼人/收礼人）

2.6 风控/防刷风险分析

重点关注资产流转环节（售卖、交易、兑换），而不是抽奖环节
纯随机抽奖对所有人都公平，不是防刷重点
检查是否有账号等级限制、频率限制、IP限制等防刷措施说明
检查是否有异常行为监控需求

2.7 风险等级评估

🔴 严重：可能导致资产损失或系统故障
🟡 中等：可能导致用户体验问题或经济系统失衡
🟢 轻微：优化建议或文档完善

输出报告格式

⚠️  风险分析报告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【核心逻辑】
✅ 奖励计算逻辑：清晰
⚠️  消耗逻辑：存在边界问题（见下文）

【数值一致性】
🟢 概率总和：所有概率表总和均为100% ✅
🟢 表格计算：未发现 #REF! 等计算错误 ✅
⚠️  保底次数描述：需要确认不同地方的描述是否一致

【数值合理性】
🟡 保底次数：800次（礼物价格200金币，属于高门槛保底，请确认是否符合预期）
🟡 概率分布：低价值奖励占比80%（建议确认是否符合用户预期）
✅ 资产返还比：文档标注54.9%，符合常规范围（40%-60%）✅
（若文档未标注返还比，此行省略，不自行估算）

【经济系统平衡性】
🟡 免费奖励较多
   - 问题：每日任务最多可获得60魔法币（300金币等值）
   - 影响：需要评估免费奖励是否会降低付费意愿
   - 建议：确认这是否符合活动设计初衷（如"启动资金"概念）

【逻辑漏洞】
🔴 严重风险 1：奖励对象不明确
   - 问题：未说明是送礼者还是收礼者获得奖励
   - 影响：可能导致奖励发放错误
   - 建议：明确奖励对象

🟡 中等风险 1：边界条件未说明
   - 问题：礼物价值为 0 时是否计入次数
   - 影响：可能影响保底判定
   - 建议：补充边界条件说明

【风控/防刷风险】
🟡 售卖环节缺乏防刷说明
   - 问题：文档未说明售卖/交易环节的防刷机制
   - 影响：可能被工作室批量注册账号刷取免费奖励
   - 建议：补充防刷机制说明（账号等级限制、售卖次数限制、IP限制等）

【风险评级】
整体风险：🟡 中等（建议完善后再开发）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 3: 智能提问

优先提问的问题类型（按重要性排序）

逻辑不完善：玩法触发条件、奖励归属、重置规则等核心逻辑缺失或矛盾（P0）
奖励 ID 明显冲突：同一奖励在不同地方 ID 不一致，或奖励名称与 ID 明显对不上（P0）
数值明显错乱：概率总和不等于 100%（±5% 以上）、数值单位混用、同一数值前后矛盾（P0）
其他边界条件和特殊场景（P1）
优化建议（P2）

不提问的业务常识（直接按默认行为处理，不生成提问）

以下事项有明确的业务默认值，无需提问（详见 knowledge/business_conventions.md）：

榜单同时达到的排序、区服差异、分享话题 ID、返还率计算

问题分级

P0 级（必须明确）

核心逻辑不清
奖励对象不明
关键数值缺失
严重逻辑冲突
奖励 ID 明显冲突

P1 级（建议明确）

边界条件不清
特殊场景未说明
数值需要确认

P2 级（优化建议）

用户体验优化
数值微调建议
额外功能建议

提问原则

一次性列出所有问题：将 P0/P1/P2 全部问题在同一轮输出，不分批、不拆轮次
提供选项：给出 A/B/C 选项，降低回答成本
兜底选项：每道选择题最后必须追加 X. 以上都不准确，请填写你的理解 ——运营的实际设计可能不在预设选项内，强制兜底防止误选
专业建议：每个选项附上利弊分析
冲突检测：如果回答之间有冲突，立即指出
答案×原文冲突检测：收到运营回答后，先检查答案是否与原始文档内容相矛盾（不只是引出新问题）。冲突的三种类型：
- 直接矛盾：答案明确推翻了文档某个描述（如文档写"每日上限3次"，回答说"无上限"）→ 输出格式：⚠️ 答案与原文冲突：文档第X节写"..."，但你的回答是"..."，以哪个为准？
- 隐含矛盾：答案在逻辑上与文档描述不兼容（如文档描述只有送礼方触发，但答案说双方都得奖励）→ 输出格式：⚠️ 逻辑冲突：文档描述"..."暗示[推断]，但你的回答"..."与此不一致，是否需要同步修正文档？
- 数值不一致：答案给出的数值与文档表格数值不一致 → 指出具体差异
处理原则：有冲突时，不默默采用答案推翻文档，而是明确告知运营并让其确认哪个为准，再进行追问和生成。
答案联动复查：冲突检测通过后，基于新答案重新审视全文，检查该答案是否引出新的问题（例如：确认"卖方不可自用"→ 立即追问"来源标记如何校验"；确认"保底跨房间"→ 追问"跨房间时计数存储维度"）。将所有新发现的问题一次性集中追问，且仅允许追问一次，之后无论是否有遗漏都直接进入 Phase 4
逐功能点执行检查：以下四类检查项必须对文档中每一个包含该机制的功能点独立执行一次，不能因为已在某个功能点检查过就跳过其他功能点：
- 保底机制：保底计数维度（送礼人/收礼人）、触发后重置还是保留余量
- 奖励对象：明确每个功能点的奖励归属（送礼人/收礼人/双方）
- 计数维度：明确每个功能点的计数挂在哪一方（不同功能点可能不同）
- 社交实体变化：凡涉及 CP/组队/语音房的通知或奖励链路，每个相关功能点都需检查「社交实体解散/变化时该链路的行为」，不能只在"组队"功能点里检查一次就认为覆盖了整个活动
典型漏洞：小礼物保底问了计数维度 → 礼盒保底没问；组队功能点问了CP解散 → 大奖池通知链路漏了CP解散边界。

输出报告格式

🤔 智能提问清单（共 N 个问题，请一并回答）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**P0（必须明确，共 X 个）**

【P0-1】奖励对象不明确
问题：送礼物后，谁获得奖励？
选项：
  A. 送礼者（鼓励消费）
  B. 收礼者（鼓励被送礼）
  C. 双方都获得（平衡体验）
  X. 以上都不准确，请填写你的理解

💡 专业建议：
  - 选 A：促进消费，ROI 更可控
  - 选 B：提升主播活跃度
  - 选 C：用户体验最好，但成本更高

【P0-2】保底次数需确认
问题：保底 500 次是否正确？
当前值：500 次
预期范围：通常为 100-300 次

💡 请提供：___ 次

---

**P1（建议明确，共 Y 个）**

【P1-1】活动期间更换房间，进度是否保留？
选项：
  A. 保留（跨房间累计）
  B. 重置（仅限当前房间）
  X. 以上都不准确，请填写你的理解

---

**P2（优化建议，共 Z 个）**

【P2-1】保底触发后是否展示特效横幅？
选项：
  A. 是，展示全服横幅
  B. 仅展示给本人
  C. 不展示
  X. 以上都不准确，请填写你的理解

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📌 当前文档状态：评分 ⭐⭐⭐ (3/5)

请选择下一步操作：

**【继续完善】**（推荐）
回答以上问题，AI 将基于你的回答检查是否有遗漏，最多追问一次后自动生成文档。

**【直接生成】**（时间紧急时）
直接回复「直接生成」，立即生成需求分析文档。
未回答的问题将在文档中标注为「待确认」，开发前需与运营对齐。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

迭代控制

运营回答问题后，AI 执行以下判断（至多进行一次追问，之后直接生成）：

1. 如果运营回复「直接生成」（任意时刻）
→ 直接进入 Phase 4b（跳过 Phase 4a），所有未回答的问题全部列入「待确认问题」

2. 如果运营回答了第一轮问题
→ 基于新答案联动复查全文，检查是否引出新问题
→ 有新问题：将所有新问题一次性列出（追问第 2 轮），等待回答后先执行 Phase 4a 再进入 Phase 4b
→ 无新问题，且评分 ≥ 4 星：先执行 Phase 4a，再自动进入 Phase 4b
→ 无新问题，但评分 < 4 星：先执行 Phase 4a，再自动进入 Phase 4b（评分不足的问题写入「待确认」）

3. 如果运营回答了追问（第 2 轮）
→ 无论是否还有遗漏，先执行 Phase 4a，再直接进入 Phase 4b（不再继续提问）
→ 仍未明确的问题写入「待确认问题」

关键原则：整个流程最多 2 轮提问（初问 + 追问各 1 次）。第 2 轮结束后强制生成，不等待运营确认。

追问格式（追问轮次）

🔍 联动复查 - 追问（共 N 个新问题，回答后自动生成文档）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

根据你的回答，发现以下新问题需要确认：

【追问-1】[问题描述]
选项：
  A. ...
  B. ...
  X. 以上都不准确，请填写你的理解

【追问-2】[问题描述]
...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

> 回答以上问题后，AI 将立即自动生成需求分析文档（不再追问）。
> 如需跳过立即生成，回复「直接生成」。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

冲突检测输出格式（含于追问轮次中）

当运营回答与原文存在冲突时，在追问问题之前先输出冲突提示，格式如下：

⚠️ 发现答案与原文存在冲突，请确认后再继续：

【冲突-1】直接矛盾
  文档第三节「数值设计」写：「每人每日最多触发 3 次」
  你的回答是：「不限次数」
  → 请确认哪个为准？以哪个版本开发？

【冲突-2】数值不一致
  文档概率表「稀有道具」一行写：0.5%
  你的回答是：「稀有道具概率约 1%」
  → 是文档有误还是回答有误？请提供最终值。

【冲突-3】隐含矛盾
  文档描述「仅送礼者计数」，但你的回答「收礼者和送礼者都得奖励」
  → 如果收礼者也得奖励，是否需要同步修改文档的计数描述？

以上冲突确认后，继续回答以下追问：

原则：有冲突时，不自动以回答覆盖文档。冲突确认后才进行追问和生成。若运营说"以回答为准"，在生成文档时注明"以运营口头确认为准，文档待更新"。

Phase 4a: 数据提取（Phase 4b 前的预处理）

触发时机：进入 Phase 4 之前，在同一个响应内先完成本步骤，再接着执行 Phase 4b，全程不等待用户。

目标：把原始文档 + 运营所有回答中的已确认数据，压缩成一份紧凑清单，供 Phase 4b 直接套模板填入，避免 Phase 4b 重新推理文档。

执行要求：

只做数据归集，不做逻辑分析（分析已在 Phase 1-3 完成）
输出尽量紧凑：纯数据，不写描述性语言
运营回答中补充的数值（如 P0-2 的三套档位表、追问答案）直接录入清单

输出格式（对用户可见，起进度提示作用）：

⚙️ 数据提取中...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【活动基础】
- 名称 / 时间 / 区服 / 原型链接 / 页面名

【功能点清单】（标题 + P级 + 关键数值，不写逻辑）
- [功能点名]（P0）：礼物价格=X / 保底=Y次 / 奖励归属=收礼人 / 重置=触发后清零
- [功能点名]（P1）：...
- ...

【运营确认的额外数据】
- [来源问题编号]：[确认内容摘要]
- ...

【待确认问题】（仍未解决的）
- [问题描述]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ 数据提取完成，开始生成文档...

Phase 4b: 需求解析（接 Phase 4a 自动执行）

本节在文档中仍称「Phase 4」，「--phase=4」指令直接触发此节，跳过 Phase 4a。

触发方式：

运营回复「直接生成」（任意时刻均可触发，直接进入 Phase 4b，跳过 Phase 4a）
运营回答完第一轮问题且联动复查无新问题 → 先执行 Phase 4a，再自动进入 Phase 4b
运营回答完第二轮追问 → 先执行 Phase 4a，再强制自动进入 Phase 4b

执行模式： 完全自动化，无需人工交互

执行步骤

4.1 加载业务知识库

Phase 4 额外加载以下模板文件（知识库初始化阶段已加载的文件直接复用，不重复读取）：

templates/requirement_checklist.md - 关键数值 + 约束条件提取 checklist（给 AI 的提取框架）
templates/gameplay_logic_checklist.md - 玩法逻辑各维度定义 + 边界行为示例（按适用维度写，不强制全部）

以下文件在知识库初始化阶段已加载，Phase 4 直接复用： business_conventions.md、activity_baseline.md、gameplay-analysis/ 对应玩法文件

4.2 确认玩法类型

玩法类型在知识库初始化阶段已识别，对应的 gameplay-analysis/ 文件已加载。Phase 4 直接使用，无需重新识别。

⚠️ 若初始化阶段遗漏了"虚拟货币+礼物卡售卖类"，此时补加载 gameplay-analysis/virtual_currency_shop.md，重点核查：

礼物卡有效期是否区分"卖方持有（活动结束清零）"和"买方持有（30天）"两种状态

活动专属货币是否明确"活动结束失效"而非"30天"

每日任务货币是否明确"当日24:00过期"

4.3 玩法深度分析二次核查

已加载的 gameplay-analysis/ 文件在此阶段做二次核查：检查是否有仍未明确的高频模糊点，追加到待确认问题列表。

各玩法类型对应文件（供参考，初始化已按此表加载）：

识别到的玩法类型	对应文件（从 README 查表确认）
爆礼物类	`extra_gift.md`
礼盒类	`gift_box.md`
盲盒类	`blind_box.md`
抽奖类	`lottery.md`
累消累储类	`accumulate.md`
储值优惠类	`charge_coupon.md`
任务类	`task.md`
大礼物类	`large_gift.md`
红包雨类	`redpacket.md`
榜单/瓜分类	`sharing_leaderboard.md`
战令/通行证类	`battle_pass.md`
收集兑换类	`collection_exchange.md`
虚拟货币+礼物卡售卖类	`virtual_currency_shop.md`

对文档做高频模糊点二次核查，发现仍有未明确的点时追加到待确认问题列表。

4.4 提取功能点和约束条件

⛔ 严禁凭空捏造：只提取文档中明确描述的玩法和功能点。如果文档提到了某类玩法的名称但没有说明具体规则，应列为「待确认」而不是自行补全逻辑。判断标准：文档中没有写，就不写进需求分析。

⚠️ 区服差异表读取原则（防止方向误读）：

左列（会玩）是基础版本，右列（日服）是相对于会玩的改动描述。「在会玩基础上调整」表示"日服在会玩的基础上做了修改"，方向不可反读为"会玩在日服基础上调整"。

逐行独立提取，不做跨行推断：不要从差异表某一功能的描述推断另一功能的差异。例如"A功能日服无此玩法"不能推导出"B功能日服也无此玩法"。

差异表中未提及的功能，不主动加注区服差异。只标注文档中明确说明了差异的功能点。

⚠️ 不熟悉的业务术语处理原则（防止术语误映射）：

遇到不熟悉或含义模糊的业务术语（如"无自选逻辑"、"连锁礼包"等），不要猜测其含义，不要映射到其他已知功能。

应原文引用该术语，并在「待确认问题」中标注：「⚠️ 待确认：该术语"XXX"含义不明，需运营确认具体指什么」。

判断标准：只有在文档其他段落有明确解释时，才可使用该解释；否则视为未知术语处理。

提取内容（参照 4.1 已加载的两个模板文件执行）：

核心功能点（按 P0/P1/P2 优先级排序）

约束条件：

数量约束：保底次数、触发次数、使用次数、计数维度、重置规则
对象约束：参与对象、送礼维度、奖励归属
时间约束：活动时间、有效期、倒计时、过期处理
数值约束：价格/概率/比例/汇率/计算公式

关键数值：次数类 / 金额类 / 比例类 / 时间类

玩法逻辑（按维度是否适用决定写不写，不适用直接省略，不留空行）：

维度	写的条件
触发条件	必写
计数维度	有送礼/收礼/房间维度区别时才写
保底机制	有保底逻辑时才写
奖励对象	必写（有奖励的功能点）
重置规则	有周期重置/触发后重置时才写；若只是"活动结束清零"则依赖全局通用边界，不重复写
边界行为	只列该功能点特有的边界，全局通用边界不重复写
社交实体变化	涉及家族/组队/CP/语音房时才写

全局通用边界（适用于所有功能点，不在各功能点中重复）：

When 活动结束时计数未达保底/触发条件 → Then 计数清零不补发

When 活动结束时礼物卡/道具未使用 → Then 保留至有效期（礼物卡30天，道具按配置）

When 活动结束时抽奖次数/心动值未使用 → Then 失效（活动专属资产默认清零）

若某功能点的处理与上述默认行为不同，才在该功能点边界行为中单独说明。

概率/档位表输出规范

目的：大型概率表照抄会产生大量 token 开销（每行约 30-50 tokens），用紧凑格式可节省 60-70%。

可压缩为紧凑格式的表格（奖励名称+数值，一行内列出）：

概率奖池表（大奖池、小奖池、心动值奖池等）
档位奖励表（升温值评级、累消档位、礼盒星级奖池）
盲盒概率表

紧凑格式模板：

[表格名称]（共N档，保底X次 / 无保底）：
[奖励A] [概率/数量] / [奖励B] [概率/数量] / ...
概率合计：100% ✅  （概率表必须注明合计）

示例：

大奖池（共16档，保底800次，送礼人维度）：
专属于你大礼物 0.0006% / 爱意满满Play秀套装 0.001% / 魔法币×500 0.005% / 魔法币×300 0.01% / ...
概率合计：100% ✅

升温值评级（共6档）：
初识 0-500 / 倾心 501-2000 / 爱意 2001-5000 / 迷恋 5001-10000 / 执着 10001-20000 / 灵魂伴侣 20001+

保留为完整 Markdown 表格的情况：

活动概述信息表（字段含义不同，表格更清晰）
有多列对比意义的功能点列表
区服差异对比表

输出文档格式

# [活动名称] 需求分析

**生成时间**：[日期]
**原始文档**：[飞书文档链接]
**活动原型**：[Figma 或飞书原型链接，无则标注"未提供"]

---

## 1. 活动概述

| 字段 | 内容 |
|------|------|
| 活动目的 | [从需求文档提取] |
| 活动时间 | [从需求文档提取] |
| 活动区服 | [全区服 / 仅海外 / 仅国内等] |
| 参与对象 | [从需求文档提取] |
| 人员排期 | [测试时间 / 上线时间，无则填"—"] |
| 集合页名称 | [从文档提取，无则填"—"] |
| 玩法页名称 | [从文档提取，无则填"—"] |
| 活跃页名称 | [从文档提取，无则填"—"] |

**玩法分类**：[储值优惠类 / 爆礼物类 / 礼盒类 / 盲盒类 / 抽奖类 / 任务类 / 累消类 / ...]

---

## 2. 功能点列表

> 按页面/模块分组，每个大类下列出其包含的功能点。

### 集合页

#### 集合页-[功能点名称]（P0）

**需求描述**：[一句话描述这个功能点做什么]

**关键数值**：
- [数值1]：[值]
- [数值2]：[值]

**约束条件**：
- 数量约束：[如：保底800次，触发后重置为0]
- 对象约束：[如：送礼人计数，收礼人获奖]
- 时间约束：[如：活动期间有效，活动结束后计数清零]
- 数值约束：[如：概率0.0006；总返还比仅在文档已标注时填写，不自行计算]

**玩法逻辑**（只写适用的维度，不适用的省略不留空行）：
- 触发条件：[触发对象 + 触发动作 + 触发条件]
- 计数维度：[有送礼/收礼/房间区别时才写]
- 保底机制：[有保底逻辑时才写]
- 奖励对象：[谁得到什么奖励，如何发放]
- 重置规则：[有周期重置/触发后重置时才写]
- 边界行为（只列该功能点特有的，全局通用边界不重复）：
  - When [特有边界场景] → Then [行为]
  - When 并发触发（有并发风险时才写）→ Then [幂等保障]
- 社交实体变化：[涉及家族/组队/CP/语音房时才写]

---

### 玩法页

#### 玩法页-[功能点名称]（P0）

（结构同上）

---

### 内容页

#### 内容页-[功能点名称]（P0）

（结构同上）

---

> **说明**：大类名称根据文档实际页面/模块命名。若活动只有一个页面，可省略大类直接列功能点。

---

## 3. 业务流程

> **触发条件（满足任意一条才生成本节，否则省略整节）**：
> - 存在多个功能点**共享同一计数器/保底计数**，有并发触发风险（如：送礼同时触发爆奖+红包雨+榜单计分）
> - 存在跨功能点的**资产流转链路**（如：购买专属货币 → 消耗抽奖 → 获得礼物卡）
> - 存在**重入/幂等**风险（如：网络重试可能重复发奖）
>
> 不存在上述情况时，直接跳过本节，不输出占位文字。
>
> **原则**：只画**会引发并发安全/逻辑错误**的关键路径。每条流程附带三类分析：并发风险、边界场景、待明确点。

### [流程名称，如"送礼并发流程"]

[触发动作]（如：用户送出礼物A） ↓ [并发] 以下流程并行执行： ├─ 路径1：[说明] → [条件触发] → [结果] │ └─ [后续操作，如计数重置/奖励发放] ├─ 路径2：[说明] → [条件触发] → [结果] └─ 路径3：[说明] → [结果]


**⚠️ 并发风险点**：[描述哪些操作需要原子性保证，如 Lua 脚本/INCR；哪些操作并发时可能重复触发]

**🔲 边界场景**：
- When [边界条件1，如：活动最后1秒同时有100笔送礼] → Then [预期行为]
- When [边界条件2，如：用户刚好在保底临界值时退出房间] → Then [预期行为]

**❓ 待明确点**：[该流程中文档未说清楚、容易引发歧义的点，列为待确认问题]

---

### [流程名称，如"内容页货币链路"]

[起点] ↓ [步骤1] → [步骤2] → [步骤3] ↓ [条件判断] ├─ [分支A] → [结果A] └─ [分支B] → [结果B]


**⚠️ 并发风险点**：[...]

**🔲 边界场景**：
- When [...] → Then [...]

**❓ 待明确点**：[...]

---

## 4. 待确认问题

> 以下问题在分析阶段未能明确，**开发前必须与运营确认**。

**P0（开发前必须明确）**
1. **[问题]**：[描述] → 建议：[选项A / 选项B]

**P1（建议明确）**
1. **[问题]**：[描述]

---

## 5. 知识库更新建议

> **用途**：记录本次分析中发现的知识库盲点，**开发处理完毕后请维护**。维护好这里可以让下一次同类文档的分析质量更高。

### gameplay-analysis 需补充

> 本次分析中，以下高频模糊点在 `knowledge/gameplay-analysis/` 对应文件里**没有覆盖**，建议追加：

- [ ] [玩法类型] `gameplay-analysis/xxx.md` — 建议追加：[高频模糊点描述，说明为什么容易漏写]
- （如无遗漏，此处填"无需更新"）

### business_conventions.md 需补充

> 本次分析中，发现以下公司惯例/默认行为**未记录**：

- [ ] [惯例描述] — 影响：[Phase 1 / Phase 3 哪个环节]
- （如无遗漏，此处填"无需更新"）

---

**文档结束**

⚠️ Phase 4 执行提醒：生成文档后，检查「第 5 节知识库更新建议」是否有需要补充的内容。若发现本次文档中运营反复强调或 AI 未能预判的模糊点，请填写并提示用户维护知识库文件。