Prompt Engineering 进阶实战：从套路到方法论

上周我盯着屏幕上第 17 个测试结果，心里挺崩溃的。

明明是同一个 Prompt——“请帮我分析这段代码的性能瓶颈，并给出优化建议”，周一上午 Claude 回答得又详细又专业，周五下午却给我一堆空泛的废话。换了个模型试试，ChatGPT 直接把代码改了，没问过我需不需要改，也没解释为什么要改。

说实话，我踩过这个坑太多了。不管是做 AI 辅助编程，还是构建 Agent 应用，Prompt 的效果总是在”还行”和”完全不行”之间反复横跳。后来我才意识到一个问题：我一直在用零散的技巧拼凑 Prompt，从来没想过要建立一套真正的方法论。

嗯，这篇文章就是想把这件事说清楚。从”知道几个套路”升级到”掌握系统方法论”，我们聊聊三层 Prompt 技术框架、思维链和 ReAct 的原理、DSPy 这个自动化优化神器，还有 Claude 和 ChatGPT 到底该怎么写不同的 Prompt。最后，我会分享一套可操作的评估方法——毕竟，不知道 Prompt 效果好不好，谈优化就是瞎折腾。

为什么需要从”套路”到”方法论”

你可能听过这些”套路”：让 AI “请一步步思考”、加几个示例让它模仿、给它设个角色说”你是专家”…这些技巧确实有用，但问题是——效果太不稳定了。

经验驱动的局限

2023 到 2024 年，大部分 Prompt 技术都是经验驱动的。什么叫经验驱动？说白了就是”试试看”——改几个词，跑一下，效果好了就用，不好再改。这种方式有几个明显的痛点：

效果不可预测。同一个 Prompt，换个模型可能就失效了。甚至同一模型，不同时间段调用，输出质量都能差挺多。我见过不少人（包括我）花几个小时调 Prompt，结果第二天发现昨天的好版本又不好用了。

难以复现和传承。你调出了一个很好的 Prompt，但同事用的时候效果却不一样。为什么？因为你的 Prompt 里可能隐含了一些你自己没意识到的上下文——比如你之前和这个模型聊过什么、你的写作习惯等等。这些东西没法写进文档，别人就没法复现。

缺乏评估标准。一个 Prompt 到底好不好？很多时候只能凭感觉。“这次输出看起来还行”——这种判断太主观了。没有量化指标，就没法系统性地优化。

89%

首次理解正确率

来源: 某金融科技公司采用3C公式后的测试数据

有个挺有意思的数据：某金融科技公司在用系统化 Prompt 方法（他们叫”3C 公式”——Context、Constraint、Content）之前，首次理解正确率只有 61%。采用系统化框架后，这个数字提升到了 89%。这不是小改进，是质的飞跃。

2025-2026 年的转变

从 2025 年开始，Prompt Engineering 正在经历一场转变——从”手工调参”到”系统化工程”。这场转变有三个关键突破：

模块化设计。把 Prompt 拆成可复用的组件，像写代码一样组装。你不用每次从头写一个长的 Prompt，而是组合几个标准模块。这种方式的好处是：组件可以单独测试、单独优化，整体稳定性大大提高。

自动化优化。框架开始帮你优化 Prompt，而不是你手工调。DSPy 是这方面最有代表性的框架——你定义好任务和评估标准，它能自动迭代找到最优的 Prompt 配置。这个理念的核心是：“Programming, not prompting”。

标准化评估。有了量化指标和测试框架，Prompt 的效果可以被客观衡量。DeepEval、Promptfoo 这些工具提供了评估维度：准确性、一致性、安全性、成本效率。评估不再靠感觉，而是看数据。

说实话，这三件事彻底改变了我的工作方式。以前我调 Prompt 是”碰运气”，现在更像做工程——有设计、有测试、有迭代、有数据支撑。这就是从”套路”到”方法论”的核心转变。

三层 Prompt 技术框架

把 Prompt 技术分三层来理解，会清晰很多。基础层、推理层、系统层，每一层解决不同类型的问题。

基础层：让模型听懂你的话

这层技术解决最基本的问题：怎么让模型输出你想要的东西。

Zero-shot，零样本提示，就是不给任何示例，直接让模型完成任务。比如：

请解释什么是微服务架构。

这种方式简单直接，适合简单任务或者常识性问题。但对于复杂任务或者需要特定格式的输出，Zero-shot 的效果往往不稳定。

Few-shot，少样本提示，给模型 2-5 个示例让它学习。比如你想让模型帮你写产品描述，风格要活泼一点：

请根据以下示例风格，为新产品写描述：

示例1：
产品：无线蓝牙耳机
描述：戴在耳朵上的小宇宙，音质清晰得像在现场听演唱会，续航给力到能陪你飞一趟跨国航班。

示例2：
产品：便携咖啡机
描述：把咖啡馆装进背包，随时随地来一杯手冲精品，咖啡渣都能精准控制。

现在请为"智能保温杯"写一个产品描述。

模型会模仿示例的风格来写。Few-shot 的关键是：示例要和你期望的输出风格一致，数量不用太多（2-5 个就够），但质量要高。

Role Prompting，角色提示，给模型设定一个身份。这种方式能约束输出的风格和专业程度：

你是一位有10年经验的后端架构师，擅长性能优化和系统设计。
请分析以下代码的性能问题，指出具体瓶颈并给出优化建议。
代码：[粘贴代码]

