企业官网建设流程全解析

• 提示工程

本文以开源仓库 GPTs 中泄漏的 Customer Service GPT 提示词（由 Daniel J Patterson 构建）为绝对核心，逐条拆解其"辅助客服坐席"的双层对话架构、10 条客服回复生成指令与 10 条企业语言语调遵从指令，并结合仓库内其他支持类 GPT 提示词横向印证，最终给出可直接复刻、可迁移到任意企业场景的客服 GPT 配置方案。读完本文，你将掌握一套"先收集信息、再生成合规回复"的企业客服提示词工程方法论，并能在自己的 GPT 或智能客服系统中落地应用。

一、文档定位与仓库背景

本仓库 README.md 将自身定位为 "leaked prompts of GPTs" 的集合，收录了大量来自 OpenAI GPT 商店的泄漏系统提示词。Customer Service GPT 即其中之一，其公开描述为：

A support bot adhering to company language guidelines.

即"一个严格遵循公司语言规范的支持机器人"。与仓库中面向 C 端用户的娱乐型 GPT（如 AI Lover、Moby Dick RPG）不同，这是一款典型的B 端业务型 GPT：它的最终输出对象不是终端顾客，而是企业里的客服坐席（customer service representatives）。这一"服务对象"差异直接决定了整套提示词的结构设计。

值得说明的是，本文所依据的提示词正文位于 prompts/Customer Service GPT.md 的代码块内。它沿用了 OpenAI 官方生成的 GPT 身份样板（"You are a 'GPT' – a version of ChatGPT that has been customized for a specific use case..."），这一样板在仓库多个泄漏提示词中反复出现，例如 GPT Builder 同样以 "You are an iterative prototype playground..." 开头——可以推断这是 GPT 构建器自动注入的通用前缀，而真正体现产品差异化的，是其后紧随的自定义指令正文。

二、核心架构：面向坐席的"双层对话"设计

这是本提示词最值得学习的设计决策，原文用一个段落明确规定了信息流向（prompts/Customer Service GPT.md）：

The GPT speaks to the user of the GPT and will ask the user to provide the information needed to answer the question before it formulates the response to send to the customer. Also the GPT always makes it clear what the user should respond to the customer, and if it does not have enough info to formulate a response it will ask the user for more information about their company.

其含义可以拆解为三条关键规则：

1. 对话对象是坐席，不是顾客：用户把顾客的原话、背景贴给 GPT，GPT 先向用户（坐席）确认缺失信息，而不是直接替坐席编造一个无法核实的答复。
2. 产出物边界清晰：GPT 必须明确指出"你应该回复顾客什么"（what the user should respond to the customer），避免坐席把辅助草稿误当成最终话术直接发出。
3. 信息不足时主动追问：如果掌握的信息不足以形成准确回复，GPT 应继续向用户索要关于其公司的更多资料，而不是硬着头皮生成。

首次消息的引导脚本

原文还规定了"第一次对话必须做什么"（第 17 行）：

After the first message, the GPT should welcome the user to CX GPT and ask for the name of the company that it will be providing customer service responses for and a list of FAQs and/or macros in order to match the company's tone/voice and provide the most accurate information possible.

即首条回复必须完成三件事：

• 欢迎用户使用 CX GPT（注意原文中 GPT 自称 "Customer Experience GPT"，与展示名 Customer Service GPT 略有出入，属于提示词内部的命名混用）；
• 询问所服务的公司名称；
• 索取 FAQ 列表和/或话术宏（macros），以便匹配公司的语气/声音（tone/voice）。

这一"开局信息收集清单"是一个高价值的工程技巧：它把"语调对齐"从运行时猜测提前到了会话初始化阶段，让 GPT 从一开始就具备公司背景，从而显著降低后续回复跑偏的概率。

三、客服回复生成指令：10 条可执行规范

原文以 "Instructions for Generating Customer Service Responses" 为标题，给出了 10 条面向"生成最终回复"的指令（第 19-43 行）。下表先给出全量清单，随后逐条展开解析：

逐条解析：

1. 先理解再回复（Understand the Inquiry）：要求 GPT 仔细阅读顾客的问题或诉求，在真正理解核心议题之后再起草回复。这与"追问机制"配合，能有效避免对歧义问题答非所问。

2. 礼貌与共情，且使用替代性道歉（Be Polite and Empathetic）：除礼貌开场和共情外，原文给出了一句极具工程价值的硬性话术约束：

Never say sorry for the delay, say thank you for your patience

即"永远不要为延误说抱歉，要说感谢您的耐心"。这是典型的负面话术改写（rephrasing）策略：把道歉导向的负面情绪替换为致谢导向的正向表达，既承认了等待事实，又维护了品牌形象。此类"禁区词 + 替代表达"可以直接沉淀为企业的通用话术规则。

3. 提供准确信息（Provide Accurate Information）：要求事实正确、与顾客问题相关，并援引公司政策、产品手册或服务指南作为依据。这为后面"接入知识库"的需求埋下了伏笔。

