教会学生，还是推进研究：两种不同的共建

给一个聊天模型写下“请耐心教学生”，距离做成一位可用的助教，还有多远？

哈佛大学一项物理教学研究提供了具体线索。实验发生在 2023 年秋季，正式论文发表于 2025 年 6 月。团队并未只向学生开放一个通用聊天窗口，而是把教师的教学设计带进系统：安排分步骤的问题，提供预先写好的解题依据，并用平台控制推进顺序。因为仅靠提示词，难以稳定地让模型按教学需要展开。¹

这个改变很小，也很关键。教师希望学生学会推理，模型却可能很擅长直接把答案说出来。如果只问“它讲得对不对”，项目会错过另一个问题：学生有没有完成本来应该由自己完成的思考？

科研也有相似的分岔。一个系统可以提出越来越多的假设，但如果研究人员无法区分新证据、已有知识和模型推测，更多答案反而会增加判断负担。知识工作中的交付，因此不能只追求系统输出更多。它还要帮助使用者看清：什么值得相信，下一步怎样验证，以及什么时候应当停下来。

本章把两种相邻的共同建设放在一起比较，不把它们统计为 FDE 项目：一边是教师希望学生经历必要的思考，一边是研究者希望尽快得到值得检验的候选。相同模型能力，会在这两个目标下要求不同的产品行为。这是对前线工程的一次压力测试：如果工程师没有理解专业目标，越有效地替人完成动作，反而可能离目标越远。

助教要控制的是节奏，不只是答案

在这项物理课研究中，符合纳入条件的学生为 194 人。学生在两次课程中分别经历主动学习课堂与定制 AI 辅导，研究用前后测等方式比较学习。在这个设计下，接受定制 AI 辅导后的即时学习测验表现，优于所比较的课堂条件。这是短期、特定课程的观察，不能据此证明长期记忆保持，也不能写成“AI 已经可以普遍替代教师”。¹

更值得交付团队研究的是设计选择。教师知道一项知识应该怎样逐步建立，技术团队要把这种顺序变成学生实际经历的互动。提示词可以表达教师的意图，平台结构则决定学生此刻看到什么、能够进入哪一步，以及此前的作答如何影响后续。

教学安排由此产生一项明确取舍。给得太少，学生得不到及时帮助；给得太多，系统替学生完成了思考。平台必须决定什么时候呈现提示、什么时候推进，而不能只比较哪段回答最完整。教师的专业知识进入了软件的控制流程，不只是写成一段欢迎语。

假设学生在第一步就索要完整答案，这是一个用于说明取舍的教学例子。若目标是教会他推理，先确认卡点、提供一条提示，比立即生成标准答案更合适；若他在做资料查阅而非学习测验，直接给出带出处的答案又可能更有效。同一个用户行为，因任务目标不同而得到不同处理。

因此，评估不能只给模型答案打分。教师要看学生随后能否自己解释，工程人员要查系统是否在约定阶段放出了过多提示。前者判断学习，后者判断设计是否被忠实执行。把二者接起来，才有办法分清是教学路径需要改，还是软件没有按路径运行。

从课堂试验到日常使用，中间还有人

一项课程研究证明某种安排值得继续研究，与学校决定长期采用，并不是同一个问题。

世界银行研究者在 2025 年 1 月介绍过尼日利亚的一项课后 AI 辅导计划。项目在 2024 年 6 至 7 月开展六周，包含教师支持，研究者报告了正面的学习结果，也指出降雨洪水、教师罢工和课后工作安排影响出勤。²

这些条件把“使用 AI”还原成了一项发生在具体生活中的活动。一个学生没有完成练习，可能因为题目太难，也可能因为没有到场。一个系统没有产生预期效果，可能因为回答不合适，也可能因为安排好的学习机会没有真正抵达学生。若把所有情况都交给模型优化，团队会修错对象。

这使教育现场需要分开观察三个层次。第一，学生是否获得了使用机会；第二，他是否按预想方式参与学习；第三，他是否在离开帮助之后仍能独立完成任务。登录次数只能接近第一层，聊天时长也不能直接代替第三层。

企业内部培训同样如此。员工让工具写出一份漂亮的分析报告，不一定已经学会分析。若培训目标是培养判断，验收就不能只看这份报告是否正确，还需要看他能否解释依据、识别错误和处理一个略有变化的新问题。

