企业官网建设流程全解析

搞提示词工程这两年，我最大的感受是：这活儿已经从“玄学”变成了硬技能。很多人以为提示词就是多打字、多客套两句，实际上它是有方法论、有调试流程甚至有版本管理的系统工程。“提示词工程”不是让人变得更会聊天，而是让大语言模型稳定地产出你想要的结果——这跟写代码、做流程设计本质上是一回事。

这篇东西适合谁？内容创作者、产品经理、运营、程序员，以及所有需要每天跟大模型打交道但又觉得“效果时好时坏”的人。我会把 10 个立刻能上手的技巧拆开揉碎讲清楚，每个都配“烂写法 vs 好写法”的对比，最后再给一套可以直接复制改用的提示词模板库。看完你至少能少踩一半的坑。

1. 把提示词当工程来做：先搞懂这 4 个底层逻辑

1.1 提示词不只是“说话”，而是“接口设计”

我见过太多人把提示词当成“跟 AI 聊天”，这恰恰是效果不稳定的根源。你想想，大模型本质上是一个函数：输入一段文本，输出一段文本。你输入的那段文本就是接口的入参，模型返回的就是返回值。既然是接口设计，就要考虑入参的格式、类型、边界条件和异常处理。

所以真正靠谱的提示词，不是一句“帮我写个方案”，而是“你是一个企业咨询顾问，请基于我提供的背景信息和数据，输出一份包含现状分析、问题诊断、改进建议三部分的方案，总字数控制在 1500 字以内，用 Markdown 格式编号输出”。前者是聊天，后者是接口调用。

把提示词当接口设计，你就能自然推导出后面所有技巧：要给字段（背景信息）、要给类型（输出格式）、要给约束（字数、风格）、要给示例（few-shot）。这不是过度设计，而是让模型从“自由发挥模式”切换到“定向交付模式”。

1.2 上下文窗口是稀缺资源：要有预算意识

大模型一次能“看到”的文本长度是有限的，这个上限叫上下文窗口。所有主流大模型的上下文窗口，从几千 token 到几十万 token 不等，其中最贵、最容易失控的就是把大量无关内容塞进上下文。

我经常跟团队说一句话：提示词里的每一个字都在花你两次钱，一次是输入费用，一次是注意力资源。因为模型在生成的时候需要处理整段上文，无关信息越多，它对关键指令的关注度就越低，这也是“越聊越飘”的常见原因。

工程化的做法是：把自己要提交给模型的内容分成两类。一类是“系统指令”，固定不变，定义了角色、任务、输出格式、边界规则；另一类是“用户输入”，每次动态变化，通常就是待处理的具体材料。系统指令要精简到不能再精简，用户输入也要先做裁剪，别把整篇 50 页的 PDF 一股脑丢进去而不做任何预处理。

1.3 模型是“高智商实习生”，不是“搜索引擎”

很多翻车现场，是因为用户把大模型当搜索引擎用，问一个事实性问题，然后抱怨它回答不准确。模型的语言能力和推理能力很强，但它对事实的忠实度完全取决于训练数据和上下文，它不是你肚子里的蛔虫，更不是你硬盘里的数据库。

我平时给非技术朋友打一个比方：大模型就像一个名校毕业但刚入职的实习生，智商很高、学习能力很强、能写出漂亮的文档，但他不了解你的业务背景、不知道你的审美偏好、也没见过你之前踩过的坑。你给他下达任务时，如果只丢一句“把这个项目整理一下”，他当然只能按自己理解瞎干。

所以提示词工程的核心能力，其实是“向下管理”的能力：把目标说清楚，把背景交代足，把标准定明确，把产出格式卡好。你越像一个人好经理，你的提示词效果就越好。反过来，你如果觉得“它怎么这么笨”，大概率是你自己的指令比它还模糊。

1.4 可复现性：没有模板的提示词等于没有工艺

