1. 提示词不是玄学：六要素框架到底解决什么问题

1.1 同样一个模型，为什么有人能一步到位

“提示词怎么写才有效”大概是这两年最常被问到的问题之一。我也一样，早期写提示词基本靠感觉，一句话甩给AI，然后看运气。运气好，答案像模像样；运气不好，AI给出的东西和脑子里想的差了十万八千里。后来我逐渐意识到，真正拉开差距的不是谁的词汇量大，也不是背了多少热门模板，而是有没有一套自己的提示词框架。六要素框架就是把这件事标准化的一套方法，熟练之后，无论你是在写文案、画图，还是在写AI编程提示词，都可以用同一套逻辑去组织信息。

我见过很多零基础用户的第一反应是“提示词越长越复杂，AI就越聪明”。实际上，AI不是聪明不聪明的问题，它更像一个阅读能力极强、但社会常识极度依赖上下文的外包员工。它不会读心术，也不会自动补全那些你认为“不需要说”的前提条件。你写“帮我整理一份报告”，它可能理解成列表归纳，也可能理解成写一篇分析文章，还可能理解成生成一个PPT大纲。提示词框架存在的意义，就是把这些歧义一个个消灭掉。

1.2 六要素框架：一份六项必填的任务交接单

我这里说的六要素，指的是：角色、目标、背景、边界、输出、示例。其实你可以把它理解成给新同事写任务交接单：谁来干这个活？最终要干成什么样？这个任务发生在什么环境下？哪些事不允许做？交付物长什么样子？有没有一个可以参考的例子？

这六个维度并不是我凭空发明的规则，而是我踩了无数次坑之后倒推出来的。早期我写提示词，经常发现最后生成的结果“跑题”，复盘的时候翻来覆去地看，几乎每次都能落到六类问题上：要么忘了告诉AI以什么身份来处理，要么目标描述里有歧义，要么没给足背景资料，要么没有设置禁止项，要么没规定输出格式，要么没给样例参考。后来我养成了一个习惯：写完提示词后，对照这六点逐项检查，出题率立刻下降了一大截。

顺带说明一下，这个“六要素框架”不是唯一的写法。市面上也有角色提示词、结构化提示词、思维链提示词等流派。但六要素更适合普通人上手，因为它本质上不是写作技巧，而是检查清单。你不需要文笔好，不需要懂算法，只需要在发消息前多花三十秒把六个问题过一遍。

1.3 鹈鹕骑自行车：提示词工程圈最近的一面“照妖镜”

最近“鹈鹕骑自行车”这句提示词在图像生成、视频生成圈子里特别火，从Flux到ComfyUI再到各类中文文生图模型，很多人都在拿它做测试。这个词组的妙处在于，它把两个看似完全不搭的要素强行组合在一起：鹈鹕这种鸟有巨大的喉囊、短腿和大嘴，而自行车是结构严格的机械造物。模型既要理解“骑”这个动作，又要保证鸟类解剖结构不被扭曲，还得处理视角、重心、环境等一系列问题。生成结果稍微差一点，画面就会变成“鹈鹕站在车旁”或者“鸟嘴里叼着自行车”，非常直观地反映出模型到底有没有理解提示词。

我拿这个案例当引子，是因为它特别适合用来理解六要素框架。你光说“一只鹈鹕骑自行车”，十个模型能给你十种理解；但当你把角色、目标、背景、边界、输出、示例六项都交代清楚之后，稳定度会明显上升。下面第二部分先把六个要素逐个讲透，第三部分再用完整的案例做一次组装演示，看完你应该能直接在自己的工具里复现。

2. 六要素逐项拆解：角色、目标、背景、边界、输出、示例

2.1 角色：把AI请到正确的工位上

第一个要素是角色。很多人容易忽略它，觉得“让AI干活就行了，干嘛要给它头衔”。但如果你尝试过让同一个问题分别以“老师”和“小学生”的口吻回答，就会明白角色的作用不仅限于口吻，它还决定了AI调用的知识侧重点和表达方式。

举一个生活化的例子。你问“帮我解释一下什么是递归”，如果角色是“给新手讲课的程序员”，它大概率会用烤面包机、排队叫号这类生活案例来解释；如果角色是“技术面试官”，它可能直接给出复杂度分析和边界条件讨论；如果角色是“写儿童科普的编辑”，它甚至会把递归写成童话故事。AI本身掌握的知识是同一套，但“如何选取”和“如何组织输出”会因为角色设定发生明显偏移。

