企业官网建设流程全解析

提示词工程这件事，我一开始也以为是个"玄学"。调了半天提示词，模型该胡说还是胡说，该跑偏还是跑偏。直到我把参数调优、思维链、ReAct、APE 这几套东西系统地跑了一遍，才发现这里面其实有相当清晰的工程逻辑——它不是靠"感觉"去写提示词，而是靠一套可复现、可验证、可迭代的方法论在支撑。

这篇内容我想把自己从零搭建提示词工程体系的完整过程拆开讲。核心围绕四块：参数调优三件套（temperature、top_p、presence_penalty）到底怎么配、思维链（Chain-of-Thought）在什么场景下真正有用、ReAct 框架怎么让模型从"会说"变成"会做"、以及 APE（Automatic Prompt Engineering）这类自动优化思路怎么落地。适合已经用过一段时间大模型、但总觉得输出不稳定、想把这套东西真正工程化的朋友。如果你还在"复制别人的提示词模板"阶段，这篇能帮你建立自己的判断标准。

1. 参数调优三件套：temperature、top_p、presence_penalty 的真实作用边界

很多人把参数调优当成"调个温度就完事"，实际上这三个参数各管一段，混着调很容易互相打架。我踩过的第一个坑就是：temperature 调到 1.2 想让模型"更有创意"，结果输出开始出现语法错误和逻辑断裂。后来才明白，创意和失控之间那条线，不是靠单一参数能守住的。

1.1 temperature 到底在调什么：概率分布的"锐化"与"平滑"

temperature 的本质是对模型输出的概率分布做缩放。模型每一步预测下一个 token 时，会给出一个概率分布，temperature 就是在这个分布上做文章：

• temperature 趋近 0：分布被极度锐化，几乎总是选概率最高的那个 token，输出高度确定、可复现。
• temperature = 1：保持模型原始分布，不做额外干预。
• temperature > 1：分布被平滑，低概率 token 也有机会被选中，输出更"发散"。

我实测下来的一组经验值，可以直接参考：

关键心得：temperature 不是越高越"聪明"。它只是让输出更随机，不会提升模型的知识或推理能力。想要"更聪明"，得靠思维链和 ReAct，不是靠调温度。

1.2 top_p 与 temperature 的配合：别同时大幅调整

top_p（核采样）是另一种控制随机性的方式：它从累积概率达到 p 的最小 token 集合里采样。比如 top_p = 0.9，就是只从累积概率前 90% 的 token 里选。

这里有个非常容易踩的坑：temperature 和 top_p 不要同时大幅调整。它们作用机制不同但效果叠加，同时调会让输出行为变得难以预测。我的做法是：

• 优先固定 top_p = 1（即不启用核采样），只用 temperature 控制。
• 如果发现输出偶尔冒出特别离谱的 token，再把 top_p 降到 0.9 左右做"兜底裁剪"。
• 只有在需要精细控制多样性时，才考虑 temperature 和 top_p 联动，且每次只动一个。

提示：很多 API 文档建议"temperature 和 top_p 二选一调整"，这不是客套话，是实战经验。同时调两个，你很难判断到底是哪个参数导致了输出变化，调试会变成玄学。

1.3 presence_penalty 与 frequency_penalty：解决"复读机"问题

这两个参数管的是"重复"。模型有时候会陷入复读，反复说同一句话，尤其在长文本生成里。

• presence_penalty：惩罚"已经出现过的 token"，只要出现过就压一压，鼓励引入新话题。
• frequency_penalty：按 token 出现次数惩罚，出现越多压得越狠，抑制高频重复。

我的经验是：presence_penalty 适合"话题发散"场景（比如头脑风暴，希望模型别老围着一点转），frequency_penalty 适合"抑制口头禅"（比如模型老爱说"值得注意的是"）。两者一般设在 0 ~ 0.5 之间，超过 1 容易让输出变得生硬、不连贯。

一个具体的排查案例：我之前做一个产品描述生成，模型每段结尾都要加"总之，这款产品非常值得推荐"。把 frequency_penalty 设到 0.6 之后，这个口头禅基本消失，但再往上调到 1.0，句子开始变得支离破碎。所以这类惩罚参数，宁可小步调，不要一步到位。

2. 思维链不是万能药：CoT 的适用边界与失效场景

