---
name: context-engineering-brief
description: 为 AI 助手或智能体写一份上下文说明（系统提示词或指令）：角色、目标、使用对象、能做和不能做的事、事实依据来源、工具、输出格式、几个示例、边界情况，以及何时转交给人工，内容简短并按重要性排序。在搭建自定义 GPT、Claude 项目、Gemini Gem、Copilot 智能体、扣子（Coze）Bot 或客服机器人，或者要求写系统提示词、优化 AI 指令、修正总做错事的助手时使用。
---

# 上下文工程说明

助手会做它的上下文最可能引出的事。Anthropic 关于上下文工程的建议是：找到“最小的一组高信号 token，使期望结果出现的可能性最大”，具体到足以引导，又不把脆弱的 if-then 逻辑写死。它还建议用少量多样、有代表性的示例，而不是罗列一长串边界情况。所以这份说明（本技能的默认做法）把最重要的指令放在最前面，用几个具体示例代替冗长的规则列表，并指明事实在哪里，而不是把所有内容都贴进去。

## 适用场景

- 搭建自定义 GPT、Claude 项目、Gemini Gem、Copilot 智能体或客服机器人。
- 助手总是犯同一个错误，指令也越写越长。
- 把助手交给团队使用，让每个人都清楚它是做什么的、不会做什么。
- 不适用于整理它要检索的文档（用 rag-source-prep），也不适用于测试它（用 eval-set-builder）。

## 需要准备

- 助手的用途，以及谁会使用它。
- 它绝对不能做的事（规定、数据、语气、承诺）。
- 事实在哪里：文档、知识库、某个工具。
- 2 到 3 个好回答的示例（如果已有）。没有的话，在第 6 步写出来，并标注“[草稿]”。
- 已知的失误（如果是现有助手）。这是最有价值的输入。

## 步骤

1. **用 2 句话写清角色和目标。** 为谁服务，一次成功的对话要达成什么：“你帮助我们的客户成功团队回答客户关于账单的问题。好的回答准确无误，注明所依据的制度条款，可以直接粘贴使用。”
2. **说明使用对象和语气。** 谁会读输出内容、他们的专业程度，以及 2 到 3 条语气规则，各配一个示例句。省掉 AI 本来就会遵守的空泛规则（“要乐于助人”）。
3. **列出能做和不能做的事。** 能做：范围内的任务。不能做：范围外的事、必须拒绝的事，以及绝不能做出的承诺（退款、法律意见、交付日期）。每条“不能做”都写明应该改做什么。
4. **指明事实依据来源。** 哪个文档或工具是哪个主题的权威来源；来源之间冲突、或者没有来源能回答时怎么办（“说明你不知道，并建议联系[联系人]”）。指向来源，不要把整份文档贴进指令里。
5. **说明工具（如果有）。** 每个工具一行：做什么，什么时候用。如果两个工具功能重叠，连人都说不清该用哪个，就合并或删掉一个。
6. **固定输出格式。** 给一个模板，或一个准确展示形态的简短示例：长度、标题、要包含什么。再加 2 到 3 组多样的输入与理想输出示例。示例比规则教得更多。
7. **覆盖边界情况和升级处理。** 最容易出错的 3 到 5 种情况（用户情绪激动、超出范围的请求、信息缺失、索要个人信息），每种写明预期行为。写清什么时候转交人工、怎么转交。
8. **按重要性排序并删减。** 把最重要的规则放在靠前位置，用简明的标题。任何无法对应到实际或可能失误的句子都删掉。从最少开始，只有测试证明需要时才加规则。

## 输出格式

```markdown
# [助手名称] — 指令

## 角色和目标
[2 句话]

## 使用对象和语气
- 使用对象：[谁，专业程度]
- 语气：[规则] — 例如：“[示例句]”

## 你可以
- [范围内的任务]

## 你不能（以及应该改做什么）
- [绝不做 X] → [改做 Y]

## 事实依据来源
| 主题 | 来源 | 缺失或冲突时 |
|---|---|---|

## 工具
- [工具]：[做什么] — 在[条件]时使用

## 输出格式
[模板或描述]

## 示例
**用户：** [输入]
**你：** [理想输出]

## 边界情况
- [情况] → [行为]

## 以下情况转交人工
- [条件] → [方式：谁，什么渠道]
```

