26 KiB

Raw Blame History

iMeeting 产品路线图

项目概述

iMeeting 是一个智能会议管理和知识库系统，旨在通过 AI 技术提升会议效率，自动生成会议纪要，并从多次会议中提炼知识。

Phase 1: 基础会议管理与知识库系统（已完成）

核心功能

1. 会议管理

会议创建与录音：支持创建会议并关联音频文件
音频转录：基于阿里云 DashScope 的语音识别，支持异步转录
AI 总结生成：使用大语言模型（通义千问）自动生成会议纪要
提示词模版：支持预定义和自定义提示词模版，适配不同会议场景
标签系统：支持为会议添加标签，方便分类和检索

2. 知识库系统

基于会议的知识提炼：从多个会议纪要中提炼知识库内容
自定义提示词：用户可以指定特定的分析角度和总结需求
Markdown 输出：知识库内容以 Markdown 格式存储和展示
标签关联：支持知识库的标签分类
共享机制：支持知识库的个人/共享模式

3. 用户权限管理

用户认证：基于 JWT 的用户登录与会话管理
角色权限：区分普通用户和管理员
菜单权限：动态菜单权限控制系统

4. 管理后台

用户管理：用户创建、编辑、删除、权限配置
系统监控：在线用户、任务监控、系统资源监控
提示词仓库：集中管理所有提示词模版

技术架构

后端技术栈

框架：FastAPI（Python）
数据库：MySQL 8.0
缓存：Redis 5.0+
AI 服务：阿里云 DashScope（通义千问）
对象存储：七牛云 OSS
异步任务：FastAPI BackgroundTasks

前端技术栈

框架：React 18
路由：React Router
UI 组件：Ant Design + 自定义组件
Markdown 渲染：react-markdown

数据模型（核心表）

users：用户表
meetings：会议表
knowledge_bases：知识库表
prompts：提示词模版表
transcription_tasks：转录任务表
summary_tasks：总结任务表
knowledge_base_tasks：知识库生成任务表
tags：标签表

Phase 2: 知识库系统大升级（规划中）

升级目标

将知识库系统从单一的"会议纪要汇总"升级为功能完整的"AI 知识助手"，参考 NotebookLM 的交互模式，提供多维度的知识管理和音频播客生成能力。

1. 输入来源扩展

1.1 功能需求

✅ 会议来源（已支持）：从多个会议纪要中提炼
🆕 外部文件上传：
- 支持 PDF、Word、TXT、Markdown 文件
- 支持音频文件（MP3、WAV、M4A）
- 支持视频文件（MP4、AVI、MOV）提取音频
- 单个知识库可混合多种来源

1.2 技术方案

文档解析

# 依赖库选型
- PDF: PyPDF2 / pdfplumber（文本提取）
- Word: python-docx（DOCX 文件）
- Markdown: 直接读取
- TXT: 直接读取，支持多种编码（UTF-8、GBK）

技术评估：

✅ 可行性：高，Python 生态成熟
⚠️ 挑战：
- PDF 中的表格、图片识别（可选用 OCR）
- 大文件处理（需要分块上传和处理）
💰 成本：无额外费用，依赖开源库

音频/视频处理

# 依赖库选型
- 音频提取: ffmpeg-python（视频转音频）
- 音频格式转换: pydub

技术评估：

✅ 可行性：高，现有转录流程可复用
⚠️ 挑战：
- 视频文件较大，需要优化存储和处理
- 需要增加进度反馈
💰 成本：
- 视频存储成本增加（七牛云存储费用）
- 转录费用与现有一致（按时长计费）

数据库设计