这会改变技术团队与采购者的讨论。购买多少账户，是覆盖范围；安排多少辅导，是支持方式；最终形成什么能力，才是学习目标。把三者分别写清，组织才不会在第一项完成时，就宣布第三项已经实现。

一份研究，不能回答所有学科

2026 年 3 月 4 日，OpenAI 对学习模式早期研究的介绍，也呈现了不同学科不一致的结果：其随机研究中，神经科学的主要比较没有得到可区分的成绩改善，微观经济学则报告了正向差异；参与程度及初始使用问题也是研究所讨论的条件。³

这使“AI 对学习有没有帮助”显得过于宽泛。更有用的问题是：哪种学生，学习哪类材料，在怎样的支持下，经过多长时间，能够独立做对什么？这些限定词不是为了把一个有希望的结果说小，而是为了让下一位实施者知道怎样检验它是否适合自己的场景。

例如，本书提出的一个小范围试行，可以让两组学生学习同一类新材料，在相近条件下获得不同支持，再用新的、未见过的题目检验。除了平均表现，还应观察谁改善最多，谁容易依赖直接答案，谁在使用过程中被排除。真实设计要由熟悉教学研究的人确定；关键是对照必须对应组织真正关心的问题。

若只比较愿意主动使用工具的人与从未使用的人，结果可能同时反映原有动机、时间和学习习惯。系统看起来很有效，未必全由系统造成。若只在辅导结束后立即测试，也难以回答一个月之后是否还记得。这些都不妨碍做试点，却决定了试点结论应怎样写。

在这里，FDE 式的快速迭代还会遇到一个张力：产品越快更新，旧研究越难代表新版本；评估越漫长，又越可能赶不上工具变化。一个务实的做法，是保留版本、课程内容和使用条件，在修改重要行为后重新检查受影响部分。不能沿用旧版本的效果说明，却忘记新版本已经改变了提示方式或答案开放程度。

科研工具要把“想法”送到证据面前

科学研究的目标与课堂不同。课堂常有已知的知识结构，科研则可能连正确问题和可行路径都尚未确定。但两者都需要防止流畅表达替代判断。

Co-Scientist 论文在 arXiv 的第一版提交于 2025 年 2 月 26 日，第二版更新于 2026 年 6 月 29 日。第二版描述：科学家用自然语言给出目标和约束，可以补入想法、反馈与新方向；系统组织不同 Agent 生成、批评、排序和改进候选。⁴

这里的产品决定与教学助教相反。研究者不需要系统按预先安排好的课程逐步揭示已知答案，而需要控制探索方向，同时保留能够比较的不同假设。软件必须使专业人员能够改变目标与约束，而不只是批准一份已经写完的计划。

论文也把三种检查分开：系统内部用类似比赛排名的 Elo 指标比较候选，专家表达对新颖性和潜在影响的判断，再由研究合作检验部分候选。作者明确指出，Elo 不等于独立的事实答案，专家偏好也不是客观真值。⁴ 因而“排名更高”对应的是候选优先级，不能直接变成“发现已经成立”。

这类系统最容易被理解为“替科学家想主意”。从工作流程看，更重要的是候选想法如何成为可检查的对象。它依据哪些已有研究？与现有解释有什么不同？需要观察到什么，才说明它比竞争解释更好？在什么条件下应当放弃？

这些问题并不会因为参与讨论的 Agent 更多，就自动得到答案。若几个 Agent 都依赖相近的材料和模型，它们彼此赞同，仍可能只是重复同一个错误。因此，系统内部的评价可以帮助排列候选，却不能代替外部世界的检验。

研究者在这里保有的判断，也不是每一步都亲自手工完成，而是决定什么问题值得投入资源、证据是否足够、结果允许作出什么结论。技术团队应当让这些决定更容易被看见和追踪，而不是把它们封装成一个不透明的“最优方案”。

这与一般企业项目有一个值得注意的差别。商业流程常要求减少异常和波动；探索性研究有时恰恰要保留意外，因为异常可能提示原假设不成立。若交付团队只追求顺利完成预设任务，可能把最有价值的不一致当成系统噪声清理掉。

接上实验设备之后，谁还在做什么

