2026年10月8日,MIT News发布了一篇报道,介绍课程6.C31"Hack Yourself"。该课程是与实验学习小组(Experimental Study Group)合作的项目,由电子工程与计算机科学系(EECS)高级讲师Ana Bell、ESG访问讲师Carter Jernigan和ESG高级讲师Paola Rebusco共同开发。据报道,讲师Carter Jernigan介绍了一种名为"失败预演"(pre-mortem)的练习:团队想象一个项目已经失败,列出所有可能出错的地方,然后倒推如何预防这些问题。报道还指出,没有任何单一干预措施表现为普遍最优,且报道并未声称失败预演本身具有可测量的效应量。

下面的会议流程将报道中的思路用于小组课程作业，例如共同撰写的报告、实验报告、展示或持续一学期的制作项目。这些步骤是 IvyClaw 的编辑建议，并非 MIT 官方指导。报道不能证明校外学生可以选修该课程，这项练习也不承诺提高成绩。请根据作业要求、可用时间和成员需求调整会议。

为什么要做失败预演

可以先考虑几种可能的问题：成员无法参加约定的会议，两个人撰写了重叠的部分，或数据清洗需要的时间超出计划。这些是假设性的讨论素材，不是关于学生项目失败频率的研究结论。建议在启动会上留出三十到四十五分钟讨论；这只是起点，小型作业可能不需要这么久。目的是趁计划仍可调整时，找出能采取的行动。

这个提问改变了讨论的时态：“假设我们已经到了截止日期，项目却失败了，哪里出了问题？”把回答当作假设分析，而不是预测。邀请大家指出计划中的隐患，不把问题归咎于个人。如果这种表述让成员不适，应先说明目的，再共同商定大家都能接受的提问方式。

第一步:写一个具体的失败场景

会议之前,由团队负责人或发起启动会的人写一个具体、明确的失败场景,并发送给所有人。模糊的提示只会产生模糊的清单。"项目进展不顺"毫无用处。"距离截止日期还有两天,最终报告缺少分析部分,因为数据清洗花了三周而不是一周"才有用,因为它指向一个你可以采取行动的原因。

场景控制在两三句话之内。写明截止日期时刻、可见的症状,以及一条合理的事件链。你不是在预测未来;你是在给团队一个共同的对象去回应。如果你的课程有多个交付物,你可以为每个主要交付物各做一次练习,但第一次尝试时,一个场景就足够了。

第二步:各自独立收集原因,再进行比对

在任何人发言之前，先留五分钟安静时间，让每个人写下可能的原因。这样每位成员都能在听取他人意见之前形成自己的初步看法。如果朗读不方便，可以书面提交或采用其他无障碍方式。练习需要多种不同的担忧，不是比谁发言更自信或谁的清单更长。

可以请每个人先列出几个原因，包括不起眼的问题：时间冲突、分工不清、等待教师回复、文件版本不兼容，或一人承担写作而其他人等待安排。每个人依次提供想法，由一人记录到共享文档。先收集，再讨论。重复出现的担忧值得关注，但出现次数不能单独决定重要性；只有一人提出的问题，也可能影响整个项目。

第三步:挑选三个可行动的风险

不必一次处理所有可能性，可以先选三个合理、可能明显影响交付成果、且能采取实际应对措施的风险。“三个”是建议数量，不是研究证明的最优值。你们无法控制评分标准是否变化，但可以约定谁查看官方通知、谁询问不明确的要求。要区分外部事件与团队能够采取的应对行动。

尤其要检查依赖关系：哪些工作必须按顺序完成，哪些需要团队之外的资源。例如数据访问权限、学习必需工具、获得反馈或预约符合要求的展示场地。逐项问一问：如果这一步延迟，哪些后续任务会停下来？尚未确认的权限应明确标为“未确认”，同时考虑仍符合课程要求的替代方案，不要默认资源一定会到位。

第四步:指定一名负责人、一项预防措施和一个早期预警

对于这三个风险中的每一个,在共享文档中记录三件事:一名负责人(具体到人,绝不能是"所有人")、一项预防措施,以及一个早期预警信号。负责人不必包揽所有工作;负责人负责监督该风险并将其提出。

下面是一条假设性的计划示例，不是学生案例。风险：数据清洗耗时超出计划。负责人：由小组选定、负责协调数据检查的成员。预防措施：在下一个约定检查点之前，加载允许使用的数据样本并记录问题。预警：样本无法加载、缺少必需字段，或未按约定时间完成检查。应对：讨论障碍，在改变任何课程规定的范围之前先询问教师。预警阈值应符合具体数据，“几行错误数据”不是通用判断标准。

第二条假设性记录：风险——两位成员撰写的内容重叠。负责人——协调大纲的成员。预防措施——起草前共享一页分章节计划，请所有人确认职责。预警——到了约定检查点仍有章节无人负责，或两份草稿覆盖同一内容。应对——共同解决重叠并更新大纲。小组应在自己的文档中约定实际负责人姓名和日期。

第五步:约定何时回顾

一份从未被重新打开的失败预演文档只是走过场。会议结束时,约定一个具体的回顾触发条件并写下来。两种可选方式：固定检查点,例如每第二次团队会议的前十分钟;或事件触发,例如任何早期预警被触发。同时决定文档存放的位置——与你的草稿放在同一个共享文件夹——以及每次由谁把三个风险粘贴到会议议程中。

最后,尊重你所在课程的实际规则。如果作业要求导师批准团队角色或里程碑,请将你的计划提交到该流程中。失败预演是对课程要求的补充;它绝不能取代它们。

你的下一步行动

在下次小组项目启动会上，可以一次尝试这套流程：发送具体失败场景，留出安静时间列原因，收集所有人的担忧，选出三个可应对的风险，为每项记录一名负责人、一项预防措施和一个可观察的预警。结束前约定第一次回顾日期和文档位置。最终带走一组简短、团队真正能用起来的决定。

中文摘要

2026年10月8日，MIT News 在课程6.C31“Hack Yourself”的报道中介绍了失败预演：先假设项目已经失败，列出可能原因，再考虑预防措施。本文提出的小组作业会议流程属于编辑建议：独立列出原因，讨论依赖关系，选出三个可应对的风险，为每项约定负责人、预防措施和可观察的预警，最后设定回顾时间。数量和时长只是起点，不代表经过验证的最优安排；计划应遵守课程要求，也不保证消除风险或提高成绩。