企业官网建设流程全解析

1. 提示词失效的底层逻辑：为什么你写的提示词总是不听话

写了两年多提示词，带过团队，也帮不少朋友调过各种场景的提示词，我发现一个特别有意思的现象：大部分人写提示词的方式，跟买彩票差不多——写一版，跑一下，不行，改几个词再跑，还不行，换个模型再试。折腾半天，最后得出结论“这模型不行”。

问题出在哪？出在大家把提示词当成了“咒语”，而不是“工程”。

咒语的特点是：你念对了就灵，念错了就不灵，但你不知道为什么不灵。工程的特点是：你知道每个环节在干什么，出了问题知道去哪找原因，改哪里能解决。

提示词工程的核心，其实就是把“念咒语”变成“做工程”。而做工程的第一步，是搞清楚东西是怎么坏的。

1.1 提示词失效的五种典型模式

我把自己和团队踩过的坑整理了一下，发现提示词失效基本逃不出这五种模式。你对照着看，大概率能对上号。

模式一：指令模糊症

这是最常见的。你写了一句“帮我写一篇关于AI的文章”，然后抱怨模型写得太泛。问题是，你自己知道要什么吗？是给谁看的？发在哪？多长？什么风格？要观点还是要科普？

模型不是你肚子里的蛔虫。你给的信息量越少，它自由发挥的空间就越大，结果就越不可控。这就像你让一个设计师“做个好看的海报”，他不把你气死才怪。

模式二：上下文过载症

跟模糊症相反，有些人喜欢把所有能想到的信息全塞进去。系统指令写了八百字，用户输入又贴了两千字参考资料，中间还夹着三段示例。结果模型跑到一半就“忘了”前面说了什么，或者把不同部分的指令混在一起理解。

这里涉及一个很实际的问题：模型的注意力是有限的。你给的信息越多，每个信息分到的“注意力权重”就越低。关键指令被淹没在废话里，模型自然抓不住重点。

模式三：格式冲突症

你告诉模型“用JSON格式输出”，然后在示例里给了一个Markdown表格。你要求“简洁回答”，但系统指令里写了“请详细解释每一步”。你让模型“扮演一个友好的客服”，但用户问题是“帮我写一段讽刺领导的段子”。

这种自相矛盾的指令，模型处理起来非常痛苦。它会在不同指令之间反复横跳，最后输出一个四不像的东西。

模式四：示例误导症

给示例是个好习惯，但给错示例比不给还糟糕。我见过有人想训练模型做情感分类，给了三个正面示例，一个负面示例都没有。结果模型把所有输入都判成正面。

还有一种情况是示例的格式和实际输入差异太大。你给的示例是短文本，实际输入是长文档；示例是英文，实际输入是中文。模型会按照示例的“样子”去处理实际输入，而不是按照你的真实意图。

模式五：边界缺失症

你没有告诉模型什么该做、什么不该做。比如你让它“回答用户问题”，但没说“如果问题超出知识范围，请说不知道”。结果模型开始编造答案，而且编得理直气壮。

边界缺失在需要严格控制的场景里特别致命。做数据提取时，你没说“只提取原文中出现的信息”，模型就会自己脑补；做内容审核时，你没说“不确定的标记为待人工复核”，模型就会强行二选一。

1.2 为什么这些失效模式反复出现

说到底，是因为大部分人写提示词是“一次性”的。写完就跑，跑完就完，没有记录，没有对比，没有迭代。

我刚开始做提示词工程的时候也是这样。后来被坑多了，才开始建立一套系统的方法。这套方法的核心就一句话：把提示词当成代码来管理。

代码有版本控制，提示词也应该有；代码有单元测试，提示词也应该有；代码有代码审查，提示词也应该有。你不需要搞得那么正式，但至少要做到：每次修改都有记录，每次效果变化都有对比，每个关键场景都有测试用例。

这听起来很麻烦，但实际做起来，比你反复试错要快得多。因为试错是随机的，而系统化迭代是有方向的。

2. 七步修复框架：从失效到可用的完整路径

搞清楚失效模式之后，修复就有了方向。我总结了一个七步框架，基本上能覆盖90%以上的提示词问题。这个框架不是线性的，你可以根据实际情况跳步，但每一步背后的逻辑都值得理解。

