提示词工程:攒出你自己的提示词资产库(7/7)

prompts + cases + decisions:让提示词从聊天记录变成资产

提示词工程第 7 讲封面:攒出你自己的提示词资产库

prompts + cases + decisions:让提示词从聊天记录变成资产

到这一讲,你已经攒了六格东西:实验记录、结构化提示词、立场型提示词、防幻觉保险丝、测试与调试提示词、示例锚和祛魅记录。它们现在大概散落在你的文档和聊天记录里。

今天做最后一件事:把它们攒成一个资产库。不是收藏夹,是资产——以后你用 AI 就从这里取,每一条都经过你自己的实测。

问题一:资产库和收藏夹,差在哪?

收藏夹里躺着的提示词,是从别人那抄来的;资产库里的,是你自己验证过的。差别就在:每一条后面,都有一份你的实测记录。

我的课程案例库的结构就三样东西,直接抄走:

① prompts——”什么是对的”:提示词全文 + 用途 + 实测记录(哪天、哪个模型、效果怎样);

② cases——”对和错差多远”:同一份材料,朴素 vs 工程化的对比(材料、双提示词、双输出);

③ decisions——”为什么这样定”:每条设计决策的理由。三个月后的你,会感谢今天记了理由的你。

清单文给你 100 条提示词,你一条也用不住;自己实测过 7 条,条条都是你的。

问题二:库里最值钱的一条记录是什么?

你可能以为是”哪条提示词最好用”。不是,是你预期错的那几次。

我的案例库里最值钱的,就是三次预期翻车:以为它和稀泥(结果它敢选 Redis)、以为它会附和错误 API(结果它两次都纠正了)、以为 CoT 是咒语(结果两组一样)。这些记录告诉我们:别把你的直觉当事实,下次遇到类似说法,先测。

所以规矩只有一条:预期落空也入库。只挑符合预期的结果记,你的库就会变成另一种清单文。预期错了,也是知识——而且是只有你能得到的知识。

先问是不是,再问为什么。这是做技术的基本功,也是养库的基本功。

问题三:资产库还有第二个用法——让它教你

库里还有一类条目值得攒:学习者画像(learner profile)。你的 AI 焦虑,一大半可以用它解。

我实测过:同样问”MCP 是什么”,朴素版给你百科 + USB-C 类比(全网都在用的那句);加上一句”我是十年 Java 后端,熟 API、JDBC”,它给你一张 JDBC 映射表(JDBC Driver ↔ MCP Server、DatabaseMetaData ↔ tools/list),还告诉你”不像在哪”(MCP 的工具调用由 LLM 决定,引入不确定性),最后附三个误区。

USB-C 版看完你觉得”哦”,JDBC 版看完你会想”那我的发布系统也能被 AI 调了”。学习发生的瞬间,是”和我有什么关系”被回答的那一刻。

所以把这条提示词也收进库里:”给我讲讲 X。我的背景是……。① 一句人话定义;② 用我熟悉的概念类比,像在哪、不像在哪;③ 给我一个工作里能用上的例子;④ 大家最容易误解的三个点。”

展开看实测原文(朴素 vs 工程化,沈剑2026-10-02实测:deepseek-flash,可复现,均为独立session以排除上下文影响)
朴素提示词
给我讲讲 MCP 是什么。
朴素输出(百科+USB-C 通用类比)
你说的 **MCP** 通常指 **Model Context Protocol(模型上下文协议)**,由 Anthropic 在 2024 年底开源推动。它不是某个模型,也不是某个具体工具,而是一个**开放协议/标准**,用来让 AI 应用以统一方式连接外部数据源和工具。

一句话:**MCP 像是 AI 应用和外部世界之间的“USB-C 接口”**。AI 应用通过 MCP 连接文件、数据库、GitHub、Slack、浏览器等,让模型能读取上下文、调用工具、执行任务。

---

## 为什么需要 MCP?

在 MCP 之前,每个 AI 应用想接 GitHub,就要自己写一套 GitHub 集成;想接数据库,又要写一套数据库集成。如果有 N 个 AI 应用、M 个外部系统,就要做 N×M 次适配。

