提示词工程实战：结构化模板与高频示例全拆解

很多人以为提示词就是"把需求和模型说清楚"，实际真正进了实战会发现，差之毫厘谬以千里。同一个任务，换个说法、加个约束、调整一下输出格式，结果可能完全不在一个档次。这篇是系列笔记的第四部分，专门把提示词示例拿出来逐一拆解，不讲虚的，直接给可复用的模板和对比分析，适用所有在用大语言模型做内容处理、数据解读、代码辅助或日常自动化的朋友。

1. 为什么"示例"才是提示词工程的真实练功房

看十篇理论不如亲手拆五个例子，这句话放在提示词工程里再合适不过。绝大部分人入门时都觉得提示词就是"把话说清楚"，结果一上手就发现，同样的意思换个说法，模型给出的东西质量完全不一样，这就是示例的作用——它不是让你抄，而是让你理解一套可迁移的设计模式。

我接手过不少内部工具的需求梳理工作，一开始的做法是给协作的同事发一份"提示词规范文档"，里面全是概念解释和原则说明，比如"要明确角色""要结构化输出""要控制长度"。结果反馈很真实：文档看完了，动手写还是不知道从哪写起。后来我把文档整个推翻，改成"示例驱动"的方式，每个场景配三五个完整示例，旁边标注设计思路和常见错误，效果立刻不一样。同事们不再问"角色怎么设定"这种抽象问题，而是直接改示例里的某个局部字段就能满足自己的需求。

这背后其实是一个很朴素的道理：大语言模型最擅长学习的是模式，人也是。 与其用抽象规则去教人写提示词，不如直接把"好例子长什么样"摆出来，让读者自己归纳总结。这也是我在写这个系列时坚持一个观点：示例不是补充材料，示例就是核心教学内容。

1.1 先分清三类提示词：指令型、角色型、结构化型

日常实际使用中，提示词大体可以归为三类，虽然界限不是绝对清晰，但分清类型对设计思路非常重要。

• 指令型：直接把要做的事情说清楚，不预设角色和风格。适合简单、定义明确的任务，比如"把下面这段话压缩到100字以内"。这类提示词的重心在于指令的精确度，要明确告诉模型做什么、以什么标准做、输出成什么样。
• 角色型：给模型设定一个身份或视角，让它从这个视角出发回应。适合需要专业知识、特定语言风格、特定立场表达的任务，比如"你是一名资深数据分析师，请从经营视角解读这份数据"。角色设定的价值在于让模型调用与该角色相关的知识背景和表达习惯，输出更贴近目标场景。
• 结构化型：将需求拆解成固定的信息块，比如角色、背景、任务、要求、输出格式，每个部分独立成字段。适合复杂任务、需要稳定复现的任务、以及需要在团队间共享和迭代的提示词。这也是我最推荐在正式工作中使用的类型。

三种类型不是互斥的，好的提示词经常是"角色+结构化"或"指令+结构化"的复合形态。关键看你的任务复杂度和稳定性要求。越复杂、越需要多次使用，越应该走结构化路线。

1.2 一个"好示例"的最低判断标准

拿一个示例在手里，怎么判断它到底好不好？我给身边同事分享过一个五条快速判断题，每次都能帮上忙：

1. 换个人来用，不需要额外解释，就能得到接近一致的结果——这是可复现性。
2. 同样的输入，跑三次，输出稳定，不会出现明显的风格漂移或内容跑偏——这是鲁棒性。
3. 需求发生变化时，改一行字就能适配，而不是推倒重写——这是可维护性。
4. 模型给出的结果基本不需要二次加工就能直接使用——这是可用性。
5. 提示词本身能看出来"为什么这样设计"，而不只是碰巧能用——这是可解释性。

写提示词本质上是在设计一个小型的人机协作协议。示例则是这种协议的具体呈现。带着这五条去审视每一个示例，你会发现很多看似能用的提示词其实还有明显的优化空间，比如约束不完整、边界不清晰、输出格式定义太松散等。

2. 结构化提示词的通用骨架：从零搭一个不会跑偏的模板

我自己在实战中大量使用的是结构化提示词，原因很简单：它最稳定、最可控，而且出了问题最容易被定位。结构化提示词并不是什么玄学，它就是把一段自然语言需求拆解成几个固定模块，让模型清楚知道"你是什么角色、面对什么背景、要干什么、按什么标准干、输出成什么样"。

