企业官网建设流程全解析

1. 为什么“一套提示词打天下”是个伪命题

先把结论摆在前面：不存在一套战无不胜攻无不克的提示词。我做了三年多提示词工程和智能体开发，从最早的 GPT-3.5 时代一路踩坑到现在，见过太多人拿着一份所谓的“万能提示词模板”到处套，结果换个模型、换个任务就翻车。这不是提示词写得不好，而是提示词的本质是任务约束，不是魔法咒语。

你手里那套“战无不胜”的提示词，大概率是在某个特定场景下调出来的——比如让模型做结构化输出、或者做角色扮演、或者做代码生成。它在那个场景下表现好，是因为它恰好把那个场景的关键约束都覆盖到了。但一旦任务类型变了，约束条件变了，模型变了，它就不灵了。

我举个真实的例子。去年有个朋友兴冲冲地跟我说他搞了一套“万能销售话术提示词”，在某个国产大模型上跑得特别好，客户回复率很高。结果他把同一套提示词搬到另一个模型上，输出质量直接崩了——因为不同模型对指令的敏感度、对格式的遵循能力、对上下文长度的处理方式都不一样。提示词工程的核心不是写一份模板，而是理解任务、理解模型、理解约束条件，然后动态调整。

所以这篇文章不是要给你一份“万能提示词”，而是要拆解一套可复用的提示词设计方法论。你学会了这套方法，就能针对任何任务快速写出高质量的提示词，而不是到处找模板。

1.1 提示词工程的本质是什么

很多人把提示词工程理解成“跟 AI 说话的艺术”，这个理解太浅了。提示词工程的本质是用自然语言做编程。你写的每一句话，都是在给模型下达指令、设定约束、提供上下文、定义输出格式。这跟写代码没有本质区别，只不过你的“编程语言”是自然语言。

既然是编程，那就有几个核心要素：

• 输入定义：你要模型处理什么信息？这些信息以什么形式给它？
• 处理逻辑：你要模型怎么处理这些信息？分几步？每步做什么？
• 输出约束：你要模型输出什么格式？长度多少？风格怎样？
• 边界条件：什么情况下模型应该拒绝回答？什么情况下应该追问？

你手里那套“战无不胜”的提示词，如果在这四个维度上都做得很好，那它确实在特定场景下很强。但问题是，不同任务的这四个维度差异巨大。让模型写代码和让模型写营销文案，输入定义、处理逻辑、输出约束完全不同。你不可能用同一套约束覆盖所有场景。

1.2 为什么大多数人写的提示词效果不好

我观察下来，大多数人写提示词效果不好，根本原因就三个：

第一，指令太模糊。“帮我写一篇好文章”——什么叫好？多长？什么风格？给谁看？模型只能猜，猜出来的结果大概率不是你想要的。

第二，缺少示例。你告诉模型“按这个风格写”，但你没给它看过“这个风格”到底是什么样。模型只能根据它训练数据里的理解来猜，猜对了是运气，猜错了是常态。

第三，没有输出格式约束。你让模型输出 JSON，但你没告诉它字段名是什么、类型是什么、嵌套结构怎样。结果它给你输出一段看起来像 JSON 但实际解析不了的东西。

这三个问题，对应的是提示词设计的三个核心技巧：明确指令、少样本示例、结构化输出。后面我会逐一展开讲。

1.3 这套方法论适合谁

如果你只是偶尔用 AI 聊聊天、查查资料，那这篇文章可能对你有点重。但如果你符合以下任何一种情况，这套方法论会帮你省下大量试错时间：

• 你在做智能体开发，需要让 AI 稳定执行特定任务
• 你在做 AI 编程辅助，需要模型按你的规范生成代码
• 你在做内容生产，需要模型稳定输出符合品牌调性的文案
• 你在做数据分析，需要模型从非结构化文本里提取结构化信息
• 你在做销售、客服、运营等场景的 AI 助手，需要模型按话术规范回复

这些场景的共同点是：你需要的是稳定、可复现、可规模化的输出，而不是一次性的创意灵感。这套方法论就是为这种需求设计的。

2. 提示词框架的核心模块拆解

一套完整的提示词框架，应该包含六个核心模块。这六个模块不是必须全部出现，但当你发现输出效果不稳定时，大概率是某个模块缺失了。

2.1 角色定义模块

角色定义是提示词的第一句话，也是最容易被忽视的一句话。很多人写提示词直接从任务开始：“帮我写一段 Python 代码”。但更好的写法是：“你是一位有十年经验的 Python 后端工程师，擅长写高并发、可维护的服务端代码。现在请帮我……”

