提示词工程这件事，最近几乎是个人都在聊，但你真让他们拿一个复杂任务出来，还是只会往输入框里甩一句“帮我写个方案”，然后抱怨模型答得平庸。问题的根源很简单——大部分人把提示词当“咒语”使，而不是当“工程”做。这篇东西我想认真拆一下实战中最能提升效果的三个核心技巧：CO-STAR框架、思维链（CoT）和少样本提示。我尽量把每个技巧的原理、适用场景、具体写法、坑点都讲透，并且给出一套可以组合使用的完整方案。
先说结论：这三种技巧不是互相替代的关系，而是分别解决“任务理解不清”“推理过程太浅”“输出格式不稳”这三个不同层面的问题。真正的高手不会选其中一个用，而是根据任务类型把三者组合进一套提示词里。下面我一个个讲，最后再给一个可落地的完整模板。
1. 为什么提示词是工程而不是咒语
1.1 从“模型玄学”到“可控输出”的转变
你肯定经历过这种事：同一个问题，换个说法提问，模型给出的答案质量天差地别。有人把它归结为“看运气”，但我更愿意把它理解为——你还没有建立起对模型行为的预测能力。
大语言模型本质上是一个基于上下文进行概率生成的系统。它的输出风格、内容深度、格式规范度，全部受限于你给它的“上下文约束”。当你说“帮我写个文案”，模型能预测到的内容分布极广：可能是短句、可能是长文、可能是口语、可能是书面语。但当你说“你是一位有十年消费品行业经验的营销顾问，请为一家主打办公室场景的精品咖啡品牌撰写一篇小红书笔记，目标用户是25-35岁的城市白领，品牌调性强调温暖、治愈、专业。要求用第一人称口吻，正文控制在300字以内，结尾带3个话题标签”——这时候模型输出的内容分布已经被压缩到一个非常窄、非常符合你预期的范围里。
这个压缩过程，就是提示词工程的核心。你可以把它类比为给一个经验丰富但有点任性的实习生布置任务：你只说“写个报告”，他交上来的东西大概率不是你要的；你把背景、目标读者、格式要求、参考风格全部交代清楚，他交上来的东西就会基本靠谱。提示词工程的全部工作，就是把这个“交代清楚”的过程做到极致。
1.2 三个技巧到底在解决什么问题
我们先建立一张总览表，把三个技巧的定位理清楚：
| 技巧 | 核心解决“什么”问题 | 典型应用场景 | 底层机制 |
|---|---|---|---|
| CO-STAR | 任务理解与表达不完整 | 需要模型生成文档、方案、文案、分析报告等长内容 | 通过结构化信息输入，把隐含需求显式化 |
| 思维链 | 复杂推理步骤易出错 | 数学题、逻辑判断、多条件决策、代码排查 | 让模型把中间推理过程写出来，降低跳跃性错误 |
| 少样本提示 | 输出格式不稳定、风格不统一 | 信息抽取、格式转换、标准化问答、代码生成 | 用示例约束输出模式，让模型“照着抄” |
这张表我建议你先存着。后面的内容全部围绕它展开，你随时可以回来对照。
2. CO-STAR 框架：把模糊需求变成结构化指令
2.1 CO-STAR 的每个字母到底是什么意思
CO-STAR 是一个非常实用的提示词组织框架，它把一段高质量的提示词拆成了六个要素。最早看到这个框架时我以为是花架子，实际用了几次之后发现，它对“不会写提示词”的人来说简直是一份救命清单。
逐个拆解：
C（Context）——上下文背景。你要告诉模型“这件事发生的背景是什么”。背景信息越充分，模型越能给出贴合实际的答案。写背景的时候要注意相关性，无关背景不仅无益，反而会干扰模型对重点的把握。
O（Objective）——目标。一句话说清楚“你希望模型做什么”。这里最容易犯的错是把目标写成一段散文。目标应该是一个动词开头的短句，比如“撰写一份项目周报”或者“提取这三段文本中的所有公司名和职位”。
S（Style）——写作风格。这里说的是文体的风格。你可以指定“商业简报风格”“知乎科普风格”“小学五年级能读懂的说明文风格”，也可以直接让模型模仿某个领域的常见表达习惯。
T（Tone）——语气。风格管的是“长什么样”，语气管的是“情绪色彩”。严肃、幽默、温和、坚定、中立，这些属于语气范畴。我刚才举的咖啡品牌例子，风格是“小红书笔记”，语气是“温暖治愈”，这两个是分开的。
A（Audience）——受众。模型如果不知道你写给谁看，它会默认写给你自己看。明确受众之后，模型会自动调整词汇难度、信息密度和表达方式。给投资人的报告和给团队内部的技术文档，措辞完全不一样。
R（Response Format）——回复格式。这是很多人忽略但极其重要的一项。你要 JSON 就必须在提示词里写明输出 JSON，要 Markdown 表格就要写明用表格呈现，要控制在多少字以内就要给一个明确的量化约束。
注意：CO-STAR 不是“每次都要六个要素齐全”的教条，而是提醒你把该给的信息给到位。任务越复杂，六要素越要齐全；简单任务可以适当省略。
2.2 一个朴素需求的前后对比
我拿一个实际项目里的例子给你看。我最初帮某公司写一个员工入职指引的生成提示词，第一版是这么写的：
帮新员工写一份入职第一周的安排建议。模型的输出倒是很快，但内容非常泛化：“第一天熟悉环境、第二天了解业务……”这种正确的废话。后来我用 CO-STAR 重写：
C：该员工入职的是某互联网公司产品经理岗位，部门人数约20人，团队主要负责后台系统的需求迭代和数据分析平台建设。入职第一周恰逢季度末，团队正在推进两个重点项目。 O：撰写一份详细的入职第一周每日安排建议，需具体到每天的工作任务和对应预期产出。 S：使用企业内部工作文档的正式、简洁风格，以日期为单位分段组织内容。 T：语气专业、积极，避免过度热情或官腔。 A：新入职的产品经理，刚毕业一年，对内部工具链和协作流程不熟悉。 R：按周一至周五分五段输出，每段包含上午安排、下午安排和当天预期产出三项内容；总字数600字以内。同样的任务，模型给出的第一周计划里有“周五下午参加 A 项目的复盘会，并同步阅读业务方反馈文档，为下周一的需求评审做输入”——这个细节在第一版里根本不可能出现。差距的来源就是：你把背景交代得越清楚，模型能在正确方向上发挥的空间就越大。CO-STAR 框架的价值，不在于给你一种固定的“句式”，而在于逼你把那些你以为“模型应该知道”但模型其实并不知道的信息补全。
2.3 CO-STAR 的适用边界
CO-STAR 不是万能灵药。它最适合那些“模型已经具备了相关能力，但需要你讲清楚产出标准”的内容生成类任务。一旦任务本身超出现有模型能力范围，比如让模型做深度的代码架构设计或者复杂的数学证明，CO-STAR 只能保证输出格式好看，无法保证内容是对的。另外还有一个小坑：背景给了太多，模型反而会挑选其中某一部分信息过度发挥，弱化真正的目标。我的经验是，背景信息的量以“能让一个聪明但不知情的人听懂你做的事”为标准即可。
3. 思维链（Chain of Thought）：逼模型“把过程摆出来”
3.1 为什么直接问正确答案经常翻车
我做一个简单的测试，你感受一下。直接问模型：
一个停车场有80辆车，其中70%是轿车，其余是SUV。如果轿车中有25%是红色的，问：红色的轿车有多少辆？模型可能会直接输出“140辆”这种离谱答案。为什么？因为它跳过了中间步骤，试图直接“猜”出最终数字。大语言模型在做复杂数学推理时，本质上是在做“根据上文预测下文”的任务。如果上文只包含问题本身，中间推理过程完全空白，模型每一步预测的难度都会急剧上升，错误概率自然跟着涨。
思维链的解法非常朴素：让模型在给出最终答案之前，先把推理过程一步步写出来。这一步操作在提示词层面做起来很容易，但背后的原理很值得说一下——当你要求模型“请逐步计算”或“让我们一步一步思考”时，你实际上把它的工作方式从“一步预测答案”转变成了“多步预测推理过程 + 最后一步预测答案”。每一步预测都在较短的语义跨度上进行，错误概率被均摊开了，最终答案的稳定性就会显著提升。
3.2 零样本思维链与少样本思维链
思维链提示有两种常用形态。
零样本思维链（Zero-shot CoT）的实现方式很简单：在问题后面加上那句被用烂了但仍然很有效的话——“请一步步思考，并输出你的推理过程”。为什么有效？因为这句指令把模型的输出分布从“直接给答案”压向了“先给过程”。注意，这里有个小技巧：如果你只想要推理过程辅助自己判断，不想要繁冗的解释，可以加一句“每一步简洁描述，控制在20字以内”。如果没有这个约束，模型会在简单问题上写出一大段论证，token 消耗成倍增加。
少样本思维链（Few-shot CoT）则是给模型提供一两个带详细推理过程的示例，让它“照葫芦画瓢”。两者的取舍很清晰：零样本思维链适合任务不太难、但你希望获得一定稳定性提升的场景；少样本思维链适合你发现模型的推理过程“风格不对”或者说“分不清哪里要展开、哪里要跳过”的场景。你可以用示例告诉模型：推理到哪一步就可以停了，哪一步需要展开计算。
我自己用得比较多的是少样本思维链，因为它的可控性最好。比如做项目排期估算时，我会在提示词里给出一个完整的示例：
示例任务：某功能开发预估需要4天，其中前端开发占2天，后端开发占1.5天，联调测试占0.5天，前端开发已经进行了一天，请问还需要几天完成？ 示例推理过程： 第一步：前端开发总共需要2天，已经进行了1天，剩余前端开发时间=2-1=1天； 第二步：后端开发和联调测试还未开始，对应时间=1.5+0.5=2天； 第三步：总剩余时间=1+2=3天。 最终答案：3天。然后让模型用同样的方式处理真实任务。实测下来，这种带推理示范的例子，比单纯说“请一步步思考”更能控制模型推理过程的组织方式。
3.3 思维链的隐藏成本与过度使用问题
思维链不是免费的。它最直接的代价是 token 消耗变大，因为模型必须生成一段推理过程。在一些低难度任务里，比如“判断某句话的情感是正向还是负向”这种不需要复杂推理的活，强行让模型输出推理过程，不仅慢，还可能在简单的任务上“过度思考”，反而把本来对的答案改错。
另一个需要注意的坑是：当你在提示词里用了少样本思维链，示例中的推理链条不能太短。如果例子太简陋，模型会学着一个“草率推理就下结论”的习惯。示例中的推理过程应当完整覆盖任务的核心思考环节，至少包含三步，每一步都有实际的计算、判断或引用原文的动作，而不是干巴巴地写“因此答案是X”。
实操心得：判断一个任务是否需要思维链，可以先用零样本直接问一句，再用零样本思维链问一句，对比两次结果。如果第一次答案就很稳，就不需要思维链；如果第一次经常出错，再引入思维链。不要一上来就无脑加“请一步步思考”。
4. 少样本提示：用高质量示例“锁定”模型的输出模式
4.1 为什么两个例子胜过十句规则
你想让模型输出一个固定的结构，比如从客户评论中提取“产品名、问题类别、紧急程度”三个字段并生成 JSON。如果你只是在提示词里写“请提取三个字段并输出 JSON”，模型的输出大概率会出现字段名不一致、JSON 格式破损、值为空串时没有处理逻辑等问题。你会发现自己在这个任务上花了几十轮对话来“调教”输出格式，效果依然不稳定。
这时少样本提示的效果就体现出来了。你只需要在提示词里放两个写好的例子：
示例1： 评论：收到的蓝牙耳机左耳充不进电，用了不到一周就这样，想要换货。 输出：{"product": "蓝牙耳机", "issue_type": "充电故障", "urgency": "高"} 示例2： 评论：手表表带的扣子松了，其实也不影响用，但有其它颜色可以换吗？ 输出：{"product": "智能手表", "issue_type": "配件问题", "urgency": "低"}只加了这两个例子，模型就会自动严格遵守同样的 JSON 结构和字段标准。这是因为模型在上下文里学到的最直观的规律，不是你的文字规则，而是示例中隐含的格式模式。文字规则是“抽象的指令”，需要模型再做一层转译；而示例是“具体的模式”，模型可以通过模仿直接命中。
4.2 设计少样本示例的四个原则
我见过太多人往提示词里丢例子，但效果不好，原因基本都出在以下四个原则的违反上。
第一，示例与目标任务同分布。你的示例必须能代表真实任务中你可能遇到的“输入特征组合”。如果你的真实任务里客户评论会包含大量错别字和口语化表述，那示例里也应当有这类输入，而不是干干净净的书面语。
第二，示例要覆盖边界情况。与其给模型两个“最典型”例子，不如给一个典型例子加一个容易出错的特例。比如同样是提取字段任务，第二个示例专门演示“问题不严重且需求模糊”这种情况，模型就能学会处理非典型的输入。
第三，示例的格式必须全局一致。如果你在示例里用了中文冒号，那么目标输出里也必须保持一致。模型对格式的敏感度非常高，一个不一致就可能让它混乱。
第四，示例输出的字段名不能有歧义。你希望模型输出 issue_type 还是 issueType？是 urgency 还是 level？这些必须在示例里统一锁定。后续代码处理 JSON 时，字段名不一致是最讨厌的坑。
4.3 示例数量应该给几个？
这个问题没有固定答案，但我可以提供一组实测经验。在绝大多数文本提取和格式转换任务中，2~5个示例的效果提升最为明显，再往上加，效果提升曲线会迅速变平。示例数量过多反而有两个副作用：一是消耗大量 token 挤占了其他指令的空间，二是示例之间的冲突会让模型无所适从。比如你给了5个示例，其中3个用“高/中/低”表示紧急程度，另外2个用数字“1/2/3”，模型就会在两种格式之间摇摆。
所以我的建议是：先用2个高质量示例跑一轮，观察输出稳定性；如果发现在某些边界输入上仍然容易出错，再针对性添加1个覆盖该边界的示例。控制示例数量在5个以内。
5. 组合实战：在同一个真实任务里把三个技巧串起来
5.1 组合策略的优先级判断
到现在为止，我们讲了三个独立技巧。实战中你真正需要的能力是给一个任务“开对药方”。我把任务分成三类给出优先级建议：
内容创作与写作类任务，优先用 CO-STAR 把背景、受众、格式交代清楚；如果模型输出的内容过于空泛或缺少逻辑层次，再叠加思维链让它先输出提纲再展开。
数据分析、计算、推理类任务，优先用思维链让模型展示过程；如果模型在推理过程中经常跳步或格式混乱，再叠加少样本示例固定推理书写的风格。
信息抽取、格式转换类任务，优先用少样本示例锁定输出格式；如果任务本身还对抽取逻辑有复杂要求，再考虑在示例前加一句推理指令。
说起来简单，但真正操作时有一种很常见的情况：任务本身是复合型的。比如“从一堆邮件里识别需要今天回复的重要邮件，并起草回复”。这里面既有判断推理（该不该今天回），又有内容创作（回复草稿）。我会把提示词拆成两段：第一段用少样本+思维链实现过滤与判断，第二段用 CO-STAR 风格约束实现回复起草。把任务拆开再分别匹配技巧，比用一个复杂提示词硬控模型高效得多。
5.2 一个完整提示词模板的现场拆解
下面这个模板是我实际在“生成项目周报”这个小工具里用过的，你直接抄去改一改就能用在很多场景。
你是一位具有多年互联网行业经验的项目管理顾问。 C：背景信息如下——项目名称是“交易后台重构”，当前处于开发中期。本周完成的任务包括：清算对账模块开发完成并进入自测阶段、权限管理接口文档已评审通过。风险项是：第三方支付渠道的回调联调环境尚未搭建完成，可能影响下周的联调进度。团队成员共6人，前端2人、后端3人、测试1人。 O：请撰写一份项目周报，内容需覆盖本周进展、风险与应对措施、下周计划三部分。 S：使用企业内部周报的标准结构，行文简洁，分点说明。 T：语气务实、客观，不夸大进展，也不回避风险。 A：阅读者是项目委员会成员，他们关注进度偏差、风险和资源协调，不需要了解技术实现细节。 R：输出三部分内容，每一部分用5条以内的短句列举，总字数控制在500字以内。 请先列出你对任务要求的理解，然后对照背景信息逐步组织内容，最后输出周报并确保格式符合要求。最后那句话是关键——它融合了“思维链”和“自我检查”两种机制。模型需要先“列出理解”，相当于把 CO-STAR 里的重点信息复述了一遍，这个复述过程能帮助模型确认自己没跑偏。然后“对照背景信息逐步组织内容”，则是深度思考后的规范化输出。这一套下来，周报的质量和对需求的贴合程度，远超直接甩一句“帮我写周报”。
5.3 混用时的优先级与权重原则
到了这儿我得给你提个醒：CO-STAR、思维链、少样本组合使用，不是“把三份提示词拼接在一起”。塞得太多，模型反而抓不住重点。
我给组合提示词设置三层权重：
第一层是“核心任务指令”，也就是 CO-STAR 里最关键的 C 和 O，表述需要最详细。第二层是“输出约束”，也就是 A、R 和 Style 的部分，确保人话能懂、格式能解析。第三层才是“推理引导和示例”，它的作用是微调模型的处理方式，作用在于“告知如何产出”，而不是“告知产出什么”。
在提示词的物理顺序上，我的习惯是先写角色与背景（C），再写目标（O），然后是风格和受众（S/A），最后写回复格式和推理指令（R+CoT），示例放在最末位置作为输出的参照物。这个顺序符合模型对上下文的注意力分布规律——紧邻输出的内容，往往对最终结果的影响最大，所以示例和具体格式要求必须放在靠后的位置。
6. 常见问题排查：提示词看起来没问题，效果为什么还是不行
6.1 排查清单与高频问题对照
我做了很长时间的提示词调优，把自己的失败经验整理成了一张排查表，每次效果不好就按表逐项检查。
| 现象特征 | 可能原因 | 优先排查方法 |
|---|---|---|
| 模型答非所问 | 目标（O）表述模糊，混入了多个任务 | 把目标拆成一句动词开头的短句 |
| 输出内容空泛、套话连篇 | 背景（C）缺失，模型缺乏角色代入 | 补充具体业务场景与数据 |
| 输出格式不符合预期 | 格式要求放在提示词最前端且只有文字描述 | 放到提示词末尾，并配合1-2个示例 |
| 推理过程太跳跃 | 没有思维链指令，或者示例推理步骤过简 | 加入“请一步步思考”，并在示例中展开推理步骤 |
| 简单任务上效果反而波动大 | 强制使用了思维链导致过度思考 | 去掉推理指令，恢复直接输出 |
| 模型反复修改格式但字段始终不一致 | 示例之间的格式存在冲突 | 重新统一示例字段名和值域风格 |
| 中英文混合时输出语言不稳定 | 未限定输出语言，或示例中语言混用 | 在回复格式中显式写入“使用中文输出” |
6.2 一个我踩过好几次的坑：示例和指令互相矛盾
某个项目的任务是“从产品评论中提取情感倾向，输出结果为‘正向’或‘负向’两位字段”。我在指令里明确写了“仅输出正向或负向”，但在示例里却写了一个“中性”的输出样例。结果模型在跑真实数据时，大量输出“中性”，怎么调都调不回来。后来我把示例里的“中性”案例删掉，问题立刻消失。这件事给我的启发是：在少样本提示中，示例对模型行为的塑造力通常大于指令文字的塑造力。如果你想真正约束输出的可能性空间，必须保证示例集合本身完整覆盖你允许的所有输出情况，一个反例都不能有。
6.3 温度参数和提示词配合的细节
很多人调提示词只看文本，完全不看生成参数。实际上，temperature（温度）的参数设置对同一套提示词的效果影响很大。做信息抽取和格式转换这类确定性任务时，建议把温度调到0，配合少样本示例可以拿到非常稳定的输出。做文案创作类任务时，温度可以适当调到0.7~0.9之间，配合 CO-STAR 的风格约束来保证创意空间不过度发散。
还有一个小细节：设置了低温度之后，如果任务里包含思维链，模型输出推理过程的多样性会降低，但在复杂推理任务上的稳定性会显著提升。生成过程里如果发现答案还是经常错，先不要急着改提示词，把温度从0调到0.3再试一轮，有时候能看到明显改善。
7. 一些实测后的真实体会
提示词工程这门手艺，做久了你会发现它其实不是“写一套完美的模板”，而是“建立一套调试的思维习惯”。我最初做的时候，每次效果不好就想再换个措辞、换个框架重写一版，后来发现效率极低。现在我的做法是：把 CO-STAR 的六个要素拆开，逐一检查哪一项没写透；把思维链的推理过程调出来看模型在哪个中间环节出错；把少样本示例的输出当作测试集，用几个不同的输入去验证格式是否稳定。这套流程跑下来，大多数提示词问题都能在十分钟内定位。
最后再分享一个实用小习惯：所有要放进生产环境的提示词，我都会用一个专门的测试集去跑。测试集由五个输入组成，覆盖典型情况、边界情况和异常情况。如果这五个输入下模型的输出都能保持结构和内容稳定性，我才认为这套提示词是可靠的。很多时候你以为自己写好了，其实只是在一个输入上碰巧成功了。多试几个输入，你才知道你的提示词工程到底过没过关。