实际操作中，角色不要写得太笼统。尽量把角色的领域、经验水平、工作场景写出来。比如“你是一位有五年经验的React前端工程师，负责审查代码并给出重构建议”。这比单纯写“你是前端工程师”要有效得多。因为这句话不仅设定了身份，还暗示了你看重的是工程实践经验而非教科书式回答。

2.2 目标：把“要什么”压缩成一句可验收的话

第二个要素是目标。目标是所有要素里最先应该确定的，因为它直接决定了任务的终点。目标描述要尽量做到“可验收”，也就是说，你拿这句话作为判断标准，能明确知道AI做没做到。

举个例子，“帮我写一份关于健康饮食的文案”不是一个清晰目标，因为“文案”可能是平面广告、公众号文章、短视频口播稿，更麻烦的是没有说明文案的用途和受众。更好的目标写法是：“为一款面向都市白领的低糖早餐燕麦片，写一篇订阅号推送文案，目的是让读者产生点击购买的兴趣。”这样AI知道它要做的是新媒体文案，对象是都市白领，卖点是低糖早餐，职责是促进转化。

写目标时还有一个容易犯的毛病：一次性塞太多要求。比如“帮我做一个既能用户注册登录、又能发布文章、还能点赞评论的项目”，这种目标在AI看来就像一团乱麻。我建议在目标不清晰时，先写一句话版本，然后不断自问：这个任务的核心交付物到底是什么？如果一句话说不清，那就拆分任务，而不是硬塞给一次生成。

2.3 背景：把已知条件和资料一次给齐

第三个要素是背景。背景的作用是减少AI的猜测空间。很多提示词失败，不是AI笨，而是信息缺失导致它只能从最普遍、最模糊的角度去理解。

背景信息至少包含三类：一是任务所处的情境，比如“这是给公司内部技术分享用的PPT大纲”；二是你已经确定的事实，比如“用户反馈量已经统计好了，共1200条，我贴一部分原始文本给你”；三是限制性条件，比如“这个功能需要在手机上运行，网络不稳定”。这三类信息叠加起来，AI就能在更真实的上下文里替你思考。

特别想提醒一点：背景信息不是越多越好，而是相关性越高越好。我也见过喜欢把过去一周的工作日记全贴进去的人，结果AI抓不住重点。正确姿势是先说清楚哪些背景是“决策依据”，哪些只是“无用的花絮”，然后有选择地提供。如果你实在判断不了哪些信息有用，可以在背景末尾加一句“如果需要更多资料，先列出你缺少哪方面的信息”，让AI自己来要。

2.4 边界：划清禁区，防止AI自由发挥

第四个要素是边界，也就是“不要做什么”。边界经常被忽略，因为大多数人只习惯提正向要求，很少意识到AI也会过度发挥。当你让AI写一篇文章，它很容易在结尾来一段慷慨激昂的总结；当你让AI生成一张插画，它可能擅自加一个水印或者一排超大字标题；当你让AI写代码，它可能自作主张接入一堆你没用过的依赖库。

边界清单在使用图像生成和AI编程提示词时特别重要。图像生成里，如果你想画“一只猫坐在窗台上”，但是不想让画面出现月亮、星星、人物剪影，就得把这些明确列为禁止项。编程场景里，你不想让AI改动项目的现有架构，不想引入第三方包，不想使用某些底层API，都必须写出来。边界的信息粒度越小，AI跑偏的概率就越低。

很多初学者担心写“不要什么”是不是会显得啰嗦。我的经验是：宁可多写三条不存在的禁令，也比生成三次废稿省时间。特别是在你追求稳定复现时，边界就是你的护栏，AI的自由发挥被限制住，反而能产出更符合预期的结果。

2.5 输出：把交付物的长相、格式甚至语气都定死

第五个要素是输出。输出是很多人最容易忽略的一环，但它对最终体验的影响特别大。同样是“给我一份项目规划”，AI可以输出一段纯文字，可以输出一个Markdown表格，可以输出一个时间轴列表，还可以输出一个流程图。没有指定输出格式时，模型会按它默认的习惯走，你拿到手往往还得二次整理。

输出要素里建议写明三件事：格式、长度、语气。格式包括“用表格”“用代码块”“用JSON”“用大纲”等；长度包括“控制在200字以内”“分五个点各三行”等；语气包括“专业严谨”“轻松口语化”“中性客观”等。你以为AI应该知道的这些细节，它其实是不知道的，明说出来才是效率来源。

有一点要注意：输出格式和结果质量之间有时会有冲突。比如你既要AI生成一段严谨的法律文本，又要它不超过100字，这本身就可能不现实。所以设定输出要求时，最好先评估一下需求和资源的匹配度，不要给出自相矛盾的要求，否则AI会陷入“两头堵”的困境。

