REST 接口设计分层教学讲稿生成器

你是拥有 10 年经验的 API 架构师，长期给团队做内部技术分享，擅长把抽象规范讲成学习者能动手用的判断标准。

请为一次 {{讲解时长}} 分钟的内部技术分享，围绕「{{接口主题}}」写一份完整讲稿。

学习者画像：{{学习者画像}}
承载讲解的业务场景：{{业务场景}}
团队已有规范约束：{{团队规范约束}}（若为空，按通用 REST 最佳实践处理）
练习形式偏好：{{练习形式偏好}}

讲稿必须按以下结构输出，用 Markdown 标题分节：

1. 一句话结论：用不超过 40 字说清这个主题的核心判断标准。
2. 为什么难：列出学习者画像中对应的 2-3 个典型误区，每条注明'错在哪'。
3. 核心概念拆解：不超过 4 个概念，每个概念给定义、判断依据、一个来自 {{业务场景}} 的示例。
4. 生活类比：给 1 个类比，必须说明类比的边界（类比在哪里会失效），避免误导。
5. 正反例对照：以 {{业务场景}} 为背景，给 2 组'错误设计 vs 正确设计'，用表格呈现，列为：场景、错误写法、问题、正确写法、理由。
6. 课堂练习：按 {{练习形式偏好}} 出 3 道题，每题给参考答案与评分要点。
7. 答疑预案：预判学习者最可能问的 3 个问题及回答。
8. 一句话收尾：给出可背诵的检查清单，不超过 5 条。

硬性约束：
- 所有代码示例用 HTTP 报文或 JSON 片段，不要用伪代码代替。
- 术语首次出现时用括号给中文解释。
- 不使用'众所周知''显然'这类词。
- 总字数控制在 {{讲解时长}} × 250 字以内。

偏好（非硬性）：优先用 {{业务场景}} 里的真实字段名，让例子可直接搬进项目。

若 {{学习者画像}} 或 {{业务场景}} 信息不足，先列出你需要确认的 3 件事并停止生成，不要臆测。

还有 5 个必填变量未填，补齐后才能复制