企业官网建设流程全解析

简介：《Ignite Your Creativity》是一本英文原版提示工程指南，面向学习AI艺术创作与ChatGPT对话式应用的人，适合入门到进阶的创作者、设计师和开发者系统补齐提示设计方法。全书先讲提示的构成要素，说明主题提示、修饰符与固化词各自的作用，再介绍负提示、零提示与变体提示的适用场景；随后进入ReAct提示、Midjourney等工具的AI艺术提示设计、迭代式细化流程和ChatGPT对话式提示的构建技巧，并专章讨论语言与意象在提示中的表现力，附有Leonardo应用实操案例与示例提示，供读者对照模仿。压缩包仅有1个PDF文件，约2.31MB，轻量便携，便于在电脑或平板上通读和检索。目前已有69人学习下载，读者能获得一套可复用的提示搭建思路、常见反例与优化路径，以及把文字描述稳定转化为画面效果的实践参考。

1. 提示工程的边界：为什么同一句话换个顺序，输出就判若两人

AI 艺术和提示工程这两个词现在被说得太轻，好像会打字就能出图。真做久了会发现，同一段描述换个词序、加一个限定词，出来的画面能差出一个档次。这里面没有玄学，只有一个很朴素的事实：模型接收的不是你的"意思"，而是一串被切碎的词元，每个词元都在给下一步的概率分布投票。提示工程做的事，就是把模糊意图压缩成一组能被解析的约束——做什么、用什么风格做、什么不能出现、输出成什么形状。这份指南把这件事拆成主体、修饰、固化、变体、负向、ReAct、迭代细化几个环节，其中真正拉开差距的不是第一条提示写得多漂亮，而是迭代式细化的收敛方法：你如何定义变量、如何只改一个、如何判断这次改动是有效还是噪音。理解了这一点，再去看那些所谓"神级提示词"，就不会只抄表面文字，而能看出它在哪个维度上施加了约束。

2. 主体与修饰词：一条提示的骨架是怎么搭起来的

把提示写成一句通顺的散文，是最常见的起点，也是最常见的瓶颈。指南给出的解法是把它拆成可组合的部件：主体决定"生成什么"，修饰词决定"往哪个方向生成"，固化词决定"每次都必须保持什么"，变体词决定"这次只测什么"。这四个槽位分开之后，调提示就从"改一句话"变成"改一个参数"，失败了也能定位到底哪一项出了问题。

2.1 主体（Subject）：先把坐标系锁死

主体是提示里第一个必须确定的槽位。原文的定义很朴素：主体可以是人、地点或事物，任何构成"你想达成的核心"的东西。之所以要把它单独拎出来，是因为模型的生成本质上是条件概率——给定前文，预测下一个词元。主体就是条件里权重最高的那一项，它决定了采样从哪一片分布区域里抽。

反例最能说明问题。"画一只猫"，这五个字给模型的条件极宽，模型只能返回最"平均"的那只猫：正面、居中、光线均匀、背景干净。这不是模型偷懒，是宽分布下的众数天然平庸。换成"雨夜里蹲在便利店霓虹灯下的流浪猫"，分布被压到一条窄带上，画面里立刻长出具体的东西：湿毛发、反光的地砖、冷色环境里的暖色光源。

原文还强调了两件容易被跳过的事。第一是受众：定义主体时要想清楚这条提示的产出给谁看，给同行看技术图和给大众看封面图，主体选词完全不同。第二是关键词选择，原文特别指出在处理大规模数据集时，没有清晰、简洁的关键词就根本无法收窄结果——放到今天多轮对话和批量出图的场景里，这条依然成立，主体词含糊，后面加多少修饰都救不回来。原文同时点出精确语言与模糊语言的分野：模糊或歧义的语言会得到不相关甚至误导性的结果。原因不神秘，模型处理模糊词的方式是把所有可能解释做加权平均，平均出来的往往是个四不像。

2.2 修饰词（Modifier）：形容词不是装饰，是旋钮

