企业官网建设流程全解析

我记得第一次被 Prompt 教育，是在一个内容批量生成的项目里。同样的模型、同样的接口、同样的温度参数，合作方那位同事的提示词丢进去，出来基本能直接用；我的丢进去，十句里有六句要返工。当时我以为他"会调参"，后来把两份提示词摆在一起逐字对比才发现，差别全在措辞和结构上：他把背景、约束、输出格式三件事写清楚了，我只写了一句"帮我写个产品介绍"。这件事之后我才认真去啃大模型提示工程（Prompt Engineering）的原理，也才有了后面这套自己一直在用的写法。这篇文章是上篇，只讲原理和基础技巧，重点是搞清楚"为什么这么写有效"，以及怎么把 AI 生成内容质量从"能看"推到"能用"。

这篇适合三类人：一是天天用对话模型写东西、但总觉得差一口气的人；二是要给团队定提示词规范、却不知道怎么开口讲的人；三是在做 AI 应用、想靠提示词把效果往上抬一截、少烧点算力的人。上篇不涉及复杂工程，全是能立刻抄走的东西：结构骨架、六个高频技巧、一份问题排查表，还有一个提示词从初稿改到定稿的完整过程。基础弱的可以照着模板直接套，有经验的可以重点看第二、第四节，那里的原理部分是我踩了不少坑才想明白的。

1. 提示工程到底在解决什么问题

1.1 模型不是不会，是你没说清楚

很多人对提示词的第一个误解，是把它当成"咒语"——觉得存在某句神秘的话，一说出来模型就变聪明了。实际完全不是。大模型的本质是一个接话机器：它读你给的全部文字，然后预测"接下来最可能出现的文字是什么"，一个 token 一个 token 往外吐。这意味着你给的那段话，就是它全部的判断依据。你没写的东西，它不会知道；你写得含糊的地方，它只能按训练数据里最普遍、最平庸的那种情况去补。

用一个生活场景类比就很清楚：你找一个能力很强、但从没见过你的外包干活。你只说"帮我写个方案"，他只能按行业最通用的模板给你糊一篇，因为他不知道你的客户是谁、预算多少、要多长、是给老板看还是给客户看。你要是把"客户是制造业中层、预算五万以内、控制在两页 A4、重点讲交付周期"这些交代清楚，同一个人的产出立刻是两个档次。模型面临的处境一模一样，它不缺能力，缺的是信息。

所以提示工程解决的第一个问题，是信息缺口：把只存在于你脑子里的背景、标准、边界，翻译成模型能读到的文字。解决的第二个问题是方向收敛：模型的输出空间极大，同一件事有一万种写法都算"合理"，你要用约束把这一万种压到你能接受的那几十种里。这两件事跟"玄学"毫无关系，全是可拆解、可复现的。

1.2 同一需求三种写法的输出差异实录

空说没感觉，我拿一个最常见的需求举例：给一款保温杯写电商详情页的主图文案。我试过三种写法，输出质量的差距非常直观。

第一种写法就一句话："写一个保温杯的文案。"出来的东西大致是"品质生活，从一杯热水开始"这类谁都能写、谁看了都记不住的句子，句式还特别爱用四字短语堆排比。

第二种加了一点信息："写一个保温杯的电商主图文案，面向通勤上班族，突出保温 12 小时，字数 30 字以内。"输出明显收敛了，会围绕"早上灌的热水，下午还烫嘴"这种具体场景写，虽然还谈不上出彩，但已经能用了。

第三种把约束和参考都给了："你是电商详情页文案。产品：316 不锈钢保温杯，容量 500ml，实测 95 度热水 12 小时后 68 度。目标人群：一线城市通勤 40 分钟以上的上班族。忌讳：不要用'品质生活''匠心''甄选'这类词，不要写四字排比。输出：3 条主图文案，每条不超过 22 字，必须包含一个具体时间或温度数字。"这次出来的三条，有两条我改两个词就直接用了。

三次用的是同一个模型、同一轮对话里连续提问，唯一的变量就是提示词。这个对比说明一件事：输出质量的方差，很大一部分是由输入决定的，而不是由模型决定的。很多人抱怨"这模型不行"，其实是把提示词该干的活推给了模型去猜。