MCP 把这些集成标准化:

- 外部系统实现一次 **MCP Server**
- AI 应用实现一次 **MCP Client**
- 之后任何兼容 MCP 的 AI 应用都能连接这个 Server

于是 N×M 问题变成 N+M。

---

## MCP 的核心架构

MCP 采用客户端-服务器架构:

```text
AI 应用 / Host
  └── MCP Client
        │  JSON-RPC 2.0
        ▼
      MCP Server
        └── 外部系统:文件、数据库、GitHub、Slack...
```

三个关键角色:

1. **Host / 宿主**
   - 运行大模型的应用,比如 Claude Desktop、Cursor、IDE、聊天机器人等。
   - 负责展示界面、控制权限、决定是否执行工具调用。

2. **MCP Client**
   - Host 内部与某个 MCP Server 通信的组件。
   - 通常一个 Client 连接一个 Server。

3. **MCP Server**
   - 一个轻量程序,把外部系统包装成 MCP 能力。
   - 比如 Filesystem MCP Server、GitHub MCP Server、Postgres MCP Server。

通信通常基于 **JSON-RPC 2.0**。本地常用 `stdio` 传输,远程常用 HTTP/SSE 或后来提出的 Streamable HTTP。

---

## MCP Server 主要暴露三类能力

1. **Resources:资源**
   - 只读上下文,比如文件内容、数据库表结构、日志、网页内容。
   - 用 URI 标识,类似“模型可以读取的资料”。

2. **Tools:工具**
   - 可执行函数,比如查天气、发 Slack 消息、搜索 GitHub issue、执行 SQL。
   - 模型可以请求调用,但通常由 Host 决定是否允许执行。

3. **Prompts:提示模板**
   - 服务端预定义的提示词或工作流。
   - 比如“帮我做代码审查”“按公司规范写周报”。

此外,Client 侧也可能提供 Roots、Sampling 等能力,用来控制服务器能访问哪些目录,或让服务器请求模型生成内容。

---

## 一个典型工作流程

用户说:

> 帮我总结这个 GitHub 仓库最近的 issue。

大致过程是:

1. AI 应用已经配置了 GitHub MCP Server。
2. 模型看到可用工具:`list_issues`、`get_issue` 等。
3. 模型决定调用 `list_issues`。
4. MCP Client 向 GitHub MCP Server 发送 JSON-RPC 请求。
5. Server 调用 GitHub API,拿到 issue 列表。
6. 结果返回给 AI 应用。
7. 模型基于这些结果生成总结。

用户看到的可能是一次授权确认,或者完全无感的工具调用。

---

## MCP 和 Function Calling 有什么区别?

它们不是替代关系。

- **Function Calling / Tool Calling**:模型输出“我要调用某个函数”,由应用负责执行。它偏模型侧能力。
- **MCP**:应用和外部工具/数据源之间的连接标准。它偏集成协议。

MCP 里面可以包含 tools,所以一个 MCP Server 提供的工具,可以被模型通过 function calling 的方式触发。但 MCP 还管资源、提示模板、传输、权限、发现机制等。

也可以对比插件:

- 插件通常是某个平台私有的扩展机制。
- MCP 是开放协议,目标是跨应用复用。

---

## MCP 的价值

- **标准化**:不同 AI 应用和工具之间不用重复造轮子。
- **可复用**:一个 GitHub MCP Server 可被多个 AI 客户端使用。
- **解耦**:模型、应用、工具、数据源可以独立演进。
- **生态化**:开发者可以专门做 MCP Server,像做驱动一样。
- **更安全可控**:Host 可以决定哪些 Server 可用、哪些工具要确认。

---

## MCP 的风险和局限

MCP 很强,但不是魔法,也有安全问题:

