LESSON 04 / 575 分钟
调试：先定位，再让 AI 修
把报错分成编译、运行、状态和性能问题，比反复要求 AI“修一下”更有效。
用你的前端经验理解
断点/LLDB 类似 DevTools 调试器；Console 类似日志面板；View Debugger 帮你看真实视图层级。
01 / 理解问题
为什么需要它
调试从一个可重复的现象开始：“点击两次后数字仍为 1”比“状态坏了”有用得多。记录输入、预期、实际和环境，把问题收窄到最短路径。你不必熟悉所有 LLDB 命令，先掌握断点、变量检查、调用栈和单步，就能判断 AI 给出的修复是不是碰巧隐藏了症状。
它是怎样工作的
编译器错误发生在运行前；崩溃发生在某条运行路径；界面错误可能根本没有异常。三者需要不同证据。断点暂停时可以检查执行到了哪个对象、当前变量是什么；调用栈说明谁调用了这里。日志适合跨事件追踪，但应记录操作和安全的标识，不输出 token、邮件正文或完整个人资料。
02 / 掌握要点
把关键概念连起来
1
编译问题
阅读首个有意义的错误及上下文。类型不匹配、缺少 import、API 不可用属于不同原因。
2
运行问题
在崩溃处设置断点，查看调用栈与变量。用 Logger 输出有上下文的日志，避免泄露个人数据。
3
界面问题
先确认数据是否变化，再看视图是否观察到它；布局可用 View Debugger，卡顿交给 Instruments。
03 / 案例推演
排查“保存成功但列表没有新记录”
- 在保存动作入口打断点，确认点击确实触发；再检查输入模型是不是预期值。
- 检查仓库是否真的保存成功。若错误被 try? 吞掉，先暴露错误；若保存成功，继续检查列表读取的是不是同一个仓库。
- 最后查看观察关系与筛选条件：新记录可能被过滤，或页面正在显示旧快照。只在定位后修改对应一层。
这里需要你亲自判断
清缓存、删 Derived Data 不能代替定位根因；不要直接把含 token 或用户信息的日志发给 AI。
04 / 动手验证
做一个小练习
在按钮动作中放断点，点击按钮，检查变量，单步执行一次。
- 人为制造一个筛选条件错误，用断点找出记录在哪一层消失。
- 给 AI 一份包含复现步骤、实际值和预期值的描述，要求它只修改已定位的逻辑。
展开参考思路与验收标准
有效结论应是“记录已进入仓库，但列表仅显示 isRead=true，因此新建未读记录被排除”。修复后还要确认原先应该隐藏的记录仍被隐藏；单纯让所有数据都出现并不算正确。
05 / 检查理解
按钮点击后 UI 没更新，首先检查什么？
答对理解题后即可标记完成