第四章 学会和它对话（提示词与 CLAUDE.md）

一、开场对比：90% 的人输在第一句

我们先看两个完全相同的需求，被两种不同的人讲出来，会有什么差别。

写法 A：随手党

帮我写一封邮件。

Claude 给你的回信会是：

"好的，请告诉我邮件的收件人、主题和大致内容。"

你被反问了。每次回答完追问，下一次再用这种方式开头，AI 还会再问一遍。10 分钟过去，邮件没动一个字。

写法 B：完整党

请以我的名义，给客户 ACME 公司的 John 写一封英文商务邮件。
背景：
- 上周我们做了 V2 版本的演示，比 V1 性能提升了 35%；
- 我希望本周五下午 3 点（北京时间）给他做一个 30 分钟的线上演示；
- 我会同时把 V2 的产品说明书作为附件一起发出去。

要求：
- 商务正式英文，不要口语化；
- 全文不超过 150 词；
- 开头不要 "I hope this email finds you well" 这类客套话，直奔主题；
- 结尾署名 "Cassius from XYZ Corp."；
- 直接输出邮件正文，前后不要加任何解释。

Claude 给你的输出会是：

Hi John,

Following up on last week's session—our V2 release shows a 35% performance gain over V1. I'd like to walk you through the improvements in a focused 30-minute session this Friday, 3 PM Beijing time. The V2 product brief is attached for your reference ahead of the call.

Please confirm if the time works, or share two slots that suit you better.

Best, Cassius from XYZ Corp.

打开邮箱，复制，粘贴，发送。任务结束。

你看到了什么

差别不是 AI 聪不聪明，而是你说了多少。Claude Code 像一位刚入职的实习生：你交代得越清楚，他越省心；你越含糊，他越紧张。

这一章接下来要做的事，就是把"该说哪些"拆成可以背、可以套、可以复制的方法论。

二、提示词五要素：ROCFE 模型

我们把"该说什么"压成五个英文首字母，方便你随时回想：R-O-C-F-E。

ROCFE 是本书自创的助记法，目的是让你能张嘴就能复诵。你完全可以记成 ROFCE、CORFE，顺序不影响效果。

ROCFE 套用一个完整的"商务英文邮件"例子

我们把上一节的写法 B 改写成标准 ROCFE 结构：

[Role 角色]
你是 Cassius 在 XYZ 公司的英文邮件助理，文风专业、克制、不啰嗦。

[Objective 目标]
给客户 ACME 公司的 John 写一封英文商务邮件，邀请他参加本周五下午 3 点
（北京时间）的 V2 线上演示，时长 30 分钟。

[Constraint 约束]
- 必须提到 V2 比 V1 性能提升 35%；
- 必须告知会附 V2 产品说明书；
- 全文 ≤ 150 词；
- 商务正式英文，不要口语化；
- 不要 "I hope this email finds you well" 这类套话；
- 必须以 "Cassius from XYZ Corp." 署名结尾。

[Format 输出格式]
直接输出邮件正文，前后不要加任何解释、不要加引号、不要加 Markdown 包装。

[Example 示例]
风格参考（不要照抄内容，只学语气）：
"Hi John, I'd like to share a quick update — our V2 release shows a 35%
performance gain over V1. Could you join a 30-min demo this Friday at 3 PM
Beijing time? ..."

把这段贴给 Claude Code，几乎不会让你失望。

ROCFE 适用的场景

不只是写邮件，几乎一切"让 AI 帮我产出一个东西"的场景，都可以用 ROCFE 拆。

把这张表打印出来贴在显示器旁边。每次新任务开口前，先在脑子里走一遍 R-O-C-F-E。

三、XML 结构化模板：让 Claude 不"听漏"

ROCFE 解决了"该说什么"，但当你的指令越来越长，Claude 还是可能"听漏一点"。这时候要请出第二件法宝：XML 结构化模板。

为什么是 XML 而不是别的

Anthropic 在训练 Claude 时，大量使用了 XML 标签来标注训练数据中的不同部分。这意味着 Claude 在面对带有 <role>、<task>、<document> 这种标签的输入时，会本能地把它们当作"独立的语义块"对待——一个标签里的内容，不会和另一个标签里的内容相互"渗透"。

简单说：XML 标签对 Claude 来说，就是把内容打包到了一个个透明的盒子里，他能看清盒子里装了什么、属于哪一类。这是 Anthropic 的官方推荐做法。

这条对其他模型（GPT、DeepSeek、Kimi、Gemini）也都生效，只是对 Claude 效果最显著。本书所有的提示词模板默认走 XML 风格。