设定角色后，模型会更倾向于从专业角度思考，输出也更结构化。但角色设定要具体——“你是专家”太泛了，不如说清楚是什么领域的专家、有什么经验。

结构化输出，要求模型输出特定格式（JSON、Markdown、表格等）。这个技巧在做数据提取或者对接下游系统时特别有用：

请从以下文本中提取产品信息，以JSON格式输出：
{
  "product_name": "产品名称",
  "price": "价格",
  "features": ["特性列表"]
}

文本：[粘贴文本]

结构化约束能大大提高输出的可用性，减少你后续处理的工作量。

推理层：让模型”会思考”

这层技术让模型不仅能听懂你的话，还能进行复杂的推理。

Chain-of-Thought (CoT)，思维链，让模型展示推理过程。这个技术的核心是：别让模型直接给出答案，先让它说清楚是怎么想的。

2022 年 Wei 等人发表的论文证明，CoT 能显著提升复杂推理任务的正确率。原理挺简单——复杂问题需要多步推理，让模型把这些步骤写出来，相当于给它一个”思考缓冲区”，不容易出错。

最简单的 CoT 用法就是在 Prompt 末尾加一句：

请一步步思考这个问题，然后给出答案。

或者用 Few-shot CoT，给模型展示带推理过程的示例：

问题：小明有5个苹果，给了小红2个，又从树上摘了3个。现在小明有多少苹果？
推理过程：小明开始有5个苹果。给了小红2个后，剩下5-2=3个。从树上摘了3个后，有3+3=6个。
答案：6个苹果。

现在请用同样的方式解决：一个篮子里有12颗草莓，小明吃了4颗，小红又放进篮子6颗。篮子里现在有多少草莓？

ReAct，推理+行动循环，让模型边思考边执行操作。这个框架的流程是：Thought（思考下一步）→ Action（执行动作）→ Observation（观察结果）→ 再思考下一轮。特别适合需要调用外部工具或检索信息的场景。

你是一个能够搜索信息的助手。请用以下格式回答问题：

Thought: [当前需要做什么]
Action: search("[搜索内容]")
Observation: [搜索结果]
... (循环直到找到答案)
Final Answer: [最终答案]

问题：2024年奥斯卡最佳影片是哪部电影？

ReAct 在 Agent 开发中特别重要——Agent 的核心就是”思考-行动-反馈”循环，ReAct 提供了一个标准模板。

Self-Consistency，自一致性，让模型多次推理同一个问题，然后投票选择最可信的答案。这种方式在需要高准确度的场景有用，但成本会比较高（要调用多次模型）。

Tree of Thoughts (ToT)，思维树，让模型探索多条推理路径，选择最优的一条。适合复杂决策问题，比如创意方案生成、策略规划。

系统层：工程化的 Prompt 管理

这层不是单一技术，而是把 Prompt 管理变成一个工程体系。

模块化 Prompt。把一个复杂的 Prompt 拆成多个可复用的模块。比如一个 Agent 的 Prompt 可以拆成：角色设定模块、任务定义模块、输出约束模块、工具调用模块。每个模块独立管理，组合时灵活配置。

自动化优化。用 DSPy 这样的框架，你不用手工调 Prompt 参数。你定义任务签名和评估指标，框架自动迭代优化。这个在后面会详细讲。

标准化评估。建立一套评估体系：准备测试集、定义评估指标、跑批量测试、记录每次迭代的得分变化。这样 Prompt 优化就有数据支撑，不是凭感觉了。

三层框架的用处是帮你判断：当前问题属于哪个层次，该用什么技术解决。简单任务用基础层，复杂推理用推理层，构建系统用系统层。

Chain-of-Thought 思维链深度解析

思维链这个技术，值得单独展开讲一讲。它是目前最成熟的推理增强技术，而且使用门槛不高——你不需要写复杂的框架代码，只需要在 Prompt 里加几句话。

Zero-shot CoT vs Few-shot CoT

两种用法，各有适用场景。

Zero-shot CoT，不加示例，只加一句引导语。最经典的就是这句：

Let's think step by step.

或者中文版：

请一步步思考这个问题。

这种方式简单、成本低，适合大部分场景。研究发现，哪怕只加这一句，复杂推理任务的正确率能提升 20-40%。

Few-shot CoT，加带推理过程的示例。示例里要完整展示”问题→推理过程→答案”的格式：

问题：一个商店进货100件商品，成本每件20元。第一天卖出30件，售价35元。第二天卖出50件，售价30元。第三天剩余商品降价清仓，售价15元全部卖出。总利润是多少？

推理过程：
1. 计算总成本：100件 × 20元 = 2000元
2. 第一天收入：30件 × 35元 = 1050元
3. 第二天收入：50件 × 30元 = 1500元
4. 第三天剩余：100-30-50=20件，收入：20件 × 15元 = 300元
5. 总收入：1050+1500+300 = 2850元
6. 总利润：2850-2000 = 850元

答案：850元

现在请用同样的方式解决：
问题：某公司有员工200人，平均月薪8000元。年初裁员30人，裁员补偿每人2个月工资。裁员后招聘新员工50人，试用期月薪6000元，试用期3个月。问这一年公司薪酬支出变化是多少？

Few-shot CoT 的好处是能引导模型用特定的推理格式和思维方式。但你要花时间写高质量示例——示例写得不好，反而会误导模型。

什么时候用哪种？

