bolna-voice-prompt

Bolna 语音提示词工程

此技能用于为基于 GPT-4.1 mini 运行的 Bolna 语音 Agent 编写可用于生产环境的提示词。此格式经过严格设计——GPT-4.1 mini 会在通话时执行这些提示词，结构、变量表示法或语言顺序上的任何偏差都会降低可靠性。请将本文件中的规则视为不可或缺的要求。

此技能涵盖的内容

两种工作流，均由用户触发：

1. 根据用例描述编写新提示词。 用户描述通话场景（招聘筛选、预约、NPS、续约、线索资格判定等）以及已有的预加载变量。输出：遵循下方确切结构的完整提示词。
2. 根据通话转录修复现有提示词。 用户粘贴通话转录（有时也会附上当前提示词），并指出问题。输出：修订后的部分内容或完整更新的提示词，并附上简短的更改说明。诊断方法请参阅 references/transcript-workflow.md。

如果用户的需求说明未明确 Agent 的性别、主要语言或主要通话目标，请先提出一个有针对性的澄清问题，再开始起草。如果这三项都明确，便直接起草完整提示词——不要就通话方向、职位名称、分支机构覆盖范围等可以合理推断的信息反复向用户提问。

起草前：始终加载静态模块

第 1 节中的两个子节——# Conversational Naturalization (Acknowledgements & Flow Softening) 和 # Pronunciation and Script Normalisation——必须逐字复制到每个提示词中。请阅读 references/static-modules.md，并将其内容粘贴到新提示词中。不要改述、概括、缩短或“改进”这些模块。它们经过调优，任何改动都会破坏 Agent 的行为。

必需的章节结构

每个提示词都必须严格按照以下顺序组织。章节编号不可省略。第 1 节始终使用下方指定的子节名称；第 3 节及之后的流程章节则根据其功能命名。

第 1 节：身份与行为方式

第 1 节具有全局效力，约束后续所有内容。生产环境中既有 SECTION 1: IDENTITY AND DEMEANOUR，也有 SECTION 1: DEMEANOUR AND IDENTITY，两种写法都可以；选择一种并在整个提示词中保持一致。SECTION 1: Demeanour & Identity（大小写混用且含 &）也有效——章节和小节标题中允许使用 &（参见下文“特殊格式”）。

使用以下小节，并以 # 引出。以下为规范顺序，但生产环境中的提示词偶尔会调换 Tone/Goal 的顺序，或在 Identity 与 Tone 之间插入 Context/Environment——这也没问题，只要每个小节仍各司其职：

• # Identity — 以固定的方括号标签标题行开头，后接一段描述性文字。标题行有以下两种形式，生产环境中都出现过：
  • You are [Agent_name: Shivani], [Gender: Female]
  • [Agent_name: Juhi], [Gender: Female] 这里的方括号是带标签的元数据格式，不是上下文变量——不要尝试用任何捕获到的值填充它们。后续段落要说明 Agent 的职责、所代表的公司，以及在整个通话过程中必须保持一致的身份声明（包括不得披露 AI 身份的条款）。
• # Tone — 用三到四行描述 Agent 应有的表达风格，并与客户的品牌调性一致。可选用专业、亲切、沉稳、自信、尊重等词语。
• # Goal — 用行动导向的措辞说明通话的主要目标。如果不同场景有不同目标（例如确认面试或重新安排面试），应明确列出每个目标。
• # Guardrails — 严格的行为边界：Agent 必须做什么、绝不能做什么、应避免什么。包括客户特定限制（例如“绝不要引用第 8 节中未提及的价格”）和固定规则（不使用感叹号、不长篇独白）。
• # Language — 说明主要语言、次要语言、通话开场使用的语言，以及切换规则（通常是：跟随来电者使用的语言；如果来电者在通话中切换语言，Agent 也相应切换）。
• # Conversation Structure and Flow — 说明通话从头到尾的推进方式、必选与可选步骤、处理 FAQ 或旁支问题后如何回到主流程，以及不得重新开始前面小节的要求。
• # Handling Customer Queries — 说明 Agent 如何先倾听再回应，如何确保回答符合当前小节的目标，在需要澄清时如何礼貌地换一种说法而非逐字重复，以及如何将范围外的问题转交给资深同事。此标题中的名词（以及第 1 节中使用的名词）应与来电者的角色一致：Porter 使用 # Handling Partner Queries，Zepto/CureFoods 招聘场景使用 # Handling Employee Queries，OEG 使用 # Handling Candidate Queries，upGrad 使用 # Handling Learner Queries。为整个提示词选择一种来电者称谓，并始终保持一致。

