有效沟通三原则

跟 Claude Code 打交道，本质上是在做一件事：把你脑子里的想法准确传达出去。

很多人觉得 AI 不好用，其实不是模型不行，而是沟通出了问题。就像跟新同事协作，你说得越清楚，他做得越好。这里有三个核心原则，掌握了之后你会发现 Claude Code 的输出质量能上一个台阶。

原则一：具体化

模糊的指令是最大的浪费。

Claude Code 不会读心术，你给的信息越具体，它越知道该往哪个方向走。比较一下这两种说法：

看到区别了吗？具体版包含了三个关键信息：文件路径、场景描述、技术偏好。这三样东西给全了，Claude Code 基本不会跑偏。

原则二：指向已有模式

你的项目里已经有了大量的"范本"——现有的组件、API 路由、工具函数。与其花十行文字描述你想要什么风格，不如直接指一个现成的例子。

看 src/components/UserWidget.tsx 的实现方式，照着做一个 CalendarWidget。
数据从 /api/calendar 获取，展示方式和 UserWidget 类似，用卡片布局。

这条 prompt 之所以高效，是因为 Claude Code 会先读 UserWidget.tsx，理解你项目里的组件规范（状态管理用什么、样式方案是什么、错误处理怎么写），然后原样复刻到新组件上。

再比如：

参照 src/app/api/posts/route.ts 的模式，新建一个 /api/comments 的 CRUD 接口。
数据库表结构在 src/config/db/schema.postgres.ts 的 comment 表。

给范本比写说明书有效得多。Claude Code 不仅能看到代码，还能理解你团队的编码习惯。

原则三：描述症状，不要猜原因

这一条很多有经验的开发者反而容易犯错，因为他们习惯先猜原因。

为什么要描述症状？因为你猜的原因可能是错的。如果你说"token 刷新逻辑有问题"，Claude Code 会直奔 token 刷新去看，但真正的问题可能是 cookie 没设 httpOnly，或者 redirect URL 配错了。

给出症状，让 Claude Code 自己去排查，它反而能找到你没想到的根因。

更多 Before/After 对比

熟能生巧，再看几个例子：

场景：添加功能

❌ 帮我做个通知功能

✅ 在 src/shared/components/ 下新建 NotificationBell 组件。
   点击后展示下拉列表，数据从 /api/notifications 获取。
   未读通知显示红色圆点，参照 src/shared/components/Avatar.tsx 的弹窗交互方式。

场景：修复部署问题

❌ Vercel 部署失败了

✅ Vercel 部署在 build 阶段失败，错误信息是 "Module not found: Can't resolve 'sharp'"。
   本地 pnpm build 正常通过。检查 package.json 的 dependencies 和 .vercelignore 配置。

进阶技巧：让 Claude 采访你

如果你自己也说不清需求怎么办？有个非常好用的技巧——让 Claude Code 反过来采访你。

我想做一个支付功能，在动手之前，先采访我，问清楚所有你需要知道的事情。

Claude Code 会问你一系列关键问题：支持哪些支付方式？国内还是海外？需要订阅还是一次性付款？怎么处理退款？要不要对接 Webhook？

你逐一回答后，让它把采访结果整理成一份 Spec（技术方案文档）。然后开一个新的 Session，把 Spec 喂进去，让它按方案执行。

这个"采访→出 Spec→新 Session 执行"的流程，特别适合复杂功能的开发。

把 Claude Code 当高级工程师来提问

除了让它干活，Claude Code 还是一个非常好的"项目顾问"。你可以像请教一个刚加入团队的高级工程师一样问它：

• "这个项目的 logging 机制是怎么工作的？"
• "我要新加一个 API endpoint，标准流程是什么？"
• "帮我梳理一下 useAuth 这个 hook 的调用链，从组件到最终的 API 请求。"
• "项目里有没有现成的工具函数可以做日期格式化？"

它会读你的代码库然后给出准确回答，比翻文档快多了。

[!TIP] 养成一个习惯：在写 prompt 之前花 10 秒想一下——文件路径给了吗？有没有可以参考的范本？我是在描述症状还是在猜原因？这三个问题过一遍，prompt 质量就能翻倍。