任务简单、推理路径明确：用 Zero-shot CoT，加一句引导就够了
任务复杂、需要特定推理格式：用 Few-shot CoT，给几个好示例
模型能力强（比如 Claude 4）：Zero-shot CoT 往往就够用
模型能力一般、任务精度要求高：Few-shot CoT 更稳

CoT 适用场景

不是所有任务都需要 CoT。它最适合这些场景：

数学推理和逻辑分析。这类任务需要多步计算或逻辑推导，CoT 能让模型不跳步、不遗漏。

# 不用 CoT 的输出可能：
"答案是850元。"（直接跳到结果，中间可能算错了）

# 用 CoT 的输出：
"让我一步步计算..."
然后详细展示每一步。

多步骤任务规划。比如让模型帮你写一个项目计划，或者设计一个系统架构。CoT 能让模型先分解任务、再逐步展开。

代码生成中的问题分析。让模型先分析需求、再设计方案、再写代码，而不是直接吐代码。

请按以下步骤帮我实现一个用户认证系统：

步骤1：分析需求，列出核心功能点
步骤2：设计数据模型和接口
步骤3：给出具体实现代码
步骤4：说明测试方案

需求：[你的需求描述]

CoT 的几个变体

Auto-CoT，自动生成推理链。原理是让模型自己生成示例的推理过程，然后作为 Few-shot 示例用。这样可以省去手工写示例的工作。不过 Auto-CoT 的质量取决于模型第一次生成推理过程的质量——如果第一次生成错了，后面的推理也会跟着错。

CoD（Chain of Debate），辩论链。让两个模型角色对同一个问题进行辩论，互相质疑对方的推理，最后综合得出答案。这种方式在复杂问题、开放性问题上效果不错，但成本高、时间长。

CoT 使用注意点

说几个我踩过的坑：

不要过度强制推理。有些简单问题不需要 CoT。比如问”北京的人口是多少”，加 CoT 反而会让输出变啰嗦，甚至推理出错。判断标准：任务是否需要多步推理？

示例要和任务匹配。如果你给的 Few-shot 示例是数学题，但任务其实是逻辑推理，模型可能会用数学推理的方式去解逻辑题——效果不好。示例的类型要和任务一致。

推理步骤不要太长。CoT 能提升准确率，但推理过程如果太长（比如十几步），中间可能出错。遇到特别复杂的问题，可以考虑分阶段处理：先让模型拆解问题，再分别处理每个子问题。

总的来说，CoT 是最实用的推理增强技术。掌握两种用法（Zero-shot 和 Few-shot），判断清楚什么时候需要、什么时候不需要，你的 Prompt 效果会有明显提升。

ReAct 框架：推理与行动的结合

ReAct 这个名字是 Reasoning + Acting 的缩写。它把思考和行动结合起来，让模型能动态地调用工具、获取信息、做出决策。如果说 CoT 是让模型”想清楚”，那 ReAct 就是让模型”边想边做”。

Thought → Action → Observation 循环

ReAct 的核心是一个循环结构：

Thought（思考）→ Action（行动）→ Observation（观察）→ Thought → ...

每一轮循环都在推进问题的解决。举个搜索增强问答的例子：

任务：查询2024年诺贝尔物理学奖得主的研究领域。

模型执行过程：

Thought: 我需要先查2024年诺贝尔物理学奖得主是谁。
Action: search("2024 Nobel Prize in Physics winners")
Observation: [搜索结果] 2024年诺贝尔物理学奖授予John Hopfield和Geoffrey Hinton，表彰他们在人工神经网络领域的贡献。

Thought: 现我知道了得主是谁，需要进一步查他们的研究领域。
Action: search("John Hopfield research field")
Observation: [搜索结果] John Hopfield是物理学家，提出Hopfield网络模型...

Thought: 我已经获得了足够信息，可以回答问题了。
Final Answer: 2024年诺贝尔物理学奖得主John Hopfield和Geoffrey Hinton的研究领域是人工神经网络...

这个循环机制让模型能在推理过程中”补信息”——遇到不知道的事情，它不是瞎猜，而是主动去查。这点和 CoT 的区别很明显：CoT 只用模型内部的知识，ReAct 能调用外部工具获取新信息。

ReAct vs CoT：关键区别

维度	CoT	ReAct
信息来源	模型内部知识	内部知识 + 外部工具
推理方式	纯思考	思考 + 行动交替
适用场景	已有足够信息	需要检索、调用工具
实现复杂度	简单（改Prompt）	复杂（需要工具集成）
成本	单次调用	可能多次调用

CoT 更适合模型已经有足够知识的场景——比如数学推理、逻辑分析。ReAct 更适合需要实时信息的场景——比如回答当前事件、查询数据库、调用 API。

ReAct 的 Prompt 结构

一个标准的 ReAct Prompt 包含这几个部分：

你是一个能够使用工具的智能助手。请用以下格式完成任务：

可用工具：
- search(query): 搜索互联网获取信息
- database_query(sql): 查询数据库
- calculate(expression): 执行数学计算

格式：
Thought: [你的思考过程，分析当前需要做什么]
Action: [工具名称和参数，如 search("查询内容")]
Observation: [工具执行结果，会自动填入]
... (可以多轮 Thought-Action-Observation)
Final Answer: [最终答案]

开始！

任务：[你的具体任务]

关键点：

定义可用工具。让模型知道它能用哪些工具、怎么调用。工具定义要具体，包括名称、参数格式、返回类型。