1.3 提示工程的能力边界在哪里

这一节必须泼冷水，因为我见过太多人把期望值拉得太高，最后反过来说"提示工程没用"。它有明确的能力边界。

第一，提示词不能凭空造出模型没学过的私有事实。你公司的内部政策、上个月的销售数据、某个客户的特殊偏好，这些必须你自己写进上下文，或者通过外部检索喂进去。提示词能做的是"用好给到的信息"，不是"变出没给的信息"。

第二，提示词不能保证 100% 的格式一致性。你可以把概率从 70% 抬到 97%，但那 3% 依然会发生，所以生产环境里永远要有校验和兜底，别指望一句"只输出 JSON"就万无一失。

第三，提示词替代不了评测。改了一版提示词，感觉"好像好点了"是不算数的，得有一批固定的测试输入、一套明确的打分标准，改完跑一遍看分数。我吃过这个亏：凭感觉调了三版，上线后发现其中一版在长输入场景下反而退化，因为那版把关键约束放在了最前面，长度一上来就被稀释掉了。

反过来，提示工程能稳定拿到的东西也很实在：减少返工次数、把输出格式稳住、让风格可复制、把复杂任务拆成可检查的步骤。这些加起来的效率提升，在实际项目里通常是数倍级别的。

2. 底层原理：模型是怎么"读"你的提示词的

2.1 从分词到概率，一句话被拆成了什么

要写好提示词，得先知道你的话进模型之后变成了什么。文本会先被切成 token——可能是一个词、半个词、一个标点，中文里常见的是 1 到 2 个字一个 token。然后模型把这些 token 转成向量，一层层算注意力，最后输出的是"词表里每个 token 作为下一个词的概率"。所谓生成，就是按这个概率分布挑一个，接上去，再算下一个。

这个机制带来两个直接影响。一是概率高的表达天然更"平庸"。模型训练时见过最多的写法，就是它最容易吐出来的写法，所以你不加约束，它给你的永远是最大公约数式的答案——这也是为什么默认输出总带着那股"综合来看""值得注意的是"的味道。二是采样策略决定发散程度。温度调低，模型更倾向挑概率最高的那个，输出稳但死板；温度调高，它会挑一些概率稍低的词，输出活了但也容易跑偏。很多人调提示词调不动，其实是采样参数和任务不匹配：抽取式任务（分类、信息提取）该用低温，创意发散任务才需要高温。

我在实际项目里的一般做法是：结构化输出和事实性任务，温度压到 0.1 到 0.3；文案和头脑风暴，0.7 到 0.9；需要多样性的批量生成，再加一点 top_p 的扰动。这一条定下来，很多"输出不稳定"的抱怨会直接消失一半。

2.2 上下文窗口和注意力分配，位置真的会影响结果

模型的上下文窗口是有限的，而且窗口内的信息并不是被平等对待的。实践里非常明显的一个现象是首尾效应：放在开头和结尾的指令，被遵循的概率明显高于塞在中间大段文字里的指令。输入越长，这个效应越显著——上万字的长文档丢进去，中间部分的细节被漏掉是常事。

这个规律直接指导了提示词的结构安排。我的固定做法是：开头用一两句话定角色和总任务（让它进入状态），中间放背景材料和具体资料，最后一段重述最关键的约束和输出格式。关键约束宁可重复两遍，也不要只在中段提一次。如果任务是"从长文档里抽取信息"，我还会在结尾再加一句"请逐项核对上述字段，缺失的填'未提及'，不要自行推测"。

另一个相关现象是近距离指令优先。当你前后给了两条有冲突的要求，模型往往听后面那条。所以改提示词的时候，如果发现某条约束"突然失效了"，先别怀疑模型，去看看是不是后面又写了一句跟它打架的话。我遇到过一次，前面写"输出 200 字以内"，后面举例时写"参考下面这段 600 字的示例风格"，结果输出全都奔着 600 字去了。把例子换成短例，问题立刻解决。

2.3 三个最耽误事的认知误区

误区一：写得越长越详细越好。长度不产生信息。塞一堆"请你务必认真思考、充分发挥你的专业能力"这种话，除了占上下文，没有别的作用。真正有效的是具体的、可核验的信息：数字、字段名、判断标准、反例。一段 200 字但全是硬约束的提示词，效果远好过 800 字的客套话。

