podcast-to-article Skill：把播客逐字稿一键整理成可发布长文

Skill超级捕获手 技术创作者 2026-10-08 155 阅读

把一期播客的逐字稿——无论中文还是英文、两人对谈还是单人访谈——交给 AI，出来的结果通常三类：记流水账（满篇「张三说…李四说…」）、过度抽象（数字全丢、只剩「行业加速、生态成熟」）、改写过度（原话被压成第三人称、读不出说话人的样子）。podcast-to-article 是一个 Agent Skill，专治这三个问题：它把稿子的轴从「发言人 + 时间」换成「话题 + 判断」，同时保留事实颗粒度，并强制留出原话语气。实测数据：一篇 5730 字的原始稿精简 35% 到 3703 字，段落从 57 压到 47 段；英文播客案例终稿 2573 字，直接引语占比 23%（18 处）。作者还提供了一个纯 Python 标准库的自检脚本 check_style.py，内嵌 300 篇 AI 生成文本与 329 篇人类写作的对照语料研究数据，逐条验证 AI 痕迹。该 Skill 由 orange2ai 于 2026 年 10 月 7 日开源，GitHub 现有 89 star（截至 2026-10-08），MIT 协议。

核心能力与设计原则

podcast-to-article 的核心是一个七步流程：清稿 → 要点梳理 → 定主线 → 换轴成文（用原文）→ 人名校准 → 精简 → 自检。设计原则有三条硬约束：

  • 拆脚手架：当且仅当多人说同一件事时才合并发言——单人对谈反而要原话直译、原样保留
  • 保留颗粒度：数字、细节、具体例子一个不删，信息密度不能被「顺」掉
  • 留住语气：原话直接引语是人物性格的载体，不能全压成概述

这三条分别对应三种最常见的 AI 改写失败模式。

认可度

指标 数据
GitHub Stars 89（截至 2026-10-08，创建于 2026-10-07）
GitHub Forks 5
最新推送 2026-10-08

这是一个真正意义上的「当天新建、当天上榜」项目，仍处于极早期增长阶段。对于有播客内容资产的内容创作者而言，这是一个值得提前关注的工具型 Skill。

链接

GitHub 仓库：https://github.com/orange2ai/podcast-to-article

原作者

orange2ai（GitHub username: orange2ai）

暂无公开身份信息，仓库定位为 AI 内容处理工具链，SKILL.md 完全开源、无平台锁定，可接入 Claude Code、Cowork、Codex、GPT 等任意支持 SKILL.md 的 Agent。

介绍

逐字稿和文章是两种完全不同的文本物种。前者的轴是「谁在什么时间说了什么」，后者的轴是「这件事究竟是怎么回事」。直接让模型做「翻译」，结果必然是三种之一：流水账、过度抽象、改写过度。

这个 Skill 的解题思路是结构化换轴：先把稿子清洗干净（去时间轴、按说话人合并段落），再提炼要点并确定文章主线（不服务主线的整块删掉），然后换轴成文——这一步强制使用原话而非改写，最后人名校准（多人对谈时归属错误是高频 bug）和自检。

Skill 附带的 check_style.py 是一个独立可用的自检脚本，基于 300 篇 AI 生成文本 + 329 篇人类写作语料的对照研究，验证破折号、对举句、总结腔、序数词小标题、动词名词化、段首零回指评论六项 AI 痕迹指标，输出逐条命中数及直接引语占比（人类基准 10–28%）、段首自足判断句占比（参考 ≤30%）。

特点

  • 七步结构化流程：清稿 → 要点 → 主线 → 换轴（用原文）→ 人名校准 → 精简 → 自检，每步有明确判据
  • 保留语气：强制直接引语占比，23% 为实测终稿基准，不做过度改写
  • 人名校准：多人对谈时自动核对逐字稿，防止把主持人说的话归属到嘉宾
  • AI 痕迹自检：配套 check_style.py 脚本，6 项指标逐条输出，含人类基准对照
  • 跨语言：中文、英文单人/多人播客均支持；单人对谈自动切换为原话保留模式

使用方法

安装

git clone https://github.com/orange2ai/podcast-to-article.git
# 接入 Claude Code
ln -s "$(pwd)/podcast-to-article" ~/.claude/skills/podcast-to-article
# 接入其他 Agent：将整个目录放入其 skills/rules 目录，指向 SKILL.md

基本调用

在支持 SKILL.md 的 Agent 中直接说：

这是这期播客的逐字稿，按 Next Token 的格式整理成一篇文章

Agent 会自动执行七步流程。

独立使用脚本

# 字幕清洗：支持 SRT、VTT、md/txt（含 **发言人：** 标记）
python3 scripts/prep_transcript.py 第004期.srt -o 清洗稿.md
python3 scripts/prep_transcript.py 第004期.srt --speakers  # 只列说话人

# 成稿自检：AI 痕迹 + 直接引语占比 + 段首判断句占比
python3 scripts/check_style.py 成稿.md

使用场景与目标用户

场景：
– 播客主理人将每期节目转化为图文长文，发布到公众号、 newsletter 或博客
– 内容编辑将访谈素材快速整理成可发表的采访稿
– 媒体记者将录音采访转写稿整理成报道
– 研究者将学术对谈转写整理成论文素材

目标用户：
– 有持续内容生产压力的播客主理人
– 需要将音频内容二次分发的内容团队
– 有大量访谈素材需要结构化整理的媒体/研究机构

输入与输出案例

输入（摘录，5730 字原始逐字稿格式）：

[00:01:23] **张三**：我觉得这个东西最大的问题在于它的时间窗口。
[00:01:31] **李四**：对，而且不只是时间窗口，它的空间分布也很奇怪。
[00:01:45] **张三**：对，所以我们后来加了一个缓存层来解决这个问题。

输出（3703 字发布稿格式）：

在分布式系统的调度层面，时间窗口和空间分布往往是两套互相牵制的约束。张三的团队最终选择用缓存层解耦——这个方案在 4 小时压测中把 P99 延迟从 2.3s 压到了 380ms。

「当时我们其实有三个备选，」张三在访谈中回忆，「一个是纯异步、一个是分片同步、最后是这个缓存层。最后选缓存是因为它对业务代码的侵入最小。」

……（继续按话题轴展开，保留原话语气和具体数字）

另一案例（英文单人访谈，86 分钟 → 2573 字终稿）：

  • 直接引语 18 处，占比 23%（基准 10–28%）
  • 段首自足判断句 0%（初稿 100%，终稿归零）
  • 主线锁定：产品「主动替用户省钱 → 从每笔交易抽成 → 必须站在用户这边」
  • 标题改为含产品名的预判式标题

podcast-to-article 解决的是一个真实的内容生产痛点：AI 转写工具（如 Whisper + 字幕工具）解决了「有逐字稿」的问题，但没有解决「逐字稿不是文章」的问题。对于每周要更新、同时运营图文渠道的播客主理人来说，这个 Skill 把「录音 → 稿子 → 文章」这条链路的成本从几个小时压缩到几分钟。

GitHub: https://github.com/orange2ai/podcast-to-article

评论区

0 条评论

登录后可评论。

Skill超级捕获手 155 阅读