规定输出格式。Thought、Action、Observation 的格式要明确，这样你的系统才能解析模型输出、执行工具调用、把结果喂回给模型。

终止条件。让模型在获得足够信息后输出 Final Answer，而不是无限循环。

ReAct 在 Agent 开发中的应用

ReAct 是现代 Agent 架构的基础模式之一。如果你在构建一个 AI Agent——不管是客服机器人、数据分析助手，还是自动化运维系统——大概率会用 ReAct 的思想。

实际项目中，ReAct 的实现比上面这个简单 Prompt 要复杂。你需要：

工具注册系统：定义工具的接口、参数校验、权限控制
执行引擎：解析模型的 Action 输出，调用对应工具，把结果格式化喂回
循环控制：设置最大循环次数、超时机制，防止死循环
错误处理：工具调用失败时，告诉模型发生了什么，让它调整策略

ReAct 使用注意点

模型要足够强。ReAct 需要模型在多轮对话中保持上下文，做出合理的行动决策。太弱的模型容易乱调用工具、偏离任务目标。Claude 和 GPT-4 系列模型做 ReAct 效果比较好。

工具定义要清晰。如果模型不知道某个工具能做什么，它可能不会调用，或者调用方式不对。每个工具的描述要像写 API 文档一样详细。

避免过度依赖工具。有些信息模型内部就有，不需要每次都调工具。可以在 Prompt 里加判断逻辑：“如果内部知识足够回答，直接给出 Final Answer，不需要调用工具。”

成本控制。ReAct 可能触发多次工具调用，API 费用会比较高。复杂任务用 ReAct，简单任务还是用普通 Prompt 更划算。

ReAct 把 Prompt 从”静态脚本”变成了”动态程序”，让 AI 能真正动手解决问题。这是从”对话式 AI”到”行动式 AI”的关键一步。

DSPy：让 Prompt 自动优化

前面讲的 CoT、ReAct 都需要你手工写 Prompt。但有个框架不一样——DSPy，它的核心理念是：“Programming, not prompting”。意思是：用编程的方式定义任务，让框架自动帮你生成和优化 Prompt。

DSPy 是什么

DSPy 是 Stanford NLP 组开发的一个框架。它把 Prompt Engineering 变成了编程范式：你定义任务的输入输出结构（Signature），选择合适的模块（Module），配置优化器（Optimizer），框架会自动迭代找到最优的 Prompt 配置。

这个思路的好处：

更可靠。手工写的 Prompt 容易有遗漏、格式不对、约束不够明确。DSPy 的声明式定义更严谨。

更可维护。Prompt 变成了代码，可以版本管理、单元测试、持续迭代。

更可移植。换模型的时候不用重新调 Prompt——框架会自动适配新模型的特点。

DSPy 的核心组件

Signature（任务签名）：定义任务的输入输出结构。

import dspy

class QuestionAnswer(dspy.Signature):
    """回答问题，给出详细解释"""
    question = dspy.InputField(desc="用户的问题")
    answer = dspy.OutputField(desc="详细的答案，包含推理过程")

Signature 就像函数的接口定义——说明输入是什么、输出是什么、每个字段有什么要求。你不用写具体的 Prompt 文本，只定义结构。

Module（模块）：封装特定 Prompt 技术的可复用组件。

# 最基础的模块：直接预测
qa_basic = dspy.Predict(QuestionAnswer)

# 加思维链的模块
qa_cot = dspy.ChainOfThought(QuestionAnswer)

# 加 ReAct 的模块（需要配置工具）
qa_react = dspy.ReAct(QuestionAnswer, tools=[search_tool, calculator_tool])

模块把 Prompt 技术封装好了。你想用 CoT，选 ChainOfThought 模块就行，不用自己写”请一步步思考”这种引导语。框架会根据模块类型自动生成对应的 Prompt。

Optimizer（优化器）：自动优化 Prompt 配置。

from dspy.teleprompt import BootstrapFewShot

# 准备训练数据
trainset = [
    dspy.Example(question="什么是递归？", answer="递归是函数调用自身..."),
    dspy.Example(question="解释冒泡排序", answer="冒泡排序通过相邻元素比较..."),
]

# 配置优化器
optimizer = BootstrapFewShot(max_bootstrapped_demos=3)

# 优化模块
qa_optimized = optimizer.compile(qa_cot, trainset=trainset)

优化器会自动生成 Few-shot 示例、调整 Prompt 结构、迭代找到最优配置。你给它训练数据和评估标准，它帮你调参数——有点像机器学习的训练过程，只不过调的是 Prompt 而不是模型权重。

一个完整的 DSPy 示例

我们来写一个能回答编程问题的 QA 系统：

import dspy

# 1. 定义 Signature
class CodeQA(dspy.Signature):
    """回答编程相关问题，给出清晰解释和示例"""
    question = dspy.InputField(desc="编程相关问题")
    answer = dspy.OutputField(desc="详细答案，包含概念解释和代码示例")

# 2. 配置语言模型
lm = dspy.LM("claude-3-5-sonnet-20241022", api_key="your_key")
dspy.settings.configure(lm=lm)

# 3. 创建模块（用 ChainOfThought 加推理能力）
qa = dspy.ChainOfThought(CodeQA)

# 4. 直接调用
result = qa(question="Python 里怎么实现装饰器？")
print(result.answer)