为什么角色定义重要？因为角色定义会激活模型训练数据中与该角色相关的知识分布。当你告诉模型“你是一位资深律师”，模型在生成回复时会倾向于调用法律相关的术语、逻辑和表达方式。当你告诉模型“你是一位幼儿园老师”，模型会倾向于用简单、亲切、鼓励性的语言。

但角色定义不是越长越好。我见过有人写了两百字的角色定义，把模型夸得天花乱坠，结果模型光顾着“扮演角色”了，正事没干。角色定义的核心是精准，不是华丽。

一个好的角色定义应该包含三个要素：

• 专业身份：模型应该以什么身份来回答
• 核心能力：这个身份最擅长的技能是什么
• 行为准则：这个身份在回答时应该遵循什么原则

举个例子：

你是一位资深数据分析师，擅长从杂乱的数据中提取关键洞察，并用通俗易懂的语言向非技术背景的决策者汇报。你在分析时始终遵循“数据支撑结论”的原则，不做没有数据依据的推测。

这个角色定义只有三句话，但把身份、能力、准则都说清楚了。

2.2 任务描述模块

任务描述是提示词的核心。很多人写任务描述的问题是太笼统。比如“帮我分析一下这份数据”，模型不知道你要分析什么维度、用什么方法、输出什么结果。

好的任务描述应该像一份工作说明书，包含：

• 任务目标：最终要产出什么
• 输入说明：给模型的信息是什么，怎么理解这些信息
• 处理步骤：如果需要多步处理，每一步做什么
• 输出要求：输出格式、长度、风格

我通常会用这样的结构来写任务描述：

## 任务 你的任务是从以下用户评论中提取产品改进建议。 ## 输入 用户评论是一段中文文本，可能包含多条评论，每条评论以换行分隔。 ## 处理步骤 1. 逐条阅读评论，判断每条评论是否包含具体的产品改进建议 2. 如果包含，提取建议的核心内容，归类到以下类别之一：功能需求、体验优化、性能问题、界面设计、其他 3. 如果评论只是情绪表达而没有具体建议，标记为“无具体建议” ## 输出格式 以 JSON 数组输出，每个元素包含以下字段： - comment: 原始评论内容 - category: 建议类别 - suggestion: 提取的建议内容 - has_suggestion: 是否包含具体建议（true/false）

这种结构化的任务描述，模型理解起来几乎没有歧义。

2.3 上下文与约束模块

上下文是给模型提供背景信息的部分。比如你在做客服智能体，你需要告诉模型当前用户的历史订单信息、会员等级、之前的沟通记录等。这些信息不是任务本身，但会影响模型的处理方式。

约束模块则是告诉模型什么不能做。比如：

• 不要编造不存在的信息
• 不要输出与任务无关的内容
• 不要使用过于专业的术语，确保初中生能看懂
• 如果信息不足，不要猜测，直接说明需要更多信息

约束模块是保证输出质量的关键。我见过太多模型“自作聪明”的例子——你让它总结一篇文章，它给你加了一堆原文没有的“延伸思考”。你让它提取数据，它给你补全了缺失的值。这些行为在创意场景下可能是加分项，但在需要精确执行的场景下就是灾难。

2.4 少样本示例模块

少样本示例是提升输出稳定性的最有效手段，没有之一。你给模型看两三个“输入-输出”的示例，它就能理解你要的格式、风格、粒度。

但示例不是随便给的。我总结了几条经验：

第一，示例要覆盖边界情况。如果你只给“正常情况”的示例，模型遇到异常输入时就不知道怎么办。比如你做情感分类，除了给“正面”“负面”的示例，还要给“中性”“混合”的示例。

第二，示例要一致。如果你给的三个示例格式都不一样，模型会困惑到底该学哪个。所有示例的输入格式、输出格式、标注粒度必须统一。

第三，示例数量不是越多越好。对于大多数任务，2-5 个示例就够了。示例太多会占用大量上下文窗口，而且边际收益递减。我通常的做法是：先给 2 个示例，如果效果不稳定，再加到 5 个。

第四，示例要放在任务描述之后、实际输入之前。这个顺序很重要。模型需要先理解任务，再看示例，最后处理实际输入。如果你把示例放在任务描述之前，模型可能还没理解任务就开始看示例，效果会打折扣。

2.5 输出格式控制模块

输出格式控制是提示词工程里最“工程化”的部分。如果你需要模型输出结构化数据（JSON、XML、YAML、CSV），你必须精确地定义格式。

我见过太多人写“请以 JSON 格式输出”，然后模型输出的 JSON 解析不了。原因通常是：

