灵知系统 - 文字+音频双工程流开发计划

版本: v1.0.0 日期: 2026-03-31 基于: LingFlow双工程流系统 工程流: 文字处理 + 音频处理并行 目标: 28天完成双工程流集成

---

📊 执行摘要

当前状态

维度	状态	数据
版本	v1.3.0-dev	develop分支
文字处理进度	70%	TOC完成，检索部分完成
音频处理进度	0%	未开始
测试覆盖	29%	目标70%

双工程流策略

┌──────────────────────────────────────────────────────┐
│              灵知系统 - 双工程流架构                  │
├──────────────────────────────────────────────────────┤
│                                                      │
│  团队A: 文字处理工程流    团队B: 音频处理工程流       │
│  ┌──────────────────┐    ┌──────────────────┐       │
│  │ • 教材文本解析   │    │ • 音频转写(ASR)  │       │
│  │ • 向量嵌入生成   │    │ • Whisper集成    │       │
│  │ • 语义检索       │    │ • 音频标注       │       │
│  │ • RAG问答        │    │ • 语音指令       │       │
│  │ • 文本标注       │    │ • 节奏检测       │       │
│  └──────────────────┘    └──────────────────┘       │
│          ↓                         ↓                 │
│  [文字数据存储]            [音频数据存储]            │
│          └───────────┬───────────┘                  │
│                      ↓                              │
│           ┌──────────────────┐                      │
│           │  多模态协调器     │                      │
│           │  - 统一数据模型  │                      │
│           │  - 跨模态检索    │                      │
│           │  - 集成API       │                      │
│           └──────────────────┘                      │
│                      ↓                              │
│           [统一API → 用户]                          │
└──────────────────────────────────────────────────────┘

---

🎯 核心原则

双工程流三问

所有功能开发必须回答：

1. 哪个工程流？
2. 文字工程流（团队A）: 文本处理、检索、问答

3. 音频工程流（团队B）: 音频转写、标注、语音

4. 如何协作？

5. 独立开发各自的组件
6. 遵循统一的数据模型
7. 定期集成测试

8. 共享数据库和API

9. 何时集成？

10. 每周同步进度
11. Sprint结束时集成测试
12. 最终集成：统一API

---

📋 工程流定义

团队A: 文字处理工程流

负责人: Senior Dev x1 + ML Engineer x1 + Junior Dev x1

核心任务:

任务ID	任务	优先级	预计时间
A-1	文本解析和分块	P0	3天
A-2	向量嵌入生成	P0	2天
A-3	语义检索实现	P0	3天
A-4	RAG问答管道	P0	4天
A-5	文本标注系统	P1	3天
A-6	测试和文档	P1	3天
缓冲	意外问题	-	2天
总计	6项任务	-	20天

技术栈: - sentence-transformers (向量嵌入) - pgvector (向量数据库) - jieba (中文分词) - regex (模式匹配) - DeepSeek API (问答生成)

交付物: - ✅ 教材文本解析器 - ✅ 向量嵌入生成器 - ✅ 语义检索API - ✅ RAG问答API - ✅ 文本标注界面 - ✅ 测试覆盖率>70%

---

团队B: 音频处理工程流（离线转写）

负责人: Audio Engineer x1 + ML Engineer x1 + Backend Dev x1

核心任务: 参考阿里云听悟 - 录音文件识别

任务ID	任务	优先级	预计时间	说明
B-1	faster-whisper集成	P0	2天	转写引擎
B-2	音频上传和预处理	P0	2天	上传API
B-3	异步转写Worker	P0	3天	核心服务
B-4	长音频分段处理	P0	2天	支持12小时
B-5	转写结果查询	P0	2天	查询API
B-6	音频标注系统	P0	5天	标注API+UI
B-7	波形可视化+编辑器	P1	3天	前端界面
B-8	导出(TXT/SRT/标注)	P1	2天	多格式导出
B-9	向量化集成	P0	2天	跨模态检索
B-10	测试和文档	P1	3天	完整文档
缓冲	意外问题	-	2天	-
总计	10项任务	-	28天	-

技术栈: - faster-whisper (比原版快4倍) - pydub (音频预处理) - asyncio (异步处理) - Redis (任务队列) - WebSocket (实时推送)