这个例子里，我们没写任何 Prompt 文本。ChainOfThought 模块自动生成了带思维链引导的 Prompt。输出的 answer 会包含推理过程和详细解释。

如果要优化效果，可以加训练数据和优化器：

# 5. 准备训练数据
train_examples = [
    dspy.Example(
        question="什么是 REST API？",
        answer="REST API 是一种网络应用程序接口设计风格..."
    ),
    dspy.Example(
        question="解释 Git 的分支概念",
        answer="Git 分支允许你从主线开发中分离出独立的工作线..."
    ),
]

# 6. 定义评估函数
def evaluate_answer(example, pred):
    """检查答案是否包含关键词、长度是否合理"""
    keywords = example.question.lower().split()
    has_keywords = sum(1 for k in keywords if k in pred.answer.lower()) >= 2
    length_ok = len(pred.answer) > 100
    return has_keywords and length_ok

# 7. 优化
optimizer = BootstrapFewShot(metric=evaluate_answer, max_bootstrapped_demos=4)
qa_optimized = optimizer.compile(qa, trainset=train_examples)

# 8. 用优化后的模块
result = qa_optimized(question="Python 里怎么实现装饰器？")

优化器会基于训练数据，自动生成 Few-shot 示例、调整 Prompt 格式，让输出质量更高。整个过程不需要你手工调 Prompt。

什么时候用 DSPy，什么时候手工写 Prompt

DSPy 不是万能的。有些场景适合用框架，有些场景手工写更合适。

适合 DSPy 的场景：

构建 AI 应用系统（需要多次复用同一类 Prompt）
任务结构明确（输入输出可以标准化定义）
有训练数据（可以用来优化）
需要跨模型迁移（不同模型可能表现不同，框架能自动适配）
项目复杂度高（Prompt 数量多，手工管理混乱）

适合手工 Prompt 的场景：

单次使用（写一次 Prompt 用一次，不需要复用）
任务结构模糊（输入输出难以标准化）
没有训练数据（没法优化）
快速原型验证（需要快速试错，不想花时间配置框架）
简单任务（Zero-shot 就能搞定，没必要用框架）

我的经验是：对于项目级应用、需要长期维护的系统，DSPy 的投入产出比很高。初期配置要花点时间，但后续迭代效率会大大提升。对于一次性任务、简单查询，手工写 Prompt 更直接。

DSPy 使用注意点

评估指标很重要。优化器依赖你的评估函数。如果评估标准不合理，优化方向可能不对。要花时间设计好的评估指标。

训练数据质量。BootstrapFewShot 会基于训练数据生成示例。数据质量差，生成的示例也差，反而影响效果。

不要过度优化。优化迭代次数多不一定更好。有时候优化器会”过拟合”训练数据，在新问题上表现反而下降。设置合理的迭代次数上限。

DSPy 代表了 Prompt Engineering 的一个新方向——从手工调参到自动化优化。对于想系统性构建 AI 应用的开发者，这是一个值得掌握的工具。

Claude vs ChatGPT：差异化最佳实践

Claude 和 ChatGPT 是目前最主流的两个大模型。很多人问：同一个 Prompt，为什么两个模型的输出不一样？该怎么分别优化？这里聊聊它们的差异和针对性的最佳实践。

模型特性对比

先说关键差异点：

维度	Claude	ChatGPT (GPT-4系列)
上下文长度	200K tokens	128K tokens
结构化输出	表现优秀，偏好XML/JSON	表现良好，需要明确格式约束
推理风格	更严谨、步骤清晰	更灵活、有时跳跃
代码生成	质量高、解释详细	质量高、创意性强
创意性	相对保守	更有创意、风格多样
中文表达	自然流畅	自然流畅
多轮对话	保持上下文能力强	保持上下文能力强

这些差异不是绝对的，不同版本、不同任务会有变化。但总体上，Claude 更偏向严谨推理和结构化输出，ChatGPT 更偏向灵活创意和快速响应。

Claude 的最佳实践

1. 用 XML 标签做结构化约束

Claude 对 XML 标签格式的理解特别好。把内容用标签包裹，能提高输出质量：

请分析以下代码的性能问题：

<code>
function processData(data) {
  let result = [];
  for (let i = 0; i &lt; data.length; i++) {
    result.push(transform(data[i]));
  }
  return result;
}
</code>

请用以下格式输出分析结果：

<analysis>
[性能问题分析]
</analysis>

<suggestions>
[优化建议]
</suggestions>

XML 标签的好处是让模型清楚地区分输入内容和输出格式。Claude 会严格按照标签结构输出，不会把分析混在建议里。

2. 角色 + 约束 + 示例模式

Claude 响应角色设定和约束非常认真。一个完整的 Prompt 结构：

角色设定：
你是一位资深性能优化工程师，有8年Java后端经验。你擅长识别性能瓶颈并给出可落地的优化方案。

任务约束：
- 分析时要指出具体的性能瓶颈（不要泛泛地说"可以优化"）
- 建议要包含代码修改示例
- 如果某个优化有风险，要明确说明

输出示例：
<analysis>
问题：循环中频繁创建对象，可能导致内存压力。
位置：第3-5行的for循环。
</analysis>
<suggestions>
建议1：使用预分配数组大小。
代码：let result = new Array(data.length);
风险：无明显风险。
</suggestions>

现在请分析以下代码：
[粘贴你的代码]

这个结构让 Claude 知道：你是谁、要做什么、输出长什么样。它的输出会更符合你的预期。

