
## 一、事情是怎么开始的

我一直有在通勤路上听 Round Table China 这个播客的习惯，几个主持人用英语聊中国社会热点，口音地道，语速适中，很适合学英语磨耳朵。但有个问题：每期二三十分钟，没有字幕没有翻译（我找过有没有好心人翻译，找到了，但是好久没更新了），听完就忘了，想回头查某个表达根本找不到！这样其实属于无效听力输入！

我也尝试过自己记笔记，听不懂的地方倒回去、查词典、记笔记，记了几次，放弃了——边听边记太打断节奏（而且前提是我在早高峰能抢到座位）。

自然而然想到了自动化工作流，用现有的软件能不能做？翻了一遍市面上的方案：

YouTube 自动字幕：不适用，这是纯音频播客

OpenAI Whisper：API 收费，本地跑需要 GPU

各种语音转文字 SaaS：要么贵要么不准

于是我就想：能不能让 Hermes 帮我搞定？让它自己做一个 skill，每天自动下载最新一期，转成文字，翻成中文，把好用的词汇摘出来，最后还能在一个网页上方便地回头看。

做完之后发现，从播客上线到我看到双语笔记，全程不需要我动手。

## 二、渐进式披露，两个 Cron 搞定全流程

这条流水线跑在**腾讯云轻量服务器（2核4g）**上，每天凌晨 3 点自动触发，核心是用 Hermes 做总调度， MiMo做听录翻译。

流水线：

```
03:00 — 采集任务
  roundtable_daily.py: RSS → 下载 → ffmpeg压缩 → MiMo转录+翻译+词汇 → 缓存分段

09:00 — 交付任务
  roundtable_deliver.py: 读缓存 → 只输出metadata+词汇短语(~2K)
                                    ↓
                          agent构建学习笔记 → 保存文件 + 触发静态网站更新
                                    ↓
                          用户访问网页查看交互式字幕
```

核心采集脚本关键流程：

```python
def main():
    episode, collected = fetch_episode_not_collected()
    audio_path = download_audio(episode["mp3_url"])
    audio_path = compress_if_needed(audio_path)     # >10分钟就压缩到32kbps
    raw_result = transcribe_with_mimo(audio_path, episode["title"])
    os.unlink(audio_path)
    sections = parse_sections(raw_result)
    segments = parse_segments(sections)              # EN/CN按时间戳配对
    save_collected(collected, episode["mp3_url"])

    # 缓存全量数据到文件
    output = {"episode": episode, "sections": sections, "segments": segments}
    with open(CACHE_FILE, "w", encoding="utf-8") as f:
        json.dump(output, f, ensure_ascii=False, indent=2)

    # stdout只输出精华（渐进式披露）
    print(json.dumps({
        "episode": episode,
        "vocabulary": sections.get("vocabulary", ""),
        "phrases": sections.get("phrases", ""),
        "transcript_length": len(sections.get("transcript", "")),
        "cache_file": CACHE_FILE,
    }))
```

两个 cron job 为什么分开？因为省钱。

MiMo 一次调用能同时出英文转录、中文翻译、重点词汇、实用短语，全量转录 + 翻译约 33K+ 字符。但如果交付 agent 也把 33K 全文塞进上下文，每次 token 消耗翻倍。所以我让 agent 做渐进式披露：采集脚本的 stdout 只输出 metadata + 词汇短语（约 2K），完整内容缓存到文件；交付 agent 先拿精华做笔记，只有需要全文时才读取文件加载。

这是 Deepseek 自己想出来的优化——我之前根本没想过 token 花费这事。

音频处理方面：

- **去重**：已采集的 URL 存 `rt_collected.json`
- **压缩**：`ffmpeg -b:a 32k -ac 1 -ar 22050`，>10分钟的才压，CPU 处理几秒完成
- **RSS 源**：CGTN Radio 通常在 14:00~18:00 发布新节目，03:00 采集比最晚发布多 9 小时缓冲



## 三、翻译出错——AI 能力瓶颈

