先选择工作模式

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

依赖评审可以只看清单与锁文件，也可以进一步核对调用方和迁移测试。教学请求明确 mode=quick，当前目标是确认解析版本变化；调用兼容性不在这次证据范围。模式应影响真实工作和报告，不能只是换一个名字。

具体做法

为每种模式写目标、读取范围和交付条件，声明适用默认值。先读取用户明确选择，再执行该分支；没有选择且目标清楚时使用已约定默认。发现需要更深检查的问题，报告缺口和原因，不把快速结果包装成全面结论。来源通过探索与组织的分离展示范围，本篇 quick/deep 是教学模式。

反例

mode=quick 也随意读取所有调用方，最后说完整迁移兼容性已确认；或者只看锁文件，却声称 deep 评审全部完成。

改进写法

教学模式契约：quick=检查清单与锁文件，报告版本变化及未核对调用兼容性；deep=另检查相关调用方和迁移测试。当前用户选择 quick，因此按其范围完成，发现影响后续决策的兼容疑点则列为需深入检查，不声称已覆盖。未指定模式时以约定 quick 为默认，用户明确范围优先。

为什么这样改

模式把工作量和结论边界显式连接，读者知道哪些证据已取得、哪些没有。它避免执行者靠语气猜深度，也防止同一份有限结果因标题不同变成更强的声明。

如何验证

示意 quick 报告列版本变化并标“调用方/迁移测试未核对”；deep 报告应包含其追加证据。检查实际读取与模式相符，用户选择没有被默认覆盖。

若发现重要缺口，报告它而不是因 quick 模式隐藏；模式标签本身不证明检查已执行。

适用边界

默认模式取决于任务，不是所有依赖问题都应先快速处理。模式不能豁免安全、正确性或用户明确要求；必要的范围变化要说明其影响，不借模式静默扩大或缩小交付。