4. 简洁清晰（Be Concise and Clear）：避免过度技术化语言，回复要容易理解、切中要点。

5. 提供解决方案或下一步（Offer Solutions or Next Steps）：区分两类场景——问题类诉求给出明确解决方案或建议下一步；信息咨询类则给出完整答案。

6. 个性化（Personalize the Response）：如可能，参考顾客此前的互动记录或本次提供的具体细节进行个性化，避免千篇一律。

7. 礼貌收尾（Close Politely）：以礼貌的结束语收尾，主动提供进一步帮助并感谢顾客联系。

8. 合规检查（Check for Compliance）：确保回复符合公司政策与法律准则，尤其是客户数据隐私相关要求。这条指令把"合规"内化为生成流程的一个必经步骤，而非事后补救。

9. 及时性（Promptness）：以快速生成为目标，维持客服效率。

10. 发送前复查（Review Before Sending）：在最终确定回复前，检查错误、清晰度和语气，确保达到优质客服的标准。

这 10 条事实上构成了一个完整的"客服回复质量检查单（QA checklist）"，从理解→措辞→内容→结构→合规→速度→质检，覆盖了一条客服消息从起草到发送的完整链路。

四、企业语言与语调遵从指令：10 条品牌一致性约束

原文第二部分以 "Instructions for GPT to Adhere to Company's Language and Tone in Customer Service Responses" 为题，给出了 10 条专门约束"语气与语言一致性"的指令（第 45-65 行）：

逐条解析：

1. 理解公司语气与语言（Understand Company's Tone and Language）：明确列出语气可能属于"正式（formal）、随意（casual）、技术（technical）或友好（friendly）"，并要求在生成前完成识别。这是所有后续语气约束的前提——它把"品牌声音"显式建模为输入参数。

2. 使用官方语言模板（Use Official Language Templates）：如有公司提供的语言模板或风格指南，一律以其为基础，确保所有回复与既有风格一致。这解释了为什么提示词首段会要求开局就索取 FAQ 和宏。

3. 严格遵守公司术语（Strict Adherence to Company's Terminology）：要求使用公司内部惯用的术语和短语，禁止自行更换措辞。对客服场景而言，术语漂移（terminology drift）是品牌一致性最大的隐性风险，此条直接将其列为硬约束。

4. 在回复中体现公司价值观（Reflect Company's Values in Responses）：每条回复都应反映公司的核心价值观与使命，以维持统一的品牌形象。

5. 不偏离脚本化回复（Avoid Deviating from Scripted Responses）：使用公司宏或脚本回复时，除非为了清晰或针对性确有必要，否则不得改动。这条与第 3 条互相呼应，共同把"一致性"置于"自由度"之上。

6. 定期更新语言与语调（Regular Updates on Language and Tone）：要求紧跟公司沟通风格或品牌指南的变化，并迅速将这些变化纳入生成流程。提示词因此具备了"可维护性"——它不是一次性的死规则，而是要求随品牌演进持续更新。

7. 模仿公司回复模式（Mimic Company's Response Patterns）：通过分析既有客服回复来学习其语气细节。这与第 1 条形成闭环：先理解风格，再通过样本模仿风格。

8. 问候语与结束语一致（Consistency in Greetings and Closings）：统一使用公司标准问候语与结束语，呼应前文"tailor its greetings and closings to match the customer's query"的个性化要求——个性化发生在标准模板内部，而非推翻模板。

9. 语言与语气的反馈机制（Feedback Mechanism for Language and Tone）：建立反馈回路，让客服坐席可以对"生成回复是否准确反映公司语言与语气"给出反馈。这是一个非常成熟的工程化设计：将提示词系统设计为可迭代闭环而非一次性提示。

10. 法律与道德合规（Compliance with Legal and Ethical Standards）：始终确保回复符合法律与道德标准，特别是客户隐私与数据保护。

五、关键设计亮点提炼

结合全文，这套提示词中有五个值得单独拎出来学习的工程亮点：

1. "双层对话 + 产出物标注"：GPT 面向坐席提问、面向顾客产出，且始终明确"你应该回复顾客什么"。这避免了 AI 直接面向顾客带来的不可控风险，是"AI 辅助人工坐席"类产品最稳妥的交互范式。
2. 开局信息收集脚本：首次对话强制收集公司名、FAQ、宏，把语调对齐前置到会话初始化阶段。
3. 负面话术改写规则："Never say sorry for the delay, say thank you for your patience" 是可直接照搬的通用话术规则。
4. "禁区 + 模板"双约束：术语严格遵从、宏脚本不轻易改动（禁区），同时保留问候语/结束语的个性化空间（模板内定制）。
5. 反馈闭环与持续更新：通过坐席反馈机制和"定期更新"要求，把提示词变成可持续进化的系统而非静态文本。

六、仓库佐证：同仓库支持类 GPT 提示词的横向印证

本仓库除 Customer Service GPT 外，还收录了多个"支持/服务"主题的提示词，可作横向参照：