第一版交付后我打开网页发现：前面几段的翻译还是对的，往后一翻，中文和英文完全对不上。第 30 段的英文显示的内容在第 15 段的中文里出现过了——错位了。

查了一下，是 agent 写的数据模型有问题。它的原始设计是：

```python
# ❌ agent 的原始方案 — 分开存
transcript.txt   ← 英文全文
translation.txt  ← 中文翻译

# 解析时按行号索引对齐
en_lines = transcript.split('\n')
cn_lines = translation.split('\n')
for i in range(len(en_lines)):
    en_text = en_lines[i]
    cn_text = cn_lines[i]   # ← 灾难
```

它在两个文件各按行解析，靠**数组索引**对齐。如果 MiMo 恰好返回的英文段和中文段数量一样，没问题。但 MiMo 有时候输出 345 段英文、344 段中文——差了一段。从某个位置开始，第 121 段英文配上了第 120 段的中文，后续全部偏移，页面一片混乱。

我跟 agent 说：翻译对不齐。它的第一反应是去调 MiMo 的 prompt，让模型多输出一段中文来弥补。我跟它说：不对，问题不在模型，在你存数据的方式——**你应该把英文和中文成对存，而不是分开存再靠索引找**。

agent 重构了数据模型：

```python
# ✅ 修正 — 按时间戳配对
def parse_segments(sections):
    en_lines = [l for l in sections["transcript"].split('\n') if l.startswith('[')]
    cn_lines = [l for l in sections["translation"].split('\n') if l.startswith('[')]

    # 构建中文时间戳字典
    cn_by_ts = {}
    for l in cn_lines:
        m = re.match(r'\[(\d+):(\d+)\]\s+(.*)', l)
        if m:
            ts = int(m.group(1)) * 60 + int(m.group(2))
            cn_by_ts[ts] = m.group(3)

    # 遍历英文段，用时间戳找对应中文
    segments = []
    for l in en_lines:
        m = re.match(r'\[(\d+):(\d+)\]\s+(.*)', l)
        if m:
            start = int(m.group(1)) * 60 + int(m.group(2))
            en_text = m.group(3)
            cn_text = cn_by_ts.get(start, "")   # 按时间戳精确查找
            segments.append({"start": start, "en": en_text, "cn": cn_text})

    return segments
```

每个 segment 里 `{start, en, cn}` 绑在一起，永不分离。这个数据结构在三个脚本中贯穿始终——采集、交付、网站生成，都用同一份 `segments[]`。

对 MiMo 的 prompt 也做了调整。中文段数比英文少，往往是因为 MiMo 把多个英文句合并翻译成一句中文。agent 在 prompt 里加了反面示例：

```
CRITICAL: One Chinese segment per English segment.
Do NOT merge multiple English sentences into one Chinese sentence.
Each Chinese segment must translate ONLY its matching English segment.

WRONG (merged):
[02:24] **史蒂夫：** 这个系统本身叫做BK助手。但在系统内部，有一个语音助手。

RIGHT (separate):
[02:24] **史蒂夫：** 这个系统本身叫做BK助手。
[02:27] **史蒂夫：** 但在系统内部，有一个语音助手。
```

实测效果：345 段英文、344 段中文，差 1 段以内，差的那段往往是片头片尾音乐，不影响正文。

## 四、agent 把自己写的代码删了一半

有一期播客网页上线后我发现详情页的 emoji 显示不正常，让 agent 去修。它用 `execute_code` 里的 `read_file()` 函数读了自己的 `roundtable_sitegen.py`（911 行），读完直接把返回的内容写回去了。

结果网站打不开了。agent 很困惑地告诉我："文件可能有点问题，我在排查。"

我 ssh 到服务器上看了一下——文件只剩 500 行，而且**每行开头多了行号前缀**：`   1|`、`   2|`、`   3|`……原来 `read_file()` 为了方便定位代码，会在返回的内容前加 `LINE_NUM|CONTENT`，而 agent 没意识到这层"包装"，直接把带行号的内容写回了 `.py` 文件。

911 行的脚本变成了 500 行废代码。

