应用生态篇已经走过 4 篇：

• 第 26 篇 RAG 实战

• 第 27 篇 Function Calling / Tool Use

• 第 28 篇 Agent 框架

• 第 29 篇 多模态部署

这一篇是应用生态篇的收官——也是整个系列里最被低估的一篇。

为什么这么说？因为很多人把 Prompt 工程当成"玄学"——觉得就是"换几个词试试"，谈不上"工程"。但事实是：

同样的模型，好的 prompt 比差的 prompt 准确率能差 30-50%。
同样的业务，prompt 设计差异能让月成本差 10×。
同样的应用，prompt 工程做得好的团队迭代速度是别人 3 倍。

如果你做过相关工作，下面这些问题应该不陌生：

• 同样的提示词，今天答得好，明天就崩了——怎么治？

• Prompt 调到上线效果好，但版本一升级就跟着退化——怎么管理？

• 团队 20 个 prompt 文件散落各处，没人知道哪个在用——怎么治理？

• 怎么量化"这个 prompt 比那个好"？

读完本文你将能：

1. 理解 prompt 演变的逻辑（从 zero-shot 到 ReAct 到 thinking）

2. 掌握 5 大基础原则和 6 大进阶技巧

3. 把 prompt 工程化（版本管理 + 测试 + 监控）

4. 知道什么时候该升级到微调

我们开始。

一、Prompt 工程的演变

1.1 五个发展阶段

2020 GPT-3 ── zero-shot / few-shot 2022 InstructGPT ── instruction prompting 2022 末 CoT ── Chain of Thought 思维链 2023 ReAct ── 推理 + 行动 2024 thinking ── 模型内化推理（o1/R1/Claude 4 Thinking） 2025-2026 ── prompt 工程化 + 自动化优化

每一代都解决了上一代的瓶颈。

1.2 2026 年 prompt 工程的新认知

随着推理模型（Claude 4.7 / GPT-5 / o3 / DeepSeek R1）的普及，prompt 工程出现了根本性转变：

但也别太乐观：

• 业务流程类 prompt 仍然复杂

• Tool Use / Agent 仍需精心设计

• 中文等非英文场景仍需更细致

二、5 大基础原则

2.1 原则 1：明确角色 + 任务

❌ 差：「帮我写代码」 ✅ 好：「你是资深 Python 工程师。 请实现一个 LRU 缓存类，要求： 1. 容量为构造参数 2. get/put 都是 O(1) 3. 加上类型注解和 docstring」

核心：

• 给清晰角色（背景 / 经验 / 风格）

• 给具体任务（要做什么 / 输入 / 输出）

• 给约束（限制 / 优先级 / 格式）

2.2 原则 2：结构化输入

文档 / 数据要用明确的分隔标记：

<context> {rag_results} </context> <user_question> {question} </user_question> 请基于 context 回答 user_question，如 context 不足请说明。

Anthropic 推荐用XML 标签（Claude 训练数据偏好），OpenAI 推荐 Markdown 分隔。

2.3 原则 3：明确输出格式

❌ 差：「分析这段代码」 ✅ 好：「分析这段代码，按以下结构输出： ## 优点 - ... ## 问题 - ... ## 改进建议 - ... 每段不超过 3 点。」

强制 JSON 输出：

prompt = """请以 JSON 输出： { "sentiment": "positive | neutral | negative", "score": 0.0 to 1.0, "reasons": ["...", "..."] } 只输出 JSON，不要任何其他文字。 """

更稳的做法：用 vLLM / SGLang 的structured output 模式（第 17 篇讲过）。

2.4 原则 4：少做 negation

LLM 对"不要做什么"理解不如"要做什么"。

❌ 差：「不要用专业术语」 ✅ 好：「用初中生能理解的语言」 ❌ 差：「不要回答与主题无关的问题」 ✅ 好：「只回答关于产品 X 的问题，其他主题礼貌拒绝」

2.5 原则 5：例子 > 描述

少量好例子胜过千言万语描述：

描述："把数字转中文大写" 例子（更好）： 123 → 壹佰贰拾叁 4567 → 肆仟伍佰陆拾柒 8900 → 捌仟玖佰 现在：12345 → ?

Few-shot 学习是 LLM 的天赋——好好用。

三、6 大进阶技巧

3.1 Chain of Thought（CoT）

让模型**"逐步思考"再答**：

问题：一个商店原价 X 元，先打 8 折再加 10% 销售税，最终价格是多少？ CoT prompt： 请逐步思考再回答： 1. 先算 8 折后的价格 2. 再算加税后的价格 3. 给出最终答案

对推理模型已经不需要——它们天生会思考。但对小模型（< 30B）和复杂问题仍然有效。

3.2 Self-Consistency（自洽性）

让模型生成 N 次，投票选最一致的答案：

