我的知识记录与开源贡献规划

为什么要重新整理

这个博客最早是我的技术学习笔记，里面有 Git、Java、Kafka、Zookeeper、Cocos、AI 训练师考试等内容。它们不需要被推翻，因为这些内容记录了我真实走过的技术路径。

接下来我希望把博客继续当成长期知识库来维护：一部分记录工程经验，一部分做知识推广，一部分沉淀 AI、RAG、知识图谱和开源贡献。

开源贡献不是博客的全部，它只是其中一条实践线。更重要的是把我做过、理解过、踩过坑的知识整理成别人也能读懂的内容。

内容主线

我会把后续内容逐步整理成四条线：

1. 基础工程：Java、并发、JVM、数据库、消息队列、Git、工程习惯。
2. AI 工程：RAG、文档解析、OCR、知识库、Agent、LLM 应用后端。
3. 知识建模：知识图谱、本体论、业务概念建模、结构化知识表达。
4. 开源贡献：issue 复现、PR 记录、维护者反馈、测试和文档补充。

旧文章会继续保留，新文章会逐渐补齐 AI 工程和知识建模这两条主线。

6 周执行节奏

第 1 周：整理博客与 GitHub 的公开入口，只做轻量修改，不大改人设。

第 2 周：写一篇 RAG 或文档解析相关的技术文章，尽量从实际工程问题出发。

第 3 周：筛选 Docling、Langfuse、LlamaIndex、LangGraph、RAG-Anything/LightRAG 中适合入手的 issue。

第 4 周：完成一个小而真实的开源 PR，优先选择测试补充、文档示例、兼容性修复或文档解析边界问题。

第 5 周：写一篇 PR 复盘，记录问题背景、复现方式、修复思路、测试命令和维护者反馈。

第 6 周：继续筛第二个 issue，同时整理一篇知识图谱、RAG 或 Agent 工程实践文章。

写作原则

我希望文章尽量满足几个条件：

• 来自真实学习或工程实践，不为了更新而更新。
• 尽量解释背景、问题和取舍，而不是只贴命令。
• 不使用公司代码、客户数据、密钥、内部截图或不可公开资料。
• 如果是开源贡献复盘，要写清楚复现、测试和结果。

下一步

下一篇文章优先写 RAG 文档解析链路：从 PDF、Word、图片、表格进入知识库之前，为什么解析质量会直接影响检索和回答效果。

这条线会自然连接到后续的 Docling、RAG-Anything、LightRAG 等开源项目贡献。