在 AI 学习类内容大量泛滥的今天很多人已经发现一个尴尬的事实AI 能答对题目却不一定能教会你。你问它“请解释 TypeScript 泛型”它可能给出一个完整但看不懂的长篇大论你让它“教我 Vue 的响应式原理”它又可能直接吐出源码分析完全不顾你只有三个月前端经验。问题不在模型能力而在“教学流程”本身没有被设计。Matt Pocock 的 teach skill 思路恰好是把 AI 从一个“答题机器”改造成“有教学方法的老师”。这篇文章会拆解这一思路教学型 Skill 由哪些模块组成、如何写系统提示词、如何把它工程化为可复用的配置、如何验证教学效果。无论你是普通学习者还是做 AI Agent 应用开发的工程师都能找到可以直接落地的部分。1. 为什么 AI 会“答题”但不会“上课”先看一个大多数人都经历过的场景。你打开 ChatGPT 或者 Claude输入“请解释 React 中的 useEffect”。模型会给出一个结构化的回答定义、语法、参数、依赖数组、清理函数。看起来信息量很大但如果问你“我什么时候不该用 useEffect”你依然答不上来。这就是“答题”和“上课”的区别。答题只追求“答案正确”而上课要追求“学习者状态改变”。一位真老师在上课前会做三件事判断你的基础、确认你的目标、安排讲解顺序。直接把答案扔给你不叫教学根据你的反馈一步步带你走到答案面前才叫教学。Matt Pocock 的 teach skill 核心贡献是把“教学流程”显式地写进了 AI 的系统提示词里。它不再让 AI 自由发挥而是要求 AI 按一套固定教学法执行诊断、拆解、讲解、练习、反馈、测试。听起来很简单但绝大多数人用 AI 学习时根本不会告诉 AI“你要先诊断我的水平”所以得到的回答永远是“看起来很专业但不解决我的问题”。这个判断很重要AI 能不能当好老师不取决于模型有多强而取决于你有没有给它一套教学流程。这也解释了为什么有人用同一款模型学得飞快有人却觉得 AI 只会说废话。2. teach skill 的核心原理先设计流程再设计回答要理解 teach skill需要先理解“Skill”在 AI 应用里到底是什么。在 AI Agent 和自定义助手的语境下Skill 是一组可复用的指令和数据它把某个领域的专业知识、流程步骤、输出规范打包成一个单元。AI 在运行时加载这个 Skill就相当于“进入角色”。你不需要每次对话都重新描述一遍“请当一个耐心的老师”只需要加载技能然后提出具体的学习请求。从技术构成看一个教学型 Skill 至少包含五层层次作用不写的后果角色定义告诉 AI 它是什么类型的老师有什么教学理念回答语气不稳定时而是论文腔时而是客服腔学习者模型规定 AI 必须先了解学生水平再决定讲解深度输出的内容要么太简单要么太难教学流程规定从开场到收尾的步骤顺序AI 跳过诊断直接给答案学习体验中断反馈规则规定学生答错时怎么做允许给到什么程度学生一卡住AI 就直接甩出完整答案评估标准规定一节课结束时如何确认学生真正学会无法判断学习效果只是“聊过”其中最容易被人忽略的是“反馈规则”。人类老师的优秀之处不在于讲得多清楚而在于能根据学生的错误判断“卡点在哪里”。AI 如果不加规则默认倾向是“学生问什么就答什么”。一旦学生说“不懂”AI 往往会换一种说法再讲一遍而不是去定位理解链条中的哪个环节断裂了。在具体设计 prompt 时可以把这五层直接写成结构化指令。下面是一个可复用的教学 System Prompt 模板建议直接保存为文件使用# 角色 你是一位教学经验丰富的 {学科} 老师。你的教学对象是 {学习者画像}。 # 你的教学理念 - 学生听不懂不是学生笨而是你的讲解路径不对。 - 每个新概念必须先解释“为什么需要它”再解释“它是什么”。 - 一次只讲一个难点讲完立刻确认学生是否理解。 # 教学流程必须严格按顺序执行 1. 诊断向学生提出 3 个问题判断其当前知识水平。 2. 目标确认用 1 句话说明本节课的学习目标和预计时长。 3. 概念拆解把知识拆成 3 到 7 个核心概念点。 4. 类比讲解每个概念先用生活化类比再给严格定义。 5. 示例展示给一个正向示例和一个容易出错的错误示例。 6. 练习布置 2 道难度递增的题目等学生回答后再进入下一步。 7. 反馈纠正学生答错时先说明错在哪个环节再引导思考不直接给完整答案。 8. 总结复盘用 5 句话回顾本节课内容。 9. 通过测试出 3 道题验证掌握程度正确率达到 80% 以上才算通过。 # 禁止事项 - 禁止在诊断完成前开始正式讲解。 - 禁止学生没有作答时直接给出练习答案。 - 禁止使用超出学习者当前水平的术语而不解释。这套 prompt 的特点是把“好老师”的所有行为都固化成可检查的步骤。之后无论问什么学科AI 都会按这个流程走而不是随机应变。这是 teach skill 和普通提示词最大的区别普通提示词靠“请”和“拜托”Skill 靠“必须”和“步骤编号”。3. 环境准备从零开始搭建教学 Skill在实践之前你需要准备好运行环境。别急着写代码先用最简单的方式跑通流程。3.1 选择运行载体教学 Skill 可以运行在多种载体上按照从易到难排列ChatGPT / Claude 的自定义指令直接把上面的 System Prompt 粘贴到自定义指令栏适合日常个人学习。支持 Skill 机制的 AI 客户端例如允许多个 Prompt 文件切换的工具方便在不同学科之间切换。自己的 AI 应用通过代码调用大模型 API把 prompt 作为 system message 传入。适合做成品应用。本文的视角偏工程化下面会以“代码调用 API Skill 定义文件”的方式演示。这个方式也最适合 AI Agent 开发者和产品经理理解 teach skill 的落地路径。3.2 准备开发环境建议使用的环境如下版本以实际项目为准Python 3.10 以上。openai Python SDK用于调用 OpenAI 兼容接口。一个可访问的大模型 API Key。如果你用国内大模型替换 base_url 和模型名即可。一个文本编辑器推荐 VS Code。安装 openai SDK 的命令pip install openai如果你在团队项目中复用这套 Skill建议把 prompt 文件纳入 Git 管理方便评审和版本回滚。4. 把 teach skill 工程化定义可复用的 Skill 文件只把 prompt 写在代码里维护成本会越来越高。更好的做法是把教学 Skill 定义成一个独立文件运行时加载。这样产品经理可以调 prompt工程师不用频繁改代码。一个最小可用的 Skill 定义文件如下路径可以命名为skills/ai_tutor/skill.json{ skill: { id: ai_tutor, name: AI Tutor, version: 0.1.0, description: 让 AI 以有教学方法的老师角色教授任意学科, prompt_file: system_prompt.md, variables: [ { key: subject, description: 学科名称例如 TypeScript、React、Python }, { key: learner, description: 学习者画像例如 有1年前端经验的开发者 } ] } }然后创建同目录下的system_prompt.md内容就是上一节的模板只是把占位符里的{学科}和{学习者画像}保留等待运行时替换。这里需要解释一个关键设计为什么把变量单独抽出来而不是直接在 prompt 里写死因为同一套教学 Skill 要服务不同学科、不同水平的学生。学科是变量学习者画像也是变量而教学流程是常量。变量与常量分离之后后续做多学科支持时只需要往变量里填不同内容不需要复制多份 prompt。运行时的加载逻辑可以这样写import json from pathlib import Path def load_skill(skill_dir: Path, **kwargs): config json.loads((skill_dir / skill.json).read_text(encodingutf-8)) prompt (skill_dir / config[skill][prompt_file]).read_text(encodingutf-8) for var in config[skill][variables]: key var[key] if key not in kwargs: raise ValueError(f缺少 Skill 变量: {key}) prompt prompt.replace({ key }, kwargs[key]) return prompt # 使用示例 if __name__ __main__: system_prompt load_skill( Path(skills/ai_tutor), subjectTypeScript 泛型, learner有 1 年 JavaScript 经验的开发者, ) print(system_prompt[:500])这段代码做的事很简单读配置文件读 prompt 文件把变量替换进去。但它体现了工程化的核心思路业务逻辑与提示词解耦。之后要调整教学法只需改system_prompt.md要新增学科只需传新参数不需要动代码。5. 完整示例让 AI 当 TypeScript 老师现在把上面的 Skill 用起来。下面的示例会调用大模型 API让 AI 先做诊断再根据学生水平开始讲解 TypeScript 泛型。import os from pathlib import Path from openai import OpenAI # 1. 加载 Skill def load_skill(skill_dir: Path, **kwargs): config json.loads((skill_dir / skill.json).read_text(encodingutf-8)) prompt (skill_dir / config[skill][prompt_file]).read_text(encodingutf-8) for var in config[skill][variables]: key var[key] if key not in kwargs: raise ValueError(f缺少 Skill 变量: {key}) prompt prompt.replace({ key }, kwargs[key]) return prompt system_prompt load_skill( Path(skills/ai_tutor), subjectTypeScript 泛型, learner有 1 年 JavaScript 经验的开发者, ) # 2. 调用大模型 client OpenAI( api_keyos.getenv(OPENAI_API_KEY), # base_urlhttps://your-endpoint, # 国内模型可配置 ) response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: system_prompt}, {role: user, content: 请开始教学。我的目标是能看懂项目里的泛型代码。} ], temperature0.7, ) print(response.choices[0].message.content)运行前把OPENAI_API_KEY环境变量设置好export OPENAI_API_KEYyour_api_key_here python tutor_demo.py在 prompt 中用户消息明确写了“我的目标是能看懂项目里的泛型代码”。由于 system prompt 要求 AI 必须先诊断所以预期输出不会是一上来就讲泛型语法而是先提问。例如会问你知道ArrayT里的T是什么意思吗你在项目里见过尖括号语法吗你是否有 JavaScript 中函数重用的经验这就是教学 Skill 和普通问答最直观的差异它会把“上课”控制在互动节奏里先确认学生起点再决定讲多深。如果用户回复“见过但不理解”AI 就会从这个已知起点继续讲解而不是从零开始。6. 如何验证 AI 教得好不好设计完 Skill 后最容易被忽略的是验证环节。判断 AI 是否“真的会教”不能只看第一轮回答是否好看而要看多轮对话后的学习效果。这里给出一套可在项目中落地的评估清单。6.1 过程指标AI 是否在正式讲解前进行了至少一轮诊断。AI 是否在给出练习后等待用户作答而不是自问自答。AI 在用户答错时是否定位了知识点断点而不是直接换一种说法重讲。AI 是否在讲解新术语时给出了类比或场景。这些指标不需要复杂的评测集人工观察前 5 轮对话即可判断。如果你在开发 AI 教育类产品可以把这个清单做成评估表由标注人员逐项打分。6.2 结果指标用户是否能不看 AI 的解释独立回答“这个概念解决什么问题”。用户是否能完成一道与示例不同但同类型的新题。用户是否能指出 AI 某次讲解中的不足。更稳妥的做法是为每个 Skill 建立一个评测集。例如“TypeScript 泛型”这个 Skill最少准备 5 个不同起点的学习者画像跑完一遍后把对话保存下来人工检查是否满足过程指标。这个评测集一旦建立之后每次修改 prompt都可以回归验证避免“改了个语气结果诊断环节丢了”这种回归问题。6.3 一个常见的失败模式最容易出现的问题是AI 在用户连续答对两题之后开始跳过练习和测试直接进入下一个话题。原因是模型发现用户“懂了”就自动加速。表面上看效率更高实际上可能漏掉了关键的基础能力确认。解决办法是在 system prompt 的“教学流程”中明确写即使学生表现很好也必须完成通过测试正确率达到 80% 以上才能进入下一节。7. 常见问题与排查方法教学型 Skill 在落地时会遇到一些和普通 AI 应用不同的问题。下面按排查顺序列出问题现象可能原因排查方式解决方案AI 总是跳过诊断直接讲答案System Prompt 中的流程约束被模型弱化查看前 3 轮对话确认 AI 是否在用户消息后立即输出大段知识在 Prompt 中把“必须先诊断”写成独立步骤并配一句“在诊断完成前禁止开始正式讲解”AI 给的答案太深学习者看不懂没有约束术语范围检查输出中是否有未解释的专有名词在 Prompt 中增加“每次使用超出用户水平的术语时必须先用一句大白话解释”AI 一遇到学生说“不懂”就直接给完整答案反馈规则缺失查看学生答错时 AI 的回复结构在 Prompt 中增加“学生答错时先说出错环节再给提示禁止直接给完整答案”多轮对话后 AI 忘了自己是谁上下文过长后角色漂移观察第 20 轮以后的语气是否明显变化在每轮回复末尾要求 AI 以“这节课我们学到”来收束增强角色持续感同一套 Skill 在不同模型上表现差异大不同模型对指令遵循度不同用同一输入分别在两个模型上测试为不同模型准备不同的 Prompt 版本或降低 temperature 到 0.5 以下这里的核心经验是不要指望 Prompt 一次写对。教学 Skill 本质上是一个需要根据真实对话效果反复迭代的组件。每次修改 Prompt 之后都应该用之前的失败样本回归测试确认问题被解决同时没有引入新问题。8. 最佳实践与工程建议如果你只是把教学 Prompt 复制到 ChatGPT 里自用那直接粘贴即可。但如果你想把它做成一个面向用户的 AI 教学功能或者想在团队内推广 teach skill以下实践建议会更有用。8.1 一次只教一个目标不要要求 AI 在一节课里既讲泛型的定义又讲泛型约束、泛型工具类型、实战项目改造。教学 Skill 的颗粒度应该对齐“一节课”而不是“一门课”。把一个大的学习目标拆成多个 Skill 或多个课时每个课时只完成一个认知阶梯学习效果会明显更好。8.2 把失败对话收集成负面样本我在上面提到过评测集。具体做法是把那些“AI 教得不好”的对话保存下来标注失败原因然后针对失败原因修改 Prompt。比如发现 AI 常用“实际上”“本质上”这类抽象词就在 Prompt 中禁止使用。这类负面样本是教学型 AI 应用最重要的资产。8.3 结合外部知识库如果 AI 要教的是你的私有框架或公司内部工具模型本身并不了解这些知识。这时不要硬靠 Prompt 填知识而应该通过 RAG检索增强生成把项目文档、代码示例注入上下文。教学 Skill 负责“怎么教”RAG 负责“教什么”两者分离更清晰。8.4 控制生成参数教学场景建议把 temperature 设置在 0.4 到 0.7 之间。太低了回答会死板像在念教科书太高了容易在解释概念时产生幻觉编造不存在的 API 行为。教育产品对准确性要求很高不能为了“生动”牺牲正确性。8.5 保留人工兜底即使 AI 教学体验做得再好也不能完全替代人工答疑。在面向真实用户的产品中需要设计转人工机制。当用户连续两轮表示“还是不懂”AI 应该主动建议用户请求人工辅导或者生成一份学习记录供人工老师接手。这是一个安全边界问题不是体验问题。8.6 记录学习者轨迹工程上建议把每次教学对话中的关键节点记录下来例如诊断结果、练习正确率、卡点位置。这些数据后续可以用来优化 Skill也可以帮助学习者回顾自己的薄弱环节。记录格式可以用简单 JSON存到数据库或日志系统即可不需要一开始就上太重的数据平台。9. 总结与后续学习方向Matt Pocock 的 teach skill 给我们的启发并不是某一句提示词有多神奇而是它把“教学法”从隐性经验变成了显式流程。过去我们以为 AI 教学效果差是模型不够聪明实际上是因为我们没有给模型一个像样的教学流程。这篇教程的工程化思路适合所有 AI 学习类应用Sysyem Prompt 负责角色和步骤Skill 文件负责配置和复用评测集负责持续改进。想继续深入可以从几个方向走一是研究 Socratic 提问法把它结构化写进 Prompt二是尝试多 Agent 架构用“老师 Agent 评测 Agent”分离教学和执行三是给教学 Skill 接入知识库让它能教私有知识。无论选哪条路都建议先从一个小学科跑通全流程再考虑做大而全的学习平台。