2.1 第一步：明确任务边界

在写任何提示词之前，先回答三个问题：

• 这个提示词要解决什么问题？
• 什么情况下这个提示词不适用？
• 成功的标准是什么？

第一个问题帮你聚焦。第二个问题帮你划定边界，避免模型越界。第三个问题帮你建立评估标准，不然你改了半天都不知道是改好了还是改坏了。

我见过太多人跳过这一步，直接开始写“你是一个专业的...”。结果写出来的提示词什么都能干，但什么都干不好。

2.2 第二步：拆解任务流程

把任务拆成模型能理解的步骤。比如“写一篇公众号文章”这个任务，可以拆成：

1. 理解主题和目标读者
2. 确定文章结构和核心观点
3. 撰写开头
4. 展开正文
5. 撰写结尾
6. 检查逻辑和语气

拆得越细，模型执行起来越稳定。但也不要拆得太碎，否则模型会失去全局观。一般来说，3到7个步骤比较合适。

拆解的时候要注意步骤之间的依赖关系。有些步骤可以并行，有些必须串行。在提示词里明确这些关系，能减少模型的混乱。

2.3 第三步：设计指令结构

指令结构决定了模型怎么“读”你的提示词。我习惯用这样的结构：

[角色定义] [任务描述] [约束条件] [输出格式] [示例] [边界说明]

这个顺序不是固定的，但逻辑是：先告诉模型它是谁，再告诉它要干什么，然后告诉它有什么限制，接着告诉它输出成什么样，给个例子参考，最后说明什么情况下不要做什么。

每一部分的长度要控制。角色定义一两句话就够了，写太多反而会让模型过度代入。任务描述要具体，但不要啰嗦。约束条件要明确，但不要自相矛盾。

2.4 第四步：注入领域知识

通用模型在专业领域的表现往往不够好，因为它缺乏领域知识。你需要在提示词里补充关键信息。

补充领域知识有两种方式：一种是直接写在指令里，比如“在医疗场景中，患者隐私信息必须脱敏”；另一种是通过示例来体现，比如给一个脱敏后的示例。

直接写指令的好处是明确，坏处是占篇幅。通过示例体现的好处是直观，坏处是模型可能学不到背后的原则。我的经验是：关键原则用指令写，具体操作展示例。

2.5 第五步：设置输出约束

输出约束包括格式、长度、语气、语言等。格式约束最常用的是JSON、Markdown、纯文本。长度约束可以用字数、段落数、要点数。语气约束可以用“正式”“口语化”“专业”等词。

设置约束的时候要注意可操作性。“写得有趣一点”这种约束模型很难执行，“每段不超过三句话，至少用一个生活化类比”这种约束就具体得多。

还有一个技巧：用“必须”和“禁止”来强化约束。“必须包含三个要点”“禁止使用专业术语”，这种表述比“尽量”“最好”有效得多。

2.6 第六步：构建测试用例

测试用例是验证提示词效果的关键。一个好的测试用例应该包含：

• 典型输入（正常情况）
• 边界输入（极端情况）
• 异常输入（错误情况）

比如你写了一个情感分类的提示词，测试用例应该包括：明显正面的文本、明显负面的文本、中性文本、混合情感的文本、讽刺文本、无意义文本。

每个测试用例都要有预期输出。跑完提示词之后，对比实际输出和预期输出，记录差异。差异越大，说明提示词需要改进的地方越多。

2.7 第七步：迭代优化

根据测试结果修改提示词，然后重新跑测试用例。迭代的时候要注意：每次只改一个地方，这样才能知道是哪个改动起了作用。

迭代的终止条件不是“完美”，而是“满足需求”。提示词工程没有终点，只有够用。你不可能写出一个对所有输入都完美的提示词，但你可以写出一个对目标场景足够好的提示词。

迭代过程中要记录每次修改的内容和效果。我习惯用一个简单的表格来记录：

这个表格看起来简单，但能帮你快速定位问题，也能在团队协作时让别人知道你都改了什么。

3. 三个工程模板：拿来就能用的提示词框架