误区二：说"务必""一定"就等于强约束。模型不理解"惩罚"，它只对语义模式敏感。你说"务必不要出现营销腔"，它知道要避开营销腔，但不知道什么算营销腔；你说"不要出现'臻选''匠心''尊享'这几个词，不要用四字短语连续排列"，它就知道了。把"强调"换成"定义"，这是提示词水平的分水岭。

误区三：礼貌用语能提升质量。这个说法流传很广。我的实测结论是：在简单任务上几乎没差别，在长上下文任务里，过多的"请您""麻烦您"反而会稀释有效信息。当然，把模型当成一个需要交代清楚的合作者、用清晰的语气沟通，是另一回事——那不是礼貌问题，是信息组织问题。

3. 高质量提示词的五段式骨架

3.1 五个必备要素：角色、任务、背景、约束、输出格式

我现在的提示词，不管长短，基本都按这五块来搭。这套骨架的价值在于，它强迫你把每类信息都想一遍，缺哪块一眼就能看出来。

角色决定用什么样的知识和语气作答。写"你是一位有十年经验的质检工程师"和写"你是一位新媒体编辑"，同一个问题的回答角度完全不同。角色不用长，一句话够，关键是要和任务真正匹配，别为了显得专业硬加一个不相关的头衔。

任务是整个提示词的动词，必须具体到一个可交付的产物。"帮我分析一下这个方案"是模糊的，"列出这个方案里 3 个成本估算上的风险点，每条给出一句依据"是可交付的。

背景是你脑子里的那些前提。行业、受众、用途、已有的判断、不能触碰的红线，都放这里。

约束是边界，包括长度、语气、必须包含什么、必须避免什么、不确定时怎么处理。约束最好写成可核验的形式，下一节专门讲。

输出格式决定了结果能不能直接用。是纯文本、分点、表格还是 JSON，字段叫什么，顺序如何，都要写清楚。这一块省下来的时间是最直观的——格式对了，复制粘贴就能进下一道工序；格式不对，光整理就要半小时。

3.2 把形容词换成可核验的标准

这是我认为最值钱的一条技巧。提示词里每出现一个形容词，就要问自己：这个词能被检验吗？不能的话，就把它翻译成能检验的东西。

这张表我团队里人手一份。道理很简单：你给的标准越可检验，模型"蒙对"的空间就越小，你验收的成本也越低。反过来，一句"写得好一点"，模型只能按训练数据里的平均值去理解"好"，那结果必然平庸。

3.3 示例怎么给才有效：数量、位置、正负例

给例子（few-shot）是提升稳定性最直接的手段，但给法有讲究，给错了反而添乱。

数量上，1 到 3 个通常最优。一个例子能定调，两个例子能定模式，三个例子能定边界。超过五个，收益急剧下降，还白占上下文。我做过一个小对比：同样的分类任务，给 1 个例子准确率 78%，给 3 个到 91%，给 8 个反而掉到 87%，因为例子之间开始出现细微的风格冲突，模型被搞糊涂了。

位置上，例子放在任务描述之后、输出格式要求之前。放太前面，模型读完例子已经忘了要干什么；放最后，又容易盖住格式要求。

正例负例搭配，效果比只给正例好。尤其在"避免某种风格"这类需求上，一个明确的负例胜过十句"不要"。比如你想避免空洞的口号式文案，与其写"不要空洞"，不如直接给一条负例："保温杯文案（错误示范）：'品质生活，从一杯好水开始'——问题在于没有任何具体信息"，再给一条正例。模型对"对比"极其敏感，这是它的强项。

还有一个小细节：例子的格式必须和你要的输出格式完全一致。你要 JSON 就贴 JSON，要三行就贴三行。我见过贴了一段散文当例子、却要求输出表格的提示词，结果模型永远在两种格式之间摇摆。

3.4 用分隔符把不同性质的信息隔开

这条技巧便宜又好用。当提示词里混着指令、资料、示例三种性质完全不同的文本时，用明确的分隔把它们的边界划出来，模型的遵循度会明显提升。常用的分隔方式有三引号、三个短横线包裹的区块、XML 风格的标签，以及"### 资料开始 / ### 资料结束"这种中文标记。

