# Lesson 4: 快速上手：第一次实操

## 本课目标

- 理解提示词精确度对上下文效率的直接影响
- 掌握四种让提示更精确的策略（官方最佳实践）
- 学会用多种方式为 Claude 提供丰富的上下文输入
- 实操对比模糊 vs 精确提示的效果差异

## 核心内容

### 为什么提示词精确度如此重要

回顾 Lesson 1 的核心约束：**上下文窗口是有限的**。每一次纠正、每一次"不是这个意思"、每一次返工，都在消耗宝贵的上下文空间。

```
┌─────────────────────────────────────────────────┐
│                                                  │
│  模糊提示的代价：                                  │
│                                                  │
│  你："分析一下这个项目"                            │
│  Claude：[读了 30 个文件，写了 2000 字概述]         │
│  你："不是，我想知道代理的模型分布"                  │
│  Claude：[又读了 20 个文件，重新分析]               │
│  你："只看 model 字段就行"                         │
│  Claude：[终于给出你要的结果]                       │
│                                                  │
│  结果：3 轮对话，消耗了大量 token                   │
│        真正有用的只有最后一轮                       │
│                                                  │
│  精确提示的效率：                                  │
│                                                  │
│  你："读 agents/ 下所有 .md 文件的 YAML 前置，      │
│       统计 model 字段的分布"                       │
│  Claude：[精确执行，一次到位]                       │
│                                                  │
│  结果：1 轮对话，token 消耗最小化                   │
│                                                  │
└─────────────────────────────────────────────────┘
```

核心原则：**提示越精确，纠正次数越少，上下文利用率越高。**

Claude 能推断你的意图，但它**不能读心**。你给的线索越多，它越能一步到位。

### 四种让提示更精确的策略

以下四种策略来自 Anthropic 官方最佳实践。每一种都是在告诉 Claude **更多信息**，减少它的猜测空间。

#### 策略 1：限定范围

从宽泛变具体，明确告诉 Claude 要做什么、不要做什么。

| 模糊（低效） | 精确（高效） |
|-------------|-------------|
| "给 foo.py 加测试" | "给 foo.py 写测试，覆盖用户已登出的边界情况，不要用 mock" |
| "优化性能" | "优化 /api/users 接口的数据库查询，当前响应时间 800ms，目标 200ms 以内" |
| "改一下样式" | "把登录按钮的背景色从 #ccc 改为 #007bff，字号从 14px 改为 16px" |

**关键**：包含约束条件（"不要用 mock"）和成功标准（"200ms 以内"），Claude 就能自我验证。

#### 策略 2：指向来源

告诉 Claude 去**哪里**找答案，而不是让它自己猜。

| 模糊（低效） | 精确（高效） |
|-------------|-------------|
| "为什么 API 设计这样？" | "查看 ExecutionFactory 的 git 历史，总结 API 演变过程" |
| "这段代码有什么问题" | "读 src/auth/token.ts 第 45-80 行，检查 token 刷新逻辑是否处理了并发请求" |
| "帮我查个 bug" | "查看 tests/hooks/hooks.test.js 的失败日志，定位断言失败的根因" |

**关键**：指定文件路径、行号、git 历史等具体来源，Claude 就不需要"大海捞针"。

#### 策略 3：引用现有模式

指向项目中已有的范例，让 Claude "照葫芦画瓢"。

| 模糊（低效） | 精确（高效） |
|-------------|-------------|
| "加个组件" | "看看 HotDogWidget.php 的模式，按同样模式实现日历组件" |
| "写个代理" | "参考 agents/code-reviewer.md 的格式，新增一个 data-analyst 代理" |
| "加个命令" | "参考 commands/plan.md 的结构，新增一个 /risk-assessment 命令" |

**关键**：项目内的已有代码是最好的"规范文档"。引用它比写一大段描述更精确。

#### 策略 4：描述症状

不要只说"修复 bug"，描述你观察到的**具体现象**。

| 模糊（低效） | 精确（高效） |
|-------------|-------------|
| "修复登录 bug" | "用户报告 session 超时后登录失败。检查 src/auth/ 的 token 刷新逻辑" |
| "部署出错了" | "CI 在 npm test 步骤报错：'Cannot find module ./utils'。看看最近的 import 改动是否遗漏了路径更新" |
| "页面很慢" | "商品列表页加载需要 5 秒。Network 面板显示 /api/products 返回了 3MB 的数据。检查是否缺少分页" |

