study-plan git:20260901.401e1ecB

Immutable. This exact content is served forever at /api/v1/blob/c99086c1c62420b8.

---
name: study-plan
license: Apache-2.0 (adapted from anthropics/claude-for-legal, law-student/skills/study-plan + law-student/skills/session; complete terms in LICENSE.txt)
description:
  制定/更新长期学习计划——分阶段、按薄弱程度分配学习时间、每天的学习安排，
  并且根据实际练习结果自适应调整；也支持跑一次聚焦N题/N卡片的学习小节，
  把结果记入计划。Use when 用户说"帮我做个学习计划""安排一下复习进度"
  "这门课/这场考试该怎么复习""来10道题练一下并更新我的计划"，或想知道
  "今天该学什么""进度怎么样"。
metadata:
  origin: 阶段划分方法(学习期/刷题期/复习期)、按薄弱程度加权分配时间、
    生活约束现实性核验(强制询问)、备考课程"补充vs替代"二选一决策、
    冲刺模式(临近考试<4周)、session_history 自适应调整机制，
    改编自 anthropics/claude-for-legal 的 law-student/skills/study-plan 与
    law-student/skills/session（Apache-2.0）；已移除全部美国司法考试
    (NCBE/NextGen/UBE/MBE/MEE)相关内容，替换为通用的考试/学期备考场景
---

# Skill: study-plan

坐下来学习却不知道该学什么，是几周时间悄悄溜走的常见原因。这个技能负责
搭一份计划——距考试还有几周、每天几节课、每周哪些学科、用什么方法——然后
根据用户实际完成的练习结果动态调整。是一份活的计划，不是一次性的日历
导出。

它也给 `flashcards`、`weak-point-drill`、`outline-builder` 这些技能提供
一份共享的进度记录，这样用户每次打开对话不用被反复问"今天想学什么"。

## 置信度纪律

计划是判断，不是教条。清楚标出哪些是估算：

- **每个知识点的时间估算**是一般性参考（基于典型的学习节奏），标注为
  估算——用户实际的学习速度会不一样。
- **学科权重分配**来自用户自己报告的薄弱环节和实际练习记录，这部分有
  把握。
- **冲刺模式下的高频考点优先级**基于"哪些内容历史上更容易考/更基础"这类
  一般性经验，任何"这个肯定会考"的说法都要标 `[不确定——历史频率不是
  预测]`。

## 工作流程

### 第一步：明确是为什么做计划

> 我们是为什么制定这份计划？
>
> 1. **一场具体的考试**（有明确日期，比如期末考、资格考、语言考试）
> 2. **一段学期/学习周期的整体节奏**（背诵、刷题、复习交替进行，没有单一
>    的终点考试）

按用户的回答确定锚点日期。

### 第二步：逐项收集信息，一次问一个，等回答

**逐个问，等回答。** 不要一次性把所有问题堆在一起丢给用户。

- **考试日期：** 确认了吗？
- **要覆盖的学科/知识点：** 参考大纲/教学计划，和用户确认"有没有要加/去掉
  的"。
- **最擅长的学科：** 优先级最低，仍然复习，但不用重点刷题。
- **最薄弱的学科：** 优先级最高，分配更多学习小节。
- **每周能投入的小时数：** 要现实，不要理想化。"我能做20小时"和"我能连续
  8周每周做20小时"是两回事，问用户实际能维持多久的强度。
- **生活约束现实性核验——必须问，不能跳过。** 用户给出小时数之后，问
  （一次一个问题，不要跳）：

  > 你说每周[N]小时。在我搭计划之前，说说你这周还有什么安排——工作/上课
  > (每周几小时)、家庭(带娃、照顾家人)、通勤、锻炼、其他占用时间的事。
  > 计划应该适配你的生活，而不是反过来。一个跟不上的计划，比一个轻一点
  > 但能坚持下来的计划更糟。

  等用户回答，再核对这个小时数现不现实：

  > 这相当于每个学习日[X]小时，算上[工作/家庭/通勤/其他]。按我的经验这
  > [现实/偏紧/不现实]。要不要在我搭计划前调整一下每周小时数目标，还是
  > 先按这个来，看第一周实际情况再说？

  即使用户之前已经说过一个目标小时数，这一步也不能跳过——之前说的是
  "想要多少"，这一步核实的是"能不能坚持"。如果核实后数字更低，用更低的
  数字搭计划，并在 `confidence_flags` 里记下这次调整。

  如果用户拒绝聊生活细节（"直接搭就行"），尊重这个选择，但加一条
  `confidence_flags`："未做生活约束核验；计划假设每周[N]小时可持续，
  如果第2周结束时执行率低于[X]%，重新评估。"
