学会和它对话 · OpenClaw 橙皮书

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

写法 A：

帮我写一封邮件。

写法 B：

请以我的名义给客户 ACME 公司的 John 写一封邮件，告诉他：
1. 上周我们演示的 V2 版本，性能比 V1 提升了 35%；
2. 计划本周五下午 3 点（北京时间）做线上演示，请他确认是否方便；
3. 附件会一并发送 V2 的产品说明。

要求：
- 用商务正式的英语，不要口语化；
- 全文不超过 150 词；
- 开头不要 "I hope this email finds you well" 这种套话，直奔主题；
- 结尾签名：Cassius from XYZ Corp。

写法 A 的输出每次都不同，而且大概率不能直接用。写法 B 的输出每次都很接近，几乎可以直接发出去。

两者唯一的差别就是你说了多少。 这一章要做的，就是教你"该说哪些"。

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

把"该说什么"拆成五个字母，简单好记：

缩写	中文	你要回答的问题
Role	角色	你希望 AI 扮演谁？（资深律师 / 旅行规划师 / 你的私人助理）
Objective	目标	你想达到什么结果？要清晰可衡量
Constraint	约束	不能做什么、必须怎么做？字数、风格、格式、口吻
Format	输出格式	你想要 Markdown 表格？JSON？分段落？bullet 列表？
Example	示例	（可选但强大）给 1-2 个"好答案"的样子

五要素套用前面的例子

[Role] 你是 Cassius 在 XYZ 公司的私人邮件助理，文风专业、克制。

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

[Constraint]
- 提到 V2 比 V1 性能提升 35%；
- 全文 < 150 词；
- 不要 "I hope this email finds you well" 这类套话；
- 商务正式语气，不要口语化；
- 落款署名 "Cassius from XYZ Corp."。

[Format] 输出纯邮件正文，不要前缀、不要解释，直接复制即可发送。

