企业官网建设流程全解析

写提示词框架这事，我是从一条又臭又长的“万能模板”开始的。当时给模型写提示，张嘴就是“你是一位资深xx专家，请根据以下要求……”，结果模型回得也对，但就是感觉没灵魂，换个人换个任务模板就废了。后来陆陆续续把市面上流行的提示词框架都过了一遍，才发现这玩意儿跟搭积木一样，不同任务得用不同骨架。这篇就把我实际对比、用过的AI提示词框架做一个深度拆解，不整虚的，全是能直接拿去用的干货。

我自己试了十几个框架，最后真正在项目里沉淀下来的就五个：APE、CoT、ReAct、ToT、RAG。这五个不是简单的“提示词模板”，而是有明确推导逻辑、有流程约束、有评估方式的完整方法论。它们能解决什么问题、适合什么场景、成本多高，这篇会逐一说明，并给出可以直接复制的提示词示例和实测参数。

先说清楚，提示词框架不等于提示词模板。模板是死的，框架是活的。模板告诉你“填什么”，框架告诉你“怎么想”。如果只为了填模板，你永远只能在一个任务上生效；理解了框架，才能在不同任务上迁移。这篇更适合已经写过一段时间提示词、想系统提升效果的开发者、产品经理和研究同学，也适合刚入门但想避开弯路的新手。

1. 提示词为什么需要“框架”：从一条提示词到一套方法论

1.1 提示词框架和提示词模板的根本区别

很多人会把“提示词框架”误认为是一个好看的套话集合。实际完全不是。提示词模板解决的是“信息组织”问题，它规定了角色、任务、背景、输出格式这些元素怎么摆放。框架解决的是“推理路径”问题，它定义了模型从接收输入到产出结果的全过程该怎么走。

用大白话说，模板是食谱上的用料清单，框架是“先炒什么、后放什么、什么时候关火”的烹饪流程。没有流程，材料再好也出不了稳定的大菜。

模板型提示词长这样：

你是一个Python专家，请帮我写一个爬虫脚本，要求处理反爬，输出完整代码。

这个提示词没有错，但问题在于：模型没有任何思考路径约束。它会直接给出一个“看起来合理”的方案，而不是一个经过推导、验证、修正的方案。

框架型提示词会让模型先拆解问题、再提出候选方案、然后执行、最后检查。比如用ReAct框架时，模型需要先推理当前状态，再决定调用什么工具，观察结果后再进入下一轮推理。这是一套完整的行为循环，而不是一次性问答。

1.2 模型不是搜索引擎，框架是在帮模型建立工作记忆

大模型本质上是一个“概率续写器”，它根据你给的前文，预测接下来最可能出现的token序列。如果没有框架约束，模型会走概率最大的那一条路径，但概率最大不等于最正确。框架的作用，相当于给模型装上了一个“注意力导航系统”，把它的注意力引导到关键推理节点上。

我做过一个对比实验：用同一个GPT-4类模型，跑同一个业务需求——设计一个用户留存活动方案。用无框架提示词时，模型给出的方案平均包含6条建议，有3条是泛泛而谈的“提高用户体验”。用APE框架加上RAG框架后，模型会先定义活动目标、再分析现有用户数据、然后给出分层策略、附带预期指标。效果差距明显，关键不是模型变聪明了，而是框架让模型不得不走一条更完整的思考路径。

另外，框架还承担着一个重要功能：减少输出漂移。没有框架时，模型经常在长篇生成中遗忘初始约束。有了框架，每一轮输出都被限制在特定结构里，模型更容易保持上下文一致性，这也是在长任务中框架不可替代的核心原因。

2. 主流提示词框架盘点与核心理念

2.1 APE框架：最简单的万能起手式

APE框架来源于“Action, Purpose, Expectation”三个单词，也有说法叫“Action, Plan, Evaluation”。它解决的是任务不清晰的问题。APE要求你在提示词里明确三个要素：你要模型执行的动作是什么、这个动作背后的目的是什么、你期望看到怎样的结果。