这个骨架可以用在任何领域：写邮件、做总结、生成代码、做翻译、做表格解读…… 差别只在具体内容，不在框架本身。

2.1 角色设定：给模型一个明确的视角

角色设定的作用不是为了让模型"演"得像，而是为了激活它对应领域的知识组织方式。同样是分析一段产品需求，以"普通用户"视角和以"产品经理"视角拿到的分析重点完全不同。没有角色设定时，模型会默认取一个平均值，导致输出泛泛而谈。

举个例子，如果你说"帮我看看这段需求有什么问题"，模型可能会给出一个通用列表，比如"需求不够明确""缺少时间节点"这类正确的废话。但如果你说"你是一名有五年经验的产品经理，请从用户价值、技术可行性和商业收益三个维度分析这段需求的合理性"，输出质量会完全不同——模型会沿着你给定的分析框架去组织信息，而不是自己在空泛的话题空间里漫游。

角色设定的关键不是角色的头衔多响亮，而是你给它限定的分析维度。头衔负责调用知识背景，维度负责约束输出方向，两者缺一不可。

2.2 背景约束：控制信息的边界

背景信息是整个提示词里最容易被忽略的部分，很多人写提示词直接就是"帮我做XXX"，不给上下文，结果模型只能靠猜。背景约束的价值在于划出一条边界——哪些信息是相关的、哪些应该被纳入考虑、哪些应该被忽略。

好的背景描述通常包含三块内容：当前的状态或处境、已知的相关信息、需要特别关注的因素。比如一个简单的文案改写任务，如果你不说明"面向客户群体是中小企业的技术负责人，他们关注成本和稳定性，讨厌空话"这个背景，模型就只能凭借它对"文案"的平均理解来写，出来的东西大概率是万金油式的宣传腔，而不是针对特定受众的有力表达。

背景不是写得越多越好，关键是每条背景信息都要和输出质量直接相关。塞入无关背景反而会分散模型的注意力，甚至引入错误联想。写完后可以逐条问自己：删掉这条，结果会变差吗？如果不会，那就删掉。

2.3 任务拆解：把一个大需求切成模型能执行的动作

这是最重要的一个环节，也是新手和老手差距最明显的地方。一个复杂需求直接丢给模型，模型往往因为目标太模糊而输出一些结构松散、重点不清的内容。但如果你把它拆成几个明确的子任务，每个子任务的目标都清晰可检验，结果的稳定性会有质的提升。

举例来说，"帮我分析这份销售数据"是一个模糊任务，模型不知道你是要趋势分析、异常诊断、还是未来预测。但如果你写"先列出过去12个月的总销售额变化趋势，再指出销售额环比波动超过15%的月份，最后对波动最大的一个月给出三个可能的原因假设"，这个任务模型就能精准执行。

任务拆解还有一个额外的好处：当输出结果不对时，你可以一眼看出是哪个子任务的表述有问题，精准修改，而不是把整段提示词删掉重写。这种可定位性在实际迭代中太重要了，我将在最后一章用一个完整的案例演示这个过程。

2.4 输出规范：先约定格式，再约定内容

输出规范是提示词里性价比最高的一部分，也是很多人最不爱写的一部分。不少人只告诉模型"做什么"，却不告诉它"输出成什么样"。结果模型交出来的作业要么是洋洋洒洒一大篇，你需要自己提取关键信息；要么格式随心所欲，下一步自动化处理时根本没法解析。

输出规范可以从四个方面来设计：结构（分几段、每段讲什么）、格式（是否用列表、是否用表格、是否用代码块）、长度（总字数、每段字数、条目数量）、风格（正式/口语、客观/带观点）。一个完整的输出规范写下来可能比任务描述还长，但它在实际使用中的回报非常值得。

最直观的例子是我处理批量信息提取任务时，一开始让模型"提取这段文本里的关键信息"，结果每次输出的组织方式都不一样，后续根本没法定量分析。后来我把输出规范改成：

请以Markdown表格输出，每行一条信息，包含四列：信息类别、原文内容、判断依据、置信度。

模型输出马上稳定下来，后续处理也顺畅了。这就是先约定格式再约定内容的含义——格式是内容的地基，地基稳了，内容的质量才便于衡量。

2.5 完整对照示例：模糊提示词 vs 结构化提示词

空谈不如对照，直接看一个实际任务的两版写法。

