跳到正文
MyDSH我的 DSH 实战笔记
English
独立维护,非DeepSeek官方;与mydsh.dev等其他MyDSH站点无关联。

让 DSH 审一遍改动,给出风险清单

配方模板 · 尚未在本站完成实测

配方 / 代码模板 · 待实测整理于2026-11-14
本页是配方模板,尚未在本站完成实测。运行记录、token与耗时会在复测后补上;在那之前不填任何估算数字。

适用场景

改完一个模块或合PR前,想先让AI把明显问题和风险点挑出来,而不是只说「看起来没问题」。

准备

宿主版本
待填(实测时记录具体rc版本号)
模型
待填
模式 / 权限
建议先用标准模式 + 工作区内修改
需装插件
无(如用到插件,在实测后补齐名称与版本)
输入材料
放在独立工作区,原始文件先备份

完整指令

审视【当前分支相对 main 的 diff】,做一次代码评审,不要自动改代码。

输出格式:
1. 风险清单:每条写 文件:行号、问题类型(空指针 / 越界 / 并发 / 资源泄漏 / 错误处理缺失 / unsafe 调用等)、为什么是风险、建议改法。
2. 必须处理项 vs 建议项 分开列。
3. 标出你没把握、需要人确认的地方,不要替我下结论。
4. 最后给一句总评:能不能合。

要求:只看 diff 涉及的文件与它们的直接依赖;不要顺手重构;不要修改任何文件。

运行记录

项目数值备注
耗时待实测
结果待实测
输入 / 输出token待实测
残留待实测

产物

跑通后在这里给出文件清单与截图,并说明原始文件有没有被改动。

验收清单

点一下可勾选,用来逐条核对。

  • 只产出评审意见,没有改动任何代码
  • 风险清单每条都带文件:行号与原因
  • 必须处理项与建议项已分开
  • 需要人确认的点被显式标出

失败与边界

  • diff很大时先评审核心文件,再补周边
  • 生成的「能不能合」只是建议,最终由人决定
  • 卡在哪:需要一个小而真实的改动集,里面含真实缺陷。自造仓库只能验证流程,验证不了「它能不能发现真问题」,而后者才是这条配方的价值。

认领这条配方 回配方列表