LESSON 56 / 575 分钟

读懂代码:五个必问的问题

AI 可以扩大你的实现能力,清晰的判断标准能让这种能力可控。

用你的前端经验理解

和审查 React PR 一样,你不必逐行背 API,但要读懂数据流、副作用、错误路径与依赖。

为什么需要它

审查生成代码时,先读数据流和生命周期,再看语法细节。一个看似简短的 Task 可能把控制器长期保留,一个便利的 try? 可能把保存失败伪装成成功,一个新单例可能让两个窗口共享本不应共享的草稿。风险通常藏在边界,而不是最显眼的界面代码。

它是怎样工作的

五个问题可以形成阅读顺序:谁拥有数据,谁能修改,副作用何时开始结束,失败如何表现,平台条件是否成立。再看修改范围是否合理:修一个按钮却同时升级依赖、改签名和重写模型,需要额外解释。对安全相关断言要查看证据,例如 token 是否确实被验证,而不是只被解码。

把关键概念连起来

1

所有权

谁拥有状态?是值还是引用?视图重建后数据是否还在?有没有互相强引用?

2

执行与失败

请求在哪个隔离域?任务会取消吗?失败/空数据/权限拒绝时用户看到什么?

3

环境

API 支持哪些平台和系统?新依赖有什么代价?配置修改是否必要?怎么在最小工程复现?

审查一段搜索功能修改

  1. 找到查询与结果的所有者,检查是否重复保存派生状态,或每次视图刷新都新建服务。
  2. 沿请求成功、失败和取消三条分支走一遍,确认旧请求不会覆盖新查询,按钮不会永久停留在加载中。
  3. 检查新 API 的可用系统版本,以及预览使用的依赖是否会访问真实用户数据。

这里需要你亲自判断

要求 AI 对代码自评“没有问题”不构成验证。要求它给出假设、测试步骤和可能失败的条件。

做一个小练习

挑一段 AI 代码,用状态、生命周期、并发、错误、平台五个维度逐项说明。

  1. 选择一段修改,为五个问题各写一条具体证据与尚未确认的假设。
  2. 指出哪一项可以靠类型检查证明,哪一项必须运行或使用测试替身。
展开参考思路与验收标准

“使用了 async/await”不能证明并发安全,“存进 Keychain”不能证明会话有效。高质量审查应该把技术名称转成可以验证的数据与行为约束。

哪种 AI 输出更容易审查?

继续查阅官方资料
Apple Developer 官方资料

本课聚焦核心认知。具体 API、系统要求与发布政策,以当前官方文档和工程验证为准。

答对理解题后即可标记完成