mcpField
V
vapi-prompt-builder

vapi-prompt-builder

github.com/vapiaiAgent 工作流67268 次安装今天更新
代码仓库

关于 vapi-prompt-builder

这是一项用于创建、改进和审查 Vapi 语音 Agent 系统提示词的技能。它围绕通话流程、工具能力、安全边界和口语交互指导提示词设计,并区分单个助手与 Squad 的方案。

主要功能

  1. 01创建、改进或审查提示词
  2. 02明确单助手或 Squad 方案
  3. 03依据实际可用能力编写指令
  4. 04处理工具、安全与升级流程
  5. 05检查提示词和部署准备情况

适用场景

  1. 01为业务场景起草语音 Agent 提示词
  2. 02修改现有 Vapi 提示词
  3. 03检查工具使用与升级规则
  4. 04设计多助手交接提示词

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/vapiai/skills --skill vapi-prompt-builder

安装后在 Claude Code 中输入/vapi-prompt-builder确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
capability-grounding.md
identifier-hygiene.md
intake-question-bank.md
review-checklist.md
squad-prompting.md
vapi-readiness.md
vapi-security-trust.md
voice-prompt-patterns.md

详细介绍

Vapi 提示词构建器

核心工作流

使用此技能来编写可用于生产环境的 Vapi 语音 Agent 系统提示词。针对语音交互、低延迟、明确的轮流发言、可靠的工具调用、安全升级处理和可预测的通话结果进行优化。

首先对请求进行分类:

  • 创建:根据业务目标或 Agent 概念,编写新的 Vapi 系统提示词。
  • 改进:在保留预期行为的前提下,重写现有提示词。
  • 审核:审查现有提示词,并返回发现的问题、缺口和建议的修改。

然后确定部署形式:

  • 单个助手:一个 Vapi 助手负责整个通话流程。
  • 助手组:多个专用助手相互交接。

如果请求含糊不清,且工作流可能涉及多个专用角色、路由或交接,请暂停并询问:“此设计应采用单个 Vapi 助手,还是采用包含多个助手并支持交接的 Vapi 助手组?”在问题得到解决之前,不要起草提示词。

当用户提到助手组、Handoff Tools、助手或助手组之间的交接、静默交接、动态路由、路由器/分诊助手、专用助手,或无法由一个可靠提示词处理的过于宽泛的工作流时,请阅读 references/squad-prompting.md。

在编写或保留工作流细节之前,先进行能力核实。确认每项声称的输入、产物、工具操作、副作用和示例,都能通过实际通话渠道、运行时上下文、可见的 Vapi 工具或明确说明的后端行为实现。如果提示词提到文件、上传、附件、文档、截图、浏览器/网页操作、异步任务、集成,或任何通话中的电话用户无法直接执行的操作,请阅读 references/capability-grounding.md。

在创建或大幅重写提示词时,或请求涉及语音风格、示例、工具行为、信息收集或通话结束时,请阅读 references/voice-prompt-patterns.md。

定稿前,进行标识符规范检查。如果提示词使用工具名称、资源 ID、snake_case 标识符、占位符名称或 the_tool_name 等通用值,请阅读 references/identifier-hygiene.md。

如果提示词、工具或配置提到身份验证、来电者身份、账户 ID、权限、机密、安全值、已验证值、静态参数、function.parameters、动态变量、variableExtractionPlan、工具别名、交接参数或敏感工具响应,请进行 Vapi 信任边界检查。在建议这些值应放置的位置之前,请阅读 references/vapi-security-trust.md。

在将产物作为可构建或可配置的就绪方案提供之前,进行 Vapi 就绪性检查。如果输出包含工具、结构化输出、动态变量、助手组、交接、发音指导、测试/评估或配置说明,请阅读 references/vapi-readiness.md。区分已确认的 Vapi 配置、假设和缺失的部署信息。

信息收集

尽可能少地提问,以便完成一份有用的初稿。与其一开始就进行冗长的问卷调查,不如在明确假设的基础上直接完成一份完整的初稿。

始终收集或推断以下信息:

  • 业务或用例
  • 部署形式:单个助手或 Squad
  • Agent 的角色和通话目标
  • 呼叫方类型及其可能的意图
  • 成功标准
  • 必需的工作流
  • 使用 Squad 时的转接/路由边界
  • Agent 可使用的工具或操作
  • 已知的工具架构、结构化输出和转接目标
  • 当转接工具的配置模式取决于模型提供商时,确认模型提供商
  • 哪些值由服务端信任、由呼叫方口述、由工具返回、由大模型推导,或涉及安全
  • 每项必需输入如何提供给 Agent 或后端
  • 人工转接或升级规则
  • Agent 可以收集的信息
  • Agent 不得收集的信息
  • 语气、角色设定和品牌限制

如果请求含糊、风险较高,或缺少多项关键信息,请阅读 references/intake-question-bank.md。

如果用户提供了现有提示词,请先检查,再提出问题。只询问缺失的信息、矛盾之处、工具行为、合规限制或含糊的转接规则。

提示词章节

对于单个助手,除非用户要求缩小范围,否则生成或改进以下章节:

  1. 身份和目标
  2. 个性和表达风格
  3. 回复指南
  4. 防护措施和安全行为
  5. 上下文和动态变量
  6. 工作流和意图路由
  7. 工具使用规则
  8. 错误处理和恢复
  9. 智能信息收集
  10. 升级、转接和通话结束
  11. 少样本示例

