第 3 讲：代码生成、理解与调试
上课时间：2026 年 10 月 27 日（第 7 周，周二 19:20–20:55）
所属板块：开发流程
第 2 讲讲了提示四要素和上下文工程。这一讲把这些方法放到代码场景里，顺序是生成、评估、理解、调试，也就是从“能生成”走到“能用”。
上讲回顾与检查点 2 反馈
第 2 讲讲了提示四要素和上下文工程。检查点 2 的完成情况和优秀示例在课上展示。
共性问题有三个：
- 骨架偏薄；
- 提交信息不规范；
- 提示实践记录缺失。
一、生成
需求描述决定生成质量
同样是“写个爬虫”，结果可能完全不一样。如果换成：
用 requests 爬取豆瓣 Top250，输出 CSV，含标题/评分/年份，限速 1 次/秒。
生成结果会稳定得多。需求至少要说清三件事：功能、约束、验收标准。提示词的基本功在第 2 讲，这一讲看它在代码场景里怎么用。
先对齐方案，再生成代码
写代码之前，先让 AI 给出实现方案：模块怎么划分、数据怎么流、用什么技术。人在方案层修改，成本比在代码层返工低。
可以直接这样要求：
先不要写代码，给出你的实现方案与理由。
四种生成模式
| 模式 | 适用场景 | 要点 |
|---|---|---|
| 全新生成 | 新函数、新模块、新脚本 | 先接口后实现；小步生成，不要一次要几百行 |
| 补全与续写 | 编辑器内补全、续写半成品函数 | 补全依赖当前打开的文件，保持文件聚焦 |
| 局部改写 | 修改现有函数、替换实现、调整签名 | 明确改动范围，比如“只改这个函数” |
| 多方案比较 | 需要权衡实现方式时 | 让 AI 给 2–3 种实现，比较性能、可读性和依赖 |
多方案比较时，不同方案共同的部分，往往是稳定的设计。
生成、审查、修改
生成结果不要直接接受。流程是：
生成 → 读 diff → 运行 → 提出问题 → 修改 → 再验证
把 AI 当成需要评审的新人，你是评审者。
二、评估
正确性
先跑主路径，确认正常输入能得到预期输出。再试边界和异常：空输入、极大值、非法格式。
能写测试就不要只靠手点，测试生成在第 7 讲展开。AI 说“完成”不算完成，要求它汇报三件事：改了什么、怎么验证的、还有哪些风险。
可读性与风格
检查命名、结构、注释是否符合项目约定。新代码要和已有代码风格一致，可以让 AI 自己检查一遍。
安全性
AI 引入的依赖要审查：是否流行、是否还在维护、许可证是否合规。
危险写法要特别留意：eval / exec、SQL 拼接、明文存储密钥、不安全的反序列化。可以让 AI 专门做一次检查：
检查以上代码的安全隐患并说明。
这一节可以记成四步：需求清晰、方案对齐、小步生成、严格验收。
三、理解
阅读代码
AI 适合解释复杂算法、正则表达式和遗留代码。提示时要求它逐段解释、举例说明、指出潜在问题。
人机协同时代，读代码的能力更关键。
梳理陌生代码库
接手开源项目或他人项目时，先问架构：目录结构与技术栈是什么，入口在哪，核心数据流怎么走。再让它描述模块之间的依赖关系。
也可以让它生成 README、模块说明和函数文档。
四、调试
五步流程
五步是：复现问题、收集证据、定位根因、修复、回归验证。
AI 在其中的角色是解释报错、梳理线索、提出假设、给候选修复；人负责确认复现、判断根因、审查修复。
错误解读与最小可复现示例
给 AI 报错时，带上完整报错栈、触发代码和环境版本。
最小可复现示例（MRE）的做法是删到不能再删，仍然能复现问题；把无关模块剥离掉。然后可以这样问：
这是报错与 MRE，请解释根因并给修复建议。
根因定位
常见的方法有三种：
- 二分法：注释或裁剪代码，缩小问题区间；
- 日志插桩：让 AI 建议在哪里打印什么；
- 假设清单：让 AI 列出 5 个可能原因，逐一验证。
修复
让 AI 给 2–3 个修复方案，并说明影响面。逐行看 diff，问“为什么这样改”。修完后重跑原始失败场景，再检查有没有引入新问题。
五、常见陷阱
| 陷阱 | 现象 | 防范 |
|---|---|---|
| 幻觉 API | 调用不存在的函数或参数，看起来很对 | 编译或运行验证；查官方文档；让 AI 给出处 |
| 表面修复 | 报错消失但根因还在，比如用 try/except 吞异常 |
追问这个修复解决的根本原因是什么 |
| 过度修复 | 顺手重构无关代码，引入新 bug | 限定改动范围；diff 里发现越界改动就回退 |
| 过度依赖 | 不看 diff 直接接受，久了不理解自己的代码 | 关键路径要能自己讲清楚；第 8 讲展示会问实现细节 |
六、课堂演示
演示一：从需求到小工具。一句话需求是“批量重命名照片文件（按拍摄日期）”。流程是需求澄清、方案对齐、分步生成、运行验收、修一轮 bug。观察点是每一轮人做了哪些审查。
演示二：调试隐藏 bug。材料是一个预置 3 个 bug 的小项目，分别是编译错误、运行时错误和逻辑错误。流程是复现、报错解读、MRE、定位、修复、回归。演示中会故意出现一次幻觉 API 和一次表面修复。
七、课堂实操
下载第 3 讲课堂实操 handout（zip，约 928 KB）。三个任务互不依赖，可以按任意顺序做。
| 任务 | 做什么 | 交什么 |
|---|---|---|
| A：生成与验收 | 在空目录里用 AI 生成一个小工具（题目自选） | 验收清单：测了什么、怎么测、结果、发现的问题 |
| B：阅读陌生代码库 | 用 AI 阅读 python-dateutil 3.0.0，回答 3 个结构化问题 | answers.json、verify.md、transcript.md |
| C：限时 debug | 用 AI 定位并修复 Brotli 解码库中的缺陷 | fix.patch、FIX.md、transcript.md |
任务 A 可以参考课堂演示的做法：先写 REQUIREMENTS.md，再写 PLAN.md，每完成一步提交一次，最后自己验收并记进 ACCEPTANCE.md，至少修一轮 bug。
任务 B 的代码库和问题都在压缩包里。答案要有“文件:行”证据，行号以自己解压出来的源码为准；confidence 是 AI 的自述，标得准不准要由人判断。核对过程写进 verify.md。
任务 C 的提示词要写清：禁止联网，只改 lib/，不用 signal、setjmp、longjmp 或 exit 兜底。修完后自己跑 make repro，确认不再崩溃并返回 ERROR；再用 make tools 造一个正常流，确认还能解压。
三个任务都要保留会话导出。AI 说“已完成”或“已验证”时，自己跑一遍再写结论。
八、检查点 3
截止 2026 年 11 月 8 日（周日）23:59（北京时间）。提交核心模块代码、代码生成与调试过程记录（含最小可复现示例）、当前问题清单。完整要求、提交目录与评分标准见检查点 3：中期检查。
第 4 讲是客座讲座，检查点 3 跨这一周推进，反馈顺延到第 5 讲。