理论说再多，不如直接给模板。下面这三个模板是我在实际项目中反复打磨出来的，覆盖了大部分常见场景。你可以直接复制修改，也可以根据需求组合使用。

3.1 内容生成模板

这个模板适合写文章、写文案、写报告等场景。

# 角色 你是一位[领域]的资深[职位]，有[X]年经验，擅长[具体技能]。 # 任务 请根据以下要求，撰写一篇关于[主题]的[内容类型]。 # 背景信息 - 目标读者：[读者描述] - 发布平台：[平台名称] - 内容目的：[目的描述] - 参考素材：[素材内容] # 约束条件 1. 字数要求：[具体字数范围] 2. 结构要求：[结构描述] 3. 语气要求：[语气描述] 4. 必须包含：[关键要点] 5. 禁止出现：[禁止内容] # 输出格式 请按照以下格式输出： [格式描述] # 示例 [示例内容] # 边界说明 如果[某种情况]，请[某种处理方式]。

这个模板的关键在于“背景信息”和“约束条件”两部分。背景信息给得越足，模型越能理解你的需求。约束条件写得越具体，输出越可控。

我实测下来，用这个模板写公众号文章，第一版就能达到可发布的水平，只需要微调个别措辞。比直接让模型“写一篇关于XX的文章”效果好太多。

3.2 信息提取模板

这个模板适合从文本中提取结构化信息的场景。

# 角色 你是一位专业的信息提取助手，擅长从非结构化文本中提取关键信息。 # 任务 请从以下文本中提取[目标信息类型]，并按照指定格式输出。 # 输入文本 [待提取的文本] # 提取规则 1. 只提取原文中明确出现的信息，不要推断或补充。 2. 如果某项信息在原文中不存在，填写“未提及”。 3. 如果同一信息出现多次且不一致，以第一次出现为准。 4. [其他规则] # 输出格式 请以JSON格式输出，包含以下字段： - field1: [字段说明] - field2: [字段说明] - field3: [字段说明] # 示例 输入：[示例输入] 输出：[示例输出] # 边界说明 如果输入文本为空或无法识别，请输出：{"error": "无法提取"}

这个模板的核心是“提取规则”和“边界说明”。规则要明确，边界要清晰。特别是“只提取原文中明确出现的信息”这一条，能大幅减少模型的幻觉。

做数据提取的时候，我建议先用小批量数据测试，确认提取准确率达标后再批量处理。不要一上来就处理几万条，出了问题返工成本太高。

3.3 对话交互模板

这个模板适合客服、助手、咨询等对话场景。

# 角色 你是[角色名称]，[角色描述]。你的性格是[性格描述]，说话风格是[风格描述]。 # 能力范围 你可以处理以下类型的问题： 1. [能力1] 2. [能力2] 3. [能力3] # 对话规则 1. 每次回复不超过[字数]字。 2. 如果用户问题超出能力范围，请引导用户[处理方式]。 3. 如果用户情绪激动，请先[安抚方式]，再[处理方式]。 4. 禁止[禁止行为]。 5. [其他规则] # 知识库 [相关知识内容] # 示例对话 用户：[示例问题] 助手：[示例回复] 用户：[示例问题] 助手：[示例回复] # 边界说明 如果用户询问[敏感话题]，请回复“[标准回复]”。 如果连续[次数]次无法解决用户问题，请[升级处理方式]。

对话模板最难的部分是“边界说明”。因为对话是开放的，用户可能问任何问题。你需要提前想好各种边界情况，并给出标准回复。

我的经验是：先上线一个基础版本，收集真实对话数据，然后根据实际遇到的问题不断补充边界说明。不要试图一次性覆盖所有情况，那是不可能的。

4. 实战案例：从失效到修复的完整过程

光给模板不够，还得看实际怎么用。我拿一个真实案例来拆解，从失效到修复的完整过程。

4.1 案例背景：电商评论情感分析

需求是这样的：从电商平台的用户评论中，判断情感倾向（正面、负面、中性），并提取关键问题点。

第一版提示词写得很简单：

请判断以下评论的情感倾向，并提取关键问题。 评论：[评论内容]

跑了一百条测试数据，准确率只有六成左右。主要问题有三个：中性评论经常被判成正面或负面；讽刺性评论完全识别不了；提取的问题点经常是原文中没有的。