这么做的原理是：模型对结构标记非常敏感，标记相当于给它画了一张地图，告诉它"这段是要执行的要求，那段是待处理的素材"。不做区分的后果是它可能把资料里的某句话当成指令去执行——这在处理用户提供的长文本时是真实存在的风险。

一个完整的骨架大概长这样：

# 角色 你是一位有 8 年经验的 B 端产品文案，擅长把技术参数翻译成采购方能理解的收益。 # 任务 把下面这份产品参数，改写成 3 条面向采购负责人的卖点短句。 # 背景 - 客户是中型制造企业，采购决策看重停机成本和维护周期 - 使用场景：展会易拉宝，观众停留时间不超过 8 秒 # 约束 - 每条不超过 18 字，必须包含一个具体数字 - 禁用"领先""卓越""一站式"等空词 - 不确定的参数不要编，标注"待确认" # 输出格式 编号列表，每条格式为「卖点短句 | 支撑参数」 # 资料 <<< （此处粘贴原始参数） >>>

这套骨架我用了很久，好处是改起来方便。效果不好时，能快速定位是哪一块的问题：是角色不对、约束太松、还是格式没写清。比一整段散文式的提示词好调试得多。

4. 六个能立刻见效的实战技巧

4.1 先要骨架，再要血肉

一次性让模型写 2000 字长文，结果通常是开头还行、中段开始注水、结尾草草收场。原因是它在生成时没有全局规划，走一步看一步。

解决办法是把一次生成拆成两次。第一轮只要结构："针对这个主题，列出 5 个一级标题和每个标题下的 3 个要点，不要展开。"第二轮再把结构喂回去："按下面这个结构写正文，每个要点不少于 150 字，注意第 2 点和第 4 点之间要有过渡。"

我自己的体感是，这个改动对长文质量的影响超过其他任何单一技巧。因为结构一旦定下来，每一段的写作就变成了"局部任务"，模型的注意力可以集中，而不是被整篇的篇幅拖着走。顺带一个好处：结构阶段你能提前发现逻辑问题，改结构比改两千字便宜太多。

4.2 让模型先列要点再写正文

和上一条类似，但更轻量，适用于单段内容。做法是在任务后面加一句："先用 5 条以内的要点列出你的写作思路，等我确认后再展开。"这句话的价值不在于让你审批，而在于强制模型把隐性的思考显性化。它列出的要点如果偏了，你一眼就能看出来，省下一整篇返工。

在实际使用中我常用的变体是"自问自答"：让模型先写出"回答这个问题需要先弄清哪三件事"，再逐条回答，最后整合。这个套路在分析类任务上特别有效，因为它逼着模型去补全前提，而不是直接给结论。

4.3 思维链的正确用法，以及它什么时候帮倒忙

"让我们一步一步思考"这句话被传得很神。它确实有效，但有效范围比传说中窄得多。

它起作用的前提是：任务本身包含多个可分解的推理步骤，比如多步计算、逻辑推理、需要综合多个条件的判断。这类任务里，让模型把中间步骤写出来，等于给它更多的计算位，准确率提升明显。

但如果是事实检索、格式转换、文案生成这类任务，强行让它"一步步思考"，结果往往是多了一堆废话，甚至因为中间步骤里编了一个错误前提，把最终答案带偏。我遇到过最典型的一次：让它从一段文本里提取日期，加了思维链之后它开始"推理"这个日期可能对应的季度，然后自作主张改写成了季度表述。

所以我的用法是：推理类任务显式要求分步，抽取和生成类任务明确要求"直接输出结果，不要解释过程"。后者加一句"只输出结果"往往比什么都管用。

4.4 让它自己挑毛病，比你自己挑快得多

模型对自己刚生成的内容是有"上下文感知"的，把内容原样贴回去让它审查，经常能揪出你都没注意到的问题。常见写法是两轮：

第一轮正常生成。第二轮把结果贴回去，加一句："以上内容里，找出 3 处最可能被专业人士质疑的地方，说明理由，然后给出修改后的版本。"