任务需求：把一段产品更新日志改写成适合发给用户的通知。

模糊版提示词：

帮我把这段更新日志改一下，写得用户能看懂。

模型输出大概率是：把原文的术语换成更通俗的说法，加一些语气词，但整体结构还是技术日志的样子，不会分重点、不会强调用户收益，也不知道该用什么语气。

结构化版提示词：

code复制角色：你是一名用户运营专员，擅长把技术性内容翻译成用户能听懂、愿意看的文案。
背景：本期更新面向全体注册用户，用户多为非技术背景，关注功能对自己有什么实际帮助。通知将通过站内信推送，用户阅读时间约30秒。
任务：将更新日志改写成面向用户的版本，包含三个部分：
1. 本次更新最值得用户关注的一件事
2. 另外两项提升体验的次要更新
3. 一句话引导用户去体验新功能
输出规范：
- 总字数控制在150字以内
- 语气轻快但不轻浮，不滥用感叹号
- 不使用技术术语，必须使用术语时用通俗解释
- 每部分使用一个小标题，标题不超过10个字
- 最后一句是行动引导，格式为"现在就去体验：+ 功能名"

这个例子你可能已经感觉到了，后者输出质量完全不取决于"运气"，而是设计的结果。整个提示词没有一句多余的话，每一行都在约束模型的输出空间，把自由度留给模型创造具体措辞，把确定性掌握在自己手里。

这才是写提示词的正确姿势——你负责定义框架和标准，模型负责填充语言和创意。

3. 五个高频场景的完整示例与设计思路

通用骨架解决了"怎么搭结构"的问题，这一章给出五类我在工作中实际反复使用的高频场景完整示例。每个示例都会标注设计思路和容易犯的错，你可以直接改改字段用在项目里。

3.1 文本摘要类：从压缩信息到提取决策依据

文本摘要是最常见的任务之一，但大部分人的做法是"帮我总结一下这段文字"。问题在于"总结"这个动词太模糊，模型不知道你是要一句话概括，还是要带要点的详细摘要；不知道是要忠实于原文，还是可以加入判断。

我在给团队做信息汇总工具时用的摘要提示词是这样的：

code复制角色：你是一名信息整理助理，擅长从长文本中提取结构化要点。
背景：下面的文本是[A类资料]，阅读者是[需要快速决策的负责人]，每篇资料阅读时间不超过2分钟。
任务：提取文本中的核心信息，按以下框架输出：
1. 核心结论：用一句话概括文本最重要的信息
2. 关键论据：列出支撑核心结论的3条以内事实或数据，每条不超过20字
3. 行动建议：基于文本内容，给出1-2条具体行动建议，格式为"建议做XXX，因为XXX"
4. 待确认信息：列出文本中没有说清楚但对结论有影响的内容
输出规范：
- 不超过200字
- 禁止使用原文中不存在的信息
- 语言中性客观，不夸大不弱化

这个提示词的精髓在于第4部分——"待确认信息"。绝大多数摘要是封闭的，只把已有信息压缩一遍，但实际工作中真正有用的摘要是能够标出信息盲区的。加了这一项之后，工具的价值立刻不一样，阅读者不仅知道文本里有什么，还知道自己还不知道什么。

同样的任务，如果你只需要一句话概括，那就把任务部分改为"用不超过30字的一句话概括全文核心信息，直接输出，不要任何解释"。摘要的核心不是模板，而是你的信息粒度选择。

3.2 内容改写类：风格迁移与对象适配

改写任务比摘要更考验提示词设计，因为"改写"的目标空间非常大。同一段话，改成面向领导的汇报、面向客户的通知、面向新员工的教程，写法完全不同。如果你只写"帮我改得口语一点"，模型只能平均地"口语一点"。

我常用的改写提示词框架是这样的：

code复制角色：你是一名内容编辑，擅长根据受众特征调整文本的语言风格和信息组织方式。
背景：
- 原文受众：[原受众描述，如：技术团队内部]
- 目标受众：[目标受众描述，如：完全没有技术背景的业务方同事]
- 使用场景：[如：月度汇报邮件]
- 关键目标：[如：让受众快速了解版本更新带来的业务价值，并愿意配合后续推广动作]
任务：重写下面的文本，要求：
1. 信息优先级调整：把对目标受众最重要的信息放在最前
2. 术语转换：技术术语替换为业务语言，无法替换时用自然类比解释
3. 语气调整：符合使用场景的语气习惯
4. 保留核心事实：不得改变原文数字、日期、结论等事实性信息
输出规范：
- 输出与原文结构对应，并附一份"修改说明"，列出你做了哪些类型的调整及其原因

