我判断的那个卡点，客户在不知情的情况下自己提了出来
这是一次很小的交付：客户是一档两个人的播客，我给它做流程自动化。规模小到不能再小，但它满足一个真实交付项目的全部条件——我不是唯一的使用者，对方不写代码，而且我交完之后得能在我不在场时继续跑。
时间范围：2026 年 8 月起，进行中。角色：《稳稳接住》联合主播，同时是这次流程改造的执行者。另一位主播是这次交付的真实使用者，非技术背景，与我异地协作。本页内容经她同意后公开，不含她的个人信息。
本页所有引用均来自真实的微信对话与项目文件。交付效果的部分只写到当前进度为止，采纳结果出来之前不做任何预测性表述。
四期节目，四种做法
《稳稳接住》是一档两个人的播客，一周一期，45 到 60 分钟。两位主播分处两地。节目的定位文档里白纸黑字写着「剪辑归另一位主播」。
但实际情况是两个人轮流剪。文档和实际做法早就脱节了，而且没有人回去改文档。
这是我在现场看到的第一件事，也是最容易被跳过的一件事。如果我直接照着定位文档去设计流程，我会为一个不存在的分工做优化。
轮流剪辑的代价，写在文件名上
轮流意味着每一期的执行者都在换，交接成本每期发生一次，而两人之间没有交接物，只有微信里说一句。结果就是产物完全不一致：
（外加一个原始录音）
（外加 m4a 和 mp4）
四期四种命名法，格式在 md、docx、txt、srt 之间反复横跳。这不是懒，是两个人的习惯在交替。
先说两件我判断错的事
在真正看文件之前，我有两个想当然的判断，两个都错了：
- 我以为剪辑是固定一个人做的。因为定位文档是这么写的。实际是轮流。这个错误如果不纠正，我设计的所有东西都会只服务一个人的习惯。
- 我以为第五期还没录。因为项目文件夹里没有它。实际早就录完了，只是素材在另一个人的电脑里。
两个错误的来源是同一个：我把文档和文件夹当成了现场。它们只是现场留下的痕迹，而且是有偏差的痕迹。
哪一步既是纯体力，又堵着下游
我把整条流程按「判断含量」拆开，因为能不能自动化跟难不难做没关系，跟这一步要不要做人的判断有关系。
最值钱的那一格是「剪辑版成片重新转写」。它零判断、纯体力，但它卡住下游三件事：时间轴、高光片段、切片清单，全都依赖准确的成片时间戳。
而且它是已知事故的根因。发布文案模板里有两条警告：「时间点必须对着剪辑版成片」「被剪掉的内容不能写进来」。会写下这两条，说明已经出过错。第四期那份精确到秒的切片清单，是人肉数出来的。
三段工具，共用同一条成片时间轴
不是三个互不相关的小脚本，是录完之后到发布之前的一条链：
三段共用同一份成片时间轴，所以第三段不可能引用到已经被剪掉的内容——这一条写成了回归测试，不是靠人记得。
代码是公开的：github.com/Juliejue/podcast-ai-workflow，含匿名 demo 和 8 项测试。仓库里不含任何真实逐字稿、音频或节目信息。
先看第一段到底解决了什么
第四期原有的转写里，错误全部集中在专有名词上，而专有名词每期就是固定那几个。同一段音频，旧转写和工具输出的对比：
开场白连主播名字都是错的，而开场白每期一模一样。这类错误可预测、可穷举，所以它属于「零判断」——一张术语表就能一次性解决，不需要每期人肉改。实测三分钟音频内自动修正四处；一集 52 分钟的音频约需 35 分钟跑完。
三个刻意的设计决策
后来使用者提出要看「接话频率」和「两个人的配合」——正好撞上这条边界。四期录音全是单声道混音，两个人在同一条轨里。我的处理不是去装模型，而是建议以后录制改成分轨：把问题消灭在源头，比在下游用 AI 猜谁在说话可靠得多，也不用她多装任何东西。
有一条线我不打算越过
第四期的切片清单里有这么一句：
第 6 条别只截结论。前面「我只会心疼我自己」那段是承重墙，有它在是自我和解，没它就像甩锅。
这是判断，不是劳动。它决定的是同一段话被听成什么。一旦交出去，切片就变成机器切的，节目的味道就没了。
同样不碰的还有排序策略——从轻松的开场、到引发共鸣、再到锋利的收尾，那是对听众情绪路径的设计，不是排列组合。
她自己提出了同一个需求，并且自己划好了边界
工具做完的第二天，东西还没发给她，她先在微信上问我：
你 AI 能够读取我们剪辑后的逐字稿吗？我在想能不能让 AI 分析一下，一个好的框架是什么样的。
起因是她发现最新一期的完播数据明显好于前三期，想搞清楚为什么，好在下一期复刻。她自己先试过：
我试了，AI 不能够传音频。
然后她把需求说清楚了：
你把我们四期的剪辑后音频都让 AI 读取一下，发我逐字稿，最好有时间节点，然后我这边分析看看什么样的脉络会更好一些。
这段话里有两件事值得单独拿出来
- 「剪辑后音频、逐字稿、最好有时间节点」——和我前一天判断出的最值钱的卡点，一字不差。而她并不知道我做过那份分析。需求验证最强的形式不是对方接受了你的方案，是对方在不知情的情况下，独立撞上了同一个问题。
- 「然后我这边分析」——她主动把判断权留给了自己。我准备要谈的那条边界，她划在了和我一样的位置上，而且是她先开口的。第 05 节那段「这条线不该由我一个人划」，就这样解决了。
还有一个细节：她是自己试过、卡住了，才来找我的。这和「我做了个工具希望你用用看」是两种完全不同的起点。
我先给了一个答案，然后数据把它拆了
为了回答她的问题，我先做了一件不需要转写就能做的事：把四期的原始录音和剪辑版成片放在一起，量各自的长度。
这张表我算错过一次。第二期我一开始按文件夹里那个 49 分钟的原始视频算，得出剪掉 35%；后来才发现完整的录制是会议软件导出的那份，有 84 分 38 秒——真实数字是 61.7%，差了将近一倍。数据源不完整的时候，算出来的东西看着一样合理。
第四期砍掉了一半以上，也是完播数据最好的一期。我当时的结论是：剪得越狠，听得越完。这个结论符合直觉，也和我剪它时的投入对得上——那期我细剪了两遍，每遍两小时。
然后我拿到了四期的完整平台数据
三件事同时冒出来，每一件都在削弱我那个结论：
- 剪得最狠的那期，完播率只排第三。第二期砍掉 61.7%，是四期里最多的，完播率却只有 40%。反过来，完播率是严格单调递增的，和「第几期」完全对齐，而剪辑率的顺序跟它对不上。也就是说，任何随期数上升的因素都能同样好地解释完播率：节目变熟、听众筛选、平台推荐权重，全是候选，剪辑率并不占优。
- 播放量和完播率是反着走的。第四期播放量最低，完播率最高。这是典型的选择效应：泛听众流失，剩下的都是核心听众，而核心听众本来就更可能听完。那么完播率上升可能不是节目变好，而是听众变少的副作用。
- 四期样本，播放量是两位数，而且分母比看上去还小。平台对完播率的定义是「完播人数 ÷ 播放人数」，而卡片上那个数字是播放次数。真实分母只会更小。
现有数据无法区分「节目变好了」和「只剩铁粉了」。唯一还算稳的观察来自两头：第一期分享率四期最高、完播率四期最低，是几乎没剪的那期——选题能拉来人，内容留不住人；第四期正好相反。拉新和留存的此消彼长，比单看完播率有意义。
我把推翻的过程完整留在这里，是因为一个只写成功归因的分析，下一次还会得出同样草率的结论。而且真正的重点是：这张表在两小时前根本算不出来。第二、三期的原始录音一直不在共享文件夹里，是她为了这次分析才补进去的。第 01 节末尾那条「没有素材存放约定」的观察，在这里第一次产生实际代价，也第一次被解决——流程改造真正的收益不是省时间，是让一个原本无法回答的问题变得可以问对。
我整个做完了，才想起没问过她用什么电脑
东西做完、准备发出去的那一刻，我才意识到：我从来没有确认过她用的是什么操作系统。
如果是 Windows，这个脚本她大概率跑不起来——要装 Python、装依赖，命令行语法还不一样。我在自己的 Mac 上把功能验证得很仔细，唯独没验证过它会不会在她的机器上根本打不开。
所以我停下来了，先去问系统，没有直接把工具丢过去。这也是为什么在第 06 节她提出需求的时候，她手上其实什么都还没有。
写在这里是因为它对下一次有用。一个只写成功的案例没有参考价值。
还没有发生的事
这个案例的成功标准只有一条：她愿意自己用。不是工具做得好，也不是省了多少时间。如果她说「还是你帮我跑吧」，这次交付就是失败的——说明门槛设错了，得改。
已经发生的：三段工具都写完并跑通了，跨期复盘用二、三、四期的真实数据跑出了结果，代码开源，8 项回归测试通过。
还没发生的，也是真正要紧的三件事：
- 她拿到逐字稿和复盘报告之后，有没有真的用它做出第五期的剪辑判断
- 下一次她需要转写时，是自己跑，还是来找我
- 她会不会自己往术语表里加词
这三件事都还没有答案。工具做完了不等于交付完了——东西能跑，只证明我这一侧做完了。结果出来之后我会把它写在这里，无论正反。如果她说「还是你帮我跑吧」，那就是这一节要写的内容。
五条
- 文档不是现场。定位文档说剪辑归一个人，实际是轮流。照着文档做设计，会为不存在的分工做优化。
- 找零判断、但堵着下游的那一步。不是找最花时间的那一步。前者只会指向一两个地方，后者会让你陷进一堆各自独立的小优化。
- 交接设计的判据是「他需不需要回来找我」。术语表做成纯文本、边界写进文档，都是为了这一条。工具做完不算交付完，对方能独立用下去才算。
- 验证功能不等于验证可用性。我在自己机器上测得很仔细，却没问过对方用什么系统。这是我这次犯的最大的错。
- 先确认数据源是完整的，再算比例。第二期我按一个不完整的原始录音算出「剪掉 35%」，真实数字是 61.7%。数据不全的时候，算出来的结论看着一样合理——而它恰好会反过来支持我原本就想相信的那个结论。