关键是要限定数量。"找出问题"太宽泛，它会挑些无关痛痒的；"找出 3 处最可能被质疑的地方"会逼它优先处理真正的问题。另外补一句"如果没有明显问题，直接说没有，不要为了凑数硬找"，否则它会礼貌性地编几个问题出来。

4.5 负面指令为什么老是失效

"不要写得太啰嗦""不要用营销腔""别太官方"——这类否定式指令的失效率高得惊人。原因在原理层面：模型的生成是"往某个方向补全"，你告诉它"不要 X"，它脑子里被激活的恰恰是 X 这个概念，然后它得再绕一圈去想"那该是什么"。绕这一圈的过程里，很容易绕回去。

替代方案有两个，我一般看情况混用。一是给出替代物：不说"不要啰嗦"，说"每句话控制在 25 字以内，删除所有修饰性副词"。二是把否定变成清单：不说"不要 AI 味"，直接列一张禁用词表，把"综上所述、值得注意的是、在当今时代、赋能、闭环"这些词列出来，明确写"出现任意一个即视为不合格"。

最后一行那条特别重要。"不要瞎编"几乎是无效的，"缺失项填未提及"才是有效的，因为后者给了模型一条明确的、可执行的退路。

4.6 参数配合，别让提示词白干

提示词写得再好，参数不对也白搭。除了前面说的温度，还有两个参数值得盯。

最大输出长度。很多人被截断坑过——内容写到一半断了，以为是模型不行，其实是长度上限设小了。长文任务一定要先估算：中文大约 1.5 到 2 个字一个 token，2000 字就是 1000 到 1300 个 token 起步，留出余量设成 2500 比较稳。

重复惩罚。批量生成同质化内容时，偶尔会出现句子结构高度雷同的情况，适度调高重复惩罚能缓解，但调太高会导致语句不连贯、用词怪异。这个参数我一般不动，宁可换个说法重新生成。

还有一个容易被忽略的点：同一个任务，不同模型的"最佳提示词"是不一样的。有的模型对结构化标记特别敏感，有的更吃自然语言描述；有的对长上下文处理得好，有的超过一定长度就开始丢信息。换模型时，原提示词至少要做一轮小规模回归测试，别直接平移。

5. 常见问题排查手册

5.1 输出跑偏、答非所问

这是最高频的问题。排查顺序我一般这么走：先看任务描述里有没有多个动词——"分析并总结并给出建议"这种，模型很可能只做了最后一件。再看约束之间有没有冲突，尤其注意后面有没有一句悄悄推翻了前面的要求。最后看资料区有没有混进类似指令的句子。

一个很隐蔽的坑是任务和例子不匹配。比如任务说"写 3 条短句"，例子却给了 3 段长文，模型会优先学例子。这种情况下改例子比改任务描述有效。

如果以上都排除了，就在最后加一句"复述一遍你要完成的任务，然后再执行"。这个动作能让模型把注意力重新锚定到任务上，实测对跑偏的修复率挺高。

5.2 内容空泛、全是正确的废话

空泛的根源通常是两个：一是没给具体素材，模型只能拿常识填；二是没给判断标准，模型不知道什么叫"有信息量"。对应的解法是补素材和补标准，两个都得补。

补素材这块，我的经验是给一个具体的数字或场景，胜过给十句描述。你说"面向中小商家"，它写得很泛；你说"面向 3 到 5 家门店的连锁餐饮老板，最头疼的是排班和损耗"，它立刻就有话可说了。

补标准这块，直接抄前面那张"模糊 vs 可核验"的表就行。另外加一句"如果你发现某个论点没有依据支撑，直接删掉，不要用形容词填充"，这句能砍掉大量水分。

5.3 格式老是不稳

要让格式稳定，三层保险一起上：一是明确字段名和顺序，不要只说"输出 JSON"，要把字段列出来；二是给一个格式完全一致的示例；三是加一个兜底规则，比如"如果某项信息不足，该字段填 null，不要省略字段"。

即便如此，也建议在程序侧做校验和重试。指望提示词做到 100% 是不现实的，工程上留一道重试，比反复抠提示词划算。我一般的配置是：格式校验失败自动重试一次，重试时把错误信息一起喂回去，成功率能到 99% 以上。