这里最后一条"修改说明"是我非常推荐的技巧。它不仅让你能核对改写是否忠于原文，还能让你和模型之间形成一个"反馈回路"——看到模型的修改说明后，你可以更精准地指出哪些调整方向是对的、哪些是过度发挥。相当于把模型思考过程的部分透明度还给了你。

3.3 数据解读类：让模型成为你的分析助手

很多团队手里有数据但缺解读，于是想用大模型直接分析表格。这个场景能不能用好，几乎完全取决于提示词里"分析框架"的定义。大模型不是统计软件，它不会主动做因果推断，你给它什么分析框架，它还给你什么分析深度。

以月度销售数据为例，我用的提示词框架是：

code复制角色：你是一名商业数据分析师，习惯从趋势、结构、异常三个角度快速定位问题。
背景：这是[某产品线]过去6个月的销售汇总数据，字段包括月份、销售额、订单量、客单价、新客户数。业务目标是提升收入，当前关注点是找出值得制定动作的机会点。
任务：
1. 趋势分析：描述整体走势，并指出2个以上明显的拐点月份
2. 结构分析：计算各指标之间的比例关系变化，指出哪个指标对销售额变化影响最大
3. 异常定位：找出数据中不符合整体趋势的月份，给出3个以内的可能原因假设
4. 行动建议：基于以上分析，给出2条具体、可执行的建议
输出规范：
- 每个部分使用独立小标题
- 数字必须带上单位和对比对象，例如"订单量较3月下降12%"
- 原因假设必须标注"待验证"，不得使用确定语气
- 总字数控制在400字以内

注意两个设计细节：任务里每条都指定了数量（2个拐点、3个假设、2条建议），输出规范里强制了"待验证"标识。前者是控制分析深度，防止模型泛泛列举一堆无关因素；后者是控制表达态度，防止模型把猜测说成事实。这两个细节恰好对应了数据解读类提示词的常见翻车点：信息过载和过度自信。

3.4 创意生成类：用限制条件倒逼高质量发散

创意生成看似不需要什么约束，毕竟要的是发散，但实际上发散也有方向差异。比如"帮我想几个产品口号"和"帮我想几个面向年轻用户、强调轻便感和社交属性、不超过8个字的产品口号"，后者输出的可用率要高得多。创意生成类的提示词设计逻辑是：用限制条件倒逼模型在特定空间里发散，而不是在无限空间里漫游。

我做过一个内部品牌素材库的生成工具，里面固定了一套创意发散的提示词框架：

code复制角色：你是一名创意策划，擅长在给定限制条件下生成风格明确、可直接执行的文案方案。
背景：
- 品牌调性：[如：简洁、专业、可信赖]
- 目标人群：[如：25-35岁职场人，关注效率工具]
- 使用场景：[如：社交媒体开场文案]
- 本次创意目标：[如：引发对效率提升的共鸣讨论]
任务：生成5条各有侧重的文案：
1. 一条强调功能价值
2. 一条强调情感共鸣
3. 一条使用反常识表述制造意外感
4. 一条使用具体场景描写让用户代入
5. 一条适合直接作为互动提问发布
输出规范：
- 每条文案不超过30字
- 每条附一行设计说明，解释这条文案试图引发什么反应
- 不得使用已被用滥的句式，含"让生活更美好"等泛化表达
- 语言克制，不用过度情绪化的标点或大写强调

很多人在创意任务里不敢加限制，总觉得限制会扼杀灵感。我的实际经验恰恰相反：合理的限制条件是在缩小模型的无效搜索空间，让它在有用的方向上去发散。 比如上面这个示例中"5条文案各有侧重"这个要求，本质上是逼着模型从不同角度去思考同一个主题，而不是给出5个换汤不换药的同类选项。这正是很多人抱怨"模型没创意"的真相——不是模型没有创意，是你没给它展示不同侧面的任务结构。

3.5 代码辅助类：把模糊需求变成可执行任务

用大模型辅助写代码是很多开发者的日常，但多数人把它当成"更懂行的搜索引擎"来用，输入的是"帮我写一个排序的函数"，得到的是教科书式的示例代码，还得自己改半天。真正有效的代码辅助提示词，是把需求、约束、验收标准一次性说清，让模型交出能直接进入迭代循环的结果。

