一条评审评论只有「这里改一下」，作者改了方法名，评审说不是这个意思，来回四轮花了两天。最后要改的是空值分支，评论里一个字都没提。乍看像缓存或者权限的锅，追下去往往不是。
gh pr comment 128 --body 'L42 orderNo 可能为 null，建议改成 Optional.ofNullable' gh api repos/o/r/pulls/128/comments --jq '.[].body'
追下去是这么回事：评审人把心里想的当成对方能看懂，没写清位置和期望。异步沟通里缺少上下文，作者只能猜。
「评审意见含糊」这类改动最怕改一半，回滚脚本先准备好，再动生产。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。报错里带路径的，先去看那个路径在不在、权限对不对。
具体做法是，评论里写清楚问题 建议 和判断依据三部分；指出具体行 用 suggestion 直接给改法；区分必须改和建议改 用前缀标出来；作者有疑问就在同一条评论下追问 不要另开。
验收就看一点，每条评审意见都能对应到具体行和改法，同一个问题不再出现第二轮追问。