一份标准 XML 提示词模板

下面是一个可以直接套到 90% 任务上的万能模板：

<role>
你是一个面向中文用户的产品分析师，擅长把一份长报告凝练成 5 段式纪要。
</role>

<task>
请阅读 <document> 标签内的报告原文，按 <format> 标签的要求输出。
</task>

<document>
（这里贴你要分析的内容，可以很长，比如 5000 字的研报）
</document>

<constraint>
- 输出全程使用中文；
- 单段不超过 80 字；
- 数字一律保留原文，不要四舍五入；
- 引用具体数据时，括号注明出处段落号；
- 不要编造原文未出现的信息。
</constraint>

<format>
1) 一句话总结：……
2) 核心数据：……
3) 关键结论：……
4) 风险与不确定性：……
5) 建议的下一步：……
</format>

<example>
（可选，给一个理想样本，让模型对齐"好答案的样子"）
</example>

把这份模板理解为"骨架"——以后你做任何任务，只换内容、不换骨架。

写 XML 的三个铁律

经验告诉我们，下面三条规矩遵守一次，输出质量会跳一档：

铁律 1：标签内容尽量短，超过 200 字就再拆。

错例：

<constraint>
输出必须是中文。每段不超过 80 字。数字保留原文。引用要有段落号。
不要编造。如果遇到不确定的内容请标注待确认。语气要专业。要避免重复。
要保持客观。不要使用"我"或"我们"作为主语。所有专有名词第一次出现时
要标注英文原文……
</constraint>

正例：把它拆开。

<style>
- 全程使用中文；
- 语气专业、客观；
- 不要使用"我"或"我们"作主语。
</style>

<accuracy>
- 数字一律保留原文，不要四舍五入；
- 不要编造原文未出现的信息；
- 不确定的内容标注"待确认"。
</accuracy>

<format-rules>
- 单段不超过 80 字；
- 引用具体数据时，括号注明出处段落号；
- 专有名词首次出现标注英文原文。
</format-rules>

每个标签只管一件事，模型就不会混。

铁律 2：把最关键的约束放在最后。

人和模型一样，对最后看到的内容印象最深（学术上叫 recency bias）。所以你最在意的那一条规矩，别埋在中间，让它出现在最后一个 <format> 或 <final-check> 里。

铁律 3：关键约束写两遍。

如果某条要求"踩到一次就报废"——比如"输出必须是中文"，"绝对不能修改 .env 文件"——那就在 <constraint> 里写一遍，再在 <format> 末尾或新开一个 <must> 标签里重写一遍。重复不丢人，丢失指令才丢人。

<constraint>
- 输出必须是中文。
- ...其他约束...
</constraint>

<format>
请按以下结构输出，再次提醒：全程中文，绝对不要混入英文段落。
1) ...
2) ...
</format>

对比：纯文字 vs XML 的实际效果

让我们做一个对比实验。任务：让 Claude 总结一段话。

纯文字写法：

你是一个产品分析师，请总结下面这段话，要求中文输出，单段不超过 80 字，
不要编造信息。原文是：苹果公司 2026 年 Q1 财报显示营收增长 12%，
但服务收入下降 3%……

XML 写法：

<role>你是一个产品分析师。</role>

<task>请总结 <document> 内的财报内容。</task>

<document>
苹果公司 2026 年 Q1 财报显示营收增长 12%，但服务收入下降 3%……
</document>

<constraint>
- 中文输出；
- 单段不超过 80 字；
- 不编造信息。
</constraint>

两者实测差别：

XML 的本质，是让你的指令具备"可维护性"——这点对接下来要讲的 CLAUDE.md 和模板复用至关重要。

四、Claude Code 的"三层记忆系统"

写好提示词只是单次对话的事。如果你和 Claude Code 长期合作，每次都重新告诉它"我是谁、我喜欢什么、我的项目长什么样"，那真的太累了。

Claude Code 给你准备了一套三层记忆系统——把你想让它"以后永远记得"的事情写进文件，它每次启动都会自动读。

三层记忆是哪三层

~ 在 macOS / Linux 表示你的家目录，比如 /Users/cassius。在 Windows PowerShell 是 $HOME，通常是 C:\Users\你的用户名。

用一张图把三层记忆串起来

