AI Skills赋能数竞教研：学案制作一体化实战指南

学案的革命（数竞版）：竞赛教研与学案制作一体化 skills

接触数学竞赛教研的老师应该都有同感：每周最耗时的事情，不是上课，而是做学案。找题、对难度、配解析、调格式、作图、排版，一套二试几何专题学案下来，三四个小时是常态。我之前也试过用通用 prompt 让 AI 帮忙，但结果总是不对味——模型给的题偶尔超出考纲，难度星级也常常飘忽不定，最难受的是排版动不动就乱。后来我接触到了 Agent Skills 这套机制，也就是现在 Claude Code、Codex、Cursor 这些 AI 编程环境里非常火的“技能包”，试着把数竞教研的整套流程封装成一组 skills，才算是真正把学案制作从手工活变成了半自动化流水线。这篇文章就把我这套“数竞版学案一体化 skills”的完整设计思路、开发过程和避坑记录分享出来，希望能给正在用 AI 做学科教研的朋友一些参考。

1. 数竞教研的碎片化痛点：为什么通用提示词做不了学案一体化

先聊一个最根本的问题：为什么市面上那么多 AI 工具，通用能力已经很能打了，但做学案还是费劲？因为学案制作这件事，看起来是“写文档”，实际上是一连串互相咬合的碎片化动作，而通用模型并不具备“教研人员的工作记忆”。

1.1 一张典型数竞学案的诞生流程

以一份二试几何专题学案为例，完整流程大概是这样的：

1. 确定专题与定位：这节课面向的是备战高联二试的学生，还是冲击 CMO 的学生？专题是圆幂与根轴，还是完全四边形？
2. 筛选题目：从历年高联、CMO、IMO、集训队题里挑出合适的题目，既要覆盖知识点，又要控制难度梯度。
3. 重排与改编：有些题太长、太偏，需要裁剪条件、换成等价表述、改成填空题或证明题。
4. 撰写解析：不是简单抄答案，要按数竞讲义的习惯写——先用一句思路总纲，再分步证明，关键步骤加注释，必要时给出“另证”。
5. 制作图形：几何题没有图基本没法用，但画图又是个单独的工作。
6. 排版成学案：标题、知识提要、例题区、练习区、解析后置或附页，版式要统一。

这套流程最大的问题是：它横跨了资料检索、教研判断、文字处理、图形绘制、排版输出五个领域，而且每个环节都有“只有数竞老师才懂的隐性规则”。通用 prompt 也许能帮你写出例题下面的解析初稿，但你要它“从题库里自动挑题、按难度排列、然后直接导出 PDF”，它就懵了。

1.2 通用 prompt 的三个典型失控点

我自己试过很多次直接用对话式 AI 做学案，最常翻车的就三类：

• 难度系统失效：你跟它说“来三道中等难度几何题”，它给出的题可能一道是联赛一试基础题，一道是 CMO 压轴题，完全不匹配。因为模型对“难度”的理解是纯语义层面的，没有一套可执行的标准。
• 题源信息失真：它很容易编造题目来源，把一道风格像高联的题标注成“2019 高联 A 卷真题”，但实际并不是。对教研来说，题源信息错误比题目本身错误更隐蔽、更危险。
• 输出格式不可控：同一个学案，第一次给你 Markdown，第二次给你代码块里的 LaTeX，第三次直接给段落文本，根本没法直接进排版流程。

这些问题本质上不是模型笨，而是因为你没有给它“约束框架”。就好比让一个新助教直接上手做学案，你只说了句“做一份几何学案”，他当然不知道你的题库在哪、格式要求是什么、难度口径怎么定。

1.3 Skills 方案的解题思路：把教研流程变成可复用技能

Skills（也叫 Agent Skills）提供了一种完全不同的思路：它把某个领域的操作经验写进结构化目录，包含说明文档、脚本、资源文件，AI 在需要的时候会主动读取这些内容，按你预定义的规范去执行。

对应到数竞教研，我可以把这些“隐性规则”全部显性化：

• 题库结构：题目统一存成 YAML/JSON，字段固定（题源、难度、知识点、题干、解析）。
• 难度口径：用脚本校验题目难度的分布，而不是让模型拍脑袋。
• 学案结构：预设“知识梳理—例题精讲—变式训练—真题实战—解析附页”五段式框架。
• 渲染管线：用 LaTeX 模板统一排版，模型只负责产出结构化内容，排版交给脚本。

