编码助手改完代码后，先别急着点击接受。它可能实现了你要的功能，也可能顺手改了无关设置，或者只处理了最顺利的情况。审查的目标很具体：确认修改符合需求，理解它影响哪里，并找到足够的证据支持接受。
你不必一次读懂整个项目。先围绕这次任务，沿着“改了什么、行为怎样变化、怎样验证”这条线走完一圈。
第一站：把需求和修改范围对上
先用一句话重述任务。例如：“提交表单时，如果手机号为空，就显示提示并停止提交。”这句话就是本次审查的边界。新增动画、调整配色、更换依赖，都需要额外解释。
接着打开修改文件列表，先看文件名，再看具体代码。如果一个表单校验任务同时修改了登录逻辑、数据库配置和依赖锁定文件，应当逐项确认原因。文件多不一定有问题，但每项修改都应当能说清用途。
可以让助手说明：“请列出修改的文件，解释每个文件与需求的关系，并标出顺手整理的部分。”把回答当作阅读地图，再与实际差异核对。
第二站：把新增和删除翻译成行为
差异视图展示修改前后的变化，通常用颜色和加减标记区分新增、删除。不要只盯着新增内容：删掉一次权限判断、一次异常处理，往往比增加几行提示更值得关注。
每读完一处修改，试着用日常语言描述结果：“以前空手机号也能提交，现在会先提示。”如果只能复述代码，却讲不出用户会遇到什么变化，就继续查看周围逻辑和调用位置。
- 输入：空值、空格、格式错误和重复操作会怎样？
- 失败：请求失败后，用户能否得到提示并重新尝试？
- 权限：修改是否影响登录检查、数据访问或敏感信息展示？
- 范围：有没有顺手删除原有功能，或者改变其他页面的行为？
看到密码、密钥或真实用户资料进入代码、日志和测试样例时，应先移除并确认影响。遇到自己解释不清的权限或数据删除逻辑，可以请熟悉项目的人协助审查。
第三站：用实际检查支持接受决定
助手说“测试通过”之后，还要看它运行了什么、结果是什么。编译成功能说明代码满足部分构建要求，却不能证明表单提示正确，也不能证明原有流程没有受影响。
对于手机号校验，至少亲自检查三种情况：留空时不能提交，填写有效号码时能继续，修正错误后提示能正常消失。再检查原有提交路径，避免新判断把正常操作挡住。
如果项目已有相关测试，运行它们并查看失败信息。涉及新增规则时，让助手补上能够覆盖这条规则的测试；涉及页面交互时，再实际操作一次。没有运行的检查应明确记下来，不能算作通过。
放行之前：处理疑点，再决定接受哪些修改
发现问题时，给出具体反馈：“保留手机号校验，撤回无关样式修改；请求失败后恢复提交按钮。”助手修正后，再检查新差异。上一轮的审查结论不能自动覆盖后来增加的代码。
如果你通过 SwiftRelay 使用编码助手，可以按用量调用模型，并注册领取少量赠送额度，用于尝试解释修改或补充检查思路。让模型帮助你理解代码时，也要把解释与实际文件、运行结果核对。
最后确认三件事：修改符合需求，关键行为已经验证，剩余疑点已经处理。如果只接受部分修改，记得针对最终保留的代码重新检查，因为它可能依赖被你排除的部分。