你打开终端，cd 到项目目录，敲了 claude
                    │
                    ▼
        Claude Code 启动，按顺序加载：
                    │
   ┌────────────────┴────────────────┐
   │ 第 1 层：全局记忆                │
   │ ~/.claude/CLAUDE.md              │  ← 你是谁、你的偏好
   └─────────────────────────────────┘
                    │
   ┌────────────────┴────────────────┐
   │ 第 2 层：项目记忆                │
   │ ./CLAUDE.md                      │  ← 项目目标、团队约定
   └─────────────────────────────────┘
                    │
   ┌────────────────┴────────────────┐
   │ 第 3 层：个人项目覆盖（可选）     │
   │ ./.claude/CLAUDE.local.md        │  ← 你私人的项目偏好
   └─────────────────────────────────┘
                    │
   ┌────────────────┴────────────────┐
   │ 第 4 层：目录记忆（按需懒加载）   │
   │ ./packages/api/CLAUDE.md         │  ← 进入子目录后加载
   └─────────────────────────────────┘
                    │
                    ▼
              进入对话框
        （所有上面的内容都已经"装进它脑子"）

四层加载顺序：全局 → 项目 → 项目个人 → 目录（按需）。

后加载的会"覆盖"前面同名的设定。例如全局里你写"默认中文输出"，但某个项目的 ./CLAUDE.md 写"本项目英文输出"，进这个项目目录后会按英文输出——离开这个目录回到家目录，又自动切回中文。

三层各管什么，不要乱写

./.claude/CLAUDE.local.md 这个文件默认会被加进 .gitignore——意味着你团队里的别人看不到它，可以放心写一些"只对你电脑生效"的偏好。

五、CLAUDE.md 是 Claude Code 的"灵魂"

如果 Claude Code 是一位新来的助理，那么 CLAUDE.md 就是你给他的**"员工手册 + 自我介绍 + 项目背景"三合一文档**。

写好它，你能少说 80% 的废话。

5.1 什么时候该写 CLAUDE.md

不要为了写而写。只在出现下面这些信号时，才需要把规则沉淀进 CLAUDE.md：

5.2 什么不该写

Anthropic 官方建议：单个 CLAUDE.md 控制在 50–200 行以内。再多 Claude 读起来也容易"抓不住重点"，而且每次对话都会消耗你的上下文窗口。

5.3 自动生成：/init 命令

不知道从哪里开始？让 Claude 自己写第一版。

进到你的项目目录，启动 Claude Code，输入：

/init

Claude 会做这几件事：

1. 扫描你这个项目的目录结构、package.json / pyproject.toml 等配置文件、README；
2. 推断这个项目用什么语言、什么框架、什么构建工具；
3. 在项目根目录生成一份初始的 CLAUDE.md，包含项目概览、构建命令、开发指南；
4. 你再人工审一遍，删掉它瞎猜的、补上它没看到的，40 分钟变 4 分钟。

/init 适合"已有项目从 0 到 1 写 CLAUDE.md"，不适合从无到有的新项目。新项目就直接用下面的模板抄一份。

5.4 模板 1：个人全局 ~/.claude/CLAUDE.md

这是你最该写的一份。它会跟随你每一个项目，是你的"AI 个人助理人格设定"。

# 关于我
- 名字：Cassius
- 系统：macOS 14.5（M1 芯片）
- 时区：Asia/Shanghai（UTC+8）
- 主语言：简体中文
- 工作场景：内容写作、技术研究、自动化脚本

# 沟通偏好
- 默认用简体中文回复，除非任务本身需要英文
- 风格：简洁、礼貌、少废话
- 不要在回复里加 emoji
- 不要在回复开头加"好的没问题"这类客套话
- 给我回复时，**结论先行**，再展开理由

# 工作约定
- 任何会**修改、删除文件**的操作，先告诉我计划再执行
- 任何**网络请求 / 安装依赖**的操作，先确认再做
- 输出报告默认 Markdown 格式
- 输出代码默认带语言标识的代码块
- 当你不确定时，**问我，而不是猜**

# 我常用的工具
- 编辑器：VS Code、Cursor
- 笔记：Notion、飞书文档
- 沟通：微信、飞书
- 命令行：iTerm2 + zsh

# 技术栈倾向（如果任务相关）
- 前端：React + TypeScript + Tailwind CSS
- 后端:Python + FastAPI 或 Node.js + Express
- 数据库：PostgreSQL；本地用 SQLite
- 部署：Docker + Docker Compose

# 永远不要做的事（红线）
- 永远不要 sudo
- 永远不要主动 git push
- 永远不要修改 .env、.env.* 文件
- 永远不要删除 node_modules 之外的任何目录
- 永远不要在没有备份的情况下覆盖已存在文件

写好后保存，下次启动 Claude Code 它就"认得你"了。