• 没有指定字段名
• 没有指定字段类型
• 没有指定嵌套结构
• 没有指定是否允许额外字段
• 没有指定空值怎么表示

一个完整的输出格式定义应该长这样：

以 JSON 格式输出，结构如下： { "summary": "string, 不超过 100 字的摘要", "keywords": ["string, 3-5 个关键词"], "sentiment": "string, 取值范围：positive/negative/neutral", "confidence": "number, 0-1 之间的浮点数，表示分析置信度", "details": { "reason": "string, 判断理由", "evidence": ["string, 原文中的支撑语句"] } }

如果模型输出的 JSON 经常有问题，还有一个技巧：在提示词末尾加一句“只输出 JSON，不要输出任何其他文字”。这能防止模型在 JSON 前后加解释性文字。

2.6 迭代优化模块

提示词不是一次写好的，是迭代出来的。我通常的迭代流程是：

1. 写初版：按上述五个模块写一版提示词
2. 小样本测试：用 5-10 个典型输入测试
3. 分析失败案例：看哪些输入输出不符合预期
4. 定位问题模块：是角色定义不够精准？还是任务描述有歧义？还是缺少示例？
5. 修改提示词：针对性地调整
6. 回归测试：用之前的测试集重新测试，确保修改没有引入新问题

这个流程听起来很工程化，但实际操作起来很快。我通常迭代 3-5 轮就能让提示词在测试集上达到 90% 以上的准确率。

3. 从零搭建一套可复用的提示词框架

前面讲了理论，这一章我带你从零搭建一套完整的提示词框架。我会用一个实际场景来演示：从用户反馈中提取产品改进建议并分类。这个场景足够通用，你可以把它迁移到自己的任务上。

3.1 场景分析与需求拆解

在写提示词之前，先要搞清楚任务到底是什么。我通常会问自己几个问题：

• 输入是什么？用户反馈文本，可能是一条，也可能是多条
• 输出是什么？结构化的改进建议列表，每条包含建议内容、类别、优先级
• 难点在哪里？用户反馈可能很模糊、可能包含多条建议、可能只是情绪发泄
• 怎么判断输出好坏？提取的建议是否准确、分类是否合理、是否遗漏了重要信息

把这些想清楚之后，再开始写提示词。

3.2 第一版提示词：快速验证

第一版不需要完美，目标是快速验证方向对不对。我通常会写一个最简版本：

你是一位产品经理，擅长从用户反馈中提取改进建议。 请从以下用户反馈中提取产品改进建议，并分类到：功能需求、体验优化、性能问题、界面设计、其他。 用户反馈： {{feedback}} 输出格式： - 建议内容 | 类别

这个版本很简单，但已经包含了角色定义、任务描述、输出格式三个核心模块。用它跑几条测试数据，看看模型能不能理解任务。

3.3 第二版提示词：增加约束和示例

第一版跑下来，你可能会发现一些问题：模型有时候会把情绪表达也当成建议、有时候分类不准确、有时候输出格式不统一。这时候就需要增加约束和示例。

你是一位资深产品经理，有 8 年 B 端产品设计经验，擅长从用户反馈中提取可落地的产品改进建议。 ## 任务 从以下用户反馈中提取产品改进建议，并分类。 ## 分类标准 - 功能需求：用户希望增加新功能或修改现有功能 - 体验优化：用户希望操作更顺畅、更符合习惯 - 性能问题：涉及加载速度、响应时间、稳定性 - 界面设计：涉及视觉、布局、交互设计 - 其他：不属于以上类别的建议 ## 约束 - 只提取具体的、可执行的建议，不要提取纯情绪表达 - 如果一条反馈包含多个建议，拆分成多条 - 如果反馈中没有具体建议，输出“无具体建议” - 不要编造反馈中没有提到的内容 ## 示例 输入：这个页面加载太慢了，每次都要等好几秒，能不能优化一下？ 输出：建议内容：优化页面加载速度 | 类别：性能问题 输入：我希望能够批量导出数据，现在一条一条导出太麻烦了。 输出：建议内容：增加批量导出功能 | 类别：功能需求 输入：这个按钮的颜色太浅了，我根本看不清。 输出：建议内容：加深按钮颜色，提高对比度 | 类别：界面设计 ## 实际输入 {{feedback}} ## 输出格式 以 JSON 数组输出： [ { "suggestion": "建议内容", "category": "类别", "original_text": "对应的原文片段" } ]

这一版增加了分类标准、约束条件、少样本示例和结构化输出格式。跑下来效果会明显好很多。

3.4 第三版提示词：处理边界情况

