用了一段时间 Claude Code, 你会发现大部分翻车的会话不是模型不行, 是你自己的 prompt 有问题。Claude 能猜你的意图, 但你没法指望它会读心。

把任务范围卡死

“帮我优化一下这段代码”——这种 prompt 出来什么结果全看运气。什么叫优化? 性能、可读性、还是裁掉冗余代码?

好的 prompt 应该说清楚文件、场景和验证方式:

给 src/auth.ts 写一个已登出用户的边缘用例测试, 不要用 mock.

任务范围越小, 结果越可控。模糊的 prompt 只有在一种情况下有用——你真的想让 agent 给意见的时候。“这个文件你有什么改进建议"就很合适, 但记得限定范围, 别让它自己逛到几百个文件里去。

指一个现成的例子

Claude 从真实代码里学规范比从文字描述里学快得多。你不需要跟它解释"我们项目的命名规范是驼峰、接口前缀有 I 开头”——

参考 src/services/user.ts 的写法, 用同样的模式实现这个新接口.

一句话, 比一百字描述都有用。

报 Bug 按固定格式来

我 debug 的时候用这个格式, 很少出问题:

症状: 用户登录后跳到 404 页面
位置: src/router/index.ts 第 42-56 行的路由守卫逻辑
修复标准: 登录后跳到 redirect 参数指定的页面, 没有 redirect 就去首页

再加一句 “先写一个能复现的测试再修”, 能防止它改完了但什么都没修。

用 /btw 处理临时小问题

有时候你做到一半, 突然想确认一个不相关的事——“这个包的 API 签名是什么样的?"。如果用主会话问, 它会污染上下文。用 /btw 这个包的 API 签名是什么 问, 答案会以浮层显示, 不进对话历史, 不占上下文。

自己不要复述代码

你不需要替 Claude 读代码。直接把上下文喂给它:

• @file 引用项目里的文件
• 用 pipe: cat package.json | claude -p "检查依赖版本"
• Claude 桌面版能看截图, 直接贴

你自己复述不仅累, 还容易漏掉关键细节。

一次只做一件事

把这个组件拆成三个子组件, 同时修掉它的性能问题, 再加一个加载状态.

这条 prompt 踩了三个坑。拆开来:

1. “把这个组件拆成三个子组件, 保持现有接口不变”
2. “优化列表渲染的性能, 用虚拟滚动”
3. “添加 loading 状态”

每个任务独立完成、独立审查、独立提交。听上去慢, 但实际上比混在一起让 Claude 来回改快得多。

大功能先让 Claude 采访你

有一次我要做一个比较大的功能, 不确定的地方很多。我试了个方法: 先给一个非常简单的描述, 然后让 Claude 用 AskUserQuestion 工具采访我。

我想加一个用户邀请功能。用 AskUserQuestion 采访我,
问技术实现、UI/UX、边缘情况、权衡取舍。
不要问显而易见的问题, 深挖那些我没考虑到的难点。
采访完写一份完整的 SPEC.md。

Claude 会一轮一轮问你, 直到覆盖所有方面。然后产出一份完整的 spec。你再开一个新会话照着 spec 做, 上下文从头就是干净的, 而且有书面文档可以对照。

让它自己查 CLAUDE.md

如果你发现每次新会话的前两三条消息都是在解释项目背景——测试怎么跑、目录怎么组织——那这些东西就该写到 CLAUDE.md 里。写进去之后 Claude 每次启动会自动读, 你再也不用重复。怎么写在后面有一篇专门聊。

文章链接：