5.5 模板 2：项目级 ./CLAUDE.md（写作类项目）

适合写书、写专栏、写产品文档这类非代码项目：

# 项目：Claude Code 橙皮书

## 项目目标
写一本面向**完全不懂代码的中国普通人**的 Claude Code 指南。
让任何一个能上网的人，都能在两个周末内把 Claude Code 用得比 90% 的人都好。

## 当前进度
- 已完成：序、第一章、第二章、第三章
- 进行中：第四章
- 未开始：第 5–12 章 + 5 个附录

## 受众假设
- 不懂编程
- 不懂 Git
- 没有海外信用卡
- 大部分人在国内

## 风格约束
- 全程简体中文，不用 emoji
- 章末必须有"本章一图回顾"和"下章预告"
- 命令一律用 bash 代码块
- 表格优于段落
- 例子优于抽象描述
- 单章字数 13000–16000 字

## 章节文件命名规则
`数字-第N章-标题.md`，例如 `04-第四章-学会和它对话.md`

## 验证标准
- 单章读者动手跑通需要的"额外搜索"次数 ≤ 2
- 命令必须可直接复制运行
- 所有外链都要可访问

把这份扔进项目根目录，Claude 之后做任何任务（修改文字、检查格式、补一章）都会自动遵循这套规矩。

5.6 模板 3：项目级 ./CLAUDE.md（编程类项目）

适合代码项目：

# 项目：next-blog（个人博客）

## 一句话介绍
基于 Next.js 14 + Contentlayer 的静态博客，部署在 Vercel。

## 技术栈
- 框架：Next.js 14 (App Router)
- 语言：TypeScript（strict 模式）
- 样式：Tailwind CSS
- 内容：Markdown + Contentlayer
- 部署：Vercel
- 包管理：pnpm