第二版在大多数情况下表现不错，但遇到一些边界情况还是会出问题。比如：

• 反馈是英文的怎么办？
• 反馈包含多个建议但混在一起怎么办？
• 反馈是讽刺或反话怎么办？

针对这些问题，再增加一轮约束：

## 边界情况处理 - 如果反馈是英文，先翻译成中文再处理 - 如果一条反馈包含多个建议，拆分成多条输出 - 如果反馈包含讽刺或反话，按字面意思理解，不要过度解读 - 如果反馈涉及多个类别，选择最相关的一个类别 - 如果反馈信息不足，在 suggestion 中注明“信息不足，需要进一步了解”

3.5 提示词模板的模块化封装

当你写了多个场景的提示词之后，你会发现很多模块是通用的。比如角色定义、约束条件、输出格式控制，这些在不同任务中结构类似。这时候就可以做模块化封装。

我的做法是维护一个“提示词组件库”，包含：

• 角色定义组件：不同身份的角色定义模板
• 约束组件：常见的约束条件，如“不要编造信息”“如果信息不足请说明”
• 输出格式组件：JSON、XML、Markdown 表格等格式的模板
• 示例组件：不同任务的少样本示例模板

当你需要写一个新提示词时，从组件库里挑选合适的模块，组合起来，再针对具体任务调整。这样效率会高很多。

3.6 不同模型的适配策略

不同模型对提示词的敏感度不同。我实测下来的一些经验：

这个表格不是绝对的，但可以作为起点。你拿到一个新模型，先用同一套提示词跑一遍，看输出质量，再针对性调整。

4. 提示词工程在智能体开发中的实战应用

提示词工程在智能体开发中尤为重要，因为智能体需要稳定、可靠、可预测的行为。一个聊天机器人偶尔说错话没关系，但一个自动处理订单的智能体如果理解错了指令，后果可能很严重。

4.1 智能体中的提示词分层架构

在智能体开发中，我通常会把提示词分成三层：

第一层：系统提示词（System Prompt）这是智能体的“人格”和“行为准则”，在整个会话过程中保持不变。它定义了智能体的身份、能力边界、回复风格、安全约束等。

第二层：任务提示词（Task Prompt）这是针对具体任务的指令，每次任务不同。比如用户让智能体查订单，任务提示词就是“查询订单状态”的相关指令。

第三层：上下文提示词（Context Prompt）这是动态注入的上下文信息，比如用户的历史订单、当前时间、之前的对话记录等。

这三层提示词组合在一起，形成最终发给模型的完整提示词。分层的好处是可维护性——系统提示词改一次，所有任务都生效；任务提示词只影响特定任务；上下文提示词动态生成，不污染前两层。

4.2 工具调用中的提示词设计

智能体通常需要调用外部工具（查数据库、调 API、发邮件等）。工具调用的提示词设计有几个关键点：

第一，工具描述要精确。你要告诉模型这个工具是干什么的、需要什么参数、返回什么结果。描述越精确，模型调用越准确。

第二，参数格式要明确。如果工具需要 JSON 参数，你要在提示词里给出参数结构示例。

第三，调用条件要清晰。什么情况下应该调用这个工具？什么情况下不应该？这个边界要划清楚。

我通常会用这样的格式来描述工具：

## 可用工具 ### 查询订单 - 功能：根据订单号查询订单状态 - 参数： - order_id: string, 订单号，格式为 ORD-XXXXXXXX - 返回：订单状态、下单时间、预计送达时间 - 调用条件：当用户询问订单状态且提供了订单号时调用 - 不调用条件：用户没有提供订单号时，先追问订单号

4.3 多轮对话中的提示词管理

多轮对话是智能体开发中最容易出问题的地方。因为上下文会越来越长，模型可能会“忘记”之前的指令，或者被后面的对话带偏。

我的做法是：

第一，每轮对话都重新注入系统提示词。不要假设模型记得上一轮的系统提示词。每轮都把系统提示词放在最前面。

第二，控制上下文长度。如果对话历史太长，只保留最近 N 轮，或者对历史对话做摘要。

第三，关键约束重复强调。如果某个约束特别重要（比如“不要泄露用户隐私”），在每轮对话的末尾再强调一次。

第四，用状态变量管理对话状态。不要依赖模型记住对话状态，而是用外部变量记录当前状态，每轮把状态注入提示词。

4.4 提示词版本管理与 A/B 测试

当你的智能体上线之后，提示词的修改需要谨慎。我通常的做法是：

