企业官网建设流程全解析

你有没有遇到过这种情况：同一个问题，上午问是一个答案，下午换一种说法，又变成另一个答案。更气人的是，明明觉得自己把要求写得够清楚了，模型还是交出一堆“正确但没用”的内容。

多数人习惯把锅甩给“模型随机性”，但作为一个几乎天天跟大模型打交道的人，我越来越确信：大部分“不听话”，不是模型的智能问题，而是你的Prompt没给够坐标。六模块Prompt结构，就是一套把随口一问变成结构化任务说明书的方案。它适用于写文案、做分析、写代码、整理资料等一系列日常场景，也适合产品、运营、数据和开发岗的同学参考。今天这篇，我不讲虚的，直接把这套结构拆开揉碎，连同调试思路和踩坑经验一起放出来。

1. 为什么你的指令总被模型“自由发挥”：失控的本质与这套结构的由来

1.1 一句话与一本书的差距：模型如何理解你的真实意图

先看一个典型场景。某内容团队的同学想写一篇“家用咖啡机怎么选”的公众号文章，原始指令是：

“写一篇关于咖啡机的文章，要专业一点。”

关键词是“专业”。但模型不知道你是写给刚入门的小白，还是写给深度玩家；不知道是带货文还是科普文；不知道平台是小红书还是公众号；不知道期望的字数和结构。结果模型只能做一件事：把训练语料里最常见的咖啡机文章元素统统拼一遍——从品牌历史讲到萃取原理，从摩卡壶讲到全自动机，逻辑上没有硬伤，但放到具体场景里根本不能用。

这不是模型“笨”，而是信息不足时它只能“平均化”。大模型本质上在做下一个词的概率预测，当所有候选方向都没有被你的指令优先加权时，它就往概率最大、最平坦、最不出错的方向走。这个方向写出来的东西，往往就是那种看哪儿都对、用哪儿都不行的文字。说得直白一点——你只给了一句话，它只能还你一本书的废话。

1.2 你需要的是一份“需求说明书”，而不是一个更长的句子

很多人觉得“那我写详细一点不就行了”，这个思路对了一半，但坑也很深。你写一大段流水账，把所有要求连在一起，模型照样会迷失。问题不是信息量不够，而是信息没有分类。就像跟一个逻辑能力很强、但完全不了解你的外包员工沟通，你只发一大段“客户背景、注意事项、平台风格、字数限制”揉在一起的聊天记录，他照样容易抓不住重点。

六模块结构的本质，是把这个“外包沟通”变成一个规范的“需求说明书”。每个模块各管一件事，角色告诉它用什么视角回答问题，背景告诉它关于什么，任务告诉它要产出什么，约束告诉它什么不能做，格式告诉它交付物长什么样，示例告诉它“好”的标准是什么。

有了这套结构，你每一次跟模型的对话，都从“随口一问”升级成了“正式需求下发”。

2. 六模块全景图：角色、背景、任务、约束、输出、示例各自管什么

2.1 六模块总览表：职责、机制与对应关系

这一套结构不是拍脑袋定的规矩，而是把一次有效沟通里必须要讲清楚的信息分成了六类。先看总览：

每个模块都不是“锦上添花”，而是“缺一不可”。角色缺失，模型语气就会漂移，像请了个临时工却不说岗位要求；背景缺失，它不知道任务发生在什么场景；任务目标缺失，它就没有明确动作；约束缺失，它就会越权发挥；格式缺失，交付物千奇百怪；示例缺失，风格只能靠猜。

2.2 为什么是六个模块，不是四个也不是八个

有一次跟某团队讨论这套结构，有同学问：为什么一定是六个？能不能精简成“角色+任务+约束”三个？

我的看法是：三个当然能跑通，但稳定性会差。你可以把六个模块看成三个层面——“上下文层”负责让模型弄清楚“谁、在什么情况下说话”（角色+背景）；“指令层”负责明确“要什么、不要什么”（任务+约束）；“交付层”负责定义“结果长什么样”（格式+示例）。如果少了交付层，模型可能给你一篇好内容，但结构完全没法直接复用；如果少了上下文层，内容又是正确但没有个性。

六个模块不是越多越好，而是刚好覆盖了一条完整指令需要的“描述信息维度”。再往下加会冗余，比如加一个“情绪模块”、加一个“文风模块”，都可以归并到角色或约束里；再往下减，就会出现不可控的短板。

3. 逐模块精讲：每个模块怎么写、写多少、哪些坑别踩