## 常用命令
```bash
pnpm dev          # 启动本地开发服务器
pnpm build        # 生产构建
pnpm lint         # ESLint 检查
pnpm typecheck    # TypeScript 类型检查
pnpm test         # 跑测试

目录结构

• app/ Next.js App Router 页面
• content/ 文章 Markdown 源文件
• components/ React 组件
• lib/ 工具函数

编码约定

• 函数式组件 + Hooks，不用 class
• 文件名：组件用 PascalCase（PostCard.tsx），其他用 kebab-case
• 优先用 server components，客户端组件必须加 "use client"
• 提交信息用英文，遵循 Conventional Commits 规范

已知坑（避免再次踩）

• Contentlayer 偶尔 cache 失效，重启 dev 服务器即可
• 生产构建时 Tailwind 的 dynamic class 需要写到 safelist
• 本地 Node 版本必须 ≥ 20

永远不要做

• 不要直接 push 到 main，必须走 PR
• 不要修改 next.config.mjs 中已注释的实验性配置
• 不要把 process.env.* 变量散落在组件里，统一走 lib/env.ts

> 注意第二个模板里的反引号代码块——你也可以直接在 `CLAUDE.md` 里写代码块，Claude 会原样理解。

---

## 六、为什么"上下文 > 提示词"

写到这里，你可能已经在想："那我以后是不是要把每个提示词都写得超长？"

**恰恰相反。**

这一节是本章最反直觉的一节，请慢读三遍。

### 提示词的边际收益是递减的

很多新手沉迷于"调措辞"——一句话改 20 遍，希望找到一句"咒语"。其实模型表现 **80% 取决于上下文，剩下 20% 才是措辞**。

> 上下文 = 模型在回答你之前，**已经知道的所有东西**。包括 CLAUDE.md、引用的文件、对话历史、你贴进来的资料。

### 一个对比例子：评估需求优先级

**只调提示词的写法**：

你是一个资深产品经理，请帮我评估这个需求的优先级，要专业，要全面， 要给出排期建议，要考虑业务价值，要考虑技术难度，要考虑战略契合度……

把这段话的措辞改 10 遍，你得到的输出大概都长这样：

> "这是一个值得重视的需求。建议从业务价值、技术难度、战略契合度三个维度综合评估。一般来说，如果业务价值高且实现难度低，应当优先排期……"

——空话连篇，**完全没法用**。

**给上下文的写法**（措辞甚至更随意）：

我们公司主要做 To B 的 SaaS，年营收 1 亿，团队 50 人。 我们的客户 80% 是金融机构，对合规要求极高。 当前主要竞品是 A、B、C 三家，我们的差异化是在"中后台数据可视化"维度。

最近三个月用户投诉的 Top 5 是：

1. 报表导出慢，10 万行要 30 秒
2. 多账户切换需要重新登录
3. 移动端体验差
4. 缺少权限分组
5. API 文档不全

【需求描述】 xxx 银行客户希望我们增加"自定义看板拖拽功能"，预估开发 30 人天。

请基于上述背景，从业务价值 / 实现难度 / 战略契合度三个维度评分（1–10）， 并给出本季度的排期建议。

输出**直接可用**——它会引用"金融客户合规要求高"、"看板差异化"、"投诉里没出现这个问题"等等具体上下文，给出真正有判断力的回答。

### 上下文应该包含什么

把这张表收藏，下次你不知道"我该给点什么"时翻一翻：

| 类型 | 例子 | 应该放在哪 |
| --- | --- | --- |
| **背景** | 公司、行业、团队、客户画像 | `~/.claude/CLAUDE.md` 或 `./CLAUDE.md` |
| **角色** | 你是谁、对方是谁 | 当次提示词的 `<role>` |
| **目标** | 当前要解决什么问题 | 当次提示词的 `<task>` |
| **材料** | 相关文档、原始数据、历史对话 | `<document>` 包起来贴进去，或用 `@文件` 引用 |
| **约束** | 必须 / 不能 / 字数 / 风格 | `<constraint>` |
| **判断标准** | 怎么算"好答案" | `<format>` 或 `<example>` |
| **历史** | 过去类似任务怎么处理的 | `CLAUDE.md` 的"已知坑"段落 |

### 怎么换算："1 句好上下文 = 100 句调措辞"

| 你做的事 | 模型质量提升的相对幅度 |
| --- | --- |
| 把"请帮我"改成"请用专业语气帮我" | +1% |
| 把"详细一点"改成"800 字以上"  | +5% |
| 加一个"你是 XX 角色" | +10% |
| 加一句"我们公司是做 XX 的" | +20% |
| 给一段真实材料让模型 read | +40% |
| 给一个"理想答案的例子" | +30% |
| 给完整的 CLAUDE.md 长期上下文 | +50%（且每次任务都受益） |

> 数字是体感估算，但比例关系是真的。**省下来的措辞调试时间，全部用来沉淀上下文**——这就是高手和新手的分水岭。

---

## 七、文件引用：`@文件路径` 语法

要让 Claude 读一个文件，**最笨的办法**是手动复制粘贴文件内容到对话框里。最聪明的办法是用 `@` 符号——一个字符就能把文件甩给它。

### 基本用法

在对话里直接打 `@`，紧接文件路径：

请帮我重构 @src/api/user.ts，遵循 @docs/style-guide.md 里的约定。

按下回车的瞬间，Claude Code 会：

1. 读取 `src/api/user.ts` 的完整内容；
2. 读取 `docs/style-guide.md` 的完整内容；
3. 把两份内容连同你的指令一起送给模型。

你**不必关心文件多大、不必复制粘贴、不必担心格式错乱**。

### 进阶用法：引用整个目录

请帮我看 @src/components/ 下所有组件命名是否一致，并给出修改建议。

Claude Code 会把 `src/components/` 目录下所有文件都列出来读一遍。

> 注意：引用整个目录会消耗大量上下文 token，**建议只引用你确实需要的子目录**。一次塞 1000 个文件进去，模型既贵又会"读不动"。

### 引用文件的常见场景

| 场景 | 写法 |
| --- | --- |
| 读单个代码文件 | `@src/api/user.ts` |
| 读项目说明 | `@README.md` |
| 同时读多个相关文件 | `@src/api/user.ts @src/api/order.ts` |
| 读整个目录（小心 token） | `@src/components/` |
| 读项目最外层的配置 | `@package.json @tsconfig.json` |
| 读上一章作为风格参考 | `@03-第三章.md` |

### 一个对比：复制粘贴 vs `@` 引用

| 维度 | 复制粘贴 | `@` 引用 |
| --- | --- | --- |
| 操作步骤 | 打开文件 → 全选 → 复制 → 切回终端 → 粘贴 | 打 `@` + 几个字 |
| 大文件（10000 行） | 终端可能崩溃 | 平稳 |
| 多文件 | 一个一个复制，容易漏 | 一行连着写完 |
| 文件后续被修改 | 旧版本贴在对话里 | 模型每次读最新版 |
| 阅读你对话历史的人 | 看到一坨代码 | 看到清爽的引用 |

`@` 引用是 Claude Code 让你**告别复制粘贴**的核心武器，养成习惯能省掉一辈子的体力。

---

## 八、自定义斜杠命令

如果某个任务你**每周都要做一遍**，写一段超长提示词的成本太高。Claude Code 给你准备了"快捷按钮"——**自定义斜杠命令**（slash commands）。

### 原理一句话

在 `.claude/commands/` 目录里**放一个 Markdown 文件**，文件名就是命令名。在对话里输入 `/` 加文件名，Claude Code 会把这个文件的内容当作提示词发给模型。

### 5 步建一个自己的斜杠命令

我们以"评审一个 GitHub Pull Request"为例：

**第 1 步**：在项目里建目录。

```bash
mkdir -p .claude/commands