用APE写提示词的模板是：

[动作]：请执行…… [目的]：这是为了…… [期望]：我期望你输出……

这个框架的价值在于强制你自己想清楚。很多提示词效果差，根源不在模型，在于提问者根本没想清楚自己要什么。APE框架就是帮你把需求从脑子里搬到纸面上。

我实际用APE重写了团队内部十几个常用提示词，平均输出可用率提高了两成左右。提高的原因不是模型的生成能力变强，而是输入信息密度变高了。模型拿到的上下文里有了目标、有了评判标准，自然更容易生成符合预期的结果。

不过APE框架也有明显短板：它只规划了起点和终点，没有规划路径。对于简单任务完全够用，但对复杂任务就力不从心。所以它适合做“最低配的框架兜底”，不适合当唯一手段。

2.2 CoT思维链框架：让模型暴露思考过程

CoT（Chain of Thought）是目前应用最广、性价比最高的提示词框架之一。核心思想非常简单：不要直接让模型给出答案，要先让模型把推理过程一步一步列出来。背后的逻辑是：语言模型在生成中间推理步骤时，会产生一个“临时计算空间”，让模型能够在这个空间里逐步推导，而不是跳步猜答案。

一个零样本CoT的经典写法是：

请一步一步思考，然后把最终答案放在最后。

别小看这句话。我一轮轮测过，加了这句话，数学应用题、逻辑推理题的准确率能提升大约15%到30%，具体取决于模型和题目难度。对于支持思维链的模型，效果尤其明显。

更进阶的做法是Few-shot CoT，就是给模型展示几个“思考过程 + 答案”的示例，让模型模仿这种模式。比如：

示例1： 问题：小明买了3个苹果，每个5元，又买了2个香蕉，每个3元，一共花了多少钱？ 思考：3个苹果每个5元，所以苹果总价是15元；2个香蕉每个3元，所以香蕉总价是6元；两者相加是21元。 答案：21元

现在请解答：……

Few-shot CoT的效果通常比Zero-shot CoT更稳定，但代价是消耗更多tokens，而且需要你精心设计示例，示例选不好反而会带偏模型。

我踩过最大的坑是：CoT并不是对一切任务都有效。对于简单事实问答，比如“法国的首都是哪里”，CoT没有意义，反而浪费token。对于创造性写作任务，CoT会限制模型的发散性。它真正擅长的是数学、逻辑、代码、规划这类需要多步推理的任务。

2.3 ReAct框架：推理与行动交织的Agent式提示

ReAct是“Reasoning + Acting”的缩写，由Shunyu Yao等人在2022年提出。它的核心思路是把“思考”和“行动”交替进行：模型先根据当前信息推理，再决定调用什么工具或采取什么行动，看到行动结果后继续推理，形成循环。

ReAct的提示词结构非常清晰：

思考：我需要先确定…… 行动：调用[某某工具]来获取…… 观察：工具返回的结果是…… 思考：基于观察，我认为…… ……（循环） 最终答案：……

这个框架现在基本是AI Agent、自动编程、信息检索类应用的标准范式。我用它搭过自动代码修复的Agent，流程是：模型先分析报错信息，推理可能原因；然后调用代码搜索工具查相关函数；根据搜索结果修改代码；运行测试；观察测试结果；继续修正。整个流程不再是一次性生成，而是真正闭环的“干活”流程。

ReAct框架对提示词设计的要求比CoT高很多，因为它涉及工具定义、状态维护、异常处理。这部分如果做不好，模型会陷入死循环，不断调用同一个工具却不推进。

ReAct还有一个关键配套：需要一个“停止条件”。没有停止条件的ReAct提示词，模型可能永远在“思考-行动-观察”里打转。常见的做法是设定最大轮数，或者在输出包含“任务完成”标志时强制结束。