- **偏好的学习方式：** 多选。刷题/论述/记忆卡片/搭大纲/定向练习/重读材料。
  按用户说的实际会去做的方式来分配安排，而不是理论上最优但用户不会执行
  的方式。
- **每周休息天数：** 休息日很重要。排满7/7天的计划通常撑不过第三周。

### 第二步半：如果用户在跟一门现成的备考课程/教材体系

如果用户已经在跟一套现成的备考课程（网课、教材配套计划表等），这套计划
本身就有一个逐日的安排。这个技能的计划必须在两个角色里选一个——不能在
不把用户拖垮的前提下和现成课程并行跑两套完整课程。

问一个问题，等回答：

> 你说在跟[课程/教材]的进度表。这份计划可以扮演两种角色，选一个：
>
> 1. **补充。** 现成课程是主线，这份计划只负责补：薄弱学科额外加练习、
>    定向出题、记忆卡片循环。不重建现成课程的日程表，只是叠加在上面。
> 2. **替代。** 不跟现成课程的进度表了（可能因为节奏不适合你的生活），
>    这份计划从头搭完整安排——学科、时间、阶段、日程，你放下现成的
>    进度表。
>
> 不要两个都选。两套完整课程互相打架，是很多人在第4周崩掉的原因。

等回答，记入计划：`prep_course_mode: 补充 | 替代`。

如果选**补充**：日程安排更轻——只加薄弱学科的定向练习，不重复现成课程
已经覆盖的内容。在 `confidence_flags` 里标注："补充模式——这份计划假设
你在跟[课程]的主线进度，如果落后了告诉我，我们重新规划。"

如果选**替代**：按下面的完整流程搭计划。

如果用户没有跟任何现成课程，跳过这一步。

### 第三步：搭日程

从今天到考试日期算出剩余周数，然后：

**正常模式（距考试4周以上）：**
- 按阶段划分：
  - **学习期**（前~60%时间）：每3-5天一个学科，搭大纲/读材料为主，
    穿插记忆卡片和少量练习。
  - **刷题期**（接下来~30%）：加大练习量，各学科轮换，逐步接近考试
    的真实条件（限时、闭卷等）。
  - **复习期**（最后~10%）：聚焦练习记录里显示的薄弱子知识点，做一两次
    完整模拟，强项轻量回顾即可。
- 按薄弱程度分配时间：薄弱学科分到的时间大约是强项学科的2倍。
- 按天排：哪个学科、用什么方法、多长时间。给用户实际生活留出余量。

**冲刺模式（距考试不足4周）：**
- 明确告知："距考试不到4周了，这是冲刺模式——计划会优先覆盖高频/基础
  内容而不是全面覆盖，会留一些盲区，这是这个阶段的取舍。"
- 二八原则：历史上更常考、更基础的内容优先分配大部分时间，冷门内容
  只做最低限度覆盖。
- 每日安排：每天都有练习量（这个阶段量比什么都重要），隔天一次论述/
  长题练习，每周一次完整模拟。
- 最后2-3天收尾放缓。考前一晚不要安排高强度刷题——这是真实的经验，
  硬扛到考前的人分数反而更差。

### 第四步：写入计划

写入 `~/.octo/learning-data/study-plan.yaml`：