写代码有版本控制，写提示词一样要有。很多人今天调出来一个不错的效果，明天换了措辞就废了，然后来回试，纯靠运气出活，这是非常危险的。提示词工程走到一定阶段，拼的不是灵感，而是可复现性。

怎么做？至少要做到三点。第一，提示词结构化：固定部分和可变部分分离，用占位符标出每次要替换的内容。第二，结果留档：每次调整后记录版本号、参数设置、输出示例和效果评价。第三，建立回归测试集：把你日常频率最高的 20 个任务沉淀成固定用例，每次改模板就跑一遍，观察有没有变差。

我在团队里经常说：如果你的提示词只活在你的聊天记录里，那它只是一个临时草稿；如果它被写成了带变量、带注释、带版本号的文档，它才算一个工程资产。这篇博文后面给的模板库，就是这套思路的产物。

2. 立刻能上手的 10 个技巧（上卷：提问结构与逻辑）

2.1 角色锚定法：先定视角，再谈内容

技巧一，角色锚定。这个技巧看起来简单，最容易被忽视，但实际效果非常显著。你要在提示词开头明确告诉模型它现在是什么角色，这个角色决定了它调用哪一类的知识和表达方式。

烂写法：

帮我看看这段代码有什么问题。

好写法：

你是一名有 10 年经验的 Python 后端工程师，最擅长代码审查和性能优化。请审查下面这段代码，按严重程度从高到低列出问题，每个问题给出具体的修改建议，最后给出一段优化后的完整代码示例。

角色不是随便挂个名字就完事，名字要配职责边界、经验范围和交付标准。你给它一个具体的角色画像，它就能调动对应领域的行话和判断标准；你只给一个模糊身份，它就给你模糊答案。进阶做法是给角色附加“性格倾向”或“风格要求”，比如“你是一个偏爱简洁、反对过度设计的工程师”，这种锚定对回答风格的影响很大。

2.2 任务拆解法：把复杂需求切成可执行小步

技巧二，任务拆解。如果你让模型一次性完成“分析这份行业报告并写一篇公众号文章”这种复合任务，它通常会顾此失彼：要么报告分析得浅，要么文章写得泛。这时候需要拆解，让模型一步一步走。

拆解有两种方式。第一种是“步骤展开式”，在提示词里明确列出步骤编号，要求模型按步骤输出中间结果。第二种是“迭代对话式”，先让它做第一步，拿到结果后再让它做第二步，每一步都基于上一步的真实输出。对于复杂任务，第二种往往效果更好，因为模型每一步的注意力都更集中。

举个例子。你让模型“做一个竞品分析报告”，它可能只给你几个泛泛的要点。你改成：

我们分三步完成任务，第一步：先从用户评价、功能对比、定价策略、市场定位四个维度拆解竞品的公开资料；第二步：基于第一步的拆解，提炼出竞品的 3 个核心优势和 2 个明显短板；第三步：基于前两步内容，输出一份结论明确的行动建议清单。

每一步的输出都更可控，最终质量自然更高。任务拆解的底层原理是降低单次推理复杂度，这和人类处理复杂工作时要列 checklist 是完全一样的逻辑。

2.3 Few-shot 示例法：给一个比讲十句更管用

技巧三，Few-shot 示例法，也叫少样本提示。人类学新东西最快的方式是看示范，大模型也差不多。你与其花一堆话描述你想要的输出格式和语气，不如直接给它一两个范例。

这里的关键是样本质量。你给模型的示例就是“金标准”，它会把它当作模仿的基准。所以，示例不仅要正确，还要能体现你想要的细节：比如你希望它用简洁短句，示例里就放短句；你希望它带数据和引用，示例里就带数据和引用。差的示例比没有示例更危险，因为它会引入错误模式。

来看一组对比。想让模型写产品卖点，烂写法是：

帮我写 3 条耳机卖点文案，要吸引人。

好写法的提示词大概长这样：

