审查代理改动：看 diff、读说明、跑测试

代理完成一轮改动后，审查是不可省略的最后一道闸门。本节把审查拆成"看范围、读改动、跑验证"三步，并给出可直接使用的只读命令、改动分级判断标准和安全红线。目标是让你既能高效采纳有用改动，又能及时拦下越界、误删和未验证的修改。

一、为什么不能只看代理的总结就接受

代理最后给出的说明是概括性结论，可能不会强调"顺带改动了哪些文件""删除了哪些分支""新增了哪些依赖"。仅凭文字总结接受改动，容易放过：跨文件连带修改、错误的边界处理、被顺手删除的代码、缺少测试的功能、以及调用了不安全或不必要命令等情况。审查的核心是对照真实改动（diff）与实际验证结果（测试/构建），而不是对照主观评价。

二、三步审查法

第 1 步：先看改动范围（改了什么、改了多少）

在会话内可用 /diff 查看当前工作区中代理产生的改动概览；如需逐行比对，代理会通过 Bash 执行终端版本控制命令（以下为通用 Git 只读命令，按你项目的实际情况使用，不会修改历史记录）：

只读命令	用途
git status	列出被修改、新增、删除的文件清单，先判断范围是否在预期内
git diff	查看工作区尚未暂存的逐行差异（增删行一目了然）
git diff --stat	只看各文件增删行数统计，快速判断改动规模是否异常
git log --oneline	了解近期提交脉络，避免代理改动与最近提交语义冲突

先确认文件数量和路径是否符合任务范围：一个"修空数组返回值"的小任务若改动了十几个文件，就应停下来追问原因，而不是继续接受。

第 2 步：读关键改动（改得对不对）

• 比对意图与实现：对照任务目标，确认每处修改是否服务于目标，有没有"为改而改"的格式化、重命名。
• 重点看边界条件：空值、异常输入、并发与错误分支是否被正确处理；新增判断是否会误伤原有正常用例。
• 检查副作用：是否新增外部依赖、改变导出签名、硬编码环境特定值、写入敏感路径或凭据。
• 阅读测试改动：功能改动是否配套新增/更新测试；只改实现不补测试的结论要打折扣。

第 3 步：跑验证（是否真的可用）

静态阅读之外必须执行可重复的验证。命令以项目实际脚本为准，常见类别如下：

验证类别	常见命令（按项目 package.json / 构建配置替换）	通过标准
单元测试	npm test / npm run test:unit	全部用例绿，原有用例无回归
类型检查	npm run typecheck / tsc --noEmit	无新增类型错误
构建打包	npm run build	构建成功、无告警错误
lint 静态检查	npm run lint	无新增 lint 报错
手动走查	启动本地服务复现目标行为	目标场景行为符合验收标准

三、改动分级：接受、追问、拒绝

信号	判断	动作
范围与目标一致、边界处理清楚、测试全绿	可接受	确认后继续下一任务或准备提交
范围偏大但理由成立、个别细节存疑	需追问	要求解释关键改动、补测试或拆分改动
改动无关文件、删除疑似必要代码、出现凭据/硬编码、验证失败	应拒绝/回退	不采纳该轮改动，回到方案阶段重新对齐

四、批准模式与审查的配合

权限模式决定代理是否需要逐条请示，审查决定你对已产生结果的态度，两者互补：在 Manual（默认）模式下逐轮审批天然增加了中间检查点；进入 acceptEdits 减少文件编辑确认打扰时，更要在阶段末尾集中做一次完整的 /diff + 测试审查；涉及生产、密钥、对外发布的改动，即使验证通过也应由人工最终拍板。若需要精确控制某类命令，可用 /permissions 固化允许或拒绝规则。

五、需要回退时的通用做法

• 改动尚未提交、想整体回到修改前，使用终端版本控制工具按团队规范撤销工作区修改（具体回滚命令由你结合分支与提交策略执行，避免影响他人提交）。
• 只想撤销单个文件的改动，先 git status 定位该文件，再针对性恢复，不要批量丢弃全部改动。
• 重要修改前先确认当前分支干净、已有备份或远程记录，确保回退路径可用。