注：此处的bug修复只适用于前两个单元的作业
互测阶段结束后，立即开始bug修复阶段，同学们可以开始进行bug修复工作，每次作业的bug修复阶段截止到下一次作业的互测开始。
bug修复阶段目的主要让同学们修正之前作业中的错误，为后续系列作业建立良好的基础，同时借助这种模式判断出互测阶段中的同质样例（即找出了同一处bug的不同样例），保证互测分数计算的公平性。
此阶段开始时将对每位同学公开测出自己程序bug的样例（包括公测和互测）以及对应的输入和期望输出。
一次bug修复尝试需要提交的内容包括：修复bug后的代码+对应修复的测出bug的测试样例+对应说明文档（可选）
对于一次bug修复尝试，我们会使用所有强测样例和该room内测出bug的样例，对提交的代码进行测试，只有通过原本未通过的测试用例，并且不产生新的bug才能视为有效修复，否则就是无效修复。（产生新bug：原本通过的测试用例在修复后无法通过，即需要通过回归测试）
修复代码的提交没有次数限制，但是提交的修复被认定无效之后30分钟内无法再提交修复。
以强测代码为初始版本，每有效修复一次更新一次版本，则要求该次修复和上次修复的代码变动小于等于5行。如果变动不符合该要求，但确实认为本次修复是针对于一个bug的，需要额外提交文档，阐述自己所修复的这一处bug，提交状态为待审核，之后由助教进行审核，如果通过，视为满足代码修改量要求，假若不通过，视为不满足，学生没有机会申诉。
注：该行数限制必须满足代码风格规范要求，比如一行不能超过80个字符。此外，5行的限制是一个暂定数值，课程组会根据情况适当进行调整。
有效修复且满足代码修改量要求的修复，是合并修复，否则是非合并修复。对于合并修复，其对应的样例视为shared（同质）bug，按照shared bug的方式进行奖励和惩罚。对于非合并修复，则还是一个样例算一个bug，按照solid bug的方式进行计算。
文档包括但不限于修复bug所对应的代码前后改动，bug原因简述。实际操作中在课程系统网站对应的文本框填入相关内容即可。文档的目的在于使助教认同不符代码修改量要求的代码修复确实仅修复了1处bug。
假若检查出学生使用作弊手段进行bug修复，包括但不限于下列情况的，本次作业认定为无效作业。
- 打表型修复，例如用 if... else...语句进行特判输出期望结果。
注：所有的作弊情况都会经过自动化检测和多名助教复核，如果自动化检查和多名助教都认为存在作弊行为，才会视为作弊。
未进入互测的玩家，同样使用bug修复系统，只是其需要修复的bug为强测部分的bug，其他规则一样。
在bug修复阶段，仍然首先会进行checkstyle代码风格测试，我们将会记录强测所用代码（即中测最后一次提交）的checkstyle分数作为初始基准分，任何bug修复提交，如果低于这个基准分，将会被系统拒绝该次修复。而且，在多次修复行为中，必须保证checkstyle分数是单调递增（大于等于）的，即如果本次提交高于上次的checkstyle分数，则会更新该基准分。
在bug修复中，对于强测错误样例，将其和互测错误样例视为同等的错误，按照规则进行修复即可，唯一的不同点在于，强测样例不参与同质分的分享。即比如互测样例A和强测样例B在某玩家的一次合并修复中被修复，该玩家只扣除一个bug的分，而对于提出互测样例A的人，由于此时只有他来分享该样例的分数，强测又不参与分享，故他会获得一整个样例的奖励分。
回归测试样例包括：所有强测样例+互测错误样例
-
算法：bug惩罚分=$未被修复的bug数\times\alpha+非合并修复对应的bug数+合并修复次数$。其中$\alpha=2$
-
未被修复的bug数=未被有效bug修复覆盖的出现bug的互测样例和强测样例数。
-
依据本算法，一次被合并修复的所有样例认定为一个shared（同质）bug。