先说一个现象同样是付费订阅用户有人拿 ChatGPT 只能写写周报、问问百科有人却能用它完整跑通“创意提案—视觉出图—自动化执行”一整套工作流。差别不在模型而在提示词。这篇是《精通 AI 提示》系列的第二篇重点从“会用”往“精通”推一步覆盖 DALL·E 图像生成的提示结构、面向办公自动化的提示策略以及自定义 GPT 的配置思路。上一篇讲的是提示词基本功这篇所有内容都会围绕真实场景展开包含可直接照抄的模板、踩过的坑和排查思路适合已经能熟练对话、但觉得输出不够稳定或不够深入的进阶使用者。1. 从“一问一答”到“上下策对照”提示词产出的底层逻辑1.1 高质量提示词的共同特征我把大量实测过的高质量提示词拆开看之后发现它们有一个共同骨架角色 背景 任务 约束 输出格式。这五个要素缺了任何一个结果都会明显下滑。先说角色。很多人在提示词里完全不定义“谁在回答”模型就只能默认用一个泛化的口吻输出。比如你写“帮我分析这份销售数据”和写“你是一名做了五年零售数据分析的运营顾问请帮我分析这份销售数据”后者输出的维度会明显更贴近业务。这不是玄学是模型在推理时确实会根据角色描述调整选词、结构和判断标准。背景信息是大多数人最容易偷懒的部分。直接问“怎么写一封催款邮件”和提供“客户已拖欠 45 天、之前承诺过两次付款、此项目毛利率只有 12%”这些背景得到的邮件逻辑完全不同。所谓提示词工程本质上就是“用文字把模型的概率分布往你想要的方向偏移”背景信息就是最有效的偏移工具。约束条件决定了输出的下限。告诉模型“不要使用专业术语”“字数控制在 300 字以内”“必须给出三个备选方案”这比只说“写一份方案”稳定得多。输出格式则决定了输出的可用性比如“用 Markdown 表格输出”“先给结论再给理由”“每一条建议后附一句解释”格式本身就是一种约束。1.2 上策与下策让模型自己比较着回答这套技巧我在接项目时用得最频繁也是热搜里“ai提示词上策下策的用法与示例”所指的核心策略。它的思路很简单不要只让模型给一个答案而是让它分别给出“上策”和“下策”再进行比较和取舍。比如我策划一个公众号选题目标群体是刚工作的程序员预算零、时间两天。提示词“你是内容策划。针对‘零基础入门自动化测试’这个选题请分别给出上策和下策两个执行方案。上策要大胆、有传播力、可能超出常规资源下策要保守、稳妥、执行成本低。每个方案说明核心亮点、执行步骤和可能的风险。最后对比两个方案给出你的推荐。”你会发现这个提示词逼着模型在两个不同方向上“各说一套”最后再强制它做一个评判。这样做的好处是把模型的推理能力逼出来它在生成上策时会更放得开生成下策时会更务实而最终对比阶段又会回到理性权衡。如果你只是单纯问“怎么做这个选题”模型往往只会给一个中庸的答案因为大多数人都是这么问的。同样的思路也能用在 DALL·E 出图上让模型为一个画面分别描述“写实风格”和“插画风格”的提示词再挑一个去执行。这比反复试错省时间得多。1.3 为什么同样的模型有人用出 80 分有人用出 20 分核心差距有三个。第一是是否明确说明上下文直接把一段代码丢给模型说“帮我改”和先说“这段代码用于 pytest 自动化测试当前在 Windows 下跑会卡在等待元素帮我排查”结果的前置方向就不一样。第二是是否清楚定义成功标准模型不知道什么叫“改好了”你需要在提示里说明“修改后必须保持原有接口不变、补充断言逻辑、给出可直接运行的完整代码”。第三是是否控制输出长度不控制长度的时候模型经常在 800 字左右开始重复车轱辘话这在自动化任务里特别致命。这三个差距都属于“提示词结构”问题不是模型能力问题。后面几章会反复用到这些原则。2. 面向创意场景的提示词从 DALL·E 出图到文案灵感的完整链路2.1 DALL·E 提示词的六要素结构创意场景最容易让人误以为“提示词就是形容词堆砌”。实际上DALL·E 3 对描述的理解方式更接近“分镜式认知”——它倾向于把你描述的画面拆解成道具、角色、环境、光线、风格等元素然后逐块生成。所以给它的提示词也应该按分镜逻辑组织。我实践下来最稳定的结构是六要素主体画面里的核心对象越具体越好“一只戴圆框眼镜的三花猫”。动作/状态主体在做什么“正在用笔记本电脑打字”。环境场景和背景“坐在老式图书馆的窗边窗外是黄昏的街道”。光线/氛围色调和光影“暖黄色台灯光线柔和逆光”。风格/媒介画面质感“水彩插画风格细节丰富”。镜头/构图视角和景别“特写镜头45 度俯拍浅景深”。你可以把这六个要素按序写成一整段句子然后用逗号或段落分隔。实测中发现用段落分隔比用逗号堆砌更容易让模型理解层次。一个反例如果只写“一只猫在窗边看书”DALL·E 输出的画面往往很普通因为模型不知道你要什么角度、什么色调、什么媒介。补全六要素之后画面会立刻专业起来。2.2 负面描述和参数控制避免 DALL·E 常见的翻车DALL·E 3 有个特点它并不像 Stable Diffusion 那样支持真正的负面提示词negative prompt但你可以用语言描述“不要出现什么”。经典用法是在提示末尾加一句“画面中不要出现文字、水印不要有其他动物入镜”。这个技巧在处理中文内容生成的画面时特别管用因为 DALL·E 生成中文文字经常出现乱码直接写“不要包含任何文字”可以规避。还有一个经常被忽略的参数——模型的 size 和 quality 参数。size 一般有三种方形、竖幅、横幅要注意提示词里构图的描述必须和尺寸匹配如果你选了竖幅却在提示词里说“全景横构图”出来的裁切效果就会很奇怪。quality 参数影响的是生成耗时和细节丰富度不是分辨率本身想要细节更丰富就选 high。2.3 用 ChatGPT 辅助 DALL·E先写后出的组合思路如果你想生成一组风格统一的系列图片我强烈建议先让 ChatGPT 把“风格描述词”抽出来再喂给 DALL·E。比如你希望生成一组系列插图用于公众号排版风格要统一就可以这样操作提示词“我准备用 DALL·E 生成三张插图分别是‘早上的办公室’‘午后的茶水间’‘深夜的工位’。请先分析这组画面共用的视觉元素提取出一份 80 字以内的风格锚点描述包括配色方向、线条风格、光影氛围然后分别套用这个锚点生成三组六要素式 DALL·E 提示词。”这个提示词的精妙之处在于“先分析共用视觉元素”这个步骤。它让模型把风格抽象成模板再生成具体画面提示词这样三张图会因为共用同一个锚点描述而明显更统一。直接让模型生成三张图它们往往是三套完全不同的视觉风格。文本创意场景同理。写提案、写故事、写标题都可以先让模型提炼一个“创作基线”比如统一使用的句式、语气、情感弧线然后再批量产出。毕业设计论文的 ai 提示词、故事灵感生成器 ai 提示词其实本质都是这个思路先让模型理解你的风格基线再让它帮你生成候选。3. 面向办公与自动化把 AI 从“答复工具”变成“执行引擎”3.1 提示词如何驱动自动化脚本生成办公自动化是提示词工程里收益最高、也最容易被低估的场景。很多人让 ChatGPT 写代码还是停留在“帮我写段 Python 处理 Excel”这个层级。这样写出来的代码往往能跑但稍微复杂一点就各种问题。实测中更靠谱的做法是“代入调试者视角的约束提示”。比如你要用 pytest 写一个自动化测试脚本可以这样组织提示“你是一名测试开发工程师。请使用 pytest 框架为以下函数编写单元测试函数代码如下。要求1. 覆盖正常输入、边界输入和异常输入三类用例2. 每个测试函数使用中文 docstring 说明场景3. 不修改被测函数内部实现4. 输出完整可运行的 test_sample.py5. 最后用注释说明运行命令。”注意这里的五个要求分别对应了覆盖范围、可维护性、代码边界、可交付性、执行方式。模型收到这种约束后输出的代码质量会显著高于“帮我写个测试脚本”这种开放式请求。3.2 分步拆解法让长任务永不半途而废ChatGPT 有一个让自动化场景很头疼的问题长输出经常中断。生成一份 2000 字的分析报告它在 1000 字左右有时会突然截断然后告诉你“是否继续”。这在工作中特别影响效率。我用的解决办法是分步拆解。把一个大任务拆成几个子任务一次只让它执行一个。比如“分析本月销售数据并生成报告”这个任务我会拆成三次对话第一次上传数据让它先总结“数据中的异常值和整体趋势”输出结果作为中间变量。第二次让它针对异常值进行归因分析列出可能的原因和验证方法。第三次把所有内容汇总让它生成报告框架再填充完整内容。这个做法的好处有三个一是避免长输出截断导致的反复重试二是每一步的结果你可以人工审核错误不会层层放大三是中间结果可以作为提示词的一部分反哺下一步任务相当于给模型提供了更充分的上下文。3.3 办公自动化场景的提示词模板我常用的几个模板直接分享出来都是经过多次实际测试的Excel 数据清洗提示词“以下是 列名/字段说明请基于这些数据完成清洗1. 识别并标记重复值2. 检查数值列的极值并给出处理建议3. 对文本列做去空格和统一格式处理4. 用表格形式输出处理前后对比。不要生成代码直接完成分析。如果需要代码请单独注明。”这个模板的关键是明确输出方式表格对比和边界哪些需要代码、哪些直接分析。实际上很多办公场景不需要脚本直接让模型分析数据反而更快。邮件/文档起草提示词“你是一名商务助理。请以 身份 给 对象 写一封邮件目的是 目标。要求1. 开头直接表明来意2. 分三点说明依据3. 结尾给出明确的下一步4. 语气专业但不生硬5. 控制在 200 字以内。”“开头直接表明来意”这个要求特别值得强调因为模型默认的邮件风格经常是先客套两句话再进入正题现在办公沟通更讲究效率。自动化测试报告总结提示词“以下是 测试框架名 的原始输出日志。请以测试负责人的视角总结1. 总体结论通过/失败/可疑2. 失败用例的共性特征3. 分别给出开发侧和测试侧下一步建议4. 输出为 Markdown 报告含小标题和表格。”这个模板在 pytest 和 Playwright 的实际项目里非常实用。特别是失败用例的共性特征分析模型经常能发现人眼忽略的模式比如“所有失败用例都集中在登录模块且都与 token 刷新相关”这种线索能直接节省半天排查时间。3.4 给模型安装“验收标准”和“自检步骤”进阶一点的操作是在提示词里加入“自检步骤”。比如让模型写完自动化测试脚本后追加一句“请检查你的代码1. 所有 import 是否必需2. 是否有遗漏的断言3. 是否考虑了超时和异常捕获4. 如发现问题直接输出修正后的版本”。这一步会触发模型的 self-correction 能力实测下来能明显减少低级错误。有人觉得这样做浪费 token但对比“写错—报错—再修”的往返次数多写一句自检的成本其实更低。这也是提示词工程里最值得养成的一个习惯。4. 自定义 GPT用提示词固化工作流而不是每次重新调教4.1 自定义 GPT 与普通对话的本质区别自定义 GPTGPTs的核心价值是把一套完整的提示词、知识文件和配置固定下来让任何人在任何时间打开它都能获得一致的行为表现。这相当于你亲手训练了一个“专岗员工”而不必每次开会都重新交代一遍工作内容。如果只把它理解成“预设提示词”那会错过它真正的能力。一个完整的自定义 GPT 由三部分组成Instructions指令告诉 GPT 它的角色、行为规范、输出格式偏好。Knowledge知识文件上传专属资料让 GPT 检索特定信息。Actions动作配置 API 接口让 GPT 可以调用外部工具执行操作。我最初搭自定义 GPT 时只写了 Instructions后来发现知识文件的价值可能更大。尤其是团队内部的历史方案、代码规范、设计规范这类资料上传之后GPT 的回答会从“泛泛而谈”变成“符合我们团队习惯”。这种体验升级是普通对话无法提供的。4.2 Instructions 的编写结构Instructions 本质上就是一份“最高优先级提示词”。我自己使用的结构是角色定义用一句话说清楚“你是谁”。工作目标说清楚“你存在的价值是什么”。行为规则用编号列出必须遵守的底线规则比如“回答必须用中文”“涉及代码时必须给出完整可运行版本”“不确定的信息不能臆测要明说”。输出格式规定默认输出格式比如“所有分析类内容都使用标题结论论据的形式”。边界与拒答明确什么情况下要拒绝回答比如“不提供法律/医疗等专业建议”“不编造数据”。示例给 1-2 个输入输出示例帮助模型校准风格和深度。这里有一个关键细节Instructions 里写的规则优先级一定高于用户每次对话里的临时指令。所以如果你希望它“每次回答都先给结论”这个规则必须写进 Instructions而不是等每次对话再说。因为普通用户并不会每次都补充这个偏好。4.3 利用 Knowledge 文件做专业增强Knowledge 文件适合放“参考性知识”不适合放“规则性指令”。一个常见误区是把 Instructions 应该承担的内容写进文件结果导致规则执行不稳定。我自己的经验是规则类内容放 Instructions参考类内容放 Knowledge。举个例子如果我要做一个“测试用例生成助手”Instructions 里定义输出格式规范Knowledge 里放团队的项目模块说明、历史接口文档、测试数据字典。这样 GPT 在生成用例时既遵守了团队的表达习惯又能引用具体的接口信息。注意文件格式会直接影响检索效果。纯文本和 Markdown 的检索效率通常高于 PDF 扫描件。表格数据用 CSV 更好因为 GPT 可以直接按行按列定位信息。上传多个小文件比分卷一个大文件效果好得多分散多个小文件比如按模块拆分它更容易命中目标内容。4.4 Actions 配置把对话变成操作Actions 是自定义 GPT 最进阶的一步。它的本质是把一个 API 接口以描述文本OpenAPI schema的方式告诉 GPT让它根据用户的自然语言请求自动决定要不要调用接口、传什么参数、怎么处理返回结果。如果你有办公系统的 API比如内部审批系统或报告生成接口配置好 Actions 之后用户可以直接对 GPT 说“把昨天的测试报告生成出来”GPT 会自己完成调接口、取数据、整理报告这一整套流程。这个效果相当于给 GPT 装上了手和脚从“只说话”变成“能干活”。配置 Actions 有一个核心难点你写给 GPT 看的接口描述必须比给程序员的接口文档更啰嗦。因为程序员能理解文档里的潜台词GPT 只能理解你显性写出来的部分。参数名、含义、取值范围、单位、默认值全部要写清楚。4.5 自定义 GPT 的发布和使用场景自定义 GPT 支持私有使用也可以分享链接给同事。我做过最成功的一个是“会议纪要助手”Knowledge 里放了项目背景和参会人角色说明Instructions 里定义了“按照决策、待办、风险三栏整理”的输出格式每次开会直接把录音转写文本粘贴进去立刻输出结构化纪要和待办清单。这大概帮团队每周省下两小时整理时间。另一个实际场景是“内容风格助手”把过往发布过的文章样例放进 KnowledgeInstructions 里写明目标读者、字数范围、禁止使用的词编辑团队所有人都可以借用它统一输出风格。这个场景对需要多人维护同一个自媒体账号的团队尤其划算。5. 构建复杂提示词时的流程化策略单元化与迭代5.1 单元化把大目标拆成小提示词单元构建复杂提示词时新手最常见的问题是“一次性把需求说完”。需求越多模型就越容易顾此失彼。比如你想让 ChatGPT 完成“数据获取 → 清洗 → 分析 → 可视化 → 生成报告”的完整流程如果你把这五步一口气写在一个提示词里大概率中间某一步会跑偏。正确的做法是“单元化”把流程拆成五个独立的提示词单元每个单元只承担一个明确任务。数据获取单元只管获取清洗单元只管清洗。上一个单元的输出直接作为下一个单元的输入。这样能让每个单元的指令更聚焦模型执行的成功率和稳定性都会上升。以自动化测试为例把“为电商网站订单模块编写 pytest 自动化测试”拆成三个单元环境与需求确认单元确认被测系统、浏览器、测试数据。用例设计单元基于确认结果生成测试场景清单。代码生成单元针对每个场景生成对应测试代码。单元化带来的另一个好处是易于重用。“用例设计单元”在另一个项目的测试工作中同样可以用只要微调需求描述即可。提示词资产化就是从这个环节开始的。5.2 迭代策略v1 输出先验证再优化提示词工程和其他工程一样很少能一次做对。我的习惯是永远给模型一个“低要求版本”的提示词让输出先跑起来再逐步增加约束。这个策略叫“渐进约束法”。比如我先写“用 Python 写一个读取 CSV 文件并统计每列缺失值的脚本。”得到可用脚本后再追加“请修改脚本1. 增加对不同编码的兼容2. 输出缺失率百分比3. 用表格打印前 10 行数据。”这样每一步的修改都有明确的参照物不会出现因为一次性要求太多导致模型崩溃或偏题的情况。在调试提示词时我会把每一次修改后的版本保存下来和输出结果做对比形成自己的修正记录。坚持下来你对提示词的敏感度会明显提高。5.3 保存提示词资产形成个人提示词库几乎所有做得好的 AI 从业者都会建立自己的提示词库而不是每次从零开始。我的提示词库按场景分成四类内容创作、代码开发、数据分析、办公协作。每一类下再按功能细分。保存提示词时有三个习惯值得借鉴一是版本管理同一个提示词的 v1、v2、v3 都要保留这样知道哪个改动导致了哪个结果变化二是变量替换把提示词里的专有名词用 占位符 标出方便下次复用三是失败标注记录哪些提示词在什么场景下效果不好防止再次踩坑。这套流程化的思维放到自定义 GPT 里也同样适用你的 Instructions 本身就是一套经过迭代打磨的提示词你的 Knowledge 文件就是提示词的参考资料。把它们体系化保存相当于给自己囤积了一套越来越值钱的资产。6. 真实环境中的崩溃排查从报错信息反推提示词修复方向6.1 对话串无法继续先检查配置再检查输入实际使用时经常遇到这个提示“无法加载 config.toml因此此对话串无法继续。请修复 config.toml”。第一次遇到时我真以为是个 bug后来排查发现这通常不是模型的问题而是客户端或 CLI 工具的配置文件错误。如果你用的是 OpenAI 官方命令行编程工具Codex CLI它的配置文件就叫 config.toml负责指定默认模型、API 密钥位置等参数。报错信息里出现“请修复 config.toml:model”往往代表 TOML 里配置的模型 ID 写错了——比如填了一个不存在的模型名像 gpt-6.1-sol 这种,或者格式上缺少引号、写错了键名。修复方法很简单打开 config.toml检查 model 字段是否设置为你账号实际可用的模型 ID把错误的字符串删掉或修正为正确值保存后重试即可。这类问题的排查思路值得强调先定位是“配置问题”还是“模型问题”。错误信息里带有“config”字样时90% 是配置文件问题如果你的代码调用了 API 但没有收到任何响应再看模型名是否拼错、API Key 是否有效。按这个顺序排查能少走很多弯路。6.2 模型不被支持的报错留意版本与接口兼容另一个高频报错是类似“the gpt-6.1-sol model is not supported”这样的提示。这类报错的本质是你请求的模型不在你当前账号或当前接口支持的范围内。可能原因有三种一是模型名称拼写错误对照官方文档核对即可二是你在旧版客户端里填入了较新的模型 ID客户端不认三是代码里把模型名写成了变量运行时把不存在的值传给了接口。排查时不要只盯着报错文本里的模型名去搜还要同步检查你正在用的客户端版本和接口版本。很多“模型不支持”其实是版本兼容问题升级客户端往往就解决了。如果是在 Codex 这类命令行工具里遇到你的账号类型也可能影响可用模型列表确认后台能访问的模型再填入 config 文件。6.3 客户端反复显示“一直在重新连接”“chatgpt一直在重新连接”这个现象多数场景下是本地网络环境或客户端缓存问题。但如果你是在调用 API 或命令行工具时遇到类似卡顿更常见的原因是代理相关设置干扰了长连接——具体排查边界取决于你所在环境和网络方案。基于合规考虑我这里不做任何网络访问技术层面的展开描述。从工程视角你可以先分清是 Web 端卡顿、桌面客户端卡顿还是 API/CLI 调用卡顿。后面两类优先检查配置文件和本地依赖环境会有更直接的收获。6.4 建立自己的“提示词报错对照表”最后我建议你把遇到的每一次报错都记录成一张对照表。格式类似这样报错关键词可能原因修复方向config.toml配置文件格式或模型字段错误检查 TOML 语法、模型 ID、密钥路径model is not supported模型名错误或版本不兼容核对官方模型列表、升级客户端对话串无法继续客户端上下文异常中断重新加载配置、清理损坏状态一直没有响应超时或上下文过长缩短上下文、重置会话这张对照表不需要多完整关键是记录你真实遇到过的场景。积累几个月之后它会成为你个人最有价值的调试手册比任何通用教程都更符合你的实际环境。我自己就靠这个习惯省去了大量重复排查时间。在真实的 AI 工作流里提示词从来不是一行文字那么简单——它是对模型的“岗位说明书”是你把想法变成执行力的翻译器。从六要素图像提示、上下策对照、分步拆解到自定义 GPT 的固化配置再到报错排查的反推思路每一个环节都在做同一件事让模型的输出更贴近你的真实意图。建议你先从今天这篇里选一个技巧放进明天的工作里试一次——等它真正帮你省下一小时你就会理解提示词为什么值得花时间研究。