应用生态篇已经走过 4 篇第 26 篇 RAG 实战第 27 篇 Function Calling / Tool Use第 28 篇 Agent 框架第 29 篇 多模态部署这一篇是应用生态篇的收官——也是整个系列里最被低估的一篇。为什么这么说因为很多人把 Prompt 工程当成玄学——觉得就是换几个词试试谈不上工程。但事实是同样的模型好的 prompt 比差的 prompt 准确率能差 30-50%。同样的业务prompt 设计差异能让月成本差 10×。同样的应用prompt 工程做得好的团队迭代速度是别人 3 倍。如果你做过相关工作下面这些问题应该不陌生同样的提示词今天答得好明天就崩了——怎么治Prompt 调到上线效果好但版本一升级就跟着退化——怎么管理团队 20 个 prompt 文件散落各处没人知道哪个在用——怎么治理怎么量化这个 prompt 比那个好读完本文你将能理解 prompt 演变的逻辑从 zero-shot 到 ReAct 到 thinking掌握 5 大基础原则和 6 大进阶技巧把 prompt 工程化版本管理 测试 监控知道什么时候该升级到微调我们开始。一、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 工程出现了根本性转变传统 LLM推理模型你要写 CoT 提示模型自己思考多 example 启发推理1-2 个就够复杂 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少做 negationLLM 对不要做什么理解不如要做什么。❌ 差「不要用专业术语」 ✅ 好「用初中生能理解的语言」 ❌ 差「不要回答与主题无关的问题」 ✅ 好「只回答关于产品 X 的问题其他主题礼貌拒绝」2.5 原则 5例子 描述少量好例子胜过千言万语描述描述把数字转中文大写 例子更好 123 → 壹佰贰拾叁 4567 → 肆仟伍佰陆拾柒 8900 → 捌仟玖佰 现在12345 → ?Few-shot 学习是 LLM 的天赋——好好用。三、6 大进阶技巧3.1 Chain of ThoughtCoT让模型**逐步思考再答**问题一个商店原价 X 元先打 8 折再加 10% 销售税最终价格是多少 CoT prompt 请逐步思考再回答 1. 先算 8 折后的价格 2. 再算加税后的价格 3. 给出最终答案对推理模型已经不需要——它们天生会思考。但对小模型 30B和复杂问题仍然有效。3.2 Self-Consistency自洽性让模型生成 N 次投票选最一致的答案def self_consistency(prompt, n5): answers [llm(prompt, temperature0.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 ThoughtsToTCoT 是线性的——错一步全错。ToT 让模型探索多条路径1. 生成 K 个下一步思路 2. 评估每个思路的优劣 3. 选最优的几个继续展开 4. 像走树搜索一样推进适合博弈、规划、有多种合理路径的题。代价调用次数指数级。3.4 ReAct推理 行动第 27 篇详细讲过Thought我需要先查 X Actiontool_call(...) Observation结果 Thought现在我...是 Agent 的基础。3.5 Reflection自反思让模型自我批评 改进def reflect_and_improve(question, max_round3): 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.mdYAML 元数据# 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: alice4.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 Judgedef 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 要监控这些指标指标含义成功率模型输出符合预期格式的比例拒答率模型说不知道的比例平均 token输入 / 输出 token 趋势延迟端到端响应时间用户反馈点赞 / 点踩比例错误率解析失败 / 调用失败主流工具LangSmithLangChain 官方Langfuse开源 alternativePhoenixArize 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(questionquestion) # 自动优化 prompt基于训练数据 optimizer dspy.BootstrapFewShot(metricmy_metric) optimized_qa optimizer.compile(QA(), trainsetexamples)DSPy 会自动学到最优的 few-shot 例子超过人工调参。PromptHub / Prompt Lab各种 prompt 协作平台团队共享 / Review版本对比一键 deploy五、Prompt vs 微调什么时候升级回顾第 7 篇我们提过的优先级Prompt → RAG → SFT → 对齐微调用 Prompt 解决的场景通用任务写作、翻译、总结输出格式要求一般调用量不大业务还在变升级到 SFT 的信号Prompt 调到极限效果仍然不够输出格式严格JSON / 特定结构大量调用prompt 长度成本高业务稳定值得固化5.1 决策矩阵现象解决方案格式偶尔崩结构化输出 / 重试格式经常崩SFT 训格式风格不稳定Few-shot 示例风格仍不稳SFT 训风格准确率 80% 但不够评估 Reflection准确率 60%SFT 训垂直能力推理能力差用推理模型 / SFT 推理知识不够RAG5.2 真实经验Prompt 长度的成本业务跑量大时长 prompt 大账单。prompt 长度 1000 token vs 5000 token 1 万次调用 多花 4000 万 token ~$80按 GPT-4 算 1 千万次 $80,000 差异优化Prompt 精简Prompt cachingOpenAI / 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_format6.3 Google / Gemini 系偏好结构化 prompt长上下文最强喜欢Step by step 标记6.4 国产模型Qwen中文优化好prompt 风格类似 GPTDeepSeek R1推理模型反而要简洁不要画蛇添足 CoTGLM中文 结构化6.5 一个 prompt 多模型兼容PROMPT_TEMPLATES { openai: 你是助手。\n\n# 任务\n{task}\n\n# 上下文\n{context}, anthropic: task{task}/task\ncontext{context}/context, qwen: ## 任务\n{task}\n\n## 上下文\n{context}, } def render_prompt(model_family, task, context): return PROMPT_TEMPLATES[model_family].format(tasktask, contextcontext)七、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 cachingOpenAI / Anthropic重复 prompt 部分前置八、应用生态篇收官篇号主题核心26RAG 实战让模型「知道」27Function Calling让模型「会做」28Agent 框架让模型「自主」29多模态部署让模型「看听」30Prompt 工程让模型「听懂」至此前30 篇覆盖了从底层架构到应用落地的完整链路。剩下 5 篇是前沿与思考——把视野推到 LLM 工程的最前线。九、结语Prompt 工程是「LLM 工程师的内功」读完本文你应该明白Prompt 工程不是玄学——是可量化、可工程化的技能基础 5 原则明确角色、结构化、明确输出、少 negation、给例子进阶 6 技巧CoT / Self-Consistency / ToT / ReAct / Reflection / Chaining工程化标配版本管理 评估集 A/B 测试 监控Prompt → RAG → SFT → 对齐的优先级不同模型有不同的 prompt 哲学——别一套打天下参考文献30.Prompt 工程方法论从玄学到工程化