请参照下面的示例风格，为新产品“降噪耳机”写 3 条卖点文案。 示例 1：“地铁通勤再也不用调音量了，戴上它，世界安静到只剩下你的播客。” 示例 2：“不是所有耳机都叫降噪耳机，但戴上它的那一刻，你会有明显感知。” 要求：每条文案不超过 30 字，语气口语化，不提具体参数，突出使用场景。

示例给了模型锚点，风格就不会跑偏。多给一个示例还能进一步提高稳定性，一般 2～3 个足够，再多会占用上下文而且边际收益递减。

2.4 思维链（CoT）法：逼模型“算给我看”

技巧四，思维链提示（Chain-of-Thought）。这个技巧常用于需要推理、计算、逻辑判断的任务。核心做法是引导模型把推理过程一步一步写出来，而不是直接给结论。

为什么有效？大模型在直接出答案时，很容易跳跃到似是而非的结论；但如果要求它先写推理步骤，每一步的小错误更有可能被显性化，模型也会因此更谨慎。一句话口诀：不给结论，给过程；绕不过去，就分步。

基础用法是在提示词末尾加一句“请一步一步思考，并展示推理过程”。更稳的用法是把推理框架预先搭好，比如：

我们来逐步解决这个问题。第 1 步：列出已知条件；第 2 步：提出求解思路；第 3 步：执行计算并记录过程；第 4 步：基于计算结果给出最终结论。

不过这里有个现实提醒：现在不少模型的 API 已经内置了思维链能力，有时你不需要在提示词里反复强调。强硬的“请展示推理过程”在某些模型上会触发额外推理 token，增加延迟。我的经验是：先加一个温和的引导，观察输出质量；如果质量不够，再加显式步骤要求。思维链不是所有场景都必要，做简单分类、文案改写这类任务时就别滥用。

2.5 格式约束法：先定好格子再填内容

技巧五，格式约束。很多对接需求，不是内容不对，而是“格式丑”。如果让模型自由输出，它会给你五花八门的结构，后续解析和排版都是灾难。要提前声明输出格式，像画好格子再让模型填色。

常见的格式约束类型有：

• 列表类：用无序列表、有序列表或编号步骤输出。
• 表格类：用 Markdown 表格输出，规定列名。
• 结构化数据：要求输出 JSON、XML 或 YAML，用于程序直接解析。
• 长度类：限定字数、行数、段落数。
• 模板类：给出一个字段骨架，让模型按字段填充。

我这里最强调的还是结构化数据。如果你写程序需要调用大模型输出，尽量让它返回 JSON，并且在提示词里给一个 JSON 示例。这样你就能免去解析自然语言的一堆麻烦。

举一个实际提示词片段：

请把下面这段客户反馈，提取成 JSON 格式，字段如下：{"sentiment": "positive/neutral/negative", "issue_categories": ["..."], "summary": "..."}。仅输出 JSON，不要输出任何解释性文字。

加了“仅输出 JSON，不要输出任何解释性文字”这一句非常关键，否则它会在 JSON 前后给你加一段废话。这段时间我实测下来，格式约束配合结尾“不要输出任何其他内容”能大幅减少解析成本。

3. 立刻能上手的 10 个技巧（下卷：约束、迭代与环境）

3.1 负面提示法：明确告诉模型“不要做什么”

技巧六，负面提示。很多提示词只写了“要做什么”，没写“不要做什么”，结果就会收到一堆废话、套话和无关内容。负面提示的作用，就是给模型划定一条红线，把低质量输出直接挡在门外。

这里有个句式陷阱要注意：负面提示不要写得模棱两可。例如“不要啰嗦”“不要废话”这种说法太主观，模型很难把握底线。负面提示要尽量具体可执行，比如“不要输出任何开场白和结束语，直接给出正文”“不要使用‘首先、其次、最后’这类连接词”“不要在回答中提及‘这是一个很好的问题’这类套话”。

