调问新增 AI 电话回访：上线前先想清楚重试和配额
问卷系统加上 AI 电话回访，第一眼看像是多了一个收集答案的入口。我更关心的是：电话挂断以后，这份答卷算完成了吗？如果回调晚到，系统会不会又拨一次？调问这次更新让我想到的，是这些不太适合写进功能海报的问题。
先把已知的事情说清楚
基于公开摘要可见，调问在本轮更新中新增了 AI 电话问卷，支持电话回访；也增加了样本配额与答卷甄别规则。摘要还宣称前后端代码全部开源。但它没有说明电话服务如何接入、回访数据怎样保存，也没有给出运行成本。下面讨论的是接入这类能力时的工程判断，不能当成调问已经实现或缺失某项机制的结论。
电话任务不能照搬网页提交
网页问卷通常由用户主动打开。电话回访则需要系统发起动作，遇到未接听、通话中断，业务很容易提出“再试一次”。如果只是给队列任务加上自动重试，遇到超时却已成功发起呼叫的情况，就可能重复联系同一个人。多一次请求在这里可能变成多一次打扰。
真要接入生产，我会先拆开呼叫任务和答卷记录，给每次业务回访一个稳定标识。请求超时先确认状态，再决定是否重拨；回调重复到达，也不能重复生成有效答卷。日志要能串起同一轮回访，否则客服说用户被连续拨打时，开发只能在几套日志里猜。
监控也得看业务结果。接口返回成功，只能说明某一步请求被接受，不代表用户接听，更不代表问卷完成。我会分别记录发起、接通和有效提交的状态，并保留暂停后续拨号的开关。花费失控或规则配错时，先停下来比边拨边查踏实。
配额遇上并发，账就不那么好算了
配额和甄别规则看起来属于问卷配置，实际会碰到数据库里很具体的竞争。假设某类样本只剩少量名额，几个回访同时进行，应该在接通时占位，还是提交答卷时扣减？前者可能被未完成的通话占住，后者又可能让已经接受回访的人最终无法计入样本。
我倾向于先由业务讲清楚超额如何处理，再决定是否需要临时占位和超时释放。不要靠一个先查后写的计数器碰运气。规则修改也要留版本，让维护人员知道某份答卷当时按什么条件进入有效样本，否则今天改了配置，明天报表就可能解释不清。
开源能查代码，接入仍要算维护账
代码开放让团队有机会检查数据流向，但不能仅凭这句话判断电话服务是否依赖外部供应商。如果计划保存录音或转写文本，就得先确认用户告知、访问权限和保留期限；是否真的需要存，也应该单独讨论。能采集不等于应该长期留着。
对小团队，我会建议先拿一个范围明确、用户已同意回访的场景试跑，把人工核对结果和实际费用记下来。先验证异常任务能否停住、答卷能否对账，再扩大范围。电话拨出去以后，撤回一个功能开关也收不回用户已经接到的来电。
本文由本站基于公开热点摘要整理和原创分析生成。来源：OSCHINA：调问更新 9.25 ~ 10.19。本文未对该项目进行部署实测。