```yaml
plan_type: exam  # 或 semester
exam_date: 2026-07-28
created: 2026-05-08
last_updated: 2026-05-08
weeks_to_exam: 12
hours_per_week: 25
days_per_week: 6
mode: normal  # 或 cram
phases:
  - name: 学习期
    start: 2026-05-08
    end: 2026-06-20
    focus: 搭大纲、记忆卡片、入门练习
  - name: 刷题期
    start: 2026-06-21
    end: 2026-07-18
    focus: 大量练习、论述题、接近真实考试条件
  - name: 复习期
    start: 2026-07-19
    end: 2026-07-27
    focus: 薄弱子知识点回顾、完整模拟
subjects:
  有机化学:
    priority: high  # 薄弱
    weekly_hours: 5
    methods: [练习题, 记忆卡片, 论述]
  # ...
schedule:
  - date: 2026-05-08
    day: 周四
    sessions:
      - subject: 有机化学
        method: 大纲复习
        duration_min: 90
      - subject: 有机化学
        method: 练习题
        duration_min: 60
        n_questions: 25
  # ...
session_history: []  # 由 flashcards / weak-point-drill / study-plan 的 session 模式追加
```

### 第五步：向用户确认

写文件前先用大白话总结（不是直接甩YAML），确认：

> 这是我搭的计划。距[考试]还有[X]周，每周[Y]小时，分[Z]天。薄弱学科
> （比如有机化学）分到2倍的时间。分三个阶段：学习期到[日期]、刷题期到
> [日期]、最后[N]天复习期。前两周已经排到每天，之后先按周分配，等你
> 实际做完小节我再填进逐日安排——这样计划会跟着你的实际进度走。
>
> 感觉合适吗？太紧还是太松？漏了哪个学科？

按回答调整，再写入文件。

## `--session <subject> <n>`：跑一次聚焦小节

用户说"来10道有机化学的题"、"做个5张卡片的小节"这类需求时用这个模式。

1. 解析学科和N。缺失就问："哪个学科，多少题/卡片？（比如'有机化学 10'
   或'合同法 5 --论述'）"
2. 读取 `~/.octo/learning-data/study-plan.yaml`（如果存在），看
   `session_history` 里这个学科之前哪些子主题错得多，按此加权。
3. 按方式分流：
   - 练习题模式：加载 `weak-point-drill` 技能，跑N道题。
   - 记忆卡片模式：加载 `flashcards` 技能，跑N张卡的 `--drill` 模式。
4. 逐题/逐卡呈现，答完给出对错解析。
5. 小节结束，写入结果：
   - 如果 `study-plan.yaml` 存在：追加到 `session_history`（格式见上面
     `flashcards`/`weak-point-drill` 里的示例）。
   - 不存在就写到 `~/.octo/learning-data/session-history.yaml`。
6. 汇报：得分/正确率、错题子主题、这次的薄弱子主题、和之前小节的对比
   （如果历史记录有2次以上）、计划接下来建议学什么。

## 计划的自适应调整

每次 `flashcards`/`weak-point-drill` 的小节结束后，结果会追加到
`session_history`。下次运行 `study-plan`（或任何技能检测到计划该更新了）
时：

- 得分持续偏低的学科，在 `priority`/`weekly_hours` 里往上调。
- 学科内部的薄弱子主题，标记为下次该学科小节的重点。
- 如果用户进度落后于计划（该完成的小节没出现在历史记录里），调整：
  压缩覆盖范围，或者标出差距直接问用户。
- 如果用户进度超前，腾出时间给薄弱学科做更深入的练习。

## 模式

`--build`（默认，没有计划时）——从头搭一份新计划
`--update`（默认，已有计划时）——重读 `session_history`，调整权重，
填入接下来的逐日安排
`--status`——今天/本周该学什么，得分趋势，哪些学科在掉队
`--cram`——即使距考试超过4周，也强制切冲刺模式（用户主动要求时用）

## 这个技能不做的事

- **保证考出好成绩。** 计划是脚手架，具体执行在用户自己。
- **预测考试内容。** 冲刺模式的高频优先级基于历史经验，历史上常考不等于
  这次一定考。
- **替代用户已经在跟的现成课程节奏。** 如果在跟一套现成的备考课程，这份
  计划可以补充，不要两套完整课程互相打架。
- **替用户安排生活。** 每周能投入的时间是用户自己说的。如果高估了，
  计划会在第2周就跟不上——生活约束核验就是为了防止这个。