原文把修饰词定义为"添加到提示里的额外单词或短语，用来提供上下文、清晰度或具体性"，并给了几个很典型的改写：把"全球变暖"改成"全球变暖的原因与解决方案"，把"健康饮食"改成"简单实用的健康饮食建议"，历史课上的提示加上"对社会的影响"，创意写作里加上"魔法王国与神奇生物"。这些例子的共同点在于，修饰词改的不是语气，是任务类型和信息密度。

从机制上分，修饰词有三类，作用点完全不同：

• 方向性修饰，比如"原因与解决方案""对社会的影响"。它切换的是任务范式，从描述切到分析，输出结构会整体重排。
• 限定性修饰，比如"简单实用""面向零基础"。它压低某一类分支的概率，把学术腔、理论化的表达推远。
• 氛围性修饰，比如"魔法王国""霓虹雨夜"。在图像模型里它拉的是风格词元的权重，改变的是视觉质感而不是内容主体。

一个血泪经验是：不要在同义词上堆叠。"美丽、漂亮、好看、精致"四个词扔进去，概率不会更集中，只会让模型在近义词区间里来回摇摆，输出反而更飘。正确做法是一个维度只留一个词，加之前先想清楚它在收窄哪个方向。可复现的验证方法也简单：先拿裸主体跑一次当基线，再每次只加一个修饰词跑一次，两次结果放在一起比，改动的贡献就一目了然。

2.3 固化词与变体词：稳定性和多样性的两个旋钮

原文提到固化提示（solidifier）用来"加强"提示，也提到变体提示（variation prompt）。这两者的关系，我一般会这么理解：固化词是跨批次不变的那一段，变体词是每次只动一项的那一段，合起来就是一个控制变量实验。

固化词通常承载四类内容：输出格式（字段、长度、比例）、风格锚点（摄影介质、渲染方式）、构图约束（视角、留白）、禁止项（不要文字、不要水印）。它的价值不在于让单次结果更好看，而在于让多次结果之间可比——没有可比性，你就永远不知道改动是好是坏。

变体词则相反，它存在的唯一目的就是被替换。替换时最忌讳"顺手多改一个"，因为一旦两个变量同时变动，结果变好你不知道是哪个起的作用，变差你也不知道该回滚哪一项。这个道理和调参一样，写在纸上都懂，真上手时几乎人人都会犯。

下面这段代码把四个槽位落成一个可执行的模板，重点不在代码本身，而在那条白名单校验——它强制你先把变量声明出来，才能改。

# 提示模板：把自然语言提示拆成可替换槽位 # 目的不是让提示"更高级"，而是让每次改动只影响一个变量 TEMPLATE = { "subject": "a stray cat", # 主体：只放名词短语，不塞形容词 "modifiers": ["rainy neon street"], # 修饰：一个维度一项，避免同类堆叠 "solidifiers": [ # 固化：跨批次冻结，保证结果可比 "35mm photography", # 风格锚点 "rule of thirds, eye level", # 构图约束 "no text, no watermark", # 禁止项 ], "variations": {"color": "teal and orange"}, # 变体：允许变动的维度集合 } def build(tpl, **override): """override 只允许覆盖 variations 里预声明的键，防止一次改多个维度""" for k in override: if k not in tpl["variations"]: raise KeyError(f"{k} 未在 variations 中声明，先声明再改") merged = {**tpl["variations"], **override} parts = [tpl["subject"], *tpl["modifiers"], *tpl["solidifiers"]] parts += [f"{k}:{v}" for k, v in merged.items()] return ", ".join(parts) print(build(TEMPLATE)) print(build(TEMPLATE, color="muted grey")) # 只改色彩，其余全部冻结

这段代码的关键逻辑有三处。subject单独成槽，是为了逼你把主体写成干净的短语，避免形容词混进来污染坐标系。solidifiers独立成组，是为了让它在所有实验里原样复现，一旦你开始"临时调一下风格词"，对照就失效了。build里的白名单校验是防守动作，它把"顺手改两个变量"这种失误挡在运行之前——报错比出一张看不懂原因的废图便宜得多。参数上，modifiers每项只描述一个维度，variations里的键名建议直接用画面或文本的可观测属性（色彩、景别、语气、长度），方便事后归因。