然后添加以下两个静态模块（从 references/static-modules.md 原样复制）：

• # Conversational Naturalization (Acknowledgements & Flow Softening)
• # Pronunciation and Script Normalisation

静态模块之后，根据使用场景的需要添加第 1 节的其他小节。生产环境中出现过的可选小节：

• # Context — 简短段落，描述通话情境（用于 Whizzy、Zepto、CureFoods 等招聘类提示词）。
• # Environment — 简短段落，描述来电者可能所处的环境（用于 Whizzy、Announcements）。
• # Ambiguous Response Handling、# Speech Style、# Eligibility Criteria、# Edge Cases、# Discount Logic、# Objection Handling、# Upsell Triggers、# Numeric Expression Rules、# For Hindi Conversation（Schoolini 中用于塑造印地语表达风格的模式）。根据使用场景选择所需内容。

第二部分：对话开场白

开场语须按固定顺序用所有必需的语言撰写（印地语／印地语与英语混合语优先，英语其次，任何第三种语言排第三），后接其指令块。本部分始终存在。

第三部分起：用例流程部分

按顺序编号，并以其功能命名 — SECTION 3: INTENT DETECTION、SECTION 4: BASIC DETAILS COLLECTION、SECTION 5: ELIGIBILITY CHECK、SECTION 6: APPOINTMENT BOOKING 等。这些部分包含实际问题、分支和路由。

第 X 部分：结束语

始终为倒数第二部分。包含多个分支 — BRANCH A: Successful Close、BRANCH B: Not Interested、BRANCH C: Rescheduling、BRANCH D: Wrong Number 等 — 每个分支均以其处理的结果命名。

第 X 部分：上下文（需要时）

用于定价、产品目录、位置数据、政策事实的结构化 JSON 知识库。只有当流程需要查询信息时才加入。格式详见 references/section-templates.md。

第 X 部分：常见问题（始终为最后一部分）

严格使用 YAML。格式详见 references/section-templates.md。

关于具有精确开场白／问题／结束语／分支格式的部分模板，请参阅 references/section-templates.md。

变量表示法 — 绝不可混用

变量类型恰好有两种，混用会导致通话出错。

• 预加载变量：通话前已知，并通过 CRM／后端／API 传入。使用带下划线的花括号：{full_name}、{contact_number}、{appointment_date}。花括号内不得有空格。
• 上下文变量：通话期间从来电者的回答中获取，或用于设置内部标记。使用带下划线的方括号：[name]、[contact_number]、[preferred_time]、[wants_callback]。方括号内不得有空格。

仅使用用户明确列出的预加载变量。 不要自行添加其他变量。如果用例需要用户未列出的数据，请在对话中将其记录为上下文变量。

一种常见模式是在问题开头将预加载变量赋值给上下文变量，例如：You have the values [name] = {referee_name}. 这样可以在后续提示词中清晰地引用 [name]，同时明确其来源。

脚本文本格式

每条脚本台词 — 开场白、问题、结束语、固定回复 — 都必须使用两种语言，并遵循固定顺序。印地语（或印地语与英语混合语）始终在前，英语始终在后，任何第三种语言排在第三位。顺序绝不可颠倒。

Opening (Hindi): [Devanagari script]
Opening (English): [English text]

Question 1 (Hindi): [Devanagari script]
Question 1 (English): [English text]

Closing (Hindi): [Devanagari script]
Closing (English): [English text]

如果用例明确要求使用 Hinglish（印地语与英语混合，主要以天城文书写并嵌入罗马字词语），标签应为 (Hinglish) 而不是 (Hindi)，且仍须排在最前。

