配置项一多，改乱的根源往往不是某个参数填错，而是顺序反了：先把流程连起来，再回头补边界，每加一个分支就得重跑一遍。更稳妥的顺序是先把任务边界固定成一句话，再只跑通一条主流程，最后才接渠道；每一步都留一个能回放的验证点，改动才有对照，出问题也能退回到上一个跑通的配置。

面对零代码平台里成片的配置项，建议按「边界→主流程→渠道」推进：先写死一句范围句（对谁、什么情况、输出什么、何时转人工），再把任务拆成触发、取信息、组织回复三段逐段配置，每配完一段就用固定输入回放一次并记录改动前后输出，最后接渠道，用同一批输入在两个渠道对照。发现不一致就回退到上一版配置，而不是在原地继续叠参数。字段名各平台不同，示例以控制台实际为准。

用一句话写清智能体负责什么、不负责什么

范围句的作用是让后面的配置有取舍依据：凡是这句话覆盖不到的需求，一律不往配置里加。可以先按下面的句式填空，一句话写完，不要拆成多条并列描述。

当【哪类用户】在【什么场景/入口】下提出【哪类问题】时，
输出【回复形态：状态说明 / 办理指引 / 固定话术】，
遇到【转人工条件：超范围、信息缺失、用户明确要求、连续两轮未解决】转人工，
其余情况一律不承诺、不办理。

判断标准很直接：拿一句范围外的问题去问自己，这句话能不能支撑你拒绝它。如果拒绝不了，说明边界还太松，需要补上「不负责什么」，比如不处理金额争议、不代替用户提交申请。这一步定完就冻结，后续新增需求先回到这句话上确认，再决定是否动配置。

把任务拆成触发、取信息、组织回复三段

拆段的意义是让每个配置项有归属，而不是散落在触发条件、知识库、提示词、回复模板里各写一半。三段各自的输入输出和判断标准建议这样定：

• 触发段：输入是用户消息与当前会话状态，输出是「命中主路径 / 未命中」。判断标准是同一句主路径问题连续触发三次都稳定命中，且范围外的问题不误触发。
• 取信息段：输入是从消息里抽出的参数（如订单号、问题类型），输出是结构化结果或空结果。判断标准是参数齐全时能取到值，参数缺失或结果为空时走转人工，而不是编一个答案。
• 组织回复段：输入是取到的结构化结果，输出是最终话术。判断标准是回复里出现的每个字段都来自取信息段，没有凭空补的内容。

三段之间只通过明确的输入输出衔接，中间不要插入「顺便判断一下情绪」「顺手推荐个产品」这类额外逻辑，否则回放时无法判断是哪一段导致输出变化。

按三段逐步写入配置，先只做主路径

主路径指最常见、参数最完整的那条路，先只配它，分支和兜底策略等主路径跑通再加。下面是一份配置骨架，字段名以控制台为准，替换成实际项即可：

agent:
  name: order_status_bot
  scope: 登录用户查订单进度时给状态与预计时间；涉及退款金额或投诉转人工
trigger:
  entry: web_chat
  intent: order_status
  required_slots: [order_id]
fetch:
  source: order_query        # 主路径只查一处数据源
  query_template: order_id={order_id}
  timeout_ms: 3000
  on_empty: handoff
compose:
  template: order_status_reply
  variables: [status, eta]
  max_length: 200
handoff:
  condition: [empty_result, out_of_scope, user_request]
  target: human_queue

按顺序执行的步骤、验证方法和回滚点可以固定成下面这张表，每完成一行再做下一行：

回滚点上要留可操作的抓手：改配置前先导出或复制一份当前版本，或者记下改动前的字段值。零代码平台通常看不到版本树，这一步只能靠自己留底。

每配完一段就回放一次，记录改动前后差异

回放不是随手点两下看看像不像，而是固定输入、固定顺序，把改动前后的输出并排记下来。建议准备三到五条样本：一条标准主路径、一条缺参数、一条范围外、一条口语化表达。每改一段只跑这一批，不同时改两处，否则差异归因不了。

「是否预期」这一列很关键：出现非预期的输出变化，说明这次改动影响到了别的路径，应当先回滚再定位，而不是继续往前配。日志里通常能看到命中意图、取信息结果和最终话术三段记录，回放时对着日志看比只看聊天窗口准。

最后再接渠道，用同一批输入复测

渠道接入常会带来格式差异：换行、字数上限、按钮与纯文本的差别、消息合并顺序等，这些不改变业务逻辑，但会改变用户看到的输出。接完渠道后，用回放时那一批输入原样再跑一遍，两个渠道的输出并排对照。

只要业务结论（命中、取值、转人工）在两个渠道一致，格式差异在模板里统一处理即可；如果业务结论不一致，说明新渠道的接入参数覆盖了原有配置，应当回退渠道接入，回到能跑通的主路径重新接。渠道上线后仍保留上一版配置备份，观察期内出问题可以切回。