Stone's Blog

blog.tao-studio.net

0%

从头学 Claude Code（四）怎么和它说话？——高效沟通技巧

发表于 分类于 ， ， ，
本文字数： 2.2k 阅读时长 ≈ 2 分钟
和 Claude Code 高效沟通的秘诀是：好的提示 = 清晰的目标 + 足够的上下文 + 明确的验收标准。提示词基本结构就像点菜：背景（菜单前情提要）+ 任务（要点什么）+ 要求（忌口和特殊需求）+ 验收（怎么算吃完）。

从头学 Claude Code（四）—— 怎么和它说话？

本系列适合零基础新手，手把手带你掌握 AI 编程助手

上节回顾

上一讲我们熟悉了 Claude Code 的工具箱。这一讲，我们来学学怎么和它沟通。

就像请了个实习生，你得告诉他要做什么，他才能帮你。说清楚了，活才干得好。

1. 为什么提示很重要？

想象一下：

你对一个真人实习生说：“帮我看看那个东西怎么弄”

实习生内心 OS：？？？哪个东西？？？怎么弄？？？

实习生不是你肚子里的蛔虫，它需要清楚的任务说明，才能把事情做好。

同样，Claude Code 需要你告诉它： - 要做什么（目标） - 做到什么程度（标准） - 有什么限制（约束）

💡 金句：好的提示 = 清晰的目标 + 足够的上下文 + 明确的验收标准

2. 提示词基本结构：点菜的学问

去餐厅吃饭时，你会怎么点菜？

❌ 乱点一通： > “来点吃的”

✅ 清晰点单： > “我要一份宫保鸡丁（不要辣），一碗米饭，再来一碗酸辣汤”

点菜模板：

1
2
3
4
5
6
7
8
9
10
11
## 背景（菜单前情提要）
[这是什么地方的餐厅、谁来吃、什么口味]

## 任务（你要点什么）
[你要做的事情]

## 要求（忌口和特殊需求）
[具体标准、限制、格式等]

## 验收（怎么算吃完）
[如何判断任务完成]

例子对比：看病和教看病

❌ 模糊的病情描述： 

1
帮我看看代码有什么问题

相当于去医院说：“医生，我不舒服”

✅ 清晰的病情描述： 

1
2
3
4
5
6
7
8
9
10
11
12
## 背景
这是一个 Vue 3 的电商项目，使用 Pinia 管理状态

## 任务
查看 src/stores/cart.js 的代码，找出性能问题

## 要求
- 指出具体问题所在
- 给出优化建议

## 验收
列出至少 3 个具体问题和解决方案

相当于去医院说： > “医生，我最近三天吃完饭就胃疼，尤其是吃油腻的东西。疼的位置是左上腹隐隐作痛，持续半小时左右。没有拉肚子，但有点反酸。之前吃了奥美拉唑没效果。”

3. 沟通四大原则

原则一：明确意图 —— 说清楚，别绕弯

❌ 模糊： 

1
那个文件改一下

✅ 清晰： 

1
修改 config.json，把 debug 字段改为 false

就像对实习生说”那个啥弄一下”——不如直接说”把茶几上的杯子拿到厨房”

原则二：分步执行 —— 别一口吃成胖子

❌ 一步到位： 

1
帮我重构整个后端，从数据库到 API 全部重写

✅ 分步进行： 

1
2
3
1. 先帮我分析当前的数据库结构
2. 确认后，帮我设计新的 Schema
3. 再实现 API 接口

就像让实习生”帮我建一栋楼”——不如说”先帮我画个图纸”

原则三：及时反馈 —— 就像打羽毛球

交互就像打羽毛球：你要接住它打过来的球，也要把它打回去

  • 如果方向错了，立即纠正——“不对不对，是往左，不是往右”
  • 如果有特殊要求，提前说明——“对了，咖啡不要糖”
  • 如果满意，及时确认——“对，就是这样，很好”

原则四：保留上下文 —— 就像连续剧

  • 同一个项目内，可以连续对话——就像电视剧上下集
  • 之前的修改，后续可以继续调整——人物关系还在
  • 不需要每次都重复背景——演员记得剧情

⚠️ 但注意：如果换了个项目，就像换了部剧，要重新介绍人物

4. 常见场景的提示模板

场景一：修复 Bug（就像描述病情）

1
2
3
4
5
6
7
8
9
10
11
12
## 背景
[项目类型] 的 [模块]，用户反馈 [具体问题]

## 任务
找到并修复这个 bug

## 信息
- 错误信息：[粘贴错误日志]
- 复现步骤：[如何触发]

## 验收
修复后代码能正常运行

场景二：添加功能（就像点菜）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
## 背景
[项目情况]

## 任务
在 [位置] 添加 [功能名称] 功能

## 功能需求
1. [需求点 1]
2. [需求点 2]

## 约束
- 使用 [技术栈/规范]
- 不要修改 [其他模块]

## 验收
[测试方式]

场景三：代码审查（就像做体检）

1
2
3
4
5
6
7
8
9
10
## 任务
审查 src/api/user.js 的代码

## 审查重点
- 安全性（有没有漏洞）
- 性能（有没有浪费资源）
- 代码规范（写得整不整洁）

## 验收
输出审查报告，列出问题和建议

5. 进阶技巧

技巧一：限制工具范围 —— 就像给实习生立规矩

1
只使用 Read、Glob、Grep 工具，不要使用 Edit 或 Write

就像说：“你就在旁边看看，别动手啊”

技巧二：指定输出格式 —— 就像要求格式化

1
2
3
4
5
6
用 JSON 格式输出结果：
{
  "file": "路径",
  "issue": "问题描述",
  "fix": "修复建议"
}

就像说：“报告写整齐一点，用表格形式”

技巧三：设置检查点 —— 就像玩游戏存档

1
2
3
1. 先列出修改计划，我确认后再执行
2. 每修改一个文件，征询我的意见
3. 全部完成后做一次整体验证

就像说：“每一步都先问我能不能继续”

6. 这些不要做！避坑指南

❌ 错误做法 ✅ 正确做法
直接上传文件不说目的 说明要做什么
说”随便弄弄” 给出具体标准
改错了不指出 立即纠正方向
任务太复杂 拆分成多个步骤
不检查结果 及时验证输出

本节小结

  • 提示结构：背景 + 任务 + 要求 + 验收（就像点菜模板）
  • 四大原则：明确、分步、反馈、保留上下文
  • 进阶技巧：限制工具、指定格式、设置检查点

💡 记住：你越说清楚，它干得越好！

下节预告

下一讲：学习一个强大的工作流方法——4A 分析法

有问题？评论区见！如果觉得有帮助，点个赞再走~

标签: #Claude Code #AI编程 #编程助手 #沟通技巧