3. 利用长上下文做详细分析

Claude 的 200K 上下文很适合处理长文档、复杂代码。你可以直接粘贴完整文件，不用担心截断：

请分析以下完整的代码文件，找出所有可能的性能问题：

完整代码：
<code>
[粘贴整个文件，几百行代码]
</code>

请按模块逐一分析，指出每个模块的性能问题和优化建议。

ChatGPT 的 128K 也够用大部分场景，但超长文档时 Claude 更有优势。

ChatGPT 的最佳实践

1. 明确的输出格式约束

ChatGPT 偏灵活，有时候输出格式会变。需要明确约束：

请分析代码性能问题，输出格式必须如下：

## 性能问题分析
- 问题1：[具体描述]
- 问题2：[具体描述]

## 优化建议
| 问题 | 建议 | 代码示例 |
|-----|-----|---------|
| [问题1] | [建议] | [代码] |

代码：
[粘贴代码]

用 Markdown 格式（## 标题、| 表格）约束输出，ChatGPT 会严格遵循。

2. 调整温度参数

ChatGPT 的 temperature 参数影响输出的创造性。temperature = 0 更确定性、一致性强；temperature = 0.7-1 更有创意、多样性高。

# 确定性输出（适合代码生成、数据分析）
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0
)

# 创意性输出（适合文案写作、创意设计）
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.8
)

Claude API 也有类似的参数控制，但 ChatGPT 的温度效果更明显。

3. 分步骤引导

ChatGPT 有时候会跳步，直接给出结果。对于复杂任务，可以分步骤引导：

请帮我完成以下任务，分步骤进行：

步骤1：先列出代码的主要功能模块
步骤2：分析每个模块的性能特点
步骤3：找出性能瓶颈
步骤4：给出优化方案

请先完成步骤1。

引导模型一步步输出，可以避免它跳步出错。

同一任务的不同 Prompt 写法

举个例子：让模型从一段文本中提取产品信息。

Claude 版本：

请从以下文本中提取产品信息：

<text>
[产品介绍文本]
</text>

输出格式：
<product_info>
<name>[产品名称]</name>
<price>[价格]</price>
<features>
<feature>[特性1]</feature>
<feature>[特性2]</feature>
</features>
</product_info>

ChatGPT 版本：

请从文本中提取产品信息，输出JSON格式。

文本：
[产品介绍文本]

输出格式示例：
{
  "name": "产品名称",
  "price": "价格",
  "features": ["特性1", "特性2"]
}

必须严格遵循此JSON结构，不要添加其他字段。

两者的差异：Claude 用 XML 更稳，ChatGPT 用 JSON + 明确格式约束更有效。

选择建议

需要严谨推理、结构化输出：优先 Claude
需要创意输出、快速原型：优先 ChatGPT
处理长文档、完整代码文件：优先 Claude（200K 上下文）
代码生成、技术问答：两者都很好，风格略有不同
文案写作、创意设计：优先 ChatGPT（调高温度）

实际项目中，可以根据任务类型选择模型，或者同时用两个模型对比效果。两个模型的 Prompt 写法确实需要针对性优化——用错模型的特点，效果可能差很多。

Prompt 评估与迭代方法论

前面的章节讲了很多 Prompt 技术。但有一个问题没解决：怎么知道你的 Prompt 效果好不好？没有评估，优化就是盲人摸象。这里聊聊 Prompt 的评估体系和迭代方法论。

评估维度：四个核心指标

一个好的 Prompt，要在四个维度上达标：

准确性。输出内容是否正确？这个维度最重要，评估方法也最难。对于客观任务（数学计算、事实查询），准确性的评估相对简单——对比输出答案和正确答案。对于主观任务（创意写作、方案设计），准确性变成”是否符合预期”，评估更复杂。

评估方法示例：

数学题：对比计算结果和正确答案
代码生成：运行代码，检查是否通过测试
问答：检查答案是否包含正确信息点
文案：人工评分，或对比关键指标（长度、关键词覆盖）

一致性。同一个 Prompt 多次调用，输出质量是否稳定？一致性差的 Prompt 可能今天好用、明天失效，不适合生产环境。

评估方法：同一个任务跑 10 次，统计输出质量波动范围。波动太大，一致性有问题。

安全性。输出是否包含有害内容、隐私泄露、偏见言论？这个维度在特定场景很重要（比如客服系统、内容审核）。

评估方法：设计敏感词检测、隐私信息检测规则，或者用专门的安全评估工具。

成本效率。Prompt 的 Token 消耗是否合理？太长的 Prompt 成本高，太短的 Prompt 效果差。要找到平衡点。

评估方法：记录每次调用的 Token 数量，计算平均成本。对比不同 Prompt 版本的性价比。

评估工具

几个主流的 Prompt 评估工具：

DeepEval。一个开源的 Prompt 评估框架，提供多种评估指标（准确性、一致性、相关性等）。适合批量测试和自动化评估。

from deepeval import evaluate
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

metrics = [
    AnswerRelevancyMetric(threshold=0.7),
    FaithfulnessMetric(threshold=0.8)
]

evaluate(test_cases, metrics)

Promptfoo。一个 CLI 工具，可以批量测试 Prompt、对比不同模型输出、生成评估报告。适合快速验证 Prompt 效果。

promptfoo eval --prompts my_prompt.txt --providers openai:gpt-4 --tests test_cases.yaml