5.4 长文档处理丢信息

处理长文档时，丢失中间信息是结构性问题，不是偶发。可行的缓解办法有几个：一是分段处理，把长文切块，每块单独抽取，最后合并；二是先摘要后细节，先让它输出全文的结构纲要，再针对每个部分单独提问；三是把关键问题放在最后重述一遍，利用首尾效应。

如果只是要从长文里找几个特定信息，我强烈推荐分段 + 逐段回答"有/无 + 原文摘录"的方式，比让它一次性通读准确得多。摘录原文这个要求很重要，它能逼模型回到原文，而不是凭印象概括。

5.5 问题速查表

6. 一次真实迭代：从初稿到定稿的六版改动

6.1 起点和第一次失败

前阵子帮一个做硬件的团队整理售后工单摘要，需求是把用户口语化的报修描述，压成一条结构化的工单记录，字段包括产品型号、故障现象、发生场景、已尝试操作、紧急程度。我第一版写得很简单："把下面的用户描述整理成工单，包含型号、故障、场景、已尝试、紧急程度五个字段。"

结果一塌糊涂：字段名一会儿是中文一会儿是英文，紧急程度有的写"高"有的写"比较急"有的写"P1"，故障现象有时摘原文有时自己概括，还有几条把用户抱怨的脏话也原样保留了。这一版基本不可用，返工率接近四成。

6.2 二到四版：逐步收紧约束

第二版我加了字段定义和枚举值：紧急程度只允许"高/中/低"，并给了判断标准——涉及安全或完全无法使用为高，影响主要功能为中，其余为低。返工率降到两成左右，但型号字段还是经常出错，因为它会把用户随口提到的配件型号当成主机型号。

第三版加了资料区和一条规则："型号只从'主机型号'字段提取，用户描述中提到的其他型号一律忽略。"同时在输出格式里明确写了 JSON 结构。这一版的型号错误基本消失，但出现了新问题：用户没提到的字段，模型开始编。有两条工单里填了根本没出现过的"已尝试操作"。

第四版加了兜底规则："任何字段在原文中没有对应信息，填'未提及'，严禁推测。"同时把紧急程度的判断标准细化到具体例子。返工率降到一成以下。

6.3 五到六版：提升可读性和稳定性

第五版的改动是加了一个完整示例，正例负例各一个，负例专门展示"编造字段"的错误。同时把最关键的两条约束——"只提取不推测"和"字段名不可改"——复制到了提示词的最末尾重述一遍。这一版在我抽测的 60 条真实工单上，字段完整率和格式合规率都到了 95% 以上。

第六版只做了微调：把 JSON 外面多余的说明文字去掉，明确要求"只输出 JSON，不要任何前后缀说明"；另外把温度从 0.5 降到 0.2。这一版才真正做到了直接入库。整个过程改了六版，提示词从 80 字涨到 600 多字，但每一条增加的字都对应着一次真实的失败。

6.4 这次迭代里最值得记住的三点

第一，每一条约束背后都应该有一次具体的失败。不是想到什么写什么，而是被坑了一次就补一条。这样长出来的提示词虽然啰嗦，但每条都在干活。

第二，枚举值和判断标准是稳定性的最大来源。把开放式判断改成封闭选项，把"高/中/低"配上明确的判定条件，稳定性提升的幅度远超加各种"请务必"。

第三，兜底规则比正面规则更重要。人写提示词时总想着"要它做什么"，但实际跑起来，出问题的往往是"它做了不该做的"。给一条明确的退路——填"未提及"、返回 null、说"无法判断"——能挡住绝大多数幻觉。

这套思路放到别的场景也一样：客服回复、简历筛选、会议纪要、日报汇总，套路都是先跑通、再收紧枚举、再补兜底、最后压缩输出格式。上篇到这里基本把原理和基础手法讲完了，角色设定、长文档处理、多轮对话的上下文管理、以及怎么做提示词的批量评测，这些展开来又是另一套东西，留在下篇里聊。我自己这几年最大的感受是，提示词写得好的标志不是它有多长多华丽，而是你换个人拿去用，出来的结果也差不多——能做到这一点，说明它已经不依赖运气了。