最近一段时间很多人都在讨论 AI 编程助手里的一条特殊指令/teach。有人把它看成“提问模板”有人觉得只是换了个说话方式还有人试了几次之后觉得“好像也没那么神”。我的判断可能不一样/teach不只是提示词技巧它代表了一种正在被重新重视的学习方式——让 AI 从“答案生成器”变成“苏格拉底式陪练”。这篇文章先回答三个问题为什么传统教程学了容易忘/teach的底层机制到底是什么怎么把它接到你自己的开发环境里真正跑通一次“交互式学习”读完之后你不会只拿到一句“可以学 XX”而会得到一整套可配置、可复制、可验证的实践方案。1. 为什么“教程看了很多代码还是写不出来”先看一个很常见的程序员学习场景。你发现某个新技术需要掌握于是开始找教程B 站视频打开两个CSDN 文章收藏五篇GitHub 仓库放进 Star。看完之后觉得“懂了”但当自己真的动手写一个功能时却不知道从哪一行开始。你可能会责怪自己不够自律或者怀疑教程质量不够好。但问题不在“教程不够多”而在“接收方式本身”。传统教程的基本结构是线性的概念 → 示例 → 练习。它在“读”和“看”层面做了大量工作却很少要求你“主动回忆”和“现场推理”。读的时候觉得自己理解了实际上大脑只是完成了语义识别并没有建立可迁移的知识结构。更麻烦的是AI 编程助手普及之后这个局面上演得更快了。以前面对一个报错你至少会去搜日志、查文档、看源码。现在你直接把报错复制给大模型几秒钟就得到一段“看起来能跑”的代码。代码跑通了但下次换个场景还是不会。我不是说不要用 AI。恰恰相反AI 是这几年学习效率提升最大的工具。问题在于大多数人用的是“索取答案”模式而不是“建立能力”模式。/teach的价值就在这里它通过一套特定的交互协议逼着 AI 在教我们的时候不再做纯粹的“输出答案”而是通过提问、拆解、反馈让我们把知识重新思考一遍。2. /teach 是什么一个把 AI 变成导师的斜杠指令/teach不是一个标准化的官方命令而是一种在 AI 编程工具社区中广泛流传的“自定义指令”思路。你在 Claude Code、Cursor以及其它支持斜杠命令的 AI 编程助手中都可以通过配置把它变成一个真正的斜杠命令。它的核心设计是让大模型不再扮演“知识搬运工”而是扮演一位“引导型导师”。普通提问和/teach式教学区别非常明显。维度普通提问/teach 式教学AI 的目标快速给出答案让你自己推导出答案输出的形态完整代码或结论问题、场景、提示、反馈学习者的角色被动接收主动推理和作答成功标准任务完成理解建立交互节奏一次性问答多轮对话式推进我见过一个非常贴切的类比普通提问是“请厨师把菜做好端上桌”/teach是“请教练在旁边看着你炒菜只在关键时刻提醒你”。这种设计看起来简单实际对 AI 的能力要求不低。因为大模型默认有“补全欲望”你问什么它就倾向回答什么。要让 AI 忍住不直接说答案还能追问、纠偏、控制信息量必须在指令层面把规则写清楚。更重要的是它给了学习者一个“安全犯错”的空间。你在跟真实导师学习时最怕暴露自己不会。但在/teach的对话空间里你的每个错误回答都会成为 AI 继续引导的线索。这种环境非常有利于知识内化。3. /teach 为什么有效从学习原理看引导式教学如果只看表面很多人会觉得/teach只是“让 AI 多问几个问题”没什么特别。但它的有效性有比较扎实的学习科学基础。第一个关键机制是“主动回忆”。当你被迫在没有参考的情况下去回答问题、去解释一个概念时大脑会主动检索已有知识。这种检索过程比重新读一遍资料更能巩固记忆。传统教程很少制造这种检索压力而/teach的提问循环正好补上了这一环。第二个关键机制是“生成效应”。学习者在尝试自己产出答案时哪怕答案是错的后续接收反馈时的注意力也会更高。这有点像程序员调试代码如果错误信息是你自己跑出来的你会更认真地看日志如果是别人告诉你“那里有问题改掉就行”你可能根本记不住原因。第三个关键机制是“及时分层反馈”。好的导师不会一下子把一个复杂系统全部讲完而是会根据你的反应决定下一轮给多少信息。/teach的交互式设计天然支持这种“逐步去除脚手架”的过程先给提示你回答后它再揭示更多直到你能独立完成。我习惯把这种方式理解成“面向学习过程的 TDD”传统 TDD 是“先写测试再让代码通过测试”/teach是“先让你尝试思考再让 AI 用反馈修正你的思考”。两者都在用“持续的反馈循环”保证最终结果不是一次碰巧的成功。理解这个原理之后你就不会把/teach当成“聊天玩法”而会把它当成一套可以控制节奏和难度的方法论。4. /teach 落地环境与配置方法想用上/teach最简便的方式是把它配置成 AI 编程工具里的自定义斜杠命令。不同工具的配置位置和语法可能不同但思路是一致的准备一份指令文本告诉 AI 在/teach被触发时按哪套规则进行教学。下面是一个通用配置示例你可以保存在项目目录或全局配置目录里具体路径以你使用的工具文档为准# 文件路径示例.claude/commands/teach.md # 或者项目根目录/.cursor/commands/teach.md # 不同工具的配置目录不同请在对应工具文档中确认 description: 引导式互动学习不直接给答案通过提问让我自己理解 argument-hint: 你想学习的技术主题或具体问题对应的指令文件可以写成这样当用户输入 /teach 时请不要再扮演“直接给出答案的助手”。 请你扮演一位经验丰富、耐心细致的软件工程师导师。 你的教学法必须遵循以下规则 1. 首先了解背景询问用户当前的技术水平、项目语言、以及具体想解决什么问题。 2. 拆解主题把一个复杂主题拆成 3 到 5 个递进的小知识点从最基础的一环开始。 3. 一次只讲一层不要一股脑把全部内容讲完先解释当前层所需的最小概念。 4. 用提问代替直接灌输每次讲解一个片段后向用户提出一个针对性问题让用户自己推理下一步。 5. 等待用户作答用户回答完之后你才继续揭示下一层内容。 6. 判断回答质量 - 如果用户答对了简短肯定并追加一个更难一点的问题。 - 如果用户答错了不要直接给出正确答案而是给一个类比或提示让用户重新思考。 - 如果用户完全不会再提供一个最小例子但仍要引导用户自己总结规则。 7. 总目标是让用户在对话结束时能够用自己的话解释所学内容并独立完成一个最小练习。这段指令的要点是“等待用户作答”。很多 AI 工具在生成回答时倾向于一口气输出全部内容。如果你希望它停下来就得在指令中明确写清“等待用户作答”“一次只讲一层”。配置完成之后你在对话里输入/teach 我想理解 Git 里面暂存区和工作区的关系使用场景是平时提交代码经常搞混。AI 就会按你设定的规则开始交互式教学。如果你用的工具不支持自定义斜杠命令也没关系。你可以直接把上面那段规则复制到一个普通对话里再附上你想学的内容效果基本一样。5. 一套可复制的 /teach 提示词模板为了让使用门槛更低我整理了一套可以直接拿来用的中文提示词模板。它不是最长的那一种但覆盖了“了解水平、拆解任务、提问引导、纠错反馈”的核心流程。请使用“引导式教学法”教我以下主题 主题{{在这里填主题}} 我的编程基础{{例如Python 学了半年能写简单脚本但没有系统学过设计模式}} 我的目标{{例如想理解装饰器并用它做一个日志功能}} 要求 1. 不要先给我完整答案。 2. 先根据我的基础和主题设计一个最小递进路线并向我确认是否合理。 3. 从第一层开始用通俗语言解释该层的最小核心概念。 4. 讲完概念后用代码片段展示“问题场景”不要展示完整解决方案先问我你觉得这里的问题是什么 5. 我回答后你根据我的回答决定下一步答对就继续向前答错就给一个类比提示仍然不会再给出该片段的小解法但还要让我解释为什么这个解法能生效。 6. 全部学完后让我用自己的话总结整个主题并布置一个扩展练习。实际使用时把模板里的占位内容替换成自己的信息就能开始一次高质量对话。我还建议你在模板里加上一条“信息量控制”如果接下来内容较多请把回答压缩到 300 字以内确保我每轮只消化一个知识点。只有我明确说“继续”时才进入下一节。这条限制很关键。它把一次“知识轰炸”变成了可控的“增量加载”也符合第 3 部分提到的分层反馈原则。6. /teach 实战两个真实学习场景的对话示范光有模板还不够我来模拟两个具体的学习场景让你直观感受/teach的对话节奏。6.1 场景一学习 Git 工作区、暂存区、版本库的关系普通提问是这样的问Git 里工作区、暂存区、版本库是什么 答工作区是你当前可编辑的文件目录暂存区是一个临时存放改动的地方版本库是保存历史提交的地方。你读完可能点头但半小时后照样会忘记。而/teach的节奏是这样的AI我先确认一下你已经掌握了 git add 和 git commit 的基本命令但对“暂存区”到底是什么感到模糊对吗 你对。 AI好。请你现在运行 git status观察一个未跟踪的新文件会出现在哪一栏。然后告诉我你觉得 git add 这个动作在物理上可能把文件“移动”到了哪个地方 你移动到一个叫暂存区的地方 AI这没错但注意一个细节git add 并没有真的把文件复制到某个特殊文件夹。暂存区更准确地说是一个记录“下一次提交要包含哪些文件快照”的地方。 现在第二个问题如果你执行 git add 后又修改了文件再运行 git status你会看到文件同时出现在暂存区和工作区。你觉得这说明什么这种对话方式让学习者在一个个问题中主动补全了模型。6.2 场景二学习 Python 装饰器传统教程会直接给出装饰器代码def decorator(func): def wrapper(*args, **kwargs): print(before) result func(*args, **kwargs) print(after) return result return wrapper新手看完往往不理解“为什么装饰器要嵌套三层”。/teach的做法是从“需求变化”开始AI假设你有一个函数 log()现在希望每次调用它时自动打印“开始执行”和“执行结束”。在不改动 log() 函数内部代码的前提下你会怎么做 你可以写一个新的函数调用 log() 前后打印日志。 AI对这是第一层。现在问题来了如果 log()、send()、save() 三个函数都要加同一段日志你打算怎么办 你难道要写三个包装函数 AI这正是装饰器要解决的问题。装饰器的本质是“接收一个函数返回一个包装后的新函数”。现在你能否基于这个定义自己写出一个最简单的不带参数的装饰器注意AI 没有把三层结构直接倒给用户而是先让用户面对“重复代码”的痛点再引导用户理解装饰器的产生动机。这样学到的知识才不是“背语法”而是“理解设计”。判断/teach是否成功就看一件事对话结束后你能不能不看任何资料自己讲清楚“这个东西解决了什么问题为什么这样设计”。7. /teach 使用中的常见问题与排查思路/teach虽然思路简单但实际使用时会出现各种“不听话”的情况。我整理了一份排错表。问题现象可能原因排查方式解决方案AI 第一次回答就给出完整答案指令中没有明确“等待作答”检查提示词是否写明“先不要给出完整答案”加入显式规则禁止直接输出完整代码先提问AI 提出的问题太难完全接不上没有先说明学习者的基础水平查看对话开头是否符合“了解水平”的步骤补充一句“请以我当前的基础为准难度要循序渐进”每次回复内容太长变成知识轰炸缺少信息量控制观察 AI 是否一次性输出多段代码增加“每轮回答不超过 300 字”的限制学到一半跑偏开始聊无关知识缺少学习目标和范围约束看 AI 是否偏离你最初填写的主题明确写出“只围绕当前主题拆解不延伸扩展内容”AI 始终用术语解释没有通俗化没有指定解释风格让 AI 用“类比 最小代码场景”说明在指令中加入先给一个程序员熟悉的类比再进入术语自己懒得回答想要答案心态还是“索取答案”模式反问自己这个知识点想不想真正掌握降低预期把一次/teach的时长控制在 10 到 15 分钟这里最常见的问题其实不是 AI 配置不对而是使用者没有坚持“作答”。一旦你连续几次不给反馈AI 就会自动退回“直接给答案”的老路。所以使用/teach时最需要记住的是你在对话里不仅是在“看 AI 输出”你是在“训练自己的思考肌肉”。8. 最佳实践把 /teach 变成一套长期学习系统/teach不应该只是一个即用即走的指令它可以成为你日常工程学习系统里的一个重要环节。这里有六条建议。第一先定义“最小成功”。在开始前用一两句话写下“这轮学习结束后我能够独立做到什么事”。目标越具体越好比如“能自己写一个带参数的装饰器”而不是“理解 Python”。第二把/teach和真实项目绑定。空学概念容易遗忘但如果你刚好在写一个 Restful API想搞清楚中间件机制就可以直接让 AI 用/teach Restful API 中间件的执行顺序来引导你分析自己项目里的代码。第三学会“主动暴露错误”。/teach最有价值的时候是你答错的时候。不要怕答错在对话里尽量给出自己的推理过程这样 AI 才能更有针对性地修正你。第四用“费曼式收尾”完成闭环。每次/teach结束后要求 AI 扮演“学生”让你把这个主题解释给它听它来检查你的表述是否有漏洞。这一步是主动回忆的最强形式也不花多少时间。第五把优秀对话沉淀成笔记。我会把和 AI 的这段教学对话中自己回答不出来的问题单独提炼成一张卡片定期复习。知识遗忘很正常关键是留下“当时卡在哪”的记录。第六在团队里推广。/teach特别适合作为新人入职培训的辅助工具。新人面对自己陌生模块时可以直接用/teach请求 AI 引导入门减少一上来就被复杂架构劝退的概率。需要提醒的是/teach不能完全替代阅读源码、查看官方文档、动手写项目。它更像是“第一盏灯”帮你把某个黑暗的角落照亮但真正走进去还是要靠你自己。9. 总结与后续学习方向/teach最大的贡献不是发明了某种神秘提示词而是提醒我们AI 时代的学习重点已经从“更快速地获取答案”变成了“更高质量地构建理解”。如果你只想记住一个核心那就是把 AI 当作教练而不是答案供应商。让它在适当的节点提问在你犯错时给提示在你理解后增加难度。这套流程不仅适用于学 Git、学 Python也可以扩展到系统设计、架构重构、领域建模等更大更复杂的主题。我的建议是今天就可以去配置一个/teach命令然后找一个小知识点完整走一遍“了解基础 → 主动回答 → 纠错反馈 → 费曼收尾”的流程。这个过程大概只需要十五分钟但比起收藏一篇教程后吃灰它的收益要实在得多。