-- 新增表：知识库来源文件表
CREATE TABLE kb_source_files (
  file_id INT AUTO_INCREMENT PRIMARY KEY,
  kb_id INT NOT NULL COMMENT '关联的知识库ID',
  file_type ENUM('pdf', 'docx', 'txt', 'markdown', 'audio', 'video') NOT NULL,
  file_name VARCHAR(255) NOT NULL,
  file_url VARCHAR(512) NOT NULL COMMENT '文件存储URL',
  file_size BIGINT COMMENT '文件大小（字节）',
  extracted_text TEXT COMMENT '提取的文本内容',
  upload_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (kb_id) REFERENCES knowledge_bases(kb_id) ON DELETE CASCADE
);

-- 修改知识库表
ALTER TABLE knowledge_bases
ADD COLUMN source_type ENUM('meetings', 'files', 'mixed') DEFAULT 'meetings' COMMENT '内容来源类型';

2. 提示词模版升级

2.1 功能需求

✅ 选择模版（已支持）：从提示词仓库选择预设模版
🆕 附加提示词：在模版基础上追加自定义需求
🆕 结构化输出：生成标题 + 多级内容（章节、小节）
🆕 输出格式控制：支持指定输出结构（JSON Schema）

2.2 技术方案

提示词组合

def build_knowledge_prompt(
    template_prompt: str,      # 基础模版
    additional_prompt: str,    # 附加提示词
    output_format: dict        # 输出格式控制
) -> str:
    """
    组合提示词策略：
    1. 基础模版（定义分析维度和风格）
    2. 附加提示词（用户自定义需求）
    3. 输出格式要求（结构化 JSON 或 Markdown）
    """
    return f"""
{template_prompt}

## 用户补充要求
{additional_prompt}

## 输出格式要求
请按照以下结构输出（Markdown 格式）：
# 标题
## 章节1
### 小节1.1
内容...
### 小节1.2
内容...
## 章节2
...
"""

技术评估：

✅ 可行性：高，现有提示词系统可直接扩展
📊 优化方向：
- 使用通义千问的 response_format 参数实现结构化输出
- 提供可视化的输出结构编辑器
💰 成本：无额外成本

结构化输出（通义千问支持）