我当时的第一反应是让 agent 从 git 恢复，但——我压根没给这个项目建 git 仓库。后来让 agent 靠自己的记忆和备份碎片重建了那个脚本。重建完之后它自己加了两个铁律：

```
1. 永远用 terminal(cat) 获取文件内容来写回
2. read_file() 只用来"看"，不用来"改"
```

并且在 skill 里写了一条 CRITICAL 警告，标注了事故日期和经过。从此再没犯过同样错误——但代价是一份 911 行的脚本被毁过一次。

## 五、网页字幕改了 4 版

网站启动之后，真正花时间打磨的是详情页的字幕交互。前后改了 4 次，每次都是我用着不满意，告诉 agent 问题在哪，它再改。

### v1：中文不见了

第一版 agent 做了双栏布局，左英右中，中文可以折叠收起。它觉得这样很整洁。

我打开一看：**没有中文**。哦，默认是英文视图，中文要手动点开。我让 agent 改了默认展示方式。

### v2：时间戳不准导致高亮乱跳

改成每段上下排列——英文在上，中文在下。播放时高亮当前段，应该点击某段跳转到对应音频位置。

看起来是对的，播起来就不对了：**高亮在跳来跳去**。当前主持人还没说完，高亮就跳到下一段了，有时候又跳回来。

原因是 MiMo 的时间戳是模型估算的，偏差 1~5 秒。agent 用了精确匹配：

```javascript
// ❌ v2 agent 方案 — 精确时间戳匹配
audio.addEventListener('timeupdate', function() {
    var t = audio.currentTime;
    for (var i = 0; i < segments.length; i++) {
        var s = segments[i].dataset.start;
        var next = segments[i+1] ? segments[i+1].dataset.start : (s + 60);
        if (t >= s && t < next) {
            // 高亮 segs[i]
        }
    }
});
```

时间戳本身不准，拿它做精确匹配当然是错的。

我跟 agent 说：高亮不准，你看能不能不要依赖时间戳。它想了另一个思路——百分比粗估。

### v3：百分比粗估，稳了

思路很简单：虽然 MiMo 对"某句话在第几秒"估算不准，但段落的相对顺序是对的。345 段、1200 秒，平均每段 3.5 秒，宏观比例不会错。

```javascript
// ✅ v3 — 百分比粗估
audio.addEventListener('timeupdate', function() {
    var pct = audio.currentTime / (audio.duration || 1);
    var idx = Math.round(pct * (total - 1));
    idx = Math.max(0, Math.min(total - 1, idx));
    // 高亮 segs[idx]
});
```

不依赖时间戳精度，345 段全部可见，播放时高亮行随进度平滑变化。不可能精确对齐每一句话，但整体进度是对的，体验反而稳了。

### v4：手工校正时间戳

但粗估毕竟不是精确——想精听某句话时，点到的大概位置还需要微调。

我跟 agent 讲：能不能加一个手动校正功能，让我播放时听到哪句话对不上就点一下修正？

agent 做了一套校正系统：

1. 点击"校正"按钮进入校正模式（关闭自动滚动）
2. 播放音频，听到某句话正好说出时，点击对应字幕段
3. 系统记录 `audio.currentTime`
4. 按钮变为 "保存 N 条"
5. 点击保存 → POST 到后端 API → 页面刷新 → 校正后的时间戳持久化

后端是个轻量的 Flask + SQLite 服务：

```python
@app.route('/api/corrections/<date>')
def get_corrections(date):
    row = db.execute("SELECT data FROM corrections WHERE date=?", (date,)).fetchone()
    return json.dumps({"corrections": json.loads(row[0]) if row else {}})

@app.route('/api/corrections/<date>', methods=['POST'])
def save_corrections(date):
    data = request.json
    db.execute("INSERT OR REPLACE INTO corrections VALUES (?, ?, datetime('now'))",
               (date, json.dumps(data)))
    db.commit()
    return json.dumps({"ok": True})
```

校正后的段落会显示 `[MM:SS]*` 带星号标记，时间戳变金色。刷新后精确匹配，从粗估切换到精准。