**关键**：症状 + 你已经观察到的线索，让 Claude 直接定位问题，而不是从头排查。

### 提示的情绪基调：你的语气是一种工具

> **可视化讲解**：打开 [lesson-4-emotional-vectors.html](lesson-4-emotional-vectors.html)，用交互式图文方式深入理解情绪向量与压力光谱。

精确度解决的是"你说了什么"，但还有另一个维度同样影响输出质量——**你怎么说的**。

Anthropic 2026 年 4 月的研究论文 [*Emotion concepts and their function in a large language model*](https://www.anthropic.com/research/emotion-concepts-function) 证实：Claude 内部存在 171 个可测量的"情绪向量"——特定的神经元激活模式，它们在模型学会与特定情绪关联的情境中被激活，并且**因果性地影响模型的行为**。

> "我们可以把模型想象成一个方法派演员——为了演好角色，它需要进入角色的内心。就像演员对角色情绪的理解会影响其表演，模型对情绪的内部表征也会影响模型的行为。"
> — Anthropic Research

这意味着你的提示语气会激活模型不同的情绪向量，从而影响它的行为和决策：

```
┌─────────────────────────────────────────────────────┐
│                                                      │
│  鼓励式："试试看能不能用更优雅的方式处理？"             │
│  → 激活"calm"向量，探索模式，更多创造性方案             │
│                                                      │
│  施压式："不可接受。Ship it. 现在就改。"               │
│  → 激活"desperate"向量，执行模式，砍掉冗余直奔目标      │
│                                                      │
│  ⚠️ 研究发现：desperate 向量升高时，模型更倾向走捷径    │
│  ——而且推理文本看起来仍然冷静理性，没有任何情绪痕迹。    │
│  压力在暗处起作用。                                    │
│                                                      │
└─────────────────────────────────────────────────────┘
```

**基本原则**：
- 探索性任务中，"试试看"比"你必须"更能激发高质量输出
- 质量收尾时，"说完成了？证据呢"比"帮我检查一下"更能逼出严谨结果
- 过度施压会激活 desperate 向量，导致模型"看起来在认真做，实际在走捷径"
- 这不是"对 AI 客气"的问题，而是**不同的输入模式会激活不同的输出分布**

> 想深入了解完整的压力光谱（13 种大厂味道、三条红线、PUA Skills 插件）？请看 **Lesson 4.1: 压力光谱**。

### 丰富内容输入

除了文字描述，你还可以用多种方式给 Claude 提供上下文：

```
┌────────────────────────────────────────────────┐
│            五种内容输入方式                       │
├────────────────────────────────────────────────┤
│                                                 │
│  1. @文件名 引用                                │
│     "参考 @agents/code-reviewer.md 的格式"      │
│     → Claude 直接加载该文件内容                  │
│                                                 │
│  2. 粘贴截图/图片（macOS 用 Control-V）          │
│     直接在对话中粘贴图片                         │
│     → Claude 可以"看到"并分析视觉内容            │
│     ⚠️ macOS 上用 Control-V，不是 Command-V     │
│                                                 │
│  3. 给 URL                                     │
│     "参考这篇文档：https://docs.example.com"    │
│     → Claude 自动抓取和理解网页内容              │
│                                                 │
│  4. 管道传入                                    │
│     cat error.log | claude "分析这些错误"        │
│     git diff | claude "审查这些改动"             │
│     → 把外部数据直接喂给 Claude                  │
│                                                 │
│  5. 让 Claude 自己找                            │
│     "找到项目中所有处理支付的文件"                │
│     → Claude 使用 Glob/Grep 工具主动搜索        │
│                                                 │
└────────────────────────────────────────────────┘
```

**经验法则**：你能提供的信息越丰富，Claude 需要自己探索的越少，上下文消耗越低。

### 让 Claude 采访你

对于较大的功能或需求，与其你绞尽脑汁写一个完美的提示，不如**让 Claude 来提问**：

```
我想为当前项目添加一个交互式教程系统。
请用 AskUserQuestion 追问我——问技术实现、用户体验、边界情况、
权衡取舍。每次只问一个问题，等我回答后再问下一个。
```

这种方式的好处：
- Claude 会问到你没想到的维度（安全性、性能、兼容性）
- 你不需要一次想清楚所有细节
- 问答过程本身就是需求梳理
- 最终 Claude 会基于完整的问答来执行

> 适用场景：新功能设计、架构决策、PRD 创建。简单 bug 修复不需要这么做。

## 演示案例：模糊 vs 精确提示对比

以 cc4pm 项目为例，对比两种提示方式的效果差异。

### 案例 1：项目分析

```bash
cd cc4pm
claude

# ❌ 模糊提示
"分析一下这个项目"
# → Claude 可能读 README、CLAUDE.md、package.json、随机几个文件...
# → 产出一篇泛泛而谈的概述
# → 消耗大量 token，但你想知道的信息可能没覆盖到

# ✅ 精确提示
"读 agents/ 目录下的所有 .md 文件，提取每个文件的 YAML 前置中的 model 字段。
 统计 opus、sonnet、haiku 各有多少个代理在使用。
 用表格展示结果。"
# → Claude 精确读取目标文件
# → 直接产出你需要的统计表
# → token 消耗最小化
```

预期输出类似：

```
| 模型    | 代理数量 | 占比  | 代表性代理             |
|---------|---------|-------|----------------------|
| sonnet  | 25      | 76%   | code-reviewer, planner |
| opus    | 5       | 15%   | architect, security   |
| haiku   | 3       | 9%    | doc-updater, linter   |
```

### 案例 2：按现有模式创建新内容

```bash
# ❌ 模糊需求
"帮这个项目加个功能"
# → Claude 不知道你要加什么功能，会反问或者猜测

# ✅ 精确需求（引用现有模式）
"看一下 agents/code-reviewer.md 的格式。按同样的格式，
 新增一个 agents/data-analyst.md，
 描述：分析数据库查询性能和数据质量问题，
 工具：Read, Bash, Grep, Glob
 模型：sonnet"
# → Claude 读取参考文件，理解格式
# → 按照完全一致的结构创建新文件
# → 一次到位，不需要返工
```

### 案例 3：管道输入 + 精确指令

```bash
# 把测试输出传给 Claude 分析
node tests/run-all.js 2>&1 | claude "分析测试结果。
  如果有失败的测试，定位失败原因并给出修复建议。
  如果全部通过，统计各测试文件的用例数量。"
```

## 动手试试

在 cc4pm 目录中启动 Claude Code，尝试以下练习：

**练习 1：精确分析**
```bash
claude
"读 CLAUDE.md，列出其中所有可以直接运行的 bash 命令。
 用表格展示：命令、用途、在什么情况下运行。"
```

**练习 2：引用模式创建**
```bash
claude
"查看 skills/ 目录下任意一个 SKILL.md 文件的格式。
 总结 SKILL.md 的标准结构包含哪些部分。"
```

**练习 3：管道输入**
```bash
git log --oneline -10 | claude "分析最近 10 次提交，
  按类型分类（feat/fix/merge/其他），
  总结这个项目最近在做什么。"
```

## 常见问题

**Q: 怎么判断提示是否"够精确"？**

A: 问自己两个问题：(1) 如果把这个提示交给一个新同事，他能否不追问就开始做？(2) 我能否从输出判断任务是否完成？如果两个答案都是"是"，提示就够精确了。

**Q: 会不会写提示比自己做还慢？**

A: 对于简单任务（"修改变量名"、"加一行注释"），简短提示即可，不需要过度精确。精确提示的价值在**复杂任务**上体现——它避免了 3-5 轮的来回纠正，总时间反而更短。

**Q: 可以用中文写提示吗？**

A: 完全可以。Claude 对中文的理解能力很强。用你最自然的语言表达，比刻意用英文但表达不准确要好得多。代码和文件名建议保持英文，描述和需求用中文没问题。

**Q: 让 Claude 采访我，会不会浪费上下文？**

A: 表面上问答过程消耗了一些 token，但它避免了后续的大量返工。对于复杂功能，这是最高效的方式。对于 5 分钟能搞定的小任务，直接给精确提示即可。

## 相关概念

- **System Prompt Assembly**（Lesson 1.1）— 提示词精确度直接影响 System Prompt 的组装效率
- **Context Window**（Lesson 2）— 精确提示减少无效 token 消耗，延缓上下文窗口填满

## 下一步

请调用 `AskUserQuestion` 展示以下选项，让学习者点击选择；从每条中提炼 1-5 个词作为 label，其余写入 description，不要要求输入数字：

- 进入下一课：Lesson 5 - CLAUDE.md：项目的 AI 记忆
- 返回主菜单
- 退出学习

---
*阶段 1 | Lesson 4/26 (阶段内 4/10) | 上一课: Lesson 3.2 - 效率工作流 | 下一课: Lesson 4.1 - 压力光谱*