AI 直接给答案，这是学习吗？

用户4405691117057
0 阅读7分钟

一个让人焦虑的场景

我女儿上小学三年级，最近开始接触鸡兔同笼问题。

有一天她问我："爸爸，笼子里有鸡和兔，一共 8 个头，26 只脚，鸡和兔各几只？"

我没直接回答，反问她："如果所有动物都是鸡，会有几只脚？"

她想了想："8 只鸡，16 只脚。"

"那题目说有 26 只脚，多了多少？"

"多了 10 只。"

"多的 10 只脚从哪来？"

她眼睛一亮："每只兔子比鸡多 2 只脚，所以有 5 只兔子，3 只鸡！"

这个对话花了三分钟。但这三分钟她自己想出来的结论，比我直接说"鸡 3 只兔 5 只"更值。

但我们的 AI 不这么讲题

我试过让 ChatGPT、Claude、DeepSeek 给她讲题。

结果是：一秒钟给出答案。

设鸡为 x 只，兔为 y 只，则 x + y = 8，2x + 4y = 26，解得 x = 3，y = 5。 答：鸡 3 只，兔 5 只。

信息量完全正确，但孩子学不到任何东西。 她看到的只是两个方程，然后答案就出来了。她不会记住，也不会理解为什么要设未知数。

更糟的是，她很快就会依赖这种回答——下次遇到问题，不用想，直接问 AI。

老师的板书为什么有效

回想我们自己上学时的体验。数学老师在黑板上讲一道题，通常是这样的：

  1. 画图：先画一个笼子，画几只鸡和兔的简笔图
  2. 提问："你们数一数，一共几个头？几只脚？"
  3. 引导："如果全都是鸡，脚会变成几只？为什么会变少？"
  4. 板书演进：每讲一步，就在黑板上补一笔——连线、写算式、画箭头
  5. 留白："剩下的你们自己想想。"

整个过程，板书是逐步展开的。学生一边看老师写，一边思考下一步。每一个画面都在提示"刚才讲了什么"、"现在该想什么"。

这不是"把答案写出来"——而是把思考的过程可视化。

现在的 AI 为什么做不到

传统 AI 对话是纯文本流。一条一条消息往下滚，没有画面，没有空间感。

即使 AI 能生成图（比如 GPT-4 画图功能），也通常是"先想好答案，再画一张配图"——图和讲解是分离的，不是"边讲边画"。

而且，"给答案"是 LLM 的本能。它们被训练成"尽快给出正确答案"。要让它学会"先不给答案，引导用户自己想"，需要非常刻意的设计。

我试着做了一个

我想做一个东西，让 AI 也能像老师一样：

  • 一边在黑板（屏幕右侧）上写板书、画图、推公式
  • 一边在对话框（屏幕左侧）里提问、引导
  • 用户可以在同一个窗口里追问，黑板会跟着更新

技术上，这属于 MCP（Model Context Protocol）技能——让任何支持 MCP 的 Agent 框架都能调用。

下面是它跑出来的样子：

（此处插入鸡兔同笼的板书截图）

右边是黑板，画着一个笼子、几只简笔的鸡和兔、题目条件的板书。左边是对话框，AI 正在用苏格拉底式提问："如果所有动物都是鸡，会有几只脚？"

注意几点：

  • AI 没有直接说答案
  • 它先画了图，让孩子建立直观
  • 它在引导孩子自己想出"多出的脚从哪来"
  • 黑板是逐步画出来的，一笔一笔，像老师写字

板书用什么画？

要让 AI "画板书"，需要一个它能稳定输出的图形格式。

试过几种方案：

  • Canvas 程序化绘图：太抽象，LLM 输出容易乱
  • 图片生成模型：太慢，且不能精确控制内容和排版
  • SVG：最合适