这版又让我接着挑了几个细节问题：

**CSS display 陷阱**：agent 给中文设了 `.seg-cn { display: none; }`，JS 用 `style.display = ''` 试图显示——空字符串会移除 inline style，CSS 的 `display: none` 重新生效，中文永远不显示。我跟它说了这问题，它改成 JS 显式设 `display = 'block'`。

**Markdown 列表断裂**：agent 的 markdown 转 HTML 函数逐行处理，遇到空白行就关闭 `<ol>`，导致每个列表项都在独立的编号列表里，全部显示成 "1."。我跟它说"编号全是一"，它排查后把逐行循环改成了 `while` 循环，遇到缩进行和空行跳过不关闭列表。

## 六、总结

这套流水线跑了快两个月了。每天凌晨 3 点自动采集，9 点更新静态网站，我起床打开手机浏览器就能看到昨天的双语笔记。

![image.png](https://developer.qcloudimg.com/http-save/yehe-11797656/ae4502ef5e14d7f426a8279740719ac5.png)

![image.png](https://developer.qcloudimg.com/http-save/yehe-11797656/b5b640c2ec697edb36c2a9879ec0a4b8.png)

![image.png](https://developer.qcloudimg.com/http-save/yehe-11797656/dbbee12c3458f0003eb2523aa98b8c09.png)

几件事印象很深：

**第一，选好数据模型比调 prompt 重要得多。** 英文和中文分开存再靠索引对齐——这个错误设计在第一天就让整条流水线不可用。改成 `{start, en, cn}` 成对存储后，后续一切顺畅。

**第二，不要相信模型生成的时间戳。** 多模态模型对"这句话在音频的第几秒"的估算不准是常态。百分比粗估 + ffmpeg 辅助 + 人工微调，三层兜底才堪用。

**第三，让 AI 写代码不等于你不用动脑。** agent 很能干，但它的判断有时有问题——把带行号的文件写回源码、时间戳不准还硬做精确匹配、CSS display 不起作用……都不是大问题，但你不指出它不会意识到。做这个项目的体验更像是**带一个水平不错但是偶尔会犯低级错误的新人**——你把方向指对，它的执行能力很强，但你得看着它。

**技术栈：**
- Hermes Agent（cron 调度 + 代码生成 + 文件操作）
- Deepseek V4 Pro（指挥官）
- MiMo v2.5 多模态模型（转录 + 翻译 + 词汇提取，一次调用）
- nginx（静态站点托管）
- Flask + SQLite（校正 API）
- ffmpeg（音频压缩 + 静音检测）
- 轻量应用服务器（2核4g）


我一直有在通勤路上听 Round Table China 这个播客的习惯，几个主持人用英语聊中国社会热点，口音地道，语速适中，很适合学英语磨耳朵。但有个问题：每期二三十分钟，没有字幕没有翻译（我找过有没有好心人翻译，找到了，但是好久没更新了），听完就忘了，想回头查某个表达根本找不到！这样其实属于无效听力输入！

我用 Hermes 建英语播客自动学习流水线

我一直有在通勤路上听 Round Table China 这个播客的习惯，几个主持人用英语聊中国社会热点，口音地道，语速适中，很适合学英语磨耳朵。于是我用 Hermes 建英语播客自动学习流水线

音视频

人工智能

后端

RoundTableChina播客自动化学习工具：通过Hermes调度MiMo进行每日自动转录翻译，生成双语字幕与重点词汇。采用分段存储优化token消耗，网页支持交互式字幕与时间戳校正，解决AI翻译错位与时间戳不准问题。基于腾讯云轻量服务器与Flask后端实现全流程自动化。

轻量应用服务器

语音助手

数据结构

服务器

SQLite

SaaS

4核4G3M云服务器 新用户低至38元/年！

lighthouse

语音产品特惠新用户14.9元起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我用 Hermes 建英语播客自动学习流水线-腾讯云开发者社区-腾讯云

我用 Hermes 建英语播客自动学习流水线

我用 Hermes 建英语播客自动学习流水线

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