写提示词时，最怕什么？最怕写了半天，模型却理解偏了。很多人用Claude生成代码修改计划，习惯性堆砌“请仔细分析”“确保逻辑严谨”“兼顾可维护性与扩展性”这类空泛表述——听起来专业，实则不提供任何具体约束，反而稀释指令效力。想要得到可执行、可验证的输出，核心原则只有一条：让每一个词都指向可落地的动作。

剔除无意义的修饰动词

把“请务必仔细分析原始代码结构”换成“列出原始代码中所有调用了getUserById的文件路径及行号”。动词必须绑定可验证动作——否则模型只会给你一段模板化的“分析报告”，而不是你要的修改清单。

同理，“合理设计”“妥善处理”“充分考虑”这些词也该删掉。它们无法被模型执行，只会触发千篇一律的套话。

用显式边界替代模糊要求

方法一：限定输出格式与字段
与其说“给出清晰修改建议”，不如写“返回JSON数组，每个对象含file（字符串）、line（数字）、before（原代码片段，≤3行）、after（修改后代码，≤3行）四个键”。效果至少提升十倍——你拿到的是可以直接解析的结构。

方法二：禁用抽象术语
禁止在提示词中间出现“高内聚低耦合”“符合SOLID原则”等术语。Claude不会按真实工程标准来判断，它只会复述这些概念。正确的做法是替换成具体约束，比如“所有新函数必须接收完整参数，不得读取全局变量config”。

注入上下文锚点

第一步：在提示词开头插入一行真实上下文快照
例如：// 当前分支：main｜最后提交：2024-06-12｜关键依赖：axios@1.6.0, zod@3.22.4
这能让Claude立刻理解项目环境，避免生成与现有代码冲突的方案。

第二步：引用具体错误现象而非笼统说“有bug”
写“用户登录后跳转到/dashboard?ref=login，但路由守卫未识别ref参数，导致重定向失败”，而不是“修复路由相关问题”。越具体，越不可能被误读。

第三步：指定最小验证行为
加一句：“每项修改必须附带一行测试断言示例，格式为expect(router.currentRoute.value.query.ref).toBe('login')”。这个要求迫使Claude聚焦可落地的改法，而不是泛泛而谈。