我常用的做法是，在提示词末尾加一段“输出规则”：

输出规则：1. 不要输出与任务无关的内容；2. 不要使用夸张的营销语气；3. 不要编造数据，所有引用数据必须以输入内容为准；4. 不要用“作为 AI 语言模型”这类表达。

这条规则加进来之后，很多烦人的“AI 腔”会明显减少。你可以配套一个“风格黑名单”持续迭代，把你不想要的表现形式加进去，时间久了这套负面提示就成了你自己的定制过滤器。

3.2 参数控制法：温度、top_p 等生成参数的实战取值

技巧七，参数控制。提示词只是输入的一半，生成参数是另一半。很多人完全忽略 API 里的参数设置，导致输出飘忽不定。实际上，温度（temperature）和 top_p 这两个参数，直接影响结果的随机性和创造性。

简单理解：温度越低，模型越保守，输出越倾向于高概率内容，适合事实类、总结类任务；温度越高，模型越发散，输出越多样化，适合创意写作、头脑风暴。我常用的取值范围如下：

如果实在不知道选什么，我的经验是：总结和提取类一律 0.2，创意和文案类用 0.7，别一上来就拉满。这里需要提醒的是，top_p 和 temperature 通常建议改一个就行，两个一起乱调容易互相干扰。绝大多数情况下，你只需要盯住 temperature 就能解决 80% 的稳定问题。

3.3 语境补全法：用 5W1H 喂饱上下文

技巧八，语境补全。模型对任务的理解，很大程度上取决于你提供了多少有效背景信息。很多人写提示词时默认模型“什么都知道”，结果模型只能依赖训练数据里的大路货来回答。

我推荐一个快速自查框架：5W1H——Who、What、When、Where、Why、How。写提示词之前，把这六个问题过一遍，凡是和任务相关的背景，都在上下文里说清楚。

举一个对比。烂写法是“帮我写一封商务邮件”。好写法是：

给我写一封商务邮件。发件人：我的公司“某某科技”，收件人：一位潜在客户王总，背景是上周展会他来过我们展台，对我们的智能巡检系统很感兴趣。邮件目的是约一次线下演示，时间定在下周三或周四下午。语气要专业但不生硬，长度不超过 150 字，结尾附上我的联系方式：138xxxx。

你有没有发现，同一件事，后者几乎不可能失败。因为你把 Who（双方身份）、What（约演示）、Why（展会有过接触）、How（联系方式）全交代了。背景信息就是模型的“素材库”，素材库越足，生成内容越具体，也就越不可能空泛。

3.4 迭代追问法：多轮对话收敛出高质量结果

技巧九，迭代追问。这条在普通聊天中好像谁都会，但放到提示词工程里，很多人反而忘了。他们指望一次提示就能拿到最终成品，但对话式修复往往是成本最低的优化路径。

我写严肃内容的标准流程是“三遍法”：第一遍，让模型出初稿；第二遍，指出问题并让它修改（如“第二段论证不够充分，补充一组数据支撑”“开头太平，改成用场景切入”“压缩到 800 字以内”）；第三遍，针对细节逐句打磨，比如让它在关键句上给出三个备选表达。

迭代追问的技术要点，是每一次的反馈指令都必须具体。不要只说“修改一下”，而要说“把第一段和第三段的逻辑顺序调换，然后重写过渡句”。模型没有“改到满意为止”的内部标准，你的反馈就是它的优化目标。多轮追问配合前面的格式约束、负面提示，可以把一个 70 分的答案慢慢拉到 90 分以上。

3.5 模板变量法：把提示词写成可复用的工厂

技巧十，模板变量法。这算是前面所有技巧的“包装工艺”，也直接对应你看到的模板库。思路是：把提示词拆成固定部分和可变部分，固定部分是逻辑框架，可变部分用占位符表示，比如${目的}、${输入内容}、${输出格式}。