[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? ..."

把这段话粘贴进 OpenClaw，几乎不会让你失望。

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

当你的指令越来越复杂，AI 容易"听漏一点"。Anthropic 的工程师在长期实战中发现，用 XML 标签包裹各部分，模型出错率会显著下降。

模板长这样：

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

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

<document>
（这里贴你要分析的内容，可以很长）
</document>

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

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

<example>
（可选，给一个理想样本）
</example>

这套模板对 Claude / GPT / DeepSeek / Kimi / Gemini 都生效，对 Claude 效果最好。

写 XML 的三个铁律

标签内容尽量短：每个 <…> 内部别塞太多东西，超过 200 字就再拆。
顺序不重要，但建议把最关键的放最后：模型对最后看到的内容印象最深。
关键约束写两遍：例如"输出必须是中文"放在 <constraint> 里之外，再在 <format> 末尾重复一遍。

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

这是本章最反直觉的一节。

很多新手沉迷于"调提示词"——同一句话改了 20 遍措辞，希望找到一句"咒语"。其实模型的表现 80% 取决于它有没有足够的上下文，剩下 20% 才是措辞。

例子

提示词写得再漂亮：

你是一个资深的产品经理，请帮我评估这个需求的优先级。

也不如直接告诉模型：

我们公司主要做 To B 的 SaaS，年营收 1 亿，团队 50 人。
我们的客户 80% 是金融机构，对合规要求极高。
当前主要竞品是 A、B、C，我们的差异化是在 D 维度。
最近三个月用户投诉的 Top 5 是：1. xxx；2. xxx ……

【需求描述】
xxx 客户希望我们增加 xxx 功能，预估开发 30 人天。

请基于上述背景，从"业务价值 / 实现难度 / 战略契合度"三个维度评分，并给出排期建议。

后者的输出直接可用，前者只能给你一篇空话。

上下文应该包含什么

把这张表打印出来贴在你显示器旁边：

类型	例子	怎么给
背景	你的公司、行业、团队、定位	写进 `openclaw memory`
角色	你是谁、对方是谁	写进任务的 `<role>`
目标	当前要解决什么问题	写进 `<task>`
材料	相关文档、原始数据、历史对话	用 `<document>` 包起来贴进去
约束	必须 / 不能 / 字数 / 风格	写进 `<constraint>`
判断标准	怎么算"好答案"	写进 `<format>` 或 `<example>`

在 OpenClaw 里维护"长期上下文"

OpenClaw 提供了三层上下文，按生命周期划分：

┌──────────────────────────────────────┐
│ 全局记忆 (memory)：永久有效            │
│  ──────────────────────────────────  │
│  你的公司、偏好、家庭、风格           │
│  全部任务都自动注入                   │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│ 项目记忆 (project)：当前项目内有效     │
│  ──────────────────────────────────  │
│  当前项目的目标、进度、已知信息       │
│  本项目的任务自动注入                 │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│ 会话上下文 (session)：单次对话内有效   │
│  ──────────────────────────────────  │
│  当前任务的具体材料                   │
│  对话结束就丢                          │
└──────────────────────────────────────┘

全局记忆操作

# 添加
openclaw memory add

# 查看
openclaw memory list

# 删除
openclaw memory remove <id>

# 编辑
openclaw memory edit

项目记忆

在你工作的项目目录里，新建一个 .openclaw/CONTEXT.md 文件。OpenClaw 在该目录下启动时会自动读它。

# 当前项目：橙皮书写作

## 项目目标
- 写一本面向普通人的 OpenClaw 入门到进阶书

## 进度
- 已完成：序、第 1-3 章
- 进行中：第四章
- 未开始：第 5-12 章 + 附录

## 风格约束
- 不用 emoji
- 章末有"本章一图回顾"
- 命令一律用 bash 代码块

之后你在这个目录跑任何任务，OpenClaw 都会记得这些。

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

写了一个好提示词，下次不用再写——把它存为模板。

第 1 步：在 `~/.openclaw/prompts/` 下创建模板

mkdir -p ~/.openclaw/prompts
nano ~/.openclaw/prompts/email-en-business.md

写入：

---
name: 商务英文邮件
description: 用商务英文给某人写邮件
variables:
  - name: recipient
    description: 收件人姓名
  - name: company
    description: 收件人公司
  - name: purpose
    description: 邮件目的
  - name: word_limit
    description: 字数上限
    default: 150
---

<role>
You are an English business email assistant for Cassius from XYZ Corp.
Your tone is professional, concise, and warm but not casual.
</role>

<task>
Write an email to {{recipient}} from {{company}}.
Purpose: {{purpose}}
</task>

<constraint>
- Total length: under {{word_limit}} words.
- No openings like "I hope this email finds you well".
- Sign off as "Cassius from XYZ Corp.".
- Output the email body only, no explanation.
</constraint>

第 2 步：调用模板

openclaw prompt run email-en-business \
  --recipient "John" \
  --company "ACME" \
  --purpose "Invite him to a 30-min V2 demo on Friday 3PM Beijing time. Mention V2 has 35% better performance than V1." \
  --word_limit 150

或者在 tui 界面里直接：

/prompt email-en-business

它会一步步问你变量。

复用的好处

稳定：同一类任务输出风格一致；
快：以后写邮件只需填空，不需要重写；
可分享：把 ~/.openclaw/prompts 文件夹丢给同事，他立刻拥有你的"咒语库"；
可版本化：用 Git 管理你的 prompts/ 目录，每一次优化都有记录。

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

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

请帮我写一篇关于 OpenClaw 的科普文章。

模型不会因为你礼貌而更卖力。用动词开头更有力：

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

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

帮我整理一下这些资料、文档等等。

"等等"是模型的灾难，它根本猜不到。列清楚。

坑 3：让模型猜你的格式

给我整理成表格。

什么表格？几列？列名是什么？

输出一个 Markdown 表格，4 列：序号 | 任务 | 负责人 | 截止日期。

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

错例：

给我写一篇关于 X 的 800 字文章，要正式，结构是 5 段，要有数据，要适合微信公众号，标题要吸引人……

模型会丢掉一半。分开写：

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

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

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

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

模型对超过 1500 字的提示词注意力会下降。如果你写到 2000 字以上还塞不下，改用模板 + 上下文文件。比如把背景丢到 memory 或 CONTEXT.md，提示词只留任务描述。

七、立即可复用的 3 个模板

把以下三段直接保存到 ~/.openclaw/prompts/，今天就能用。

模板 1：会议纪要

<role>你是会议纪要整理专家，特长是把口语化的录音/字幕变成结构清晰的纪要。</role>

<task>
阅读 <transcript> 内的会议记录，按 <format> 输出纪要。
</task>

<transcript>
{{transcript}}
</transcript>

<constraint>
- 全程中文；
- 不要编造未提及的信息；
- 待办事项必须有明确负责人和截止日期；如无，标注"待确认"；
- 重要决议加粗。
</constraint>

<format>
# {{meeting_title}}

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

## 二、关键决议
（每条单独一行）

## 三、讨论摘要（按议题分小节）

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

## 五、未决问题
</format>

模板 2：信息提取

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

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

<text>
{{raw_text}}
</text>

<constraint>
- 不要推断、不要猜测，只提取显式信息；
- 日期统一为 ISO 8601 格式 (YYYY-MM-DD)；
- 金额统一为数字（去掉单位和逗号）。
</constraint>

<format>
{
  "name": "...",
  "amount": 123.45,
  "currency": "CNY",
  "date": "2026-04-19",
  "category": "..."
}
</format>

模板 3：风险审视

<role>你是一个执着的风险审视专家，专门给方案挑刺。</role>

<task>
阅读 <plan> 中的方案，从 <dimension> 列举的维度评估风险，按 <format> 输出。
</task>

<plan>{{plan}}</plan>

<dimension>
1. 法律合规
2. 数据安全
3. 用户体验
4. 实施成本
5. 时间风险
6. 道德风险
</dimension>

<constraint>
- 每个维度至少给出 1 个潜在风险，最多 3 个；
- 每个风险给出"严重程度（高/中/低）"和"缓解建议（一句话）"；
- 不要泛泛而谈，结合方案细节。
</constraint>

<format>
| 维度 | 风险 | 严重程度 | 缓解建议 |
| --- | --- | --- | --- |
</format>

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

每写完一段提示词，问自己 5 个问题：

我是否说清楚了 AI 该扮演什么角色？
我是否说清楚了"成功"长什么样？
我是否给出了所有必要的背景信息？
我是否说清楚了输出的格式？
我是否避开了"等等"、"之类"、"自由发挥"这种模糊词？

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

本章一图回顾

       ROCFE 五要素
┌──────────────────────────┐
│ R  Role        谁来做     │
│ O  Objective   做什么     │
│ C  Constraint  不能怎样   │
│ F  Format      长什么样   │
│ E  Example     像谁那样   │
└──────────────────────────┘
            ↓
       XML 结构化
            ↓
       上下文 > 提示词
            ↓
        模板复用化
            ↓
   稳定可工业化的 AI 输出

下章预告

提示词写得再好，OpenClaw 也只是"会动嘴"。要让它真的"会动手"，得给它装上Skills——也就是各种能力插件。下一章第五章 Skills 扩展能力我们带你逛 Claw Hub 市场，挑出 10 个普通人最值得装的 Skill，并教你识别"安全可靠的"和"危险的"。