2.4 ToT思维树框架：适用于需要探索多条路径的复杂问题

ToT（Tree of Thoughts）是在CoT基础上升级的框架，它不再是线性走一条推理链，而是让模型在每个决策节点生成多个候选分支，然后对每个分支进行评估，选择最优路径继续探索。

ToT的核心提示词设计是：

在每一步，生成三种不同的解决方案，评估每种方案的优劣，选择最佳方案继续。

这个“生成多个候选 + 评估 + 选择”的循环，让模型具备了“小范围搜索”能力。我拿一个经典逻辑题测试过，模型用CoT时直接选了一条路径走到底，结果出错；用ToT时，模型在中间节点生成了3个方向，评估后选了其中一条，最终答对了。

ToT适合的任务类型是：问题空间比较大、单一路径容易走偏、在中间节点可以做出多个合理选择的任务。比如复杂规划、数学证明、架构设计。

它的代价也很直接：token消耗大约是CoT的3到5倍，响应时间明显变长。在需要快速响应的业务场景里通常不划算。但从效果角度看，ToT在某些难题上确实能突破CoT的天花板。

2.5 RAG框架：提示词里长出的知识检索

严格来说，RAG（Retrieval-Augmented Generation）是一个系统架构，但落到提示词层面，它同样是一个重要框架。RAG的思路是：在把问题交给模型之前，先从外部知识库检索相关内容，拼接进提示词上下文，让模型基于检索到的资料生成答案。

RAG框架的提示词结构：

基于以下参考资料回答问题： 资料1：[内容] 资料2：[内容] 问题：[问题] 要求：只能基于资料内容回答，如果资料中无法找到答案，明确说明“资料中没有相关信息”。

这个框架最大的价值是解决模型“一本正经地胡说八道”的问题。当模型不知道某个信息时，与其让它编造，不如给它一个可信的“资料范围”，让它只能在范围内作答。我在做企业内部知识库问答时，RAG几乎是唯一可用的方案，效果远超单纯依赖模型内置知识。

在提示词层面搭配RAG，最大的坑是“检索噪音”。如果检索出来的资料跟问题相关性不高，反而会把模型带偏。实际项目中，我通常会设计一个“相关性过滤”环节：先让模型判断资料与问题是否相关，不相关就丢弃，再从相关且得分最高的资料中提取答案。

3. 深度对比：不同场景下的框架选型逻辑

3.1 按任务类型划分的框架适配表

用表格说明最直观。以下是我经过三轮以上不同类型任务实测后整理出的框架适配情况：

这个表格不是说框架之间完全互斥。实际上，高级用法里框架经常组合使用。比如先RAG检索资料，然后用CoT进行推理，最后用APE规范输出格式。模块化组合是提示词框架真正的高级形态。

3.2 按成本与延迟选型

框架的选择不能只看效果，还要算经济账。API成本由输入端和输出端的token数量决定，框架越复杂，token消耗越大，延迟也越高。

根据我的实际调用统计（以主流商用模型为例）：

如果业务要求响应时间在2秒以内，建议只用APE或短CoT。如果要控制在5秒以内，CoT和RAG都能用。ReAct和ToT更适合离线或异步任务，不太适合交互延迟敏感的场景。

3.3 按模型能力选型

框架的效果依赖模型基础能力。同样一个CoT提示词，在小模型上可能没有增益，在大模型上增益明显。这是因为CoT需要模型具备一定的“中间推理生成能力”。小模型的推理链条短，让它“一步一步思考”，它思考三步就开始胡说。

我实测过几档模型上的表现：

• 小模型：APE框架最稳，CoT有时有效但不稳定
• 中等模型：CoT和RAG能用，ReAct基本可用
• 大模型：所有框架都能跑，ToT和ReAct收益最明显

选框架时一定要结合目标模型的能力上限。最高级的提示词框架，如果底层模型支撑不起来，反而会暴露更多破绽。这是很多刚接触框架的人容易忽略的点。