def self_consistency(prompt, n=5): answers = [llm(prompt, temperature=0.7) for _ in range(n)] # 投票 from collections import Counter extract = [extract_answer(a) for a in answers] return Counter(extract).most_common(1)[0][0]

适合：数学、推理、有标准答案的题。成本翻 N 倍但精度显著提升。

3.3 Tree of Thoughts（ToT）

CoT 是线性的——错一步全错。ToT 让模型探索多条路径：

1. 生成 K 个"下一步思路" 2. 评估每个思路的优劣 3. 选最优的几个继续展开 4. 像走树搜索一样推进

适合：博弈、规划、有多种合理路径的题。
代价：调用次数指数级。

3.4 ReAct（推理 + 行动）

第 27 篇详细讲过：

Thought：我需要先查 X Action：tool_call(...) Observation：结果 Thought：现在我...

是 Agent 的基础。

3.5 Reflection（自反思）

让模型自我批评 + 改进：

def reflect_and_improve(question, max_round=3): answer = llm(f"回答：{question}") for _ in range(max_round): critique = llm(f""" 问题：{question} 当前答案：{answer} 请指出答案的问题，如果没有问题就说"OK" """) if "OK" in critique: return answer answer = llm(f""" 问题：{question} 之前答案：{answer} 批评：{critique} 请改进答案 """) return answer

适合：高质量场景（文章、代码、报告）。
代价：调用次数 2-5 倍。

3.6 Prompt Chaining（提示链）

复杂任务拆成多步 prompt：

# Step 1：理解问题 parsed = llm(f"把用户问题拆成结构化数据：{question}") # Step 2：决策 plan = llm(f"基于：{parsed}，规划解决方案") # Step 3：执行 result = llm(f"基于计划：{plan}，给出答案")

优势：

• 每步更可控

• 出错容易定位

• 单 step 更便宜（用小模型）

这就是 Agent 的雏形——只不过没有 tool。

四、生产级 Prompt 工程化

业余 prompt 工程：在 ChatGPT 调一调，写到代码里。
工业级：版本管理 + 评估 + 监控 + A/B testing。

4.1 Prompt as Code

把 prompt 当作代码管理：

prompts/ ├── customer_service/ │ ├── v1.0.yaml │ ├── v1.1.yaml # 新版 │ └── current -> v1.1 # 软链接 ├── ticket_classify/ │ └── ... └── README.md

YAML 元数据：

# prompts/customer_service/v1.1.yaml name:customer_service version:1.1 model:qwen3-32b temperature:0.3 max_tokens:800 system:| 你是一名专业客服... user_template:| 用户问题：{question} 历史对话：{history} 请给出回答。 created_at:2026-05-15 author: alice

4.2 Prompt 评估体系

评估数据集

# eval_datasets/customer_service.yaml -input: question:"怎么退款？" history: [] expected: contains: ["退款", "申请"] not_contains: ["不知道", "无法处理"] max_length:500 -input: question:"你叫什么名字？" history: [] expected: contains: ["客服"] sentiment: "friendly"

自动化评估

def eval_prompt(prompt_version, dataset): scores = [] for case in dataset: output = llm(prompt_version.render(case["input"])) score = check_against_expected(output, case["expected"]) scores.append(score) return sum(scores) / len(scores)

LLM as Judge

def llm_judge(question, answer, criteria): return llm(f""" 用户问题：{question} 回答：{answer} 评估标准：{criteria} 给 1-5 分并说明： """)

主流框架：

• promptfoo：开源 prompt 测试框架

• LangSmith/Langfuse：完整 LLM 应用追踪与测试

• OpenAI Evals：标准化评测框架

4.3 A/B 测试

# 在 LLM Gateway 层（如 LiteLLM）做 A/B def route_prompt(user_id): bucket = hash(user_id) % 100 if bucket < 10: return PROMPT_V2 # 10% 流量到新版 return PROMPT_V1 # 监控两个版本的指标： # - 用户满意度（点赞 / 点踩） # - 回复质量（LLM Judge） # - 业务指标（解决率、转化率）

4.4 Prompt 监控

生产 Prompt 要监控这些指标：

主流工具：

• LangSmith（LangChain 官方）

• Langfuse（开源 alternative）

• Phoenix（Arize AI 开源）

• Helicone（轻量级）

4.5 Prompt 优化的工具化

DSPy

斯坦福开源的"自动化 prompt 优化"框架：

import dspy class QA(dspy.Module): def __init__(self): self.cot = dspy.ChainOfThought("question -> answer") def forward(self, question): return self.cot(question=question) # 自动优化 prompt（基于训练数据） optimizer = dspy.BootstrapFewShot(metric=my_metric) optimized_qa = optimizer.compile(QA(), trainset=examples)

DSPy 会自动学到最优的 few-shot 例子，超过人工调参。

