要让Claude写出具体、可执行的代码评审意见，需四步：一明确目标用户身份及任务；二括号补充其具体认知盲区；三指定交付场景与动作预期；四用反例约束表述，强制包含行/函数、实际后果、修改代码。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Claude在代码评审中写出具体、可执行的意见，必须先明确告诉它“谁在看这条意见”——是刚入职的应届生？是熟悉业务但不熟悉新框架的资深工程师？还是负责合并PR的TL？不同角色需要的信息颗粒度、术语深度、上下文依赖完全不同。
第一步：在提示词开头锁定目标用户身份
直接写明角色+经验范围+当前任务，例如：“你正在为一位有3年Python后端经验、刚加入本团队两周、正在review一个Django权限模块PR的工程师写评审意见”。
不能只说“面向开发者”，这等于没说；也不能笼统写“面向同事”，同事之间能力差异可能极大。
第二步：用括号补充该用户的典型认知盲区
在角色描述后加一句括号说明，例如：“（他熟悉Django ORM，但没接触过本项目自研的rbac_sync装饰器）”。
这一步决定了Claude是否会自动解释装饰器原理，还是默认跳过说明直接提改进建议。
该技能指导用户根据设计灵感创建视觉情绪板。它提供分步说明，用于提取颜色、排版和UI模式，并将其组织成文档化的设计方向。工作流程包括根据用户反馈进行迭代优化，最终形成可供实施的设计系统。
【必须写具体技术点，不能写“不熟悉相关技术”这种空泛描述】
第三步：指定意见的交付场景和动作预期
方法一：PR评论场景
写明“这条意见将作为GitHub PR下的单条评论发出，作者会直接看到，且不会附带其他上下文”。Claude就会避免写“参考上文第3节”，也不会假设读者能点开链接。
方法二：同步会议纪要场景
写明“这条意见将放入每日站会共享文档，由3名跨职能成员（前端1人、后端2人）快速扫读”。Claude会主动压缩长度、前置结论、剔除调试细节。
第四步：给一个反例，强制Claude避开模糊表达
在提示词末尾加一句：“禁止出现以下表述：‘建议优化逻辑’‘此处可读性较差’‘考虑边界情况’。每条意见必须包含：① 具体哪一行/哪个函数 ② 当前行为导致什么实际后果（如：并发时token重复释放、iOS15下按钮失焦）③ 修改后的代码片段或伪代码。”