把这些东西做成一套 skills 之后，AI 就不再是“一个聪明的聊天机器人”，而是一个“熟悉数竞教研流程的虚拟教研助手”。这个思路放在任何学科其实都成立，只不过数竞的特殊性更强：题目复杂度高、难度分层细、几何图形要求精确、排版要求统一，它刚好是 Skills 机制能解决得最彻底的一类场景。

2. 学案一体化系统的架构设计：从知识底座到渲染管线

既然决定用 Skills 来做，第一件事不是写代码，而是先把整个系统的数据模型和工作流定义清楚。这步想不清楚，后面写多少脚本都是白搭。

2.1 题目资源的标准化：用 YAML 题库承载教研资产

我一开始的冲动是让模型“即兴出题”，但试了两周后就放弃了。模型出的题偶尔能出得不错，但稳定性太差，而且你没法积累——好不容易见到一道好题，下次想要时它又不记得了。真正的解法是：把题库作为独立资产沉淀下来，模型只负责“选”和“改”，不负责“凭空造”。

每一道题在题库里长这样：

id: geo-00127 topic: 几何 subtopic: 圆幂与根轴 source: 2019 全国高中数学联赛 A 卷加试 difficulty: 4 tags: [圆幂, 根轴, 三点共线] statement: | 如图，在锐角三角形 ABC 中，AB > AC，D 为边 BC 的中点…… hint: | 考虑点 D 关于三角形外接圆的幂，尝试证明目标点在根轴上。 answer: | 先用中线条件计算 DB=DC，再结合圆幂定理…… solution: | 解析正文……

这里的字段都是有讲究的：

• difficulty用 1-5 星，但它的评级不是模型的“感觉”，而是由脚本根据题源、历年得分率标签等综合计算出来的。比如高联加试第 3 题固定给 4-5 星，高联一试填空压轴给 3 星左右。
• source必须有，哪怕是“模拟题/自编”也要写清楚。这样学案末尾的题源列表才能自动生成。
• statement和solution分开存，是因为学案有两种版式：解析直接跟在题目后面，或者全部放到末尾附页。数据层分开，渲染层才能灵活切换。

这套 YAML 题库是整个系统的心脏。实际使用中，我会在题库文件头部维护版本号，因为题库会不断增补修订，学案里引用了旧题还是新题，必须可以追溯。

2.2 学案的五段式结构：教研逻辑驱动排版

数竞学案和普通讲义最大的差异，在于它的课堂节奏感。我做学案时一贯采用五段式结构：

1. 知识提要：本专题的核心结论、常用定理、经典构型，控制在半页以内。
2. 例题精讲：3-5 道，按难度递增排列，每道题附思路点注。
3. 变式训练：与例题高度相关、但需要学生独立动笔的题，通常不附解析。
4. 真题实战：节选历届竞赛真题，标注年份与赛制，帮助学生感受实战难度。
5. 解析附页：所有例题和训练的详解，与正文分开排版，方便学生先做后对答案。

把学案结构固定下来的意义在于：模型不需要“设计版式”，它只需要在合适的槽位填内容。这也让自动化质检成为可能——脚本可以检查“例题精讲”部分是否恰好有 3-5 道题、每道题是否都配了解析、难度是否严格递增。

2.3 渲染管线：为什么一门心思选 LaTeX

做学案的最终交付形态，我建议直接锁定 LaTeX（具体用 XeLaTeX，因为要兼容中文字体）。原因很简单：

• 数学公式必须走 LaTeX，Word 自带公式编辑器虽然也能用，但在大量几何符号、多行证明、带编号公式面前效率差距太大。
• 版式可完全程序化控制：页边距、题号格式、图形占位、解析分页，全部通过模板控制，不会出现“每份学案长得都不一样”的问题。
• 和 Skills 的脚本机制天然契合：模型产生 JSON/YAML 结构数据，Python 脚本负责把它“填”进.tex模板，然后调用xelatex编译输出 PDF。

有人会问：直接让模型产出 LaTeX 代码不就行了吗？我的建议是：不要让模型直接写完整.tex文件，而是让模型产出结构化的学案内容（JSON），再由固定脚本套模板。因为模型直接写 LaTeX 太容易在宏包调用、特殊符号转义上翻车，而结构化内容 + 人工模板的组合，输出稳定得多。