交付物: - ✅ 离线音频转写服务（最长12小时） - ✅ 音频标注系统（6种标注类型） - ✅ 波形可视化+标注编辑器 - ✅ 转写结果编辑和导出 - ✅ 实时进度推送 - ✅ 与文字流集成（向量化） - ✅ 测试覆盖率>70%

核心功能: 1. 音频转写: - 支持音频格式：MP3, WAV, M4A - 最长12小时音频 - 最大2GB文件 - 异步处理，实时进度

1. 标注系统:
2. 文本校对（纠正ASR错误）
3. 段落标注（主题分类）
4. 重点标注（重要内容标记）
5. 知识关联（链接理论/实践）
6. 教学要点（标记要点/误区）

7. 时间戳笔记（添加笔记）

8. 导出功能:

9. TXT（纯文本）
10. SRT（字幕格式）
11. JSON（标注数据）
12. CSV（标注列表）

---

协调器: 多模态集成

负责人: 架构师 + DevOps

核心任务:

任务ID	任务	预计时间
C-1	统一数据模型设计	2天
C-2	跨模态检索API	3天
C-3	集成测试框架	2天
C-4	部署和监控	2天
总计	4项任务	9天

---

📅 开发时间线

阶段0: 准备阶段（2天）

目标: 环境准备、架构对齐

时间	团队A	团队B	协调器
Day 1	环境配置	环境配置	架构设计
Day 2	数据库设计	音频数据模型	接口定义

交付: - [x] 开发环境就绪 - [x] 数据库Schema确定 - [x] API接口规范文档

---

阶段1: 独立开发（14天，Day 3-16）

Sprint 1 (Day 3-9):

时间	团队A	团队B	同步活动
Day 3-5	A-1: 文本解析和分块	B-1: Whisper集成	每日站会
Day 6-7	A-2: 向量嵌入生成	B-2: 音频转写服务
Day 8-9	A-3: 语义检索实现	B-3: 音频数据模型	Sprint评审

Sprint 1交付: - 团队A: 文本可检索 - 团队B: 音频可转写 - 集成: 初步数据互通

Sprint 2 (Day 10-16):

时间	团队A	团队B	同步活动
Day 10-13	A-4: RAG问答管道	B-4: 音频标注界面	每日站会
Day 14-15	A-5: 文本标注系统	B-5: 语音指令识别
Day 16	集成测试	集成测试	Sprint评审

Sprint 2交付: - 团队A: 问答系统可用 - 团队B: 音频标注可用 - 集成: 端到端测试通过

---

阶段2: 集成和优化（7天，Day 17-23）

时间	团队A	团队B	协调器
Day 17-18	A-6: 测试和文档	B-6: 节奏检测	C-1: 统一数据模型
Day 19-20	优化和修复	B-7: 测试和文档	C-2: 跨模态检索
Day 21-22	集成测试	集成测试	C-3: 集成测试框架
Day 23	文档完善	文档完善	C-4: 部署准备

交付: - ✅ 双工程流完全集成 - ✅ 跨模态检索可用 - ✅ 测试覆盖率>70% - ✅ 文档完整

---

阶段3: 部署和验证（5天，Day 24-28)

时间	活动
Day 24-25	部署到测试环境
Day 26-27	完整测试（文字+音频）
Day 28	生产发布

---

🎯 成功标准

团队A成功标准

指标	目标	验收方式
文本解析准确率	>95%	自动测试
检索准确率	>75%	人工评估
问答准确率	>70%	用户测试
响应时间	<3秒	性能测试
测试覆盖	>70%	pytest --cov

团队B成功标准

指标	目标	验收方式
转写准确率 (WER)	<15%	评估集测试
转写速度	RTF<1	性能测试
标注效率	提升50%	用户反馈
音频播放延迟	<500ms	性能测试
测试覆盖	>70%	pytest --cov

集成成功标准

指标	目标	验收方式
跨模态检索准确率	>70%	集成测试
端到端响应时间	<5秒	E2E测试
系统稳定性	99% uptime	监控指标
用户满意度	>4.0/5.0	用户调查

---