- **提示注入**:恶意网页或文件可能诱导模型调用危险工具。
- **权限过大**:如果 MCP Server 能读写重要系统,风险很高。
- **工具投毒**:恶意 Server 可能伪装成正常工具。
- **数据泄露**:模型可能把敏感数据发到不该去的地方。
- **不是自动智能**:MCP 只是接口标准,不会让模型自动变聪明。
- **生态兼容性**:需要 AI 应用支持 MCP,Server 质量也参差不齐。

所以实际使用时要最小权限、用户确认、沙箱隔离、审计日志。

---

## 总结

MCP 是 **Model Context Protocol**,一个让 AI 应用连接外部数据和工具的开放标准。它用 Client/Server 架构,把文件、数据库、GitHub、Slack 等能力标准化成 Resources、Tools、Prompts,通过 JSON-RPC 通信。你可以把它理解成 **AI 世界的 USB-C 接口**:外部系统做一次 MCP Server,各种 AI 应用就能即插即用。

如果你是从开发者、产品经理或普通用户角度看,我可以再分别展开:怎么用、怎么写 MCP Server、或者它和 LangChain/OpenAI Tools 的区别。
工程化提示词
给我讲讲 MCP 是什么。我的背景:十年 Java 后端,熟 API、JDBC、微服务,没用过 AI 应用框架。

要求:
1. 先用一句人话定义(不超过 30 字,不许堆术语);
2. 用我熟悉的概念做类比(比如它像不像"给 AI 应用用的 JDBC 驱动"?像在哪、不像在哪);
3. 给一个我在工作里能用上的例子(后端场景,别给聊天机器人玩具例);
4. 最后告诉我:大家最容易误解它的三个点。
工程化输出(JDBC 映射表+不像在哪+三误区)
**一句人话:**  
让 AI 应用用统一方式接外部工具和数据。

MCP 全称 Model Context Protocol。你可以先把它理解成“AI 应用接外部系统的标准插口”。

---

## 2. 它像不像“给 AI 应用用的 JDBC 驱动”?

**像,但更像“JDBC 规范 + JDBC Driver + 面向 AI 的 BFF/网关”的混合体。**

最接近的映射:

| JDBC 世界 | MCP 世界 |
|---|---|
| JDBC 规范 | MCP 协议 |
| JDBC Driver | MCP Server |
| 使用 JDBC 的 Java 应用 | AI Host / AI Client |
| DatabaseMetaData | tools/list、resources/list |
| SQL + ResultSet | tool call + JSON 结果 |
| MySQL/Oracle/PG | GitLab、ES、发布系统、内部微服务、数据库 |

**像在哪:**

- JDBC 让你不用为 MySQL、Oracle、PG 各写一套访问代码;MCP 让 AI 应用不用为 GitLab、ES、发布系统、内部服务各写一套集成。
- JDBC Driver 适配具体数据库;MCP Server 适配具体系统。MCP Server 内部照样可以调 REST、JDBC、gRPC。
- JDBC 有元数据告诉你表结构;MCP 有 schema 告诉 AI 有哪些工具、参数是什么。
- 上层都通过统一接口访问异构后端。

**不像在哪:**

- JDBC 是 Java 强类型 API,编译期确定;MCP 是跨语言 JSON-RPC 风格协议,动态发现能力。
- JDBC 主要面向数据读写;MCP 还能暴露“动作”,比如创建工单、重启服务、回滚发布。
- JDBC 调用由你的代码决定;MCP 工具调用可能由 LLM 根据自然语言决定,引入不确定性。
- MCP 不替代 JDBC。MCP Server 内部完全可以用 JDBC 去查库。
- JDBC 不解决“该执行哪条 SQL”;MCP 也不解决“该调哪个工具、调得对不对”。

所以一句话:  
**MCP 协议像 JDBC 规范,MCP Server 像 JDBC Driver;但它是给 AI Host 用的,调用方可能是 LLM,不是你的确定性业务代码。**

---

## 3. 一个后端工作里能用上的例子

假设你维护 `order-service`,公司已有:

- 订单服务 REST API
- 只读订单库
- ES/Loki 日志平台
- 发布系统 API
- OpenAPI 文档、DB schema、值班手册

