评审清单落地工作流

把评审者反复重复的清单尽量编码进自动化，其余做成结构化提示，把人类留给判断。

目标

每周重复打同样三十条评论的评审者，就是一条等待被写出来的 lint 规则。挖掘评审历史、把机械类交给 CI、把判断类做成结构化提示——清单从记忆负担变成机器，评审对话被设计与正确性主导。

步骤要点

挖掘重复的评审评论：收集近几个月的评审发现，分类为机械类（工具可查）与判断类（需要人）。
自动化机械类：把高频机械发现编码为 CI 检查——lint 规则、禁用导入、生成代码漂移、尺寸守卫。
提示化判断类：把高频判断发现变成 PR 模板里的结构化问题——错误路径、并发假设、断言强度。
退役被检查取代的评论：评审者停止重复自动化能拦的内容，清单版本记录哪些类别移交给了工具。
季度重挖：重复挖掘把新出现的重复评论升级为自动化或提示，清单随代码库的失败模式演进。

排错提示

评审还在手打 lint 能拦的评论是自动化没跟上，从挖掘清单的机械类开始逐条编码；判断类问题被跳过是模板没强制，勾选框必须留在提交前路径上；规则越积越吵要定期清理，误报多的规则比没有规则更毁纪律。

适用边界

自动化只能覆盖可机械判定的模式，语义与设计判断永远需要人；清单项过多会产生“全勾”惯性，判断类提示要控制在五条以内。

代码示例

mined findings (6 months, by frequency):
  MECHANICAL (54% of comments):
    unused import / dead code        -> lint rule
    missing error handling on await  -> custom check
    test missing for new branch      -> coverage gate
    forbidden cross-layer import     -> eslint boundary
  JUDGMENT (46%):
    error path semantics
    concurrency assumptions
    test assertion strength

PR template prompts (judgment):
  [ ] walked the failure path: what happens
      when the dependency returns 503?
  [ ] concurrency: any shared mutable state?

result: mechanical comments -86%, review
threads now 71% design/correctness