检查点 3：中期检查
截止时间：2026 年 11 月 8 日（周日）23:59（北京时间）。提交方式见网络学堂。
本次在检查点 2 的基础上推进核心功能，结合第 3 讲的代码生成、理解与调试方法，提交核心模块代码、代码生成与调试过程记录（含最小可复现示例）、当前问题清单。每位同学独立提交，计入“阶段检查点”5 分。反馈安排在 11 月 10 日第 5 讲。
一、核心模块与本阶段进展
至少跑通一条核心流程，或完成一项可以验证的核心改动。在报告中说明它对项目目标的作用、涉及哪些模块，以及相较检查点 2 新增或改进了什么。注明检查点 2 的版本和本次提交版本，区分已有功能与本阶段工作。
以下任务仅供参考，按自己的项目选择合适的范围：
| 类别 | 本阶段参考任务 | 可核对的结果 |
|---|---|---|
| 软件开发 | 接通一条主要使用流程，如录入、处理、保存与重新打开，或完成游戏的一段核心规则 | 给定输入后的实际输出或状态变化，正常操作与错误操作的处理 |
| Agent 应用 | 完成一项具体任务的模型调用、工具执行与结果检查 | 输入、工具调用、最终结果及出处；失败或超出能力范围时的反馈 |
| 开源项目优化 | 实现核心补丁、功能扩展或优化，检查相关旧功能 | 固定版本与输入下的修复前后结果、测量或回归记录 |
| 数据处理与可视化 | 接通从输入数据到计算、导出或展示的主要流程 | 可共享的小样例、计算口径、输出与人工核对结果 |
本人需要实际运行当前成果，记录操作或命令、输入、预期结果与实际结果，至少核对一个正常情形和一个相关的边界或错误情形。可以使用手工操作、小测试或测量；采用模拟数据或模拟接口时需明确标注。
尚未完成的模块如实列入问题清单。本次不要求完成整个项目，但不能只提交界面截图、空骨架或 AI 对“功能已完成”的描述。
二、代码生成与理解记录
选取本阶段一项有代表性的核心开发工作，说明如何借助 AI 生成、补全或修改代码，以及自己如何检查这些改动。开源项目也可以从理解待修改模块入手。
记录至少说明：
- 任务与上下文： 要解决什么问题，给 AI 提供了哪些相关文件、接口、输入输出样例和约束。
- 实现与理解： 核心模块的职责、主要调用或数据流；选取一段关键逻辑，结合实际代码解释其作用。
- 审查与取舍： 检查了哪些改动，接受、修改或拒绝了哪些建议，为什么。
- 运行结果： 如何判断改动符合要求，对应的命令、输出和 Git 提交是什么。
正文可以节选关键提示和代码差异，完整对话另附。使用代码位置、输入输出和运行结果支持说明，不只粘贴 AI 对代码的解释。本次重点是代码审查与调试，不要求重新做一组检查点 2 的 fork 对比；实际使用了 fork 时仍应保留对应记录。
三、调试案例与最小可复现示例
选取本项目中的一个真实问题，记录“复现问题—收集证据—定位原因—修改—回归验证”的过程。问题可以是报错、错误输出、边界处理缺失、状态异常或明显的性能问题，不一定表现为程序崩溃。
最小可复现示例（MRE）
保留触发问题所需的最少代码、输入和操作，去掉无关数据、模块和界面步骤，让他人能够按说明复现。图形或移动端项目可以提供最少的操作序列及必要样例，不必另写一个命令行程序。
复现说明至少包含：
| 内容 | 需要说明什么 |
|---|---|
| 问题版本与环境 | 能复现问题的 Git 提交、必要依赖与运行条件 |
| 触发步骤与输入 | 具体命令或操作、最小样例，以及准备方法 |
| 预期与实际 | 正确行为应是什么，实际出现了什么；附相关报错、日志或截图 |
| 定位依据 | 排查过哪些可能原因，哪些证据支持最终判断；尚未确认时写明假设 |
| 修复与复查 | 修改位置与提交，原失败场景重跑结果，以及相关正常功能的回归结果 |
复现材料可放在仓库的测试或示例目录中，也可单独提供，报告中标明路径即可。若问题已修复，保留修复前的提交及复现方法，无需为了演示把错误重新放进最终代码。
说明 AI 在解释报错、提出假设或生成修复时做了什么，以及本人如何判断建议是否解决了原因。仅隐藏报错、跳过失败步骤或删掉失败测试，不能说明问题已解决。
若本阶段尚未发现缺陷，可以复现同一项目此前遇到的真实问题，注明当时的版本，并在当前版本做回归检查。不要为提交材料编造故障或修复过程。若问题尚未解决，提交可复现的现象、已做的排查和下一步计划，如实说明当前进度。
四、当前问题与后续工作
列出当前影响项目推进或使用的主要问题，写清具体表现、影响、已做的排查，以及准备采取的下一步。例如，“某输入导致结果错误，已定位到解析模块，下一步补边界判断”，比“继续优化系统”更便于检查。
说明哪些问题需要优先处理，哪些功能准备延后或缩减。需要大幅更换选题或调整主要目标时，请及时联系助教。详细任务分解、里程碑和 AGENTS.md 在第 5 讲学习后随检查点 4 提交。
五、提交材料
提交阶段报告、本阶段完整 AI 交互记录、含 Git 版本历史的代码仓库，以及调试案例的复现材料。已有文件可以直接引用路径，不必在多个目录重复放置。
文件结构参考
学号_姓名_checkpoint3/
├── report.md # 中期报告，格式按网络学堂要求
├── ai-records/ # 本阶段完整 AI 交互记录
│ └── ...
├── repro/ # 最小复现说明与必要样例，也可放在 project/ 内
│ ├── README.md
│ └── ...
├── attachments/ # 可选：未放入报告的运行输出、截图等
│ └── ...
└── project/ # 打包提交仓库时提供；交仓库链接时可省略
├── .git/ # 保留版本历史
├── README.md # 环境、依赖、启动与检查方法
└── ... # 源代码、依赖清单、测试和必要样例
仓库链接或打包文件均按网络学堂要求提交。使用链接时，注明地址、分支和提交编号，确认已推送且助教可访问；使用压缩包时，保留 .git/，解压后应能查看历史。提交前确认工作目录中的核心改动已进入本次 Git 提交，报告所写版本与实际材料一致。具体操作见 Git 使用基础。
不打包虚拟环境、依赖安装目录或缓存。私有数据用可共享的小样例替代，并检查代码、对话和历史中的密钥与个人信息。
报告至少包含
- 基本信息与阶段进展： 姓名、学号、项目名称、当前目标，相较检查点 2 的新增工作和范围调整。
- 核心模块与运行结果： 模块作用、关键逻辑、启动方法，本人正常与边界情形的实际核对结果。
- 代码生成与审查： 一项代表性任务的提示、上下文、代码改动，以及本人接受或修改建议的理由。
- 调试案例与 MRE： 问题版本、触发步骤、预期与实际、定位依据、修复与回归结果；尚未解决时写清排查进展。
- 当前问题与下一步： 主要缺口、影响和准备采取的具体措施。
- 提交版本与材料位置： 仓库获取方式、提交编号、完整 AI 记录和复现材料的路径。
完整保留本阶段相关会话，包括失败尝试和可导出的工具执行结果。之前阶段的记录继续保存，本次可以注明其位置；同一段材料不必重复上传。
六、评分标准（5 分）
本次沿用阶段检查点评分标准，各类别使用相同分值。
| 分项 | 分值 | 本次评价内容 |
|---|---|---|
| 按期提交与材料完整性 | 1 | 按时提交；报告、完整 AI 记录、含版本历史的仓库和复现材料可访问，版本与路径对应 |
| 阶段成果 | 2 | 核心模块或核心改动有实际进展和可核对的结果；本阶段贡献、当前问题与限制清楚 |
| 方法与过程记录 | 2 | 能解释关键代码与审查判断；调试案例有复现、定位证据和修复或排查过程，包含本人的运行核对，AI 记录与 Git 改动能对应 |
不按代码量、对话长度或提交次数给分。调试未完全成功时，按实际进展和已有证据评价，不把失败本身当作过程记录无效。
七、提交前自查
- 已说明相较检查点 2 的新增工作，并注明前后版本。
- 核心模块或改动有实际运行结果，本人核对了正常与边界情形。
- 能结合代码解释关键逻辑，说明对 AI 建议作出的判断。
- 有真实调试案例和最小复现材料，能按步骤重现问题或核对修复。
- 当前问题和后续措施具体，未把待实现内容写成已经完成。
- 完整对话、复现材料、代码与 Git 版本对应，助教可以访问。
- 已按网络学堂说明提交。
后续时间安排：检查点 4 于 11 月 15 日截止；同伴互评于 11 月 22 日截止；根据同伴互评反馈修改后，于 11 月 29 日提交最终版。上述截止时间均为当日 23:59（北京时间）。12 月 1 日进行课堂展示，展示项目由教学团队依据最终提交质量选定。详见课程安排。