forked from new_org/Project-Caffeine
140 lines
9.4 KiB
Markdown
140 lines
9.4 KiB
Markdown
<!--
|
||
---
|
||
title: "Project Caffeine MVP 开发路线图"
|
||
description: "基于敏捷迭代原则的 Project Caffeine 系统五阶段开发规划与核心设计蓝图"
|
||
type: "Roadmap"
|
||
file: "project-caffeine-mvp-development-roadmap.md"
|
||
version: "V0.1.0"
|
||
author: "Gitconomy Research-郭晧"
|
||
date: 2026-02-28
|
||
tags:
|
||
- Project Caffeine
|
||
- MCP
|
||
- MVP
|
||
- 开发路线图
|
||
- Deep Research
|
||
- PKM
|
||
license: "CC BY-SA 4.0"
|
||
status: "Active"
|
||
---
|
||
-->
|
||
# Project Caffeine MVP 开发路线图
|
||
|
||
## 1. 开发路线图概述
|
||
|
||
本系统的开发将遵循“敏捷迭代、核心优先、由浅入深”的研发原则。为了确保开发过程的稳健性，整个生命周期被划分为五个渐进式阶段，从最基础的物理检索链路起步，逐步叠加思维框架、递归推理算法，最终实现与本地个人知识库的完美融合。每个阶段均能独立跑通并产出具备核心价值的最小可行性产品（MVP）。
|
||
|
||
---
|
||
|
||
## 2. 设计阶段规划
|
||
|
||
在正式启动编码前，需用 1 周时间完成从产品需求到技术实现的图纸转化。此阶段需产出以下 **5 份核心设计文档**，作为后续所有开发的唯一事实依据：
|
||
|
||
| 序号 | 核心设计文档名称 | 核心内容 | 输出价值 |
|
||
| :---- | :---------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------ |
|
||
| **1** | 《系统总体架构和开发框架设计》<br> | 确定三大 MCP Server（执行者、军师、分析师）的开发语言（如 TypeScript vs. Python）。确定底层依赖组件：如网页抓取库、文本切块算法库。系统部署拓扑图规划。 | 统一团队技术栈，明确性能边界，避免后期因组件不兼容导致的大规模重构。 |
|
||
| **2** | 《MCP 接口契约与 API 规范文档 (API Contract)》 | 基于 JSON-RPC 2.0 规范，详细定义所有 Tools（如 `search_academic_literature`）、Prompts（如 `analyze_via_scqa`）和 Resources 的出入参 JSON Schema。定义全局错误码（如 API 限流、Token 超载、抓取失败）及异常抛出机制。 | 由于系统是解耦的微服务，这份契约能让 S1、S2、S3 的开发人员以及前端/客户端联调人员实现完全的并行开发。 |
|
||
| **3** | 《递归深度研究核心算法与状态机设计》 | 设计深研状态机（Deep Research State Machine）：明确大模型在“检索 -> 切块 -> 提取 -> 评估盲区 -> 追问”循环中的状态流转图。定义“探索账本（Exploration State）”的数据结构，设计布隆过滤器或哈希去重逻辑，严防大模型陷入检索死循环。制定长文本“Token 感知语义切块（Semantic Chunking）”的具体策略与重叠率标准。 | 这是本系统最硬核的算法底座，决定了系统能否真正被称为“AI 研究员”而不是单纯的“搜索外挂”。 |
|
||
| **4** | 《大模型提示词工程与角色矩阵规范 》 | 详细设计并固化系统所需的所有底层 Prompt 模板（5W3H、SCQA、5 Whys、PESTLE 等）。建立**多智能体角色矩阵 (Persona Matrix)**：为“检索策略专家”、“洞察提取研究员”、“战略分析顾问”等角色撰写精确的 System Prompts。定义大模型的输出结构约束（如强制 Markdown 格式、强制引用溯源标记的 Few-Shot 示例）。 | 确保大模型的输出质量稳定、格式统一、逻辑严密，降低大模型的幻觉率。 |
|
||
| **5** | 《双轨制数据结构与 PKM 集成白皮书 》 | 设计系统内部流转的 JSON 数据结构规范。设计最终落盘的 Markdown 模板与 YAML Frontmatter 元数据字典（需列出所有支持的键值对，如 `title`, `citation_density_check`, `research_depth_level`）。梳理与 Obsidian/Logseq 等工具联动的双向链接（`[[...]]`）自动生成策略。 | 保障用户最终获得的本地知识图谱干净、可检索且具备高可扩展性。 |
|
||
|
||
---
|
||
|
||
## 3. 开发阶段规划
|
||
|
||
### 3.1 阶段 1：基础设施与单点能力验证 (MVP 阶段)
|
||
|
||
1. **目标**：搭建底层 MCP 框架，跑通“检索 -> 落盘”的基础物理链路。
|
||
|
||
2. **预计周期**：1 周
|
||
|
||
3. **S1 (文献查询 Server) 核心开发**：
|
||
|
||
- 初始化 MCP Server 环境（基于 Node.js）。
|
||
- 集成至少 2 个核心学术 API（如 arXiv API、Semantic Scholar API），实现基础的 `search_academic_literature` 工具。
|
||
- 开发双轨制数据落盘模块 `save_to_local_vault`，实现 JSON 到 Markdown + YAML Frontmatter 的自动转换。
|
||
|
||
4. **客户端联调测试**：将 S1 接入 Cherry Studio，测试大模型能否通过对话触发搜索，并成功在本地 Obsidian 目录生成标准 `.md` 文件。
|
||
|
||
- **🎯 里程碑成果**：系统拥有了“手”和“脚”，能帮用户查文献并规范化存入本地。
|
||
|
||
### 3.2 阶段 2：思维框架与单次分析闭环 (思维引擎组装)
|
||
|
||
1. **目标**：上线 S2 和 S3，打通“意图拆解 -> 检索 -> 框架分析 -> 落盘”的**单轮（非递归）**工作流。
|
||
|
||
2. **预计周期**：1 周
|
||
|
||
3. **S2 (提示词策略 Server) 核心开发**：
|
||
|
||
- 注册 Prompts 原语，写入 5W3H、SCQA、SWOT 等静态思维框架模板。
|
||
- 开发 `generate_search_queries` 工具，让大模型能将用户的“大白话”拆解为 3-5 个专业检索词（实现 Breadth 广度解析）。
|
||
|
||
4. **S3 (CoT多步推理 Server) 核心开发**：开发 `cot_literature_synthesis` 核心提示词模板，规范大模型的输出结构（摘要、引言、主体等）。
|
||
|
||
5. **S1 (文献查询 Server) 能力扩充**：开发 `fetch_and_split_document`：引入文本切块（Semantic Chunking）算法，解决长篇 PDF 解析导致的 Token 超限问题。
|
||
|
||
- **🎯 里程碑成果**：用户输入问题，系统能自动拆解关键词、并发检索多篇文献，并基于 SCQA 框架生成一份基础报告存入本地。
|
||
|
||
### 3.3 阶段 3：递归深挖引擎的核心攻坚 (Deep Research 模式)
|
||
|
||
1. **目标**：实现系统最具价值的“自主探索与深度递归”能力。
|
||
|
||
2. **预计周期**：2周
|
||
|
||
3. **S2 (提示词策略 Server) 升级**：
|
||
|
||
- 引入**角色化智能体 (Persona Agents)** 逻辑，支持动态下发“检索专家”、“提取员”等角色指令。
|
||
- 开发最关键的 `evaluate_research_depth`（深度评估）和 `evaluate_knowledge_gaps`（盲区探测）工具。
|
||
|
||
4. **S1 (文献查询 Server) 升级**：开发 `manage_exploration_state` 工具，记录已经检索过的 Query 和文献 ID，防止系统在循环搜索时陷入死循环。
|
||
|
||
5. **工作流编排**：在客户端提示词中写入递归循环逻辑：强约束大模型在每次提取洞察（Learnings）后，必须调用 S2 评估盲区；若未达标，必须携带原 Learnings 发起新一轮检索。
|
||
|
||
- **🎯 里程碑成果**：系统不再是“查一次就写报告”，而是能像人类一样，顺着第一轮的线索，自动发起第二轮、第三轮的深挖检索。
|
||
|
||
### 3.4 阶段 4：学术级质量把控与 PKM 融合
|
||
|
||
1. **目标**：拔高输出结果的严谨性，彻底点亮 Obsidian 本地知识图谱。
|
||
|
||
2. **预计周期**：2 周
|
||
|
||
3. **S3 (CoT多步推理 Server) 质检强化**：
|
||
|
||
- 实现**引用密度强制校验**逻辑，确保正文中的核心事实必须带有 `[文献ID]` 尾注。
|
||
- 开发“利益冲突与时效性局限”自动声明模块。
|
||
|
||
4. **PKM (个人知识管理) 深度对接**：优化 `save_to_local_vault`：在 Markdown 正文中自动生成 Obsidian 格式的双向链接 `[[文献名称]]`，将主报告与独立洞察卡片物理串联。
|
||
|
||
5. **S1 (文献查询 Server) 爬虫强化**：实现 `scrape_and_parse_deep_content`，引入 Playwright 或 Firecrawl，突破纯 API 限制，抓取含金量高的网页正文。
|
||
|
||
- **🎯 里程碑成果**：生成的报告达到专业研报标准，且用户的 Obsidian 图谱中开始出现网状关联的知识节点。
|
||
|
||
### 3.5 阶段 5：非功能性优化与发布准备
|
||
|
||
1. **目标**：解决高并发下的稳定性问题，准备打包开源或交付。
|
||
|
||
2. **预计周期**：1周
|
||
|
||
3. **性能与稳定性优化**：
|
||
|
||
- 在 S1 增加 API 并发控制（Concurrency-limited batching）与请求重试机制，防止触发外部数据库的 Rate Limit。
|
||
- 增加 LRU 缓存机制，避免重复消耗大模型 Token 抓取相同的文献。
|
||
|
||
4. **工程化打包**：完善 `.env.example`（配置各路 API Keys、默认 Depth/Breadth 参数等）。
|
||
|
||
- **🎯 里程碑成果**：V0.1.0 正式发布。
|
||
|
||
---
|
||
|
||
## 4. 开发路线图
|
||
|
||
*图1-1：Project Caffiene MVP开发路线图*
|
||
|
||
|
||
|
||
---
|
||
|
||
## 许可声明
|
||
|
||
本文档采用 **知识共享署名--相同方式共享 4.0 国际许可协议 (CC BY--SA 4.0)** 进行许可，© 2025-2026 Gitconomy Research.
|