这次分享的方法来自 Matt Pocock 的实战教程:让 AI 从“答疑机器人”变成“真老师”。核心就是一套叫 teach skill 的提示词技能,不需要装服务,不需要显卡,只需要一个能设置 system prompt 或自定义指令的对话模型,粘贴进去就能用。
普通聊天 AI 的学习体验通常是这样:你问一句“Docker 怎么学”,它立刻给你一份 2000 字的学习路线图。看的时候感觉全都会,合上电脑后一个字也说不出来。teach skill 要做的就是把这种默认行为反转过来:先摸底,再拆解,一次只讲一个知识点,讲完马上练习,做错了引导你自己改,而不是直接递答案。
对技术开发者来说,这套小技能除了自己学东西,还能当成一个可编程的“系统提示词模块”:接入 API、批量生成学习计划、按课程主题自动出题。这篇文章会把它拆开讲清楚:设计原理、完整提示词、配置方式、功能验证、API 接入方法,以及最容易踩的几个坑。
1. 核心能力速览
先把最关键的信息放到最前面。
| 能力项 | 说明 |
|---|---|
| 项目类型 | AI 提示词技能模板,不是一个独立模型 |
| 方法来源 | Matt Pocock 实战教程(中英字幕) |
| 核心功能 | 水平摸底、课程拆解、渐进式讲解、练习反馈、复习规划 |
| 可运行模型 | 主流大语言模型,云端或本地均可 |
| 硬件要求 | 云端模型基本无要求;本地模型需按模型参数量评估 |
| 启动方式 | 粘贴到自定义指令 / system prompt |
| API 能力 | 可以作为 system prompt 传给接口 |
| 批量任务 | 可批量生成学习计划、练习题、复盘报告 |
| 典型场景 | 编程教学、外语学习、学科辅导、企业培训 |
从能力边界来看,teach skill 不负责生成课程视频,也不负责模拟复杂的实验环境。它解决的问题集中在“对话式教学过程”这一层:用什么节奏提问、什么时候给答案、什么时候切换知识点。教学链条里的内容大纲、例题、复习计划都可以由模型生成,但最终的执行、判断和效果评估,仍然需要你自己或你的业务系统来把关。
有一个很容易被忽略的点:teach skill 不是一次性的“万能输出模板”。它是把“老师”这个角色拆成了一套标准操作流程。换成任何学习主题,流程都不变,变的只是具体问题。这也是提示词工程里比较实用的思路:不要堆砌形容词,而是定义流程和约束。
2. 适用场景与使用边界
2.1 适合谁
- 自学者:想用一个对话窗口系统化掌握一门技能,而不是零散地搜教程。
- 课程讲师:需要快速生成分步教学大纲、练习题和阶段性小结。
- 开发者:想把“AI 助教”能力包进自己的产品,比如题库系统、学习平台、企业培训工具。
- 内容创作者:需要用 AI 辅助备课,先在教学结构上打底稿,再人工优化。
2.2 能解决什么问题
第一个问题是“学习节奏失控”。普通 AI 没有节奏概念,用户问一个点,它恨不得把一个领域全讲完。teach skill 把教学拆成了小台阶,每一步只推进一个知识点。
第二个问题是“反馈太及时”。传统问答模型中,用户答错后通常只能得到标准答案。但学会一个东西的真正节点,是理解自己为什么错。teach skill 要求模型先定位错误,再给出提示,让用户自己找到正确路径。
第三个问题是“缺乏复盘”。学完一段内容后,模型会主动小结,并给出下一阶段的练习方向。这对长期学习特别有用。
2.3 不适合什么
- 需要真实操作环境的技能,比如焊接、手术、驾驶。这类学习必须依赖真实设备或高精度仿真。
- 需要客观评分的考试场景。大模型打分不够稳定,不能直接用于高利害考试。
- 对教学内容准确性要求极高的专业领域,比如医疗诊断、法律文书起草。模型生成的内容只能作为初稿,必须人工复核。
2.4 使用边界与合规提醒
无论 teach skill 用于哪种场景,都要注意几条底线:
- 不生成违法、危险、绕过安全限制的教学内容。
- 不把他人版权教材、付费课程内容直接塞给模型二次分发。
- 处理企业内部资料或个人信息时,先确认是否允许发送到云端模型服务。
- 涉及未成年人使用时,建议在家长或老师指导下进行,并限制敏感话题。
3. 环境准备与前置条件
teach skill 不是一个需要编译安装的软件,所以“环境准备”的重点在模型选择和配置入口。
3.1 选择模型
从使用成本看,云端模型最省事,任何能设置 system prompt 或自定义指令的模型都可以。比如常见的 ChatGPT、Claude,以及各类国产助手,大部分都支持自定义人设或指令,只是入口名称不同。
从数据隐私看,本地部署模型更可控。配合 Ollama 这类推理框架,可以把对话完全留在自己机器上。缺点是模型参数量越大,对显存和内存的要求越高,实际效果需要按本机配置测试。
3.2 准备测试材料
建议准备三个不同领域的测试问题,用来验证 teach skill 的“跨领域能力”:
测试 1:教我 TypeScript 泛型 测试 2:教我 Docker 常用命令 测试 3:教我英语虚拟语气这三个问题覆盖了编程、运维、语言三类内容,能快速看出 skill 是否真的按“先摸底、再拆解、后练习”的流程走,而不是退化成普通问答。
3.3 通用检查清单
| 检查项 | 说明 |
|---|---|
| 模型是否支持 system prompt | 不支持则无法约束教学流程 |
| 上下文长度 | 建议 8K 以上,长对话更从容 |
| 输出长度限制 | 如果模型总是输出过长内容,需要限制 max_tokens |
| 温度参数 | 太高容易跑题,太低会变得机械,一般 0.5-0.7 |
| 对话历史管理 | 教学超过 10 轮后,注意历史截断或摘要 |
4. teach skill 的提示词设计与一键配置
4.1 设计原理
一个可用的 teach skill,核心不是“你要温柔一点讲题”,而是三件事:角色、流程、约束。
“角色”让模型切换到老师模式,比如“你是一名有十年经验的私人教师”。这个设定不是让它更有代入感,而是为了激活教育类回答的语气和节奏。
“流程”是骨架。默认流程是:摸底 -> 目标拆解 -> 渐进讲解 -> 练习反馈 -> 复盘。这个大模型是可以“记住”的,因为每一步都有清晰指令。
“约束”是硬规则。比如“一次只讲一个知识点”“禁止直接给答案”。约束写得越具体,模型越不容易退化成普通问答。
4.2 完整提示词模板
下面是一个可以直接复制的通用模板,保存成teach_skill.md文件,方便后续调用:
# 角色 你是一名极度耐心、善于追问的私人教师。 # 教学流程 当用户发送学习目标时,严格按照下面五步执行: 第一步:摸底 - 先向用户提出 3 到 5 个具体问题,判断当前掌握程度 - 不要开始正式授课 - 例如“你已经会写 for 循环了吗”“你用过 Docker 的哪些命令” 第二步:目标拆解 - 根据用户水平和目标,把学习内容拆成 7 到 10 个台阶 - 每个台阶只包含一个知识点 - 向用户展示整个台阶列表,并说明第 1 个台阶的内容 第三步:渐进讲解 - 从第 1 个台阶开始,一次只讲一个知识点 - 每次讲解不超过 200 字 - 讲完立即布置一个小练习 第四步:练习与反馈 - 用户完成练习后,先肯定做对的部分 - 再指出错误点 - 不直接给出正确答案,用提示引导用户自己修正 - 如果用户连续三次尝试失败,可以给出答案并解释思路 第五步:复盘 - 每完成 3 个台阶,做一次阶段性小结 - 全部台阶完成后,输出一份完整学习记录和复习计划 # 硬性规则 - 禁止一次性输出大段完整教程 - 禁止用户还没理解就跳到下一个知识点 - 禁止默认直接给答案 - 用户说“直接给答案”时,可以妥协一次,但要提醒这样会降低学习效果 - 遇到不确定的知识点,要明确说“我不确定”,不要编造4.3 配置到对话模型
在 ChatGPT、Claude 这类支持自定义指令的产品中,直接把teach_skill.md的内容粘贴到“系统提示词”或“自定义指令”输入框即可。之后新会话会自动加载这个技能。
部分国内对话产品把入口叫“人设”“角色设定”或“智能体提示词”,操作思路一样。粘贴完成后,先发一句测试目标,观察模型第一句话是否是提问。如果是,说明配置成功。
4.4 本地模型配置方法
如果使用本地推理框架,比如 Ollama,可以在交互模式里设置 system prompt:
ollama run qwen2.5:7b # 在对话窗口中输入 /set system,粘贴 teach_skill 内容 # 设置完成后输入学习目标,例如:教我 Python 装饰器注意:本地模型的具体启动命令和模型名需要以你本机安装的推理框架为准,上面只是最常见的操作路径。
5. 功能测试与效果验证
配置完成后,建议按下面的维度逐项测试,而不是直接开始学习。
| 测试项 | 测试目标 | 输入示例 | 预期行为 |
|---|---|---|---|
| 摸底测试 | 验证模型是否先提问 | “我要学 Docker” | 先问 2-3 个基础问题,不给教程 |
| 渐进教学 | 验证知识点是否拆开 | “我已经会 run 命令了” | 只讲下一个知识点并给练习 |
| 练习反馈 | 验证是否不直接给答案 | 故意答错题目 | 先肯定对的部分,再给提示 |
| 复盘能力 | 验证是否能总结并规划 | “我学完了 4 个台阶” | 输出小结和后续复习建议 |
| 稳定性 | 验证教学节奏是否一致 | 新开会话重复测试 | 流程和节奏基本一致 |
5.1 摸底测试
测试方式:在配置好 teach skill 的会话中,发送“我要学 Docker”。
判断成功的标准:
- 模型没有急着输出完整的 Docker 学习路线。
- 它至少问了 2 个关于当前经验水平的问题。
- 问题之间有递进关系,比如从“是否用过命令行”到“是否接触过镜像和容器”。
如果模型直接给了一篇长教程,说明约束没生效。优先检查提示词是否完整粘贴,以及产品是否真的支持 system prompt。
5.2 渐进教学测试
接上一轮,回答完摸排问题后,要求模型进入下一个台阶。
判断成功的标准:
- 模型会明确说“下面讲解第几部分”。
- 讲解内容被限制在一个知识点范围内。
- 讲完立刻给出一个小练习。
这里最容易出现的问题是模型把一个台阶讲成十个台阶。遇到这种情况,可以在提示词里再加一句约束:“如果用户没有要求继续,不要展开不相关知识点。”
5.3 练习反馈测试
故意在练习中写错一个地方,观察模型的反应。
判断成功的标准:
- 模型不是先给出正确答案,而是先指出错误位置。
- 它会用一个提示引导思考,例如“检查一下第二行代码的退出条件”。
- 如果继续答错,模型会逐步给出更多提示,而不是瞬间放弃。
如果模型直接给完整答案,说明“禁止默认直接给答案”这条约束权重不够。可以改成“只要有练习错误,必须先用提示引导至少一轮”。
5.4 复盘能力测试
当学习完第 3 个或第 4 个台阶后,要求模型进行阶段小结。
判断成功的标准:
- 模型会输出本次学习的知识点列表。
- 会指出容易混淆的概念。
- 会给出下一步的练习方向。
如果模型只是把前面内容重新复述一遍,说明复盘部分的流程不够完整,可以补充要求:“用每一条不超过 20 字的方式归纳要点。”
5.5 稳定性测试
换一个新会话,用同样的问题重新执行一次完整流程。
判断成功的标准:
- 教学节奏没有明显变化。
- 第一次提问的数量和类型基本一致。
- 台阶拆解的颗粒度差别不大。
如果两个会话的差别很大,可能是模型温度设置过高,或者同一模型在不同时间段的输出存在随机性。稳定的做法是把温度调低到 0.5 左右。
6. 接入 API 与批量构建技能库
teach skill 最大的价值在于可编程。只要模型服务支持/chat/completions这类接口,就可以把它当成一个固定system prompt,用代码批量驱动。
6.1 将 teach skill 作为 system prompt 调用
假设teach_skill.md已经保存了提示词模板,Python 调用示例可以这样写:
import requests # 读取提示词模板文件 with open("teach_skill.md", encoding="utf-8") as f: system_prompt = f.read() # 换成你实际使用的模型服务地址和密钥 url = "https://your-model-service.example/v1/chat/completions" headers = { "Authorization": "Bearer YOUR_API_KEY", "Content-Type": "application/json" } payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": "教我 TypeScript 泛型"} ], "temperature": 0.5, "max_tokens": 800 } response = requests.post(url, json=payload, headers=headers, timeout=120) print(response.json())这里的关键点是把 skill 内容放在system消息里,而不是和用户消息混在一起。这样每次请求都会自动加载教学流程。
6.2 批量生成学习计划
如果需要给多个主题生成学习计划,可以写一个简单循环:
topics = ["Docker", "Kubernetes", "React", "英语虚拟语气"] for topic in topics: payload["messages"] = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": f"教我{topic},先摸底"} ] response = requests.post(url, json=payload, headers=headers, timeout=120) data = response.json() print(f"=== {topic} ===") print(data["choices"][0]["message"]["content"]) print()批量任务运行时,建议把每个主题的结果保存成独立文件,方便人工检查和后续优化,而不是直接在终端里跑完就丢。例如,用 JSON 结构组织输出:
{ "topic": "Docker", "first_questions": ["...", "..."], "steps": 8, "status": "ok" }6.3 批量任务的稳定性建议
批量任务最容易踩的坑是并发过高导致接口限流。建议先单线程跑通 5 个主题,再逐步增加并发。每个请求之间加一个小的延时,例如time.sleep(1)。
如果某个主题返回超时或空结果,不要整体重跑,只针对失败项重试。可以用下面的思路处理:
第一步:保存 request_id 第二步:检查错误消息是超时、鉴权还是模型拒绝 第三步:只对超时请求重试,最多 3 次 第四步:重试之间间隔 5 秒、10 秒、20 秒递增7. Token 消耗与性能观察
虽然 teach skill 不依赖本地显存,但使用 API 或本地模型时,Token 消耗和推理速度仍然需要关注。
7.1 Token 量级估算
以第 4 节的模板为例,中文提示词大约 500 到 800 个汉字,换算成 Token 通常在 800 到 1200 之间。具体数字取决于模型分词器,不同服务商差异不小,但量级可以参考。这个固定开销在每次请求中都会存在,所以长会话中会反复累积。
7.2 对性能的影响
| 影响项 | 因素 | 影响 |
|---|---|---|
| 固定提示词 | 每次请求多消耗 800-1200 Token | 总量可控 |
| 模型输出长度 | max_tokens 设置 | 设置过大会延长等待时间 |
| 多轮对话 | 上下文持续累积 | 可能出现截断,影响记忆 |
| 温度参数 | 温度过高容易跑题 | 影响效果稳定性 |
7.3 如何降低 Token 消耗
- 精简模板:提示词中的示例不一定要保留太多个,只留 2 个典型场景即可。
- 定期清理历史:对话超过 15 轮后,可以由模型生成一段摘要,再开始新一轮学习。
- 控制输出上限:在 API 请求中设置
max_tokens: 600左右,避免模型长篇大论。 - 会话复用:如果用户还在学习同一主题,尽量在同一个会话里继续,不重复发送全量历史。
7.4 本地模型的性能观察
如果走本地部署,观察重点要放在显存和推理延迟上。不同模型和量化版本对显存的要求差别很大,所以不要直接照搬网上的某个数字。
观察方法是:启动服务后用nvidia-smi查看显存占用峰值,再连续执行多轮教学对话,看推理速度和上下文增长是否稳定。如果对话变慢,优先缩短历史记录,而不是降低模型量化档位。显存不足时,再考虑更换更小的模型。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型一上来就输出长答案 | system prompt 未生效 | 检查是否粘贴完整 | 重新粘贴提示词,增加“第一个回复必须先提问” |
| 用户答错后直接给正确答案 | 约束条件不够强 | 故意答错观察反馈 | 在硬性规则中增加“必须先引导一轮再考虑给答案” |
| 教学几轮后忘记流程 | 上下文被冲掉 | 查看对话长度和截断情况 | 清理历史,开启对话摘要 |
| API 批量任务频繁失败 | 并发过高或超时设置过短 | 查看错误日志和限流信息 | 降低并发,增加重试间隔 |
| 生成内容有事实错误 | 模型幻觉 | 核对知识点关键词 | 在 prompt 中加“不确定时明确说不知道” |
| 本地模型效果明显偏差 | 模型参数量较小 | 和云端模型对比 | 换更大参数模型或调整量化档位 |
| 输出越来越啰嗦 | 温度偏高且无输出限制 | 检查参数配置 | 调低温度,增加 max_tokens 上限控制 |
排查时有个建议:不要只看一次输出就下结论。同一个问题多轮测试,观察稳定表现。比如连续问 3 次同一个学习目标,如果 3 次都是先摸底、再拆解、后讲解,说明 skill 已经稳定生效。
9. 最佳实践与使用建议
9.1 一套模板不够,每个领域做变体
teach skill 的通用模板可以跑通,但要达到“像真老师”的水平,最好按领域定制。比如编程教学需要在练习环节给出代码片段,外语教学需要在练习环节加入口语复述和例句改写。
可以按主题维护多个 skill 文件:
teach_skill_programming.md teach_skill_language.md teach_skill_math.md它们共享同一个教学流程,但练习形式和示例不同。这样切换主题时,不需要反复调整提示词里的细节。
9.2 第一次使用先小范围测试
不要一上来就生成整套 20 课时的学习计划。先拿一个 30 分钟能学完的小主题,完整跑一遍流程。确认摸底、练习、复盘都正常后,再投入大批量任务。
这样做的目的是快速暴露 prompt 中没写清楚的地方。比如模型在讲完知识点后忘了布置练习,你可以立刻补一句“每次讲解结束后必须给出一个小练习”。
9.3 把 skill 和材料分开管理
好的 prompt 结构应该是“固定的教学流程”加上“每次不同的学习素材”。不要把所有内容都塞到 system prompt 里,否则提示词会越来越长,模型也会被大量无关内容干扰。
推荐的目录结构:
skills/ teach_skill_base.md teach_skill_programming.md materials/ typescript_guide.txt docker_cheatsheet.md outputs/ study_plan_ts.md9.4 日志与复盘
长期使用 teach skill 的人,建议把每一轮对话记录保存下来。一是方便复盘模型输出质量,二是可以拿它作为下一版 prompt 的优化依据。
每次记录至少包含:学习目标、用户水平、模型输出类型、是否达到预期。
9.5 隐私与合规
在把教材、公司内部文档或个人学习记录发给模型前,先确认该数据是否允许上传到对应模型服务。涉及真实身份的对话,建议脱敏后再写入提示词。企业环境里,优先用本地部署或已签署保密协议的私有化服务。
10. 总结与下一步
这个项目最值得尝试的地方,不是它的某个具体答案,而是它把“教学”从凭感觉变成了流程。teach skill 本质上是一套教学 SOP,任何大模型接上这套 SOP,都会有明显变“老师”的倾向。
如果你准备试,建议先验证三件事:第一,模型第一个回复是否在提问;第二,练习答错后模型是否先引导而不是给答案;第三,新会话里教学节奏是否稳定。这三个点通过了,整个 skill 基本就能用。
最容易踩的坑集中在两个地方:一是 system prompt 没生效,只顾着粘贴,没确认产品是否支持;二是模型输出过长,把一次讲解变成了完整教程,这会完全破坏“渐进式”的教学节奏。
下一步可以往三个方向扩展:把 teach skill 打包成独立 API 服务,做成小组件嵌入到自己的学习平台;针对编程、外语、数学分别做 skill 变体;再进一步,把教学对话存档,用来源材料迭代出更贴近目标用户的教学风格。这套提示词技能适合长期保留,建议收藏备用。