1.1 和 Claude Code 对话的正确姿势

学习目标

学会写出让 Claude Code 准确理解你意图的提示词
掌握好提示词和差提示词的区别
学会用 @文件名 引用项目文件
学会用 # 快速记忆重要信息

为什么提示词这么重要？

你跟 Claude Code 的对话，本质上就是在"下指令"。指令越清晰，它干活越靠谱。这跟你给同事交代工作一个道理——你说"帮我改改那个页面"，同事肯定一脸懵；你说"帮我把首页的导航栏背景色从白色改成 #1a1a2e，字体颜色改成白色"，同事立刻就能动手。

Claude Code 也是一样。给它越精确的上下文，它返回的结果越好。

好提示词 vs 差提示词

我们直接看对比，体感最明显：

对比 1：创建项目

差：帮我做个网站
好：用 Next.js 14 + TypeScript 创建一个个人博客项目，要求：
    - App Router 架构
    - 支持 Markdown 文章渲染
    - 首页展示文章列表，按时间倒序
    - 包含暗色模式切换

差在哪？"做个网站"——什么网站？用什么技术？什么功能？Claude Code 只能猜，猜的大概率不是你想要的。

对比 2：修 Bug

差：这个代码有 bug，帮我修
好：运行 npm run dev 后，点击登录按钮报错 "TypeError: Cannot read properties of undefined (reading 'email')"，
    错误出现在 src/components/LoginForm.tsx 的第 42 行。
    用户填完表单点登录后触发，空表单提交不会报错。

好的提示词包含了：什么操作 → 什么现象 → 在哪里 → 什么条件下触发。这就是经典的 Bug 报告格式，Claude Code 拿到这些信息可以精准定位问题。

对比 3：功能开发

差：给这个项目加个搜索
好：给文章列表页加一个搜索功能：
    - 在列表上方添加搜索输入框
    - 支持按标题和内容模糊搜索
    - 输入时实时过滤（debounce 300ms）
    - 无结果时显示"没有找到相关文章"的提示
    - 搜索框样式和现有的 UI 风格保持一致

对比 4：代码审查

差：看看这个代码有没有问题
好：审查 src/utils/auth.ts 这个文件，重点关注：
    - 有没有安全漏洞（特别是 token 处理）
    - 错误处理是否完善
    - 有没有可以优化的性能问题

对比 5：重构

差：重构一下这个文件
好：重构 src/api/userService.ts：
    - 把重复的错误处理逻辑提取成公共函数
    - 用 TypeScript 接口替代现在的 any 类型
    - 保持所有现有功能不变，写完跑一遍现有测试确认没问题

提示词的黄金公式

记住这个公式，写提示词基本不会翻车：

做什么 + 用什么技术 + 具体要求 + 约束条件

做什么：目标明确，一句话说清楚
用什么技术：框架、语言、版本号
具体要求：功能细节，越具体越好
约束条件：不要改哪些、保持什么风格、性能要求等

踩坑提醒：不要一次给太多不相关的任务。"帮我建个项目，顺便写个爬虫，再帮我看看那个 Bug"——这种 Claude Code 也会晕。一次专注一件事，效果最好。

用 `@文件名` 引用文件

当你想让 Claude Code 关注某个特定文件时，直接在对话中用 @ 引用：

@src/components/Header.tsx 把这个导航栏改成响应式的，手机端显示汉堡菜单

[截图: 输入 @ 后弹出的文件选择列表]

Claude Code 会自动读取这个文件的内容，然后基于文件现有代码来修改。比你说"改一下 Header 组件"靠谱得多，因为它确切知道你在说哪个文件。

多文件引用也没问题：

参考 @src/components/Header.tsx 的样式风格，给 @src/components/Footer.tsx 加上相同的响应式布局

踩坑提醒：@ 后面的路径是相对于你当前项目根目录的。如果文件不存在，Claude Code 会提示找不到。

用 `#` 快速记忆

在对话中输入 # 加一个关键词，可以快速添加记忆。比如：

# 这个项目用的是 pnpm 不是 npm

[截图: 使用 # 添加记忆的效果]

Claude Code 会把这条信息记下来，后续对话中会自动参考。这在你反复纠正同一个问题时特别有用——与其每次都说"用 pnpm 不要用 npm"，不如一次性让它记住。

常见问题

Q：英文提示词效果是不是比中文好？ A：Claude Code 对中文的理解能力很强，日常使用中文完全没问题。但如果涉及非常专业的技术术语，保留英文关键词会更准确，比如"用 React Server Components"比"用 React 服务端组件"更不容易歧义。

Q：一次能给多长的提示词？ A：很长都没问题，但建议结构化。用列表、分段来组织，而不是写一大段话。Claude Code 对结构化输入的理解能力明显更好。

Q：它理解错了怎么办？ A：直接告诉它哪里不对。"不对，我要的不是这个，我是说 xxx"。Claude Code 的上下文理解很好，会根据你的纠正调整方向。别不好意思"怼"它，说清楚才能干好活。

小结

这节课的核心就一句话：把 Claude Code 当成一个能力很强但不了解你项目背景的新同事。你给的信息越完整、越具体，它交付的活儿越好。下节课我们来学斜杠命令，这些是 Claude Code 的快捷操作入口。

1.1 和 Claude Code 对话的正确姿势 ​

学习目标 ​

为什么提示词这么重要？ ​

好提示词 vs 差提示词 ​

对比 1：创建项目 ​

对比 2：修 Bug ​

对比 3：功能开发 ​

对比 4：代码审查 ​

对比 5：重构 ​

提示词的黄金公式 ​

用 @文件名 引用文件 ​

用 # 快速记忆 ​

常见问题 ​

小结 ​