3.1 角色定位：给模型一个“思考的角度”，而不是一个空洞人设

角色定位是第一模块，目的是控制模型输出的“视角”。很多人会写“你是全网最厉害的文案大师”，这种写法不是没用，是太虚。模型很难把“最厉害大师”转成具体的措辞和判断标准。

更有效的写法是给出“岗位+领域+特长”的组合，比如：

• 你是一位负责家用小家电类目的电商运营，擅长把专业参数翻译成消费者能感知的生活场景。
• 你是一名熟悉咖啡设备选购的编辑，了解新手常见误区，说话直接、不绕弯。

这样模型就知道自己应该站在什么位置上，用什么样的语气、关注什么样的信息。还要提醒一句：不要在角色里给它“虚构背书”的机会。比如描述成“你是获得某认证的品酒师”，模型后续可能顺着编造证书编号和评分结果。尽量选“能力范围内可承担的描述”，别给说谎留口子。

3.2 背景信息：少则糊、多则乱，控制在三五行之内

背景模块是给模型限定“领域范围”的，不是给它上课的。很多人写背景像写百科，比如“咖啡机是一种家用电器，通过加热水并使其穿过咖啡粉进行萃取……”——这种内容除了占上下文窗口，还会把模型带往“百科体”方向。

正确的背景写法是“告诉它你知道什么”，而不是“请你学习”：

• 产品：家用半自动咖啡机，价位500-800元。
• 人群：刚工作、第一次尝试意式的年轻人，家里空间不大。
• 平台：电商商品详情页，浏览时间短。
• 核心卖点：操作不劝退、小户型友好。

背景信息必须与任务直接相关。无关背景越多，模型越分不清重心，最后它可能把精力放在你根本不关心的“品牌历史”上，而忽略了你要的卖点提炼。

3.3 任务目标：动词驱动、单一主目标、可验证

任务模块是整个六模块里的“主心骨”。我的经验是三句话：

第一，用动词开头。“写”“列出”“分析”“总结”“对比”“提出”——每个动词都会把模型导向不同类型的操作。

第二，一个主目标。如果你一次给三件不太相关的事，模型会端水，每一件都做得不深。更好的做法是拆解脱：先“提炼两个核心卖点”，再“基于卖点写三个首屏文案版本”，用编号列出步骤，模型就会按顺序执行。

第三，数量要给死。“三个版本”就是三个，不要“几个”“一些”。只要能用数字衡量的，都尽量写进任务里。可验证的任务目标，是后面判断输出好坏的基础。

3.4 约束条件：禁区条款的正确写法，少用“不要”开头

约束条件是最容易被写坏的模块。很多人一上来就是：

• 不要写得太书面
• 不要太长
• 不要写成说明书

问题在于，模型对否定指令的捕捉并不可靠，反而经常出现“你越说不要，它越注意那里”的情况。更有效的做法是用正面替代给出方向：

• 用口语化的短句表达，每句不超过20字
• 每一条控制在80字以内
• 如果写了具体技术参数，只允许使用产品页已有数据

写清楚“要怎么做”，模型遵守的概率远高于“不能怎么做”。当然，如果确有硬边界必须靠“禁止”来声明，比如“严禁编造实测数据”，那还是得明确写出来。约束要尽量可以验证：能数的（字数）、能比的（不超过三个）、能检查的（不得出现某个具体表述），这类约束遵守率最高。

还有一个细节：当约束和任务产生冲突时，模型往往会优先满足靠后出现的、更具体的约束。如果任务里写了“详细展开”，约束里又写了“每条100字以内”，模型容易犹豫。这时候要把两个信息合并写清楚，比如“每条100字以内，但核心卖点必须完整表达”，优先级就明确了。

3.5 输出格式：给结果一个固定的“壳”

输出格式在我心里的地位，是“优先级最高的约束”。为什么单独列成一个模块？因为不指定格式时，模型有时给大段文字、有时给列表、有时还夹带一两个Markdown标题，每次都不太一样。一旦你明确指出“按表格输出”“按JSON结构输出”“每条用版本一/版本二开头，每条之间空一行”，输出就会稳定得多。

固定格式的另一个额外价值，是可自动化。我自己做过一些数据处理流程，Prompt输出是强格式化的JSON，后段脚本直接解析，节省了大量洗数据的时间。哪怕你只是写文案，固定格式也会让“挑哪一版”这个动作变快。

