首先给出一个关键判断：代码评审意见是否具体，其影响究竟有多大？差异足以决定接收者是立刻着手修改，还是盯着屏幕困惑三分钟后默默关闭页面。

要让Claude生成“一目了然、可直接执行”的评审意见，核心只需四个步骤。这并非玄学，而是可重复运用的方法论。

在此之前，需要明确一个核心问题：这条评审意见的读者是谁？

是刚入职两周、仍在学习项目命名规范的新人？是熟悉业务模块但首次接触新框架的资深工程师？还是负责合入PR的技术负责人？

不同角色，需求截然不同。行业普遍认为，同样的“该函数存在性能风险”这一意见，面向新人和资深工程师所需的上下文密度完全不同。对新人，必须详细解释风险原因、具体哪个循环引发、修改后的示例；对技术负责人，只需一句“第45行存在低效查询，请参考db_session批处理示例”即可。

第一步：在提示词开头明确目标用户身份

直接清晰地指明，避免模糊。例如：“你正在为一位拥有3年Python后端经验、刚加入团队两周、正在审查Django权限模块PR的工程师撰写评审意见”。

仅写“面向开发者”毫无意义。笼统地写“面向同事”也远远不够——你与同事之间的能力差距可能需要两种语言才能沟通。

第二步：用括号注明该用户的常见认知盲区

在角色描述后附加括号说明。例如：“（他熟悉Django ORM，但未接触过本项目自研的rbac_sync装饰器）”。

这一步决定了Claude是否会主动展开解释原理，还是默认跳过说明直接给出改进建议。这一点至关重要。

【必须写明具体技术点，避免使用“不熟悉相关技术”这类空泛表述】

第三步：明确意见的交付场景与预期动作

场景不同，撰写方式截然不同。

方法一：PR评论场景。明确说明“这条意见将作为GitHub PR下的单条评论发布，作者将直接查看，且不附带其他上下文”。这样Claude就不会出现“参考上文第3节”这种令人困惑的表述，也不会假设读者能自己点击链接。

方法二：同步会议纪要场景。说明“这条意见将放入每日站会共享文档，由3名跨职能成员（前端1人、后端2人）快速浏览”。Claude会自动压缩篇幅，将结论置于最前，并剔除仅调试时才用到的细节。

第四步：提供反例，迫使Claude避免模糊表述

在提示词末尾增加一条硬性约束：“禁止出现以下表述：‘建议优化逻辑’‘此处可读性较差’‘考虑边界情况’。每条意见必须包含——① 具体哪一行或哪个函数 ② 当前行为导致的实际后果（例如：并发时token重复释放、iOS15下按钮失焦） ③ 修改后的代码片段或修改示意”。

到这里你是否也发现了？优秀的代码评审意见本质上只需三个要素：具体行号、实际后果、修改代码。不解释逻辑、不说明后果、不提供修改代码——那只能算点评，而非评审。