模型能力不是瓶颈,学习环境的设计才是。
引子:一场理论一致、形态分歧的讲座
2026 年,MIT Schwarzman College of Computing 的学习科学家 Grace Lin 做了一场题为 "AI Coding and Learning" 的讲座,介绍了 MIT 开发的 AI 辅助编程教学平台 PyTutor。讲座的核心论点我完全认同:AI 辅助编程在教育中的关键挑战不是"该不该用 AI",而是如何设计恰当的摩擦(friction)——AI 应该减少不必要的认知负荷,但必须保留生产性的挣扎(productive struggle)。
讲座中的两个实验令人印象深刻。Sindarin 精灵语翻译实验中,用 LLM 翻译的小组快速完成了任务,用纸质材料手动摸索的小组慢得多;但去掉 AI 之后的独立测试里,学习组能完成翻译,AI 组无法完成。更早的 Fortran 实验结论更尖锐:第一轮 ChatGPT 组最快完成,第二轮独立测试中纯网络资源组全部正确,ChatGPT 组零人正确。
你让别人替你做的部分,你学不到。 这个结论与我一直以来的判断完全一致。
但听完整场讲座,我的结论是:PyTutor 的教育理论是对的,产品形态是错的。 这篇文章想说清楚为什么,以及更好的形态应该长什么样。整个框架分四层:教育哲学、产品形态、技术方案、评估方式。
第一层:教育哲学
任何 AI 教育产品的设计,背后都站着一套对学习本质的判断。我的判断有三个:
第一,学习必然伴随痛苦。 这里的痛苦指认知阻力,不是外部压力。它有几种典型形态:你原来的理解不够用了,必须修改它;你原来的直觉失效了,必须重新建立判断;你以为自己懂了,但一做题、一表达、一迁移,马上发现其实没有懂。这些摩擦正是认知改变发生的地方。
AI 降低摩擦是一把双刃剑。它可以把材料解释得更清楚、随时回答问题、拆解复杂内容、降低入门门槛——这些都有价值。但摩擦减少之后,很容易产生一种**"假装学会"的状态:我看懂了、我听懂了、我跟着做了一遍、我完成了任务,于是我觉得自己掌握了。而真正的掌握要经过调用、判断、迁移、纠错和反复使用**——这些环节不发生,"学会"就停留在体验层面。
这也是我怀疑"成瘾式学习"的原因。成瘾机制影响的是行为,不直接影响认知。多邻国是典型例子:连续天数、任务完成、即时反馈、奖励系统都做得很好,但用户获得的正反馈来自"我完成了任务",而不一定来自"我真的掌握了语言"——这是两个不同的爽点。你可以让人沉迷于学习的行为,却不能保证认知真的发生变化。所以 AI 的角色应该是帮助学生穿过困难,而不是用更顺滑的体验让学生绕过困难。
第二,自控力也是天赋。 不是所有人都能被教育改变。承认这个边界不是放弃,而是有效设计的起点——为愿意学的人把环境做到最好,比假设所有人都能被某种机制"激活"更诚实。
第三,尊重他人的不作为。 包括选择不学习、选择躺平的权利。教育者应该在他人的生活中保持退场的能力,而不是把"让所有人学会"当作可以无限侵入的正当性。
在这三个判断之上,可以把摩擦分成两类:
- 生产性摩擦(generative friction):必须保留。做题、调试、表达、迁移时暴露出来的认知阻力,是学习真正发生的地方。
- 不必要摩擦:应该消除。工具安装、环境配置、文件管理——这些与学习本身无关的障碍,只会消耗学生在到达生产性摩擦之前的耐心。
AI 的正确角色由此可以一句话概括:减少不必要摩擦,保留生产性摩擦。
到这一层为止,我和 PyTutor 是高度一致的:
| 设计原则 | PyTutor | 我的观点 |
|---|---|---|
| 认知卸载 ≠ 学习 | ✅ 教学护栏,不直接给代码 | ✅ 不替学习者消化资料 |
| 保留生产性摩擦 | ✅ design friction | ✅ 学习必然有痛苦过程 |
| 反馈指向产物而非指向人 | ✅ 逐步引导 | ✅ 锚定约束 |
| Bloom "apply/analyze" 层面的提升 | ✅ 有实验数据支持 | — |
理论一致。分歧出现在下一层。
第二层:产品形态——为什么 PyTutor 的形态不对
PyTutor 自己制造了一种不必要摩擦
PyTutor 是一个专为教育场景设计的 Web IDE:白板手绘、多人协作、教学护栏、课程上下文感知、主动/被动双模式。工程上做得很认真,已经覆盖 12 门课程、2500 多名学生。
但它重新造了一个学习环境。学生要从正常的工作流中跳出来,进入一个专门的"学习平台"。用前面的框架来检验:这本身就是一种不必要摩擦——不是生产性的认知摩擦,而是工具切换的摩擦。
更深一层的问题是身份设定。在专用学习平台里,学生的身份是"被管理对象":他在一个为他设计的沙盒里完成练习,产出是练习答案,凭证是平台内的成绩。这套结构延续的依然是旧的教学范式,只是把 AI 嵌了进去。
更好的形态:Agent 嵌入真实工作流
我认为正确的形态是反过来的:学生不用"进入学习模式",他们本来就在工作,学习自然发生。
具体来说,学生在 VSCode 这样的真实开发环境里工作,AI 以 agent 的形式嵌入环境——扫描文件变更、感知代码状态、按需介入。两种形态的差别可以列成一张表:
| 维度 | PyTutor | Agent + 真实环境 |
|---|---|---|
| 环境 | 专用 Web IDE | VSCode / 真实开发环境 |
| 交互方式 | 学生主动问 AI(聊天窗口) | agent 扫描文件,按需介入 |
| 身份 | 学生 = 被管理对象 | 学生 = 开发者 |
| 工作产出 | 练习答案 | 真实项目文件(可 git 追踪) |
| 学习凭证 | 平台内成绩 | 工作区本身就是学习证据 |
| AI 的位置 | IDE 旁边的聊天面板 | 嵌入环境、透明、后台运行 |
身份的转变是关键。当学生以开发者的身份在真实环境里工作,他的产出是真实的项目文件,他的学习证据就是工作区本身——不需要平台替他记成绩,git 历史比任何成绩单都诚实。
介入方式是一条可调光谱
PyTutor 有 proactive / reactive 两种模式:前者在检测到学生空闲太久或反复犯错时主动介入,后者只在学生提问时响应。这个思路是对的,但两档太粗了。
Agent 的优势在于介入强度是连续可调的,设计哲学决定一切:
- 保守模式:agent 只在工作区里维护一份 state.md 记录进度,学生下次回来自己看。AI 完全退场,只留痕。
- 被动模式:学生问了才答;扫描到文件变更时默默记录,不出声。
- 主动模式:检测到卡住的信号——文件长时间没有变更、代码反复报同一个错——主动提示。
- 监管模式:agent 自动执行 git commit 记录学习过程,适用于学校场景。
这条光谱比两档模式丰富得多,而且不需要任何专用界面。agent 通过文件变更、代码状态、git 提交节奏来判断介入时机,学生不需要主动开口。这也呼应了第一层的哲学:介入强度可以调到零(保守模式),"退场"本身被设计进了系统。
第三层:技术方案
个人学习场景:文件即协议
个人场景下,整个学习系统就是一个普通的工作区目录:
工作区/
├── mission.md ← 学习契约
├── plan.md ← 学习计划
├── profile.md ← 学习者画像
├── state.md ← 当前状态
├── resources.md ← 学习资料
├── notes/ ← 学习笔记
├── exercises/ ← 代码练习
└── ...
agent 定期扫描文件变更,基于 mission.md 和 plan.md 提供帮助。所有状态都是明文 Markdown 文件,学生随时可以查看、修改、否决——透明性不是附加特性,而是结构本身。
已有的实现:learning-plan-skill
这个方向不是纸上设想。learning-plan-skill(当前 v0.5.1)是它的一个现行实现:一个自学陪伴 skill,围绕一个主题完成"摸底 → 计划 → 资料整合 → 检查点 → 陪伴学习"的全流程,所有状态用 Markdown 记录、用 git 追踪。它的几条设计规则正是前面哲学层的落地:
- 自主性前提与负功能清单。 skill 的第一条前提是"学习者具有自主性"——主导权、进度责任、结果责任都在学习者,不试图用功能去适配缺乏自主性的人。由此明确列出不做的功能:进度百分比、连续打卡天数、徽章、掌握度仪表盘、与他人比较。这份清单就是"怀疑成瘾式学习"的工程表达。
- 两个阶段,行为准则相反。 规划期 agent 主动(摸底、生成计划、抓资料、设计检查点);学习期 agent 被动,默认状态是等待——学习者开口才行动。理由写得很直接:agent 替学习者"消化"资料,等于剥夺学习本身。
- 检查点是邀约,不是关卡。 走"交付—提交—检查"三步:agent 告知本阶段检查点后不再提起,学习者完成后自己提交,提交才是核对的邀请。学习者跳过检查点直接进入下一阶段时,只提醒一次,然后如实记录为学习者的主动选择——不强制、不阻拦。这是"尊重退场"在协议层的样子。
- 锚定约束。 所有反馈指向资料和产物,不指向人:可以说"你的复述与讲义 3.2 节在 X 处不一致""代码没有通过边界用例 7",不可以说分数、等级、"你已掌握"。
个人学习场景的目录结构、git 留痕(包括 agent 对用户计划改动的异议也以 objection: 类型写入 commit message)、按需介入的节奏——本文第三层描述的形态,很大程度上就是这个 skill 的产品化方向。
学校场景:真实工具的组合,而非专用平台
学校场景不需要重新发明学习平台,只需要组合现成的真实工具:
- 云端 VSCode(如 GitHub Codespaces)作为统一工作区,解决环境配置这个最大的不必要摩擦;
- 定制 VSCode:预装 agent 插件,集成 AI 助手;
- Git 作为过程监管:agent 自动提交,形成学习过程记录。
学生全程在真实开发环境里工作。他们离开学校后用的还是同一套工具——学习环境和工作环境之间没有需要跨越的鸿沟。
Git 双层提交设计
监管和自主可以在同一个仓库里共存,靠两层提交分开:
- agent 自动提交(监管层):定期或文件变更达到阈值时自动 commit,记录学习过程;
- 学生手动提交(工作层):学生自己用 git 做版本控制、回退、分支实验。
两层通过 commit message convention 区分(如 [agent] auto-snapshot 与学生自己的提交)。值得注意的是,学生对 git 的感知程度本身也是一个设计选择:可以完全不感知(git 只是后台记录仪)、感知但不操作(知道有历史可查)、感知且操作(把 git 本身作为学习内容)。
Git 是天然的学习行为记录仪
git log 本身就是最好的学习分析数据源,不需要额外埋点:
| 行为模式 | git 表现 |
|---|---|
| 真实学习 | 小步提交、逐步调试、渐进重构 |
| 复制粘贴 | 一个大 commit 丢进完整代码 |
| 卡住 | 某文件长时间没变更,然后突然完成 |
| 真正理解 | commit message 与代码内容匹配,有调试痕迹 |
PyTutor 需要专门的"学生进度建模"来追踪形成性评估;在真实工作流里,这些数据是工作的副产品,免费且更难伪造。
第四层:评估方式——小黄鸭测试
伪代码评估的问题
MIT PyTutor 和 IB DP 计算机科学课程都接受伪代码提交。这个做法需要重新审视。
我最初的反对比较直接:古典编程时代,伪代码不等于代码实现,不能把伪代码等同于编程能力;到了 AI 时代,从伪代码到代码只差一次 AI 调用,更没有必要接受伪代码——伪代码评估本质上是"你大概知道就行了",而这正是"假装学会"的另一种形态。
但这个观点需要修正。问题不在伪代码本身——在当前时间节点,伪代码几乎可以和代码画等号,大模型可以在两者之间无损转换。
真正的问题是:如果学生对代码完全不理解,他就无法判断自己逻辑严密的伪代码和大模型给出的实现之间是否吻合。 不需要能找出所有错误,但至少要能大致看懂大模型的实现逻辑。伪代码评估跳过了这个关键环节——它只验证了学生脑子里有没有思路,没有验证学生能不能把思路和真实实现对齐。
举个具体的例子:看 GPT 生成的代码,经常会发现它试图用大量特判和关键词列表来跳过错误,而不是用泛化的方法处理。一个理解代码的学生能看出这种模式并质疑它——"为什么这里用 if-else 堆叠而不是抽象一个通用处理?"但如果学生只写过伪代码,他看到这段代码只会觉得"逻辑差不多,应该没问题",完全察觉不到实现质量的差距。在一个学生大量依赖 AI 生成代码的时代,"对齐思路与实现"恰恰是最不能跳过的能力。
小黄鸭测试:面对 agent 的版本
那评估应该怎么做?我的方案是把传统的小黄鸭调试反过来用。
传统小黄鸭调试是程序员对着玩具鸭讲解自己的代码,在讲解过程中自己发现问题。换成 agent 之后,duck 变成一个能追问的考官:
学生:这个函数先遍历数组,然后把每个元素乘以 2
agent:为什么要用这个遍历方式?换成 map 可以吗?
学生:可以,但是我需要 index……
agent:为什么需要 index?
这种追问式讲解天然防作弊:
- 复制粘贴的代码:讲不出来为什么这么写;
- AI 生成的代码:能解释每一行,但说不清它们为什么组合在一起;
- 真正理解的代码:能解释设计选择、能讨论替代方案、能指出哪里可能有问题。
而且这套评估不需要任何额外基础设施。学生就在 VSCode 里,agent 扫描代码文件,然后说一句"给我讲讲这个函数做了什么"。事实上 learning-plan-skill 已经有这个协议的雏形:评测通过 ≠ 理解,学习者提交 lab 后,agent 在同一次受邀检查内追问一个"为什么"。小黄鸭测试是把这一问延展成一场对话。评估是环境设计的一部分,不是独立于学习之外的考试环节——这和前三层是同一个逻辑的延续。
结语:能力不是瓶颈,环境才是
最近有一个衡量 AI 经济的度量衡叫 Dollar per Watt($/W):年总收入除以年总耗电量,看每一瓦特的电到底换回了多少钱。这个指标暴露出一个有意思的事实:OpenAI 的 $/W 三年稳定在 10 美元左右,加了大量算力也没有抬升——能力提升是真实的,但行业还没有解决"怎么把这个能力变成收入"。前沿实验室每瓦特赚的钱,甚至不如云巨头把瓦特当原始算力租出去。能力和变现之间,桥还没建好。
AI + 教育面对的是同构的问题:AI 的能力提升是真实的,但教育产品尚未解决的是"怎么把 AI 能力变成学习者的真实认知改变"。 答案不是更强的模型——对于编程基础教育,几乎所有主流大模型的能力都已经足够。答案是更好的学习环境设计。环境就是教育领域的那座桥。
PyTutor 们答对了哲学题:认知卸载不等于学习,生产性摩擦必须保留。但它们在形态题上交了一份旧答案:又造了一个平台,又设了一道学生需要跨过去的门槛。
更好的答案是让 AI 消失在环境里。学生以开发者的身份在真实工具中工作,agent 在后台感知、按需介入、可以退场到零;git 既是版本控制也是学习记录仪;评估不是考试,而是一只会追问的鸭子。
学习不需要一个专门的地方。它应该在工作发生的地方自然发生。
2026-06-12
基于 MIT 讲座 "AI & Coding: AI Coding and Learning"(Grace Lin, MIT Schwarzman College of Computing)的对比分析
关联:learning-plan-skill v0.5.1 / 《我为什么怀疑成瘾式学习》/ "尊重他人的不作为" / Dollar per Watt 讨论