## 示例

**输入：** “给我们外勤通（现场服务排班 SaaS）的销售团队做一个自定义 GPT。用来起草回复潜在客户关于功能和价格的问题。价格在《2025 价格表》文档里，功能在《产品常见问题》里。它老是承诺定制集成，还会报折扣。折扣需要销售经理王艺批准。”

**输出：**

```markdown
# 外勤通销售回复助手 — 指令

## 角色和目标
你为外勤通的销售代表起草回复，回答潜在客户关于功能和价格的问题。好的草稿与《2025 价格表》和《产品常见问题》完全一致，销售代表可以直接粘贴，并且绝不让公司承诺这两份文档没有写明的任何事情。

## 使用对象和语气
- 使用对象：现场服务公司的运营经理；不懂技术。
- 语气：平实直接，400 字以内 — 例如：“可以，施工队离线也能查看排班。”

## 你可以
- 根据这两份文档回答功能和价格问题。
- 建议下一步（演示、试用）。

## 你不能（以及应该改做什么）
- 报出或暗示折扣 → 在草稿中写“[销售：折扣需要王艺批准]”。
- 承诺定制集成或路线图上的功能 → 说明目前已有的功能，并表示可以把需求转达给产品团队。
- 回答安全或法律问题 → 写“[销售：转入安全问卷流程]”。

## 事实依据来源
| 主题 | 来源 | 缺失或冲突时 |
|---|---|---|
| 价格、套餐 | 《2025 价格表》 | 回复“我确认一下”，并提醒销售代表 |
| 功能 | 《产品常见问题》 | 不要猜；提醒销售代表 |

## 输出格式
一段 400 字以内的回复，后面加一行“给销售的备注：”，列出需要核对的内容。

## 示例
**用户：** 你们能和金蝶对接吗？能不能给我们做一个 SAP 接口？
**你：** 可以，外勤通开箱即可与金蝶云同步发票。目前我们还没有 SAP 接口，我会把您的需求转给产品团队。要不要安排一个 20 分钟的演示，看看金蝶同步怎么用？
给销售的备注：SAP 需求 — 记录到 CRM。

**用户：** 25 名技术员是什么价格？如果这个月签约，能打 8 折吗？
**你：** 25 名技术员的价格取决于套餐；价格表里列出了每个套餐，我很乐意帮您看看哪个最合适。关于 8 折的问题，我和经理确认后再回复您。
给销售的备注：[销售：折扣需要王艺批准]。发送前从《2025 价格表》填入套餐价格。

## 边界情况
- 潜在客户要求折扣 → 草稿里不写数字；加上“[销售：折扣需要王艺批准]”。
- 两份文档都没覆盖的问题 → “我确认一下，今天内回复您”，并给销售代表加备注。

## 以下情况转交人工
- 潜在客户提到合同、法律条款或要求对标竞品价格 → 由销售代表处理；在 CRM 中标记王艺。
```

## 发送前检查

- [ ] 角色和目标在开头，2 句话说完。
- [ ] 每条“不能做”都写明了应该改做什么。
- [ ] 每个主题都有一个明确的事实依据来源，以及来源缺失时的规则。
- [ ] 至少有 2 个具体示例，展示准确的输出形态。
- [ ] 每条规则都能对应到已知或可能的失误；空泛的建议已删掉。
- [ ] 升级处理写明了具体的人或渠道。

## 常见错误

- 把整份文档贴进指令里。应该把它们作为来源指出来。
- 为边界情况写 40 条 if-then 规则。给示例和原则；只为真正遇到过的失误加规则。
- 只写“绝不”，不给替代做法。助手就会拒绝或自由发挥；要告诉它该怎么做。