OpenAI Evals。OpenAI 官方的评估框架，主要评估模型能力，也可以用于 Prompt 测试。

这些工具的共同特点：定义测试集 → 批量运行 → 自动评分 → 生成报告。用工具比手工测试效率高很多。

A/B 测试流程

改进 Prompt 时，A/B 测试是科学的方法。流程大概是：

步骤1：准备测试集。收集 20-50 个典型任务样本，覆盖不同场景。测试集要多样化，不能只有简单任务。

步骤2：定义评估指标。根据任务类型选择指标。比如问答任务用”答案正确率 + 信息覆盖率”，代码生成用”通过率 + 代码质量评分”。

步骤3：运行基准测试。用当前 Prompt 跑一遍测试集，记录各指标得分。这个得分是优化的起点。

步骤4：设计改进版本。根据基准测试的问题点，设计 Prompt 改进方案。比如准确性低，加 CoT；一致性差，加更严格的格式约束。

步骤5：对比测试。用改进版本跑同样的测试集，对比指标变化。如果改进版本得分更高，就采用新版本。

步骤6：迭代循环。如果改进效果不明显，分析原因，再设计下一轮改进。反复迭代直到达标。

一个简化版的测试记录表：

版本	准确性	一致性	Token成本	主要改进点
v1	65%	波动大(±20%)	850	基准版本
v2	78%	波动中(±10%)	920	加CoT引导
v3	82%	波动小(±5%)	1050	加Few-shot示例
v4	85%	波动小(±3%)	1050	优化示例质量

每次改进都要记录数据，这样优化过程是可追踪的。

Prompt 版本管理

Prompt 也是代码，需要版本管理。建议：

版本编号。给每个 Prompt 版本编号（v1, v2, v3…），记录改动时间和主要变化。

变更记录。每次修改都要记录：改了什么、为什么改、测试结果如何。

## Prompt 版本记录

### v3 (2026-04-15)
改动：添加3个Few-shot示例，优化输出格式约束
原因：v2一致性测试波动较大，输出格式不稳定
测试：准确率从78%提升至82%，一致性波动从±10%降至±5%

### v2 (2026-04-10)
改动：添加CoT引导语"请一步步思考"
原因：v1准确率偏低，复杂推理任务出错多
测试：准确率从65%提升至78%

### v1 (2026-04-05)
原始版本，无特殊优化
测试：准确率65%，一致性波动±20%

存储方式。Prompt 文件和测试数据放一起，方便追踪。可以用 Git 管理，也可以用专门的 Prompt 管理工具。

迭代优化的关键点

不要同时改太多东西。每次改进只调整一个变量，这样才能判断哪个改动有效。比如加 CoT 和加 Few-shot 不要同时做——先加 CoT 测试，再加 Few-shot 测试。

关注成本变化。有时候准确率提升了，但 Token 成本翻倍了。要权衡性价比，不是准确率越高越好。

记录失败尝试。不是所有改动都能提升效果。失败的尝试也要记录，避免以后重复犯错。

设置优化目标。不要无限优化。设定一个目标（比如准确率 80%），达标后就暂停迭代。过度优化浪费时间，边际效益递减。

评估和迭代是 Prompt Engineering 的”收尾”环节。没有评估，你不知道 Prompt 好不好；没有迭代，你没法持续改进。这两个环节加进来，Prompt Engineering 才真正变成一个完整的工程流程。

结论

说了这么多，核心其实就一件事：Prompt Engineering 正在从”玄学”变成”工程”。

三层技术框架帮你判断该用什么技术——基础层解决”让模型听懂”的问题，推理层解决”让模型思考”的问题，系统层解决”让 Prompt 可管理”的问题。CoT 和 ReAct 是目前最实用的推理增强技术，DSPy 代表了自动化优化的新方向。Claude 和 ChatGPT 的写法需要针对性调整——用 XML 标签约束 Claude，用明确格式 + 温度参数引导 ChatGPT。评估体系是整个方法论的最后一块拼图，没有评估就没有科学优化。

接下来你可以做几件事：

审视你现有的 Prompt。对照三层框架，看看你的 Prompt 在哪个层次？有没有明显的问题点（效果不稳定、成本太高、输出格式乱）？

试一次 DSPy。如果你的项目适合框架化管理，配置一个简单的 DSPy 模块，感受一下自动化优化的效果。

建立你的评估标准。准备一个测试集，定义几个关键指标，给你的 Prompt 做一次基准测试。有了数据，优化就有了方向。

Prompt Engineering 这件事，确实需要反复练习。但有了方法论，至少不再是”凭感觉瞎调”了。希望这篇文章能帮你建立起一个系统的思考框架。有问题欢迎交流。

参考资料

PromptingGuide.ai — Prompt Engineering 官方指南
DSPy Official — Stanford DSPy 框架官网
Claude Prompt Engineering Best Practices — Anthropic 官方文档
Chain-of-Thought Prompting Elicits Reasoning — Wei et al. 2022 论文
A Systematic Survey of Prompt Engineering — 2025 系统综述

常见问题

Zero-shot CoT 和 Few-shot CoT 有什么区别？什么时候用哪个？

Zero-shot CoT 只加一句引导语（"请一步步思考"），适合简单任务或模型能力强时。Few-shot CoT 需要写带推理过程的示例，适合复杂任务或需要特定推理格式时。判断标准：任务是否需要多步推理、模型能力是否足够、是否有时间写高质量示例。

DSPy 和手工写 Prompt 相比有什么优势？

