一个硬件控把老式FeTAp电话改装成与Claude对话的设备:ESP32采集音频,树莓派编排,ElevenLabs做语音管道。延迟从13秒优化到1秒,月成本仅6美元。关键是——电话和微信机器人共享同一记忆库。

每一块都有它的位置。这是一个双脑系统:电话里藏着一块微型控制器,树莓派负责编排。
这是我引以为傲的部分:电话并不硬连线到某一套AI。它设计成可切换的。几个环境变量决定电话用哪个语音引擎、哪个语言模型、哪个声音——每个组合在延迟、成本、能力和隐私点上落在不同的位置。没有“最佳”方案。只有你今天想要的取舍。
第一个能工作的版本要13秒才回答。你说句话,然后沉默,等到你放弃回答才到。根本没法用。
第一个大脑用本地CLI跑Claude——免费,因为有订阅,但每个轮次要启动一个完整进程,实时通话太慢。改成直接调API:降到了大约2秒,但变成按量计费。然后把整个管道搬进ElevenLabs的对话式AI,一切都在同一个伺服器:大约1.2秒,语言模型通过ElevenLabs的积分计费,不用另外付API钱。最后这一步同时解决了延迟和费用问题。但也带来了一个陷阱。
换用更便宜、更快的模型(Claude Haiku)后,Elliot变得话多——它开始喋喋不休而不保持简短。显然的修复:限制回复长度。所以我设了一个token上限。
它奏效了正好两轮。然后通话会无声地中断——我说话,没有回应,直到闲置超时挂断。每次通话都这样。
日志很残酷:我的语音明显到达了(音频诊断中到处是语音峰值),但ElevenLabs没有生成它的转录。第三轮直接消失了。
原因:当硬token上限截断模型中间一句话时,ElevenLabs的轮次切换状态机不能干净地关闭当前轮次。对话卡住,接下来你说的话直接丢在地上。我花了很多时间怀疑轮次检测模型,直到在日志里看到被截断的半截词语,才意识到上限才是真凶。
修复:彻底移除token上限。用正确的方式强制简短——在提示词里,最上面加一条硬规则:“始终用最多1–2个短句回答。”连续六轮干净对话,回复简短,没有丢掉任何内容。有时候粗杠杆(硬上限)会破坏系统,而软杠杆(指令)不会。
电话跑在ElevenLabs Starter计划上:每月6美元,包含75分钟对话。一次典型的1.5分钟通话消耗大约560积分——语音转文字、语言模型和文字转语音合起来。Claude部分只占一小部分,因为Haiku很便宜。这个计划日常使用足够了;话多的人可以升级。
其他所有东西都已经付费或免费:Claude的通话后记忆提取用我已有订阅(0美元),Supabase用免费层(0美元,与微信机器人共享),树莓派电费大约每月0.3美元,ESP32板子几欧元一次性投入。所以:大约每月6美元,就能有一部古董电话,拿起来就能对话。对一个以前只是装饰的家具来说,不赖。
硬限制会以微妙的方式破坏有状态系统。Token上限不只是缩短回复——它破坏了对话的轮次状态。提示词里的软约束达到了同样的目标,但没造成破坏。当下游有状态保持时,宁可用指令代替硬截断。
管道集中比拼凑好。把语音、语言和声音放进一个托管代理,延迟从几秒降到大约一秒,而且简化了计费。代价是对每个阶段控制力降低——但对电话通话来说,延迟就是一切。
跨渠道记忆是杀手锏。电话和微信机器人共享同一个记忆,意味着AI感觉像是一个助手以两种方式触达,而不是两个独立的机器人。用语音告诉它一件事,它用文字时也知道。这种连续性是让它感觉活起来的关键。
免费获取企业 AI 成熟度诊断报告,发现转型机会
关注公众号

扫码关注,获取最新 AI 资讯
3 步完成企业诊断,获取专属转型建议
已有 200+ 企业完成诊断