🔄 协作机制

每日同步（10分钟站会）

时间: 每天 10:00 参与者: 全体开发人员

议程: 1. 昨天完成的工作 2. 今天的计划 3. 遇到的阻塞 4. 需要的协助

格式:

团队A:
- 昨天: 完成文本解析器
- 今天: 开始向量嵌入生成
- 阻塞: 无

团队B:
- 昨天: Whisper环境配置完成
- 今天: 实现转写服务
- 阻塞: GPU资源不足

协调器:
- 跟进: GPU资源已申请
- 通知: 数据库Schema已更新

每周集成（1小时会议）

时间: 每周五 16:00 参与者: Tech Lead + 团队代表

议程: 1. Sprint进度回顾 2. 集成测试结果 3. 接口变更讨论 4. 下周计划对齐

接口变更流程

流程:

提出变更 → 团队内部评审 → 影响分析 → 协调器审批 → 更新文档 → 通知对方团队

示例:

团队A: 修改了textbook_blocks表结构
  ↓
影响分析: 团队B的音频标注需要关联文本块
  ↓
协调器审批: 同意，更新API文档
  ↓
通知团队B: 音频标注界面需要适配新的textblock_id字段

---

📊 数据模型设计

统一数据模型

-- 文本数据（团队A负责）
CREATE TABLE textbook_blocks (
    id SERIAL PRIMARY KEY,
    textbook_id VARCHAR(100),
    chapter_id VARCHAR(100),
    content TEXT,
    embedding vector(1024),
    created_at TIMESTAMP DEFAULT NOW()
);

-- 音频数据（团队B负责）
CREATE TABLE audio_segments (
    id SERIAL PRIMARY KEY,
    textbook_id VARCHAR(100),
    audio_file_path VARCHAR(500),
    duration FLOAT,
    transcript TEXT,
    embedding vector(1024),  -- 转写文本的嵌入
    created_at TIMESTAMP DEFAULT NOW()
);

-- 跨模态关联（协调器负责）
CREATE TABLE multimodal_annotations (
    id SERIAL PRIMARY KEY,
    textbook_id VARCHAR(100),
    text_block_id INTEGER REFERENCES textbook_blocks(id),
    audio_segment_id INTEGER REFERENCES audio_segments(id),
    annotation_type VARCHAR(50),  -- 'alignment', 'highlight', 'note'
    annotation_data JSONB,
    created_by VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW()
);

-- 跨模态索引
CREATE INDEX idx_multimodal_text ON multimodal_annotations(text_block_id);
CREATE INDEX idx_multimodal_audio ON multimodal_annotations(audio_segment_id);
CREATE INDEX idx_multimodal_textbook ON multimodal_annotations(textbook_id);

API接口规范

文字检索API (团队A):

# backend/api/v1/text.py
@router.post("/search")
async def search_text(query: str, top_k: int = 5):
    """语义检索文本"""
    # 1. 生成查询向量
    # 2. 向量检索
    # 3. 返回结果
    pass

音频转写API (团队B):

# backend/api/v1/audio.py
@router.post("/transcribe")
async def transcribe_audio(audio_file: UploadFile):
    """音频转写"""
    # 1. 保存音频文件
    # 2. Whisper转写
    # 3. 保存到数据库
    # 4. 返回转写结果
    pass

跨模态检索API (协调器):

# backend/api/v1/multimodal.py
@router.post("/search")
async def search_multimodal(query: str, modalities: List[str] = ["text", "audio"]):
    """跨模态检索"""
    # 1. 文字检索（调用团队A的API）
    # 2. 音频检索（调用团队B的API）
    # 3. 结果融合（RRF或其他算法）
    # 4. 返回统一格式
    pass

---

⚠️ 风险与缓解

风险1: 数据模型不一致

风险: 两个团队独立设计数据模型，后期无法集成

缓解措施: - ✅ 阶段0统一设计数据库Schema - ✅ 使用SQLAlchemy ORM确保一致性 - ✅ 定期同步数据库变更 - ✅ 使用数据库迁移脚本

风险2: 接口变更冲突

风险: 一方修改API，另一方不知道，导致集成失败

