使用 Remy
审查代码改动
限定审查范围，逐项核对发现。
适用范围： 桌面端本地 Git 项目。
在提交代码前，让 Remy 检查改动是否符合需求、是否引入问题，并给出可以逐项核对的发现。本例先审查，再由你决定是否修改。
1. 准备项目与审查范围
按桌面端指南添加项目，打开该项目中的新对话。
发送任务前，准备好：
- 本次改动要解决的需求或问题。
- 要审查的范围，例如当前全部未提交改动，或明确列出的几个文件。
- 不能改变的行为，以及用于判断是否完成的标准。
Changes 显示当前工作区的改动，可能包含你此前的工作。先核对文件清单；如果只想审查其中一部分，在提示词中列出范围。
2. 发起审查
将下面的需求替换为你项目中的实际内容：
示例提示词
请审查当前项目中与订单列表筛选相关的未提交改动。
本次需求是：切换关键词或状态筛选后回到第 1 页，刷新列表，并保留原有排序。
请先列出你纳入审查的文件，区分已暂存、未暂存和新增文件；
只审查与上述需求相关的改动，不把其他已有修改算进来。
重点检查：
1. 实现是否满足上述需求。
2. 请求参数、状态更新和页面展示是否一致。
3. 空结果、快速连续切换和请求失败等情况下是否有问题。
4. 现有测试是否覆盖实际变化，是否遗漏关键情况。
按严重程度列出发现。每项说明文件位置、触发条件、实际影响、依据和建议。
把已确认问题与仍需验证的疑点分开；没有发现时也说明检查范围和未覆盖部分。
只审查，不修改文件、安装依赖、提交或推送代码。
3. 核对审查结果
逐项打开相关文件，检查发现是否成立。
| 检查项 | 你应能回答的问题 |
|---|---|
| 审查范围 | 是否覆盖了指定改动，有没有遗漏新增文件或混入无关工作？ |
| 问题依据 | 文件位置是否存在，描述是否符合当前实现？ |
| 触发条件 | 在什么条件下会发生，能否复现或通过测试验证？ |
| 实际影响 | 是会影响使用的问题，还是可以另行考虑的改进建议？ |
| 检查结果 | 哪些检查确实执行了，哪些只是建议或没有条件执行？ |
如果只有笼统判断，可以继续要求：
示例提示词
请展开第 2 项发现，指出具体代码和触发条件，给出最小复现步骤。
如果目前只有推测，请明确说明，并列出验证它所需的检查。
先不要修改文件。
4. 按选定的问题修复
确认需要修复的事项后，在同一对话继续：
示例提示词
请只修复已确认的第 1 项问题。
保留其他已有改动，沿用项目原有实现方式，补充并运行相关测试。
完成后说明修改文件、检查结果，以及未完成的检查。
先不要提交或推送代码。
然后重新查看实际差异，并按原复现步骤检查功能。需要按需求核对完成情况时，可以明确要求使用 Verification；验证结论仍应有实际改动和检查结果支撑。
5. 完成标志
你已获得一份范围清楚、每项发现可追溯的审查结果，并能区分需要修复的问题、尚待验证的疑点和未覆盖的部分。若进一步做了修复，应能看到对应改动及检查结果。
“没有发现问题”不等于所有场景都经过验证。是否提交或合并，仍按项目原有流程决定。
6. 继续阅读
- 使用子智能体：从不同模块或角度分工审查。
- Quick Start：完成一次小改动并检查实际效果。
- Cloud 指南：需要云端执行和 PR 交付时使用。