3. 文生图提示的结构化语法：五段式与权重到底改了什么

图像提示和文本提示最大的差别在于容错率。文本输出跑偏了还能读，图像跑偏了就是一张废图，而且你很难从图里反推出是哪句话导致的。所以图像提示更依赖结构，而不是文采。

3.1 五段式结构：让每个词各归其位

把一条图像提示拆开，稳定可用的结构大致是五段：主体、媒介与风格、构图与视角、光照与色彩、技术渲染。指南里讲 AI 艺术提示设计的那一章，本质上也是在做这种分层——先确定画面里有什么，再确定它被怎么拍出来。

为什么要分段而不是写成一句流畅的话？因为文生图模型的文本编码器会把提示切成词元，再和视觉特征做对齐。当风格词散落在句子各处时，多个风格描述会竞争同一组视觉方向，谁也没压倒谁，最后的画面就是风格混叠：一半油画一半照片，谁看都别扭。分段之后，同一段内部的词在语义上互相支持，冲突概率明显下降。

优先级也需要明确。主体必须前置，因为注意力对靠前的词元更敏感，主体放在句末，模型很可能把它当成修饰成分吃掉。风格词放在主体之后、构图之前，因为风格决定的是"整体质感"，它应该先于局部约束生效。禁止项和建议项放最后，它们不参与画面构建，只做过滤。

3.2 权重与顺序：括号和数字改的是条件强度

加权语法在各家工具里写法不同，有(word:1.3)这种带系数的，也有(word)++这种叠括号的，但语义是一致的：给某个词元的条件向量乘一个系数，系数大于 1 就往那个方向拉，小于 1 就往外推。

这里有两个必须知道的边界。第一，加权不是线性的。系数从 1.0 调到 1.2，画面变化是渐进的；从 1.3 调到 1.8，经常直接崩——过饱和、结构扭曲、主体变形。原因是权重放大到一定程度后，该词元在特征空间里压过了其他所有约束，包括"这应该是一张正常照片"这种基础约束。第二，加权语法不通用。同一段带括号和数字的提示换一个工具，括号很可能被当成普通文字处理，输出里真的给你画出括号。跨工具迁移提示时，第一件事是把加权符号全部剥掉，只保留纯文本，再按目标工具重写。

顺序敏感性也值得单独说。同一个词放在开头和放在结尾，效果差别可能比调权重还大。所以做对照实验时，"调换词序"本身就应该被当成一个独立变量来测，而不是改提示时顺手做的调整。

3.3 三组示例的逐段拆解

下表把同一条提示的槽位拆开，看每一格改动会牵动画面里的什么。这种表格比背提示模板有用得多，因为它给的是因果，不是答案。

用这张表做实验有个技巧：每次只动一行，其余四行整行复制。动"光照"时发现画面变冷了，那是光照的贡献；如果你同时把"风格"从胶片改成数码，画面变冷就说不清是谁干的。三组示例跑下来，你对自己这套工具的词感基本就建立了——这比收藏一百条提示词管用。

4. 从一次性提示到协议：零示例、ReAct 与多轮对话

前面讲的都是单轮、单次的提示构造。一旦任务变复杂，单轮就撑不住了：模型要么漏步骤，要么自己编一个中间结论往下推。指南后半部分给的三个方案——零示例提示、ReAct、对话式提示——本质上都是在把"一次性问答"升级成"有协议的交互"。

4.1 零提示：没有示例时靠什么对齐

零提示指的是不给任何输入输出样例，只给指令。它和少样本提示的差别在于，模型失去了"照猫画虎"的参照，只能靠预训练阶段积累的任务先验来理解你要什么。

这个先验很不稳定。同一个指令，模型可能理解成"写一段介绍"，也可能理解成"列一个清单"，还可能理解成"给一段分析"。所以零提示要成立，必须显式补齐三件套：任务（做什么，动词要具体）、格式（输出长什么样，字段、层级、字数）、边界（信息不足时该说什么，什么情况该拒答）。

