本周要回答： 当 AI 改坏了项目，或者换一台干净环境时，你能把它恢复到可用状态吗？
进入本周前： 已有小工具与基本测试，能读懂核心函数；准备一个不含秘密的练习仓库。
- 01复现故障
- 02提出假设
- 03最小修复
- 04验证与恢复
学习内容与理解目标
本周学习变更历史、工作区、提交、分支、差异和撤销的关系。目标不是背所有 Git 命令，而是能回答“改了什么、为什么改、怎样回退”。同时认识依赖清单、锁文件、运行时版本和配置的区别：别人电脑上可复现，靠的是可解释的环境，而不是复制整个私人目录。
调试采用复现、缩小、假设、验证的顺序。先看错误位置和调用关系，再做最小修改；不要连续把完整日志和整个仓库扔给不同模型碰运气。补充一点复杂度直觉：遍历一次列表、嵌套遍历与集合查找有什么不同，先理解再测量，不为了“优化”过早重写。
学习链接与选读范围
| 级别 | 官方或原始资料 | 本周只读这些 | 阅读预算 |
|---|---|---|---|
| 必读 | R04 · MIT Missing Semester：Version Control (Git) | 提交、差异、分支和恢复相关部分。 | 40 分钟 |
| 必读 | R03 · MIT Missing Semester：Debugging and Profiling | 复现错误、调试器、日志和定位方法。 | 45 分钟 |
| 选读 | R07 · MIT Missing Semester：Code Quality | 类型与代码质量反馈；只接入当前真正需要的检查。 | 35 分钟 |
实战拆解
把现有可运行状态存为一个清楚的提交。加入运行说明和依赖锁文件，并检查待提交内容；不把依赖目录、凭据、原始记录和构建缓存一起推送。
人为制造一个小错误，例如分钟被当成小时、重复项不再去重。先记下如何触发、实际与期望差异，再用日志或调试器找到出错函数。
只修复导致问题的最小范围，运行相关测试并检查差异。记录“假设—证据—修复”，不要用大量截图代替故障说明。
在临时干净目录中按说明恢复项目，安装已确认的依赖并运行测试。清楚标记哪些操作可能联网；新依赖执行前先核对来源和安装脚本。
实际演练一次回退：恢复到上个可用版本，再恢复修复版本。涉及已共享分支时优先保留清楚的变更历史，不随意强推覆盖别人的工作。
交付与验收
| 本周交付 | 怎样确认真的完成 |
|---|---|
| 可复现运行说明 | 从干净目录按步骤能启动；运行时、包管理器和锁文件关系清楚。 |
| 一条可解释的修复 | 包含故障样例、最小差异和验证结果。 |
| 回退演练 | 本人实际操作过，不只是 README 里写了一句“可回滚”。 |
不用代码生成器的练习： 关闭代码生成器，定位一个预先放入的小 bug；允许查官方文档，但先写自己的原因假设，再修改并检查差异。
隐私与安全检查： .gitignore 不能撤回已经泄露的秘密，也不能从已提交历史中自动删除数据。误提交凭据应先撤销或轮换，再按平台指南处理历史；不要把“删文件”当泄露已经解决。参考 R64 · GitHub：Removing sensitive data from a repository。
落到日常生活： 给工具增加一个可靠的“坏了之后怎么办”入口。下一次报错先保留最小可复现例子，避免重新做一遍整个项目。
过关或补课判断： 能从错误信息定位到相关函数，能看懂补丁并恢复旧版本才过关。无法解释的大规模改写应拆小，而不是用通过一个测试来安慰自己。
本周可复制的协作提示
请不要重写整个项目。先复现指定故障，提出一个可验证的原因，做最小补丁并运行相关检查。给出干净环境复现与回退步骤，然后让我独立定位第二个小错误。
本周来源与核对范围
来源编号与核对说明沿用课程原文，基线为 2026-09-27。未逐一登录完成外部实验；实施前请核对最新版本与访问条件。
- R03MIT Missing Semester：Debugging and Profiling ↗
2026 讲义；先学重现、定位、调试，性能分析按需。
- R04MIT Missing Semester：Version Control (Git) ↗
2026 讲义；课程实验应在自己的练习仓库进行。
- R07MIT Missing Semester：Code Quality ↗
2026 讲义；选类型、格式、测试与代码质量反馈。
- R64GitHub：Removing sensitive data from a repository ↗
先撤销或轮换泄露凭据，再处理历史；无法承诺清除所有副本。