2026 年 8 月的一份 Gemini 科研预印本，将工具使用、研究计划与真实实验联系起来。在一组材料研究中，实验室设备条件成为系统的输入，系统据此提出并排列候选方案；研究人员选取方案，再结合其他候选的信息作调整。自动设备执行实验，人仍负责装卸样品；每轮结束后，研究人员用仪器检查产物，再决定后续验证。作者观察到与目标材料接近的结构信号，但明确保留了精确结构尚未确认的限制。⁵

这条真实分工链里，生成候选、执行实验和确认发现由不同环节承担。预印本还讨论了快速模式与产物形态质量的取舍。把循环变快，并不自动使每一项观察更可信。

这几项细节，比“自主实验室”这个大词更有助于理解当前边界。软件可以推进一段工作，并不意味着所有物理操作都已经自动完成；一种结果与预测相符，也不意味着它已经具备稳定的工业用途。

对共同建设科研工具的团队而言，可以先把一次实验拆成几个不同的承诺。计划是否表达清楚？设备是否按计划执行？记录是否完整？观察是否可重复？结论是否超出数据？任何一处成立，都不能替代后面几处。

把这段实际分工与课堂放在一起，差异就不再只是“教育”和“科研”两个名称。

这张表是对前述材料的设计分析，不声称每个系统都已经实现了表中的理想安排。它让交付团队能提出有区别的需求：学生作答不能被最后一段流畅总结覆盖；实验失败也不能因为影响展示效果而从记录中消失。

假设工具把所有“不成功”都删去，教学端会失去最需要补教的误解，科研端会失去区分设备问题与假设问题的依据。两边都需要保留异常，保留的理由和下一责任人却不同。懂模型的工程师必须与懂工作的人共同决定这一层结构，否则系统可能运行正常，却稳定地保存了错误的信息。

给专业判断留下可以工作的空间

无论课堂还是实验室，“最终由人决定”都不应只出现在介绍页的最后一行。

如果教师要对学习结果负责，他需要看到学生真正做过哪些思考，而不只是聊天摘要。如果研究者要对结论负责，他需要看到原始记录、模型建议与人工修改之间的区别，而不只是最终报告。如果使用者只有点击确认的时间，没有核实所需的信息，人的参与就很难提供实际价值。

工程交付应把这些差异组织成可操作的信息。教师不必读取模型参数，研究者也不必亲自维护平台，但他们需要能改变系统对专业任务的解释：哪一步提示过早、哪一种观察被误当作支持证据、哪个候选虽然排名低却能区分两种解释。若界面只让人点击确认，这种专业参与便没有落到产品里。

能推广的，常常是一套改造办法

教育和科研的案例，很容易被推广成一个宏大承诺：某个地方有效，别处也应立即复制。真正值得带走的，往往不是一套完整答案，而是设计问题的方式。

从物理辅导案例，可以带走“把教学顺序变成系统行为”的思路，但不能原样假定它适用于所有年龄、语言和学科。从科研系统，可以带走“区分假设生成与实验检验”的工作安排，却不能把一种实验的验证结果当成其他研究方向的证据。

采购和建设也应对应这种差别。一个新机构究竟需要接入已有内容、重新设计课程、连接自己的设备，还是建立全新的评估方式？只有前两步相似，第三步完全不同的项目，成本不会因为使用同一个模型而自动相同。

若教师能在成熟平台安排教学步骤，学校也有人维护内容和评估，就可先使用现有能力。科研机构则先检查仪器接口和记录方法是否已能支撑任务。只有当专业目标不断暴露未解决的产品限制、数据连接或操作交接问题，现有团队又难以持续把它们改到可用时，才值得比较更深入的现场工程协作。这里给出的是本书的适用条件判断，不是从这些研究反推已经证实的 FDE 成效。

这使现场工程的价值出现了一个更深的尺度：它是否使组织更会提出问题、更能看清结果，以及更有能力决定下一步。如果技术做得越多，专业人员越说不清为什么得到这个答案，项目可能正在以效率之名削弱自己的目的。

在本章的两个现场中，交付的终点都不只是屏幕上出现一个好答案。学生需要把理解带走，研究者需要把证据留下。一个可靠的共同工程团队，应当帮助他们做到这两件事，并愿意用脱离即时帮助之后的表现，检验自己的工作。