PromptHub / Prompt Lab

各种 prompt 协作平台：

• 团队共享 / Review

• 版本对比

• 一键 deploy

五、Prompt vs 微调：什么时候升级

回顾第 7 篇我们提过的优先级：

Prompt → RAG → SFT → 对齐微调

用 Prompt 解决的场景：

• 通用任务（写作、翻译、总结）

• 输出格式要求一般

• 调用量不大

• 业务还在变

升级到 SFT 的信号：

• Prompt 调到极限，效果仍然不够

• 输出格式严格（JSON / 特定结构）

• 大量调用，prompt 长度成本高

• 业务稳定，值得"固化"

5.1 决策矩阵

5.2 真实经验：Prompt 长度的成本

业务跑量大时，长 prompt = 大账单。

prompt 长度 1000 token vs 5000 token 1 万次调用 = 多花 4000 万 token = ~$80（按 GPT-4 算） 1 千万次 = $80,000 差异

优化：

• Prompt 精简

• Prompt caching（OpenAI / Anthropic 都支持，50-90% 折扣）

• 小流量场景：长 prompt OK；大流量：必须精简

六、各家模型的「Prompt 哲学」

6.1 OpenAI / GPT 系

• Markdown 友好

• 喜欢清晰的结构标题

• system prompt 重要

• few-shot 用\n---\n分隔

6.2 Anthropic / Claude 系

• XML 标签最友好

• 长 prompt 表现优秀

• 喜欢"让 Claude 思考"的明确指令

• thinking 模式：让 Claude 用<thinking>内部思考

<role>你是法律分析师</role> <context>{document}</context> <task>提取所有合同风险点</task> <output_format> JSON 数组，每个元素是 {risk: "...", severity: "high/medium/low"} </output_format>

6.3 Google / Gemini 系

• 偏好结构化 prompt

• 长上下文最强

• 喜欢"Step by step" 标记

6.4 国产模型

• Qwen：中文优化好，prompt 风格类似 GPT

• DeepSeek R1：推理模型，反而要简洁（不要画蛇添足 CoT）

• GLM：中文 + 结构化

6.5 一个 prompt 多模型兼容

PROMPT_TEMPLATES = { "openai": "你是助手。\n\n# 任务\n{task}\n\n# 上下文\n{context}", "anthropic": "<task>{task}</task>\n<context>{context}</context>", "qwen": "## 任务\n{task}\n\n## 上下文\n{context}", } def render_prompt(model_family, task, context): return PROMPT_TEMPLATES[model_family].format(task=task, context=context)

七、Prompt 工程的反模式

7.1 6 大反模式

反模式 1：超长系统提示词

症状：system prompt 3000 字，包含所有规则、例子、边角情况。

问题：

• 每次调用都贵

• 模型对中间内容"近视"（lost-in-the-middle）

对策：

• 核心规则 < 500 字

• 例子放到 few-shot

• 业务知识用 RAG

反模式 2：模糊的好坏判断

症状："这个 prompt 感觉好一点"——但没有量化。

对策：

• 准备评估集

• 用 LLM Judge / 人工评分

• 数据化对比

反模式 3：散落在代码中

症状：prompt 写在 100 个不同 .py 文件里，硬编码字符串。

对策：

• 集中到 prompts/ 目录

• 版本管理

• 团队共享

反模式 4：忽视模型版本

症状：上线时用 Claude Sonnet 4.5，升级到 4.6 后效果异常。

对策：

• 每次升级模型重跑评估

• 关键 prompt 锁定版本

• 渐进切换

反模式 5：迷信"咒语"

症状：写一堆"你必须！！！否则我会失业！！！"

对策：

• 这些"咒语"对推理模型基本无效

• 用清晰描述替代情绪化表达

反模式 6：忘了 prompt cache

症状：每次 RAG 都把整个 system + 文档塞进去，账单飞起。

对策：

• 启用 prompt caching（OpenAI / Anthropic）

• 重复 prompt 部分前置

八、应用生态篇收官

至此，前30 篇覆盖了从底层架构到应用落地的完整链路。剩下 5 篇是前沿与思考——把视野推到 LLM 工程的最前线。

九、结语：Prompt 工程是「LLM 工程师的内功」

读完本文你应该明白：

• Prompt 工程不是玄学——是可量化、可工程化的技能

• 基础 5 原则：明确角色、结构化、明确输出、少 negation、给例子

• 进阶 6 技巧：CoT / Self-Consistency / ToT / ReAct / Reflection / Chaining

• 工程化标配：版本管理 + 评估集 + A/B 测试 + 监控

• Prompt → RAG → SFT → 对齐的优先级

• 不同模型有不同的 prompt 哲学——别一套打天下

参考文献：

30.Prompt 工程方法论：从玄学到工程化