印地语台词中的天城文规则

• 印地语台词使用天城文书写。
• 印度日常对话中常用的英语借词，即使出现在印地语台词中也保留罗马字：app、WhatsApp、form、session、login、OTP、link、email、call、number、register、confirm、please、thank you、okay、sorry。不要将这些词音译。
• 在印地语句子中念出的首字母缩略词须以天城文逐字拼写 — SSC → एस एस सी、UPI → यू पी आई、EMI → ई एम आई。（更全面的规则由 # Pronunciation and Script Normalisation 模块统一处理。）

脚本文本中的数字

所有脚本文本和常见问题答案中的数字都须以所在语言的文字形式写出。“五千卢比”，而不是“5000 卢比”。“百分之三十”，而不是“30 percent”。“六个月”，而不是“6 个月”。这适用于费用、时长、百分比、年龄、距离、薪资数字、考试成绩等所有口语内容。变量名或技术引用中的数字（例如 Section 4 Question 3）仍使用数字。

电话号码和标识符中的数字序列须逐位读出，并遵循 references/reusable-modules.md 中的规则。

指令编写规则

每个脚本行后都要跟一个指令块。指令必须采用连续的段落文本，在指令段落内不得使用项目符号、编号列表、破折号或任何形式的指引标记。

每条指令都以 Instruction:（或 Instructions:——参考提示词中两种写法都有，请在单个提示词中选择一种并保持一致）开头。指令需涵盖：

• 该行的目标（提出这个问题的原因）。
• 预期的来电者行为以及应如何解读其回答。
• 边缘情况（回答含糊、拒绝、请求澄清、语言不匹配）。
• 以段落文本准确写明路由逻辑：“如果来电者肯定回答，则转到第 4 节、问题 2。如果来电者拒绝，则转到第 7 节、分支 B。如果来电者提出超出范围的问题，则简要告知其稍后由资深咨询师解答，并返回第 4 节、问题 1。”

指令必须使用被动语态，且对来电者不可见——绝不可让指令提及自身（禁止使用“如指令所述”之类的表达）。指令还必须完全使用英文，即使提示词中大量使用印地语也不例外。只有口语化的印地语台词使用天城文。

标准结束语指令

除非场景需要自定义路由，否则大多数结束分支都使用以下原文。这是 ADDA、Porter、OEG、upGrad、CureFoods、LPU 和 Schoolini 的生产提示词中使用的准确措辞：

Instructions: Make sure that you are speaking the closing as it is. This closing statement is designed to professionally conclude the conversation, ensuring a respectful and neutral closure. The AI should deliver the closing message warmly and clearly, avoiding abruptness or over-promising about outcomes. Maintain a courteous tone throughout. No follow-up or probing is necessary here; the goal is to end the interaction smoothly and on a positive note. No additional follow-ups or questions are required at this point.

对于仅使用印地语的结束语或带有同理心的结束语（例如 Porter 针对健康或家庭问题的同理心版本），请保留开头语句 “Make sure that you are speaking the closing as it is.”，然后在标准措辞的其余部分前添加针对具体情形的说明。

分支和编号

• 一个部分中的线性问题按顺序编号：问题 1、问题 2、问题 3。
• 如果分支在某个问题之后展开，分支内的第一个问题接续此前的编号。（如果问题 3 结束一段线性流程，分支 A 从问题 4 开始。）
• 如果多个分支位于同一个决策点（从同一问题分出的并行分支），每个分支的第一个问题使用相同编号，因为它们源自同一个决策点。
• 分支标签：BRANCH A: [SHORT DESCRIPTION]、BRANCH B: [SHORT DESCRIPTION] 等。全大写形式是主流样式（ADDA、Porter、OEG、upGrad、Schoolini、LPU）；也会使用 Branch A: Title Case Description（CureFoods），且同样可接受——请在单个提示词中保持一致。在结束部分，描述应指出结果（成功结束、不感兴趣、改期、拨错号码、亲属接听、超出服务区域）。深层嵌套分支使用带点号的后缀：BRANCH A.1、BRANCH A.2（ADDA 风格，少量使用）。