缓解措施: - ✅ API接口规范文档（OpenAPI 3.0） - ✅ 接口变更必须通知对方 - ✅ 使用版本号管理API - ✅ 集成测试及早发现

风险3: 资源竞争

风险: GPU资源、开发环境冲突

缓解措施: - ✅ 使用Docker隔离环境 - ✅ GPU资源预约制 - ✅ 异步开发，减少耦合 - ✅ CI/CD自动测试

风险4: 进度不同步

风险: 一个团队快，另一个慢，影响集成

缓解措施: - ✅ 每周Sprint评审 - ✅ 灵活调整任务分配 - ✅ 关键路径优先 - ✅ 缓冲时间应对延期

---

📈 预期效果

效率提升

项目	单团队顺序开发	双团队并行开发	提升
文字处理	20天	20天	-
音频处理	20天	20天	-
集成测试	5天	5天	-
总周期	45天	28天	38% ⬇️

质量对比

质量维度	单团队	双团队
代码质量	7.5	8.5
测试覆盖	60%	70%
功能完整性	单模态	多模态
团队协作	-	优秀

---

📞 团队配置

团队A: 文字处理（3人）

角色	技能要求	职责
Senior Dev	Python, FastAPI, PostgreSQL	架构设计、代码审查
ML Engineer	NLP, sentence-transformers, RAG	向量检索、问答系统
Junior Dev	Python, SQL	文本解析、数据导入

最小配置: 2人 (Senior Dev + ML Engineer，Junior Dev可兼职)

团队B: 音频处理（3人）

角色	技能要求	职责
Audio Engineer	音频处理, Whisper, pydub	转写服务、音频处理
ML Engineer	PyTorch, 深度学习	模型优化、性能调优
Frontend Dev	HTML/CSS/JavaScript, Web Audio API	音频播放、标注界面

最小配置: 2人 (Audio Engineer + ML Engineer，Frontend Dev可兼职)

协调器（2人）

角色	技能要求	职责
架构师	系统设计, 数据建模	架构设计、技术决策
DevOps	Docker, CI/CD, 监控	部署、监控、运维

---

🚀 快速开始

第1天: 环境准备

团队A:

# 文字处理环境
cd backend
pip install sentence-transformers jieba regex psycopg2-binary

团队B:

# 音频处理环境
cd backend
pip install faster-whisper torch torchaudio av pydub

协调器:

# 数据库初始化
docker-compose up -d postgres
psql -U zhineng -d lingzhi_db < scripts/init_dual_workflow_db.sql

第2天: 数据模型创建

统一执行:

# 创建数据库表
psql -U zhineng -d lingzhi_db <<EOF
-- 文本表
CREATE TABLE textbook_blocks (...);

-- 音频表
CREATE TABLE audio_segments (...);

-- 跨模态关联表
CREATE TABLE multimodal_annotations (...);
EOF

第3天开始: 并行开发

团队A: 开始文本解析 团队B: 开始Whisper集成 协调器: 每日站会、每周集成

---

📚 相关文档

LingFlow文档

• MULTI_WORKFLOW_GUIDE.md
• MULTI_WORKFLOW_DESIGN.md

项目文档

• DEVELOPMENT_RULES.md - 编码规范
• ENGINEERING_ALIGNMENT.md - 工程对齐
• P0_PROGRESS_REPORT.md - 当前进度

---

✅ 下一步行动

立即执行 (本周)

1. 组建团队
2. 团队A: 3人（文字处理）
3. 团队B: 3人（音频处理）

4. 协调器: 2人

5. 环境准备

6. 开发环境配置
7. 数据库Schema设计

8. API接口规范文档

9. 启动会议

10. 对齐目标和时间线
11. 明确职责和分工
12. 建立沟通机制

下周执行

1. 开始Sprint 1
2. 团队A: 文本解析和向量生成
3. 团队B: Whisper集成和转写服务

4. 协调器: 数据模型和API规范

5. 建立同步机制

6. 每日站会（10:00）
7. 每周集成（周五）

---

文档状态: ✅ 准备就绪

版本: v1.0.0

日期: 2026-03-31

下一步: 组建团队，开始双工程流并行开发

众智混元，万法灵通 ⚡🚀