提示词拆解实录：同一个需求，为什么第二版更稳定
这不是一篇“万能提示词合集”，而是我把一份模糊需求改到可以交付的过程记录下来。需求来自一个很普通的场景：团队想做一组给新用户看的 AI 工具介绍，既要让第一次接触的人看懂，又不能把还没上线的功能写成已经存在；同一套内容还要能被改成网页、社交媒体短帖和客服话术。
我以前遇到这类任务，第一反应是让模型“写得专业、有吸引力”。结果通常不算差，但每一次生成的长度、重点和语气都不同。编辑同事拿到后还要重新拆分，产品同事则会追问“这个功能到底有没有”。真正耗时的不是生成，而是不断解释什么叫合格。
一、先把“想要一篇好文章”改成可验收任务
第一步不是写更多形容词，而是把需求拆成几个互相独立的变量：读者是谁，交付物用于哪里，必须回答哪些问题，哪些内容不能碰，最后用什么方式检查。拆开以后，提示词才从一句愿望变成一张任务单。
- 任务目标：让读者在三分钟内理解工具解决的问题，并能判断是否适合自己的工作。
- 读者画像：没有技术背景，会使用浏览器和表格，但不熟悉模型、接口和自动化概念。
- 交付渠道：官网长文、产品内帮助卡片、社交媒体短帖。
- 事实边界：没有被产品文档确认的能力，必须写成待确认，不得用推测补齐。
- 验收标准：读者看完能说出适用场景、开始步骤、限制和下一步行动。
这里有一个容易被忽略的点：同一个任务往往有多个交付渠道。如果只要求模型写一篇长文，后面还要人工把它切成短帖；如果一开始就要求同时输出多个版本，模型又可能在每一版里重复相同的空话。所以我把“事实层”和“表达层”分开，让模型先整理信息，再基于同一份信息生成不同载体。
二、我的五层提示词结构
现在我常用的结构是：角色与边界、任务目标、输入资料、输出格式、质量检查。它没有什么神秘技巧，优点是别人接手时能看懂，也方便逐层排错。
你是“产品内容编辑”，不是产品经理，也不是销售。
你的职责是：根据已确认的资料，帮助普通用户理解工具。
【任务】
写一份面向新手的工具介绍，并生成一个适合社交平台发布的短版。
【读者】
第一次使用 AI 工具的普通职场用户。
他们关心：能解决什么问题、怎么开始、是否需要付费、有什么限制。
【已确认资料】
- 工具名称：待填写
- 已确认能力：待填写
- 不支持的场景：待填写
- 官方帮助页：待填写
【输出】
A. 长版：标题、80 字摘要、适用人群、3 个具体场景、开始步骤、限制、常见问题。
B. 短版：不超过 120 字，保留一个具体场景，不使用夸张承诺。
C. 待核验项：列出资料中仍然不确定的事实。
【写作规则】
- 不把推测写成事实。
- 不使用“万能、颠覆、零成本、百分之百”等绝对化表达。
- 每个场景都要说明输入、动作和结果。
- 没有资料支持的价格、功能、兼容性写“待确认”。
- 先复述任务，再开始写作。“先复述任务”对我很有用。它不是为了增加对话轮次，而是让错误尽早暴露。模型如果把“面向新手”理解成“儿童读物”，或者把“短版”理解成“标题”，我可以在正式生成前纠正。对于团队协作，复述结果还可以作为任务确认记录。
三、一次真实的迭代日志
第一轮：看起来完整，但不能直接交付
第一轮输出有标题、有段落、有行动号召，读起来很顺。问题是它偷偷补充了“支持所有主流格式”“适合任何行业”“无需学习成本”等内容，而资料里根本没有这些结论。表面上文字更漂亮，实际上审核成本更高。
第一轮的失败原因：我只说了“写得专业”，却没有告诉它哪些信息必须有依据，也没有规定遇到未知信息时怎么办。
第二轮：加上限制条件
第二轮加入“事实边界”和“待核验项”，虚构能力明显减少，但长版文章开始重复同一个观点：提高效率、节省时间、方便协作。它符合要求，却缺少可执行的细节。
于是我增加了场景模板：每个场景必须包含“原来的做法、输入给工具的内容、得到的结果、用户仍需人工确认的地方”。这样写出来的介绍不再只是口号，而是能让读者判断自己的工作是否匹配。
第三轮：固定输出顺序，允许表达有变化
我没有把每句话都锁死，只固定信息顺序和不可缺少的字段。结果是不同版本的语气可以变化，但关键事实仍然在同一位置，编辑阅读时更容易比较。
- 固定的是：字段、顺序、长度上限、事实边界。
- 可变化的是：开头案例、比喻、段落长短和结尾提问。
- 不交给模型自行决定的是：价格、发布时间、兼容范围和安全承诺。
四、让模型学会区分事实、推断和建议
内容团队最怕的不是错别字，而是把推断写成事实。为此我会要求模型给每一条重要说法打一个内部标记，最终发布前再删除标记。这个方法不适合所有公开文章，但适合资料整理和初稿阶段。
[事实] 官方资料明确写出的功能
[推断] 根据多个事实得出的合理判断
[待确认] 当前资料不足，不能下结论
[建议] 面向读者的使用建议，不代表产品承诺例如，“可以上传文件”如果在帮助文档中明确出现，属于事实；“因此适合处理所有长文档”就是推断，而且可能不成立；“建议先用一份不含敏感信息的文件试运行”则是使用建议。把三者分开后，编辑可以只重点检查事实和推断，不必对每一个修辞句子逐字审查。
五、同一份事实，输出三种内容
我把已确认的资料整理成一个小型事实表，再让模型分别生成长文、短帖和客服回复。三种内容的目标不同，不能简单截断。
- 长文：负责解释背景、步骤、边界和常见误区，读者可以慢慢阅读。
- 短帖：负责引起兴趣，只保留一个具体问题和一个清晰收益，不塞五个卖点。
- 客服回复：负责解决当前问题，先给操作步骤，再给限制，避免用宣传语绕开问题。
我的做法是先让模型写“事实骨架”，再分别套用三种输出模板。这样可以减少不同渠道的说法互相矛盾，也方便后续产品改动时只更新一处。
六、最容易失控的六个位置
1. 角色写得太大
“你是一位世界顶级专家”通常不会让事实更准确，反而可能让语气变得过度自信。角色应该说明工作职责、读者和边界，而不是堆叠头衔。
2. 输入资料没有标出优先级
同一份任务里可能同时放了产品文档、旧文章、用户评论和一段聊天记录。若不说明优先级，模型可能把用户猜测当成官方事实。我会明确：最新的正式文档优先，其次是产品负责人确认，评论只用来发现问题，不用来证明功能。
3. 输出格式过于宽泛
“写得清楚一点”不能验收。应改成“先给 80 字摘要，再给 3 个场景，每个场景包含输入、操作、结果和人工确认点”。格式越可观察，返工越少。
4. 把检查交给最后一句
单独说“请检查是否准确”力度很弱。更好的方式是要求生成一个“待核验清单”，并把无法从资料中确认的地方集中列出。
5. 例子与正式答案混在一起
如果提示词中有示例，必须明确“以下只是格式示例，不是本次任务事实”。否则模型会把示例中的品牌、价格或数字带进答案。
6. 让模型一次完成所有事情
资料整理、观点判断、文案写作、事实核验和排版是不同工作。任务越复杂，越适合分两到三轮完成。每轮只解决一种问题，结果通常比一条超长指令更稳定。
七、我现在会保留的人工环节
提示词写得再好，也不能替代人工判断。尤其是对外发布的内容，我会保留四个检查点：功能事实由产品资料确认；价格与时间由运营确认；涉及安全和隐私的表述由负责人确认；案例中的用户信息做脱敏处理。
我不会让模型自行决定“这句话听起来很合理，所以应该是真的”。合理只是表达层面的感觉，不是事实证据。模型可以帮助我找到矛盾、补全问题和改写语言，但最终发布责任仍然在人。
八、一个适合团队共享的轻量模板
任务名称：
使用场景：
最终读者：
交付渠道：
截止时间：
已确认事实：
1.
2.
3.
禁止假设：
1.
2.
必须回答的问题：
1.
2.
3.
输出格式：
- 标题：
- 摘要：
- 场景：
- 步骤：
- 限制：
- 待确认：
验收人：
验收方式：
版本号：这个模板看起来很朴素，但比“大家自由发挥一下”更适合长期复用。尤其是版本号和验收人，可以避免同一份内容被改了很多次，却没人知道哪一版才是有效版本。
九、什么时候不该继续加提示词
如果模型总是答错，问题不一定在提示词。可能是资料缺失、工具能力本来就不支持、上下文太长导致重点被稀释，或者任务本身需要调用数据库、搜索和人工审批。继续往提示词里添加“务必准确、必须认真、不要出错”，通常不会解决根因。
我的判断顺序是：先检查输入是否完整，再检查任务是否可拆分，然后检查输出是否可验收，最后才调整语气和示例。如果连人类编辑拿到资料都无法确认答案，模型当然也不应该被要求猜。
十、这套方法给我的实际变化
过去我把提示词当成一次性文本，写完就丢；现在更像维护一个小型工作流程：有输入、有版本、有验收、有失败记录。每次迭代不只是修改句子，而是记录“哪个约束减少了哪一种错误”。
这也改变了我对“好提示词”的判断。好提示词不一定很长，也不一定写得像技术论文；它应该让任务目标、输入边界和合格标准变得清楚，并且允许另一个人接手。对于简单任务，一句话加一个例子就够；对于高风险或多人协作的任务，结构化模板才值得投入。
给社区朋友的提问：你们在实际工作中最难控制的是事实准确、输出格式，还是语气一致？如果愿意分享，可以贴一段脱敏前后对比，我想继续整理成更具体的失败案例库。
参考入口：OpenAI Prompt Engineering · Anthropic Prompt Engineering
说明：本文是基于公开提示词工程资料和个人工作流整理的原创实践记录，不是任何平台的官方教程，也不保证同样的模板适用于所有模型和任务。
