关于我们：为什么坚持本地部署这条路
我们不是从外呼行业起家的，起点是语音与对话技术本身。选择电话场景是因为它最考验全链路协同 —— 任何一环出问题，客户立刻挂断。
我们是谁
一家做语音对话系统的技术团队
深度求知（openx）主要做企业级语音交互系统。 AI 电话机器人是我们把语音识别、语音合成、大模型对话、业务编排 这几块拼成的一套完整产品。
我们不是从「外呼」这个行业起家的。起点是语音与对话技术本身 —— 怎么让机器在嘈杂环境里听清人说话、怎么让合成的声音不带机械感、 怎么在毫秒级的时间里完成检索与生成。这些技术问题解决之后， 才去找它们最能落地的业务场景。
选择电话外呼与接听作为落地场景，是因为它是最考验全链路协同的场景： 识别慢半秒、合成机械、回答答非所问、转人工接不上， 任何一环出问题客户都会立刻挂断。这个场景没有中间状态， 要么真的能用，要么完全不能用。
为什么不做「什么都做」的通用 AI 平台
通用平台的问题是：每一块都做到 60 分，但拼在一起还是 60 分。 而电话对话要求每一块都在 85 分以上，否则整通电话就崩了。
所以我们把精力集中在一条链路上，从音频采集一直做到业务系统回写。 这条链路上的每个环节我们都能自己排查，不需要"这个问题请找模型供应商"。
我们服务的是企业客户的真实业务流程，不是演示环境。
技术路线
为什么坚持本地部署这条路
这不是「技术洁癖」，是被客户的真实约束逼出来的选择。
数据不出机房是硬需求
金融、医疗、部分国企的合规要求里，「数据不得出机房」没有折中方案。 调用公网 API 的方案在这些客户面前直接出局。
延迟要可控
公网 API 的网络抖动无法预测。对话场景里 500 毫秒的抖动就会让客户觉得「对面没反应」， 而这类问题在本地部署里根本不存在。
长期成本可控
按调用量付费的模式，通话量越大成本越高。本地部署是一次性投入 + 摊销， 量上来之后单通成本会显著下降。
能改得动
客户经常需要改一些很具体的逻辑（某个行业术语、某个审批流程）。 本地部署可以直接改代码；调 API 的方案只能在对方开放的参数里打转。
不依赖外部服务的存亡
外呼是长期业务。如果核心能力依赖某个外部服务，那个服务涨价、下线、 改协议，你的系统就得跟着动。
但代价要认
本地部署意味着客户要自己承担 GPU 成本与运维。 所以我们从不隐瞒这一点：CPU 跑不动语音合成与大模型，这是硬约束。
工作原则
六条我们自己守的规矩
这些不是宣传语，是遇到分歧时的判断依据。写出来是为了让合作方知道我们的底线在哪。
合作方式
我们怎么和客户配合
企业级项目的失败很少是技术问题，更多是配合方式有问题。 所以这里把分工写清楚。
你提供的
合法持有的客户名单、行业合规边界（或一起梳理）、 产品与价格口径、现有 CRM 与工单系统的接口情况、转人工的承接安排。
我们提供的
系统部署与配置、话术设计与迭代、知识库搭建、线路对接、 质检规则配置、上线陪跑与排障支持。
共同负责的
小范围试点、话术打磨、验收指标确认。这三件事任何一方单独做都做不好 —— 试点要你的真实数据，话术要你的业务知识，验收要双方都认可标准。
不由我们做决定的
话术里能不能承诺某个效果、某个价格能不能报、某类客户能不能打 —— 这些由你的业务与法务判断，我们只负责把它做进系统。
常见问题
关于我们常被问的四条
这些问题在方案会上几乎每次都会出现。
你们能提供哪些技术支持和响应时效？
正式合作会约定支持范围与响应时效，通常按问题等级区分： 系统不可用、通话中断这类影响业务的为最高优先级； 配置调整、话术修改为一般优先级。
需要说明的是：私有化部署后，机器、网络、磁盘属于客户自己的运维范围。 我们能做的是软件层面的排障与修复，不代管硬件。
如果以后不再合作，我的数据能拿走吗？
能。系统提供数据导出能力：名单、通话记录、转写文本、审计明细都可以按标准格式导出。
私有化部署的情况下更直接 —— 数据本来就在你自己的库里， 不存在「拿不走」的问题。这也是我们建议强监管客户走私有化的原因之一： 数据主权在你自己手上。
模型会不会突然变差？
本地部署的模型不会「突然」变化，因为我们不做静默升级 —— 什么时候升级、升哪个版本，由客户决定，并且必须可回滚。
这一点和云端 API 有本质区别：调 API 的方案里，服务方换一个模型版本， 你的效果可能当天就变了，而你无法阻止也无法回滚。
能来现场做演示吗？
可以安排线上或现场演示。更有效的方式是先真机演示再开会： 我们按你的行业配一版话术，用真实线路打给参会的人， 让他们自己体验一通完整对话，而不是看我们演示一段剪好的录音。
具体安排见联系我们。
技术栈
我们用的东西和为什么用它
写这一节是为了让技术选型的人能判断我们的水平与路线， 而不是听营销话术。
| 层 | 做法 | 为什么不用另一条路 |
|---|---|---|
| 语音识别 | 本地部署的流式识别模型 + 热词表 + 端点检测 | 不调公网 API：网络抖动会让响应时间不可预测，而对话对延迟极敏感 |
| 语音合成 | 本地部署的神经网络合成，支持音色克隆，48kHz 输出 | 不用传统拼接合成：机械感明显，长句尤其明显 |
| 对话与推理 | 本地部署的开源大模型 + 检索增强（RAG） | 不让模型自由发挥：涉及参数、价格、承诺的回答必须能检索到出处 |
| 业务编排 | 自研的状态机：节点、分支、闸门、留痕 | 不把流程交给模型判断：「这一步该不该转人工」必须是确定的规则 |
为什么把「流程」和「模型」分开
很多方案的失败点在这里：把「下一步做什么」也交给大模型决定。 结果同一个客户、同样的问题，今天和明天的处理路径不一样 —— 这在演示时看不出问题，在生产和合规上都是灾难。
我们的做法是：流程由规则决定，模型只负责理解与生成。 模型说「客户在问价格」，规则决定「这时候该查知识库还是转人工」。 这样系统行为可预测、可测试、可审计。
为什么强调「可测试」
语音对话系统最麻烦的地方是它很难自动测试：音频进、音频出， 中间还有模型的不确定性。所以我们在设计上刻意把可测的部分抽出来 —— 闸门逻辑、状态机、留痕格式都可以用纯文本测试，不依赖音频。
这也是为什么我们的测试里有大量「断言某个函数在生产路径上真的被调用」这类检查： 因为「写了但没接上」是这个系统里最隐蔽的失败方式。
团队与工作方式
我们怎么做事
不写人数和融资 —— 那些信息对判断「能不能合作」帮助有限。 写工作方式，因为它决定了项目会怎么推进。
技术直接对客户
做方案、做演示、做部署的是同一批人，不经过售前转述。 好处是需求不会被"翻译"丢失，坏处是能同时推进的项目数量有限。
先跑真机再谈方案
不接受「先看 PPT 再决定要不要看演示」。演示的默认做法是用客户的真实场景问题， 而不是我们准备好的脚本。
不接受「先上线再补合规」
合规配置必须在试点之前完成。先上线再补，等于把风险敞口留在生产环境里。
说清做不到的部分
包括：CPU 跑不动合成与推理、重方言识别差、长程谈判不如人、 无法承诺转化率。这些都会在方案里写明，不靠客户自己发现。
交付带运维能力
私有化项目必须交部署说明、配置手册、排障手册。目标是「换个人也能维护」， 而不是把客户锁在原来的对接人身上。
不承诺做不到的时间
上线时间按「话术配置 + 部署 + 联调 + 试跑」四段估，并且把 「你内部确认口径要多久」明确算进去 —— 这一段最容易被低估。
我们踩过的坑
这些教训写进了产品里
下面几条都是真实踩过的。写出来不是为了显得诚实，是因为它们解释了为什么有些设计看起来「过度谨慎」。
「配置写了，但不生效」是最常见的坑
我们曾经有一个录音开关，配置里写着关闭，代码路径却从来没读过这个值 —— 客户以为不录音，实际一直在录。这类问题在测试里完全看不出来， 因为每个模块单独测都是对的，只是没人把配置接到代码上。
后来我们做了一件笨事：写扫描器，把配置文件里的每个键在生产代码里找一遍， 找不到读取点就报错。这个方法很原始，但确实把「配了不生效」这类问题挡住了。
「写了但没人调用」同样常见
更隐蔽的一种是：某个功能写好了、测试也覆盖了，但生产主流程从来没调用它。 比如强制转人工的判定逻辑写得很完整，却没有任何一处代码调用它 —— 结果是制度写了五条，生产上一条都没生效。
所以我们有一类测试专门盯这个：断言「某个函数在生产路径上真的被调用」， 而不只是「这个函数算得对」。
「失败静默变成空」比崩溃更危险
早期有个设计：读不出来就返回空列表。看着很稳健，实际后果是 「所有号码都变成未知 → 全部放行 → 每天重打一遍空号」。 现在我们的原则是失败必须显式：报错、进返回结果、进批次汇总，不允许静默。
这些设计在某些人看来是「过度谨慎」。但外呼系统一旦跑起来， 出问题的代价不是一次报错，是一次投诉、一次处罚。
边界声明
我们不擅长的三类项目
写清不擅长什么，比宣称什么都擅长更容易建立信任。
一、需要长程谈判的销售
如果一通电话需要反复讨价还价、需要现场承诺特殊条件、需要判断对方话里的弦外之音， 这类对话不适合交给当前的 AI。它可以在前期做筛选与信息确认， 但真正的谈判环节交给人更划算。
二、强监管且流程未定的业务
如果业务方自己也说不清「哪些话能说」，那我们无法把它变成可执行的规则。 这种情况下正确的顺序是先梳理业务与合规，再谈系统。
三、名单质量极差的场景
如果名单里有大量空号、停机和「从没咨询过」的人，先做数据清理。 系统再好在坏数据上也发挥不出作用，反而会加速号码被标记。
这三类情况我们都会在前期沟通时直接说。不是不想接， 是因为硬接下来的结果通常是「项目做了但没效果」，对双方都不划算。
怎么验证我们
不要只听我们说
采购任何系统都应该验证。这一节列出你可以自己动手验证的四件事。
第一，让演示用真实噪声。看演示时要求对方用手机扬声器外放、 在普通办公室里打，而不是用安静环境的高清音频。识别率在这种条件下才有参考价值。
第二，问两个刁钻问题。你自己准备两个「机器肯定答不上来」的问题， 看它怎么处理。如果它编了一个答案，说明检索兜底没做好；如果它坦然说确认一下并转人工， 说明设计是对的。
第三，看打断后的反应。在它说话时打断它，看它是否立刻停。 如果它坚持把那段话说完，那它在真实对话里会非常难用 —— 因为客户不会等它说完。
第四，要求看审计明细。让对方现场打开一通通话的完整记录， 看能不能看到转写、意图、知识库命中、转人工原因。 看不到这些的系统，出问题时你拿不出证据。
这四件事都不需要技术背景，十分钟就能做完，但能筛掉大部分不合格的方案。