提示工程实战指南：从基础到高阶的LLM提示模板

为什么提示工程值得系统学习

提示工程不是玄学，而是一种结构化沟通。LLM 的表现差异，往往不在于模型本身，而在于你如何组织输入。一篇来自 Dev.to 的长期实践总结指出，一套可复用的提示模式能够跨模型稳定生效——无论你用的是 GPT-4、Claude 还是 Llama，核心逻辑都相通。

本文基于这份系统化指南，梳理从零样本到思维树、从提示公式到反模式清单的完整知识体系，并给出可直接复制使用的模板。

提示公式：四个组件决定输出质量

任何有效的提示都包含四个基本元素：

ROLE + CONTEXT + INSTRUCTION + CONSTRAINTS = GOOD OUTPUT

以 Python 开发场景为例：

ROLE: You are a senior Python developer
CONTEXT: Building a REST API for a todo app with FastAPI
INSTRUCTION: Create a POST /todos endpoint with validation
CONSTRAINTS: Use Pydantic models, return 201 on success, 422 on validation error

角色定义了模型的知识调用范围，上下文限定了问题边界，指令明确目标动作，约束则控制了输出形态。缺少任何一个，模型都会用自己的默认假设来填补空白——而这通常不是你想要的结果。

Level 1：基础模式

零样本指令（Zero-Shot）

最直接的方式，适用于任务简单、模型已充分训练的场景。例如要求编写一个计算复利的 Python 函数，只需给出参数和返回值定义即可。零样本的局限在于：当任务存在歧义时，模型会自行选择一种解释。

少样本示例（Few-Shot）

通过给出输入-输出对来建立模式。典型应用是自然语言转 SQL：提供三四个示例后，模型能更准确地理解你期望的输出风格和粒度。少样本对小模型尤为关键——实践建议，7B 参数以下的模型几乎必须配合示例使用。

思维链（Chain-of-Thought）

要求模型展示推理步骤。经典案例是求解两列火车相遇问题：模型依次计算合速度、时间、并给出最终答案。思维链对数学、逻辑推理类任务的提升最为显著。

Level 2：结构化模式

角色 + 上下文模式

将提示构建过程函数化，可以在代码中动态组装提示。指南中给出了一个 build_prompt 函数，支持传入角色、上下文、任务、约束和示例：

def build_prompt(role, context, task, constraints=None, examples=None):
    parts = [
        f"ROLE: {role}",
        f"CONTEXT: {context}",
        f"TASK: {task}"
    ]
    if constraints:
        parts.append(f"CONSTRAINTS:\n" + "\n".join(f"- {c}" for c in constraints))
    if examples:
        parts.append("EXAMPLES:\n" + "\n\n".join(examples))
    return "\n\n".join(parts)

实际调用时，角色为「Expert code reviewer」，上下文为「Reviewing a PR for a payment processing module」，约束包括聚焦 OWASP Top 10、检查注入和鉴权绕过、标记硬编码密钥、给出具体修复代码。这种结构化方式让提示本身成为可维护的代码资产。

任务分解与输出格式规范

将复杂任务拆为步骤并逐步执行——例如构建完整认证系统时，先设计数据库 schema，再实现密码哈希、注册端点、JWT 登录、令牌轮换、密码重置、限流和集成测试。每次只让模型执行一步。

输出格式规范则要求模型返回严格的 JSON 结构，指定 issues 数组和 summary 统计，并明确「No markdown, no explanation — just the JSON object」。这在需要程序化解析 LLM 输出的流水线中至关重要。

Level 3：高阶模式

ReAct（推理 + 行动）

ReAct 模式让模型在推理和工具调用之间交替。格式为 Thought → Action → Action Input → Observation 循环，最终给出答案。适用于需要外部信息或计算的场景，例如查询 Apple 当前市值并计算其 0.1%。

自洽性、思维树与元提示

自洽性（Self-Consistency）要求模型用三种不同方法解决同一问题，再比较结果以提高置信度。思维树（Tree of Thoughts）则列出多种方案路径——例如设计分布式限流器时对比令牌桶、滑动窗口日志、固定窗口计数等五种方案，逐一分析优劣后给出推荐。

元提示（Meta-Prompting）是用提示来改进提示。原始指令「Write a blog post about AI」经过补充目标受众、字数、语气、结构、SEO 关键词和行动号召后，变成一份可直接执行的创作简报。