思维链（Chain-of-Thought）刚火的时候，我几乎给所有提示词都加了"让我们一步步思考"。结果发现，有些任务加了反而变差——模型开始编造不存在的推理步骤，最后得出一个看似有理实则错误的结论。这让我意识到，CoT 有它明确的适用边界。

2.1 CoT 真正生效的底层逻辑

CoT 之所以有效，核心在于它给了模型"中间计算空间"。大模型是逐 token 生成的，如果直接要求它输出最终答案，相当于让它一步到位完成复杂推理，中间没有草稿纸。而 CoT 强制模型把中间步骤写出来，这些步骤本身就成了后续推理的上下文，相当于给模型提供了"工作记忆"。

这解释了为什么 CoT 在以下任务里效果显著：

• 数学应用题（需要多步计算）
• 逻辑推理（需要排除多个可能性）
• 多约束条件规划（需要同时满足多个条件）

而在以下任务里，CoT 基本没用甚至有害：

• 简单事实检索（"法国首都是哪"不需要推理）
• 情感分类（直接判断比"一步步分析"更准）
• 格式转换（模型容易在"推理"里跑偏）

2.2 Zero-shot CoT 与 Few-shot CoT 的选择

Zero-shot CoT 就是那句著名的"Let's think step by step"，不需要给例子。它的优势是省 token、通用性强，劣势是推理路径不可控。

Few-shot CoT 是给几个带推理步骤的示例，让模型模仿。它的优势是推理路径可控、格式统一，劣势是费 token、示例质量要求高。

我的选择标准很简单：

• 任务简单、对推理路径没要求：用 Zero-shot CoT。
• 任务复杂、需要固定推理格式、要接入下游程序：用 Few-shot CoT。

举个实际例子，我做结构化信息抽取时，用 Few-shot CoT 给了三个示例，每个示例都展示"先识别实体类型 → 再判断关系 → 最后输出 JSON"的完整路径。这样模型输出的 JSON 格式稳定性从大概 70% 提升到了 95% 以上。而如果只加一句"一步步思考"，格式照样乱。

2.3 一个反直觉的发现：CoT 会放大幻觉

这是我在实际项目里踩的最大的坑。CoT 让模型"展示推理过程"，但模型并不保证推理过程是真实的——它会编造看起来合理的步骤。更麻烦的是，这些编造的步骤会让最终答案显得"有理有据"，反而更难被察觉。

应对方法有两个：

1. 要求模型标注不确定性：在提示词里明确"如果某一步你不确定，请标注'不确定'，不要编造"。
2. 对关键推理步骤做外部验证：不要让模型自己验证自己，用外部工具（计算器、检索）去核对中间结果。

注意：CoT 提升的是"推理的呈现质量"，不是"推理的正确性"。这两者经常被混淆。模型可能推理过程写得很漂亮，结论却是错的。

3. ReAct 框架：让模型从"会说"到"会做"的关键一跃

如果说 CoT 是让模型"想清楚再说"，那 ReAct（Reasoning + Acting）就是让模型"边想边做"。它的核心是把推理（Reasoning）和行动（Acting）交替进行：模型先推理当前该做什么，然后调用工具执行，观察结果，再推理下一步。这个循环让模型能处理需要外部信息的任务。

3.1 ReAct 的循环结构拆解

ReAct 的一个完整循环包含三步：

1. Thought（思考）：模型分析当前状态，决定下一步该做什么。
2. Action（行动）：模型选择一个工具并给出调用参数。
3. Observation（观察）：工具返回结果，作为下一轮思考的输入。

这个循环持续到模型认为可以给出最终答案为止。关键在于，Observation 必须是真实工具返回的，不能是模型编的。这是 ReAct 和纯 CoT 的本质区别——CoT 的中间步骤可能是幻觉，ReAct 的中间结果来自真实世界。

3.2 工具设计：ReAct 成败的关键

我做过一个需要查数据库的问答系统，一开始工具设计得很粗，就一个"query_database"接口，参数是自然语言。结果模型经常传一些数据库根本不认识的查询，循环几次就卡住了。

后来我把工具拆细：

• search_by_keyword(keyword)：按关键词检索
• get_record_by_id(id)：按 ID 精确获取
• list_recent_records(limit)：列出最近记录

工具拆细之后，模型的调用准确率大幅提升。原因是：工具的参数越具体、语义越明确，模型越不容易传错。自然语言参数看似灵活，实则给了模型太多自由发挥空间。

