97 lines
4.9 KiB
Markdown
97 lines
4.9 KiB
Markdown
---
|
||
title: Knowledge Bank — AI 辅助开发时代的知识管理系统
|
||
created: 2026-04-16
|
||
updated: 2026-04-17
|
||
type: concept
|
||
tags: [knowledge-management, open-source, multi-agent]
|
||
sources: [raw/articles/knowledge-bank-ai-dev-2026.md]
|
||
---
|
||
|
||
# Knowledge Bank
|
||
|
||
面向 AI 辅助开发时代的知识管理系统，通过自动捕获、结构化存储和智能检索，让开发团队的知识真正流动起来。
|
||
|
||
项目仓库: [gabrywu-public/knowledge-bank](https://github.com/gabrywu-public/knowledge-bank)
|
||
|
||
## 核心洞察
|
||
|
||
### 转变一：知识受众从"人"变为"机器"
|
||
|
||
传统知识管理假设知识是给人阅读的（精美文档、结构化 wiki、详细注释），但现实中开发者不会主动看文档，即使看了也记不住、找不到、或已过时。
|
||
|
||
在 AI 辅助开发时代，**真正的知识消费者是 AI 代码助手**（Claude Code、Cursor、GitHub Copilot）。知识需要结构化、情境化、可检索的格式，让 AI 能快速理解和应用。
|
||
|
||
### 转变二：三维知识分类体系
|
||
|
||
不再按主题分类，而是采用 **作用域 + 来源 + 类型** 的三维分类：
|
||
|
||
| 维度 | 分类 | 说明 |
|
||
|------|------|------|
|
||
| **作用域 (Scope)** | 个人 / 项目 / 组织 | 知识的共享边界，避免知识冲突，实现精准注入 |
|
||
| **来源 (Source)** | AI 观察 > 架构师决策 > Reviewer 偏好 > 开发者经验 | 知识的权威性权重；AI 观察因来自实际代码、可验证、实时性而权重最高 |
|
||
| **类型 (Type)** | 代码模式 / 架构决策 / 配置偏好 / 陷阱警示 / API 用法 | 知识的应用方式 |
|
||
|
||
**关键设计：AI 观察的可信度最高** —— 这违反直觉但合理，因为 AI 观察直接来自实际代码（可追溯到 commit），反映当前真实状态，而非人为偏好或可能过时的文档。
|
||
|
||
### 转变三：知识生命周期重构
|
||
|
||
从 **"写作→发布→被遗忘→过时→删除"** 转变为 **"捕获→检索→应用→收集"**：
|
||
|
||
- **零摩擦捕获**: 不需要开发者专门写文档，知识在开发过程中自动提取
|
||
- **情境化检索**: 不是被动等待查询，而是主动在需要时注入相关知识
|
||
- **智能去重**: 通过多维度相似度评分（标题 40% + 摘要 30% + 内容 20% + 上下文 10%）自动合并
|
||
- **持续进化**: 知识库随项目发展自动更新和优化
|
||
|
||
## 技术架构
|
||
|
||
### Fork Context（上下文隔离架构）
|
||
|
||
知识操作（检测、去重、评分）在分叉的隔离环境中执行，不干扰主会话：
|
||
|
||
1. **会话开始 → 知识注入**: 提取关键词 → 搜索知识 → 相关性评分 → 过滤 → 格式化注入
|
||
2. **会话结束 → 知识收集**: 分析会话记录 → 识别有价值知识点 → 4 项资格检查 → 去重 → 创建/更新知识
|
||
|
||
优势：主会话保持简洁，复杂分析不干扰用户体验，可并行执行。
|
||
|
||
### 强制仓库关联 (Repository-Aware)
|
||
|
||
所有知识和会话必须关联到 Git 仓库（`repository_id NOT NULL`），确保数据完整性和精准检索。
|
||
|
||
### 完整会话追踪
|
||
|
||
记录每次开发会话的完整上下文：session_id、仓库、分支、commit、工具使用、文件修改等。
|
||
|
||
## 知识生命周期七阶段
|
||
|
||
Knowledge Bank 将知识管理融入软件开发全流程，形成"生长的枝干"：
|
||
|
||
1. **需求分析**: 自动检索历史需求知识，注入相关业务规则
|
||
2. **架构设计**: 自动注入项目架构规范，收集新的设计决策
|
||
3. **编码开发**: 自动注入编码规范，识别新的代码模式
|
||
4. **测试验证**: 自动注入已知陷阱，收集新的 edge case
|
||
5. **Code Review**: AI 辅助审查，更新 Review 规则
|
||
6. **部署运维**: 基于历史故障经验自动诊断，收集运维知识
|
||
7. **迭代优化**: 追溯完整知识链路，指导优化决策
|
||
|
||
## 与传统知识管理的对比
|
||
|
||
| 维度 | 传统方式 | Knowledge Bank |
|
||
|------|----------|----------------|
|
||
| 受众 | 人 | AI（+ 人） |
|
||
| 载体 | 静态文档 | 动态上下文 |
|
||
| 获取方式 | 主动查询 | 自动注入 |
|
||
| 维护方式 | 人工编写 | 自动捕获 |
|
||
| 知识形态 | 散落的金子（孤立、过时） | 生长的枝干（互联、进化） |
|
||
|
||
## 相关概念
|
||
|
||
- **多 Agent 工作流**: Knowledge Bank 的多阶段知识采集机制本质上是一种 agent 工作流
|
||
- **持久化知识编译**: 与 Karpathy 的 LLM Wiki 模式形成互补——Knowledge Bank 侧重 AI 辅助开发场景的自动化知识捕获，llm-wiki 侧重持久化知识编译
|
||
- [[computerized-adaptive-testing]] — CAT 的自适应选题本质上是知识注入的精准化：在正确的时间向正确的对象注入正确的测试项，与 Knowledge Bank 的情境化检索有相同的设计哲学
|
||
|
||
## 开放问题
|
||
|
||
- Knowledge Bank 的三维分类体系是否可扩展到非代码领域（如科研、写作）？
|
||
- AI 观察的"最高可信度"假设在代码存在 anti-pattern 时是否仍然成立？
|
||
- 知识去重的相似度阈值（0.85 合并 / 0.60 提示）是否经过实证验证？
|