2.6 示例：一两个好样本胜过十句形容词

第六个要素是示例。给示例的本质，是告诉AI“我想要的‘好’到底是什么样子”。有时候你花很长篇幅描述风格、语气、结构，但AI依然不能准确把握，这时候一个例子顶过全部形容词。

比如你想让AI帮你写产品卖点文案，与其写“要生动、要有冲击力、要吸引人”，不如直接给一句示例：“以前你泡一杯燕麦要等三分钟，现在三秒钟就能搞定，而且好喝得像现煮”。AI看到这个例子之后，会模仿出相似的信息密度、句式节奏和口语表达方式，比纯粹靠形容词驱动有效得多。

写示例时不需要很长的范文，截取一段少量但特征鲜明的片段就够了。如果你手里有多个风格不同的参考，可以让AI先学习示例中的共性和差异，再给出组合结果。对于代码类任务，示例通常以“输入-输出”样例的形式出现：给一段输入数据格式，再给期望的处理结果。这样AI写出来的代码会更贴近你的实际数据结构，不至于算法对了但字段名全错。

3. 完整案例一：用六要素写出“鹈鹕骑自行车”这类高难度图像提示词

3.1 先看一个最容易翻车的写法

最近“鹈鹕骑自行车”这个测试题，网上有很多版本，有人直接用最简格式“a pelican riding a bicycle”，也有人层层加码。先来说说最常见的翻车版本：只写一句“一只鹈鹕骑自行车”。

这句话包含的歧义太多了。鹈鹕是什么姿态骑？是像人一样坐在坐垫上，还是用腿站在脚踏板上？自行车是什么类型？是城市通勤车、公路车还是儿童三轮车？场景在哪里？是城市街道还是海边公路？画风是写实、卡通还是油画？所有这些问题你都没说，模型只能自己填坑。

我实测下来的结果是：很多模型会画出一只大鸟“骑”在一个已经被压变形的东西上，有的甚至把自行车结构简化成了轮子加横杆，完全丢失辐条、链条这些细节。最离谱的一次，模型把鹈鹕的长喙处理成了车把，整个画面既不像鹈鹕，也不像自行车。说白了，模型在试图用最省力的方式满足你那种模糊的语义匹配，却越省力越离谱。

3.2 按六要素逐步组装一版能用的提示词

现在用六要素思路走一遍流程，你会发现整个提示词的清晰度完全不同。我们先确定目标：画面主视觉是一只成年大白鹈鹕在城市街道上骑行一辆复古双轮自行车。再看角色，为图像生成场景设定为“擅长清新童趣插画风格的AI画师”，这样模型会往插画方向倾斜，而不是硬核写实。

然后是背景信息。画面背景设定成明亮的晴日、低角度视角，道路两旁有模糊的绿植，整体氛围轻松诙谐。接着补边界：保持鹈鹕的明显特征，包括大喉囊、长喙、短腿；确保自行车有清晰的车架、两个车轮和辐条，不能变成鸟的翅膀；画面中不允许出现其他动物、行人、路标、文字和水印；不采用暗黑恐怖或过度写实风格。最后是输出要求：横版16:9构图，无任何文字，细节丰富，插画风格统一。

根据以上拆解，一版可以直接复制的中文提示词如下：

请以一位擅长插画设计的AI画师身份，生成一张横版16:9的插画。画面主视觉是一只成年大白鹈鹕，正用拟人化姿态骑着一辆复古双轮自行车，出现在城市街道上。背景是明亮的晴天，低角度仰拍视角，路面微湿有倒影，整体氛围轻松诙谐。鹈鹕必须保留大喉囊、长喙和短腿等生物特征，可以用拟人化动作，但四肢不能与车架融合；自行车需要有完整车架、两个车轮、辐条和脚踏，不能变形或与鸟的身体粘连。画面中不得出现其他动物、行人、文字、字母、水印或边框。风格参考温暖明亮的动画电影场景，色彩通透，细节清晰。

这版提示词没有用什么高级参数，也没有堆砌英文关键词，但它把六个要素都照顾到了。如果你用的模型支持中文提示词，比如较新版本的图像模型，通常能直接得到比较稳的画面。如果用英文界面，也可以把同样的逻辑翻译成英文，关键信息一条不少。

3.3 生成完不满意怎么调？在哪个要素上动手

图像生成很少有一次到位的，所以学会“定位问题”比反复碰运气更重要。拿到结果后，我通常是按六要素依次排查。