我在一个自动化脚本项目中使用的代码辅助提示词框架如下：

code复制角色：你是一名资深Python开发工程师，擅长写结构清晰、边界完整的生产级代码。
背景：需要编写一个[脚本用途]脚本，运行环境是[版本信息]，输入数据来自[来源]，输出结果将用于[下游用途]。
任务：
1. 实现[核心功能点1：具体函数/行为描述]
2. 实现[核心功能点2]
3. 处理已知的边界情况：[列举具体边界条件]
4. 对关键逻辑添加中文注释
约束：
- 不使用[指定需要避免的依赖或写法]
- 函数命名遵循[命名规范]
- 错误处理方式：[如：捕获异常后记录日志并继续执行]
- 性能要求：[如：单次处理时间不超过XX秒]
输出规范：
- 直接输出完整代码，不附加说明
- 代码外另附一段"使用说明"，包括输入输出示例和一个运行验证命令

这个提示词里最有价值的是"输入输出示例"和"运行验证命令"这两项。它们不是写给人看的，而是让你在拿到代码后能以最低成本验证它是否可用。很多人在代码类提示词上吃亏，根本原因不是模型写得不对，而是你没给它"可验证"的目标，它自然就停在"看起来对"的阶段。把验收标准写进提示词，相当于在需求阶段就把测试用例想清楚了。

4. 提示词示例里的边界与防守性写法

实战中还有一个容易被忽略的维度：提示词不仅要"要什么"，还要明确"不要什么"。这一节讨论的防守性设计，属于提示词工程里虽然不性感但极其保命的部分，尤其当你的提示词要交给自动化流程反复调用时，边界写不写清楚，差别会以很难看的方式暴露出来。

4.1 为什么提示词里必须写"不要什么"

大模型默认状态下倾向于面面俱到、尽力满足用户的显性要求，但它对"你没提到的东西"没有任何意识。如果你只告诉它"要专业"，它可能输出大量术语堆砌的内容；你只告诉它"要简洁"，它可能为了简洁丢掉关键信息。

我经历过一个实际的教训：做一个自动生成产品介绍的工具，最初版提示词只写了"生成一段简洁的产品介绍"，结果模型每次都主动加一段"本产品采用先进的技术架构，为用户提供优质体验"这类废话，看起来没有错，但放在正式宣传场景里就显得空洞廉价。后来我在提示词里加了"不得使用任何在具体功能描述之外的评价性空话"这一条，输出质量立刻正常了。

"不要什么"的价值不是限制模型的创造力，而是告诉它你的审美边界在哪里。 模型没有天然的审美判断，你不给它边界，它会默认取一个语料库里的平均值。平均值在任何专业场景里都是不够用的。

4.2 防守性提示词的三个常用层次

在多次迭代之后，我把"不要什么"的写法归纳为三个层次，按优先级从高到低：

• 禁止性指令：直接声明禁止出现的行为或表达。适用于定义明确、危害清晰的禁区。写法如"不得编造数据""不得使用原文没有的信息""禁止使用感叹号"。这类指令最有效，建议放在输出规范里，而不是放在远处的背景描述里。
• 负面示例驱避：给出明确的反面参照物，让模型知道"这个方向不要走"。适用于审美类、风格类的模糊禁区。写法如"避免以下表达方式：不要写成'一站式解决方案'式的产品宣传腔；不要使用'赋能''抓手'这类空泛词汇"。
• 条件性防护：设定"如果出现XX情况，应该怎么做"的规则。适用于需要模型自行判断的灰色地带。写法如"如果原文中存在互相矛盾的数据，不要自行选择，请标注'数据冲突待确认'并保留引用原文"。

单个"不要什么"密度太高会干扰模型理解主线任务，所以我一般控制在提示词中最重要、最影响判断的3至5条以内。超过这个数量，说明你对输出空间的审美要求已经复杂到了应该重新审视任务拆分，而不是继续堆提示词。

4.3 对比示例：有防守与无防守的差异

直接用一组实质对照展示防守性带来的变化。任务是"给一篇文章写三条摘要式推荐语，用于社交媒体推广"。

无防守版提示词：

帮我写三条推荐语，推荐这篇文章。

模型倾向于输出那种充满兴奋感的推广文案，比如"不看后悔系列！""干货满满，强烈推荐！"等。这类输出不能说是错，但放在内容品牌调性偏冷静克制的账号上，就完全不合适。