• 版本管理：每次修改提示词都记录版本号、修改内容、修改原因
• A/B 测试：新版本提示词先在小流量上测试，对比关键指标（任务完成率、用户满意度、平均对话轮数）
• 回滚机制：如果新版本指标下降，能快速回滚到旧版本
• 灰度发布：逐步扩大新版本的流量比例，观察指标变化

这些做法听起来很“工程”，但实际做起来并不复杂。关键是要有记录、有对比、有回滚。

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

这一章我整理了一些在实际操作中经常遇到的问题和解决方法。这些问题大多是我自己踩过的坑，或者帮别人排查时遇到的。

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

这是最常见的问题。你明明写了“以 JSON 格式输出”，模型却给你输出一段带解释的文字。解决方法：

第一，检查格式定义是否完整。你有没有给出完整的 JSON 结构？字段名、类型、嵌套关系都写清楚了吗？

第二，在提示词末尾加一句“只输出 JSON，不要输出任何其他文字”。这句话很管用。

第三，给一个输出示例。模型看到示例之后，遵循格式的概率会大幅提升。

第四，如果还是不行，用“预填充”技巧。在提示词末尾加上{，让模型从{开始续写。这样模型就只能输出 JSON 了。

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

长度控制是另一个常见问题。解决方法：

• 明确指定字数范围：“输出 100-150 字”
• 指定段落数：“输出 3 个段落”
• 指定要点数：“列出 5 个要点”
• 给示例：给一个长度合适的示例，模型会模仿

如果模型总是输出太长，还有一个技巧：在提示词里加一句“简洁回答，不要展开解释”。如果总是太短，加一句“详细说明，每个要点至少 50 字”。

5.3 模型“幻觉”怎么处理

幻觉是指模型编造不存在的信息。在需要精确执行的场景下，幻觉是致命的。处理方法：

第一，明确约束：“只使用提供的材料，不要编造任何信息”。

第二，要求引用来源：“每个结论都必须引用原文中的具体语句”。

第三，信息不足时要求说明：“如果信息不足，直接说明需要更多信息，不要猜测”。

第四，用少样本示例展示“不知道”的情况：给一个“信息不足”的示例，让模型知道这种情况应该怎么处理。

5.4 提示词效果不稳定的排查思路

有时候同一套提示词，有时候效果好，有时候效果差。排查思路：

5.5 提示词优化的常见误区

最后说几个我见过的常见误区：

误区一：提示词越长越好。不是。提示词太长会占用上下文窗口，而且可能让模型“迷失”在细节里。关键是精准，不是长度。

误区二：一套提示词走天下。不同任务、不同模型、不同场景，提示词都需要调整。没有万能模板。

误区三：只调提示词，不调参数。temperature、top_p、max_tokens 这些参数对输出影响很大。需要稳定输出时，temperature 设低；需要创意时，temperature 设高。

误区四：不测试就上线。提示词必须经过充分测试才能上线。我通常至少用 20-30 个测试用例验证，覆盖正常情况和边界情况。

误区五：忽略负面示例。除了告诉模型“应该怎么做”，还要告诉它“不应该怎么做”。负面示例能有效减少错误输出。

6. 提示词工程的进阶方向

如果你已经掌握了前面的内容，想进一步提升，可以关注这几个方向。

6.1 自动提示词优化

手动调提示词效率有限。现在有一些工具和方法可以自动优化提示词，比如用另一个模型来生成和评估提示词变体，然后选择效果最好的。这个方向适合有工程能力的团队。

6.2 提示词与微调的配合

提示词工程和模型微调不是互斥的。对于高频、固定的任务，微调可能比提示词更稳定、更高效。对于低频、多变的任务，提示词更灵活。实际项目中，通常是两者结合：用微调让模型掌握基础能力，用提示词处理具体任务。

6.3 多智能体协作中的提示词设计

在多智能体系统中，每个智能体有自己的角色和提示词，智能体之间需要协作。这时候提示词设计要考虑：智能体之间怎么通信、任务怎么分配、冲突怎么解决。这是一个更复杂的领域，但核心原则是一样的：明确角色、明确任务、明确约束、明确输出格式。

6.4 提示词安全与对抗

提示词注入是一个真实存在的安全问题。用户可能在输入中嵌入恶意指令，试图让智能体执行非预期操作。防御方法包括：输入过滤、指令隔离、输出审查等。这个方向在智能体上线后尤其重要。

我个人在实际操作中的体会是，提示词工程没有捷径，就是理解任务、理解模型、持续迭代。你看到的那些“战无不胜”的提示词，背后都是大量测试和调整的结果。与其到处找模板，不如踏踏实实掌握方法论，针对自己的场景写出真正好用的提示词。