Claude写代码修改计划提示词如何生成多个角度

必须按四类角度结构化评估：①兼容性影响→用“✅”或“⚠️”开头；②性能开销→标注CPU/内存/IO中至少两项，单位毫秒或KB；③测试覆盖缺口→列具体用例名；④回滚可行性→三选一。禁用模糊词，无依据写“暂无依据”。

要让Claude在写代码时自动从多个角度思考修改计划，必须让它明确知道“角度”具体指什么、每个角度要输出什么格式、以及不同角度之间不能重复或遗漏。

第一步：定义清晰的“角度”类型

打开新对话，在第一条消息中直接列出你要覆盖的视角类别，例如：【必须包含且仅限这四类：兼容性影响、性能开销、测试覆盖缺口、回滚可行性】。不写“比如”“例如”，不加“等”字，每类用中文顿号分隔，结尾不加句号。

这一步漏掉任何一类，Claude就会默认只按常规逻辑推演，不会主动补全维度。

第二步：强制结构化输出格式

在定义完角度后，立刻指定输出模板：“请严格按以下顺序和格式输出，不得合并、省略或调整顺序：① 兼容性影响 → 用‘✅ 保持向后兼容’或‘⚠️ 需修改调用方’开头；② 性能开销 → 必须标注‘CPU/内存/IO’三项中的至少两项，数值单位统一为毫秒或KB；③ 测试覆盖缺口 → 列出具体缺失的测试用例名称（如test_invalid_input_v2）；④ 回滚可行性 → 用‘可单步回退’‘需数据库迁移’‘不可逆’三选一。”

模板里带编号和箭头符号，Claude会照着格式填空，而不是自由发挥。

第三步：切断泛化表达路径

在提示词末尾加一句硬性约束：“禁止出现‘可能’‘一般’‘通常’‘建议’等模糊表述；所有判断必须基于你当前看到的代码片段，若某角度无相关信息，写‘暂无依据’而非跳过该条。”

这一步堵死它用套话充数的路——没有上下文支撑的推测，Claude会直接放弃生成，而不是编造结论。

方法一：用角色指令锚定思维框架

在系统级提示中设定角色：“你现在是资深后端架构师，正在给初级工程师做代码评审。你的任务不是优化代码，而是预判这次修改会在四个确定维度上引发什么连锁反应。”

角色越具体，Claude越容易调用对应领域的检查清单，而不是泛泛而谈“这个改法不错”。

方法二：注入反例触发多维校验

提供一个错误示例并要求对比：“下面是一个只考虑性能、忽略回滚的修改方案：[粘贴一段代码]。请指出它在哪几个角度上存在缺陷，并按前述四类结构重写完整评估。”

Claude看到反例后，会自动激活纠错机制，比单纯说“请多角度思考”更可靠。