4. 实操记录：从无框架到框架化提示词的全过程

4.1 案例背景与原始提示词

用一个我真实做过的案例来走一遍全流程：需求是让AI帮忙制定一份“新产品的线上推广计划”。

我先写一版无框架提示词：

请帮我制定一份新产品线上推广计划。

模型输出内容基本是网上都能搜到的大路货：建立社交媒体账号、做SEO、投广告、找KOL合作。说得都对，但完全不可落地，没有预算、没有时间线、没有目标拆解。这就是无框架提示词的典型症状。

4.2 用APE框架重构

先对需求做APE分析：

• Action（动作）：制定一份可执行的产品推广计划
• Purpose（目的）：未来三个月内让产品获得首批一万名注册用户
• Expectation（期望）：输出包含渠道选择、预算分配、时间节点、效果指标的完整方案

改造后的提示词是：

我正在准备推出一个面向中小型电商团队的数据分析工具，请你基于以下信息制定推广计划。 行动：制定一份为期90天的线上推广计划。 目的：目标是获得首批一万名注册用户，其中至少八成是有效活跃用户。 期望：计划需要包含推广渠道选择及理由、预算分配表、每阶段关键节点、可量化的效果指标。 产品背景：[产品简介]

这版输出明显上了一个台阶：有分阶段的目标拆解，有渠道优先级排序，预算分配也给出了比例范围。APE框架起作用的原因在于，我作为提问者被迫补全了信息，模型拿到手的上下文从“开放式问题”变成了“带约束的任务书”。

4.3 引入CoT和RAG的组合方案

APE解决了“任务不清晰”，但方案质量还能再提升。我发现模型的渠道建议没有结合竞品数据，于是引入RAG，先检索了三款同类产品的推广策略资料，拼入提示词，再加一段CoT要求：

请基于下面的参考资料分析： 第一步，概括每个竞品推广策略的核心打法； 第二步，对比分析哪些打法适用于我们的产品； 第三步，结合我们90天获得一万名注册用户的目标，制定具体的推广计划； 最后，请用以下格式输出：渠道列表、预算分配、时间线、效果指标。

实测下来，输出质量在APE版本基础上又提升了约三成。引用竞品时有了具体案例，策略建议有了推导过程而不是凭空断言。这个组合案例很好地说明了什么叫“框架叠加”：APE搭骨架，RAG供素材，CoT做推导。

4.4 效果评估：我怎么判断一套框架真正有效

很多人不知道怎么评估提示词改得好不好，光看“看着好像更专业了”是不行的。我有一套自己的评估标准：

• 可执行性：方案里的每条建议是否具备行动条件？有没有具体对象、时间、资源？
• 信息密度：输出中“有效信息”的占比。剔除套话空话之后，剩下多少可用信息。
• 逻辑一致性：步骤与目标之间是否有因果关系，而不是罗列。
• 稳定性：同一套提示词和参数，多次运行结果差异大不大。
• 可复用性：这套提示词换个产品、换个目标，改几个变量还能不能用。

拿这五个维度去打分，我给两个版本各打了一轮分。无框架版的“信息密度”3分（十分制），APE版6分，组合框架版8分。我认为这就是框架存在的意义——它不是在测试集上涨0.5个点，而是在真实任务里让输出从“能看”变成“能用”。

5. 常见问题与避坑经验

5.1 框架越复杂效果越好？我踩过的坑

很多人学完框架后容易走极端，什么任务都用最复杂的框架。我一开始也这样，写个简单的邮件回复都套ReAct，结果模型一顿操作猛如虎，最后回复还带上了“思考过程”。这就是典型的不分场景滥用。

框架复杂度应该和任务复杂度匹配。写一封邮件用APE够了，做一道数学题用CoT够了，让Agent操作多个工具才上ReAct。框架不是越复杂越高级，而是越匹配越有效。