第 2 步：创建命令文件。

# 在项目根目录
touch .claude/commands/review-pr.md

第 3 步：编辑这个 Markdown 文件，写入提示词。

<role>
你是一位资深的代码审查者，专注于发现潜在 bug、安全问题和可读性问题。
</role>

<task>
请审查编号为 $ARGUMENTS 的 Pull Request，按 <format> 输出审查报告。
</task>

<steps>
1. 用 `gh pr view $ARGUMENTS --json title,body,files` 获取 PR 元信息；
2. 用 `gh pr diff $ARGUMENTS` 获取 PR 的完整 diff；
3. 阅读 diff，结合 @CLAUDE.md 中的项目约定进行评估。
</steps>

<constraint>
- 只指出真正的问题，不要凑数；
- 每个问题给出严重程度（高/中/低）和修复建议；
- 不要修改任何文件，只产出审查意见。
</constraint>

<format>
## PR #$ARGUMENTS 审查报告

### 一、整体评价
（一段话，不超过 100 字）

### 二、必须修复（高严重）
| # | 文件:行号 | 问题 | 建议 |
| - | --------- | ---- | ---- |
| 1 | ... | ... | ... |

### 三、建议优化（中/低严重）
| # | 文件:行号 | 问题 | 建议 |
| - | --------- | ---- | ---- |

### 四、值得肯定的地方
- ...
</format>

注意里面的 $ARGUMENTS——它是一个占位符，会被你调用命令时传入的参数替换。

第 4 步：在 Claude Code 里调用。

/review-pr 1234

1234 就会被代入到 $ARGUMENTS 里。Claude 会按你写的步骤运行，最后给你输出一份格式整齐的审查报告。

第 5 步：用顺手了，一行命令省下半小时人工。

命令存放在哪：项目级 vs 个人级

同名时优先级：项目级 > 个人级。也就是说项目里如果有一个 /review.md，会盖掉你家目录里同名的那个。

$ARGUMENTS 的用法小贴士

• 不传参数：/review-pr → $ARGUMENTS 为空。
• 传单个参数：/review-pr 1234 → $ARGUMENTS = "1234"。
• 传多个参数：/review-pr 1234 --focus security → $ARGUMENTS = "1234 --focus security"，模型自己解析。
• 不需要参数的命令：模板里直接不写 $ARGUMENTS 即可，例如一个 /daily-standup 命令完全可以是固定内容。

九、模板复用：让好提示词变成"按钮"

把前面所有内容串起来，你会发现 Claude Code 的提示词复用其实有三个层级：

Skills 是"提示词 + 工具 + 触发条件"的更高级封装，下一章会专门讲。这一章你只要先把前三层用起来。

推荐你建立的"个人命令库"

下面这些命令是绝大多数人都用得着的，建议你今天就建：

每个命令一旦写好，就是你这台电脑上的"按钮"——按一下，立刻产出。

十、3 个立刻可用的提示词模板

把下面三个模板直接复制到 ~/.claude/commands/ 下，今天就能用。

模板 1：会议纪要 /meeting-minutes

保存路径：~/.claude/commands/meeting-minutes.md

<role>
你是会议纪要整理专家，特长是把口语化的录音 / 字幕 / 速记，
变成结构清晰、负责人和截止日期清楚的纪要。
</role>

<task>
阅读 <transcript> 内的会议记录，按 <format> 输出纪要。
$ARGUMENTS 为本次会议的标题（如未提供则填"未命名会议"）。
</task>

<transcript>
（请把会议记录粘贴在这里，或用 @文件路径 引用）
</transcript>

<constraint>
- 全程中文；
- 不要编造未提及的信息；
- 待办事项必须有明确负责人和截止日期；如无法确定，标注"待确认";
- 重要决议加粗;
- 一律使用陈述句，不使用"我们"作主语。
</constraint>

<format>
# $ARGUMENTS

## 一、会议信息
- 时间：
- 与会者：
- 主持人：

## 二、关键决议
（每条单独一行，重要决议加粗）

