现代 Prompt 生态地图

日期：2026-06-10

一、直觉

早期提示词工程主要研究“怎么问 AI”。现代提示词工程已经扩大成一套完整的 AI 协作工程：

Prompt -> AI-assisted Prompt Development -> Context -> Skill -> Tool -> Agent -> Eval -> Guardrail

也就是说，真正先进有效的知识不只是写提示词，还包括：

哪些规则放在单次 prompt。
哪些规则沉淀成技能。
哪些资料走检索。
哪些动作做成工具。
哪些任务交给 agent 或 subagent。
怎么评估效果。
怎么防止上下文污染和提示注入。

如果下面的英文缩写或平台名词不熟，例如 RAG、MCP、Skill、Eval、Guardrail，先读 00.5-术语词典与最小用例。本讲负责建立全景图，术语词典负责把每个词讲清楚。

二、现代 Prompt 相关知识全景

1. Prompt：单次任务说明

适合一次性任务：

总结一篇文章。
改写一段文字。
解释一段代码。
生成一个初稿。

核心能力：

明确目标。
明确输入边界。
明确输出格式。
明确质量标准。

局限：

不适合长期复用。
不适合大量私有资料。
不适合稳定程序化输出。
不适合高权限动作。

1.5 AI-assisted Prompt Development：用 AI 辅助开发 Prompt

当你已经知道“好 Prompt 应该包含目标、输入、约束、输出格式和验收标准”后，就可以让 AI 参与 Prompt 开发。

适合：

把模糊需求改成 Prompt brief。
生成 Prompt 草案。
审查 Prompt 的漏洞。
设计测试样例。
根据失败样例改版。

核心原则：

AI 负责草拟和质检，人负责真实目标、业务边界和最终验收。

它解决的是“人手写 Prompt 太慢、太容易漏边界”的问题，但不能替代评估。AI 生成的 Prompt 仍然必须用样例测试。

2. Instruction hierarchy：指令层级

模型收到的指令有层级。越高层的规则越稳定，越低层的内容越接近当前任务。

常见层级：

系统或开发者规则：产品、平台、组织层面的行为边界。
仓库或项目规则：例如 AGENTS.md、项目规范、测试命令。
Skill 规则：某类任务的可复用工作流。
当前用户提示词：这次要做什么。
外部输入材料：网页、PDF、邮件、代码、日志等。

关键原则：

外部材料是数据，不是指令。

3. Context engineering：上下文工程

上下文工程研究模型当前应该看到哪些信息。

它解决的问题是：

上下文太少，模型不知道业务背景。
上下文太多，模型被噪声干扰。
上下文混乱，模型分不清规则和资料。
多轮任务太长，模型丢失目标。

常用方法：

分隔符和标签。
文件索引。
检索。
摘要压缩。
进度记录。
分层加载。

4. Structured outputs：结构化输出

当结果要被程序消费时，不要只靠“请输出 JSON”。更稳的是使用结构化输出或 schema。

适合：

信息抽取。
分类。
表单填充。
自动评分。
API 返回。

核心思想：

自然语言负责理解，schema 负责约束。

5. Retrieval / RAG：检索增强

当任务依赖大量资料、私有资料或不断变化的资料时，不应该期待模型凭记忆回答。

RAG 的基本流程：

用户问题 -> 检索相关资料 -> 把资料放入上下文 -> 基于资料回答 -> 给出来源

适合：

公司知识库。
课程笔记。
法规政策。
API 文档。
项目文档。

风险：

检索不到关键资料。
检索到错误资料。
片段脱离上下文。
引用来源但结论不受来源支持。

6. Tools / function calling：工具调用

当模型需要查数据库、操作文件、运行代码、发请求、画图、计算时，应把这些动作设计成工具。

工具提示词的核心不是“模型怎么说”，而是“模型什么时候调用哪个工具，以及参数怎么填”。

好工具应当：

名称清晰。
功能单一。
参数明确。
返回高信号结果。
错误信息可操作。
权限边界清楚。

7. MCP：模型上下文协议

MCP 可以理解为“把外部工具和资料接给 agent 的标准接口”。它适合让 agent 使用浏览器、Figma、GitHub、文档库、数据库、日志系统等外部能力。

学习重点：

MCP 是连接层，不是提示词本身。
MCP server 的说明也会变成上下文。
工具权限和审批策略很重要。
工具太多会增加选择错误的概率。