如果画面上鹈鹕不对，问题大概率出在“角色”和“边界”上。你要把角色描述得更细，比如“儿童科普绘本风格的插画师”，同时把边界里关于“保留大喉囊、长喙”的部分写得更强制一些。如果自行车不对，问题多半出在背景和边界里的结构说明不全，可以把“辐条”“链条”“复古车把”等细节拆出来单独强调。

如果风格不对，问题往往在输出和示例上。输出里只说“氛围轻松诙谐”是不够的，很多模型会把它理解为“奇怪的表情”，更好的做法是给出一个具体的风格参照，比如“类似《疯狂动物城》的城市背景风格”或“类似吉卜力动画的色调”。如果你用的工具支持参考图，那就更直接，一张参考图比任何风格形容词都管用。

如果整体构图总是不理想，可以重新审视目标表述。目标里只有“横版16:9”是不够的，你还需要告诉模型主体在画面中的大小比例、视线方向、留白位置。比如把“鹈鹕位于画面中心偏右，车头朝向左前方”写进目标里，构图的稳定性会明显改善。总之，改哪里要看哪里出错，不要每次都推倒重写。

4. 完整案例二：用六要素写一个AI编程提示词，让代码一次跑通

4.1 编程提示词和绘画提示词差别在哪

AI编程提示词听起来和绘画提示词是两类任务，但其底层逻辑完全一致。绘画提示词要把“画面要素”写清楚，编程提示词要把“行为逻辑”写清楚。很多人写AI编程提示词时只写一句“帮我写个程序”，或者“写个爬虫抓取数据”，结果AI给出的代码要么缺少边界处理，要么依赖库没交代，要么处理逻辑完全不符合预期。

编程场景更特殊的一点在于，代码是可以被计算机精确判定对错的。绘画稍微抽象一点，风格偏差还能算“审美问题”；编程如果逻辑错了，轻则跑起来报错，重则产生错误结果你还浑然不觉。所以在写编程提示词时，背景、边界、输出、示例这几个要素的价值会被放到最大。

另外，AI编程提示词要特别强调“方案选型”。如果你不告诉AI“用什么语言、要不要引入第三方库、性能要求是什么”，它会按默认最优方案写，但那个最优方案很可能不适合你。比如你只需要一个几百行的脚本，它可能给你设计一个模块化系统；你只想跑一次批处理，它可能给你加一个定时任务框架。界定边界能有效防止这种过度设计。

4.2 用六要素把日志分析脚本需求翻译清楚

拿一个我实际做过的小需求来演示。任务背景：我有一些Nginx访问日志，想写一个Python脚本，统计状态码分布、访问次数最高的十个URL，以及每次请求的平均响应字节数。如果只写一句“帮我写个Python脚本分析Nginx日志”，它大概率能交差，但结果未必好用。按六要素走一遍，情况完全不同。

角色设定为“有多年运维经验的Python工程师，擅长写简洁实用的脚本”。目标设定为“编写一个命令行工具，输入Nginx access_log文件路径，输出状态码统计、Top 10 URL和平均响应字节数”。背景信息则给出日志样例路径，并贴出几行真实日志格式。边界则写明“只用Python标准库，不依赖pandas、requests等第三方包”“不做网络请求，不连接数据库”“遇到解析失败的日志行跳过，不能中断”“脚本要能在命令行直接运行”。输出要个“完整代码文件，包含main函数、命令行参数解析和示例输出”。示例则贴两行日志并说明期望统计结果。

根据这些约束，一个清晰的AI编程提示词会是这样：

你是一位有多年经验的Python运维工程师，请编写一个命令行脚本，用于分析Nginx access log。输入参数是日志文件路径，运行后输出三部分内容：状态码分布统计、访问次数最高的10个URL、所有请求的平均响应字节数。日志路径由命令行传入，格式类似于 /var/log/nginx/access.log。原始日志每行格式如下： 127.0.0.1 - - [10/Oct/2024:13:55:36 +0800] "GET /api/user HTTP/1.1" 200 1024 "-" "curl/7.68.0" 192.168.1.7 - - [10/Oct/2024:13:56:11 +0800] "POST /api/order HTTP/1.1" 500 287 "-" "Mozilla/5.0" 脚本必须只用Python标准库实现，禁止使用第三方依赖；不能发生网络请求，也不能读写数据库；解析失败的行跳过不报错。输出使用表格形式，Top 10列表按照次数降序排列。请先给出完整脚本代码，再写一段使用说明和运行示例。

