一次对话的复盘。围绕一个刚上线的 TTS 流水线工具，聊清楚了几件事：AI 时代的"code is cheap"是不是真的、单机脚本到服务化的断层、以及为什么"写个 AI 脚本就能解决"往往是最贵的幻觉。
一、"code is cheap" 是半句话
流行的说法是 LLM 让 code 变得廉价了。更准确的版本是：code 的边际生产成本塌方了，但总拥有成本没变，某些场景甚至更贵。
塌方的是"从零到一个能跑的 demo"。没变便宜的是：
- 让代码在生产环境稳定跑、处理边界情况、和老系统对齐
- 判断生成的代码对不对、架构合不合理——因为你得 review 大量没亲手写的东西
- 维护一堆 AI 生成、没人真正理解的代码
所以当自媒体上 AI 框架一周一个、人人 SOTA、demo 剪得像电影预告的时候，真正的过滤器只剩一个问题：线上跑多久了，多少真实用户，failure case 怎么处理？ 一问就失声的，大多是 talk。
Talk 从来没 cheap 过，只是现在通胀得更快。
二、单机脚本 → 服务化，不是"套个 API"
这是最容易被低估的一段路。表面看只是把脚本包成服务，实际上它强制你面对一堆在单机上可以装没看见的问题：
- 状态去哪存、失败了怎么恢复
- 并发请求会不会打架
- 密钥怎么不泄漏
- 重启后历史还在不在
- 存储满了怎么办
- 任务粒度怎么切、重试边界在哪
单机脚本里"能跑"有多少是靠运气，只有走完服务化这一步才知道。没走完就开始讲架构的人很多，这恰恰是最值得警惕的信号。
三、自用工具的陷阱
一个诚实的自我提醒：自用工具最大的陷阱是，你是唯一用户，所以所有反直觉的设计你都能自己绕过去。
手动改的 normalize 规则、靠字符加权估的字幕时间戳、可能误报的转写验证——自己知道怎么忍，换个人用可能第一天就卡住。
这引出一个需要先想清楚的分叉问题：做服务化这一层，是为了让别人能用，还是为了让自己搞懂服务化？ 两个目标导出完全不同的下一步：
- 前者 → 找一两个真实非本人的用户，看他们在哪里卡住
- 后者 → 继续往深挖 observability、队列、多租户、成本核算
这两件事不冲突，但不能混着做。混着做就会既没人用，也没彻底挖透。
四、最贵的幻觉："写个 AI 脚本就能解决"
这是最值得单独拎出来的一条。
中英混读发音不稳是 TTS 模型本身在 code-switching 上的能力缺陷——这是上游问题。初期的想法是写个 LLM 预处理脚本（改写文本、加标注、插 SSML）在下游绕过去。能缓解，但解决不了。模型该读错的还是读错，你只是在猜它什么时候会错然后提前改。猜得准的时候很爽，猜不准的时候就只能回到人工试听+微调+重试。
抽出来的通用形式值得记住：
当一个问题的根因在模型能力层，应用层写再多脚本都是在打补丁，而且补丁之间会互相冲突。
真正的解法只有三条：
- 换模型——双语 TTS、带 language tag 的模型
- 改变问题——按语言切片分别合成再拼接
- 承认解决不了——做人机协同，人耳作为 ground truth
最后选的是第三条，做成纯流水线工具：合成、试听、微调、一键导出。这个决策听起来保守，其实是整个项目最关键的一次克制。LLM/Agent 越强，"什么时候不该让它介入"的判断越值钱。 读一百篇 agent 论文不会告诉你"你这个场景不该上 agent"，这个判断只能从踩坑里长出来。
早一点承认第一条路不成立，能省很多时间。自信和自满的分界线就在这里——不是"我能搞定"，而是"我分不清哪些问题不是应用层能解决的"。
五、平静，和它的反面
踩完这些坑之后的一个副作用：不焦虑了。
AI 这波最大的精神污染不是技术本身，是"你再不跟上就被淘汰"的节奏。每天新框架、新 SOTA、新 agent，看多了人会飘，飘起来就开始囤 tab、囤收藏、囤没看完的 paper，然后什么都没做成。
亲手把一个具体东西从脚本推到服务化，碰过 Postgres 迁移、Caddy 配置、Cookie 加密、ffmpeg 拼接这些一点都不性感的细节——这些事的副作用是让人重新相信时间和功夫是真的。别人一周发三个推说自己搭了个 agent，你知道中间省了多少东西，因为你自己补过那些洞。
但这种平静也有反面需要警惕：它容易变成另一种形式的自满——"他们都在吹，我在做真东西"。这个叙事一旦固化，就会默认"新热点 = 噪音"，从而错过一些其实值得追的新东西。
"不实践不出真知"是对的，但它的反面——"只实践不看"——也有坑。有些东西你动手一百次也撞不出来，得靠别人趟过的路告诉你。比如 forced alignment，自己摸索半年，不如一下午看 WhisperX 怎么做的。
平静的健康版本是"我知道自己在做什么所以不慌"，不是"我受够了所以不看了"。
小结：四条可带走的判断
- code 的生产成本降了，判断和维护成本没降——别被 demo 骗。
- 服务化是认知分水岭——走完才知道自己的"能跑"有多少靠运气。
- 识别"根因在模型层"的问题——应用层的聪明绕不过上游的硬缺陷，承认得越早越省。
- 平静来自动手，但动手之后要警惕把平静变成不看——实践和阅读是互补的，不是替代的。
这篇文档来自一次闲聊的复盘。工具本身是 TTS 流水线：脚本 → 合成 → 试听微调 → 一键导出音频和字幕。自用 + demo 演示，没有塞 LLM——这是它最重要的一次设计决策。