4.2 失效分析：三个核心问题

对照五种失效模式，这个案例命中了三个：

指令模糊症：没有定义什么是“正面”“负面”“中性”，模型只能凭感觉判断。

示例误导症：没有给示例，模型不知道什么样的评论对应什么样的输出。

边界缺失症：没有说明讽刺、反话、混合情感怎么处理。

4.3 修复过程：七步框架的应用

按照七步框架，我重新设计了提示词。

第一步，明确任务边界：这个提示词只处理中文电商评论，不处理其他语言；只判断情感倾向和提取问题点，不做其他分析；情感倾向只有三个类别，没有中间状态。

第二步，拆解任务流程：先判断整体情感倾向，再提取具体问题点，最后检查问题点是否在原文中出现。

第三步，设计指令结构：采用“角色-任务-规则-格式-示例-边界”的结构。

第四步，注入领域知识：补充了电商评论的常见特点，比如“好评可能是刷的”“差评可能带有情绪化表达”“中性评论通常是在描述事实”。

第五步，设置输出约束：要求以JSON格式输出，包含sentiment和issues两个字段。sentiment只能是positive、negative、neutral之一。issues必须是原文中出现的短语。

第六步，构建测试用例：准备了五十条测试数据，覆盖正面、负面、中性、讽刺、混合情感、无意义文本等情况。

第七步，迭代优化：跑了三轮迭代，准确率从60%提升到92%。

修复后的提示词核心部分是这样的：

# 角色 你是一位电商评论分析专家，擅长从用户评论中判断情感倾向并提取关键问题。 # 任务 请分析以下评论的情感倾向，并提取评论中提到的具体问题。 # 判断规则 1. 正面：评论整体表达满意、推荐、赞扬。 2. 负面：评论整体表达不满、批评、抱怨。 3. 中性：评论主要是客观描述，没有明显情感倾向。 4. 如果评论同时包含正面和负面内容，以主要篇幅的情感为准。 5. 如果评论是讽刺或反话，按照实际表达的情感判断。 # 提取规则 1. 只提取评论中明确提到的问题，不要推断。 2. 问题以短语形式提取，不超过10个字。 3. 如果没有提到具体问题，issues为空数组。 # 输出格式 {"sentiment": "positive/negative/neutral", "issues": ["问题1", "问题2"]} # 示例 评论：质量很好，物流也快，下次还会来买。 输出：{"sentiment": "positive", "issues": []} 评论：用了三天就坏了，客服还不理人。 输出：{"sentiment": "negative", "issues": ["三天就坏了", "客服不理人"]} 评论：东西收到了，包装完整，还没用。 输出：{"sentiment": "neutral", "issues": []} # 边界说明 如果评论为空或无法识别，输出：{"sentiment": "neutral", "issues": []}

4.4 修复效果对比

这个案例说明一个道理：提示词的问题，大部分不是模型能力不够，而是你没把需求说清楚。

5. 常见问题与排查技巧实录

在实际操作中，还有一些高频问题值得单独拿出来说。这些问题不一定能通过模板解决，但知道怎么排查能省很多时间。

5.1 模型不按格式输出怎么办

这是最常见的问题。你要求JSON，它给你Markdown；你要求三段，它给你五段。

排查思路是这样的：

首先，检查你的格式要求是否明确。不要写“用JSON格式”，要写“以JSON格式输出，包含以下字段：...”。字段名、字段类型、是否必填，都要写清楚。

其次，检查示例的格式是否和要求的格式一致。如果你要求JSON但示例是表格，模型会优先学示例。

再次，检查是否有冲突的指令。比如你要求“简洁”但又要求“详细解释每一步”，模型会不知道该听哪个。

最后，如果以上都没问题，可以在提示词末尾加一句“请严格按照上述格式输出，不要添加任何额外内容”。这句话看起来废话，但实测有效。

5.2 模型输出太长或太短怎么办

长度控制是个精细活。写“简短回答”太模糊，写“不超过100字”又太死板。

我的经验是用“范围+弹性”的方式。比如“控制在200到300字之间，根据内容复杂度适当调整”。这样既给了约束，又留了空间。