# 通义千问支持 JSON Schema 格式控制
response_format = {
    "type": "json_schema",
    "json_schema": {
        "name": "knowledge_base_output",
        "schema": {
            "type": "object",
            "properties": {
                "title": {"type": "string"},
                "sections": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "section_title": {"type": "string"},
                            "subsections": {
                                "type": "array",
                                "items": {
                                    "type": "object",
                                    "properties": {
                                        "subsection_title": {"type": "string"},
                                        "content": {"type": "string"}
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

3. 音频概览生成（TTS 播客）

3.1 功能需求

🆕 文字转语音：将知识库内容转换为音频
🆕 播客式对话（类似 NotebookLM）：
- 双人对话形式（主持人 + 嘉宾）
- 自然的问答式讲解
- 语气生动，易于理解

3.2 技术方案

方案一：基础 TTS（快速实现）

服务选型：

# 1. 阿里云语音合成（推荐）
- 优势：已集成 DashScope，音质自然，支持多音色
- 成本：约 0.002 元/次（100字符）
- 特性：支持 SSML 标签控制语速、停顿

# 2. 微软 Azure TTS
- 优势：音质最佳，支持神经网络语音
- 成本：约 $4/百万字符
- 特性：支持情感控制、多语言

# 3. OpenAI TTS
- 优势：音质优秀，与 GPT 集成度高
- 成本：约 $15/百万字符
- 特性：6 种不同音色可选

实现流程：

async def generate_basic_audio(kb_content: str) -> str:
    """
    基础 TTS 实现
    1. 文本预处理（分段、去除特殊字符）
    2. 调用 TTS API
    3. 音频文件合并
    4. 上传到七牛云
    """
    # 分段处理（避免单次请求过长）
    segments = split_text_by_paragraphs(kb_content, max_length=500)

    audio_files = []
    for segment in segments:
        audio = await tts_service.synthesize(
            text=segment,
            voice="zhichu",  # 阿里云音色
            rate=1.0,        # 语速
            pitch=0          # 音调
        )
        audio_files.append(audio)

    # 合并音频
    final_audio = merge_audio_files(audio_files)
    audio_url = upload_to_qiniu(final_audio, "kb_audio")

    return audio_url

技术评估：

✅ 可行性：高，实现简单
⚠️ 局限性：
- 单调朗读，无对话感
- 缺乏停顿和情感
💰 成本：
- 阿里云 TTS：约 0.02 元/千字
- 10 万字知识库：约 2 元/次

方案二：播客式对话（NotebookLM 风格）

技术架构：

输入: 知识库内容 (Markdown)
  ↓
1. 内容理解与脚本生成
  - 使用 LLM 将内容改写为对话脚本
  - 双人角色：主持人（引导）+ 专家（讲解）
  ↓
2. 对话脚本优化
  - 添加开场白和结束语
  - 插入自然的停顿和过渡
  - 添加情感标记（SSML）
  ↓
3. 多音色 TTS 合成
  - 主持人音色：女声，温和亲切
  - 专家音色：男声，稳重专业
  ↓
4. 音频后处理
  - 添加背景音乐（轻音乐）
  - 音量均衡化
  - 添加片头片尾
  ↓
输出: 播客式音频文件 (MP3)

LLM 脚本生成示例：

PODCAST_SCRIPT_PROMPT = """
你是一个播客制作专家。请将以下知识库内容改写为一段双人对话脚本：
- 主持人（Host）：提出问题，引导话题，语气轻松友好
- 专家（Expert）：讲解内容，回答问题，语气专业自信

要求：
1. 开场白介绍今天的主题
2. 通过问答形式逐步展开知识点
3. 加入自然的过渡语（"那么..."、"接下来..."）
4. 结束时做简短总结

知识库内容：
{kb_content}

请输出 JSON 格式：
{{
  "title": "播客标题",
  "intro": {{
    "host": "开场白...",
    "expert": "回应..."
  }},
  "dialogues": [
    {{"speaker": "host", "text": "问题1..."}},
    {{"speaker": "expert", "text": "解答1..."}},
    ...
  ],
  "outro": {{
    "host": "总结...",
    "expert": "结束语..."
  }}
}}
"""

async def generate_podcast_script(kb_content: str) -> dict:
    """使用 LLM 生成播客脚本"""
    response = await llm_service.call(
        prompt=PODCAST_SCRIPT_PROMPT.format(kb_content=kb_content),
        response_format={"type": "json_object"}
    )
    return json.loads(response)

async def synthesize_podcast(script: dict) -> str:
    """合成播客音频"""
    audio_segments = []

    # 片头音乐
    audio_segments.append(load_intro_music())

    # 开场白
    for speaker, text in script["intro"].items():
        voice = VOICES[speaker]  # {"host": "xiaoyun", "expert": "zhichu"}
        audio = await tts_service.synthesize(text, voice=voice)
        audio_segments.append(audio)
        audio_segments.append(silence(duration=0.5))  # 停顿 0.5 秒

    # 主体对话
    for dialogue in script["dialogues"]:
        speaker = dialogue["speaker"]
        text = dialogue["text"]
        voice = VOICES[speaker]
        audio = await tts_service.synthesize(text, voice=voice)
        audio_segments.append(audio)
        audio_segments.append(silence(duration=0.3))

    # 结束语
    for speaker, text in script["outro"].items():
        voice = VOICES[speaker]
        audio = await tts_service.synthesize(text, voice=voice)
        audio_segments.append(audio)

    # 片尾音乐
    audio_segments.append(load_outro_music())

    # 合并所有音频
    final_audio = merge_with_background_music(audio_segments)

    # 上传到七牛云
    audio_url = upload_to_qiniu(final_audio, "kb_podcast")
    return audio_url

技术评估：

✅ 可行性：中等
- LLM 脚本生成：成熟方案
- 多音色 TTS：阿里云、Azure 均支持
- 音频后处理：需要 ffmpeg 或 pydub
⚠️ 挑战：
- 脚本质量依赖 LLM prompt 优化
- 音频合成时长较长（需要异步处理）
- 音频文件较大，存储成本增加
💰 成本（以 5000 字知识库为例）：
- LLM 脚本生成（输入 5000 字 + 输出 3000 字）：约 0.05 元
- TTS 合成（约 3000 字对话）：约 0.06 元
- 总成本：约 0.11 元/次

音频处理库：

# 新增依赖
ffmpeg-python==0.2.0  # 音频处理
pydub==0.25.1         # 音频编辑

方案对比

特性	方案一：基础 TTS	方案二：播客对话
实现难度	低（1-2 天）	中（3-5 天）
音频质量	单调朗读	自然对话
用户体验	⭐⭐⭐	⭐⭐⭐⭐⭐
成本	0.02 元/千字	0.11 元/5000 字
适用场景	快速阅读	深度学习

推荐方案：

🚀 Phase 2.1：先实现方案一（基础 TTS），快速上线
🎯 Phase 2.2：再实现方案二（播客对话），提升体验

4. NotebookLM 式交互

4.1 功能需求

🆕 知识库问答：基于知识库内容的智能问答
🆕 引用溯源：回答时显示来源（段落、页码）
🆕 相关内容推荐：基于用户提问推荐相关知识点
🆕 多轮对话：支持上下文记忆的连续对话

4.2 技术方案

方案一：基于向量数据库的 RAG（推荐）

技术架构：

知识库内容
  ↓
1. 文本分块 (Chunking)
  - 按段落或语义分块（500-1000 字/块）
  - 保留元数据（来源、章节、页码）
  ↓
2. 向量化 (Embedding)
  - 使用阿里云通义千问 Embedding API
  - 或使用 OpenAI text-embedding-3-small
  ↓
3. 存储到向量数据库
  - Milvus（开源，功能强大）
  - 或 Qdrant（轻量，易部署）
  - 或 PostgreSQL + pgvector（复用现有数据库）
  ↓
4. 用户提问
  ↓
5. 向量检索
  - 将问题向量化
  - 检索 Top-K 相似内容块
  ↓
6. LLM 生成回答
  - 将检索结果作为上下文
  - 生成准确回答 + 来源引用

实现示例：

from dashscope import TextEmbedding
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

# 1. 向量化服务
class EmbeddingService:
    def embed_text(self, text: str) -> List[float]:
        """将文本转换为向量"""
        response = TextEmbedding.call(
            model='text-embedding-v3',
            input=text
        )
        return response.output['embeddings'][0]['embedding']

# 2. 向量数据库
class VectorStore:
    def __init__(self):
        self.client = QdrantClient(host="localhost", port=6333)

    def create_collection(self, kb_id: int):
        """为知识库创建向量集合"""
        self.client.create_collection(
            collection_name=f"kb_{kb_id}",
            vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
        )

    def add_chunks(self, kb_id: int, chunks: List[dict]):
        """添加文本块到向量库"""
        points = []
        for i, chunk in enumerate(chunks):
            embedding = embedding_service.embed_text(chunk['text'])
            points.append(PointStruct(
                id=i,
                vector=embedding,
                payload={
                    "text": chunk['text'],
                    "source": chunk['source'],
                    "section": chunk['section']
                }
            ))
        self.client.upsert(collection_name=f"kb_{kb_id}", points=points)

    def search(self, kb_id: int, query: str, top_k: int = 3):
        """搜索相似内容"""
        query_vector = embedding_service.embed_text(query)
        results = self.client.search(
            collection_name=f"kb_{kb_id}",
            query_vector=query_vector,
            limit=top_k
        )
        return results

# 3. RAG 问答
async def answer_question(kb_id: int, question: str, chat_history: List[dict] = None):
    """基于知识库回答问题"""
    # 检索相关内容
    results = vector_store.search(kb_id, question, top_k=3)

    # 构建上下文
    context = "\n\n".join([
        f"[来源: {r.payload['section']}]\n{r.payload['text']}"
        for r in results
    ])

    # 构建 prompt
    prompt = f"""
基于以下知识库内容回答用户问题。如果无法从内容中找到答案，请明确告知。

知识库内容：
{context}

用户问题：{question}

请提供准确的回答，并在回答中标注来源章节。
"""

    # 调用 LLM
    response = await llm_service.call(prompt, chat_history=chat_history)

    # 返回回答 + 来源
    return {
        "answer": response,
        "sources": [
            {"section": r.payload['section'], "text": r.payload['text'][:200]}
            for r in results
        ]
    }

技术评估：

✅ 可行性：高
- 向量数据库：Qdrant（轻量级）或 pgvector（复用 MySQL）
- Embedding：阿里云通义千问 Embedding API（0.0007 元/千 tokens）
📊 优势：
- 回答准确性高（基于实际内容）
- 支持引用溯源
- 检索速度快（毫秒级）
💰 成本（以 10 万字知识库为例）：
- 向量化：约 0.07 元（一次性）
- 每次问答检索：免费（本地向量库）
- LLM 生成：约 0.01 元/次

方案二：基于 LLM 长上下文（备选）

技术方案：

async def answer_with_full_context(kb_content: str, question: str):
    """直接将整个知识库作为上下文"""
    prompt = f"""
你是一个知识库助手。请基于以下知识库内容回答用户问题。

知识库内容：
{kb_content}

用户问题：{question}

请提供准确的回答，并标注引用的段落。
"""
    response = await llm_service.call(prompt)
    return response

技术评估：

✅ 可行性：中等
- 通义千问支持 128K tokens 上下文
- 约 10 万字中文
⚠️ 局限性：
- 大文本上下文成本高
- 无法精确定位来源
- 不支持多知识库联合查询
💰 成本：
- 每次问答（10 万字上下文）：约 0.15 元
- 比 RAG 方案贵 10 倍以上

推荐方案：方案一（RAG） 为主，方案二作为小规模知识库的快速方案。

数据库设计

-- 知识库对话历史表
CREATE TABLE kb_chat_history (
  chat_id INT AUTO_INCREMENT PRIMARY KEY,
  kb_id INT NOT NULL COMMENT '关联知识库ID',
  user_id INT NOT NULL COMMENT '用户ID',
  question TEXT NOT NULL COMMENT '用户提问',
  answer TEXT NOT NULL COMMENT 'AI回答',
  sources JSON COMMENT '回答来源（JSON数组）',
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (kb_id) REFERENCES knowledge_bases(kb_id) ON DELETE CASCADE,
  FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE,
  INDEX idx_kb_user (kb_id, user_id),
  INDEX idx_created_at (created_at)
);

-- 知识库向量块表
CREATE TABLE kb_text_chunks (
  chunk_id INT AUTO_INCREMENT PRIMARY KEY,
  kb_id INT NOT NULL COMMENT '关联知识库ID',
  chunk_text TEXT NOT NULL COMMENT '文本块内容',
  chunk_metadata JSON COMMENT '元数据（章节、页码等）',
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (kb_id) REFERENCES knowledge_bases(kb_id) ON DELETE CASCADE,
  INDEX idx_kb_id (kb_id)
);

5. 前端交互升级

5.1 新增页面/组件

知识库详情页
├── 📄 内容展示区
│   ├── Markdown 渲染（已有）
│   └── 音频播放器（新增）
│       ├── 播放/暂停
│       ├── 进度条
│       ├── 倍速调节
│       └── 下载音频
│
├── 💬 智能问答区（新增）
│   ├── 对话输入框
│   ├── 对话历史列表
│   ├── 来源引用卡片
│   └── 相关问题推荐
│
└── 📊 知识库信息
    ├── 来源文件列表（新增）
    └── 标签、创建时间等（已有）

5.2 技术实现

// 音频播放器组件
import ReactAudioPlayer from 'react-audio-player';

const KnowledgeAudioPlayer = ({ audioUrl }) => {
  return (
    <div className="audio-player-container">
      <h3>🎧 音频概览</h3>
      <ReactAudioPlayer
        src={audioUrl}
        controls
        autoPlay={false}
        controlsList="nodownload"
      />
    </div>
  );
};

// 智能问答组件
const KnowledgeChatbot = ({ kbId }) => {
  const [messages, setMessages] = useState([]);
  const [input, setInput] = useState('');
  const [loading, setLoading] = useState(false);

  const handleAsk = async () => {
    setLoading(true);
    const response = await apiClient.post(`/knowledge-bases/${kbId}/ask`, {
      question: input,
      chat_history: messages
    });

    setMessages([
      ...messages,
      { role: 'user', content: input },
      {
        role: 'assistant',
        content: response.data.answer,
        sources: response.data.sources
      }
    ]);
    setInput('');
    setLoading(false);
  };

  return (
    <div className="chatbot-container">
      <div className="chat-history">
        {messages.map((msg, idx) => (
          <div key={idx} className={`message ${msg.role}`}>
            <div className="message-content">{msg.content}</div>
            {msg.sources && (
              <div className="message-sources">
                <h4>📚 来源</h4>
                {msg.sources.map((src, i) => (
                  <div key={i} className="source-card">
                    <strong>{src.section}</strong>
                    <p>{src.text}...</p>
                  </div>
                ))}
              </div>
            )}
          </div>
        ))}
      </div>
      <div className="chat-input">
        <input
          value={input}
          onChange={(e) => setInput(e.target.value)}
          placeholder="向知识库提问..."
          onKeyPress={(e) => e.key === 'Enter' && handleAsk()}
        />
        <button onClick={handleAsk} disabled={loading}>
          {loading ? '思考中...' : '发送'}
        </button>
      </div>
    </div>
  );
};

Phase 2 技术依赖汇总

新增 Python 依赖

# 文档解析
PyPDF2==3.0.1
pdfplumber==0.10.3
python-docx==1.1.0

# 音频处理
ffmpeg-python==0.2.0
pydub==0.25.1

# 向量数据库（二选一）
qdrant-client==1.7.0          # 推荐：轻量级向量库
# 或
pgvector==0.2.3               # 备选：PostgreSQL 扩展

# 阿里云 Embedding（可选，通义千问已集成）
# 无需新增依赖，使用现有 dashscope

新增前端依赖

{
  "react-audio-player": "^0.17.0",
  "react-markdown": "^9.0.0"  // 已有
}

基础设施

向量数据库：Qdrant（Docker 部署）
```
docker run -p 6333:6333 qdrant/qdrant
```

音频处理：FFmpeg（系统依赖）

apt-get install ffmpeg  # Ubuntu
brew install ffmpeg     # macOS

成本预估（Phase 2）

开发成本

模块	工作量（人天）	说明
文件上传与解析	3-5 天	PDF、Word、音频解析
提示词升级	2-3 天	附加提示词、结构化输出
基础 TTS	2-3 天	文字转语音
播客对话（可选）	5-7 天	LLM 脚本生成 + 多音色合成
RAG 问答系统	5-7 天	向量化、检索、对话
前端交互升级	3-5 天	音频播放器、聊天界面
总计	20-30 天	约 1-1.5 个月

运营成本（月）

项目	预估用量	单价	月成本
阿里云 TTS	100 万字	0.02 元/千字	20 元
LLM 脚本生成	50 次（5000 字/次）	0.05 元/次	2.5 元
Embedding 向量化	100 万字	0.0007 元/千 tokens	0.7 元
LLM 问答	1000 次	0.01 元/次	10 元
七牛云存储（音频）	10 GB	0.148 元/GB/天	44 元
Qdrant 服务器	1 核 2G	-	0 元（自建）
总计	-	-	约 77 元/月

注：基于中小规模使用场景（月活 100-500 用户）

技术风险与缓解措施

风险 1：向量数据库性能

风险：大规模知识库检索延迟
缓解：
- 使用 Qdrant 的分片和副本
- 限制单次检索 Top-K 数量
- 增加缓存层（Redis）

风险 2：播客生成质量

风险：LLM 生成的对话脚本不自然
缓解：
- 提供多个脚本模版供用户选择
- 支持用户编辑脚本后再合成
- 引入少样本学习（Few-shot）优化 prompt

风险 3：文件解析准确性

风险：PDF、Word 解析失败或乱码
缓解：
- 提供预览功能，让用户确认提取结果
- 支持手动文本粘贴作为备选
- 增加 OCR 处理扫描件 PDF

风险 4：成本控制

风险：TTS 和 LLM 调用费用超预算
缓解：
- 设置单用户每日调用限额
- 音频生成采用队列异步处理
- 提供缓存机制避免重复生成

实施建议

Phase 2.1（基础版，2-3 周）

✅ 优先级高

文件上传与解析（PDF、Word、TXT）
基础 TTS 音频生成
提示词附加功能

Phase 2.2（进阶版，3-4 周）

🎯 优先级中

RAG 问答系统（向量检索）
播客式对话生成
前端聊天界面

Phase 2.3（优化版，2-3 周）

🔧 优先级低

音频后处理（背景音乐、片头片尾）
多轮对话记忆
相关问题推荐

总结

Phase 2 升级将把 iMeeting 知识库系统从"被动阅读"升级为"主动交互"，核心亮点包括：

✅ 多源输入：会议 + 文件 + 音视频
🎙️ 音频播客：类 NotebookLM 的对话式音频
💬 智能问答：基于 RAG 的精准问答
📊 结构化输出：自动生成多级章节

技术可行性：高（基于成熟技术栈） 成本可控性：高（月运营成本 < 100 元） 开发周期：1-1.5 个月（20-30 人天）

建议采用分阶段迭代方式，先上线基础版（文件上传 + 基础 TTS），快速验证用户需求，再逐步完善高级功能（播客对话 + RAG 问答）。

26 KiB Raw Blame History Unescape Escape

iMeeting 产品路线图

项目概述

Phase 1: 基础会议管理与知识库系统（已完成）

核心功能

1. 会议管理

2. 知识库系统

3. 用户权限管理

4. 管理后台

技术架构

后端技术栈

前端技术栈

数据模型（核心表）

Phase 2: 知识库系统大升级（规划中）

升级目标

1. 输入来源扩展

1.1 功能需求

1.2 技术方案

文档解析

音频/视频处理

数据库设计

2. 提示词模版升级

2.1 功能需求

2.2 技术方案

提示词组合

结构化输出（通义千问支持）

3. 音频概览生成（TTS 播客）

3.1 功能需求

3.2 技术方案

方案一：基础 TTS（快速实现）

方案二：播客式对话（NotebookLM 风格）

方案对比

4. NotebookLM 式交互

4.1 功能需求

4.2 技术方案

方案一：基于向量数据库的 RAG（推荐）

方案二：基于 LLM 长上下文（备选）

数据库设计

5. 前端交互升级

5.1 新增页面/组件

5.2 技术实现

Phase 2 技术依赖汇总

新增 Python 依赖

新增前端依赖

基础设施

成本预估（Phase 2）

开发成本

运营成本（月）

技术风险与缓解措施

风险 1：向量数据库性能

风险 2：播客生成质量

风险 3：文件解析准确性

风险 4：成本控制

实施建议

Phase 2.1（基础版，2-3 周）

Phase 2.2（进阶版，3-4 周）

Phase 2.3（优化版，2-3 周）

总结

26 KiB

Raw Blame History