[EP57]伊伊子思考中|一个没有发布的教育操作系统，如何改变了我对开源的理解？

大家好，欢迎回到《教育AI智造者》。

过去两年，我做了很多看起来彼此分散的教育 AI 项目：帮助自己理解日语剑道视频的学习工具、论文搜索与阅读、从研究到产品需求的转换、知识图谱、数学概念可视化、互动学习页面、教学智能体、评价器，以及学习者运行记录。

这些项目有的仍在继续，有的已经停止，有的只是很快做出来的原型。它们看起来并不属于同一个产品，却不断把我带回同一个问题：

当人工智能已经可以非常快速、低成本地生成内容、页面和软件以后，教育产品中真正值得被认真设计的，究竟是什么？

我现在的答案越来越接近四个词：目标、判断、证据和责任。

我们想让谁发生什么变化？为什么选择这一步，而不是另外一步？看见了什么，我们才有资格说学习可能发生了？当系统并不确定时，它应该继续给出一个自信的答案，还是停下来寻找更多证据？

EduOS 就是在我试着把这些问题写进软件以后，逐渐长出来的东西。

这个名字里的 OS，是 Operating System，也就是“操作系统”。但我并不是想重新制造一个庞大的教育平台，也不是想把老师、学生、课程和人工智能全部装进同一个超级应用。相比一个所有人都必须进入的界面，我更想做的是一套教学运行环境：它可以被老师直接使用，也可以被教育科技产品放进自己的系统，还可以由更大的智能体工作框架在需要教学判断时调用。

它最初被设计成一个命令行工具。模型和智能体可以提出方案，但验证、授权、执行和记录要由更稳定的系统负责。一次教学判断使用了什么证据、调用了什么能力、为什么进入下一步，都应该能够被检查和追溯。

但这期节目不是一次产品发布。

EduOS 做到一半，被我自己推翻了。

它已经有能够运行的代码、教学图、案例、学习程序、事件记录和解释工具。也正因为它真的运行起来了，我才看见一个无法继续忽视的空缺：这套系统可以把一个教学决定执行得很规范，却没有真正回答——这个决定为什么值得产生？

如果目标、评价标准、学习困难和教学动作都已经被预先写进输入，系统当然可以稳定地执行；但最困难的教学智慧，会不会早已被偷偷放进了输入？面对一个陌生的学习者、一项新的学科任务和一组很长的材料，模型怎样发现真正的学习困难？当几种教学理论彼此冲突时，它怎样保留张力，而不是从目录里挑一个听起来合适的名字？

如果这些问题没有解决，那么完整的工程结构和漂亮的运行日志，也可能只是把一个未经证明的教学判断执行得更加稳定。

所以，我没有发布 EduOS。

但推翻一个项目，并不等于这段探索什么都没有留下。

在这期节目里，我会从最早的 YouTube Sensei 讲起：为什么一个只想帮助自己听懂剑道老师的个人工具，让我开始相信软件可以围绕人的真实需要重新生长；为什么实现越来越便宜以后，选择和判断反而变得更加昂贵；以及我怎样从一个个具体应用，逐渐走向“教学基本单元”和“框架优先，应用其次”。

我也会具体解释，什么是教学基本单元。它并不只是按钮、卡片、高亮或拖动组件，而是一种把教学目的、适用条件、学习者动作、学习证据和使用边界连接起来的设计结构。界面告诉我们“可以做什么”，教学基本单元还要回答“为什么在这里这样做，以及我们凭什么认为它可能帮助学习”。

推翻 EduOS 以后，我又开始尝试一种“工作图”：让模型先形成一个公开、可检查、可修改的学习设计状态，再围绕局部关系继续读取材料、选择能力和生成产物。它不是模型私下的思维链，也不是一张为了展示而存在的漂亮流程图。它更像一个人和系统都能共同查看的推理工作台。

这轮实验仍然没有给出一个宏大的答案。它没有证明把输出画成图以后，模型就会变得更聪明；但它让我更清楚地看到，教学设计中的关系、证据、不确定性和注意焦点，需要以什么方式变得可见。

这也改变了我对开源的理解。

开源不一定只发生在成功以后。没有发布的系统、走错的图结构、失败的提示词、解析规则、评价方法、开发日志，以及能够独立使用的教学基本单元，也可以成为公共材料。重要的不是把所有代码原封不动地扔出来，而是诚实标明：什么已经可以运行，什么仍然只是实验，什么已经被推翻，什么还没有证据。

