完整题目
请详细介绍提示工程的主要方法和技术，并说明它们各自的应用场景和优缺点。
本文目录
答案要点
- 能系统分类提示工程方法（基础技巧、上下文学习、推理增强、Agent模式）
- 准确说明CoT/ToT/ReAct的核心机制与区别
- 能结合业务场景分析选型（简单任务vs复杂推理vs工具调用）
- 指出提示工程的局限性（上下文长度、稳定性、可扩展性）
一、基础提示技巧
Zero-shot / Few-shot
- Zero-shot：直接描述任务，适合简单明确的需求（如格式转换、简单分类）
- Few-shot：给2-5个示例，显著提升小模型表现和输出格式稳定性
- 优缺点：零成本低，但复杂任务效果有限；示例设计耗精力，且占用上下文
角色设定与约束
- 通过"你是一位专家..."设定风格，用"必须/禁止"明确约束
- 适合对输出语气、格式有明确要求的场景（如客服话术、营销文案）
二、推理增强方法
Chain-of-Thought (CoT)
- 在提示中加入"Let's think step by step"或示例推理过程
- 场景：数学计算、逻辑推理、多步骤决策
- 局限：简单任务可能过度思考，增加延迟和成本
Tree-of-Thoughts (ToT)
- 让模型生成多个候选思路，评估后选择最优路径
- 场景：创意写作、策略规划、需要探索的复杂问题
- 代价：需要多次采样，推理成本显著增加
三、Agent与工具增强
ReAct (Reasoning + Acting)
- 交替进行思考→行动→观察，直到完成任务
- 场景：需要调用外部工具（搜索、计算、数据库）的动态任务
- 小红书场景：结合笔记搜索API做个性化推荐，实时获取用户画像数据
Function Calling / 结构化输出
- 定义工具schema，让模型生成可解析的调用参数
- 是Agent落地的工程基础，保证与后端系统的可靠对接
四、高阶优化方向
| 方法 | 核心思想 | 适用阶段 |
|---|---|---|
| Prompt Tuning | 学习软提示向量，冻结模型 | 大量相似任务，需降低推理成本 |
| Auto-CoT | 自动聚类生成多样化推理示例 | 缺乏人工标注时提升Few-shot效果 |
选型建议
- 简单任务（分类、摘要）：Zero-shot + 清晰指令
- 复杂推理（数据分析、决策）：CoT/ToT，权衡效果与成本
- 工具集成（搜索、推荐）：ReAct + Function Calling，注意异常处理链
- 规模化部署：考虑Prompt Tuning或转向SFT降低推理成本
提示工程的优势是快速迭代、零训练成本，但天花板明显——当提示长度超过1k tokens或需要数百条规则时，应考虑SFT或RLHF。
换一种问法，检查是否真正理解
场景切入
假设你正在做一个客服系统，用户问“我的订单到哪了”，你直接调接口返回物流信息，效果还行。但如果用户问“为什么比预计晚一天”，你打算怎么设计Prompt让模型先查物流、再结合规则推理延迟原因，而不是瞎编？
层层追问
你觉得写好Prompt最关键的是哪几点？……那如果任务很复杂，比如让模型写一份市场分析报告，你会用什么技巧来提升推理质量？……这些技巧有副作用吗，比如成本或者稳定性问题？
直球架构
请系统性地介绍一下提示工程的主要方法，包括基础技巧、推理增强、Agent模式等，每个方法的应用场景和优缺点，以及在实际项目中你怎么根据任务复杂度选型。
练习口述回答 · 约4分钟
- 本质是问怎么跟大模型有效沟通
- 基础技巧：Zero-shot/Few-shot和角色设定
- 推理增强：CoT和ToT的适用边界
- Agent模式：ReAct和Function Calling落地
- 选型取舍与风险
这道题其实是在问，当你面对一个大模型时，怎么用提示词让它稳定、高效地完成你想要的输出。本质上，这是人和模型之间的沟通问题。我会从几个层次来讲：先是基础技巧，再是推理增强，然后是[[Agent]]模式，最后聊聊怎么选型和落地风险。
先说基础技巧。最简单的就是 [[Zero-shot]]，直接给指令，比如“把这段翻译成英文”。它适合特别明确、不需要额外示例的任务，比如格式转换、简单分类。但一旦任务复杂一点，效果就不稳定了。所以更常用的是 [[Few-shot]]，给两三个例子，模型就能模仿你的格式和思路，输出质量会明显提升，特别是小模型。不过代价是示例设计很耗精力，而且会占上下文长度。还有个常用的技巧是角色设定和约束，比如“你是一位资深客服，说话要礼貌但坚定”，或者“必须用JSON格式输出”。这对输出风格有要求的场景很管用，比如客服话术、营销文案。
接下来是推理增强。这里最核心的是 [[Chain-of-Thought]]，也就是让模型一步一步想。比如做数学题，你加一句“Let's think step by step”，它就能把中间步骤写出来，结果准确率大幅提升。但这里有个坑：简单任务上，CoT反而会过度思考，增加延迟和成本，说白了就是杀鸡用牛刀。所以我会区分场景，简单分类用Zero-shot，逻辑推理才上CoT。再进一步是 [[Tree-of-Thoughts]]，它让模型同时生成多个候选思路，然后评估选最优。适合创意写作、策略规划这类需要探索的问题。但代价很大，需要多次采样，推理成本高，所以我只在效果要求极高、预算又充裕的场景用。
然后是Agent模式。这块重点是 [[ReAct]]，也就是Reasoning + Acting。模型先思考要做什么，然后调用工具，观察结果，再继续思考，循环直到完成。比如在客服场景，用户问“我的订单怎么还没到”，模型可以思考“需要查物流状态”，然后调用查询API，拿到结果再回复。这里的关键是工具调用要可靠，所以 [[Function Calling]] 是工程基础，你要定义好工具schema，让模型生成可解析的参数。落地时有个常见失败场景：模型调用工具后，返回结果格式不对或者超时，链就断了。所以我会特别关注异常处理，比如加一个超时重试，或者让模型在失败时换一种方式思考。
最后聊选型。简单任务比如分类、摘要，用Zero-shot加清晰指令就够了。复杂推理比如数据分析、决策，用CoT或ToT，但要权衡效果和成本。如果涉及工具集成，比如搜索、推荐，那ReAct加Function Calling是标配。规模化部署时，如果提示长度经常超过1k tokens，或者规则特别多，我会考虑转向[[SFT]]或者 [[RLHF]]，因为提示工程的稳定性天花板很明显。
其实还有一个方向我最近在关注，就是 [[Self-Consistency]] 和多路径集成。CoT虽然好，但单次推理可能随机走偏，如果用多次采样再加投票，能显著提升可靠性，当然代价是推理成本翻倍。这块我觉得在金融、医疗等高容错场景很有价值，但怎么平衡成本和效果，还得看具体业务。
所以整体上，我更倾向把提示工程看成快速验证和轻量迭代的工具，它零训练成本，适合快速试错。但真要上线高并发、高稳定的系统，我会优先考虑SFT或者Agent框架，把提示词固化到模型里，减少运行时的不确定性。