2.4 版本管理与协作：学案也是代码资产

很多教研组做学案是“一人一份，互不通用”，这非常浪费。既然题库和脚本都进了 Git 仓库，学案的版本管理就应该顺理成章。我的做法是：

• 每次生成学案自动带版本号，如geometry-power-2025-v2.3。
• 学案的 JSON 源数据入库，PDF 只是编译产物，不进版本管理。
• 多人协作时，每人负责自己最熟悉的专题模块，通过 Git 分支合并，避免互相踩踏。

这一步看似和“学案制作”无关，但恰恰是它能持续积累教研资产的关键。你不需要一开始就做得多完善，只要从第一份学案开始用 Git 管理，半年后你回头看，题库的增补历史、学案的演进过程全都在，这是传统教研方式给不了的。

3. 开发实录：SKILL.md、目录结构与自动化脚本

架构定了，接下来就是动手写 skills。这一章的实操细节比较多，我会把目录结构、SKILL.md 写法和脚本设计逐一展开。

3.1 Skill 的标准目录结构：一个 skill 就是一个小项目

我总共拆了四个 skill，分别对应学案制作流程的不同阶段：

skills/ ├── problem-bank-manager/ │ ├── SKILL.md │ ├── scripts/ │ │ ├── query_bank.py │ │ ├── validate_bank.py │ │ └── sha_check.py │ └── resources/ │ └── difficulty_rules.md ├── lesson-plan-builder/ │ ├── SKILL.md │ ├── scripts/ │ │ ├── build_plan.py │ │ └── template_utils.py │ └── resources/ │ └── plan_schema.json ├── latex-renderer/ │ ├── SKILL.md │ ├── scripts/ │ │ ├── render_plans.py │ │ └── compile_tex.sh │ └── resources/ │ └── templates/ │ ├── main.tex │ └── cover.tex └── geometry-figure-gen/ ├── SKILL.md └── scripts/ ├── make_ggb.py └── generate_png.py

每个 skill 都是一个独立目录，里面必须有SKILL.md，这是模型读取技能说明的入口。scripts放可执行脚本，resources放模板和参考数据。这个结构其实就是现在社区里通行的 Agent Skills 标准结构，Claude Code、Codex 等环境都能识别。

3.2 SKILL.md 的写法：让模型知道“何时用、怎么用、别乱来”

SKILL.md的开头是 YAML frontmatter，里面最重要的就是name和description。这段描述决定了模型在什么时候会调用这个 skill，所以一定要写清楚“何时触发”和“边界”。

以lesson-plan-builder的 SKILL.md 为例：

--- name: lesson-plan-builder description: > 将题目资源组装为结构化数竞学案。当用户需要生成一份完整的 "知识梳理—例题精讲—变式训练—真题实战—解析附页"五段式学案时， 使用此 skill。输入应为题目 ID 列表或专题筛选条件。 本 skill 不负责从零出题，题目必须来自已被 problem-bank-manager 校验过的题库。 ---

正文部分，我建议写清楚四个内容块：

• 使用步骤：先查题，再组装，再校验。
• 输出格式：学案 JSON 的 schema，包括字段名和类型。
• 禁止事项：比如“不得修改题目的难度评级”“不得省略题源信息”。
• 参考指向：告诉模型可以去读resources/plan_schema.json获取详细字段规范。

很多第一次写 SKILL.md 的人容易犯一个毛病：把文档写得像产品说明书的简介，只有“这个 skill 能做什么”，没有“具体怎么做”。实际上，模型在运行时是非常依赖文档里的操作指引的，写得越具体，输出就越稳定。

3.3 脚本设计：把判断交给代码，把表达交给模型

我始终坚持一个原则：凡是能靠脚本校验的事情，绝不指望模型自觉。

拿problem-bank-manager/scripts/validate_bank.py来说，它做的事情包括：

• 检查每条题目的必填字段是否齐全，缺失的自动列入报告。
• 检查题目 ID 是否重复，避免组卷时出现“两个不同的题共用同一个 ID”。
• 校验difficulty是否在 1-5 范围内，超出自动修正为最接近的档位。
• 对source字段做格式规整，比如统一成“年份 + 赛事 + 卷别”的格式。

