Review 的目标不是找茬
语音输入是「宝贝轻松记」里很关键的一条链路。
它不是单个按钮，也不是单次接口调用，而是一整段用户体验：
用户点击语音按钮
↓
进入录音状态
↓
采集音频
↓
识别文本
↓
解析成照护记录草稿
↓
展示确认结果
↓
用户保存或取消这条链路里任何一个环节不稳，用户都会觉得“语音不好用”。所以这次 Code Review 的目标不是让 AI 帮我找几个格式问题，而是检查整条链路是否能经得起真实使用。
AI 适合做第一轮链路扫描
人在 review 自己刚写完或刚合并的代码时，很容易带着实现路径看问题。
AI 的价值在于，它可以按链路重新扫一遍：
- 入口在哪里；
- 状态从哪里开始；
- 成功路径怎么走；
- 失败路径怎么走；
- 超时如何处理；
- 用户取消时是否清理；
- 录音资源是否释放；
- 识别结果为空时页面如何反馈；
- Parser 失败是否会误保存；
- 首页是否能正确刷新。
这些问题不一定都复杂，但它们分布在 UI、权限、录音、ASR、解析、状态反馈和数据保存之间。让 AI 先做一轮结构化扫描，可以帮助我更快看到链路全貌。
好的 Review 会追问状态，而不是只看代码
这次复盘里最重要的收获，是把 review 重点从“代码有没有写错”转向“状态有没有闭合”。
语音链路至少涉及几类状态：
- 空闲；
- 录音中；
- 识别中；
- 识别成功；
- 识别失败；
- 解析成功；
- 解析失败；
- 用户确认；
- 用户取消；
- 资源清理完成。
如果只看某个函数，很容易觉得每一段都没问题。但把状态串起来看，就会发现风险通常藏在过渡处。
比如：录音结束后进入识别中，如果用户立刻退出页面，是否还会回调 UI？识别失败后按钮是否回到可点击状态？Parser 失败时用户看到的是空白、错误提示，还是可编辑的原始文本？
这些都不是简单的语法问题，而是产品体验问题。
AI 不能替我验收，但能帮我列出验收路径
我不会把语音链路的最终判断交给 AI。
原因很简单：语音输入需要真机、真实麦克风、真实网络、真实用户节奏。AI 可以分析代码，但它不能替我感受按钮反馈是否自然，不能替我判断识别失败时用户是否困惑，也不能替我确认真机权限弹窗是否顺。
但 AI 可以帮我把验收路径列出来：
首次点击语音按钮
录音权限允许
录音权限拒绝
短语音识别成功
长语音识别成功
空音频 / 无有效内容
网络异常
识别超时
Parser 无法解析
用户中途取消
页面退出后回调
保存后首页刷新这份清单比单纯“跑一下看看”更可靠。
Review 应该按风险分层
不是所有改动都值得同样强度的 review。
语音链路这种功能，涉及权限、音频资源、网络识别、数据写入和 UI 状态，风险就比较高。它适合做三层 review：
- 静态链路 review：看调用路径和状态边界；
- 代码重点 review：看资源释放、异常处理、生命周期；
- 真机验收 review：按清单跑成功、失败、取消和异常路径。
AI 可以参与前两层，也可以辅助生成第三层清单。但最后是否放行，仍然要由人基于真机结果判断。
这次复盘真正沉淀下来的东西
这次和 AI 做 Code Review，最有价值的不是某一个具体 bug，而是一套方法：
- 先让 AI 按用户路径重建链路；
- 再让 AI 按状态枚举成功和失败路径；
- 然后让 AI 找资源、权限、生命周期边界；
- 最后由人按验收清单在真机上确认。
AI 在这里不是“替我负责”的 reviewer，而是一个帮助我扩大视野的 reviewer。
它能把我从实现细节里拉出来，重新看见产品链路。对个人开发者来说，这种能力很重要，因为一个人做产品时，最容易缺的就是第二双工程眼睛。