如果模型总是超长，可以在提示词里加一句“如果内容较多，优先保留核心观点，删减次要细节”。如果总是太短，可以加一句“每个要点至少展开两句话说明”。

还有一个技巧：在示例里体现长度。你给的示例是多长，模型输出大概率就是多长。

5.3 模型“忘记”前面的指令怎么办

长提示词里，模型经常“忘记”前面的内容。这不是模型的问题，是注意力机制的特性。

解决办法有三个：

一是把最重要的指令放在开头和结尾。中间部分模型容易忽略，首尾部分注意力权重更高。

二是用分隔符把不同部分隔开。比如用“---”或者“###”把角色、任务、规则分开，帮助模型区分不同模块。

三是减少不必要的废话。提示词越长，每个部分分到的注意力越少。能删的就删，能合并的就合并。

5.4 模型输出不稳定怎么办

同一个提示词，跑两次结果不一样，这是正常的。模型有随机性，温度参数越高，随机性越大。

如果你需要稳定输出，可以把温度调低。但温度太低又会导致输出死板，缺乏灵活性。一般来说，内容生成场景温度设在0.7左右，信息提取场景设在0.3左右。

如果温度调低了还不稳定，那可能是提示词本身有歧义。同一个输入，模型每次理解不一样，说明你的指令不够明确。

5.5 常见问题速查表

5.6 几个容易被忽略的实操心得

第一个心得：先写测试用例，再写提示词。这跟写代码先写测试是一个道理。你先想清楚什么算成功、什么算失败，写提示词的时候就有方向了。

第二个心得：保留每次修改的版本。不要在一个版本上反复改，改到最后你都不知道最初是什么样了。每次大改就存一个新版本，出问题了可以回滚。

第三个心得：用真实数据测试，不要用编造的数据。编造的数据往往太干净、太典型，真实数据里的噪音和边界情况才是考验提示词的关键。

第四个心得：不要追求一次完美。提示词工程是迭代的过程，先跑通再优化。第一版能到70分就够了，剩下的30分在迭代中慢慢补。

第五个心得：记录失败案例。每次模型输出不符合预期，把输入和输出都记下来。这些失败案例是你优化提示词的最好素材。

6. 提示词工程的长期维护思路

提示词不是写完就完了，它需要维护。模型会更新，需求会变化，数据分布会漂移。你今天调好的提示词，三个月后可能就不管用了。

6.1 建立提示词版本管理

最简单的做法是用文件命名来管理。比如prompt_v1.0.txt、prompt_v1.1.txt。每次修改都存新文件，在文件头部写清楚修改内容和日期。

稍微正式一点的做法是用Git。提示词也是文本文件，完全可以纳入版本控制。每次修改提交一次，写清楚commit message。这样不仅能追溯历史，还能对比不同版本的差异。

6.2 定期回归测试

每次模型更新或者提示词修改后，都要跑一遍回归测试。回归测试的用例不用太多，但必须覆盖核心场景和已知的边界情况。

我习惯维护一个“黄金测试集”，大概二三十条数据，覆盖了所有关键场景。每次改动后跑一遍，通过率低于90%就不发布。

6.3 监控线上表现

提示词上线后，要持续监控实际表现。监控的指标包括：输出格式错误率、用户投诉率、人工复核率等。

如果发现某个指标异常，先看是不是数据分布变了。比如突然来了很多英文评论，而你原来的提示词只针对中文优化过，那表现下降是正常的。

6.4 建立反馈闭环

最好的提示词优化素材来自真实用户的反馈。用户觉得哪里不对，哪里就是需要改进的地方。

我习惯在输出里加一个“反馈”入口，让用户能快速标记“这个回答有帮助”或“这个回答没帮助”。收集到足够多的负反馈后，集中分析原因，然后针对性优化。

这套方法看起来麻烦，但实际做起来，比你每次遇到问题从头排查要高效得多。提示词工程的核心不是写出一个完美的提示词，而是建立一套能持续产出可用提示词的流程。

我在实际项目中的体会是：花在流程建设上的时间，最终都会以效率提升的形式回报回来。一开始可能觉得繁琐，但当你同时维护十几个不同场景的提示词时，没有流程根本管不过来。