ARTICLE / ai
Prompt Engineering 技术栈:从基础到 CoT/ToT 的完整体系
Prompt Engineering 在 LLM 应用中的地位
在 LLM 应用工程的技术栈中,Prompt Engineering 是投入产出比最高的核心技能。与微调(Fine-tuning)、RAG、Agent 框架开发等工程手段相比,它不需要额外的训练数据、GPU 算力或复杂的基础设施——仅仅通过优化输入文本的结构与语义,就能显著改变模型的行为质量。
从工程视角看,Prompt Engineering 处于 LLM 应用金字塔的基座层:
无论上层架构如何演进——从单轮对话到多步 Agent,从简单 QA 到复杂 RAG pipeline——每一次与模型的交互最终都会收敛到一个 Prompt 上。因此,Prompt 质量直接决定了整条链路的输出上限。这也是为什么 OpenAI、Anthropic 等头部实验室在模型发布时,首要的配套文档不是 API Reference,而是 Prompt Engineering Guide。
对于有经验的开发者而言,将 Prompt Engineering 视为一种「结构化编程」而非「自然语言技巧」会更为准确:它有输入输出规范、有可复现的模式、有版本管理和 A/B 测试方法论——本质上是一个完整的工程学科。
Prompt 设计基础框架:五要素模型
成熟的 Prompt 设计不是即兴创作,而是遵循结构化框架。五要素模型(Role / Task / Constraints / Format / Examples)是目前工程实践中最广泛使用的 Prompt 架构:
五要素定义
| 要素 | 作用 | 对输出的影响 |
|---|---|---|
| Role(角色) | 设定模型的行为模式和专业背景 | 决定回答的视角深度、用词风格和知识边界 |
| Task(任务) | 明确要完成的具体目标 | 直接决定输出的主体内容和方向 |
| Constraints(约束) | 限定输出的范围、规则和限制 | 控制输出的质量下限,防止退化 |
| Format(格式) | 指定输出的结构化形式 | 影响信息的组织效率和下游可解析性 |
| Examples(示例) | 提供期望行为的参考样本 | 最直接地锚定输出分布,减少歧义 |
各要素的工程影响
Role:行为模式锚定
Role 的核心机制是通过系统提示改变模型的注意力分配——当角色被明确定义后,模型会在 token 生成时倾向于选择该角色常用的专业词汇和推理路径。
Task:目标的精确度直接决定输出质量
Constraints:质量下限的护栏
Constraints 是工程化 Prompt 中最容易被忽视但最关键的要素。它们定义了输出的「不应」边界:
Format:下游可解析性
在 Agent 系统中,Format 不仅影响可读性,还直接决定下游管道能否正确解析模型输出:
Examples:Few-shot 的核心
Examples 是五要素中对输出分布影响最强的要素。在后续的 Few-shot 章节会深入展开。
五要素协同效应
这五个要素不是独立工作的,它们之间存在协同与权衡:
- Role + Task 共同决定输出的深度与方向
- Constraints 设定输出的质量下限
- Format 控制输出的可解析性
- Examples 直接锚定输出的分布中心
在实际工程中,五要素的权重分配应根据场景动态调整——创意生成任务中 Examples 权重更高,合规性任务中 Constraints 权重更高,技术文档生成中 Format 权重更高。
Zero-shot vs Few-shot vs One-shot:策略选择矩阵
三种策略的本质区别
| 策略 | Prompt 结构 | Token 消耗 | 适用场景 | 典型延迟影响 |
|---|---|---|---|---|
| Zero-shot | Role + Task + Constraints | 最低 | 简单分类、格式转换、常见 QA | 最低 |
| One-shot | 上述 + 1 个示例 | 中等 | 需要轻微格式校准的任务 | 中等 |
| Few-shot | 上述 + 多个示例 | 较高 | 复杂格式、领域特定输出、低容错任务 | 较高 |
工程选型指南
Few-shot 的工程细节(比选策略本身更重要):
- 示例顺序影响结果——模型对末尾示例的注意更强(recency bias),把最难/最典型的样例放最后
- 示例分布即输出分布:三分类任务里 2:1:1 的示例比例会让模型偏向多数类,标签平衡要刻意做
- 格式一致性:示例的缩进、标点、字段顺序必须逐字对齐期望输出——模型模仿格式的能力远强于理解格式描述的能力
- 长上下文时 Few-shot 进缓存:把示例固定为前缀可吃 Prompt Cache 折扣,few-shot 的边际 Token 成本递减
Chain-of-Thought 与结构化推理
CoT 的触发方式
关键工程事实:CoT 对模型是"输出成本"——推理链占输出 Token,延迟与费用同步上升。2024 年后的推理模型(o1、R1、Qwen3 thinking)本质是把 CoT 从 prompt 技巧变成训练内化的能力,此时再手写 “step by step” 反而可能干扰其原生推理格式。
ToT(Tree of Thoughts):把 Prompt 变成搜索
ToT 将推理组织为树:每步生成多个"想法"分支,用模型自评(或外部验证器)打分,保留高分分支做 BFS/DFS 展开。
成本清醒剂:ToT 的 API 调用量是朴素 CoT 的 10-100 倍。只用于"有明确对错 + 搜索空间大"的问题(谜题、规划、多约束设计);日常任务用 self-consistency(采样 5 次投票)性价比更高。
高级技术速查
| 技术 | 一句话机制 | 适用 |
|---|---|---|
| ReAct | 思考→行动→观察交替循环 | Agent/工具调用 |
| Least-to-Most | 先分解子问题,按序求解 | 组合推理 |
| Step-Back | 先抽象一般原理再解题 | 科学/数学问答 |
| Generated Knowledge | 先生成背景知识再作答 | 事实密集任务 |
| Role Prompting | 专家角色锚定知识域 | 专业问答、风格控制 |
| JSON/Function Schema | 解码期语法约束 | 结构化输出(生产标配) |
Prompt 的版本管理与评估
Prompt 即代码,没有工程化管理的 Prompt 迟早劣化:
落地三步:建 50-200 条带标注的黄金集 → 每次改动全量跑回归(分数、延迟、Token 成本三指标)→ 灰度 5% 流量 A/B 验证线上质量。Prompt 优化的收益上限往往藏在评估里——多数团队的 Prompt 不是写不好,而是改不动(怕改坏、没有度量)。
总结
Prompt Engineering 技术栈的重心已从"话术技巧"转向结构化规范:五要素给骨架,few-shot 锚定分布,CoT/ToT 分配推理算力,schema 保证下游可解析,版本管理与评估让一切可迭代。记住工程三角:质量、成本、可控性——每个 prompt 决策至少影响其一;好的 prompt 不是最长最华丽的那版,而是被评估证明有效的那一版。
(注:文中技术要点整理自 CoT/ToT/SelfCheckGPT 等公开论文与 OpenAI/Anthropic 官方 prompt 指南,代码为示意片段,接口行为随模型版本变化。)
本文面向授权安全研究与防御建设,未经授权对任何系统实施文中技术属违法行为。