1. 从"会聊天"到"会指挥"：提示工程到底在解决什么问题
很多人第一次用大语言模型，感觉就像面对一个知识渊博但完全不懂你心思的实习生。你问它"帮我写个方案"，它给你一篇四平八稳、毫无灵魂的八股文；你问它"这段代码哪里有问题"，它洋洋洒洒分析一通，最后发现它连你用的语言都没搞清楚。问题出在哪？不是模型不够强，而是你给它的指令太模糊。
提示工程（Prompt Engineering）这个词听起来很唬人，但说白了就是一件事：用模型能理解的方式，把你的真实意图准确传达给它。这跟带团队是一个道理——你对下属说"把那个东西弄一下"，他大概率会做错；但你说"把Q3的销售数据按区域汇总，做成带趋势线的柱状图，下班前发我"，他就能干得八九不离十。大语言模型也是一样的逻辑，它不会读心术，你给什么输入，它就给你什么输出。
我在过去两年多的时间里，从最早拿模型当搜索引擎用，到后来把它嵌入到日常写作、代码审查、数据分析的完整工作流里，踩过的坑可以说能写一本书。最深的体会是：提示工程不是"玄学咒语"，而是一套可以系统化学习和复用的工程方法。它涉及对模型能力的理解、对任务结构的拆解、对输出格式的控制，以及对边界情况的处理。这些东西一旦掌握，你使用任何大语言模型的效率都会有质的飞跃。
这篇文章是"大型 AI ChatGPT 提示工程书籍"系列的第一篇，我会从最基础但最容易被忽视的环节讲起——如何理解模型的工作方式，以及如何写出第一条真正有效的提示。不管你是刚接触大语言模型的新手，还是已经用了一段时间但总觉得"差那么点意思"的老用户，这篇内容都能帮你把底层的逻辑理清楚。我不会给你一堆"万能模板"让你去套，而是带你理解每一条提示背后的设计意图，这样你才能根据实际情况灵活调整。
2. 大语言模型不是"搜索引擎"：理解它的工作方式才能写好提示
2.1 模型到底在做什么：下一个词的预测游戏
要写好提示，首先得知道模型内部在干什么。大语言模型的核心任务其实非常朴素：根据已有的文本，预测下一个最可能出现的词。它把一句话拆成一个个"token"（可以粗略理解为词或词的一部分），然后基于海量的训练数据，计算每个可能的下一个token出现的概率，选一个出来，再把这个token加到输入后面，继续预测下一个。
这个机制决定了几个非常重要的特性。第一，模型没有"记忆"，它不会像人一样记住你上次跟它说了什么——除非你把之前的对话内容一起塞进输入里。第二，模型没有"事实核查"能力，它生成的内容是基于概率的，看起来合理不等于事实正确，这就是所谓的"幻觉"问题。第三，模型对输入的顺序和措辞非常敏感，同样的意思换一种说法，输出质量可能天差地别。
理解这三点，你就能明白为什么有些提示"好用"、有些"不好用"。好用的提示，本质上是在帮模型缩小搜索空间，让它更容易找到你想要的输出方向。不好用的提示，则是在给模型制造混乱，让它在一个巨大的可能性空间里随机游走。
2.2 为什么"帮我写个方案"是最糟糕的提示
我见过太多人上来就是一句"帮我写个方案"，然后抱怨模型输出太水。我们拆解一下这句话的问题："方案"是什么方案？给谁看的？多长？什么风格？重点是什么？这些信息全都没有。模型面对这种提示，只能根据训练数据里最常见的"方案"模式来生成——通常就是那种放之四海而皆准的模板文，读起来通顺，但没有任何实际价值。
正确的做法是把任务拆解成模型能执行的维度。比如你可以这样写：
你是一位有十年经验的B端产品经理。请为一家做企业培训的SaaS公司写一份"新客户 onboarding 流程优化方案"。方案面向公司管理层，需要包含现状问题分析、优化目标、具体改进措施（至少5条）、预期效果评估四个部分。总字数控制在1500字左右，语言简洁务实，避免空话套话。
对比一下，后面这个提示给了模型什么信息？角色定位、任务背景、目标读者、内容结构、数量要求、字数限制、语言风格。模型拿到这些约束条件，生成的内容质量会立刻上一个台阶。这就是提示工程的第一条核心原则：你给模型的约束越具体，它的输出就越接近你的预期。
2.3 提示的四个核心要素：角色、任务、格式、约束
经过大量实践，我把一条有效提示拆解为四个核心要素。这四个要素不一定每次都要全部出现，但当你发现输出不理想时，逐一检查这四个维度，通常就能找到问题所在。
角色（Role）：告诉模型"你是谁"。这个设定会影响模型调用哪部分训练数据。比如你让它扮演"资深律师"和"科普作家"，同样写一篇关于合同纠纷的内容，风格和侧重点会完全不同。角色设定的作用是激活模型中与特定领域相关的知识和表达模式。
任务（Task）：明确告诉模型"要做什么"。这里的关键是动词要具体。"分析"不如"对比分析A和B的优缺点"，"写一段"不如"写一段300字以内的产品介绍，突出三个核心卖点"。任务描述越具体，模型越不容易跑偏。
格式（Format）：规定输出"长什么样"。是纯文本、Markdown表格、JSON、还是分点列表？格式要求能极大提升输出的可用性。比如你需要把结果直接导入程序处理，那就明确要求输出JSON格式，并给出字段定义。
约束（Constraint）：划定"不能做什么"和"必须满足什么"。字数限制、语言风格、必须包含的关键词、不能出现的内容，这些都属于约束。约束是保证输出质量稳定性的关键，尤其是在批量处理任务时。
这四个要素的组合方式非常灵活。简单任务可能只需要"任务+格式"，复杂任务则需要四个要素全部到位。我个人的习惯是，在处理任何稍微正式一点的任务时，都会在心里过一遍这四个维度，缺哪个补哪个。
3. 从零写出一条能用的提示：完整实操流程
3.1 第一步：把模糊需求翻译成具体指令
很多人写不好提示，根本原因不是不会写，而是自己都没想清楚到底要什么。我经常遇到的情况是，有人跟我说"帮我用AI写个东西"，我问他写什么、给谁看、什么风格，他自己也说不清楚。这种情况下，再厉害的提示技巧也救不了。
所以写提示的第一步，其实是需求澄清。我通常会用一张纸（或者一个空白文档）把以下问题回答一遍：
- 这个任务的最终产出物是什么？（一篇文章、一段代码、一个表格、一份报告？）
- 产出物给谁看？（自己、同事、客户、公开读者？）
- 产出物的核心目标是什么？（说服、告知、记录、分析？）
- 有没有参考样例或风格要求？
- 有没有必须包含或必须避免的内容？
- 产出物的长度、格式、详细程度有什么要求？
把这六个问题回答清楚，你的提示基本上就成型了一半。剩下的工作只是把这些信息组织成模型能理解的指令。
3.2 第二步：用"角色+任务+格式+约束"搭建提示骨架
有了清晰的需求，接下来就是搭建提示的骨架。我习惯按照"角色→任务→格式→约束"的顺序来组织，因为这个顺序符合模型理解任务的逻辑：先设定身份，再交代任务，然后规定输出形式，最后补充边界条件。
举个例子，假设我需要模型帮我审查一段代码。按照这个骨架，提示可以这样写：
你是一位有十年经验的Python后端工程师，擅长代码审查和性能优化。 请审查以下代码，找出其中可能存在的bug、性能问题和可读性问题。 输出格式要求： 1. 按问题严重程度排序，分为"严重"、"中等"、"轻微"三个等级 2. 每个问题需要包含：问题描述、所在行号、修复建议 3. 最后给出一个整体评价，不超过100字 约束条件： - 只关注代码本身的问题，不要讨论业务逻辑 - 修复建议要给出具体的代码片段 - 如果代码没有问题，直接说"未发现明显问题"，不要强行找问题 代码如下： [粘贴代码]这个骨架的好处是结构清晰，模型很容易理解每个部分的要求。而且当你发现输出有问题时，可以快速定位是哪个环节的描述不够清楚。
3.3 第三步：加入示例，让模型"照葫芦画瓢"
对于格式要求比较严格的任务，光靠文字描述往往不够。模型可能理解了你说的"分点列表"，但分出来的点跟你想要的粒度不一样。这时候最有效的方法是给示例。
比如你要模型从用户评论中提取产品特征和情感倾向，与其花大段文字描述格式，不如直接给一两个输入输出示例：
请从以下用户评论中提取产品特征和对应的情感倾向。 示例1： 输入：这个手机电池太不耐用了，一天要充三次电，但是拍照效果确实好。 输出：{"features": [{"name": "电池续航", "sentiment": "负面"}, {"name": "拍照效果", "sentiment": "正面"}]} 示例2： 输入：屏幕显示很细腻，就是价格有点贵。 输出：{"features": [{"name": "屏幕显示", "sentiment": "正面"}, {"name": "价格", "sentiment": "负面"}]} 现在请处理： 输入：[待处理的评论]这种"少样本提示"（Few-shot Prompting）的方法，在需要结构化输出的场景下特别有效。模型通过示例能快速理解你想要的格式和粒度，比纯文字描述高效得多。我个人的经验是，示例的数量控制在2到5个之间比较合适，太少模型可能抓不住规律，太多则会占用宝贵的上下文空间。
3.4 第四步：迭代优化，别指望一次就完美
写完提示只是开始，真正的功夫在迭代。我几乎从来没有一次就写出完美提示的经历，通常都需要两到三轮调整。迭代的时候，重点关注以下几个方面：
输出是否符合格式要求。如果模型没有按照你要求的格式输出，先检查格式描述是否足够清晰，然后考虑加示例。如果还是不行，可能是格式要求太复杂，需要拆分成多步任务。
内容是否切题。如果模型跑题了，通常是任务描述不够具体，或者约束条件没有覆盖到跑题的方向。这时候需要补充"不要做什么"的约束。
细节是否到位。如果输出太笼统，说明你对细节的要求没有传达到位。可以尝试在提示中明确要求"每个要点至少展开200字"或者"给出具体的数字和案例"。
语气是否合适。如果输出风格不对，检查角色设定是否准确，或者直接给出风格示例。
迭代的过程中，建议每次只改一个变量，这样才能清楚地知道是哪个改动起了作用。同时，把效果好的提示保存下来，形成自己的提示库，以后遇到类似任务可以直接复用或微调。
4. 新手最容易踩的五个提示陷阱
4.1 陷阱一：把模型当人，用"暗示"代替"明示"
很多人跟模型交流时，习惯性地使用人类之间的含蓄表达。比如想要模型写一篇批判性的文章，就说"你觉得这个现象怎么样"，然后期待模型给出犀利的批评。结果模型给了一篇四平八稳的中立分析，用户就觉得"模型不行"。
问题在于，模型不会揣摩你的言外之意。你问"你觉得怎么样"，它就真的只是给你一个中立的看法。如果你想要批判性的内容，就得明说："请从批判的角度分析这个现象，指出其中至少三个值得质疑的地方，语气要犀利直接。"
我刚开始用模型的时候也犯过这个错误。当时想让模型帮我写一封委婉的拒绝邮件，提示写的是"帮我写封邮件回复一下"，结果模型写了一封热情洋溢的接受信。后来我才明白，在提示工程里，直白永远比含蓄有效。你想要什么，就说什么，不要指望模型能读懂你的潜台词。
4.2 陷阱二：信息过载，把提示写成小作文
跟上一个陷阱相反，有些人喜欢把所有能想到的信息都塞进提示里，结果提示长得像一篇小作文，模型反而抓不住重点。我见过最夸张的一个提示，写了将近两千字，里面混杂了任务描述、背景信息、格式要求、示例、约束条件，还有大段大段的个人感想。模型处理这种提示时，注意力会被分散，关键信息反而被淹没了。
好的提示应该像一份清晰的工作说明书，结构分明、重点突出、没有废话。我的建议是，如果提示超过500字，就要考虑是否所有信息都是必要的。背景信息只保留与任务直接相关的部分，示例控制在2到3个，约束条件按重要性排序，把最关键的放在前面。
如果任务确实很复杂，需要大量背景信息，更好的做法是分步处理。先让模型理解背景，再让它执行任务。或者把任务拆成多个子任务，每个子任务用一条独立的提示来处理。
4.3 陷阱三：忽视输出格式，拿到结果还要手动整理
这个坑我在做数据分析的时候踩得最深。早期我让模型从一堆文本里提取信息，提示写的是"请提取以下文本中的关键信息"，然后模型输出了一段格式各异的文字，有的是分点，有的是段落，有的用冒号，有的用破折号。我拿到结果后还得手动整理成表格，效率极低。
后来我学乖了，每次需要结构化数据时，都会在提示里明确指定输出格式。最常用的是JSON，因为格式固定、易于程序解析。如果不需要程序处理，Markdown表格也很好用。关键是在提示里把格式要求写清楚，包括字段名、数据类型、空值处理方式等。
比如提取信息的任务，可以这样写：
请从以下文本中提取公司名称、成立年份、主营业务、融资轮次四个字段。输出格式为JSON数组，每个对象包含name、founded_year、main_business、funding_stage四个键。如果某个字段在文本中没有提及，值设为null。不要输出任何JSON之外的内容。
这样拿到的结果可以直接导入程序或表格，省去了大量手动整理的时间。
4.4 陷阱四：一次要求太多，模型顾此失彼
大语言模型虽然能力很强，但它的"注意力"是有限的。如果你在一条提示里同时要求它做五件事——总结、翻译、改写、提取关键词、生成标题——它很可能每件事都做得马马虎虎。
我的经验是，一条提示专注于一个核心任务。如果确实需要多个输出，可以拆成多轮对话，或者用"首先...然后...最后..."的方式明确执行顺序。但即便如此，复杂任务还是拆开做效果更好。
举个例子，我需要把一篇中文文章翻译成英文，同时生成摘要和关键词。与其一条提示全搞定，不如分三步：第一步翻译，第二步基于翻译结果生成摘要，第三步提取关键词。每一步的提示都聚焦一个任务，输出质量会稳定得多。虽然多花了几轮交互的时间，但省去了反复修改的麻烦，总体效率反而更高。
4.5 陷阱五：不验证输出，盲目信任模型
这是最危险的一个陷阱。模型生成的内容看起来通顺、专业，但实际上可能包含事实错误、逻辑漏洞甚至完全编造的信息。我在早期做技术调研时，就被模型编造的"参考文献"坑过——它给我列了一堆看起来非常正规的论文标题和作者，但我一查，全是假的。
所以，对模型的输出保持健康的怀疑态度是必须的。特别是涉及事实、数据、引用、代码的内容，一定要验证。验证的方式包括：交叉比对多个来源、实际运行代码、查阅原始资料。对于关键决策，永远不要只依赖模型的输出。
我现在的习惯是，把模型当作一个"高效的初稿生成器"和"思路拓展工具"，而不是"最终答案提供者"。它帮我快速产出草稿、提供不同角度的思路、处理重复性的文字工作，但最终的判断和决策，还是由我自己来做。
5. 提示工程的核心能力：拆解、表达、验证
5.1 拆解能力：把大任务切成模型能执行的小步骤
提示工程最核心的能力，我认为是任务拆解。一个复杂的任务，直接扔给模型往往效果不好，但如果你能把它拆成一系列清晰的子任务，每个子任务用一条精准的提示来处理，整体效果会好很多。
拆解的原则是：每个子任务都有明确的输入和输出，且子任务之间的依赖关系清晰。比如"写一份行业分析报告"这个任务，可以拆解为：确定分析框架→收集和整理信息→撰写各章节内容→整合和润色。每个步骤都可以用独立的提示来完成，而且每一步的输出都可以作为下一步的输入。
拆解的好处不仅仅是提高输出质量，更重要的是让整个过程可控。你可以清楚地知道每一步在做什么，哪一步出了问题，以及如何调整。这种可控性在处理复杂任务时尤其重要。
5.2 表达能力：用模型能理解的语言描述需求
表达能力体现在两个层面：一是用词准确，二是结构清晰。用词准确意味着避免模糊、歧义的表达，尽量使用具体、可操作的动词和名词。结构清晰意味着提示的组织要有逻辑，让模型能快速抓住重点。
我总结了一个简单的检验方法：把你的提示读给一个不了解背景的同事听，如果他能在不追问的情况下理解你要做什么，那这条提示大概率也能被模型理解。如果同事听完一脸茫然，或者问了一堆澄清问题，那说明你的提示还需要打磨。
另外，表达要符合模型的"阅读习惯"。模型对开头和结尾的内容注意力更高，所以把最重要的指令放在开头或结尾。中间部分放背景信息和示例。如果提示很长，用分隔符（如三个短横线）把不同部分隔开，帮助模型区分。
5.3 验证能力：建立自己的输出质量检查清单
验证能力是区分"会用模型"和"用好模型"的关键。我给自己建立了一个输出质量检查清单，每次拿到模型输出后，都会过一遍：
- 事实准确性：涉及事实、数据、引用的内容，是否经过验证？
- 逻辑一致性：前后是否有矛盾？推理过程是否合理？
- 格式合规性：是否符合我要求的输出格式？
- 完整性：是否覆盖了我要求的所有要点？
- 语气适配性：风格是否符合目标读者的预期？
- 可操作性：如果输出的是方案或建议，是否具体可执行？
这个清单看起来简单，但坚持执行能避免很多低级错误。特别是当你在批量处理任务时，建立标准化的验证流程能极大提升效率。
6. 一个完整的提示优化案例：从"没法用"到"直接能用"
6.1 初始提示与糟糕的输出
让我用一个真实的案例来演示提示优化的完整过程。假设我需要模型帮我写一份"产品需求文档"（PRD）的初稿。我最初的提示是这样的：
帮我写一份产品需求文档。
模型的输出是一篇标准的PRD模板，包含"项目背景"、"目标用户"、"功能列表"、"非功能需求"等章节，但内容全是空泛的套话，比如"本产品旨在为用户提供优质的服务体验"、"功能设计应遵循用户至上的原则"。这种输出完全没有使用价值，我还得从头重写。
6.2 逐步优化的过程
第一轮优化：加入角色和任务细节
你是一位有五年经验的B端产品经理。请为一家做企业报销管理的SaaS公司写一份"智能发票识别功能"的产品需求文档。这个功能的目标是让用户通过拍照或上传发票图片，自动提取发票上的关键信息（发票代码、号码、金额、日期、开票方），并自动填充到报销单中。
这一轮的输出明显好了很多，模型给出了具体的功能描述，但格式还是比较随意，而且缺少一些关键细节，比如异常处理、性能要求。
第二轮优化：明确格式和约束
你是一位有五年经验的B端产品经理。请为一家做企业报销管理的SaaS公司写一份"智能发票识别功能"的产品需求文档。
文档需要包含以下章节：
- 功能概述（200字以内）
- 用户场景（至少3个具体场景）
- 功能详细说明（按功能点拆分，每个功能点包含：功能描述、输入、输出、异常处理）
- 性能要求（响应时间、并发量、准确率指标）
- 依赖与风险
约束：
- 面向研发团队，语言简洁技术化，避免市场宣传用语
- 每个功能点的异常处理至少列出3种情况
- 性能指标要给出具体数字
这一轮的输出已经可以直接用了。模型给出了结构清晰的PRD，异常处理部分列出了"图片模糊无法识别"、"发票格式不支持"、"网络超时"等情况，性能指标也给出了"单张发票识别时间不超过3秒"、"准确率不低于95%"这样的具体数字。
第三轮优化：加入示例和边界条件
在第二轮的基础上，我加入了一个示例功能点，展示我期望的详细程度，并补充了"如果某个信息无法从发票中识别，应允许用户手动输入"这样的边界条件。最终的输出质量非常稳定，基本上只需要微调就可以提交给研发团队。
6.3 优化前后的对比与经验总结
回顾这个案例，优化的核心逻辑是：不断补充模型缺少的信息，直到输出达到可用标准。第一轮补充了角色和任务细节，第二轮补充了格式和约束，第三轮补充了示例和边界条件。每一轮都在缩小模型的理解偏差。
这个过程中我最大的体会是：提示工程不是一次性的工作，而是一个迭代的过程。不要指望写一条提示就一劳永逸，而是要把每次交互都当作一次优化机会。当你发现输出有问题时，不要急着换模型或放弃，先想想是不是自己的提示还可以改进。
另外，保存好用的提示模板非常重要。我在这个案例中打磨出来的PRD提示模板，后来被我复用到多个不同的产品功能上，只需要替换功能描述和具体约束，就能快速产出高质量的PRD初稿。这种积累带来的效率提升是巨大的。
7. 建立你的提示工程工作流
7.1 从"每次重新想"到"模板化复用"
刚开始用模型的时候，我每次都是临时想提示，结果就是质量不稳定，有时候效果好，有时候效果差。后来我开始有意识地积累提示模板，把效果好的提示保存下来，分类整理。现在我的提示库里有几十个模板，覆盖了写作、编程、数据分析、翻译、头脑风暴等常见场景。
模板化的好处是降低认知负担。当你需要完成一个任务时，不需要从零开始构思提示，而是找到最接近的模板，根据具体情况微调即可。这就像程序员使用代码库一样，不需要每次都重写基础功能。
我的模板通常包含几个固定部分：角色设定、任务描述、输出格式、约束条件、示例（可选）。使用的时候，只需要替换任务描述和具体参数。这种结构化的模板不仅提高了效率，也保证了输出质量的稳定性。
7.2 用变量和占位符管理可复用提示
对于需要频繁使用的提示，我会用变量和占位符来管理。比如一个"文章摘要"的提示模板：
你是一位专业的编辑，擅长提炼文章核心信息。 请为以下文章写一段摘要，要求： - 字数在{word_count}字左右 - 包含文章的核心观点和关键论据 - 语言简洁客观，不添加个人评价 - 如果文章涉及数据，摘要中要保留关键数字 文章内容： {article_content}使用的时候，只需要把{word_count}和{article_content}替换成实际值。这种模板化的管理方式，让提示的复用变得非常方便。我甚至用脚本把这些模板自动化，批量处理大量文本。
7.3 记录每次交互，形成自己的经验库
我强烈建议养成记录提示交互的习惯。每次使用模型后，简单记录一下：用了什么提示、输出质量如何、做了哪些调整、最终效果怎样。这些记录积累起来，就是你自己的提示工程经验库。
我自己的记录格式是这样的：
| 日期 | 任务类型 | 提示要点 | 输出质量 | 调整记录 |
|---|---|---|---|---|
| 某日 | 代码审查 | 角色+任务+格式+约束 | 良好 | 增加了"按严重程度排序"的要求 |
| 某日 | 数据提取 | 少样本提示 | 优秀 | 示例从2个增加到4个后格式更稳定 |
| 某日 | 文案撰写 | 角色+风格示例 | 一般 | 需要补充目标读者信息 |
这种记录看起来简单，但坚持一段时间后，你会发现自己对"什么样的提示有效"有了非常直观的判断力。遇到新任务时，能快速判断应该采用什么策略。
8. 关于提示工程，我踩过的最值钱的三个坑
8.1 坑一：以为"模型越强，提示越不重要"
这是我早期最大的认知误区。刚接触大语言模型时，我觉得只要模型足够聪明，随便怎么说它都能理解。结果就是大量时间浪费在反复调整输出上，效率极低。
后来我才明白，模型能力的提升和提示工程的重要性是两回事。模型越强，它的潜力越大，但要把潜力发挥出来，仍然需要精准的提示。就像一个能力很强的员工，如果你不把需求说清楚，他可能做出一个很漂亮但完全不是你想要的方案。
而且，随着模型能力提升，提示工程的重点也在变化。早期模型理解能力有限，提示需要非常详细、手把手地指导。现在的模型理解能力大幅提升，提示可以更简洁，但对任务目标的描述要求更高。核心逻辑没变：你给模型的输入质量，决定了它的输出质量。
8.2 坑二：忽视上下文长度对输出质量的影响
大语言模型有上下文长度限制，也就是一次能处理的文本量是有限的。我早期做长文档处理时，经常把整篇文档直接塞进提示里，结果模型处理到后面就"忘了"前面的内容，输出质量明显下降。
后来我学会了分段处理和摘要传递。对于超长文档，先分段处理，每段生成摘要，再把摘要汇总处理。或者在多轮对话中，把关键信息提炼出来，作为下一轮的上下文。这样虽然多花了几轮交互，但输出质量稳定得多。
另外，上下文中的信息顺序也很重要。模型对开头和结尾的内容注意力更高，所以把最重要的指令放在开头，把需要处理的文本放在中间，把格式要求放在结尾。这种"三明治"结构能有效提升模型对关键信息的捕捉能力。
8.3 坑三：没有建立输出验证机制
这个坑的代价最大。我曾经用模型生成了一批数据报告，因为输出看起来非常专业，就直接用了。后来发现其中几个关键数字是模型编造的，差点造成严重后果。从那以后，我建立了严格的输出验证流程。
验证的核心原则是：模型输出的任何事实性内容，都必须经过独立验证。具体来说：
- 数字和统计数据：必须找到原始来源核对
- 引用和参考文献：必须确认真实存在
- 代码：必须实际运行测试
- 专业建议：必须对照权威资料确认
对于创意类内容（如文案、故事），验证的重点则是逻辑一致性和风格适配性。虽然不需要事实核查，但需要通读检查是否有前后矛盾或不符合要求的地方。
这个验证流程看起来增加了工作量，但实际上它避免的返工和纠错成本远大于验证本身的投入。而且，随着经验积累，你会逐渐培养出对模型输出质量的直觉判断力，验证效率也会越来越高。
9. 下一步：从单条提示到提示系统
掌握了单条提示的编写和优化方法后，你会发现很多复杂任务用单条提示很难做好。这时候就需要考虑构建提示系统——也就是一组相互配合的提示，共同完成一个复杂任务。
提示系统的核心思想是分工协作。就像软件开发中的模块化设计，每个提示负责一个明确的子任务，通过输入输出串联起来。比如一个完整的内容创作系统，可能包含：选题生成提示、大纲设计提示、初稿撰写提示、润色优化提示、标题生成提示。每个提示各司其职，最终产出高质量的内容。
构建提示系统的关键，是设计好每个模块的输入输出接口。上一个模块的输出要能直接作为下一个模块的输入，格式要匹配，信息要完整。这需要一些工程化的思维，但一旦搭建起来，效率提升是巨大的。
我在实际工作中已经用这种思路搭建了几个小型的提示系统，用于处理周报生成、竞品分析、用户反馈分类等重复性任务。效果非常稳定，基本上只需要人工做最后的审核和微调。
这个系列后续会详细展开提示系统的设计方法和实战案例。如果你已经掌握了单条提示的编写，不妨开始尝试把日常工作中的重复任务拆解成提示流程，逐步构建自己的提示系统。这是从"会用AI"到"用好AI"的关键一步。
