course-outline-design

课程大纲设计

Schema 权威来源：所有原始字段名（unit / concept / prompt / task / material / quiz / faq / illustration）均来自 _shared/domain-primitives.md。本技能提及字段时，以该文件为准。

文件名约定（英文优先）：所有生成的文件和目录都使用英文名称。旧版中文名称的映射见 _shared/domain-primitives.md §0。

本技能用于生成课程的结构框架：课程有几天、每天的主题是什么、每个单元讲什么、贯穿全程的共同情境是什么，以及元信息（时长、课堂、日程）是什么样。它不负责编写讲课内容——那是 course-content-authoring 的工作。

何时调用

• 用户说“我想举办一场关于 X 的研讨会”，但还没有课程结构。
• 用户有一些零散笔记，想把它们整理成课程。
• 用户想修改现有大纲（添加／删除单元，调整每日安排）。

交付物

标准大纲会生成以下文件。可根据用户的项目调整路径，但要让每个文件的作用各自独立——这种划分能让下游子技能顺利运行。

course-package/   (or your preferred root)
├── overview.md         ← top-level meta + day list + shared scenario summary
├── shared-scenario.md     ← the persistent scenario / fictitious company / characters used across days
├── supporting-docs.md     ← optional: FAQ, pre-reading, environment setup
└── day{n}/
    └── outline.md     ← per-day outline: theme, units, learning goals, hours

这里的文件名采用中文，是因为这是本技能诞生时所在项目的约定。请使用适合项目的语言，但务必将文件作用分开。将 overview.md 合并到每天的大纲中是常见错误——这样一来，元信息更新就需要修改 N 处。

必须确定的五项决策

起草任何文件之前，先确认以下事项（如有必要，可以一次询问用户一项）：

1. 受众和先备知识——这决定了之后每个概念的讲解深度。
2. 总授课时长和天数——例如 4 天 × 6 小时，或 1 天 × 8 小时。这决定单元数量。
3. 共同情境——每场优质研讨会都会有一个反复出现的虚构案例（公司、人物或数据集），将各个单元串联起来。设计单元之前就要确定情境，因为它会渗透到每个单元的示例中。
4. 学习成果动词——学员每天结束时应该能够做什么？使用行动动词（use、build、evaluate），而不是认知动词（understand、know）。
5. 评估形式——前测／后测／测验／作品集？这会影响是否要预留一个单元安排评估。

按文件提供的模板

overview.md（概览）

# {Course title}

## 基本資訊
- **對象**: {audience}
- **總時數**: {total hours} ({days} 天 × {hours/day})
- **上課時間**: {schedule, e.g. 每週三 14:00–17:00}
- **教室**: {location + mapUrl if physical}
- **講師**: {instructor}

## 課程目標
{3–5 outcome statements using action verbs}

## 每日主題
| Day | 主題 | 核心產出 |
|---|---|---|
| Day 1 | ... | ... |
| Day 2 | ... | ... |
...

## 共用案例
{1-paragraph summary of the persistent scenario; full details in shared-scenario.md}

day{n}/outline.md（每日大纲）

# Day {n}: {day theme}

## 學習目標 (action verbs!)
- 能夠 {do X}
- 能夠 {do Y}

## 時程
| 時段 | 單元 | 重點 |
|---|---|---|
| 14:00–14:50 | u-1 {unit title} | ... |
| 15:00–15:50 | u-2 ... | ... |
...

## 單元細部
### u-1: {title}
- **學習目標**: ...
- **任務 (tasks)**: 條列學員實作項目
- **素材需求**: 條列此單元需要的素材檔（給 content-authoring 階段填）

shared-scenario.md

用 1–2 页介绍贯穿全程的虚构情境。内容包括：

• 公司／人物名称（使用不会被误认为真实实体的占位名称）
• 课程要为他们解决的核心问题
• 数据格式示例（列名、文件类型）——这些示例会在测验题目和提示词示例中重复使用

应避免的反模式

• “等内容写完再回来补大纲”——内容编写前必须先确定大纲，因为内容作者会根据大纲中的 ID 来设计每个单元。
• 单元标题只有名词（例如“提示词”）——这样不好，因为标题没有说明学员要做什么。建议使用基于动词的标题（“撰写一份结构化提示词”）。
• 没有共同情境——缺少共同情境时，每个单元的示例都是孤立的，学员也无法看出各种技巧如何逐步叠加。
• 总时长对不上——元信息写着“每天 6 小时”，但时间表只安排了 4.5 小时。务必计算时间表的总时长并核对。