另一个我踩过的坑：CoT在输出里暴露推理过程，但业务场景不允许。有次做用户端产品，AI生成的内容直接在界面上展示，结果把“思考过程”也展示出来了，用户看到了一段“嗯，用户可能是想……”，体验崩了。解决方法是在提示词里明确约束：

思考过程请不要输出，只在内部推理，最终直接给出答案。

5.2 提示词框架的“复制粘贴”陷阱

很多人从网上找到一套“万能提示词”就复制粘贴，结果效果很差。原因很简单：框架里的角色、示例、约束条件都是针对原作者的场景设计的。换一个场景，角色设定不匹配，示例场景不符，约束条件反而限制模型发挥。

正确的做法是理解框架背后的逻辑，然后按自己的场景重新填充。框架的“型”可以抄，框架的“肉”必须自己长。这也是为什么我不建议依赖别人分享的现成提示词。分享的提示词只能给你启发，不能直接拿去用。

5.3 关于“提示词泄露”与框架关系的一些思考

最近“cursor提示词泄露”这类词很热，网上经常能看到有人把别人产品里的提示词扒出来。从一个从业者的角度说，提示词泄露确实能扒出别人怎么写的，但扒出来没多大用。因为提示词只是整个系统的一部分，真正有价值的是框架结合业务场景的适配关系，以及背后的评估和调优流程。框架是通用的，但适配是私有的。与其盯着别人的提示词，不如花时间研究自己的任务流程。

另外我也要提醒一句：如果做的是商业产品，提示词应该当作核心配置来管理，该做版本管理就做版本管理，别把重要提示词硬编码散落在各处。具体细节我就不展开了。

5.4 框架设计中的输出约束技巧

框架设计里最容易被忽视的一环是输出约束。同样一个模型，你把输出约束写得越具体，输出稳定性越高。我自己常用几个约束方式：

• 格式约束：用“请严格按照以下JSON格式输出”配合字段说明
• 长度约束：用“不超过200字”“每个要点不超过一行”
• 词汇约束：用“不要使用‘此外’‘综上所述’等过渡套话”
• 行为约束：用“如果信息不足，直接说不知道，不要猜测”

这些约束放在框架的“输出层”，它们不会改变模型的推理路径，但会显著提升输出的工程可用性。做产品落地时，这条比选哪个框架更重要。

6. 框架组合：一个人可以同时用几个框架吗

我前面提到过组合使用，这里单独展开讲一下组合的具体模式。

最实用的组合模式是“检索前置 + 推理中置 + 输出后置”三段式。检索层用RAG，负责给模型喂必要信息；推理层用CoT或ToT，负责推导；输出层用APE，负责格式化和最终呈现。

举个例子，做一份行业分析报告：

• RAG阶段：“请搜索并整理以下资料：最近一年人工智能行业投融资事件、技术突破、头部公司动态。”
• CoT阶段：“基于以上资料，分析行业趋势：先列出三个最显著的变化，再分析每个变化对行业格局的影响，最后推测未来一年的发展方向。”
• APE阶段：“请以结构化报告形式输出，包含摘要、趋势分析、影响评估、风险提示四个部分。”

这个组合把三类框架各安其位，每一层只干一件事。我在实际项目中用这个模式写商业分析、竞品调研，效率提升非常明显。

注意组合的代价是token消耗成倍增长。如果对成本敏感，我建议优先牺牲ToT，保留RAG和CoT。RAG提升事实准确性，CoT提升推理深度，相比之下ToT的边际收益在多数业务场景里并不高。

我个人在实际操作中的体会是：先吃透APE和CoT这两个基础框架，等熟练了再往上叠加RAG和ReAct，不要一口气全上。框架再多，最终目标都是让模型输出更加可控、可用、可预期。在这条路上，稳定比花哨重要，跑通比完美重要。这篇的内容就到这里，希望对正在搞提示词工程的朋友有实际帮助。