让 DSH 审一遍改动,给出风险清单
配方模板 · 尚未在本站完成实测
本页是配方模板,尚未在本站完成实测。运行记录、token与耗时会在复测后补上;在那之前不填任何估算数字。
适用场景
改完一个模块或合PR前,想先让AI把明显问题和风险点挑出来,而不是只说「看起来没问题」。
准备
- 宿主版本
- 待填(实测时记录具体rc版本号)
- 模型
- 待填
- 模式 / 权限
- 建议先用标准模式 + 工作区内修改
- 需装插件
- 无(如用到插件,在实测后补齐名称与版本)
- 输入材料
- 放在独立工作区,原始文件先备份
完整指令
审视【当前分支相对 main 的 diff】,做一次代码评审,不要自动改代码。
输出格式:
1. 风险清单:每条写 文件:行号、问题类型(空指针 / 越界 / 并发 / 资源泄漏 / 错误处理缺失 / unsafe 调用等)、为什么是风险、建议改法。
2. 必须处理项 vs 建议项 分开列。
3. 标出你没把握、需要人确认的地方,不要替我下结论。
4. 最后给一句总评:能不能合。
要求:只看 diff 涉及的文件与它们的直接依赖;不要顺手重构;不要修改任何文件。运行记录
| 项目 | 数值 | 备注 |
|---|---|---|
| 耗时 | 待实测 | |
| 结果 | 待实测 | |
| 输入 / 输出token | 待实测 | |
| 残留 | 待实测 |
产物
跑通后在这里给出文件清单与截图,并说明原始文件有没有被改动。
验收清单
点一下可勾选,用来逐条核对。
- 只产出评审意见,没有改动任何代码
- 风险清单每条都带文件:行号与原因
- 必须处理项与建议项已分开
- 需要人确认的点被显式标出
失败与边界
- diff很大时先评审核心文件,再补周边
- 生成的「能不能合」只是建议,最终由人决定
- 卡在哪:需要一个小而真实的改动集,里面含真实缺陷。自造仓库只能验证流程,验证不了「它能不能发现真问题」,而后者才是这条配方的价值。