另一个特别实用的脚本是sha_check.py。它的作用是给题库文件计算 SHA-256 哈希值，把它记录在学案 JSON 中。这样当一份学案被回读时，脚本能立刻判断题库在这之后是否被改动过，防止模型在生成学案时悄悄改掉题目内容而不自知——这个问题我在测试时真实遇到过，后面会细说。

lesson-plan-builder里的build_plan.py则是一个“组装器”：它读入题目列表和专题信息，按五段式结构填充 JSON，并自动完成难度排序、重复题目检测、题源列表生成。模型在生成过程中要做的是“判断和表达”——比如根据学生水平调整例题的题号顺序、为每道题写一句思路点注——而不是“计算和记忆”。

3.4 四个 skill 如何协同：用“主 skill 调度 + 子 skill 执行”的模型

如果只有一个 skill，那它可能是一个“全流程大招”，但一旦流程里某个环节要独立复用（比如只画图、只排版），就会很尴尬。所以我采用了“主调度 + 子分工”的组合方式：

• problem-bank-manager：管题目的查询、校验、完整性。
• lesson-plan-builder：管组卷逻辑与结构生成，是流程中的“主编”。
• latex-renderer：管把 JSON 渲染成 LaTeX 并编译 PDF。
• geometry-figure-gen：管几何图形的自动生成，被lesson-plan-builder在需要时调用。

实际运行时，模型会先读lesson-plan-builder的 SKILL.md，再按其中指引去调用其他 skill。这个模式的好处是：每个 skill 都可以独立测试、独立替换。比如你想把排版从 LaTeX 换成 Typst，只需要替换latex-renderer一个 skill，其他完全不用动。

4. 实测跑通：从题目导入到学案导出的一整条链路

架构和脚本都搭好之后，最重要的一步就是把整条链路跑通。这一章我拿一个真实的案例——二试几何专题“圆幂与根轴”——把完整过程走一遍。

4.1 准备题库与调用环境

我先在仓库里准备了一个小型题库文件bank_geometry.yaml，里面存了 30 道几何题，覆盖圆幂、根轴、调和点列、完全四边形等几个二试高频专题。然后在 Claude Code 环境中启用 skills，把仓库放到了项目的.claude/skills目录下（具体部署方式下一章细说）。

启动会话后，我的需求指令是：

“请用 lesson-plan-builder 生成一份圆幂与根轴专题学案， 学生水平：备战高联二试，目标课长 90 分钟。”

这里有一个关键点：需求指令里不要写“我要 20 道题”这种细节，把“学生水平”和“课长”这两个关键约束给足就够了。模型会通过 skill 的 SKILL.md 知道怎么选题、怎么排布。

4.2 生成过程：模型在做什么，脚本在做什么

整个生成过程大致分四步：

第一步，模型调用problem-bank-manager的查询脚本，从题库里筛出topic=几何且subtopic=圆幂与根轴的题目，得到候选列表。

第二步，模型根据“二试水平”粗略筛选——我在这套 skill 里给了一个成文规则：“高联二试阶段的例题精讲部分，题目难度应覆盖 3-4 星，4 星占比不低于一半；变式训练以 3 星为主；真题实战部分应包含一道 4 星高联真题和一道 5 星 CMO/IMO 风格题”。模型按这个规则做初选，但实际难度档次以validate_bank.py的输出来校准。

第三步，build_plan.py读取模型选出的题目 ID，自动完成排序、查重、题源格式化，生成学案 JSON。

第四步，模型向latex-renderer发送学案 JSON，脚本渲染出.tex文件，调用xelatex编译，最终产出 PDF。

4.3 生成结果示例与人工质检

输出的学案 JSON 结构大致是这样的：

{ "title": "圆幂与根轴专题学案（高联二试）", "version": "2025-06-v1", "sections": { "knowledge_review": [ "圆幂定理及其逆用", "根轴的定义与性质：到两圆切线长相等的点轨迹是一条直线", "三圆根轴共点（根心定理）" ], "examples": [ {"id": "geo-00012", "difficulty": 3, "note": "基础圆幂计算，作为课堂开场"}, {"id": "geo-00045", "difficulty": 4, "note": "根轴与三点共线，核心题型"}, {"id": "geo-00051", "difficulty": 4, "note": "结合四点共圆的综合题"} ], "variation_training": ["geo-00088", "geo-00091", "geo-00094"], "real_exams": [ {"id": "geo-00102", "source": "2022 高联 A 卷加试第 2 题"}, {"id": "geo-00117", "source": "2018 CMO 第 3 题"} ] } }

