有人看到我简历上的一个项目，问了我一个很简单的问题：

这个软件真的解决了你的问题吗？

这个问题问得很好。

那个项目是一款播客摘要工具。

源代码公开在这里：yanqian/podcast-summarizer。

最初的想法很直接。

听完一段长音频，要花不少时间。

如果能先把一期节目转成文字，再生成摘要，我也许只需读一遍摘要，不必花一个小时收听，就能理解整期内容。

当时的产品假设是这样的：

长内容
  -> 转写文本
  -> 摘要
  -> 理解

真正做完以后，我才意识到，这个假设并不成立。

倒也不是全错。

但它偏偏错在最关键的地方。

这个软件确实能生成摘要。

它也完整展示了一套 AI 工作流。

它能导入播客、处理音频、生成转写片段和摘要片段，还能显示两者之间的对应关系。

作为工程演示，它是成功的。

但作为帮助人理解内容的工具，它没有解决真正的问题。

最初的问题并不是内容太长 链接到标题

一开始，我以为问题就在于内容太长。

一期播客很长。

一篇博客文章也可能很长。

会议转写同样可能很长。

于是，最自然的产品思路就是压缩：

把内容变短

摘要承诺的正是这件事。

它减少篇幅。

删去重复。

把散漫的对话梳理出结构。

看起来很高效。

但真正读过生成的摘要后，我发现了一件不太对劲的事。

摘要读完了，我还是不知道那场谈话究竟是怎样展开的。

我知道他们谈了什么。

知道大致结论。

也记住了几个要点。

但我并没有真正理解整段对话。

摘要丢掉了：

  • 一个观点是怎样被引出来的
  • 是什么问题触发了这个观点
  • 哪些地方仍有疑问
  • 有哪些例子支撑它
  • 讨论过哪些取舍
  • 哪些情绪或现实背景很重要
  • 说话者在哪里改变了思路

摘要并没有说错。

它只是不够。

摘要会抹掉通往结论的过程 链接到标题

好的摘要保留了终点。

却留不住抵达终点的那条路。

这正是问题的核心。

很多时候，我们恰恰要沿着这条路走一遍，才能真正理解一个观点。

人们讨论一个想法时，重要的不只是最后那句话。

更重要的是思路如何一步步推进：

问题
  -> 背景
  -> 例子
  -> 质疑
  -> 澄清
  -> 结论

摘要往往把整个过程压成一段干净利落的文字。

结果确实更方便扫读。

但许多帮助我们理解观点的线索，也随之消失了。

在探索性内容里，这个问题尤其明显。

播客、访谈、随笔、设计讨论和技术对话中，常常会冒出一些尚未完全成形的想法。

它们的价值不只在最终答案。

一个答案如何从问题和讨论中逐渐浮现，本身也是价值的一部分。

摘要可以告诉我：

说话者认为 X 很重要。

但我通常还需要知道：

为什么 X 在这里成了关键问题？
他们当时想解决什么问题？
他们排除了哪些可能？
什么证据让这个观点变得可信？

这已经不只是摘要了。

这是带着上下文阅读。

这个项目真正证明了什么 链接到标题

不过，作为一个软件项目，它依然很有价值。

它迫使我搭建出一套完整的本地工作流：

播客 URL
  -> 查询元数据
  -> 下载音频
  -> 切分音频
  -> 语音转写
  -> 转写片段
  -> 摘要片段
  -> 来源映射
  -> 前端阅读器

这些工作很重要。

整个实现并不只是给一条提示词套上用户界面。

系统有持久化机制。

支持幂等导入。

使用本地存储。

有后端处理流水线。

也有前端阅读器，把摘要放在对应的原始转写片段旁边。

最后这一点尤其重要。

建立摘要与转写文本之间的对应关系，已经比单纯生成摘要多走了一步。

它隐约指向了一种更好的交互方式：

摘要 -> 原始转写文本

但这个设计停得太早了。

它只是把来源摆了出来。

却没有把原始材料变成一个可以操作、可以深入探索的阅读界面。

缺少的是在全局与细节之间缩放 链接到标题

更合理的产品模式不是：

内容 -> 摘要

而应该是：

拉远看全局
  -> 检视
  -> 拉近看细节
  -> 提问
  -> 核实
  -> 再次拉远

摘要适合用来拉远视角。

它能让我先看见整张地图。

但碰到真正重要的内容时，我还需要拉近细看。

我希望能点开某个片段，然后继续问：

  • 这里的背景是什么？
  • 说话者这句话究竟是什么意思？
  • 在这之前发生了什么？
  • 有哪些例子支持这个说法？
  • 这里涉及哪些取舍？
  • 他们有没有提到其他方案？
  • 你能检验一下我是否真的理解了这部分吗？

一旦加入这些交互，产品的性质就变了。

它不再只是一款摘要工具。

它会变成一个以原始材料为基础的阅读与推理界面。

摘要只是其中一层。

原始内容始终可查，也始终可以继续追问。

让问答始终有证据可查 链接到标题

最自然的下一项功能，不是继续改进摘要提示词。

而是加入以证据为依据、结合上下文的问答。

交互过程可以是这样：

选中一个摘要片段
  -> 展开对应的转写片段
  -> 提出问题
  -> 给出带引用的回答
  -> 高亮原始片段

答案不应该脱离来源，悬在原始内容之上。

它必须牢牢依附于证据。

每次回答时，系统都应该返回：

  • 使用了哪些转写片段 ID
  • 对应的时间戳范围
  • 原文摘录，或对证据的准确转述
  • 回答只使用了选中片段，还是也参考了相邻上下文
  • 哪些地方无法确定，或原始材料中根本没有提到

这一点很重要，因为人很容易过早相信 AI 给出的答案。

一段流畅的回答，很容易制造出已经理解的错觉。