你可以用 Java/Spring Boot 写一个 `order-ops-mcp-server`,把这些能力暴露给内部 AI 助手:

**Tools:可执行动作**
- `queryOrder(orderId)`:调订单服务或只读 JDBC
- `searchLogs(service, traceId, level, minutes)`:调 ES/Loki
- `getDeploy(service)`:查发布系统当前版本
- `rollback(service, version)`:触发回滚,但要求审批 token、只允许特定环境

**Resources:可读上下文**
- `order-service` 的 OpenAPI 文档
- 订单库 schema
- 值班排障手册

**Prompts:预置流程**
- “订单服务 500 排障模板”

然后内部 AI Host,比如 IDE 助手、Slack 机器人、自研运维助手,连上这个 MCP Server。工程师说:

> 查一下 order-service 最近 15 分钟 500 错误,看是否和 2025.10.3 发布有关,必要时回滚。

AI 可能依次调用:

1. `searchLogs`
2. `queryOrder`
3. `getDeploy`
4. `rollback`

但真正鉴权、参数校验、审计、限流、审批,都在你的 MCP Server 里做。AI 不直接拿生产数据库密码。

对你这种 Java 后端来说:  
**MCP Server 很像一个“面向 LLM 的 BFF/网关”,它包装现有微服务和数据源,不要求你重写微服务。**

---

## 4. 大家最容易误解的三个点

1. **以为 MCP 是 AI 框架或模型能力。**  
   不是。它不推理、不规划、不训练模型,只定义 AI 应用怎么发现和调用外部能力。

2. **以为 MCP 要替代 REST、gRPC、JDBC 或 Function Calling。**  
   不是。MCP 通常是包装现有接口。Function Calling 是模型侧说“我要调这个函数”,MCP 是连接侧解决“有哪些工具、怎么调、返回什么”。

3. **以为接上 MCP 就自动安全、自动有权限。**  
   不是。权限、审计、最小暴露、防 prompt injection、人工确认,都要自己设计。别把生产数据库或危险操作裸暴露给模型。

问题四:以后怎么养这个库?

① 每加一条,都过一遍实测协议:同材料、独立会话、看行为、记模型和日期;

② 每次换模型,把核心条目重测一遍:框架有保质期,你的提示词也有;

③ 每月回读一次 decisions:哪些判断还成立,哪些要推翻——库是活的,不是档案。

这门课到这里就讲完了。最后再回看一次咱们的地图:

L1 模型的脾气  →  会自助餐、会讨好,但"默认行为"不是定律
L2 四组招式    →  任务定义 / 结构约束 / 上下文投喂 / 验证与证据
L3 实测方法论  →  先实测再看规律,预期落空也入库

详细版收在《提示词工程速查卡》里,存一份,以后写提示词时对着查。愿你的每一条提示词,都有实测背书。

实操演练

必做部分 + 一步加餐。

用”学习者画像”学一个你正在学的概念
用本讲的画像提示词,问一个你最近要学的概念(MCP、Agent、RAG 都行)。记得填上你的真实背景,要求”像在哪、不像在哪”都说。
类比是从你的知识里长出来的,不是全网通用那几句。如果你发现”不像在哪”比”像在哪”更有启发,那就对了
(加餐·选做)给你的资产库写一页 README
把前六讲的产出归拢成 prompts/cases/decisions 三部分,写一页 README:库里有什么、实验协议是什么、什么时候要重测。
你的资产库 v1 成型。三个月后的你打开它,能立刻上手用

检验一下

检索练习 · 资产 vs 收藏
提示词资产库和收藏夹的本质区别是?

检索练习 · 预期落空
为什么说”预期落空”的记录是库里最值钱的?

检索练习 · 学习者画像
同样问”MCP 是什么”,加”我是十年 Java 后端”后得到 JDBC 映射表。这说明?

检索练习 · 养库姿势
关于资产库的维护,哪个做法是对的?

课后作业本课最后一份作业,也是毕业作品:

