提示词工程进阶：从DALL·E图像生成到自定义GPT的完整实战指南

先说一个现象：同样是付费订阅用户，有人拿 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.py；5. 最后用注释说明运行命令。”

注意这里的五个要求分别对应了：覆盖范围、可维护性、代码边界、可交付性、执行方式。模型收到这种约束后，输出的代码质量会显著高于“帮我写个测试脚本”这种开放式请求。

3.2 分步拆解法：让长任务永不半途而废

ChatGPT 有一个让自动化场景很头疼的问题：长输出经常中断。生成一份 2000 字的分析报告，它在 1000 字左右有时会突然截断，然后告诉你“是否继续”。这在工作中特别影响效率。我用的解决办法是分步拆解。

把一个大任务拆成几个子任务，一次只让它执行一个。比如“分析本月销售数据并生成报告”这个任务，我会拆成三次对话：

1. 第一次：上传数据，让它先总结“数据中的异常值和整体趋势”，输出结果作为中间变量。
2. 第二次：让它针对异常值进行归因分析，列出可能的原因和验证方法。
3. 第三次：把所有内容汇总，让它生成报告框架，再填充完整内容。

这个做法的好处有三个：一是避免长输出截断导致的反复重试；二是每一步的结果你可以人工审核，错误不会层层放大；三是中间结果可以作为提示词的一部分反哺下一步任务，相当于给模型提供了更充分的上下文。

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 与普通对话的本质区别

自定义 GPT（GPTs）的核心价值是：把一套完整的提示词、知识文件和配置固定下来，让任何人在任何时间打开它，都能获得一致的行为表现。这相当于你亲手训练了一个“专岗员工”，而不必每次开会都重新交代一遍工作内容。

如果只把它理解成“预设提示词”，那会错过它真正的能力。一个完整的自定义 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 里定义了“按照决策、待办、风险三栏整理”的输出格式，每次开会直接把录音转写文本粘贴进去，立刻输出结构化纪要和待办清单。这大概帮团队每周省下两小时整理时间。

另一个实际场景是“内容风格助手”：把过往发布过的文章样例放进 Knowledge，Instructions 里写明目标读者、字数范围、禁止使用的词，编辑团队所有人都可以借用它统一输出风格。这个场景对需要多人维护同一个自媒体账号的团队尤其划算。

5. 构建复杂提示词时的流程化策略：单元化与迭代

5.1 单元化：把大目标拆成小提示词单元

构建复杂提示词时，新手最常见的问题是“一次性把需求说完”。需求越多，模型就越容易顾此失彼。比如你想让 ChatGPT 完成“数据获取 → 清洗 → 分析 → 可视化 → 生成报告”的完整流程，如果你把这五步一口气写在一个提示词里，大概率中间某一步会跑偏。

正确的做法是“单元化”：把流程拆成五个独立的提示词单元，每个单元只承担一个明确任务。数据获取单元只管获取，清洗单元只管清洗。上一个单元的输出直接作为下一个单元的输入。这样能让每个单元的指令更聚焦，模型执行的成功率和稳定性都会上升。

以自动化测试为例，把“为电商网站订单模块编写 pytest 自动化测试”拆成三个单元：

1. 环境与需求确认单元：确认被测系统、浏览器、测试数据。
2. 用例设计单元：基于确认结果生成测试场景清单。
3. 代码生成单元：针对每个场景生成对应测试代码。

单元化带来的另一个好处是易于重用。“用例设计单元”在另一个项目的测试工作中同样可以用，只要微调需求描述即可。提示词资产化就是从这个环节开始的。

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 建立自己的“提示词报错对照表”

最后我建议你把遇到的每一次报错都记录成一张对照表。格式类似这样：

这张对照表不需要多完整，关键是记录你真实遇到过的场景。积累几个月之后，它会成为你个人最有价值的调试手册，比任何通用教程都更符合你的实际环境。我自己就靠这个习惯省去了大量重复排查时间。

在真实的 AI 工作流里，提示词从来不是一行文字那么简单——它是对模型的“岗位说明书”，是你把想法变成执行力的翻译器。从六要素图像提示、上下策对照、分步拆解，到自定义 GPT 的固化配置，再到报错排查的反推思路，每一个环节都在做同一件事：让模型的输出更贴近你的真实意图。建议你先从今天这篇里选一个技巧，放进明天的工作里试一次——等它真正帮你省下一小时，你就会理解提示词为什么值得花时间研究。