但真正的理解必须有依据。

用户应该随时可以追问：

这个答案是从哪里来的？

产品不必绕弯子，只要回答：

就在这里。

然后直接展示原始材料。

合理分段比切得更碎更重要 链接到标题

我也曾想过，调整音频切分方式能不能改善产品。

也许音频块切得更小，产出的样本会更好。

也许切得更细，摘要质量也会提高。

但这只对了一部分。

音频切分主要解决的是流水线运行中的问题：

  • 文件大小限制
  • 重试机制
  • 本地存储
  • 转写边界
  • 运行中断后的恢复

它不会自动带来更好的理解。

真正重要的分段，发生在转写完成之后。

内容单元不应该是：

为了方便 Whisper 处理而切出的某个音频块

更合理的单位应该接近：

一次连贯、完整的话题推进

这就需要按主题分段。

更好的流水线可以从较小的转写单元开始：

单句发言或较短的转写片段

然后再识别主题边界。

一种可行的方法是：

转写单元
  -> 向量嵌入
  -> 相邻窗口相似度
  -> 候选主题边界
  -> LLM 修正边界
  -> 输出结构化章节

向量嵌入可以找出相邻内容在语义上逐渐拉开距离的位置。

但只靠向量嵌入还不够。

它适合提出候选切分点，却不适合直接决定最终边界。

随后可以让语言模型结合话语中的信号修正边界，例如：

  • 提出新问题
  • 转向新话题
  • 开始回顾总结
  • 发言者切换
  • 得出结论
  • 引入新例子
  • 提出新的反对意见

最终结果应该采用结构化格式：

章节标题
起始片段
结束片段
摘要
关键词
划分边界的理由

这比按固定大小分组更合理。

固定分组很容易实现。

但真实对话从来不会按照固定长度展开。

为什么 NotebookLM 更接近我想要的产品 链接到标题

后来我发现，NotebookLM 更接近我真正想要的产品。

不是因为它能生成一份完美的摘要。

而是因为原始材料在其中始终可供查询。

我可以继续追问。

可以查看某个具体段落。

可以在整体认识和局部细节之间来回移动。

也可以检验自己是否真的读懂了某一部分。

这种工作流更接近用户真正要完成的事：

不是压缩信息
而是在信息中穿行

这也改变了我对 AI 摘要工具的看法。

最好的工具，并不是能生成最短准确摘要的那个工具。

真正好的工具，应该帮助我围绕原始材料建立一套稳固的认知框架。

有时，这需要压缩。

有时，需要展开。

有时，需要查看证据。

有时，需要提出问题。

有时，则必须回到原文。

真正的产品教训 链接到标题

这个项目让我学到了一条关于 AI 产品的重要经验。

我们很容易从模型能力出发：

AI 可以生成摘要。

然后围绕这种能力搭建产品：

那就做一个摘要工具吧。

但用户真正的问题可能是：

我需要高效理解篇幅很长的材料。

这两件事不是一回事。

摘要是一种能力。

理解是一套工作流。

这个区别很重要。

一种能力可以在演示中显得很惊艳。

一套工作流却必须经得住真实使用。

我的工具确实压缩了内容。

但真正需要的工作流，是让人能在不同层次的信息之间来回穿梭：

整体概览
  -> 证据
  -> 局部解释
  -> 继续追问
  -> 回到来源核实
  -> 综合形成理解

意识到这一点后，产品方向也随之改变了。

真正重要的功能不再是：

把摘要做得更好

而变成了：

让原始材料可以被探索

如果继续做，我会增加什么 链接到标题

如果继续这个项目，我不会先去修改提示词。

我会做四件事。

第一，按主题生成章节。

应用应该识别转写文本中真正有意义的内容区段，而不只是沿用音频块或固定大小的片段组。

第二，加入有证据支撑的问答。

每个答案都应该能指回具体的转写片段和时间戳。

第三，支持可缩放阅读。

用户界面应该允许人从整期摘要逐层深入到章节、片段和原始文本，也能随时返回上一层。

第四，加入主动回忆。

系统应该针对用户选中的内容生成问题，用来检验用户是否真正理解了这一部分。

最后这一点很容易被低估。

读完一份摘要，可能会让人产生已经理解的感觉。

回答问题，则能暴露自己到底懂没懂。

为什么我也会选择停下来 链接到标题

不过，我现在大概不会继续做这个项目。

这同样是这次经历带来的教训。

一个项目不必发展成一家公司，才算有价值。

这个项目已经完成了它的使命。

它展示了一套由 AI 驱动的软件流水线。

它也让我练习了本地优先架构、前后端边界、持久化、模型适配器和可恢复处理。

更重要的是，它让我发现，最初的产品假设并不完整。

这本身就是一个很好的结果。

最坦诚的结论是：

这个软件完成了工程演示。
但它没有解决理解问题。

这一点值得明确说出来。

因为成熟的工程能力，不只是让软件成功运行。

还包括看清一个正常运行的软件，究竟有没有解决对的问题。

更准确的项目表述 链接到标题

现在，我会换一种方式介绍这个项目。

不再说：

我做了一款播客摘要工具。

而会说：

我搭建了一套用于播客转写和摘要的本地 AI 流水线，
随后意识到，摘要只是更深层阅读工作流中的一层。

这是一种更准确的讲法。

它既体现了实现能力。

也体现了产品判断。

继续演进的技术路径已经很清楚：

语义分段
  -> 有依据的问答
  -> 来源引用
  -> 可缩放阅读
  -> 理解程度检查

但更深层的教训其实很简单：

不要把文字变短误认为理解变深。

摘要当然有用。

但摘要不等于理解。

理解需要在不同层次之间不断移动：

拉远
拉近
核实
提问
返回

这才是我真正想要的产品。