加强防守版提示词：

code复制角色：你是一名内容和用户运营，深谙本账号的调性：理性、克制、有干货。
任务：为以下文章写三条推荐语，用于[平台名]发布。
输出规范：
- 每条不超过50字
- 每条突出一个具体亮点，不得使用"干货满满""不容错过"等泛化赞美
- 语气克制，不使用感叹号，不使用夸张修辞
- 如果文章中有数据或案例，必须优先采用具体事实，而不是抽象评价
- 三条推荐语的角度不得重复，分别侧重：核心观点、实用方法、案例价值

同样的任务，后者的三条推荐语会明显更像一个"了解自己在说什么"的人写的，而不是一个气氛组。防守性语句表面上是限制，实际上是把模型输出的审美方向拉回到你所处场景需要的坐标轴上。

5. 参数搭配：同一个提示词，四个参数决定输出质感

提示词文本本身的质量很重要，但它不是全部。同样的提示词，搭配不同的生成参数，输出结果也有很大差异。这组参数对大模型的输出质感起着调节作用，很多人写完提示词直接用默认参数，相当于拍完照不调色，当然也能看，但离"符合预期"总是差点意思。

5.1 温度：控制创造性的阀门

温度是最直观、也最值得理解的一个参数。它控制的是模型在生成每个词时选择的确定性。温度越低，模型越倾向于选择概率最高的词，输出更确定、更可重复；温度越高，模型更倾向于选择概率排名靠后的词，输出更多样、更有发散性。

不同场景的常见取值参考如下：

很多人不清楚的是，温度的高低会直接影响提示词里"输出规范"的执行力度。温度低时，输出格式的遵循度高，几乎不会出现结构错乱；温度高时，格式约束容易被打破，创新的冲动可能在某些词句上绕开你的格式要求。所以一个需要严格格式但又有创意成分的任务，温度设置在0.7左右通常比较平衡，同时可以在输出规范里对格式重复强调两次。

5.2 最大长度：不是越大越好

最大长度参数限制模型单次输出的token数量。这里最常见的错误是把它设得过大，以为"输出空间越大越好"。实际上，模型生成头重脚轻的现象很常见——较早生成的内容占据脉络优势，过长的输出空间容易让模型在某些部分展开过度，后段质量明显下降。

我会先预估一个"合格输出"应该有的长度范围，然后设置成上限比预估值多出10%到20%，同时靠输出规范中的长度约束更精确地控制输出规模。例如提示词里写了"总字数不超过200字"，最大长度设置成不低于800 token（中文大约对应400~700字）就基本够用了。如果你把最大长度设成4000 token，模型可能出于"充分利用空间"的倾向，在内容后面继续添凑，对稳定性并不是好事。

5.3 停止词与其他参数：容易被忽略但关键时刻救命

停止词是另一个容易被忽略的参数。它的作用是告诉模型"生成到这个标记就停下来"。在输出规范的末尾加上一个独特的结束标记，再把它填入停止词参数，可以避免模型在输出结尾处自作主张加一段总结或延伸内容。我常用""或将输出规范中明确约定的结束标记设为停止序列这样的做法。

批量任务中重复调用同样提示词时，把温度调低、停止词调稳，每条输出的稳定性会带来天壤之别的体验。写提示词组合时，把这几个参数当成整套方案的一部分，而不是独立的旋钮，这样调试效率会高很多。

5.4 参数与示例的联动：调试顺序建议

最后给一个实战调试顺序建议：先调提示词文本，再调参数，最后调防守性内容。 不要并行修改，也不要一上来就把参数拉到极端看效果。最让我受益的调试方法是：

1. 用各参数的接近中间值跑一版输出，拿到基准对比。
2. 判断输出问题属于语义理解类（任务表述不清楚）、表达能力类（风格、语气不达标）还是稳定性类（三次结果漂移大）。
3. 语义问题优先改任务和背景描述；表达问题优先改输出规范和角色设定；稳定性问题优先调温度和停止词。
4. 每次只改一处，跑两三轮对比后再动下一处。

这样做看起来慢，实际上反倒是收敛最快的。真正浪费时间的做法是每轮同时改好几个地方，输出变了也不知道是哪个改动起的作用。

6. 一个完整示例的迭代记录：从"能用"到"好用"

