提示词模式通过业务规则驱动智能体对话，适用于短路径、分支少的通话场景。本文说明适用场景、配置步骤、写法规则、验证方法，以及迁移到对话流模式的判断标准。
适用场景
提示词模式通过一组结构化的业务规则驱动智能体对话。智能体根据客户表达自然回应，同时在明确的目标、边界和结束规则内行动。适合以下场景：
生产通知、简单回访、问卷调研、面试提醒等短路径场景
业务规则较少、分支有限，且需要快速迭代验证
当前目标是验证话术效果和客户反馈，而非编排复杂流程
不适合：多轮资格判断、多个固定出口、依赖工具动作、复杂转人工或需要精确定位路径问题的场景。这类正式运营需求优先使用对话流模式。
与对话流模式的对比
提示词模式适合短链路、分支少的场景；对话流模式适合有多轮判断、有相对固定但复杂业务流程的场景。下表对比两种模式在配置方式、路径控制等方面的差异。
对比维度 | 提示词模式 | 对话流模式 |
规则放在哪里 | 一份主提示词 | 全局规则、节点提示词、跳转条件 |
路径控制 | 主要依赖模型理解整段规则 | 关键状态和去向显式可见 |
适合场景 | 短链路、流程分支少、快速验证 | 有多轮判断、有相对固定但复杂的业务对话流程 |
修改影响 | 改一处可能影响整通电话 | 可定位到某节点或某条连线修改 |
主要风险 | 提示词变长后易跑偏、难定位 | 节点过多、条件重叠或遗漏兜底会难维护 |
推荐场景 | 简单通知、轻量回访、PoC | 作为主推方案，用于稳定运营的业务流程 |
快速开始
完成以下5步，可配置并测试第一个提示词模式智能体。
创建智能体时选择标有提示词的模板，并完成创建。
在提示词编辑区域填写以下内容：
身份与对象：你是谁、联系谁、来电目的。
核心目标：本通电话需要达成的可观察结果。
主流程：开场 → 确认是否方便 → 业务沟通 → 结果确认 → 结束。
关键判断：客户忙碌、拒绝、已办理、听不清时分别如何处理。
边界与收口：不能承诺什么、何时转人工、何时礼貌结束。
保存草稿，进入测试页面执行文本测试。
文本测试通过后，执行专家拨测确认语音体验。
拨测通过后发布上线。
快速开始仅覆盖最简配置。完整配置项、写法规则和验证方法见后续章节。
配置步骤
步骤一：进入提示词配置
创建智能体时选择标有提示词的模板，或进入已有智能体的构建 > 智能体 页签，在提示词区域开始配置。
步骤二：填写提示词内容
按推荐提示词骨架组织内容，以下为核心字段的填写说明：
字段 | 填写说明 | 示例 |
身份与对象 | 说明智能体的身份、联系对象和来电目的。用一句话讲清"你是谁、找谁、为什么"。 | 你是XX公司的服务通知员，联系已报名活动的用户，确认是否参加本周六的线下活动。 |
核心目标 | 描述本通电话需要达成的可观察结果。目标需具体、可验证。 | 确认用户是否参加，如参加则记录出席人数；如不参加则记录原因。 |
主流程 | 按通话顺序列出标准流程。一般为：开场 → 确认是否方便 → 业务沟通 → 结果确认 → 结束。 | 开场问候 → 确认对方是否方便接听 → 说明活动内容并询问是否参加 → 记录结果 → 感谢并结束。 |
关键判断 | 列出客户可能的典型回应及对应处理方式。每条规则用条件句式描述，覆盖忙碌、拒绝、已办理、听不清等场景。 | 若客户表示现在不方便，则说明改日再联系并结束通话。若客户表示已参加，则感谢并结束通话。 |
边界与收口 | 明确不能承诺的内容、转人工的触发条件，以及何时停止追问并礼貌结束。 | 不承诺具体活动细节以外的内容。若客户投诉或情绪激动，则转人工处理。同一问题追问不超过两次。 |
如需使用 AI 辅助生成，可填写智能体角色、对方角色、核心目标、任务描述后由系统自动生成提示词草稿，详情请参见通过AI辅助构建提示词。
步骤三：配置辅助模块
将以下能力分别配置在对应的模块中，不要仅依赖提示词文字描述：
呼叫配置：设置智能体的呼叫音色、语速和音量。
事件处理配置：配置静音检测和用户打断策略。
知识库：挂载业务资料，使智能体可在资料范围内回答问题。
变量：定义通话中需要提取和使用的动态信息（如客户姓名、活动时间）。
通话小记：配置通话结束后自动生成的摘要内容。
通话后处理：配置通话结束后的自动操作（如发送短信、重新呼叫）。
工具能力以当前账号实际开通范围为准。未开通的模块在配置界面中不可见或不可用。
步骤四：测试与发布
保存草稿，进入在线调试页面执行文本测试，验证提示词逻辑是否正确。
文本测试通过后，进行通话测试确认语音体验（首句、语速、打断、静音和挂断体验）。
拨测通过后，发布智能体上线。
上线后观察通话指标，如转化率、异常退出率等，根据实际效果持续优化提示词。
推荐提示词骨架
按以下骨架结构组织提示词，各部分对应的写法规则见括号标注：
# 身份与对象
你是谁；正在联系谁；本通电话的来电目的。
（规则：用一句话讲清"你是谁、找谁、为什么"）
# 核心目标
本通电话最重要、可观察的达成结果。
（规则：目标需具体、可验证）
# 主流程
开场 → 确认是否方便 → 业务沟通 → 结果确认 → 结束。
（规则：按通话顺序列出，一条流程只描述一个标准路径）
# 关键判断
客户忙碌、拒绝、已办理、听不清、投诉时分别如何处理。
（规则：用条件句式，一条规则只解决一件事）
# 边界与收口
不能承诺什么；何时转人工；何时停止追问并礼貌结束。
（规则：每个异常都有出口，明确不可承诺的内容）写法规则
用条件句式写规则：写"若客户明确表示现在不方便，则礼貌回复并结束对话"，不要写"灵活处理"或"视情况而定"。
一条规则只解决一件事：身份确认、资格判断和转人工不要写入同一句。拆分后每条规则独立可执行。
每个异常都有出口：变量缺失、无知识命中、客户沉默、拒绝、投诉等边界场景都需要有明确的处理方式。
使用短句，提升拟人感：一次只提一个问题，避免长段落。数字、金额、日期、英文缩写可以通过拨测确认读法。
验证方法
文本测试
在测试页面中至少覆盖以下场景：
测试场景 | 预期表现 |
正常接听，按主流程走通 | 身份、来意和目标清楚，能完整推进主流程并正确收口 |
客户忙碌或拒绝 | 不强行追问，按规则收口或记录后续动作 |
超出资料范围的问题 | 不猜测答案，按知识库、转人工或兜底规则处理 |
通话测试验收清单
文本测试通过后，通过通话测试确认以下语音体验指标：
首句体验：开场白是否自然、清晰，是否在 3 秒内讲明来电目的。
语速：语速是否适中，关键信息（时间、地点、金额）是否播报清楚。
打断体验：客户中途打断时，智能体是否能正确响应并切换话题。
静音处理：客户长时间不说话时，智能体是否按配置的静音策略进行提醒。
挂断体验：结束时是否礼貌收口，无突兀挂断或追问。
文本正确不代表通话体验正确。必须通过通话测试确认首句、语速、打断、静音和挂断体验后，方可发布上线。
何时迁移到对话流模式
当提示词出现以下情况时，建议迁移到对话流模式：
出现大量独立分支，提示词难以维护。
反复补充例外规则，主流程被不断打补丁。
需要调用多个工具动作（如查询系统、创建工单、发送通知）。
测试中难以定位"为什么走错路径"，排查成本高。
将业务状态拆为节点和跳转条件后迁移到对话流模式，更易维护和排查。