审查器不生效时，dsh-auto-review 先查这五个原因-平芜编程栈

dsh-auto-review 在审批链上放一个只读的第二模型：它读取证据并返回{ decision, reason, riskLevel }裁决，默认失败关闭，全过程可从会话日志审计（approval/asked → autoReview/verdict → approval/decided）。它的行为完全由配置驱动，而配置放错位置时既不生效也不报警——这正是「审查器不生效」最常见的来源。

一个前提：站点对它的信任档位是「仅索引—— 本站尚未对其实装验证，仅收录元数据」，静态安装检查通过但未做真实安装；安全扫描列出「含敏感能力」44 处证据且尚无人工评估。本文给的是排错路径，不是背书。

装好之后先确认三件事

配置落在 profile 的cordis.patch.yml中auto-review那一行的config里。会话内用/auto-review status看有效状态（开关、按轮次预算、熔断状态与会话统计）——排错先看它，再动手改配置。

更多同类插件的信任档位与检查结论，见完整插件清单与汉化避坑指南。

五个原因，逐个定位

坑一：配置写进了 settings.yaml

现象。在~/.dsh/settings.yaml里写了auto-review:块，改完重启，审查器毫无反应，日志也无任何提示。

原因。与所有 DSH 函数插件一样，它从加载器挂载它时所用的那一行接收 Config，即 profile 的 cordis 补丁层，settings 服务不是它的配置来源——这种症状还与「审查器单纯拒绝」无法区分。

解决。把配置写进 profile 的cordis.patch.yml。怎么确认：跑dsh --profile web --dump-config | grep -A4 'id: auto-review'，看那一行下面有没有你写的键。

坑二：覆盖整行把 toolsPolicy 弄丢了

现象。只想改一个键（比如调小reviewerTimeoutMs），覆盖后审查器完全不跑，bash和write变回人工审批。

原因。以 id 为目标的覆盖是替换整个配置行，不做逐键合并；丢掉toolsPolicy会把bash/write静默地恢复为 schema 默认的human。

解决。覆盖时把需要的键都重写一遍，例如toolsPolicy.overrides要连同bash: ai, write: ai一起声明。怎么确认：--dump-config输出里该行的config是否完整包含toolsPolicy。

坑三：fallbackPolicy 默认是 rejected

现象。正常操作被反复拒绝，/auto-review status里「回退」计数在涨，却看不到明确错误。

原因。默认fallbackPolicy: rejected是失败关闭：提供者缺失、超时、裁决缺失或格式错误、审计关联失败等每条异常路径都走这个策略——宁可拒绝，不做静默授予。

解决。先理解这是设计而非 bug。无人值守且确实要放行，才显式改成delegate（交回人工链）或allow-once，后者是无条件授予，只应存在于管理员已接受该风险的部署里。怎么确认：回退计数与拒绝计数同步增长，基本可判定是回退在拒。

坑四：默认不管 edit

现象。以为开了 AI 审查就覆盖所有写操作，结果bash、write顺畅通过，就地编辑却卡在人工审批。

原因。随附补丁开箱即用只对bash和write做 AI 审查，其他所有工具——包括edit（就地修改）——都委托给人工链。

解决。接受无人工介入的就地编辑，就在toolsPolicy.overrides里给edit写上ai。怎么确认：看--dump-config里toolsPolicy.overrides是否出现edit。

坑五：reviewerTimeoutMs 给得太短

现象。把它调成很小的值后请求频繁被拒，日志里看不出原因。

原因。超时本身就走fallbackPolicy，默认又是rejected，所以「超时」与「裁决为拒绝」的最终表现完全一样。该键默认 60000ms。

解决。结合模型延迟给足时间，并一并考虑回退策略；否则缩短超时等于变相提高拒绝率。怎么确认：临时调回 60000 再跑同一条操作，若放行即说明是被超时触发了回退。

收尾提醒

五条都指向同一判断顺序：先确认配置落在 profile 的 cordis 补丁层，再看策略，最后才怀疑模型。另外两点易忽略：审查器需要一条可用 LLM 路由，否则每次都按fallbackPolicy回退；敏感参数脱敏按键名匹配token、password、api_key这类名字而非内容。