对于 Squad,生成或改进以下内容:

  1. Squad 的目标和成员映射
  2. 入口助手行为
  3. 每个助手各自聚焦的系统提示词
  4. 转接决策规则
  5. 上下文转交要求
  6. 各助手的工具边界
  7. 共享防护措施
  8. 每个助手的示例,包括转接示例
  9. 用于路由和上下文保留的外部测试场景

对于新提示词和大幅改写,除非用户明确要求省略示例,或出于延迟/令牌方面的充分考虑需要保持提示词精简,否则应在最终的 Vapi 系统提示词中加入简洁的 Examples 章节。不要用外部测试场景替代提示词内的示例。

保持最终系统提示词精简。除非用户要求,否则不要加入教程性文字、理由说明或面向人类读者的 Markdown。只有在有助于维护时才使用章节标题。

将最终提示词格式化为便于模型快速解析的内容,而不是面向人类读者的文档:

  • 优先使用简洁的项目符号、编号工作流步骤和简短的祈使规则,避免密集的段落。
  • 每条规则只表达一个要点;将包含多个从句的段落拆分为多条规则。
  • 仅使用段落简要说明身份/个性背景,并将其控制在一到三句短句内。
  • 不要混淆提示词格式和口头输出:系统提示词中可以使用 Markdown,但要指示 Agent 不要对呼叫方说出 Markdown、项目符号或编号列表。
  • 定稿前,将任何读起来像解释性文字的章节压缩为可执行指令。

示例设计

将提示词内示例设计为语音 Agent 的行为训练数据:

  • 如果提示词涵盖完整工作流,至少包含三个示例:顺利完成、边缘情况和错误恢复。
  • 如果 Agent 有多个高价值意图,则覆盖每个主要工作流。
  • 展示真实的来电者对话、简洁的助手回复、工具调用和工具结果。
  • 相关时,展示无结果、多条结果、输入无效、语音不清和工具故障时的分支行为。
  • 确保每个示例都基于实际的渠道、运行时、工具或后端能力。
  • 仅在明确的 Tool Call: 行或面向机器的配置说明中使用确切的工具标识符。
  • 控制示例长度,确保其带来的价值足以抵消延迟成本。
  • 使用形式示例,避免重复受禁止的短语、敏感值或不受支持的内容。

将外部测试场景与最终提示词分开。测试场景供人工操作员验证提示词;示例则是嵌入提示词中、供模型模仿的指令。

语音优化

返回最终提示词前,先进行一轮语音 Agent 优化:

  • 面向来电者的每轮回复都要简短,通常为一两句话。
  • 一次只问一个问题。
  • 避免在 Agent 回复中使用编号列表、项目符号、Markdown 和视觉排版。
  • 将日期、电话号码、货币、时间和 URL 转换为适合口语表达的形式。
  • 在普通文本中,将工具 ID、资源标识、snake_case 标识符和占位符名称替换为自然的能力描述。
  • 明确规定如何处理打断、沉默、输入不清和工具故障。
  • 区分轻松闲聊和明确的跑题请求。
  • 根据使用场景调整人性化程度:所有生产环境中的 Agent 都需要自然的语速、补救能力和亲和力;只有符合角色设定和风险状况时,才加入不流利表达、闲聊或个人化交流。
  • 移除渠道不可能实现的行为,除非工具或后端契约明确支持这些行为。
  • 在可靠性或安全性至关重要时,优先采用确定性的 Vapi 配置,而不是提示词指令。

工具和配置说明

涉及工具时,同时检查提示词指令和工具配置。标明需要在系统提示词之外配置的内容:

  • 工具描述应说明何时调用、何时不调用,以及所需的参数格式。
  • 提示词正文应按能力描述工具。确切工具名称只能出现在工具调用示例、架构、配置说明中,或出现在 Vapi 要求系统提示词指定搜索工具的 Query Tool 指令中。
  • 不要臆造可部署的工具架构、结构化输出架构、枚举值、服务器 URL 或转接目标。应询问相关信息,或标记为需要配置。
  • 转接和结束通话工具需要明确的描述。
  • 对于响应缓慢的工具,应使用请求开始消息填补等待空白。
  • 如果存在发音问题,应使用发音词典。
  • 对于必须保密、经过验证或无法由大模型伪造的值,应采用 Vapi 的服务端/静态参数模式,而不是依赖提示词文本或由大模型填写的架构。
  • 工具响应应简短、结构清晰,并仅包含模型需要的字段。

输出模式

对于新提示词,请返回:

  • 简要假设(如有)
  • 最终 Vapi 系统提示词;使用 Squad 时则返回 Squad 提示词集
  • 建议的 Vapi 配置说明(如相关)
  • 若缺少部署关键细节,则列出所需配置或阻塞性问题
  • 外部测试场景,与提示词分开列出

对于改进提示词,请返回:

  • 最终修订后的提示词;使用 Squad 时则返回修订后的 Squad 提示词集
  • 所做的重要更改
  • 尚待解答的问题或风险
  • 若缺少部署关键细节,则列出所需配置或阻塞性问题
  • 外部测试场景,与提示词分开列出

对于审计,请返回:

  • 按严重程度排序的发现
  • 缺失或薄弱的提示词部分
  • Vapi 配置方面的注意事项
  • 具体的改写建议

在完成审计或大幅改写之前,请阅读 references/review-checklist.md。

评论

支持 Markdown