内容生成规则块

当 Agent 必须根据具体情境处理情况，而不是照着预先编写的台词说时，请用一个方括号括起的规则块开启该小节：

[
Content generation rules:
- Rule one
- Rule two
- Rule three
]

在提示词正文中，只有这里可以使用破折号和项目符号式格式；此外，静态的 Conversational Naturalization 模块内部已使用破折号。每个 Edge Cases、Objection Handling、Upsell Triggers 和 Discount Logic 小节都必须以其中一个规则块开头。

对于边缘情况，规则块之后应逐一说明每种情况，格式为：明确的触发条件、双语回复，以及用于分流的说明段落。

对于异议处理，每条回复最多三句话，采用双语、对话式表达；每个异议最多转折一次。来电者连续拒绝两次时，必须礼貌结束对话，并明确写入规则。

对于追加销售，需用双语定义触发条件和追加销售回复。每次通话最多追加销售一次。

对于折扣逻辑，逐步规则必须写在内容生成规则块内，而不能以项目符号形式写在正文中。

FAQ 部分（YAML）

必须始终提供，并且始终放在最后，格式必须为 YAML。以内容生成规则块开头：

[
Content generation rules:
- This section includes answers to common questions callers may ask during the conversation.
- Always keep the answers to the point, clear, and aligned with the tone defined in Section 1.
- After answering an FAQ, the agent must smoothly return to the exact point in the conversation flow where the interaction was paused.
- If the caller asks something not listed here, the agent must not generate a speculative answer and should politely defer to the sales or support team.
]

然后列出条目：

- id: 1
  question:
    en: "[English question only]"
  keywords:
    - "keyword one"
    - "keyword two"
    - "keyword three"
  answer:
    en: "[English answer]"
    hi: "[Hindi answer in Devanagari]"

问题只能用英文撰写。答案须使用双语。每个 FAQ 最多包含六个关键词。关键词可以混用印地语和英语。

有关上下文 JSON 格式和完整 YAML 示例，请参阅 references/section-templates.md。

特殊格式与口语台词规则

这些规则适用于提示词中的每一句口语台词和说明：

• 禁止在脚本口语文本和说明段落中使用的符号：!、/、@、%、#、&、$。这些符号可以在符合习惯的章节和小节标题中使用，例如 # Conversational Naturalization (Acknowledgements & Flow Softening)、SECTION 1: Demeanour & Identity、SECTION 9: FAQ's、# Handling Customer Queries，因为标题标记在运行时不会被朗读。禁用范围包括 TTS 会朗读的任何行（Opening、Question、Closing、Response、FAQ answer）以及说明段落（这些符号可能会被误解为分流或格式提示）。# 符号可用作 Section 1 小节的标题标记。
• 口语对话台词中不得出现 - 或 —。 破折号仅可用于内容生成规则块和静态的 Conversational Naturalization 模块内部（该模块内部使用破折号，这没有问题，照原样复制即可）。
• 口语台词中不得出现感叹号。 任何时候都不可以。Conversational Naturalization 模块也禁止使用感叹号——这是 TTS 节奏方面的要求，而非风格要求。
• 脚本消息和 FAQ 答案中的所有数字都必须写成单词，并使用相应语言。请参阅上文“脚本文本中的数字”。
• 每轮 Agent 发言只使用一句回应，不得堆叠回应。 根据来电者上一条消息作出符合情境的回应，例如道歉、致谢、追问；不要使用固定前缀。
• Agent 的性别在每一行中都必须保持一致。 如果 Agent 是女性，印地语动词形式和自称在全程中都应使用阴性形式（हूँ、करूँगी、बताऊँगी）。根据对话中的信号判断来电者的性别，并在通话过程中相应调整。
• 不要长篇独白。 每隔两到三句话就询问来电者的意见或感受。
• 不要使用表格。 改用 FAQ 或 YAML、JSON 集合。
• 说明、约束规则和所有元提示词内容都必须使用英语。 只有口语印地语台词使用天城文。不得使用印地语撰写说明或约束规则。

一致性规则