我拿到 JSON 后，不会直接编译，而是先跑一轮人工质检。重点检查三样东西：难度分布是否符合预设、题目之间是否有重复或相似度过高的情形、解析最长的那道题会不会导致学案版面失衡。这道工序目前还不能省，毕竟 AI 组卷的品位还需要人工把关。

4.4 渲染与输出：LaTeX 模板的实用细节

latex-renderer里的主模板main.tex有几个实用设计：

• 题目区与解析区分页：\newpage在解析附页前强制分页，确保答案不会“不小心”出现在题目旁边。
• 几何图占位：在题目statement末尾留一个\includegraphics占位，图片由geometry-figure-gen生成后自动填入。
• 难度标记：每道例题右上角以角标形式标注星数（用\tag实现），学生一眼能看到难度梯度。

第一次编译时最容易遇到的坑是宏包缺失或中文字体路径不对。我的模板里会用ctex宏包，并在编译脚本中显式指定字体目录，尽量减少环境依赖。

5. 开发过程踩过的坑：难度漂移、解析失控与题目被悄悄改编

这章要说的几个坑，都是我实际开发测试中遇到过的，很多问题不跑到真实场景根本发现不了，写出来帮大家省时间。

5.1 模型对难度标签的“理解漂移”

最早一版我把难度判断完全交给模型，结果同一个题库，第一次生成学案时 geo-00012 被标成 3 星，第二次生成同一道题却变成了 5 星。原因在于模型对“困难”的判断会受上下文影响——如果同一次会话里连续出现了几道很简单的题，它会把中等题标成高难度。

后来我做了两处改进：一是题目源数据里就固定了星级，模型只允许读取，不允许修改；二是增加了一个validate_bank.py的自动校验步骤，学案里题目的难度星级必须和题库元数据一致，一旦不一致脚本直接报错并把错误写进日志。这个改动之后，难度漂移问题基本绝迹。

5.2 “解析写得太长”导致学案比例失衡

模型写数竞解析很容易收不住笔。有一道 4 星几何题，它写了三段“另证”，加起来快两页，把整份学案的版面完全带偏了。学生做学案不是读论文，例题解析讲究“精讲”，变式训练更是这样，答案留白比长篇大论更重要。

我的解决方案是在lesson-plan-builder的 SKILL.md 中明确规定了“解析三段式”：思路总纲（不超过 3 句）、主要证明/解答步骤、关键注记（点明突破口或延伸思考）。如果模型想写“另证”，只允许在“关键注记”里用两句话概括思路，不允许展开全文。规范化之后，解析的可读性和版式都改善了很多。

5.3 几何图形自动生成：从“让模型画”到“脚本画”

一开始我很天真地想让模型直接用 Python 生成几何图。后来发现，模型画出来的几何图经常是不精确的——线的角度不对、圆与点不共轴、中点明显不在中点上。对有教研要求的几何学案来说，一张不精确的图比没有图更尴尬。

我最终的方案是：图形的绘制不做成“灵感创作”，而做成精确的构型脚本。对于常见的数竞几何构型，比如“三角形 + 外接圆 + 根轴”“两圆相交 + 连心线”，在geometry-figure-gen里预定义绘制模板，传入点坐标和圆参数，脚本用 Python 精确计算坐标并生成矢量图。模型要做的是读题后在构型模板中做选择，而不是自己对着屏幕画。

5.4 题库被“悄悄改编”的问题与 SHA 校验

这是最隐蔽的一个坑。有一次我检查生成结果，发现一道高联真题的题干被改了数字——模型可能觉得原题太复杂，顺手做了“合理化改编”，但学案里并没有标注这是改编题。这在教研上是非常严重的问题：学生练的题和真题不一致，题源标注却指向了真题。

根治方案是我前面提到的sha_check.py。生成学案时，脚本记录题库文件哈希以及每道题的最终状态；任何“改写题目内容”的操作，都会被哈希校验拦下来。如果教研员确实需要改编题目，流程上必须显式创建一条“改编题”记录，并在学案里标注“改编自 + 原题出处”。这一条已经写进lesson-plan-builder的禁止事项，等于从机制层面堵住了模型自作主张的路。

6. 部署到 Claude Code / Codex / Cursor：从仓库到可用的完整路径

