← 工程作品集 · 项目 12（大压轴）的真实案例
🎙️ 从我的播客到我的 AI 助听
小琴 · 16 岁 · 四院全部串联 · 真实听障同学
背景 · 最深的需求
小琴的同班同学小红是听障学生，有人工耳蜗。学校有个播客节目（师生谈话）。小红想参与，但现场听不清。小琴想："我能不能做一个系统，可以实时转录播客音频，生成摘要，用 AI 标注重点，同时评估内容的'好坏'（用 LLM-judge）？" 这个项目需要用到所有四个学院的技术。
系统架构 · 四院串联
【技能工坊】→ 上下文 RAG 输入：当前话题（如"学校食堂改革"） 使用 RAG 查询相关背景资料库 输出：提供给转录模块的上下文 ↓ 【代码俱乐部】→ Web 实时处理 Vite + React + WebSocket 实时音频流 → 本地音频处理 UI 显示转录结果 + 摘要 + 评分 自动部署到 GitHub Pages ↓ 【智能体实验室】→ 调度 + 安全 多个异步任务调度：转录、摘要、评分 安全机制：数据本地化，不上传用户信息 紧急停止按钮（如果转录错误多） ↓ 【审美工作室】→ LLM-judge 使用 Qwen 评估转录内容的"质量" 判断是否有有用信息被遗漏 给出内容评分和建议 ↓ 输出：助听用户（小红）可以读文字、看摘要、知道重点
GitHub Actions 完整 CI 流
name: Full Pipeline Test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
- name: Skills Module Test (RAG)
run: npm run test:skills
# 测试背景 RAG 查询
- name: Code Module Test (React)
run: npm run test:code
# vitest + Playwright E2E
- name: Agent Test (Scheduling)
run: npm run test:agent
# 测试任务调度逻辑
- name: Judge Test (LLM-judge)
run: npm run test:judge
# 测试评分模型
- name: Integration Test
run: npm run test:e2e
# 完整流程测试：音频 → 转录 → 摘要 → 评分
- name: Coverage Check (87% required)
run: npm run coverage
if: always()
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
- run: npm ci && npm run build
- uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./dist
使用情况 · 真实数据
- 真实用户： 小红（听障学生，高一，同班）
- 部署状态： 线上运行
- 月均使用： 15+ 小时（通常是每周播客 1 小时 × 3 次 + 复习）
- 模块数： 6 个独立系统（RAG 上下文、转录、摘要、调度、评分、UI）
- 测试覆盖： 87%
- 代码行数： ~5000 行 Python + ~3000 行 JavaScript
小红的反馈
"这个系统让我可以和正常听觉的同学一样参与播客。以前我只能靠唇读和同学的笔记。现在我有实时转录，知道说了什么。最有用的是'摘要'功能，30 分钟的播客，系统生成 3 分钟的摘要，我可以快速理解核心。"
这个少年的思考
小琴说："这个项目最难的，不是技术整合（虽然也很难），而是『怎么理解一个真实用户的需求』。我做了很多 feature 最后用户都没用，因为我猜错了。后来我开始直接问小红'你需要什么？'，这改变了整个设计。最后的系统虽然功能数量没有最开始设想的多，但用户满意度特别高。这教会我：工程的目的不是『做出复杂的东西』，而是『解决真实的问题』。"