Claude写代码review意见的提示词

写提示词这事儿，说白了就是让AI替你干活时，别让它跑偏。尤其是代码审查这种需要专业判断的任务，光说“看看这段代码有没有问题”远远不够——你得告诉它你是谁、要查什么、怎么输出、避开哪些坑。

下面直接拆解一套经过验证的提示词写法，每个环节都有干货，照着改就能立竿见影。

明确角色与目标

提示词开头就得亮明身份。别用“你是一个代码助手”这种模糊设定，换成“你是一位有5年后端开发经验的资深工程师，正在为团队做PR级代码审查”。角色一明确，Claude的反馈颗粒度会直接提升一个档次——它知道该用工程思维而非语法检查器来思考。

紧接着用一句话锁死目标：

约束输出格式

给出固定的答题框架，比自由发挥强得多。每条意见必须包含四个要素：问题类型（比如“空指针风险”“竞态条件”“N+1查询”）→ 具体位置（文件名+行号）→ 复现路径（1–2句话说明什么输入或状态会触发）→ 修复建议（能直接粘贴的代码片段，不是模糊描述）。

语气上也要硬起来。禁止“可以考虑”“建议优化”这类软词，一律用“应替换为”“需添加校验”“必须加锁”。这不是不礼貌，是代码审查的纪律性要求。

注入上下文锚点

有两种方式能把业务上下文塞进提示词，效果都很好。

一种是把关键业务规则当作前置条件写进去。比如：“该函数处理金融交易，金额字段不能为空且必须大于0，所有数据库操作需满足幂等性。”——有了这个背景，Claude就不会拿通用工具库那套来检查。

另一种是给最小可复现片段。把出问题的3–5行代码，连同它的上游调用链一起附上。比如“被PaymentService.process()调用，传入参数为order_id=‘ORD-789’”。经验表明，这样做的准确率比单纯说“检查这段代码”高出4倍以上。

屏蔽干扰项

AI很容易在无关细节上纠缠。所以需要提前画好禁区。

第一步：声明排除项——“不评论缩进风格、变量命名长度、是否用了Lambda表达式”。把这些噪音提前过滤掉。

第二步：禁用模板话术——“禁止出现‘代码整体质量良好’‘注意可读性’等无效结论”。这些废话除了占字数，没有任何价值。

第三步：设定阈值——“单个文件反馈不超过5条，优先级按：崩溃风险＞数据泄露＞功能偏差＞资源泄漏排序”。这样Claude会把火力集中在真正要命的问题上，而不是均匀分布到鸡毛蒜皮。