高效沟通：跳出 Copilot 式补全思维

用 Copilot 久了，有一套默认的交流习惯会被带进 Claude Code，结果是不管怎么用都像在和一个不太灵光的补全工具打交道。根本差别在于：Copilot 时代你的 Prompt 其实是代码上下文——它盯着你的光标、看着你手边的几行代码帮你猜下一步，所以你说得少是因为环境替你说了。Claude Code 不看你的光标，也不知道你刚才在想什么，它必须被完整地告知目标。交流的单位因此从"提示一行"变成了"交代一项任务"。

这篇不是 Prompt 模板大全，是讲清楚几条在日常使用中真正有效的思维切换。模板抄一百个也不如理解背后的几条原则自己组合得出。

一句话要同时给出目标、约束、验收

新手最常写的 Prompt 是"加个登录"。这句话对补全工具够用，对 Agent 等于一个开放式问题——它要么回过头反问你一串细节，要么自作主张做一套你不想要的，两种结果都让你返工。可用的最小结构是目标加约束加验收：要做什么、在什么边界内做、怎么算完成。

同样是加登录功能，稍微展开就完全不同：

给这个项目加一个登录页面：
- 路径 /login
- 用 NextAuth v5，Credentials provider
- 用户表已在 db/schema.ts：users(id, email, password_hash)
- 登录成功跳首页，失败显示错误
- UI 复用现有的 shadcn/ui 组件
- 完成后跑 pnpm build 确认通过

这条指令里，目标（登录页面）、约束（用 NextAuth、复用 shadcn、已有的 users 表不要动）、验收（build 通过）都在，Agent 拿到之后不会再反问，也不会乱发挥。把这三段想清楚写下来，哪怕形式再简陋都比精心写的开放式问题有效。

过度详细同样是毛病。我见过有人写三千字讲项目背景再问"你觉得用什么比较好"，这种 Prompt 既浪费 token 也让 Agent 抓不到重点。节制的标准不是字数，而是"每一句都在帮它做决策"——背景信息如果和当前任务无关，删掉。

喂上下文，不要让它猜

Agent 不是无所不知，它只知道它读过的东西。所以给它上下文的速度往往决定结果的质量。最常用的办法是 @ 引用文件：在 Prompt 里写 @src/api/auth.ts，这个文件会被完整读入再配合你的问题处理。比"你看下 auth 相关的代码"高效得多，因为它不用去搜索、猜测，直接就在手上。

贴报错和日志同样朴素有效。"build 失败了帮我修"是典型的差指令，换成"我跑 pnpm build 报这个错" 然后把完整堆栈粘进去，Agent 立刻能定位到具体的符号和文件。图也可以直接拖进终端或者 Ctrl+V 粘贴——UI 截图、设计稿、报错截图都行。对于"照着现有风格写一个新组件"这种任务，最好的喂法是指一个参照："把 components/Button.tsx 当模板，给我写一个类似的 IconButton"——模仿比发明好控制得多。

让它先说再做

对于需求略模糊或者范围较大的任务，最有用的一条 Prompt 是"开始前先列出你准备做的事情，以及你不确定的地方（最多 5 个问题），等我回答再开始。" 这句话把 Agent 从"埋头干"切换成"先对齐"，你用一轮问答把它的理解纠正到位，剩下的执行就安心多了。对于涉及三个以上文件的任务，这条规则可以直接写进 CLAUDE.md 让它长期生效。

相应的另一面是执行完让它自我验证。Claude Code 能实际运行命令看结果，这是它比纯聊天模型大得多的优势，不用就浪费了。写任务的时候顺手加一句"做完后跑 pnpm test 确认通过并跑 pnpm build 确认编译"，或者对 API 类任务加一句"写完后 curl 调用一下那个接口贴出响应给我看"——Agent 会自己把验证动作跑掉，你不用手动去复查每一步。

负面指令的价值

Agent 对"看着别扭就顺手改掉"有天然偏好，写了一半会去"优化"配置、清理你没动过的代码、顺带重构几个相邻函数。大多数时候你并不希望这些动作发生，所以要显式禁止。"不要改 config/* 下的任何文件"、"不要重构其他地方，只改我说的"这类负面约束加上去，能省掉大量"咦它怎么把这个也改了"的返工。这条尤其在 bug 修复和小范围补丁场景重要——越是小任务，Agent 越容易越界。

类似的还有对节奏的约束。简单任务可以说"这个任务简单，别过度思考，直接改"；复杂任务反过来说"这个要仔细，先读代码再规划再写"。Claude Code 在 extended thinking 和普通模式之间会根据 Prompt 做判断，一句话就能把它推到合适的档位。

让它解释再改

对完全陌生的代码，尤其是改动前最好加一步："先读 lib/auth.ts 解释一下逻辑，确认你理解了，再动手改。" 如果它解释得不对，你立刻就发现方向跑偏了，这时候纠正成本接近零；如果它先改完再发现理解有误，改回去的成本要大得多。同样思路的还有"先写骨架（函数签名和 TODO），我审完再写实现"——对业务逻辑复杂的模块特别管用，能在早期截停错误方向。

常见的反模式

问"你觉得这样好不好"、"帮我优化一下"这类开放式问题几乎永远得不到有用答案。前者太模糊，Agent 会给你一堆不痛不痒的肯定；后者没说优化什么维度，结果可能是它去改一些你不想改的地方。改成"这样做有什么具体风险，给 3 个"、"把这个函数的时间复杂度从 O(n²) 降到 O(n log n)"——让它在明确维度上给答案。

一次塞五个不相关的任务是另一个常见坑。Agent 会把所有任务的上下文混在一起，结果每个都做得半吊子。拆开，之间用 /clear 分隔，每个会话专注一件事。相关联的任务可以放一起，但"顺便帮我 A、B、C、D、E"这种流水账要拆。

最后一条：改坏了不要去骂它。它不在乎你的情绪，只会在你的怒气里继续消耗 token。直接说"回退刚才的改动，换个思路"，必要时 /clear 重开一轮。语气温和、目标明确，比情绪化的指令有效得多。

从 Copilot 迁移过来最难改的习惯

一是不要再边写边改。Copilot 的节奏是"我写一行它补一行"，你和工具之间的反馈频率高但单次信息量小。Claude Code 反过来：单次信息量大、频率低，把任务说完整一次交付，比切成几十段来回啰嗦省时间得多。二是不要再一行一行看它写的代码——看 diff、看测试结果、看 UI 整体效果，把注意力抬高一层。三是信任但要验证：它声称改完了不等于对，跑测试、看 UI、必要时让它贴运行结果。四是多问"为什么这么做"——理解它的选择比接受它的代码更重要，尤其是它做了一个你不太熟的技术选型时。

把这几条走通，你会发现手里的工具从"一个会写代码的补全"变成了"一个能独立完成任务的同事"。下一篇把这些原则落到每天会重复遇到的几类任务里——bug 修复、新功能、重构、测试——讲每类任务背后合适的沟通节奏。

参考资料

• Anthropic: Prompt Engineering
• Claude Code Best Practices
• Awesome Claude Prompts