• Tech Support Advisor：由 ChatGPT 官方构建的 IT 支持顾问，主打"从配置打印机到设备排障，一步步帮你"（"From setting up a printer to troubleshooting a device, I'm here to help you step-by-step"）。它同样以"逐步引导（step-by-step）"为核心交互模式，并配置了 python、browser、myfiles_browser 等工具能力，说明支持类 GPT 普遍采用"结构化引导 + 工具辅助"的组合，而 Customer Service GPT 则在语言一致性和合规上做了更重的约束。
• Email Responder Pro：由 Max Krishtul 构建，是"粘贴来信、生成得体回信"的邮件场景助手。它同样遵循"先粘贴原文 → 分析内容/语气/意图 → 生成对等语气的回复 → 意图不明时追问澄清"的流程，与 Customer Service GPT 的"先收集信息再生成回复"在方法论上高度同构。

从源码结构可以推断：这类"回复生成类"GPT 提示词的通用骨架是——角色定位 → 输入收集（粘贴原文/提问补全）→ 生成规范（语气/结构/合规检查单）→ 输出边界（明确指出回复内容）。Customer Service GPT 的价值正是在这个通用骨架上，额外叠加了"企业语言遵从"这一层纵深约束。

七、复刻与落地指南：如何用该提示词配置企业客服 GPT

基于原文与仓库证据，在 OpenAI GPT Builder 或其他支持系统提示词的自定义助手中复刻该方案，推荐按以下步骤进行：

1. 准备公司侧配置物料（对应开局收集脚本）

• 公司名称与品牌定位（对应 "ask for the name of the company"）；
• FAQ 清单（对应 "a list of FAQs"）；
• 话术宏 / 脚本回复集（对应 "macros"，直接决定问候语、结束语与标准答复）；
• 公司语气画像：在正式/随意/技术/友好之间明确取值；
• 风格指南或官方语言模板（如有）；
• 公司政策、产品手册、服务指南（作为准确性依据）；
• 合规边界：明确哪些客户隐私信息不可提及、不可外泄。

2. 指令组装（保留原文 20 条并做参数化）

可直接以原文两个指令块为骨架，将其中"公司"占位符替换为实际信息。一个最小可运行的结构示意如下（仅展示组织方式，实际应保留原文全部 20 条指令）：

你是 <公司名> 的客服回复助手，面向客服坐席工作： 1. 对话对象是坐席，不是顾客；生成回复前先向坐席收集缺失信息，并明确指出坐席应回复顾客的内容。 2. 首次对话：欢迎使用客服助手，询问公司名称，并索取 FAQ 与话术宏清单。 3. 生成回复时必须：先理解诉求、礼貌共情、不说道歉改说感谢耐心、引用公司政策与手册、简洁清晰、给出方案或完整答案、尽量个性化、礼貌收尾、做合规检查、快速生成、发送前复查。 4. 语言与语调遵从：识别公司语气画像、使用官方模板、严格使用公司术语、体现公司价值观、不随意偏离宏/脚本回复、及时跟进风格更新、模仿公司既有回复模式、统一问候与结束语、建立坐席反馈闭环、遵守法律与隐私规范。

3. 运行与迭代建议

• 在首次会话中主动完成信息收集，确认 FAQ 与宏已载入后再开始产出；
• 每次生成都明确划分"回复给顾客的话术"与"给你的内部说明"，防止坐席误发；
• 建立坐席反馈台账：定期把"语气不符"的案例回填进提示词，呼应原文的反馈机制要求；
• 若企业有更细的 FAQ 文档，可参考本仓库其他 GPT 使用上传文件（knowledge）能力的先例，将知识库文档作为 GPT 的 knowledge 文件接入，以增强第 3 条"引用公司政策与手册"的准确性。

4. 适用前提与限制（基于原文可观察到的边界）

需要说明的是，泄漏提示词正文中并未声明该 GPT 具备联网检索、代码执行或文件检索等工具能力，其知识来源依赖坐席人工提供与公司背景资料；因此它的"准确性"高度依赖输入信息的完整度，这也正是原文反复强调"信息不足必须追问"的原因。在复刻时，若业务需要实时订单查询、知识库检索等能力，需按平台规则另行接入工具（Actions / knowledge），而提示词层则负责保证生成质量与语气合规。

八、结语

Customer Service GPT 的泄漏提示词虽然篇幅不长，却是一份教科书级别的企业客服提示词工程样例：它用"双层对话"解决了 AI 直接对外发言的失控风险，用"开局信息收集"解决了语气对齐问题，用 20 条指令把"礼貌、准确、简洁、个性化、合规、及时、质检"拆解为可执行清单，再用"术语禁区 + 模板 + 反馈闭环"把品牌一致性落地为可持续维护的流程。任何计划在企业内落地 AI 客服辅助系统的团队，都可以直接以本文第七节的方法，把这份提示词改造成自己的生产级方案。

深入阅读：Customer Service GPT 原始提示词｜仓库 README 与提示词索引｜同类支持类提示词 Tech Support Advisor｜Email Responder Pro

• 提示工程