一个结构化模板示例：

你是一名 ${角色}。请基于以下背景完成一个任务：${任务描述}。输入内容如下：${输入内容}。要求以 ${输出格式} 格式输出，注意 ${约束条件}。

这样设计的好处有三个。第一，可复用：换掉变量，模板就能服务于新任务。第二，易调试：如果输出不理想，你能判断是逻辑框架的问题，还是变量内容的问题。第三，好协作：团队成员用同一套模板，就不怕每个人写出来的提示词五花八门。

更进一步，你还可以把模板和参数绑定成“配方”。比如“内容创作配方” = 角色锚定 + 风格示例 + 温度 0.7；“信息提取配方” = 格式约束 + 负面提示 + 温度 0.2。用配方思维来管理提示词，你很快就能搭出一套属于自己的“提示词工具箱”。

4. 模板库：10 个拿来即用的结构化模板

4.1 模板库使用说明

在贴模板之前，我先把用法说清楚。这套模板不是让你无脑复制的，而是给你一个修改起点。每个模板都用中括号[ ]标出需要替换的部分，替换之前想清楚三个问题：你要的角色是谁？你要的输出格式是什么？哪些约束条件是针对这次任务新加的？想清楚这三件事，模板改成自己的才不会变形。

另外，模板里的角色设定和约束条件，都是“参考值”。比如某些模型对新角色指令的遵循程度不同，如果你发现结果还是不如意，优先调整角色描述的详细程度，其次是增加示例，最后才去动温度参数。调参顺序别反过来，先结构后参数，效率最高。

4.2 内容创作类模板（3 个）

模板 1：小红书 / 社交平台种草文案

你是一名资深社交媒体内容编辑，擅长写有生活气息、不做作的种草文案。请根据我提供的产品信息，写 3 条不同侧重点的种草笔记。 产品信息：[产品名称、核心功能、目标人群、价格范围] 每条笔记要求：标题 20 字以内，正文 150 字以内，口语化，突出真实使用场景，不夸大功效，不自嗨式刷感叹号。 附加要求：在正文末尾加 3 个相关话题标签。

这个模板的核心价值在“不做作”和“真实使用场景”这两个约束上。很多人让 AI 写种草文，得到的是满屏几百个感叹号，就是因为没给负面提示。

模板 2：公众号 / 知乎长文提纲生成

你是一名深度内容策划，擅长把复杂话题拆解成有逻辑的干货文章。请围绕主题：[主题]，生成一份文章提纲。 要求：大纲包含 1 个主标题、5 个一级小标题、每个一级小标题下有 2～3 个二级要点；整体结构要兼顾“引入痛点—给出方法—案例佐证—总结行动”，每个要点后附一句话说明该部分的核心内容。 输出格式：用 Markdown 嵌套列表呈现。

长文提纲模板的坑在于，AI 经常会生成那种“全世界通用的空泛大纲”，比如“什么是 X”“为什么要 X”“怎么做好 X”。加了“痛点—方法—案例—行动”的结构约束之后，大纲才真正落地。

模板 3：视频口播脚本

你是一名短视频口播编剧，擅长用口语化表达抓住观众注意力。请写一个时长约 [60秒] 的口播脚本，主题是：[视频主题]。 脚本格式：前 10 秒为钩子（用一个冲突或反常识提问开场），中间 40 秒为内容干货（拆分 2 个核心要点），结尾 10 秒为行动号召。 语言要求：短句，多停顿，不要书面语，不要排比句，不要刻意押韵。 输出格式：按“开场 / 正文 / 结尾”三段展示，每段标注建议时长。

写口播脚本最忌讳书面化和铺陈太多。这里给了一个非常明确的时间轴和格式，模型就不容易写散。

4.3 办公效率类模板（3 个）

模板 4：会议纪要整理

你是一名高效项目助理，擅长从杂乱信息中提取关键结论。下面是一段会议录音转写文字，请将其整理为结构化会议纪要。 会议纪要格式：

