从"能用"到"好用"，v2.0.0 用一次彻底的架构升级，重新定义了开源代码知识库的边界。
写在前面
今天，我们正式发布OpenDeepWiki v2.0.0 预览版。
这不是一次简单的功能迭代——我们几乎重写了整个系统的核心架构，从后端的 .NET 10 + Semantic Kernel 升级、前端的 Next.js 16 重构，到全新的增量更新引擎、多平台聊天系统、MCP 协议支持，每一个模块都经历了深度打磨。
如果你还不了解 OpenDeepWiki：它是一个开源项目，灵感来源于 DeepWiki，能够将任意 GitHub、GitLab、Gitee、Gitea 代码仓库在几分钟内转换为结构化的 AI 知识库。支持所有编程语言，自动生成文档、代码结构图、思维导图，并提供对话式交互能力。
一、全局架构升级
v2.0.0 采用前后端分离架构，在工程化层面做了大量优化：
后端基于 ASP.NET Core Minimal API 构建，抛弃了传统 Controller 模式，端点按业务域组织（Auth、Chat、Wiki、Admin、IncrementalUpdate 等），代码更简洁、路由更清晰。
前端升级到 Next.js 16 + React 19，全面采用 App Router 和嵌套布局模式。组件按业务域组织（仓库浏览、聊天助手、管理后台、应用管理），配合 Radix UI 基础组件和 Motion 动画库，UI 体验有了质的飞跃。
数据层通过统一的数据库抽象接口，SQLite 和 PostgreSQL 可通过一个环境变量自由切换，零代码改动。
支持生成一次一次文档包含多个语言。
二、增量更新引擎——从"全量重建"到"精准更新"
这是 v2.0.0 最重要的技术突破。
痛点：v1.x 中，仓库每次有代码变更，都需要完整重新生成所有文档。对于大型仓库，这意味着漫长的等待和大量的 AI Token 消耗。
解决方案：基于 Git Diff 的增量更新。系统记录每次处理的 Commit ID，当检测到新提交时，只比对两个 Commit 之间的文件差异，仅重新生成发生变更的文件对应的文档。
技术实现分为几个关键层：
任务实体：每个增量更新任务记录了上次和当前的 Commit ID、优先级、重试次数、状态等信息，形成完整的任务生命周期管理
更新服务：核心流程为"准备工作区 → 比对 Commit → 获取变更文件列表 → 对每个语言版本调用 AI 增量生成 → 更新 CommitId → 通知订阅者"。内置工作区损坏检测与自动修复机制，配合指数退避重试策略
后台工作器：独立的后台轮询服务，优先处理手动触发的高优先级任务（Priority=100），再检查需要定期更新的仓库（Priority=0）。每次最多检查10个仓库，防重复创建任务
RESTful API：提供手动触发、查询状态、重试失败任务三个端点，供前端和外部系统调用
AI 增量文档生成：内置专门的增量更新提示词模板，AI Agent 会分析变更影响范围，精准定位需要更新的文档章节，做最小化修改而非全量重写
这套机制让大型仓库的文档更新从"分钟级"降低到"秒级"，Token 消耗降低 80% 以上。
三、多平台聊天系统：飞书、QQ、微信一键接入
v2.0.0 新增了完整的多平台聊天系统。
架构上采用 Provider 抽象模式：所有聊天平台（飞书、QQ、微信）都实现统一的消息提供者接口，通过消息路由器分发到对应的 Provider。消息进入数据库持久化队列后，由后台消息处理器统一调度 AI Agent 执行知识库检索和回答生成。
几个设计亮点：
消息合并器：处理用户连续发送的多条消息，合并后再交给 AI，避免碎片化对话
配置热重载：后台服务监听配置变更，无需重启即可更新 Provider 配置
会话管理：维护每个用户/群聊的对话上下文，支持多轮对话
扩展性：新增平台只需实现一个 Provider 类，注册即可使用
以飞书为例，接入只需设置 AppId/AppSecret 环境变量，配置回调地址，将机器人拉入群聊即可。支持文本和图片回复（包括思维导图）。
四、AI Agent 工厂：多提供商统一抽象
v2.0.0 的 AI 能力通过 AgentFactory 统一管理，支持 OpenAI、Azure OpenAI、OpenAI Responses API、Anthropic 四种提供商，通过环境变量一键切换。
分离式模型配置是一个精妙的设计——Wiki 生成支持为三个阶段配置不同的 AI 模型：
阶段 | 用途 |
|---|---|
目录生成 | 分析仓库结构，生成文档目录树 |
内容生成 | 生成每个文档页面的详细内容 |
翻译 | 将文档翻译为其他语言 |
这意味着你可以用便宜的模型生成目录结构，用强力模型生成核心内容，用专门的翻译模型做多语言——成本和质量的最优平衡。
五、Wiki 生成管线：AI 如何"读懂"一个代码仓库
整个 Wiki 生成由 WikiGenerator 编排，流程为：克隆仓库 → 扫描目录（超过阈值则 AI 智能过滤）→ AI 生成文档目录结构 → 并行生成文档内容 → 多语言翻译 → 思维导图生成。
系统内置四套经过精心调优的提示词模板（目录生成器、内容生成器、增量更新器、思维导图生成器），每套都针对特定任务优化。
以内容生成器为例，它对 AI 有严格的约束：禁止编造代码示例（必须从实际源文件提取）、强制源码归属（每个代码块必须附带引用链接）、Mermaid 图表必须反映真实代码结构、工具调用是强制的（AI 必须使用 Git 读取和搜索工具）。这套约束机制确保了生成文档的可信度。
后台运行着四个独立的工作器：仓库处理、增量更新、文档翻译、思维导图生成，各司其职，互不干扰。
六、聊天助手 & 可嵌入组件
v2.0.0 提供了两套聊天能力：
内置聊天助手：支持 SSE 流式传输、多模型切换、文档上下文感知（自动注入当前浏览的文档信息）、引用文本提问、图片理解。
可嵌入聊天组件：通过 App 管理系统创建独立的聊天应用，生成 API Key，嵌入到第三方网站。支持域名白名单验证、独立的 Token 消耗统计、应用级别的聊天隔离。
写在最后
OpenDeepWiki v2.0.0 是一次从内到外的重构。增量更新让文档永远保持最新，MCP 协议让 AI 工具直接接入知识库，多平台聊天让知识触手可及——这些能力的组合，让 OpenDeepWiki 不再只是一个文档生成器，而是一个活的代码知识中枢。
项目完全开源，MIT 协议，欢迎 Star、Fork、PR：
🔗GitHub: https://github.com/AIDotNet/OpenDeepWiki
📖文档站: https://docs.opendeep.wiki
如果这篇文章对你有帮助，欢迎转发分享。我们正式版本见 👋
