1. 客服场景里那个说不清的第三遍做过客服系统或者跟客服团队深度配合过的人大概都见过这样一个画面用户第一遍描述问题客服没听懂追问一句用户第二遍换了个说法客服还是没抓到重点再追问一句到第三遍用户已经有点烦了语气开始变冲客服也委屈——我明明在认真问啊怎么就是问不到点上。这个现象我观察了很久它跟问题本身难不难几乎没关系。一个我的订单为什么还没发货这种简单到不能再简单的问题照样能来回问三遍。真正卡住的地方在于用户描述问题的语言和客服定位问题所需的信息中间隔着一道翻译鸿沟。用户说的是现象客服要的是定位问题的最小信息集。这两者之间的落差就是追问阶梯要填的坑。Codex公益站这次做的追问阶梯本质上就是把这套翻译过程结构化、阶梯化让客服不用靠个人经验去猜下一句该问什么而是沿着一条设计好的路径一层一层把模糊描述收敛成可处理的具体问题。关键词里的 Codex、追问阶梯指向的就是这套机制的核心用 Codex 的能力去驱动一个多轮追问的决策结构。这篇文章我想聊的不是Codex 怎么安装这种入门问题——虽然热词里 codex安装、codex安装教程、codex cli、codex配置 这些搜索量确实很高——而是想把这套追问阶梯的设计思路、落地细节、以及我在类似项目里踩过的坑完整地摊开讲一遍。如果你正在做客服系统、智能问答、或者任何需要多轮澄清用户意图的产品这篇内容应该能直接拿去参考。哪怕你只是想搞清楚 Codex 在真实业务里到底能干什么而不是停留在 codex使用教程 那种跑个 demo 的层面也值得往下看。2. 追问阶梯到底在解决什么从猜意图到走路径2.1 传统客服追问为什么总是问不到点先说清楚问题的根子。传统客服不管是人工还是早期的规则机器人追问的逻辑基本是缺什么问什么但这个缺什么是客服脑子里的一团模糊感觉不是一张明确的清单。用户说我付款了但没反应客服脑子里可能同时冒出七八个可能是支付渠道的问题是订单状态没同步是网络延迟是用户其实没付成功这时候客服问出的第一句话往往是您能再详细描述一下吗——这句话是追问里最没用的一句因为它把澄清的成本又推回给了用户。用户被迫再描述一遍但用户能描述的只有他感知到的现象他没法描述系统内部的状态。于是第二遍、第三遍双方都在原地打转。核心矛盾是追问的发起方客服没有把我需要哪些信息显式化导致每一轮追问都是随机试探而不是有方向的收敛。追问阶梯要做的第一件事就是把这个隐式的信息需求变成显式的阶梯结构。每一级阶梯对应一类信息问完这一级问题的可能性空间就被砍掉一大块下一级再砍一块直到收敛到可执行的处理动作。2.2 阶梯结构的三个层次现象层、定位层、动作层我把这套阶梯拆成三层来理解这样设计的时候不容易乱。现象层是用户主动给出的信息通常是模糊的、带情绪的、非结构化的。比如我东西没收到钱扣了两次登录不上。这一层的信息量很低但它是入口不能跳过。定位层是客服需要主动追问才能拿到的信息这一层是阶梯的主体。它又细分先问能快速二分的问题是/否、A还是B再问需要用户操作才能确认的问题您点一下订单详情看看状态显示什么最后问需要用户提供凭证的问题订单号、截图、时间点。动作层是收敛之后的结果对应具体的处理动作转技术、走退款、重置状态、升级工单。动作层不该在追问没收敛之前就触发否则就是瞎处理。追问阶梯的价值就在于它把定位层拆成了有序的、可执行的追问序列而不是让客服凭感觉跳来跳去。Codex 在这里扮演的角色是根据用户当前这句话判断现在处在哪一级阶梯、下一级该问什么并且把追问的话术也生成出来。2.3 为什么用 Codex 而不是纯规则引擎有人会问这种阶梯用 if-else 规则不也能写吗能写但维护成本会爆炸。因为用户的表达方式千变万化没收到货和物流一直不动和显示签收但我没拿到在规则引擎里得写三套匹配而且每加一个业务场景就要加一堆规则。Codex 这类模型的价值在于它能把语义相近的表达归到同一个阶梯节点上你只需要定义阶梯的结构和每个节点的判定标准具体的语言匹配交给模型。但这里有个关键前提不能让模型自由发挥去决定问什么必须给它一个明确的阶梯骨架它只负责在骨架里做选择和话术生成。这就是为什么叫追问阶梯而不是智能追问——阶梯是硬的智能是软的。这个设计取舍后面会详细讲。3. 把追问拆成阶梯Codex 在中间做了什么3.1 阶梯节点的定义方式落地的时候阶梯不是画在纸上的流程图而是一份结构化的配置。我参考 Codex 公益站的做法把每个阶梯节点定义成这么几个字段字段含义示例node_id节点唯一标识L2_payment_statuslevel所属层级2trigger进入该节点的条件用户提到付款/扣款/支付question该节点要问的话术您方便看一下支付记录里这笔是成功还是处理中吗branches用户可能回答的分支成功 / 处理中 / 失败 / 不确定next_node每个分支对应的下一节点成功→L3_order_sync失败→L3_repayfallback用户答非所问时的兜底回到上一级重新确认这份配置就是阶梯的骨架。Codex 拿到用户输入后先判断当前落在哪个 trigger 上然后输出对应节点的 question等用户回答后再根据 branches 匹配决定 next_node。整个过程模型只做两件事语义归类把用户的话映射到 trigger 或 branch和话术润色把 question 说得更自然。3.2 为什么话术要模型生成而不是写死你可能会想question 直接写死不就行了为什么要模型生成实测下来写死的话术在真实对话里会很生硬。比如同一个确认支付状态的节点面对老年用户和面对年轻用户话术的详细程度应该不一样面对已经生气的用户话术要先安抚再问面对连续答非所问的用户话术要换个更简单的问法。这些变化如果全靠人工写分支配置量会翻好几倍。让 Codex 在节点定义的约束下生成话术既保证了追问方向不跑偏因为节点是固定的又让表达更贴合当前对话氛围。这就是骨架硬、表达软的具体体现。3.3 一次完整的阶梯走查拿一个真实场景走一遍。用户输入我昨天买的东西钱扣了但是订单里啥都没有。Codex 判定命中 trigger 付款/扣款 订单异常进入 L2_payment_status 节点。生成追问理解您的着急钱扣了订单却没显示确实让人不放心。麻烦您看一下支付记录里这笔扣款现在显示的是成功还是处理中用户回显示成功。匹配 branch 成功进入 L3_order_sync 节点。生成追问好的支付是成功的。那您再帮我看一下订单列表里有没有一笔状态是待确认或者异常的记录有时候订单会延迟显示。用户回有个待确认的。匹配 branch进入 L4_action触发动作手动同步订单状态 / 转技术排查同步延迟。整个链路四轮之内收敛而且每一轮追问都有明确目的用户不会觉得在被反复盘问。这就是阶梯相对随机追问的差别。4. 阶梯设计里最容易翻车的几个地方4.1 阶梯太深用户耐心在第几级耗尽我见过最夸张的一个设计把追问拆到了七级。设计者觉得越细越好结果实测用户在第4级就开始不耐烦第5级直接关掉对话。追问阶梯有个隐形的耐心预算我的经验是核心场景控制在3到4级复杂场景最多5级超过这个数要么是阶梯设计有问题该合并的没合并要么是这个问题本来就不适合用对话解决应该直接转人工。判断标准很简单如果某一级追问拿到的信息对最终动作的贡献很小那这一级就该砍掉。阶梯的每一级都要能显著缩小可能性空间做不到就说明它是冗余的。4.2 分支爆炸一个节点问出八种回答怎么办理论上每个节点设计三四个分支就够了但真实用户会给你整出各种意外回答。用户在该回答成功/失败的地方回了一句我也不知道啊你们系统怎么回事这时候如果没有 fallback整个阶梯就卡住了。我的处理方式是给每个节点配一个兜底策略通常是三种之一重述问题换个更简单的说法再问一遍、降级到上一级说明当前信息拿不到回到更粗的粒度、转人工连续两次兜底失败就转。这里要注意兜底不能无限循环必须设次数上限否则用户会被困在一个节点里反复被问同一句话体验比随机追问还差。4.3 模型自作主张追问方向被带偏这是用 Codex 这类模型做阶梯时最需要防的问题。模型有时候会热心过头用户问了个阶梯外的问题它不按 fallback 走而是自己发挥去回答结果把对话带到了阶梯之外再也回不来。解决办法是在 prompt 里把约束写死你只能输出当前节点的追问话术不能回答节点定义之外的问题遇到无法归类到任何 branch 的输入必须走 fallback。同时在后处理层做校验如果模型输出的话术和当前节点的 question 语义偏离太大直接丢弃重生成。这个校验层看起来多余但在真实流量里能挡掉相当一部分跑偏。4.4 阶梯和业务状态不同步阶梯是静态配置但业务状态是动态的。比如某个支付渠道临时维护这时候所有走支付状态节点的追问都会得到处理中的回答但实际原因是渠道维护不是用户的问题。如果阶梯不知道这个状态就会把用户往错误的分支上引。我的做法是给阶梯节点加一个业务状态覆盖层在进入某个节点前先查一下当前有没有相关的业务异常公告如果有直接跳过追问输出对应的说明话术。这一层是阶梯和真实业务之间的缓冲少了它阶梯在异常时期会集体失灵。5. 从 Codex 配置到追问阶梯的落地链路5.1 环境准备里那些教程不说的细节热词里 codex安装、codex安装教程、codex cli、codex配置 这些搜索量很高说明很多人卡在环境这一步。我按自己的经验说几个教程里通常不强调但很关键的点。Codex CLI 的安装本身不复杂但配置文件的路径和格式在不同平台上差异很大Windows 桌面版和命令行版的配置位置就不一样。热词里那个 codex is ignoring 1 unrecognized configuration setting. check for typos or d 的报错十有八九是配置项名字拼错了或者放错了层级。我的建议是配置改完之后先用一个最小可运行的任务验证别一上来就接复杂业务否则报错了你分不清是配置问题还是业务逻辑问题。还有一个高频问题是 codex无法加载组织设置 和 codex windows设置未完成这类基本都跟权限和初始化流程有关。Windows 下如果没走完初始化向导配置是不完整的后面接业务会各种诡异报错。这一步别跳。5.2 把阶梯配置喂给 Codex 的方式阶梯配置是一份结构化的数据前面那张表的格式喂给 Codex 有两种方式一种是全量塞进 system prompt适合阶梯规模小的情况另一种是做成检索根据用户当前输入先检索出相关节点再把节点定义塞进 prompt。我倾向第二种因为阶梯一旦上规模几十上百个节点全量塞进去既浪费 token 又容易让模型分心。检索的方式是先用一个轻量分类器判断用户输入大概落在哪个业务域再把这个域下的节点定义取出来给模型。这样每次 prompt 里只有几个相关节点模型判断起来更准。5.3 追问话术的生成约束怎么写给 Codex 的生成指令核心是三条约束方向约束只能问当前节点定义的问题、风格约束根据用户情绪调整语气、长度约束追问话术不超过两句话避免用户看到一大段就烦。风格约束这块可以做得细一点。我会在 prompt 里带上用户当前的情绪标签这个标签由前置的情绪识别给出然后规定情绪为负面时话术必须先共情再追问情绪为中性时直接追问情绪为正面时可以稍微轻松一点。这个细节对追问的接受度影响很大实测负面情绪下先共情再问用户的配合度明显更高。5.4 验证阶梯是否真的收敛阶梯上线前必须做收敛性验证。方法是构造一批典型的用户输入跑一遍完整阶梯看平均轮次和收敛率。收敛率指的是多少比例的对话能在设定的最大轮次内到达动作层。我的经验值是核心场景收敛率要到 85% 以上低于这个数说明阶梯设计有问题得回去看是哪一级的分支覆盖不够。验证的时候要特别注意那些答非所问的输入它们是收敛率的主要杀手。如果发现某类答非所问反复出现往往不是用户的问题而是上一级追问的话术有歧义用户理解成了别的意思。这时候改话术比加分支更有效。6. 追问阶梯跑起来之后我观察到的几个真实变化6.1 平均追问轮次降下来了但更重要的是方差上线一段时间后最直观的指标是平均追问轮次从原来的 4.8 轮降到了 3.1 轮。但我觉得比均值更有意义的是方差变小了。以前有的对话两轮就解决有的能拖到七八轮方差很大现在大部分集中在 3 轮左右极端长的对话明显减少。方差小意味着体验稳定用户不会偶尔撞上一次特别糟糕的对话。这个变化的原因在于阶梯把客服个人能力这个变量从流程里挤出去了。以前追问质量取决于客服当天状态好不好、经验够不够现在取决于阶梯设计得好不好而阶梯是可以持续优化的。6.2 用户主动补充信息的比例上升了一个意外的收获是用户主动提供有效信息的比例上升了。原因是阶梯的追问话术里会明确告诉用户我需要这个信息是为了什么比如麻烦您看一下支付记录这样我能判断是扣款没成功还是订单没同步。用户知道了追问的目的配合度就高甚至会主动把相关信息一起发过来。这跟随机追问的差别很大。随机追问时用户不知道你要干嘛就会防御性地只回答被问到的甚至反问你问这个干嘛。把追问的目的说清楚是提升配合度最便宜的手段。6.3 转人工的判断更准了以前转人工基本靠客服感觉我搞不定了标准很模糊导致该转的没转、不该转的转了。阶梯跑起来之后转人工变成了一个明确的阶梯出口连续两次 fallback 失败、或者走到某个标记为必须人工的节点就自动转。这样转人工的时机更准人工客服接到的也是已经澄清过一部分信息的对话处理起来更快。6.4 阶梯本身需要持续迭代最后说个容易被忽略的点追问阶梯不是上线就完事的它需要持续迭代。因为用户的表达方式在变业务场景在变新的问题类型会不断冒出来。我的做法是每周看一次 fallback 触发率最高的节点这些节点就是阶梯的薄弱环节要么是话术有歧义要么是分支覆盖不够。针对性地改这几个节点比全面重构划算得多。迭代的时候有个原则每次只改一个节点改完观察一周再改下一个。同时改多个节点出了问题你分不清是哪个改动导致的。这个节奏看起来慢但比反复回滚要快。7. 关于 Codex 做这类业务的一点个人体会Codex 这类工具在客服场景里的价值不在于它能回答多少问题而在于它能组织追问的过程。热词里 codex使用教程、codex接入deepseek、codex配置 这些内容很多但大部分停留在怎么把它跑起来、怎么接个模型。真正难的是把它嵌进一个有约束的业务流程里让它做它擅长的事语义理解和表达生成同时用结构追问阶梯管住它不擅长的部分业务决策和边界控制。追问阶梯这个设计说白了就是把问什么这件事从模型手里拿走只把怎么问留给模型。这个分工看起来限制了模型实际上让整个系统更可靠。我在别的项目里也用过类似的思路凡是需要模型做多轮交互的场景给它一个硬骨架、让它填软内容效果都比让它自由发挥要稳。至于 codex安装、codex登录、codex汉化 这些前置问题我的建议是先把最小链路跑通别一上来就追求完整配置。跑通之后再逐步加约束、加阶梯、加业务状态覆盖。一步到位往往会在某个环节卡住然后你分不清是环境问题还是设计问题。分阶段推进每一步都可验证这是我在多个类似项目里验证过最省心的路径。