格式不妨给得很具体：用什么开头、每条之间要不要空行、要不要编号、是否要加粗标题。给得越细，模型越不需要动脑筋“自己挑一个好看的排版”。

3.6 示例参考：正例放在最后，别用反例找存在感

示例参考是很多人容易忽略的模块。给与不给，差异非常明显。模型非常擅长“模仿”，你给它一个正例，它就会把注意力锚在那个风格上。

有几个关键要点：

示例一定要是正例。有人喜欢在Prompt里写“不要像这样写：某某文案”，这种做法效果不稳定——模型可能记住内容本身，却忘了“不要”这个指令。正例则简单直接：想要这个风格，就给它看这个风格。

示例放在最后。如果示例放太靠前，模型容易被示例的格式锁住，后面的任务和约束反而被弱化。先讲清楚要求，再用示例收尾做风格锚定，这是最稳固的顺序。

一个正例通常够用。要展示两种不同风格，可以给两个正例并标好“版本一参考这个、版本二参考那个”。超过三个，模型反而容易把不同风格混在一起。

4. 一个完整案例的从零拆解：从一句废话到精准输出

4.1 失败的起点：一句“写个文案”带来的灾难

拿一个真实的虚构案例来走一遍全流程。某电商平台的运营同学想给一款家用半自动咖啡机写详情页首屏文案，最开始的输入只有一句：

“帮我写个咖啡机的文案，要吸引人。”

模型给的是这种：

“咖啡机，不仅是工具，更是一种生活态度。每一次萃取，都是对味觉的极致追求……”

听着挺像那么回事，但放在电商详情页里毫无转化力。空泛、堆砌形容词、没有任何针对人群的信息，“吸引人”成了唯一的指挥棒，模型就用它训练数据里最常见的咖啡机文案模板来对付你。

4.2 完整六模块Prompt示范：一段可以直接抄的模板

同样的需求，换成六模块之后是这样的：

【角色】 你是一位在电商平台负责家用小家电类目的资深运营，擅长把产品参数翻译成消费者可感知的生活场景，文字口语化但有分寸。 【背景】 产品：一款家用半自动咖啡机，价位500-800元。 目标人群：刚工作、第一次尝试意式咖啡的年轻人，家里空间不大。 平台：电商商品详情页，消费者浏览时间短。 核心卖点：操作不劝退（不需要专业咖啡知识也能做出合格意式）、小户型友好。 【任务】 写3个版本的详情页首屏文案，每个版本都以“给第一次做意式咖啡的你”作为第一句。 每个版本突出同一个核心信息：这款机器让你在家轻松做出咖啡馆级别的意式咖啡。 【约束】 每条文案控制在80字以内。 不使用“高端大气”“萃取纯粹”这类空泛词。 不出现具体水温、压力等技术参数，除非产品页已有数据。 语气生活化，可以有适度的“种草感”，但不要浮夸。 【输出格式】 按“版本一：”“版本二：”“版本三：”分行输出，每个版本之间空一行。 【示例】 给第一次做意式咖啡的你： 不用研究粉水比，不用盯着压力表，把咖啡粉装进去，按键，一杯油脂漂亮的意式浓缩就出来了。 （参考这段的语气和文字节奏，不需要模仿具体内容。）

把这份Prompt交给模型，输出的内容会明显发生三个变化：语气从“百科腔”变成“种草口吻”，重点从“泛泛的产品介绍”变成“新手友好”，内容里不再出现那些不需要的所谓专业术语。这是六模块结构最直观的效力。

4.3 结果差异与迭代过程：一次只改一个字段

实战中第一次跑六模块版，输出已经能用了，但出现一个小问题：版本二偏长，加起来快90字，超出了“80字以内”的约束。

这时候我强调一个原则：一次只改一个模块。我没有重写整个结构，也不改任务内容，只把约束从“每条文案控制在80字以内”改成了“每条文案必须控制在80字以内，超出一字都算不合格”。同样的模型，第二次输出三条都在上限内。原因是用词从“建议性”变成了“硬性条款”，模型对“必须”的响应强度明显上了一个台阶。

如果第一次就把任务、约束、角色全改了，输出变了你也不知道是哪一步起的作用，后面就没法调试。结构化Prompt之所以好调，就是因为每个模块是一个独立变量。

5. 模块顺序的底层逻辑：为什么角色必须在最前面，示例必须放最后

5.1 注意力分配：模型对长输入的“开头更敏感”