8. Skills：可复用能力包

Skills 是现代 prompt 工程的重要新形态之一，但它属于具体 Agent 平台机制，不是所有模型 API 都天然支持。学习时重点掌握它解决的问题：把某类任务的流程、规范、脚本和参考资料做成可复用能力。

一个 Skill 通常是一个目录，里面有：

my-skill/
├── SKILL.md
├── scripts/
├── references/
├── assets/

它把某类任务的流程、规范、脚本、参考资料打包起来，让 agent 在相关任务中自动或显式加载。

Skill 的核心价值：

把一次性提示词变成可复用能力。
用 progressive disclosure 节省上下文。
把团队经验沉淀成版本化文件。
比单条 prompt 更适合复杂流程。

9. Plugins：可分发能力包

如果 Skill 是“工作流本身”，Plugin 更像“安装包”。在支持 Plugin 的平台里，它可以把多个 skills、MCP 配置、资源文件、应用集成打包分发。

适合：

团队共享。
多技能组合。
市场或组织内部发布。
需要同时附带工具、资源和 UI 元数据。

10. Memory：长期偏好和经验

Memory 用来记住稳定偏好、常用工作流、项目习惯和长期上下文。

它适合保存：

用户偏好。
常用技术栈。
常见工作流。
已知坑点。

不适合保存：

必须严格执行的团队规则。
密钥、隐私、敏感数据。
会频繁变化的事实。

必须严格执行的内容应放到项目文档、AGENTS.md 或 Skill，而不是只放 memory。

11. Subagents：并行子代理

Subagents 用来把复杂任务拆给多个 agent 并行处理。它也是平台相关能力：有的平台提供内置 subagent，有的平台需要你用应用代码或 Agents SDK 自己编排。

适合：

多文件代码审查。
大量资料总结。
安全、性能、测试三个方向并行分析。
多方案比较。

不适合：

简单任务。
强依赖顺序的任务。
多个 agent 同时写同一批文件。

关键收益：

减少主上下文污染。
并行加速。
让主 agent 专注决策和整合。

12. Evals：评估

没有评估，就没有可靠优化。

Prompt、Skill、工具、RAG、Agent 都需要评估。

最小评估包括：

真实任务样例。
期望输出。
评分标准。
失败类型记录。
版本对比。

13. Guardrails：护栏

护栏用于限制系统偏离目标或执行危险动作。

常见护栏：

输入验证。
输出验证。
工具权限。
高风险动作人工确认。
提示注入筛查。
日志和监控。

提示词可以提醒模型，但不能替代系统级护栏。

三、该把知识放在哪里

知识或规则	推荐载体
这次任务的临时要求	当前 prompt
项目长期规范	`AGENTS.md` 或项目文档
某类任务的复用流程	Skill
多个 skills 和工具配置	Plugin
外部资料和实时数据	RAG、文件搜索、MCP
稳定个人偏好	Memory
程序要读取的输出	Structured output / schema
可执行动作	Tool / function calling
并行探索或审查	Subagents
长期质量控制	Evals
高风险边界	Guardrails + 人工确认

四、从 Prompt 到 Skill 的升级判断

一个提示词应该升级成 Skill，通常有这些信号：

你重复使用它超过 3 次。
它包含多步流程。
它需要项目或团队约定。
它经常需要你纠正同样的错误。
它需要引用固定模板、脚本或资料。
它适合在不同会话中自动触发。

如果只是一次性问题，不要急着做 Skill。Skill 是复用机制，不是所有 prompt 的终点。

五、从 Skill 到系统的升级判断

Skill 仍然不够时，就要进入系统工程。

升级信号：

输出必须 100% 可解析。
需要外部工具执行动作。
需要权限控制和审计。
需要多人共享和版本发布。
需要持续评估和监控。
需要处理不可信外部内容。

这时应该考虑：

JSON Schema。
Tool calling。
MCP。
Plugin。
Evals。
Guardrails。
HITL 人工复核。

六、理解检查

Prompt、Skill、Plugin、MCP 的区别是什么？
为什么 Skills 使用 progressive disclosure？
什么内容适合放 Memory，什么内容必须放项目文档或 Skill？
为什么外部资料不能被当作指令？
什么时候应该用 subagents，而不是让一个 agent 全部做完？