1. 会议主题
2. 参会人员（如原文未提及，标注“未明确”）
3. 讨论事项清单（每条一句话概括）
4. 明确结论（如有多个结论，分条列出）
5. 待办事项（标注负责人和截止时间，如原文未提及，标注“待确认”）
6. 风险与阻塞项（如果没有，输出“无”） 输入文字：[粘贴转写内容] 要求：不要新增原文中没有的信息；不要修改原意；待办事项用“负责人—任务—截止时间”格式。

会议纪要模板的关键是“不要新增原文中没有的信息”，否则模型会不自觉脑补。

模板 5：商务邮件润色

你是一名商务写作专家，擅长把口语化内容改写成专业得体的商务邮件。请将下面的草稿润色成正式商务邮件。 草稿内容：[粘贴草稿] 要求：保留原意；语气专业但不冷漠；正文不超过 [150] 字；不要使用“希望您能理解”“感谢您的配合”等过于套路的表达；如果需要补充礼貌性收尾，只在结尾加一句。 输出格式：邮件主题一行，正文分段展示。

这个模板里“保留原意”和“不要套路表达”形成了双重压力，会让模型更谨慎地进行措辞优化，而不是随手给你套一堆模板句。

模板 6：周报 / 月报生成

你是一名项目管理助手，请根据我提供的工作内容素材，生成一份结构清晰的周报。 素材内容：[列出本周完成的事情、遇到的问题、下周计划，可以口语化、零散写] 周报格式：

1. 本周核心成果（不超过 3 条，每条带量化结果）
2. 本周问题与处理
3. 下周工作计划
4. 需要协调的资源（没有则写“无”） 要求：成果描述不要用“推动”“赋能”这类空词，尽量用动词 + 结果；语气客观，不夸大。

写周报模板，我用“动词 + 结果”这个约束来对抗 AI 腔。“赋能”“抓手”“闭环”这类词它太爱用了。

4.4 编程与数据类模板（2 个）

模板 7：代码审查（Code Review）

你是一名资深软件工程师，擅长代码审查。请审查下面这段代码： [粘贴代码] 语言 / 框架：[如 Python 3.11 / Flask] 审查要求：

1. 找出可能导致 bug 的问题，按严重程度分级；每类问题给出代码定位。
2. 指出可读性和可维护性问题，并给出重命名或结构优化建议。
3. 指出潜在的性能问题（如果存在），说明原因。
4. 最后给出一个“重点关注清单”，用 checklist 形式列出需要我人工复核的点。 输出格式：用 Markdown 表格展示问题清单，列包括“问题类型 / 位置 / 问题描述 / 建议修改”。

代码审查模板的独特之处，是要求模型最后给“人工复核清单”。因为模型可能漏判，这个清单能提醒你别盲目相信 AI 审查结果。

模板 8：SQL 查询生成

你是一名数据分析师，请根据表结构信息，为我的问题生成 SQL 查询。 表结构：[table_name]包含字段：[字段1] (类型), [字段2] (类型), ...需求描述：[用大白话描述你想从数据中看到什么] 要求：

1. 生成 SQL 语句前，先用一句话解释你的查询逻辑；
2. SQL 要兼容 [MySQL/PostgreSQL/其他]；
3. 如果需求有歧义，不要擅自假设，而是列出 2 个可能的解释并给出对应的 SQL；
4. 只输出 SQL 和简短说明，不要输出其他废话。

“列出 2 个可能的解释”这个要求特别实用，能逼模型在歧义场景下把判断显性化，避免它闭眼猜一个。

4.5 通用思考类模板（2 个）

模板 9：SWOT 分析

你是一名商业策略顾问，请针对以下对象进行 SWOT 分析： 对象描述：[项目 / 产品 / 公司背景，尽量提供具体信息，没有的标注“未知”] 要求：