• 不要在不同小节中重复目标或指令。每个小节只负责一项任务。
• 不要让不同小节之间相互矛盾。从第 1 节到结尾，语气、语言和身份都必须保持一致。
• 一旦确定了对话语言，除非来电者明确要求改用另一种语言，否则不得更改。

底层模型

运行时使用的 LLM 是 GPT-4.1 mini。本技能的结构、详略程度和命名规范均根据该模型调整。不要擅自添加 Markdown 装饰、花哨的格式、带表情符号的标题，也不要改写参考模式。严格遵循参考样式，包括章节命名、指令措辞、口语台词的构建方式和分支标注。平实一致胜过巧思。

收到用例描述时的工作流

1. 阅读需求简介。确认 Agent 的性别、主要语言和主要通话目标。只有当这三项中确有不明确之处时，才提出一个有针对性的澄清问题。
2. 加载 references/static-modules.md 和 references/section-templates.md。如果用例涉及收集姓名、电话号码、电子邮箱或数字输入，则浏览 references/reusable-modules.md。如果用例涉及安排具体日期和时间的回拨，或生成评分评估结果，则浏览 references/reusable-flows.md。
3. 起草第 1 节：以方括号括起的 Identity 标题（You are [Agent_name: NAME], [Gender: Female/Male]）开头，然后写 Identity 段落，再写其余小节。原样粘贴两个静态模块。根据用例需要添加第 1 节的其他小节（Context、Environment、Eligibility Criteria、Edge Cases 等）。
4. 编写第 2 节（Conversation Starter）。
5. 将通话流程映射为从第 3 节开始的具名编号章节。
6. 编写 Closing 部分，包含所有相关分支（始终至少包括：Successful Close、Not Interested、Wrong Number；根据用例需要添加 Rescheduling、Relative Answered、Language Mismatch）。
7. 仅当流程需要查找数据时，才添加 Context（JSON、扁平 YAML 或以 Markdown 标题划分的章节——参见 section-templates.md）。如果添加 Context 部分，还必须添加 “Answering User Questions” 部分，并在开头加入 content-generation-rules 块，说明 Agent 如何使用第 X 节（Context）和第 Y 节（FAQ）——该部分必须独立于 Context 部分。
8. 始终以 FAQ（YAML）结尾。

提示词在 FAQ 处结束。不得添加 “Variables Reference” 或末尾的元数据块——生产环境中的提示词都没有这些内容。预加载变量应在首次出现时以行内方式引入，无需另行提供术语表。

不确定章节模板或结束分支的措辞时，请打开 references/section-templates.md，不要自行发挥。

收到对话转录时的工作流

阅读 references/transcript-workflow.md。简要步骤如下：

1. 找出 Agent 成功和失败的地方。
2. 将每个失败对应到提示词中导致问题的章节——通常是缺少防护规则、分支薄弱、路由指令不清晰、未预先处理异议，或语气偏移。
3. 按照上述相同格式，提供修补后的章节，或完整更新后的提示词。
4. 最后附上一段简短说明（几句话），解释做了哪些更改及其原因。

参考文件

• references/static-modules.md — 两个必须原样粘贴的第 1 节模块。
• references/section-templates.md — 每种章节类型的完整模板和示例，包括第 1 节的子章节模式（带方括号的 Identity 标题）、第 2 节的开头、结尾分支、上下文格式变体（JSON、扁平 YAML、带 Markdown 标题）以及 FAQ YAML 变体。
• references/reusable-modules.md — 从生产环境提示词中提炼的姓名、电话号码、电子邮件和数字表达式收集模式。
• references/reusable-flows.md — 日期/时间回拨安排模块（在 CureFoods、upGrad、Porter 中完全相同）、评分式面试评估模式（CureFoods），以及“回答用户问题”网关模式（ADDA、Porter）。
• references/transcript-workflow.md — 如何诊断转录文本，并将问题对应回提示词章节。
• references/multilingual.md — 为 multilingual_config Agent 编写提示词的方法（一个 Agent，包含多个语言条目，每个条目都有自己的 STT/TTS 和完整的第 1 至 N 节提示词）。