LESSON 56 / 575 分钟
读懂代码:五个必问的问题
AI 可以扩大你的实现能力,清晰的判断标准能让这种能力可控。
用你的前端经验理解
和审查 React PR 一样,你不必逐行背 API,但要读懂数据流、副作用、错误路径与依赖。
01 / 理解问题
为什么需要它
审查生成代码时,先读数据流和生命周期,再看语法细节。一个看似简短的 Task 可能把控制器长期保留,一个便利的 try? 可能把保存失败伪装成成功,一个新单例可能让两个窗口共享本不应共享的草稿。风险通常藏在边界,而不是最显眼的界面代码。
它是怎样工作的
五个问题可以形成阅读顺序:谁拥有数据,谁能修改,副作用何时开始结束,失败如何表现,平台条件是否成立。再看修改范围是否合理:修一个按钮却同时升级依赖、改签名和重写模型,需要额外解释。对安全相关断言要查看证据,例如 token 是否确实被验证,而不是只被解码。
02 / 掌握要点
把关键概念连起来
1
所有权
谁拥有状态?是值还是引用?视图重建后数据是否还在?有没有互相强引用?
2
执行与失败
请求在哪个隔离域?任务会取消吗?失败/空数据/权限拒绝时用户看到什么?
3
环境
API 支持哪些平台和系统?新依赖有什么代价?配置修改是否必要?怎么在最小工程复现?
03 / 案例推演
审查一段搜索功能修改
- 找到查询与结果的所有者,检查是否重复保存派生状态,或每次视图刷新都新建服务。
- 沿请求成功、失败和取消三条分支走一遍,确认旧请求不会覆盖新查询,按钮不会永久停留在加载中。
- 检查新 API 的可用系统版本,以及预览使用的依赖是否会访问真实用户数据。
这里需要你亲自判断
要求 AI 对代码自评“没有问题”不构成验证。要求它给出假设、测试步骤和可能失败的条件。
04 / 动手验证
做一个小练习
挑一段 AI 代码,用状态、生命周期、并发、错误、平台五个维度逐项说明。
- 选择一段修改,为五个问题各写一条具体证据与尚未确认的假设。
- 指出哪一项可以靠类型检查证明,哪一项必须运行或使用测试替身。
展开参考思路与验收标准
“使用了 async/await”不能证明并发安全,“存进 Keychain”不能证明会话有效。高质量审查应该把技术名称转成可以验证的数据与行为约束。
05 / 检查理解
哪种 AI 输出更容易审查?
答对理解题后即可标记完成