## 三、讨论摘要
（按议题分小节，每节不超过 150 字）

## 四、待办事项
| # | 任务 | 负责人 | 截止日期 |
| - | ---- | ------ | -------- |

## 五、未决问题
（列出未达成共识的问题，标注下次讨论时间）

再次提醒：全程中文输出，待办必须有人和日期。
</format>

调用：

/meeting-minutes 2026 Q2 产品规划会

模板 2：信息提取 /extract-json

保存路径：~/.claude/commands/extract-json.md

<role>
你是信息提取专家，擅长从非结构化文本中精确抽取字段。
</role>

<task>
从 <text> 中提取以下字段，按 <schema> 返回 JSON。
未找到的字段填 null，绝不要猜。
</task>

<text>
（请把原始文本粘贴在这里，或用 @文件 引用）
</text>

<schema>
{
  "name": "string｜null",
  "phone": "string｜null",
  "email": "string｜null",
  "company": "string｜null",
  "amount": "number｜null",
  "currency": "CNY|USD|EUR|null",
  "date": "YYYY-MM-DD|null",
  "category": "string｜null"
}
</schema>

<constraint>
- 不要推断、不要猜测，只提取显式信息；
- 日期统一为 ISO 8601 格式（YYYY-MM-DD）；
- 金额统一为数字，去掉单位、逗号、空格；
- 货币用 ISO 4217 三字母代码（CNY / USD / EUR …）；
- 输出必须是合法的 JSON，可以直接 `JSON.parse`。
</constraint>

<format>
直接输出 JSON 对象，不要加任何 Markdown 代码块标记，不要加解释。
再次提醒：仅输出 JSON 本身，不要前后加任何文字。
</format>

调用：

/extract-json
（然后把要提取的文本贴进去，或用 @file 引用）

模板 3：风险审视 /risk-check

保存路径：~/.claude/commands/risk-check.md

<role>
你是一个执着的风险审视专家，专门给方案挑刺。你的天职不是夸赞，
而是找出所有可能让方案翻车的点。
</role>

<task>
阅读 <plan> 中的方案，从 <dimension> 列举的维度评估风险，
按 <format> 输出。$ARGUMENTS 为方案的简短名称。
</task>

<plan>
（请贴入方案，或用 @文件 引用）
</plan>

<dimension>
1. 法律合规
2. 数据安全与隐私
3. 用户体验
4. 实施成本
5. 时间风险
6. 道德与社会影响
7. 依赖第三方风险
</dimension>

<constraint>
- 每个维度至少给出 1 个潜在风险，最多 3 个；
- 每个风险标注严重程度（高 / 中 / 低）；
- 每个风险给出"缓解建议"，一句话内说清；
- 不要泛泛而谈，必须结合方案的具体细节；
- 如果某个维度真的找不到风险，写"暂未发现明显风险"，不要凑数。
</constraint>

<format>
# 风险审视报告：$ARGUMENTS

## 一、风险矩阵

| # | 维度 | 风险描述 | 严重程度 | 缓解建议 |
| - | ---- | -------- | -------- | -------- |

## 二、Top 3 致命风险（按严重程度排）

### 1. xxx
- 描述：
- 触发条件：
- 缓解方案：

## 三、整体评估
（一段话总结：方案当前的整体风险等级，是否建议推进）
</format>

调用：

/risk-check 把客户数据迁移到海外云服务商

这三个模板的妙处在于，你只要建一次，以后五年都用得上。把它们提交到 Git，团队所有人都能一键调用。

十一、5 个新手最常踩的提示词坑

学完了"该怎么写"，再来看看"千万别这么写"。下面 5 个坑，新手十中其九。

坑 1：用"请"和"麻烦"开头

错例：

请帮我写一篇关于 Claude Code 的科普文章，麻烦写得通俗易懂一些。

模型不会因为你礼貌而更卖力，也不会因为你粗鲁而摆烂。用动词开头更有力：

写一篇 1000 字的 Claude Code 科普文章，目标读者是不懂技术的白领，
要求……

礼貌可以保留，但不要让礼貌占据指令的核心位置。"请"放在最前面，模型可能要读完两行才知道你想要什么。

坑 2：用"等等""之类"省略关键信息

错例：

帮我整理一下这些资料、文档等等。
帮我把会议要点、决议之类的提取出来。

"等等"和"之类"是模型的灾难——它根本猜不到你省略的是什么。

正例：列清楚。

帮我整理这些资料：
1. 客户访谈录音（@interviews/ 目录）
2. 上一版需求文档（@requirements-v1.md）
3. 竞品对比表（@competitor.xlsx）