第三件最容易被忽略，也最容易翻车。不写边界，模型遇到不知道的东西不会停，它会补一个听起来很合理的答案。补出来的内容语法通顺、格式工整，唯一的问题是错的。所以零提示里那句"如果资料中没有相关信息，直接回答无法确定，不要推测"，不是客套话，是给模型一个合法的退出通道。

4.2 ReAct：把"想一想"变成可观察的词元

ReAct 的核心是把推理和行动拆成交替的步骤，而不是让模型一口气吐出最终答案。它的骨架是三段循环：先写 Thought，说明当前判断和下一步打算；再输出 Action，指定要调用的工具和参数；执行之后把 Observation 原样回填；然后回到 Thought，基于新观察继续。

这套结构为什么有效，可以从两个角度看。一是计算层面：原本藏在一次前向计算里的多步推理，被摊开成多个词元步骤，每一步的结果都进入上下文，下一步的概率计算建立在这些中间结果之上，复杂推理的负担被分摊了。二是纠错层面：Action 交给外部工具执行，Observation 是真实返回值，模型编造的中间结论会在这一步被现实打脸，然后它有机会在下一个 Thought 里修正。

代价也很明确：token 消耗成倍增长，延迟变高，而且一旦某一步的 Observation 格式混乱，后续推理会沿着错误前提一路跑偏。所以 ReAct 适合"步骤可验证、工具有确定返回值"的任务，不适合开放式创作。

4.3 多轮对话：上下文是资产，也是负债

对话式提示的直觉是"聊着聊着就清楚了"，但实际用起来经常是"聊着聊着就散了"。原因是上下文窗口是有限预算，而且历史消息不会自动失效。你在第五轮说"改成更简短的版本"，第三轮那句"尽量详细展开"依然躺在上下文里，两者权重接近，模型就会给你一个又长又短的四不像。

稳住多轮的办法是主动做上下文管理，而不是指望模型自己记住重点。常见做法是每轮开头重述一次"当前任务 + 硬约束 + 已确认的决定"，把漂移拉回来；历史过长时，把前面的对话压成几条结论再放回去，原始对话丢弃；关键约束单独成行，不要混在长段落里。

下面这段是 ReAct 的最小骨架，把上面几节的东西串起来。工具函数是假的，结构是真的。

# ReAct 最小骨架：推理与行动交替，观察结果回填上下文 def react_loop(question, tools, max_steps=5): history = [f"问题：{question}"] for _ in range(max_steps): ctx = "\n".join(history) # 1) Thought：先写判断，不允许直接给答案 thought = llm(f"{ctx}\n请先输出 Thought：当前已知什么、下一步要查什么") history.append(f"Thought：{thought}") # 2) Action：约束成结构化字段，方便程序解析 action = llm(f"{ctx}\n输出 Action: <tool>(<arg>) 或 Final: <答案>") history.append(f"Action：{action}") if action.startswith("Final:"): return action.split(":", 1)[1].strip() # 3) Observation：真实执行，结果原样回填，不做改写 try: name, arg = parse_action(action) obs = tools[name](arg) except Exception as e: obs = f"执行失败：{e}" # 失败也回填，让模型知道这条路走不通 history.append(f"Observation：{obs}") return "达到步数上限，最后一条观察：" + history[-1]

几个参数值得说明。max_steps是止损阀，ReAct 在工具反复返回无用信息时会陷入循环，没有上限就是无限烧 token。Observation必须原样回填，任何"顺手整理一下"都会污染后续推理，模型会把你整理后的版本当成事实。解析失败时把异常信息当观察结果回填，比直接抛错更有用——模型看到"参数格式不对"，下一步往往能自己改对。Final:是显式终止信号，比让模型"觉得差不多了就停"可靠得多。

5. 避坑清单：六个把提示越改越烂的常见动作

提示调优最反直觉的地方在于，很多"优化"动作本身就是问题源。下面六条是按现象倒推出来的，每条都能对上具体的机制。

5.1 图像侧：三个高频翻车现场