完成门槛（硬性规则——交接前必须通过）

在宣布“大纲已锁定”并建议使用 course-content-authoring 之前，以下每一项都必须有书面记录（不能只口头说“是”）。逐项引导用户完成；如果回答含糊，先提出一个澄清问题，再继续下一项。

1. 受众 + 先备条件——在 overview.md 的 對象 字段中记录为具体句子（例如：“行政部门人员，会用 Excel，但没有编过程序。”）。只写笼统的“新手”不够。

2. 总时数 + 天数——填写 總時數，并确保 每日主題 表格中的天数行数恰好与总天数一致。将每个 day{n}/outline.md 中的时间表时长相加，并确认总和等于每天的课时。

3. 共用案例（可选，但必须明确决定）——二选一：

   • 存在 shared-scenario.md，其中包含具名公司/角色 + 核心问题 + 1–2 种示例数据形态；或
   • overview.md 中包含一行明确说明：本课无共用案例，每单元独立举例。

   没有回应不算通过——必须询问并记录其中一种结果。

4. 学习成果动词——每天的 學習目標 都使用行动动词（use、build、evaluate、design、compare）。知识类动词（understand、know、learn about）不符合要求——请用户改写。

5. 评量形式——在 overview.md 中明确记录（例如：“前测 5 题 / 后测 10 题 / 每日 quiz 3 题”），或明确豁免，并添加一行说明（“本课无评量，以作品集验收”）。没有回应不算通过。

如果用户在 5 项都尚未有书面记录前，就催促说“可以了，先开始写内容”，请礼貌拒绝：

「第 1 阶段还没锁定，后续 content/SPA/visual 任一阶段只要修改 outline，就得连带重做多个文件。先补上第 N 项，大概需要 X 分钟，之后省下的时间不止这些。」

决策时的默认原则（询问，不要假设）

如果用户确实不知道答案，不要提供模板或填入占位默认值——直接问一个简短的问题，然后等待回答。基于错误假设反复沟通，代价比多一轮确认更高。

• 受众未知 → 直接询问：「这堂课是为谁开的？学员来自哪个部门 / 属于哪种角色？他们现在会什么、不会什么？」在收到具体回答前，先不要进入第 2 项。
• 课时 / 天数未知 → 直接询问：「总时数和每天的时段怎么安排？例如『2 天 × 6 小时』或『每周三 14:00–17:00，共 4 周』。」不要提供 1d×6h / 2d×6h / 4d×6h 模板——安排应由用户的日程决定，而不是由我们猜测。
• 尚未决定是否设置共用案例 → 直接询问：「这套课程要不要设置一个贯穿全程的虚构案例（例如一家公司、一个角色，让所有单元的示例都围绕它）？如果需要，我们可以一起设定；如果不需要，就在 overview.md 中写『本课无共用案例』，然后跳过第 3 项。」无论用户选择哪种，都接受，不要强行要求设置案例。

原则：这项技能应通过根据明确回答采取相应行动来保持果断，而不是在没有答复时擅自假设。

交接到下一阶段

只有通过完成门槛后，用户才应具备：

• 一套完整的 outline .md 文件
• 明确的单元 ID 规范（例如 d{n}-u{m}），供内容编写阶段使用
• 已确定的共用案例

告诉用户：“大纲已锁定。从现在起，修改天数或单元 ID 会产生连锁成本——如需修改，请先告诉我。”然后建议接下来调用 course-content-authoring。

修订流程（用户希望修改现有大纲时）

1. 比较变更内容——列出所有受影响的单元 ID。
2. 检查第 3 阶段及之后的内容是否已存在（是否存在 course-data.js？）。如果存在，提醒用户下游文件需要同步更新，并在交接回 teaching-site 时记得再次说明。
3. 按以下顺序更新文件：overview.md（元信息）→ 受影响的 day{n}/outline.md → shared-scenario.md（如果案例有变更）。
4. 单元内容写好后，绝不重命名单元 ID。将其标记为弃用，并使用新的 ID 添加一个新单元。