很多人按习惯把背景放最前面，或者把示例放最前面，但这不是最优解。大模型处理长文本时，对开头部分通常有更强的注意力，中间段的信息容易被稀释——业内把它叫“lost in the middle”现象。你的关键信息放在哪里，模型对它的重视程度就有差别。

所以把角色放在最前面，等于先让模型“戴上正确颜色的眼镜”；背景紧随其后，把镜头框进具体领域；任务再往后，把镜头对准具体动作。如果把关键约束埋在一大段背景的第三行，很可能会被模型忽略。这也是为什么约束要单独成块、并且尽量靠后放——它需要有自己的存在感。

5.2 从角色到示例：一次典型的“收敛漏斗”

我习惯把六模块的顺序看成一条收敛漏斗：

角色决定视角，背景收缩到领域，任务聚焦到动作，约束排除干扰，格式固定载体，示例锁定风格。每一步都在缩小模型的输出解空间。如果顺序打乱，比如示例放最前，模型就会被示例里的具体措辞锁死，后面的角色设定和约束反而成了“仅供参考”。

曾经有次我把示例提到最前面，角色放在最后面，模型写出来的东西没一句像“资深运营”，全是示例的腔调。把顺序调回来之后，同样的内容组合，输出质量立刻稳定了。所以这个顺序不是排版洁癖，是真的有机制在背后起作用。

5.3 分隔与标记：让模块更容易被模型识别

想让六模块真正生效，排版也要动点脑筋。我习惯每个模块名称用【】括起来，模块与模块之间空一行。这样模型能更清晰地判断“你现在切换到了一个独立字段”。

如果Prompt更长，也可以用Markdown的三级标题做分隔，或者用XML标签包裹。核心思路都一样：尽量给模型显式的结构信号。空行非常重要，它能缓解长上下文里信息互相纠缠的问题。不要省那一行。

6. 从一次性提问到可复用模板：沉淀你自己的六模块体系

6.1 把六模块写成字段模板

当六模块跑通之后，下一步是把Prompt变成“填空模板”。我为经常重复的任务准备了一个通用结构，每次只需要填字段：

【角色】 你是一位{角色描述}，擅长{特长}。 【背景】 {与任务直接相关的上下文，3行以内} 【任务】 {动词开头的任务描述，尽量可验证、可计数} 【约束】 {可验证的约束，优先用正面表述} {如有硬性禁止项，单列} 【输出格式】 {指定输出结构，明确分隔方式} 【示例】 {一个正例，放在最后}

这样做的价值在于：下次遇到类似任务，不用再动脑子重新设计Prompt。某团队把一套“产品周报生成Prompt”沉淀成字段模板后，新同学只需要填背景和任务，输出的周报质量和老员工手动写的接近，这比我一开始预想的效果好得多。

6.2 一次只改一个模块的迭代原则

调试Prompt和调试代码很像，要养成“一次只改一个变量”的习惯。我发现很多人调Prompt，一次改一堆，输出变好了也说不清是哪个字段起了作用；变差了更不知道回滚哪一句。

更靠谱的做法是：改动一个模块，连续跑三次，记录结果是否稳定。如果一次跑得好、两次跑得差，说明这个模块描述得还不够硬，需要再加约束或改变措辞。

顺手建议做一个Prompt版本记录表，记账真的有用：

这种记录做上一周，你对“什么修改会产生什么结果”的感觉会灵敏很多。

6.3 团队复用与个人沉淀的两条路

这套结构最大的长期价值，不在某一次输出上，而在于它可复用、可沉淀、可共享。

个人层面，我会按场景把跑通的Prompt分门别类存下来：写作类、分析类、数据处理类、代码审查类。每次写新Prompt时，先翻找同类模板，从已有基础上改，而不是从零开始。团队层面，把字段模板和版本记录表共享，每个人都往里填一次自己的成功案例，整个团队的“模型调用质量下限”就会被拉高。我见过最直接的效果，是团队几个人交上来的AI产出，从“风格千奇百怪”变成“一起迭代同一个模板”。

最后说点实在的。跟大模型打了这么长时间交道，我最大的体会是：大部分人觉得“大模型不听话”，其实是需求说明书没写到位。六模块结构不一定是最短的写法，有时候它甚至让你多打几行字，但它换来的是稳定的输出下限和可调试的改进路径。如果你现在还在随口问、随手扔指令，我建议你挑一个每周都会重复的任务，把六模块填一遍，连跑三天，看看输出稳定性的变化。让模型精准听话，从来不是玄学，就看愿不愿意把要求讲清楚。