最后聊一下最实际的问题：写好了一套 skills，怎么装进你手头的 AI 编程环境里用起来。这部分网上教程零散，我把通用的做法说清楚。

6.1 Skill 的识别机制与安装位置

不同工具对 skills 目录的默认位置有差异，但核心机制是统一的：工具会扫描特定目录下的 skill 子目录，读取其中的SKILL.md作为技能描述。

以 Claude Code 为例，支持两种安装位置：

• 项目级：放在项目根目录下的.claude/skills/，只对当前项目生效。
• 用户级：放在用户主目录下的~/.claude/skills/，所有项目都能用。

Codex 和 Cursor 的机制类似，多数是扫描.codex/skills或.cursor/skills目录。如果你要跨工具复用同一套 skills，最省事的做法是：在 Git 仓库里维护一套skills/目录，部署时用脚本同步到各工具的对应目录。

# 将仓库中的 skills 同步到 Claude Code 项目级目录 mkdir -p .claude/skills cp -r skills/* .claude/skills/

6.2 从远程仓库手动安装的注意点

如果你想安装网上开源的一套 skills（比如 GitHub 上的各类 skills 集合），注意两件事：

第一，一定要看目录结构是否合规——好的 skill 仓库每个子目录下都有SKILL.md，而不是只放一个说明文档。第二，装完后在会话里确认 skill 是否被识别。最简单的方法是在对话里直接问“你现在有哪些可用的 skills？”，模型会把扫描到的技能列表报出来。

如果是“手动装 GitHub 上的 skills”，本质就是git clone或下载 zip 后，按 6.1 的目录规则放进去，然后重启会话让工具重新扫描目录。这个操作不需要任何额外配置，只是注意别放错层级——很多新手把SKILL.md直接放在skills/根目录下，这样是无效的，必须是一级子目录下的SKILL.md。

6.3 会话中如何触发：让模型主动发现并调用 skill

Skill 的触发有两种方式：

一是显式引用，比如你在需求里直接说“请使用 lesson-plan-builder……”；二是隐式触发——模型的调度机制会根据你描述的需求自动匹配 SKILL.md 里的description。要让隐式触发更可靠，description里就要尽量写清楚典型场景，比如“当用户需要把题目组装成一节课的学案时使用”。

我自己的习惯是：复杂任务必须显式点名，简单任务可以隐式触发。比如“帮我看看这道题的难度评级是否合理”这种问题，模型不需要加载整套 skill，直接对话即可。

6.4 与第三方 skill 集合共存的命名冲突处理

社区里有很多现成的 skills 集合（比如知名的 superpowers 之类的通用技能包），它们里面往往也会有file-operations、code-reviewer之类的通用技能。如果你同时装了多套 skills，注意命名冲突。

处理办法很简单：一是尽量给学科类 skill 起有辨识度的名字，比如problem-bank-manager和通用的file-operations就不会撞车；二是在彼此交叉的领域设置调用优先级——在需要调控的地方，自己在需求指令里写明“不要使用通用的文件操作，使用我专用的lesson-plan-builder”。

6.5 团队分发与长期沉淀

这套 skills 最难能可贵的是：它可以拷贝、可以分发、可以进化。一个教研组只需维护一个仓库，里面包含skills/、题库/、学案模板/三个部分，任何新加入的老师都能在十分钟内跑通第一份学案。

仓库里配一个 README，把本组的学案制作规范写清楚，比如难度口径、五段式结构、格式要求，顺手把SKILL.md的更新记录也放在文档里。这个仓库本身就会成为教研组的“数字资产”，越用越厚。

我个人的实际体会是：这套流程跑了两个月之后，最明显的变化不是“做学案变快了”（虽然确实从两三小时缩短到二十来分钟），而是整个教研组对“题目难度口径”“学案结构规范”“题源可信度”形成了统一的语言。过去说要出一份二试几何学案，每个老师脑子里的画像都不一样；现在只要说一句“用那套 skills 跑一份”，大家看到的是一模一样的结构化骨架，剩下的只是个性和风格的差异。最后分享一个小技巧：别指望第一次就把 SKILL.md 写完美，先用文档描述清楚“最让你头疼的那个环节”，比如难度控制或解析长度，然后每跑一次学案就顺手修订一处，迭代三四版之后，它就会变得非常顺手。