第一条：一条提示塞进五个风格词。现象是画面四不像，既不像油画也不像照片，细节糊成一团。原因在于风格词竞争同一组视觉特征方向，权重接近时没有赢家，模型只能做加权平均。解决办法是只留一个主风格词，其余降权到 0.5 以下或者直接删掉，让主风格拿到决定性权重。

第二条：用负向词硬压解剖错误。现象是越写"不要多手指"越多手指，越写"不要畸形"越畸形。原因在于负向词依然会激活对应概念，它在特征空间里做的是"往反方向推"，但当这个概念本身很强时，推力不够，反而因为被提及而加强了存在感。解决办法是改成正向替代加构图规避：把"不要多手指"换成"双手插在口袋里"，从根上减少手部露出，比对抗可靠。

第三条：直接复制别人的长提示当模板。现象是在别人那里出神图，在你这里出废图。原因不止是随机种子，还包括不同模型版本的词表差异、权重语法不兼容、以及那段提示里大量词是针对特定模型调过的。解决办法是先固定种子，再把长提示按五段式切开逐段替换，只保留结构不保留具体词，这样迁移的才是方法而不是巧合。

5.2 文本侧：三个隐形陷阱

第四条：对话里改了需求，但没有重述。现象是模型答的还是上一轮的任务，你明明已经说了"换成另一个方向"。原因是上下文里旧指令的权重并不低，新指令只是又一条消息，两者并列存在。解决办法是每轮开头用一句话重述当前任务与硬约束，把新指令的权重顶上去，必要时把已废弃的旧指令显式作废。

第五条：用"更专业一点""再深入一些"这类模糊修饰。现象是输出变长了，但准确度没变，甚至更啰嗦。原因是这类修饰不改变约束集，只改变长度和语气分布，模型能做的只是把话说得更绕。解决办法是把模糊要求翻译成可验证的契约：要求包含哪几个字段、每个字段多少字、必须引用哪些材料、禁止出现哪些表述。

第六条：把整篇参考文档塞进上下文。现象是关键信息被淹没，模型引用了一句边角料，主线结论反而丢了。原因是上下文预算有限，长文档会稀释注意力，位置靠中间的内容最容易被忽略。解决办法是先摘要再引用，把结论前置，把要引用的段落单独摘出来放在指令附近，而不是整篇丢进去。

这六条有个共同点：它们都是"想省一步"导致的。省掉重述、省掉重写否定、省掉切分结构，短期看是效率，长期看是反复返工。黑匣子不可怕，可怕的是改了参数却不记录改了什么。

6. 收敛：一次只改一个变量，比一次改十个更接近目标

迭代式细化这个词听起来很温和，实际执行起来是全文最费纪律的一节。多数人调提示的过程是这样的：出图不满意，凭感觉加三个词，再出图，还不满意，删两个词再加两个词。跑了二十轮，终于有一张能看，但你不知道是哪几个词起的作用，下次遇到同类需求还得从头再来。这不是在细化，是在碰运气。

把提示当代码管，是我认为这份指南里最值得带走的一条隐性主张。落到操作上就是三件事：版本、对照、回归。版本是每条提示带编号，改了什么写在旁边，别嫌麻烦，一周之后你会感谢自己。对照是同一批次里只允许一个变量不同，其余整段复制。回归是攒一组固定输入，每次改完提示都拿这组输入跑一遍，看老场景有没有被改坏——提示调优最常见的失败不是新需求做不好，而是改好了新的、弄坏了旧的。

设计取舍上，有三组矛盾值得提前想清楚：

没有普适解，只有场景解。批量出图、要交付的场景，固化词拉高、约束写死；探索风格、找灵感的阶段，固化词压低、允许跑偏。真正要避免的是在同一批实验里两种取向混用——那等于同时动了好几个变量。

从那以后我每次改提示都强制走一遍单变量对照，哪怕只是加一个逗号也要记一条。听起来过分，但正是这个习惯让我从"这张图为什么好"的困惑里走出来，变成能说清"这一项改动带来了什么"。这份指南的价值也在这里：它给的不是一堆可以直接抄的提示词，而是一套能让你自己收敛到目标的方法。希望帮到你。

本文还有配套的精品资源，点击获取