不聊虚的，直接聊怎么用。这篇是提示词系列第四篇，前几篇把角色设定、上下文管理、输出约束这些基础过了一遍，这篇集中讲进阶场景：复杂任务拆解、编程场景提示词、多模态生成提示词，还有最常见的报错现场。核心就一句话——提示词不是“问得漂亮”，而是“把需求说清楚到AI无法误解”。
先把话说在前面：到了这个阶段，你缺的已经不是提示词模板，而是拆问题的能力。同样的ChatGPT，有人拿它当搜索引擎，有人拿它当半个团队，差距全在提示词设计上。
1. 从追问到设计：提示词进阶的核心思路转变
1.1 提示词工程的三个层次
我习惯把提示词能力分成三层，你可以自己对号入座。
第一层是“会用”，就是知道怎么提问、怎么补上下文、怎么要求格式，大多数教程停在这一层，你照猫画虎也能干活。第二层是“会调”，输出不对的时候知道问题出在哪，是任务描述含糊、缺少示例、还是约束条件冲突，能针对性地改提示词。第三层是“会设计”，面对一个复杂目标，能主动拆成多个阶段、多组角色、多轮对话，让AI按你的思路逐步逼近结果。
这篇讲的就是第二层和第三层。别觉得抽象，下面每个小节都有能直接拿来改的实例。
1.2 为什么有人写一百条提示词不如别人写三条
我见过太多人反复修改提示词，改了十几版还是不满意，最后归咎于“AI不行”。其实多数情况是改错了地方。提示词写不好的典型问题有三个：任务边界不清、评价标准缺失、示例锚点不足。
边界不清，表现为“帮我写个方案”这种话，AI只能猜你的行业、风格、深度、篇幅，猜中就赚，猜不中你就得反复修。评价标准缺失，是你没说“什么样算好”，AI不知道拿什么标准自我检查。示例锚点不足，是你描述的抽象概念缺乏具体参照物。
打个比方，这就像你让一个没见过鹈鹕的外国朋友“画一只像鹈鹕的鸟”，他画出来什么你都嫌不像，可你也没告诉他鹈鹕嘴下面有个大皮囊、腿短、走起来一步一晃。提示词的本质就是给AI补上“它猜不到”的信息。
1.3 进阶提示词的通用骨架
我自己的提示词结构长期稳定在四段式，不管什么场景都能套：
角色与目标、输入材料、处理规则、交付格式。
角色与目标解决“你是谁、要干什么”，输入材料解决“基于什么”，处理规则解决“怎么干、别干什么”，交付格式解决“长什么样”。四段缺一段，输出质量就掉一截。写提示词不是写作文，是写技术需求文档，越像后者越稳。
2. 复杂情境提示词的拆解实战：以“鹈鹕骑自行车”为例
2.1 一个奇怪提示词为什么值得拆解
“鹈鹕骑自行车”最近在AI圈挺火，表面是个趣味测试，实际是检验模型对不合理场景的合成理解能力。鹈鹕有标志性的大嘴和皮囊，骑自行车则需要肢体协调、平衡和动态动作，这两个元素组合在一起，AI如果只是简单堆砌图像特征，画出来大概率是鹈鹕站路边、车在旁边，或者人骑车后面驮着鹈鹕——都不是“鹈鹕在骑车”。
这个案例特别适合用来讲进阶提示词，因为它同时考验对象描述、动作描述、关系约束和物理合理性。你要是能把这个提示词写明白，那工作里绝大多数复杂描述都不在话下。
2.2 把“鹈鹕骑自行车”写成结构化提示词
先看一个失败的写法：
鹈鹕骑自行车。
这是给AI出难题。模型知道鹈鹕，也知道骑自行车，但两者组合时，优先联想是“人骑车”。缺了对主体的精确描述、动作姿态、视角、风格，AI只能拿概率最高的答案糊弄你。
拆解后可以这样写：
一只成年白鹈鹕，黄色大嘴，喉囊微微鼓起，正骑在一辆老式黑色自行车上。它双翅自然收拢，两只脚踩在脚踏板上，身体略微前倾保持平衡，背景是沿海小镇的黄昏街道。写实风格，侧面视角，重点表现鹈鹕骑车时的笨拙又认真的神态。
区别在哪？一是主体精确到“成年白鹈鹕”，二是动作具体到“脚踩脚踏板、双翅收拢、前倾保持平衡”，三是视角和风格定了“侧面、写实”，四是给了一个情感基调“笨拙又认真”。AI一旦有了这些锚点，就不容易跑偏。
2.3 从趣味测试到真实业务场景的迁移
这个拆解方法迁移到工作里，就是所谓的“给AI写分镜”。比如你做活动海报，要AI生成一张“开会时偷吃零食的企鹅”配图，同样得交代企鹅种类、偷吃动作、开会场景、视角、光线。更通用的是：凡是涉及人物动作的内容，都建议按“主体+姿态+动作+道具+背景+视角+风格”七要素来写。
这里顺手整理一个通用模板：
| 要素 | 说明 | 示例 |
|---|---|---|
| 主体 | 具体到种类、颜色、状态 | 成年白鹈鹕、黄色大嘴 |
| 姿态 | 整体身体姿态 | 身体前倾、双翅收拢 |
| 动作 | 正在做的具体动作 | 双脚踩踏脚踏板 |
| 道具 | 与主体互动的物品 | 老式黑色自行车 |
| 背景 | 环境场景与氛围 | 沿海小镇黄昏街道 |
| 视角 | 观察角度 | 侧面视角 |
| 风格 | 视觉风格 | 写实、温情 |
七要素不用每次写全，但核心动作和主体特征必须明确。趣味案例的价值不是乐一乐，而是它把要素拆解练得足够顺手。
3. AI编程提示词的工程化写法
3.1 让代码助手听懂需求的提示词结构
编程提示词和普通提示词的差别在于：需求描述必须接近需求文档，而不是聊天。你写“帮我写个爬虫”，AI确实能写出来，但大概率不是你要的。
靠谱的结构是：功能目标、输入输出、约束条件、异常处理、测试用例。拿“读取配置文件”举例，菜鸟写法是“写个读取config.toml的程序”，老手会这样写：
请用Python实现一个配置读取函数：输入是config.toml文件路径，输出是解析后的配置字典；要求支持基础数据类型、嵌套表、数组解析；文件缺失或格式错误时抛出自定义异常，并在报错信息中标注具体行号；最后给一个最小可用示例。
每一条都是可验证的约束。AI生成之后，你还能拿“文件缺失”“格式错误”两条去测它，测不过就说明没写到位。能验证的提示词，才是可交付的提示词。
3.2 处理报错的提示技巧：config.toml与模型不支持这类问题
最近不少人遇到“无法加载config.toml，对话串无法继续”，以及“gpt-6.1-sol模型不支持当前请求”这类服务端报错。先纠正一个误区：这种问题多数不是你的提示词写得差，而是客户端配置文件和服务端模型路由出了状况。
排查思路有几步：先确认配置格式，TOML对缩进、引号、数据类型都比较敏感，一个值是字符串却写成裸数字，解析就会断掉。再确认模型名是否真实存在，不少报错是本地代码里硬编码了一个不存在的模型标识，服务端不认就直拒连接。最后看网络日志，分清“请求没发出去”和“服务端拒绝”两种类型。
调试时有个小技巧，可以单独准备一条“连通性测试提示词”，内容就三个字“请回复OK”。它能帮你快速区分是模型本身有问题，还是你的复杂提示词触发了某些限制。先跑通最小请求，再叠加复杂逻辑，排查效率高很多。
3.3 编辑器场景下的提示词习惯
VSCode写C没有代码提示，Cursor里提示词泄露，Codex登录后模型不支持当前请求——这几个问题放在一起说，因为它们都指向同一个核心：让AI编程工具真正帮你干活的提示词习惯。
先说代码提示。VSCode里写C语言没有智能提示，多数不是提示词问题，而是没装扩展、没配置，includePath没指全。装了扩展后，写函数前先写清楚注释，让AI知道这个函数要干嘛，提示的有效性会大幅提高。
再说提示词泄露。你在Cue中写的提示词，可能被模型回显到对话里，或者在分享项目时不小心带了带出去。这提醒我们一个原则：不要把密钥、隐私路径、完整业务逻辑写进提示词，能变量化的就变量化，能引用外部配置文件的就别硬编码。提示词是给AI的指令，不是你的私有笔记。
Codex这类命令行智能体，和普通ChatGPT对话是两套逻辑。它更像操作系统的AI助手，可以执行命令、修改文件。提示词不能只描述目标，还要告诉它能动哪个目录、不能碰哪个文件、预期改动的粒度。写得越像给实习生的操作工单，执行越可靠。
4. 文生视频与多模态提示词模板
4.1 从“画一幅画”到“拍一段视频”的思维升级
文生视频提示词最近讨论度很高，像“seedance生成iris out舞提示词”这类热搜，说明很多人已经在尝试让AI生成舞蹈、镜头感、动态场景的内容了。文生视频和文生图的提示词逻辑有关联，但必须升级，因为多了时间维度和镜头语言。
静态图提示词描述瞬间，视频提示词描述过程。同样写一个人跳舞，静态图要的是姿态、灯光、表情，视频要的是动作起点到终点、节奏快慢、镜头如何移动、起幅落幅分别是什么。
4.2 一套能直接套用的文生视频提示词模板
综合我测试各家的经验，文生视频提示词套这个骨架上手最快：
场景与主体：谁在哪，什么状态；运动描述：主体有什么动作，动作幅度与节奏；镜头语言：固定镜头还是推拉摇移，视角高度；氛围节奏：光线色调情绪，节奏快慢；时长与起止：希望强调的开场和收尾画面。
拿“iris out舞”做个示例——这个词指舞蹈动作加上镜头光圈收缩的效果，一种常见转场手法。一个可用提示词长这样：
一个穿银白色紧身衣的舞者在暗色摄影棚里跳现代舞，动作流畅，从舒展的慢动作开始，逐渐加快节奏到转身跳跃；镜头缓慢推进到近景，在动作高潮处画面以iris out光圈收缩方式收尾；冷色侧光照亮人物轮廓，背景留黑，情绪克制但有力；总时长约8秒，开场画面是全景，结尾是光圈收缩到黑场。
这套模板的关键是把“时间轴”拆开：开场什么画面、中间什么动作、镜头怎么走、怎么收尾。每条都落在具体的画面上，AI生成时才有据可依。
4.3 长期实验后得出的文生视频提示词避坑清单
第一，否定词尽量少用。写“画面不要模糊”“不要抖动”，在部分模型里会被理解成反向指令或漏掉，建议换成正向描述，比如“保持画面锐利、主体清晰”。第二，速度描述要用有参照感的词，比如“缓慢推进”“逐渐加速”“突然停下”，纯写“速度快”容易失控。第三，镜头运动和主体运动分开写，别掺在一句话里，模型更容易分开执行。第四，长视频要分层提示，先定主体动作主线，再加镜头副线，最后补氛围细节，一次全塞进去容易互相干扰。
这些坑我全都踩过。最早我图省事，一个长句子把所有信息列完，生成结果经常是主体糊、镜头乱。拆成三板斧之后，成功率明显稳定了。
5. 提示词的调试与避坑实录
5.1 输出不稳定，先改提示词还是先换参数
很多人一遇到ChatGPT输出不稳定，就怀疑模型出bug，其实提示词层面还有好几个可调的旋钮。
第一，检查任务描述是否在同一轮里混入多个目标。“先分析后建议再润色”三个动作挤在一个提示词里，模型只能在中间态里打转，不如拆三次对话或三小段分步做。第二，给足示例锚点。两个好的参考案例比十句抽象形容词有用。第三，注意上下文长度。超长对话里早期的约束会逐渐被后续内容稀释，长任务做到一半发现风格跑偏，常见原因就是原始要求被冲掉了。
有的平台也会提供温度或随机性参数调整入口。温度调低，输出会更稳定、更偏向常规答案；调高则会更有创意但更飘。如果你是做数据整理、代码生成这种确定性任务，建议往低调；做头脑风暴、文案创意就往高调一档再拉回。先调提示词，再调参数，不要一上来就动参数。
5.2 上下文污染与常见连接异常的处理思路
“ChatGPT一直在重新连接”这种症状，不少人遇到过。先明确一点：它和提示词设计没有直接关系，属于客户端与服务的连接问题，但处理思路上也有相通之处，就是分层排查。
从上到下检查：网络是否稳定、平台服务状态是否正常、客户端有没有缓存异常、账号是否有配额限制。最快的办法是刷新页面、重新登录、或者换一个客户端验证，这三个动作能解决大半“一直重连”的情况。
更有参考价值的反而是“上下文污染”。一个会话里塞入太多不同主题的任务，模型会被早期对话干扰，后面的回答逐渐跑偏。我的习惯是：一个会话只干一类事，不同主题开新会话。这相当于提示词层面的“隔离部署”，减少上下文漂移。
5.3 提示词安全与价值沉淀
现在的提示词既是技能，也是资产。“Cursor提示词泄露”这类事件提醒我们：提示词里包含业务逻辑和未公开规则时，就要按机密对待。不要把密钥、内部地址、数据库结构直接写进提示词。更规范的团队可以做一套内部提示词模板库，把高频任务标准化，把风险点位去掉后再复用。
提示词工程的深层价值，是把个人经验结构化。你写得越多，越会发现，那些能复用的不是某条提示词，而是拆需求的方式。同样面对一个任务，有人直接问，有人先分析再问，后者的输出质量高出一个量级。
最后分享一个我自己的习惯：所有重要提示词我都会留一个备份副本。不是因为怕丢，而是改完一版之后往回看，能找到思路演进的路径。提示词写久了你会发现，真正让你变强的不是某一条神奇指令，而是每一次调试时逼自己把需求想清楚的这个过程。这大概就是提示词工程最真实的收获。