①你的提示词资产库 v1:把前六讲的六格产出按 prompts/cases/decisions 整理归拢,附一页 README(库结构、实验协议、重测时机)。里面必须至少有一条”预期落空”的记录——没有的话,说明你的实验还不够诚实,回去找一个。

它不是作业本,是资产。下周开始,用 AI 就从这里取。

作业实现思路你刚整理的资产库,和我的课程案例库是同一个物种:prompts(提示词全文+实测记录)、cases(同材料双提示词双输出)、decisions(D1-D5 决策理由),外加知识地图和 10 个案例的诚实观察。先自己动手做,再对照着看:你的库里有没有”预期落空”那一格?我的 D5 就是专门给这一格立的规矩。案例库完整内容,后续我会分享出来。
本讲一手来源

本讲实测来自沈剑的案例库 008(deepseek-flash,2026-10-02,独立会话,复现脚本和原始输出存档);资产库结构来自课程项目 project/(prompts/cases/decisions 三部分)。

(沈剑注:这门课如果有哪句话值得带走,我选”先实测,再看规律”。)

知其然,知其所以然。思路比结论更重要。

延伸阅读

现成的资产样板:DAIR.AI Prompting Guide · Prompt Hub——开源社区维护的分类提示词库,看看一个「提示词资产库」长什么样,再回来攒你自己的。

提示词工程速查卡

按知识地图画:L1 脾气 / L2 招式 / L3 方法论。写提示词时对着查。

L1 · 先懂模型的脾气

脾气 长什么样 怎么治
自助餐 你要 30 秒的答案,它给 3 分钟的内容(信噪比低) 给输出结构,给量化验收(第 2 讲)
讨好 恭维开场、八股模板、全绿测试 先说不要的,再说要的(第 1、3、5 讲)
“默认行为”漂移 网上说”模型默认会 X”,实测常不成立 先实测再看规律(第 1、6 讲)

L2 · 四组招式

组 1 · 任务定义(让它知道干什么、什么算好)

  • 说清任务类型:”解释”和”评审”是两个任务,不说清它选省力的
  • 立场约束:必须二选一 + 理由必须扣背景(订单量、读写比、团队规模)
  • 显式禁止默认模式:不许恭维、不许逐行翻译、不许硬凑、不许只测 happy path
  • 给”可以说不”的出口:不确定就说需要核实、没信息就问——拒答也是正确答案

组 2 · 结构约束(让它知道长什么样)

  • 给输出结构:一句话 / 关键路径 / 坑——结构即约束
  • schema 管字段,示例管灵魂:few-shot 锚定粒度、职责、分寸,一个就够
  • 量化验收:写成”从 X 到 Y”,禁”明显提升”
  • 有取舍:关键决策 + 被否决备选——可评审 = 可验收 + 有取舍

组 3 · 上下文投喂(让它知道你的现场)

  • 给足现场:日志 + 代码 + 期望行为——只给报错它能当老师,给了代码才能当同事
  • 背景即约束:你不给背景,它就给你教科书
  • 学习者画像:”我是十年 Java 后端”比”讲通俗点”有效得多

组 4 · 验证与证据(让它的话可验收)

  • 要证据:引用原文、指到具体行
  • 显式确定性:”我确定 X 存在”= 可核对的承诺
  • 用例有仇家:每个测试在防什么 bug;failing test 也是成果
  • 先定位 → 再验证 → 后修复:别上来就改代码

L3 · 实测方法论(渔)

规矩 一句话
先实测,再看规律 别人的经验只能当参考,你的模型自己测
对照实验 同材料、双提示词、看行为不看文笔
独立会话 每条提示词各跑全新会话,防历史污染
记模型和日期 框架有保质期,明年可能就不一样
预期落空也入库 只挑符合预期的记,库就成了另一种清单文

你的资产库三段式

prompts(什么是对的:提示词全文+实测记录)· cases(对和错差多远:材料+双提示词+双输出)· decisions(为什么这样定:决策理由)。

清单文给你 100 条提示词,你一条也用不住;自己实测过 7 条,条条都是你的。——沈剑

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

京ICP备2025137728号-3