兵五进一(@bingwujinyi):经常有人说，让 AI 审查自己写的代码是自欺欺人，本质上是自己给自己打分。这个质疑听起来有道理，但恰恰问错了地方，问题不在于"能不能用 AI 审 AI"，而在于你有没有把上下文切干净。我现在的固定流程是这样的：一个 Claude Code 实例负责写修复，写完之后不允许直接合并。另开一个全新的 session，给它设一个人设，“挑剔的高级工程师”，把 diff 和最初的需求一起扔进去，规则很明确：只许挑 bug 和安全漏洞，代码风格一律不许评论，避免它把精力浪费在无关紧要的地方。这套流程背后的原理其实很简单。写代码的那个实例，上下文里已经塞满了自己的假设、试错过程、中途改过的方向，让它回头审自己写的东西，本质上是闭卷考试自己改卷,它对自己的盲区没有任何免疫力,因为那些盲区就是它思考路径的一部分。而新开的实例完全不同,上下文是干净的，没有任何沉没成本，也不需要为之前的判断辩护，它只专注在“作者盲区”上。权限校验有没有漏掉，边界条件有没有漏判，这类问题一抓一个准，因为它没有心理包袱去为原作者的选择找补。技术实现上，配合 gh CLI 自动拉取 PR 的 diff，整条链路可以做到零人工介入，写、审、拉取代码全部自动衔接。核心的洞察其实就一句话：同一个模型，换一个干净的上下文，就等于换了一位完全独立的工程师。人设不是玄学，是给模型一个明确的注意力聚焦点。我自己试过几种设定，「安全审计员」这个人设的拦截率，比“挑剔的高级工程师”还要高，可能是因为"安全"这个词本身就把它的注意力压得更窄、更狠。

2026.07.05 18:33

经常有人说，让 AI 审查自己写的代码是自欺欺人，本质上是自己给自己打分。这个质疑听起来有道理，但恰恰问错了地方，问题不在于"能不能用 AI 审 AI"，而在于你有没有把上下文切干净。我现在的固定流程是这样的：一个 Claude Code 实例负责写修复，写完之后不允许直接合并。另开一个全新的 session，给它设一个人设，“挑剔的高级工程师”，把 diff 和最初的需求一起扔进去，规则很明确：只许挑 bug 和安全漏洞，代码风格一律不许评论，避免它把精力浪费在无关紧要的地方。这套流程背后的原理其实很简单。写代码的那个实例，上下文里已经塞满了自己的假设、试错过程、中途改过的方向，让它回头审自己写的东西，本质上是闭卷考试自己改卷,它对自己的盲区没有任何免疫力,因为那些盲区就是它思考路径的一部分。而新开的实例完全不同,上下文是干净的，没有任何沉没成本，也不需要为之前的判断辩护，它只专注在“作者盲区”上。权限校验有没有漏掉，边界条件有没有漏判，这类问题一抓一个准，因为它没有心理包袱去为原作者的选择找补。技术实现上，配合 gh CLI 自动拉取 PR 的 diff，整条链路可以做到零人工介入，写、审、拉取代码全部自动衔接。核心的洞察其实就一句话：同一个模型，换一个干净的上下文，就等于换了一位完全独立的工程师。人设不是玄学，是给模型一个明确的注意力聚焦点。我自己试过几种设定，「安全审计员」这个人设的拦截率，比“挑剔的高级工程师”还要高，可能是因为"安全"这个词本身就把它的注意力压得更窄、更狠。