1. 每个维度输出 3～5 条要点；
2. 每条要点必须说明判断依据，不得只给结论性短语；
3. 重点区分“内部可控因素”和“外部环境因素”；
4. 在 SWOT 基础上，额外给出 3 条可执行的行动建议。 输出格式：使用 Markdown 表格呈现。

很多 SWOT 模板产出全是“品牌知名度高”“市场潜力大”这种废话。加“判断依据”这一条，等于要求模型的每个结论都能溯源，泛泛而谈立刻少一大半。

模板 10：学习计划制定

你是一名学习教育顾问，请为我制定一份学习计划。 学习目标：[目标描述，例如“3 个月内能用 Python 做数据分析”] 目前水平：[例如“有编程基础但没系统学过”] 每周可用时间：[例如“工作日每晚 1 小时，周末 4 小时”] 截止日期：[日期] 要求：

1. 计划按周拆分，每周有明确主题和交付物；
2. 每阶段要有可自测的小项目或练习题；
3. 遇到瓶颈时给出备选调整方案；
4. 不要盲目堆学习资源，推荐的资源每条都要说明理由。 输出格式：按“阶段—时间—学习内容—产出物—自测方式”表格展示。

注意最后一句“推荐的资源每条都要说明理由”，这是对抗 AI 推荐一堆无关课程的有力武器。

5. 踩坑实录：提示词工程常见的 5 个问题与排查

5.1 问题一：角色设定失效，模型“出戏”

有时候你明明在提示词里设定了角色，模型还是用默认的“作为 AI 语言模型”口吻回答。我排查过几次，原因通常是角色描述写得太多太碎，被淹没在长上下文里。解决办法很简单：把角色设定放在提示词的第一句，然后用一个空行隔开；或者把它单独放进系统提示（system prompt）部分，而不是埋在用户消息中间。

另外，“出戏”也可能是模型自身偏好导致的。遇到这种情况，可以在负面提示里直接加一句“不要提及你是一个 AI 语言模型，不要使用‘作为 AI’这类表达”。多数模型会尊重这个明确指令。

5.2 问题二：输出格式“鬼打墙”

明明要求输出 JSON，模型却在 JSON 外面包了一圈 Markdown 代码块和解释文字；明明要求用表格，它却列出几个带竖线符号的乱行。这是格式约束最常见的故障，原因通常是你只说了“输出 JSON”，没告诉它“不要输出任何其他内容”。

我的排查顺序是：先在提示词结尾加“直接输出，不要任何解释”；如果还不行，就在负面提示里写“禁止使用 Markdown 代码块，禁止输出 JSON 以外的任何字符”；最后还可以在示例段加一个“期望输出示例”，让模型照着格式抄。三步走下来，99% 的格式问题都能解决。

5.3 问题三：越写越空洞，全是正确的废话

这类问题的典型表现是：输出内容语法正确、结构完整，但信息量趋近于零。比如你让模型分析竞品，它给你“竞品 A 技术实力强、B 营销做得好、C 性价比高”，每一项都是正确的废话。

问题根源通常是提示词里缺少“论据要求”和“边界条件”。我的修法是给模型加两个约束：一是“每条观点必须附上判断依据或示例”，二是“无法从上下文中获取的信息，明确标注‘信息不足’”。前者逼它把论点具象化，后者逼它承认不知道。用了这两个约束之后，答案质量明显提升，因为模型没法用泛泛的套话蒙混过关了。

5.4 问题四：多轮对话后“忘了”前面的指令

在迭代式修改中，模型经常会丢掉最初的系统指令，尤其是在中间几轮对话比较长、改动内容很多的情况下。它可能在第三轮以后开始自由发挥。

我的做法是：不要把所有历史对话都保留。如果任务比较复杂，我会在每轮修改时，把原始提示词重新带上，然后追加一句“请基于上面这条原始指令，并参考以下修改要求生成新版本”。这样做会让模型重新聚焦到系统目标上。如果模型支持上下文管理接口，更好的做法是始终把固定指令放在 system prompt 里，用户消息里只放“本次的修改要求 + 上一次输出”。