纸上得来终觉浅，这一章完整展示一个实际提示词的迭代全过程。这个示例是我在处理内部自动化周报时写的，需求非常具体：从项目成员提交的周报中提取重要进展、风险和下周计划，输出成固定格式的汇总文档。

6.1 第一版：一句话版，结果远不够实用

一开始我写的是最省事的版本：

帮我把这些周报汇总一下，提取重要信息。

模型输出了一份还说得过去的总结，但有两个明显问题：不同成员周报覆盖的维度（进展、风险、计划）完全没有被系统化保留，有的成员写了风险有的没写，汇总后缺失的那些信息直接被吞掉了；每条信息的归属人没有保留，后续无法追溯。

这个版本的教训是：当你没有为任务定义稳定的信息结构时，模型会自动按"平均印象"来组织输出，而这恰恰是你最不想看到的结果。

6.2 第二版：强制信息结构，稳定性上来了

第一版跑了两天之后，我把任务描述细化成明确的信息框架：

code复制任务：汇总以下周报，按成员归类，每位成员输出三部分：
1. 本周进展：最多3条，每条不超过20字
2. 风险与阻塞：如实保留，无风险则写"无"
3. 下周计划：最多3条，每条不超过20字
输出规范：
- 每位成员之间用分隔线隔开
- 每条进展/风险/计划后面用括号标注关联的具体项目名
- 不得遗漏任何成员

这版的输出稳定性有了质的提升，信息没有缺失了。但它的问题在于输出仍然只是"信息陈列"，领导层面需要的"整体判断"没人做——哪几个项目的风险需要重点关注、整体进度是否健康、下周资源是否需要协调。模型不会主动做这一步，因为提示词里没有给它这个授权和目标。

6.3 第三版：增加分析层，从汇总工具变成决策辅助

第三版在前面的信息框架基础上，增加了一个"整体判断"部分，放在汇总文档最前面：

code复制在输出信息汇总之前，先输出"整体判断"部分：
1. 本周最需要领导关注的1个事项，说明原因
2. 整体进度健康状况：使用"正常/关注/异常"三档判断，并给出一句理由
3. 跨项目协调建议：如发现多个项目依赖同一资源或同一时间节点，说明风险和备选方案

这版才是真正能进入日常工作流的版本。周报汇总从单纯的"信息压缩"变成了"信息压缩+结构化判断"，输出稳定、信息可追溯、且直接支持决策。这个版本在团队里用了很长时间，基本没有大改。

6.4 迭代复盘：三个阶段分别对应什么设计思路

把这次迭代的要点复盘一下，三个阶段非常典型：

这次迭代的完整链路也印证了我反复强调的一个观点：提示词设计不是一次性写出来的，而是跟着使用反馈一轮轮打磨出来的。第一版能用吗？能。但"能用"和"好用"之间隔着的是你对场景的理解深度、对输出信息结构的定义能力，以及对边界条件的把握意识。与其指望一步到位写出完美提示词，不如搭好一个可迭代的框架，然后快速跑几轮让问题自己浮出水面。

7. 从提示词出发，构建你自己的示例库

提示词示例看再多，不如自己在实战中积累一套属于自己的示例库。我越来越觉得，对每个深度使用大模型的人来说，提示词示例库就是这个时代的个人知识库，它的价值不在于收藏了多少别人的写法，而在于沉淀了多少你自己验证过有效、且知道你当时为什么这样设计的模板。

我的做法是维护一份纯文本分类记录，按"角色/任务类型"建条目，每条里存三个版本：最早能跑通的初版、解决某类问题后的改进版、以及当前最好用的版本，同时在旁边备注当时的改动动机。不要小看这两个字的备注——它才是让你下次能快速判断"这个示例适不适用新场景"的关键。

至少每周做一次快速复盘：本周有哪些任务是反复用同一种提示词完成的？有没有更好的写法？哪类提示词产出效果最差，是任务表述问题还是参数配对问题？把这些问题跑一遍，花费不到十分钟，但对提示词掌控能力的提升是日积月累的。这也是我目前自己坚持在做的事情。

最后想说的是，提示词工程本质上不是让你去研究模型的语言学，而是让模型体验你的逻辑学。你可以不背书任何算法原理，但不能不清楚自己的场景需要什么样的信息结构、表达边界和验证方式。把这些想明白了，一个又一个具体的提示词示例便能成为你和模型之间的高效协作协议。