ReAct 的工程意义：ReAct 将 LLM 从"一次性生成器"变成"循环控制器"，本质是把推理轨迹与外部工具调用解耦又交替。其 Thought 阶段产生自然语言推理，Action 阶段输出结构化工具调用（如搜索、计算器、数据库查询），Observation 阶段把工具返回结果注入下一轮上下文。这一模式是当前主流 Agent 框架（LangChain Agent、LlamaIndex、AutoGPT）的理论基础。工程实现时需要注意：必须设定最大循环步数以防死循环，Observation 应做截断或摘要以控制上下文长度，且要处理工具调用失败时的回退策略。与思维链相比，ReAct 的推理不再局限于模型内部知识，而是可以用真实数据校正每一步判断，因此在需要实时信息、精确计算或多跳检索的任务上优势明显。

三种模式的成本—收益权衡：自洽性、思维树和元提示都属于"用更多 token 换更高准确率"的策略，但代价结构不同。自洽性通常采样 3-5 条推理路径并做多数投票，成本是单次调用的数倍，适合有唯一正确答案的数学与逻辑题。思维树则引入显式的方案打分支与剪枝，可能结合 BFS 或 DFS 搜索，调用次数可达数十次，适合开放性设计决策，但需要评分函数来判断路径优劣。元提示是单向的一次性增强，成本最低，收益集中在"把模糊需求转化为可执行简报"这一环节。实践中建议先用元提示理清需求，再用自洽性处理关键计算，仅在真正需要探索性决策时才启用思维树，以避免无谓的 token 消耗和延迟。

模型差异与反模式

不同模型对提示的响应方式存在差异。GPT-4 和 Claude 擅长遵循复杂指令和结构化输出，偏好显式约束；Llama 和 Mistral 等开源权重模型需要更多示例和更清晰的步骤，有时会忽略否定约束（「不要做 X」），并且对 XML 标签的响应优于 Markdown；7B 以下的小模型则必须依赖少样本、短提示、单任务和明确的输出格式。

指南还列出了一组反模式对照表：

不好的写法	好的写法
"Write code"	"Write a FastAPI endpoint for user registration with Pydantic validation"
"Make it better"	"Optimize this query: reduce from 500ms to <50ms, add index suggestion"
"Fix bugs"	"Fix the race condition in lines 45-52 where concurrent writes corrupt state"
"Explain this"	"Explain this regex to a junior dev: break down each capture group"
无格式要求	"Return ONLY valid JSON matching this schema: {...}"

规律很清晰：具体性和可度量性是区分好提示与差提示的核心指标。

为什么模型对提示的响应方式不同：差异主要来自三个层面。其一是训练数据构成——GPT-4 与 Claude 的指令微调和 RLHF 数据中包含大量带结构化约束的任务，所以对"Return ONLY valid JSON"这类硬性要求服从度高；开源权重模型往往在社区语料上继续训练，指令遵循的覆盖度较窄。其二是架构与上下文窗口——Claude 的长上下文和 XML 标签偏好与其训练时采用的标注格式有关，而 Llama 系列对类似 Markdown 的分隔符更容易混淆，使用 <context>...</context> 这类显式标签能显著提升解析稳定性。其三是指令遵循与生成能力的权衡——7B 以下模型参数有限，同时处理长指令和长输出会退化，因此必须拆分为单任务、短提示并强制少样本示例。理解这些成因，比死记"某模型要用某写法"更能迁移到新模型上。

提示模板库与迭代流程

指南提供了三个可直接使用的模板：代码生成（指定语言、项目上下文、需求、风格指南、测试要求）、代码审查（包含七项检查清单和输出格式）以及调试助手（要求给出根因、修复 diff 和预防建议）。

在使用前，建议过一遍评估清单：角色是否定义、上下文是否提供、任务是否具体可衡量、约束是否明确、示例是否包含、输出格式是否指定、复杂任务是否要求步骤、边界情况是否提及。

迭代优化的循环也很直接：写提示 → 在 3-5 个样例上测试 → 分析失败 → 添加约束或示例 → 重复直到 90% 以上成功率 → 保存为模板。

这套方法论的核心观点是：把提示当作代码来管理——建立提示库、做版本控制、与团队共享。提示工程的本质，是清晰思考加上结构化表达。