5.5 问题五：温度太高导致“一本正经胡说八道”

如果你发现答案文笔不错但事实错误很多，先别急着改提示词，去看一眼你的温度参数。我曾经为了追求文采把温度调到 0.9，结果让模型生成产品介绍时凭空多出了三个不存在的功能，差点闹出事故。

在事实类场景中，温度请保持在 0.2 以下。如果需要在事实基础上有一点表达变化，可以把 0.2 提到 0.3，但别突破 0.4。规律很简单：温度是火候，事实类任务要的是“煮鸡蛋”，定在低档就行；创意类任务才需要“爆炒”，温度可以拉高。

6. 几个让提示词真正“工程化”的落地心得

6.1 提示词版本管理：像管代码一样管你的模板

我踩过最大的坑，就是没有版本管理。某次调模板调出了很好的效果，但忘记记录改动项，后来又改了几轮，想回退却完全找不到之前的版本。从那以后，我的所有提示词模板都进了同一个文档仓库，每个模板头部都有一段元信息，记录：创建日期、适用模型、温度参数、最近修改人、修改原因。

如果你是个人使用，用备忘录或 Notion 都行；如果是团队协作，强烈建议用 Git 仓库或带版本历史的功能。别嫌麻烦，提示词这种东西，改动的“手感”非常重要，有版本记录你才能复现成功。

6.2 建立自己的“回归测试集”

回归测试这个说法来自软件开发，放到提示词工程里一样成立。做法很简单：找出你日常最高频的 15～20 个任务，给每个任务准备标准输入和期望输出，每次调整提示词后，把测试集跑一遍，看看有没有因为改了一个词导致其他任务的效果崩掉。

我自己的测试集里包含：总结一段 500 字新闻、从一段对话提取待办事项、生成 3 条小红书文案、把一段口语改写成商务邮件、分析一组简单数据并给出结论，等等。每次改完模板，花 20 分钟跑一遍，心里的底就稳了。这比临时抱佛脚发现问题要省心得多。

6.3 注意 token 成本和延迟：别让提示词越来越胖

工程化不仅要看效果，还要看成本。提示词写得越来越长，效果不一定更好，反而会在长上下文模型上显著增加延迟和费用。我的习惯是：一个模板在使用前先做“瘦身”，看看哪些背景信息是这次任务真正需要的，哪些是上次复制过来的残留。

这里有一个经验值：如果一段提示词超过 1500 字，你先别急着加更多规则，试试把它压缩成 800 字，很多情况下输出质量反而会提升，因为关键指令的密度变高了。提示词不是越长越好，而是信息密度越高越好。

6.4 最后的最后：把提示词当成你团队的“新人培训手册”

我有一个观点：提示词库做得好的团队，本质上是把团队的判断力和工作标准沉淀成了可执行文档。新同学接入的时候，不用你反复口头教，丢一堆模板给他，照着用就八九不离十。所以，每当你发现一条特别好用的提示词，别让它沉睡在聊天记录里，把它提炼成模板，写清楚适用场景和坑点，放进你的模板库。

这个习惯一旦养成，你会发现自己的效率在稳步提升，而不是每次都靠临场发挥调提示词。我自己的模板库现在已经有几十个分类，覆盖文案、编程、分析、沟通等场景，日常工作基本不慌。你从现在开始攒，半年后也会有自己的“私房模板库”。

我在实际使用中还有一个体会：提示词工程不是一次性的，它跟你的业务场景、使用的模型、团队协作方式都深度绑定。你今天掌握的方法，到了新的模型和新的场景里可能需要微调，但底层那套“角色—任务—格式—约束—迭代”的框架始终能用。把这套框架变成你自己的习惯，你就不需要再依赖别人给的模板了。