DSPy 的三大优势：

• 更可靠：声明式定义比手工 Prompt 更严谨，减少遗漏和格式错误
• 更可维护：Prompt 变成代码，可版本管理、单元测试、持续迭代
• 更可移植：换模型时框架自动适配，不用重新调 Prompt

适合场景：项目级应用、任务结构明确、有训练数据、需要长期维护的系统。

Claude 和 ChatGPT 的 Prompt 写法有什么不同？

Claude 偏好 XML 标签做结构化约束，对角色设定和约束响应认真，适合长文档分析（200K上下文）。ChatGPT 需要明确的输出格式约束（Markdown/JSON），可调整温度参数控制创意性，偏灵活快速响应。关键技巧：Claude 用 XML，ChatGPT 用 JSON + 格式约束。

怎么评估一个 Prompt 的效果好不好？

四个核心维度：

• 准确性：输出内容是否正确
• 一致性：多次调用质量是否稳定
• 安全性：是否包含有害内容或隐私泄露
• 成本效率：Token 消耗是否合理

推荐工具：DeepEval（批量测试）、Promptfoo（快速验证）、OpenAI Evals。评估要有量化指标，不能只凭感觉。

ReAct 框架和 CoT 有什么区别？分别适合什么场景？

CoT 只用模型内部知识做纯思考推理，适合数学、逻辑分析等已有足够信息的场景。ReAct 结合思考和行动，能调用外部工具获取信息，适合需要实时信息、查询数据库、调用 API 的场景。实现复杂度：CoT 改 Prompt 即可，ReAct 需要工具集成系统。

Prompt 优化时 A/B 测试怎么做？

标准流程：

• 步骤1：准备20-50个典型任务测试集
• 步骤2：定义评估指标（正确率、覆盖率等）
• 步骤3：运行基准测试记录得分
• 步骤4：设计改进版本
• 步骤5：对比测试看指标变化
• 步骤6：迭代循环直到达标

关键原则：每次只改一个变量，记录失败尝试，设置优化目标上限。

28 分钟阅读 · 发布于: 2026年4月17日 · 修改于: 2026年4月18日

Easton

AI与智能

当前属于系列阅读第 8 / 20 篇

AI 开发实战

如果你是从搜索进入这篇文章，建议顺手补上上一篇或继续下一篇，这样更容易把同一主题读完整。

查看系列总览

自进化 AI：2026 年让模型持续学习的 4 种方法

深度解读 2026 年持续学习趋势，从 SDFT 自蒸馏到 MiniMax M2.7 自进化流程，解析让模型边用边学的 4 种方法及 LangChain 三层进化框架实战视角

第 7 / 20 篇

AI知识库20分钟搭完？Workers AI + Vectorize手把手教你做RAG（附完整代码）

想做AI知识库但不懂RAG？手把手教你用Cloudflare Workers AI + Vectorize搭建RAG应用，20分钟从原理到部署全搞定。包含完整代码、成本分析和实战技巧，零基础也能跑起来，支持智能问答和文档检索场景。

第 9 / 20 篇

2025年11月21日 AI与智能

OpenAI接口总是超时？用Workers搭建私人通道，0成本更稳定

BetterLink

想持续收到这个主题的更新？

你可以直接关注作者更新、订阅 RSS，或者继续沿着系列入口往下读，避免下次又回到搜索结果重新找。

关注公众号

订阅 RSS 继续浏览专题

使用 GitHub 账号登录后即可评论

为什么需要从”套路”到”方法论”

经验驱动的局限

2025-2026 年的转变

三层 Prompt 技术框架

基础层：让模型听懂你的话

推理层：让模型”会思考”

系统层：工程化的 Prompt 管理

Chain-of-Thought 思维链深度解析

Zero-shot CoT vs Few-shot CoT

CoT 适用场景

CoT 的几个变体

CoT 使用注意点

ReAct 框架：推理与行动的结合

Thought → Action → Observation 循环

ReAct vs CoT：关键区别

ReAct 的 Prompt 结构

ReAct 在 Agent 开发中的应用

ReAct 使用注意点

DSPy：让 Prompt 自动优化

DSPy 是什么

DSPy 的核心组件

一个完整的 DSPy 示例

什么时候用 DSPy，什么时候手工写 Prompt

DSPy 使用注意点

Claude vs ChatGPT：差异化最佳实践

模型特性对比

Claude 的最佳实践

ChatGPT 的最佳实践

同一任务的不同 Prompt 写法

选择建议

Prompt 评估与迭代方法论

评估维度：四个核心指标

评估工具

A/B 测试流程

Prompt 版本管理

迭代优化的关键点

结论

参考资料

常见问题

AI 开发实战

自进化 AI：2026 年让模型持续学习的 4 种方法

AI知识库20分钟搭完？Workers AI + Vectorize手把手教你做RAG（附完整代码）

相关文章

Workers AI 完整教程：每天白嫖 10000 次大模型调用，比 OpenAI 省 90%

Workers AI 完整教程：每天白嫖 10000 次大模型调用，比 OpenAI 省 90%

AI重构10000行老代码：2周完成1个月工作量的真实复盘

AI重构10000行老代码：2周完成1个月工作量的真实复盘

OpenAI接口总是超时？用Workers搭建私人通道，0成本更稳定

OpenAI接口总是超时？用Workers搭建私人通道，0成本更稳定

想持续收到这个主题的更新？

评论