原因有四条：

  1. LLM 对 SVG 最熟悉——训练数据里有大量 SVG 代码，输出质量稳定
  2. 浏览器原生渲染——不需要额外引擎
  3. 可以嵌入数学公式——通过 foreignObject 把 KaTeX 的输出塞进 SVG
  4. 文本内容可以程序化提取——用于 TTS 朗读

实际用下来，SVG 方案的板书质量超出了我的预期。LLM 能画出几何图形、坐标轴、数轴、箭头、分步推导，而且排版基本合理。

关键挑战：怎么让 AI "不直接给答案"

这是整个项目最费劲的部分。

传统的做法是在 system prompt 里写一堆"约束"：

你是陪读学长，苏格拉底式提问，严禁直接给答案……

但问题是：约束放在 system prompt 里，多轮对话后 LLM 会逐渐"忘记"——尤其当上下文变长时。

这个项目用的方案是：把约束写进"工具描述"里。

具体来说，AI 每一轮都要调用一个叫 show_and_wait 的工具——这个工具用来"把板书推送到屏幕，然后等待用户输入"。

而这个工具的描述文档里，就写着教学法的约束：

【教学方法 —— 严格遵守】
1. 苏格拉底式引导：严禁在板书或文字中给出最终答案。
   你只能引导学生自己得出答案……
2. 每轮只聚焦一个核心问题，等用户回应后再进入下一步。

因为 AI 每轮调用这个工具时都会重新读一遍描述，所以约束"持续在场"，不会因为上下文变长而失效。

实测下来，在两个不同的 Agent 框架上，约束都能稳定生效。

一个技术上的"反直觉"选择

这里有个细节值得说：

一开始我尝试的做法是：在 MCP Server 里内置一个 LLM，让它自己处理弹窗里的对话。

但很快发现不对劲——用户的主对话已经有 LLM 了，弹窗里再来一个，就变成"两个大脑"。主对话里的上下文传不进去，弹窗里的回复也不影响主对话。用户体验很割裂。

后来我想通了：让调用方框架的 LLM 直接驱动弹窗。

怎么做到？利用 MCP 工具的阻塞特性：

AI 调用 open_tutoring(topic) → 弹窗打开
AI 调用 show_and_wait(content) → 推送板书 + 阻塞等用户输入
用户在弹窗里打字 → 工具返回"用户说：XXX"
AI 看到用户输入 → 生成新板书 → 再次调用 show_and_wait

这就绕开了"两个 LLM"的问题——全程只有一个 LLM，就是调用方的那个。

代价是：依赖 AI 遵守"生成回复后必须再次调用工具"的循环协议。目前实测下来，主流模型都能稳定做到。

一些可以复用的经验

如果你也在做类似的东西——让 AI 用可视化的方式教学，这几点可能有参考价值：

  1. 不要低估"板书"的价值。人脑对空间关系的记忆远强于线性文本。逐步演进的板书，本身就是一种"思维脚手架"。

  2. "给答案"和"引导思考"是两种完全不同的能力。目前的 LLM 前者很强，后者需要刻意设计。

  3. 把教学约束放在"工具描述"而不是"system prompt"里，能让约束持续在场，对抗上下文退化。

  4. SVG 是 LLM 输出图形的最佳格式——不是因为它完美，而是因为它处在"LLM 熟悉度"和"浏览器可渲染性"的甜蜜点。

项目是开源的

如果你对这个项目感兴趣：

MIT 协议，欢迎试用、提 issue、或者 fork。

它本身是一个"板书讲解"技能，但底层的骨架（弹窗 + 阻塞循环 + 结构化输出）是通用的——把 SVG 黑板换成 Mermaid、代码编辑器、3D 场景，就是另一个技能。

我一直觉得，好的教育不应该只是"答案的高效传递"，而应该让学习者看到思考的过程。老师写在黑板上的每一笔，都是在演示"怎么想"。

数字时代，AI 应该能做得更好——不只是更快地给答案。

avatar
文章
阅读
粉丝