所以，这期节目表面上是在复盘一个没有发布的“教育操作系统”，更深处讨论的其实是：

当人工智能可以生成越来越多东西以后，我们怎样让教学判断变得可见、可讨论、可修改，也保留人拒绝系统判断的权利？

内容大纲

- EduOS 为什么叫“教育操作系统”？它为什么不是一个把所有功能装进去的超级应用？

- 从一个只想听懂日本剑道老师的个人需求出发，YouTube Sensei 如何改变了我对个性化学习工具的理解？

- 软件能不能不再要求所有人进入同一个固定房间，而是让不同能力围绕真实任务临时组合？

- 当生成页面和应用越来越便宜，为什么“选择什么值得做”反而成为更昂贵的能力？

- 从教育研究到产品设计：什么是“操作化”？为什么“深度理解”“有效反馈”和“提供支架”不能只停留在产品介绍或提示词里？

- 什么是教学基本单元？它与按钮、卡片、高亮、拖动等普通界面组件有什么区别？

- 从英语长句分层到面积与周长可视化：一个教学基本单元为什么必须同时包含目的、条件、学习动作、证据和边界？

- 为什么把几个优秀组件拼在一起，并不会自动得到一节好课？教学基本单元、教学流程和完整学习案例分别保存什么？

- “框架优先，应用其次”到底是什么意思？为什么它不是说应用、界面和使用体验不重要？

- EduOS 为什么采用命令行？老师、教育科技产品和更大的智能体工作框架，可以怎样从不同入口调用同一套教学能力？

- 一个已经能够运行、测试和重建记录的系统，为什么反而被我推翻？

- 当系统擅长验证、执行和记录，却不知道一个教学决定为什么值得产生，工程完成度还能代表问题已经解决吗？

- 什么是工作图？它与思维链、知识图谱、课程目录和预先写死的控制流程有什么不同？

- 固定拓扑、字符画和严格输出格式分别带来了什么失败？为什么机器需要稳定的关系表达，而人需要一眼能够看懂的空间视图？

- 不同云端模型和本地模型在复杂指令与严格格式下表现如何？“有能力推理”和“能够被智能体安全调用”为什么是两个不同的问题？

- 一张图为什么不会自动带来长期记忆或节省上下文？局部焦点、能力选择和运行权限应该怎样分层？

- EduOS 没有发布以后，教学基本单元为什么仍然值得被整理、验证和开放？

- 开源是否只能开放成功的完成品？失败案例、实验记录和被推翻的假设，可以怎样帮助后来的人少走一些弯路？

- 真正以人为中心的软件，为什么不仅要响应人的需要，还要允许人参与定义需要、看见决定依据，并知道系统什么时候不应该越过边界？

人工智能可以生成一个看起来完整的答案，但教育真正困难的部分，是判断什么变化值得发生、什么证据足以支持下一步，以及谁应该为这个决定负责。

-----------------------关于伊伊子----------------------

伊伊子的小红书传送门

伊伊子个人网站

EduAI Builders 网站

EduAI Builders GitHub

----------------------关于听友群-----------------------

如果您对 AI 和教育的融合充满兴趣，欢迎填写我们的听友群入群申请问卷！🎧 点击链接或扫码，与更多志同道合的伙伴交流行业动态、分享实践经验，并共同讨论人工智能将如何改变教育。期待在听友群中与您相遇，共同成长！😊

请大家填写微信联系方式时，务必确认拼写完整、正确。我们遇到过几次微信 ID 无法识别的情况，谢谢大家！

============关键词解析============

EduOS｜教育操作系统

EduOS 中的 OS 来自 Operating System，也就是“操作系统”。这里的操作系统并不是一个类似电脑桌面的巨大界面，而是一种教学运行环境：它负责组织教学能力怎样进入任务、模型可以读取什么、能够调用哪些工具、什么判断必须验证，以及一次学习过程需要留下什么记录。

本期讨论的 EduOS 没有正式发布。它已经形成过可以运行的工程结构，但由于没有解决“可靠教学决定如何形成”这一核心问题，开发在中途被主动停止和重新审视。

Pedagogical Runtime｜教学运行环境

教学运行环境是模型真正开始处理教育任务时，安排它如何工作、允许它做什么，以及要求它留下哪些证据和记录的那一层。模型可以提出建议，但建议不应自动变成决定；能力、权限和责任必须被区分。