工具设计的三条经验：

• 工具名要动词开头、语义明确（search_、get_、list_）。
• 参数类型要具体（枚举、ID、关键词），避免"自然语言大参数"。
• 每个工具要有清晰的描述，说明什么时候用、什么时候不用。

3.3 ReAct 的循环终止与死循环防范

ReAct 最容易出的问题是死循环：模型反复调用同一个工具，拿到相同结果，却不知道怎么推进。我在实际项目里加了三道防线：

1. 最大循环次数限制：一般设 5 ~ 8 轮，超过就强制输出当前最优答案。
2. 重复调用检测：如果连续两轮调用相同工具且参数相同，提示模型"你刚才已经调用过，请换思路"。
3. 无进展检测：如果连续几轮 Observation 没有带来新信息，触发终止。

这三道防线加上之后，死循环基本消失。这里的心得是：ReAct 的鲁棒性不来自模型本身，而来自外层的工程约束。你不能指望模型自己意识到"我卡住了"，得靠代码去兜底。

3.4 ReAct 与 CoT 的组合使用

实际项目里，我很少单独用 ReAct 或 CoT，而是组合：外层用 ReAct 做工具调用循环，内层每一轮的 Thought 用 CoT 展开。这样既有外部工具的真实信息，又有充分的推理空间。

一个具体的提示词骨架大概长这样：

你是一个可以使用工具的助手。请按以下格式循环： Thought: [你的推理，说明下一步要做什么] Action: [工具名] Action Input: [工具参数] （系统会返回 Observation） 当你认为信息足够时，输出： Thought: 我已经有足够信息 Final Answer: [最终答案]

这个骨架看起来简单，但配合前面说的工具设计和循环约束，能撑起相当复杂的任务。

4. APE 自动提示词优化：把"手调"变成"可迭代"

手写提示词最大的问题是：改一版、测一版，全靠人肉对比。APE（Automatic Prompt Engineering）的思路是让模型自己生成候选提示词，然后用评估指标自动筛选。这套方法我一开始觉得"多此一举"，直到提示词数量多到几十个、每次改动都要回归测试时，才发现自动化是刚需。

4.1 APE 的基本流程

APE 的核心循环是：

1. 生成候选：给模型一个任务描述，让它生成 N 个不同的提示词候选。
2. 评估候选：用一批测试样本跑每个候选，计算准确率/格式合规率等指标。
3. 筛选迭代：保留高分候选，让模型基于它们生成新一批候选，重复几轮。

这个流程的关键在于评估集的质量。评估集必须能代表真实场景，否则优化出来的提示词只是"过拟合"到评估集上。

4.2 评估指标怎么定

不同任务的评估指标差别很大，我常用的几类：

我的经验是：先定一个"硬指标"（比如 JSON 解析成功率），再定一个"软指标"（比如内容质量）。硬指标用来快速筛掉明显不合格的候选，软指标用来在剩下的候选里做精细选择。

4.3 APE 的局限与人工介入点

APE 不是银弹。它有几个明显局限：

• 评估集偏差：评估集不能代表真实分布时，优化方向会跑偏。
• 指标不可完全量化：创意类任务很难用自动指标衡量。
• 候选同质化：模型生成的候选容易趋同，多样性不足。

所以我的做法是：APE 负责生成和初筛，人工负责终选和微调。让机器做它擅长的（批量生成、快速评估），让人做机器做不好的（判断微妙的质量差异、注入领域知识）。

一个实用技巧：在 APE 的生成阶段，故意要求模型生成"风格差异大"的候选（比如一个极简、一个详细、一个带示例），这样能扩大搜索空间，避免所有候选都长一个样。

5. 系统提示词工程与 Skill Agent 的边界：别把两件事混为一谈

最近经常看到有人把"系统提示词工程"和"Skill Agent"当成一回事，其实它们解决的是不同层面的问题。我在实际搭建 Agent 系统时，把这两者分得很清楚，混在一起会让架构变得混乱。

5.1 系统提示词管的是"人设与规则"

系统提示词（System Prompt）定义的是模型的角色、行为边界、输出规范。它回答的是"你是谁、你能做什么、你不能做什么、你该怎么表达"。比如：

• 角色定义："你是一个严谨的技术文档助手"
• 行为边界："不编造不存在的 API"
• 输出规范："所有代码块标注语言类型"