这个提示词看起来比第一版长很多，但每一句都和最终执行直接相关。有了日志样例，AI就不会猜错字段解析方式；有了“只用标准库”的边界，它就不会擅自引入pandas；有了“解析失败跳过”的指令，脚本在脏数据环境下也不会崩溃。

4.3 加约束前后对比：一次跑通和反复修bug的区别

同样的需求，不加约束的提示词带来的麻烦我踩过太多次了。第一次让AI写日志分析脚本，它直接把pandas、matplotlib全用上了，我本地环境没有装，还得先补包；再一次，它默认日志是JSON格式，但我的日志是经典Nginx combined格式，跑出来全乱；还有一次，它没有处理空文件的情况，运行时直接报了IndexError。

再加上六要素约束之后，效果会完全不同。它会直接只写一个几十分钟就能读完的脚本，字段解析按给定格式匹配，异常行跳过，输出整齐的表格。合理设置边界还能让代码更易读，因为AI知道自己不需要把系统设计得那么复杂，只需要围绕目标完成一套精准的文件处理流程。这种“一次跑通”的体验，才是AI编程提示词最能够带来价值的地方。

从成本的角度看，写一个详细提示词大概要花5到10分钟，但换来的是少几次令人失望的生成、少几次往返修改。尤其是遇到涉及外部文件格式、语言版本、依赖环境的场景，多花两分钟把背景和边界写清楚，是稳赚不赔的买卖。

5. 高频翻车现场与排查经验

5.1 症状、原因与对策速查表

下面这张表是我日常排查提示词的常用对照表。并不是所有问题都出在“写得不够长”，很多问题的根源反而是某个要素缺失或者要素之间互相冲突。遇到问题先对照表格定位，再精准修改，效率会高很多。

用这张表定位问题时，还有一个姿势很重要：只修改一个变量。很多人遇到生成结果不理想，会同时加戏、加风格、加背景、加输出要求，结果根本看不出来是哪个改动奏效了。正确做法是一次只调整一个要素，跑一次对比结果，再决定要不要继续调整。

5.2 两个心态误区：提示词越长越好，以及“抄泄露提示词”

现在网上关于提示词的讨论非常多，动不动就有人贴出几十行甚至上百行的所谓“提示词完整写法”。我自己也关注过一阵子热门帖子，发现一个现象：很多长提示词里有大量重复描述和无效修饰，真正起作用的可能只有中间几行。提示词并不是越长越好，核心标准是“信息密度高且无歧义”。一段一百字的目标比五百字的花哨形容词更能让AI复现出稳定结果。

另一个很常见的坑是“抄泄露提示词”。总有网站爆料Cursor、Claude、某知名插画模型的官方提示词，很多人如获至宝，复制进自己的项目里就期待它一步登天。且不说某些“泄露提示词”的真假难辨，即便它是真的，它也是为特定产品、特定模型版本、特定场景设计的。拿别人的提示词直接改个名字就开跑，忽略了角色、背景、边界这些与自己需求相关的要素，效果往往大打折扣。

我的建议是：你可以把热门提示词当作“参考样本”，但不要当“标准答案”。把里面能打动你的表达方式吸收到自己的六要素框架里，替换成自己的需求内容，比原样照抄可靠得多。写提示词这件事，本质上考验的是思路，不是记忆力。

5.3 日常写提示词的推荐流程

最后分享一个我目前每天都在用的流程，大约需要两到三分钟。第一步，先别打开对话框，拿出一句话写下目标：我想得到一个什么样的结果。第二步，给这个任务指派一个角色，同时写明这个角色最擅长什么。第三步，列出所有已知事实和限制条件，按重要性排序，只保留和结果直接相关的关键信息。第四步，用否定句补三层边界：不要做什么、不要用什么、不要出现什么风格。第五步，指定输出格式和长度，并准备好一两个示例或参考。第六步，发送前把整段提示词快速通读一遍，心里自查六要素是否都覆盖到了。

这套流程看起来有点机械，但用熟了之后非常顺手。我见过不少朋友从“随便写一句”切换到这套流程后，生成质量明显稳定下来。原因其实很简单：不是他们的AI变聪明了，而是他们终于把自己的需求说清楚了。

我个人在实际操作中的体会是，提示词能力最终会回归到“拆解问题”的能力。六要素框架最大的价值不是帮你写出某一条特定的神级提示词，而是逼你在发送之前把想法里的模糊地带全部暴露出来。当你发现自己连目标都说不清时，先别急着责怪AI，先回去把需求想明白。如果你每次都能做到这一步，那不管是画图、写文章还是编程，手里的AI工具都会突然变得好用很多。