Command Line Interface（CLI）｜命令行界面

命令行不是通过网页按钮操作，而是在终端中输入明确指令，例如编译教学图、组合案例、运行活动、查看轨迹，或者询问系统为什么选择某一步。

它并不是所有老师最终都要面对的界面，而是一个透明、容易组合的底层入口。老师可以直接使用，教育科技产品可以在后台调用，更大的智能体工作框架也可以把它作为教学能力的一部分。

Agent Harness｜智能体工作框架

智能体工作框架是承载人工智能完成复杂任务的外部系统。它可能负责文件、日程、工具调用、权限、记忆和任务状态。在 EduOS 最初的设想中，更大的工作框架可以处理一般事务，并在真正需要教学判断时调用 EduOS。

Pedagogical Primitive｜教学基本单元

教学基本单元不是普通界面组件，也不是“最佳教学法”清单。一个相对完整的教学基本单元至少需要说明五件事：它想达到什么教学目的、适合什么条件、学习者需要进行什么动作、什么可以成为学习证据，以及在什么情况下不应该使用。

它尝试把教学意图、学习动作、表现形式、证据要求和使用边界连接起来，使一种教学能力可以被不同老师、产品和系统复用、修改与检验。

Operationalization｜操作化

操作化是把抽象概念转化成可以观察、执行和检验的结构。教育产品经常使用“深度理解”“有效反馈”“启发性”和“个性化”等词；如果不能继续说明它们改变了什么、产生什么证据、在什么情况下成立，这些词就很容易变成装饰。

Framework First, Apps Second｜框架优先，应用其次

“应用其次”并不是说应用、界面或体验不重要。这里的“优先”是指：先明确哪些教学判断、证据关系和权责边界，不应该随着某一个具体界面一起消失；再让不同应用成为检验这套框架的真实证据。

框架提供方向，应用提供证据。应用并不是框架的包装，它也会通过真实使用不断暴露框架的问题。

Learning Evidence｜学习证据

点击、停留时间和完成率可以提供线索，但不能被直接等同于理解。更有价值的学习证据，可能来自学习者选择的理由、修改前后的变化、能否迁移到新情境，以及能否区分相似但不同的概念。

当系统缺少足够证据时，更负责任的做法可能不是继续下结论，而是保留不确定性，并设计一个成本较低、能够区分不同原因的后续任务。

Trace｜运行轨迹

运行轨迹不是为了监控学习者的每一次点击，也不是把一个人变成一串数据。它是为了让系统能够回到真实发生过的事情：学习者提交了什么，系统引用了哪一段作为证据，依据什么标准形成了怎样的有限判断，又为什么选择下一步。

Working Graph｜工作图

工作图不是模型私下的思维链，也不是传统知识图谱、课程目录或预先写死的流程。它是一种公开、可以检查、可以修改和复用的学习设计推理状态。

它让人能够看见：当前怎样理解学习问题，哪些关系彼此支持或限制，系统此刻关注哪里，以及这一局部为什么需要某一种教学能力。

Deterministic Parser｜确定性解析器

确定性解析器通过明确规则检查模型输出，而不是再请另一个模型猜测原模型想表达什么。符合协议的结果可以继续运行；可以安全修复的格式问题会被透明标明；存在歧义、无法可靠解释的内容则会被拒绝。

模型说得有没有道理，与它的输出能不能被智能体安全地继续使用，是两个不同维度。

Human-in-the-Loop｜人在回路中

人在回路中并不只是让教师在人工智能完成工作以后按一下确认。它意味着人能够看见系统使用的证据和理由，修改目标，拒绝不恰当的判断，并决定哪些权力不能交给模型。

真正以人为中心的软件，不只要能够响应人的需要，还要让人有能力参与定义需要；不只替人做决定，还要让决定的依据可见；不只越来越聪明，也要知道什么时候不应该越过边界。

Open Source｜开源

开源不只是公布一个成功的完成品。开发日志、失败案例、提示词实验、解析规则、评价方法和可独立使用的教学基本单元，也可以成为公共材料。

负责任的开源需要说明状态：什么已经可以运行，什么仍然只是实验，什么已经被推翻，什么还缺少证据。开放的价值不在于要求所有人接受同一套框架，而在于让判断有机会被看见、争论、修改和重新组合。