系统提示词是静态的、全局的，它在整个对话里都生效，不随任务变化。

5.2 Skill Agent 管的是"能力与流程"

Skill Agent 关注的是"完成某类任务需要哪些步骤、调用哪些工具、遵循什么流程"。它是动态的、任务级的。比如一个"数据查询 Agent"可能包含：解析查询意图 → 选择数据源 → 执行查询 → 格式化结果。

这两者的关系是：系统提示词提供"底座"，Skill Agent 在底座上运行具体能力。系统提示词说"你是一个严谨的助手"，Skill Agent 说"处理这个查询时，先做 A 再做 B"。

5.3 混用的典型症状与拆分方法

混用的典型症状是：系统提示词越写越长，塞进了大量任务流程细节，最后变得难以维护。我踩过这个坑，一个系统提示词写到 2000 多字，改一处影响一片。

拆分方法很简单：

• 把"角色、边界、通用规范"留在系统提示词。
• 把"任务流程、工具调用、步骤"抽到 Skill Agent 里。
• 系统提示词只保留对 Skill Agent 的"调度说明"。

拆完之后，系统提示词稳定在 300 字左右，各个 Skill Agent 独立维护，改动互不影响。这个结构清晰太多。

6. 从参数到框架：我踩过的坑与沉淀下来的检查清单

把前面这些串起来，其实提示词工程的核心不是"写一句神奇的提示词"，而是建立一套从参数到框架、从手调到自动化的完整体系。这里把我踩过的坑和沉淀下来的检查清单整理一下，都是真金白银换来的。

6.1 参数层面的三个高频错误

• 错误一：temperature 和 top_p 同时大幅调整。前面说过，这会让调试变成玄学。正确做法是固定一个、只调另一个。
• 错误二：用高 temperature 追求"聪明"。temperature 只影响随机性，不影响能力。要聪明靠 CoT 和 ReAct。
• 错误三：惩罚参数一步调到位。presence_penalty 和 frequency_penalty 要小步调，超过 1 容易让输出生硬。

6.2 框架层面的三个关键决策

• 决策一：什么时候用 CoT。需要多步推理、有中间计算空间时用；简单检索、分类不用。
• 决策二：什么时候用 ReAct。需要外部信息、需要调用工具时用；纯知识问答不用。
• 决策三：什么时候上 APE。提示词数量多、需要回归测试时用；单个提示词手调更快。

6.3 我常用的提示词自检清单

每次写完一个提示词，我会过一遍这个清单：

1. 角色定义是否清晰？模型知道"自己是谁"吗？
2. 输出格式是否明确？有没有给出格式示例？
3. 边界条件是否说明？遇到不确定的情况该怎么办？
4. 是否需要 CoT？如果需要，是 Zero-shot 还是 Few-shot？
5. 是否需要工具？如果需要，工具的参数是否足够具体？
6. 有没有防死循环、防幻觉的约束？
7. 评估指标是什么？怎么判断这版比上版好？

这个清单看起来啰嗦，但每次过一遍，能省下大量返工时间。

6.4 一个真实的迭代案例

最后分享一个我实际做过的迭代案例。任务是"从用户反馈里抽取产品问题并分类"。

第一版：直接让模型输出分类结果。准确率大概 60%，格式经常乱。

第二版：加了 Few-shot CoT，给了三个带推理步骤的示例。准确率到 80%，格式稳定了。

第三版：把分类体系拆成两级（先判断大类，再判断小类），每级单独推理。准确率到 88%。

第四版：加了 ReAct，让模型在不确定时调用"检索历史相似反馈"工具。准确率到 92%。

第五版：用 APE 批量生成候选提示词，自动评估筛选。在第四版基础上又提升了 2 个点，且找到了一个更简洁的提示词写法。

这个案例说明：提示词工程的提升是阶梯式的，每一版解决一个具体问题，不是一步到位。而且越往后，提升越依赖工程手段（工具、自动化），而不是单纯"把提示词写得更花哨"。

我个人在实际操作中的体会是：提示词工程最忌讳"凭感觉调"。每一次改动都应该有明确的假设（"我认为加上格式示例能提升合规率"）和可验证的指标（"合规率从 X 提升到 Y"）。没有假设和指标的调整，就是在碰运气。把这套方法论跑顺之后，你会发现提示词不再是玄学，而是一门可以积累、可以复用的工程手艺。