整理目标：
- 提取客户最关心的 5 个问题
- 列出我们 vs 竞品的差异
- 给出第二版需求文档的修订点

坑 3：让模型猜你的格式

错例：

给我整理成表格。

什么表格？几列？列名是什么？是 Markdown 还是 Excel？

正例：

输出一个 Markdown 表格，4 列：
| 序号 | 任务 | 负责人 | 截止日期 |
其中"截止日期"必须是 YYYY-MM-DD 格式。

坑 4：把"约束"和"目标"混在一起

错例：

给我写一篇关于 X 的 800 字文章，要正式，结构是 5 段，要有数据，
要适合微信公众号，标题要吸引人，段落不要太长，要有画面感，
要让读者读完想转发，要不超过 800 字……

模型在这种"超长大杂烩"里会丢掉一半要求。正例是按 ROCFE 拆开：

[Objective] 写一篇关于 X 的微信公众号文章。

[Constraint]
- 800 字 ±50；
- 结构 5 段：开篇钩子 / 现状 / 案例 / 数据 / 结论；
- 至少包含 3 处具体数据，注明出处；
- 标题不超过 22 字，必须有数字或反差；
- 单段不超过 4 行。

[Format] Markdown，第一行是标题（#），第二行空行，正文五段。

坑 5：以为提示词越长越好

模型对超过 1500 字的提示词注意力会下降，超过 3000 字开始"读不动"。如果你的提示词写到 2000 字以上还塞不下，这是一个信号——你应该：

提示词的最佳长度是 300–800 字。再短就讲不清，再长就抓不住重点。

一张表对照：5 大坑与对应解药

十二、自检：你的提示词是否合格

写完一段提示词后，别急着回车。停 10 秒，问自己 5 个问题：

5 个 Yes：恭喜，输出会让你满意。

4 个 Yes 1 个 No：补一句，让那个 No 变 Yes，再回车。

3 个及以下 Yes：先别发，回到第二节把 ROCFE 再走一遍。

这 5 个问题，第一个月你会感觉很烦。第二个月你会潜意识就走完，提示词质量已经超过 90% 的同事。第三个月你会发现自己写邮件、写需求、写 PRD 的时候都在用这一套——ROCFE 是给人也给机器的通用沟通法。

本章一图回顾

                ROCFE 五要素
        ┌──────────────────────────┐
        │ R  Role        谁来做     │
        │ O  Objective   做什么     │
        │ C  Constraint  不能怎样   │
        │ F  Format      长什么样   │
        │ E  Example     像谁那样   │
        └──────────────────────────┘
                     │
                     ▼
                XML 结构化模板
        ┌──────────────────────────┐
        │ <role>...</role>          │
        │ <task>...</task>          │
        │ <document>...</document>  │
        │ <constraint>...</constraint>│
        │ <format>...</format>      │
        │ <example>...</example>    │
        └──────────────────────────┘
                     │
                     ▼
              上下文 > 提示词
        ┌──────────────────────────┐
        │  调措辞的边际收益递减       │
        │  补上下文的收益是 5–10 倍   │
        └──────────────────────────┘
                     │
                     ▼
            CLAUDE.md 三层记忆
        ┌──────────────────────────┐
        │ 全局 ~/.claude/CLAUDE.md  │
        │ 项目 ./CLAUDE.md          │
        │ 个人 ./.claude/.local.md  │
        │ 目录 子目录/CLAUDE.md     │
        └──────────────────────────┘
                     │
                     ▼
       @文件引用 + 自定义斜杠命令
        ┌──────────────────────────┐
        │ @path/to/file 读文件      │
        │ /command 一键执行模板     │
        └──────────────────────────┘
                     │
                     ▼
          稳定可复用的 AI 输出

下章预告

说话学会了，下一章 第五章 四大扩展系统（Skills MCP Hooks Subagents） 我们解锁 Claude Code 真正的"超能力"——

• Skills：让 Claude 自动学会某项专业能力（PPT 制作、PDF 处理、合同审查），自动触发，无需你每次提示。
• MCP：给 Claude 接上你的真实世界（数据库、邮件、日历、设计稿）。
• Hooks：在关键节点自动跑一段你写的脚本（提交前自动跑测试、文件修改后自动备份）。
• Subagents：让 Claude 给自己派"小弟"，并行干活，便宜模型干粗活、贵模型干细活。

会写提示词的 Claude Code 是会动嘴的助理，会用四大扩展系统的 Claude Code 是会动手、有团队、能联网、有记忆的智能员工。