基于 TRAE SOLO 构建个人学术知识库与自动化学习系统
1. 摘要
本项目利用 TRAE SOLO 构建了一套面向深度学习时序预测研究的个人学术知识库系统。系统实现了从 PDF 论文解析、知识节点提取、双向链接网络构建到每周自动出题+邮件推送的完整闭环，将碎片化的论文阅读转化为结构化的、可检索、可复习的知识图谱。
必须注意的是：AI 可以收集资料、总结方法，但更重要的是独立完成"我认为"后面的部分。
2. 背景
我是一名计算机技术专业的研一新生，研究方向为乙烯裂解炉炉管的温度检测，主要采用深度学习中的时间序列处理方法。日常面临的挑战包括：
- 论文阅读碎片化：每周阅读多篇时序预测、Transformer 架构相关论文，笔记散落在各处，缺乏系统整理
- 知识遗忘快：读完论文后，核心概念和方法的细节很快模糊，缺乏有效的复习机制
- 研究方向聚焦难：面对大量前沿工作（PatchTST、iTransformer、Timer-XL、AttnRes 等），难以理清它们之间的关联和演进脉络
- LLM 辅助学习的"幻觉"问题：直接让 LLM 总结论文容易产生事实错误，需要一种可控的、基于真实内容的知识提取方式
3. 实践过程
3.1 任务拆解
整个知识库建设经历了 4 个阶段，每个阶段都由 SOLO 协助完成：
阶段1: 知识库架构设计 → 学习 Karpathy 方法，搭建项目结构，选型 Marker
阶段2: 防幻觉优化 → 参考 andrej-karpathy-skills，优化 DEEPSEEK_SCHEMA.md
阶段3: Token 精简 → 发现冗余上传问题，优化处理流程
阶段4: 自动化学习系统 → 设计出题机制，实现邮件推送+云端提醒
3.2 阶段一：知识库架构设计与搭建
学习 Karpathy 的知识库方法论
项目灵感来源于 Andrej Karpathy 的个人知识库搭建方法。Karpathy 的核心理念是：知识应该以原子化的方式组织，每个概念一个文件，通过双向链接形成网状图谱，而非传统的树状文件夹结构。这种方法让知识之间的关系变得可探索、可发现。
基于这一理念，我用 SOLO 搭建了完整的项目骨架：
personal-knowlegel-net/
├── .obsidian/ # Obsidian 配置（图谱、双向链接、标签）
├── _staging_pdf/ # 待处理 PDF 论文（输入入口）
├── raw/ # Marker 转换后的 Markdown（中间产物）
├── _ManuNote/ # 个人手写笔记（已经存在的个人笔记md文件）
├── wiki/ # 知识节点（核心输出）
├── DEEPSEEK_SCHEMA.md # LLM 处理规范（关键规则文件）
└── manifest.json # 处理状态追踪
注：我个人的论文笔记是参照B站漫士沉思录的 【专业】清华博士示范阅读AI论文+学习资源分享推荐（BV1aT421a7Sj） 的6个问题的形式编写。
设计 DEEPSEEK_SCHEMA.md 规范
为了让 LLM（DeepSeek）能够将论文和笔记转化为标准化的 wiki 节点，我设计了 DEEPSEEK_SCHEMA.md 规范文件，定义了每个知识节点的结构：
---
tags: [标签]
date: YYYY-MM-DD
source_refs: [来源论文/笔记ID]
---
一句话定义。
## 数学/逻辑推导
## 前提条件与适用边界
## [关联拓扑]
- [[相关概念]]：关系说明
选型 Marker 作为 PDF 转换工具
选择让 LLM 直接处理 PDF 效果不好，因为 LLM 对 PDF 的阅读能力有限。需要先将 PDF 转为 Markdown 格式，再交给 LLM 处理。经过调研，选择了 Marker——一个高精度的 PDF 转 Markdown 工具，支持公式、表格、图片的提取。
踩坑：Windows 文件名长度限制。在运行 Marker 转换 PDF 时，发现 Windows 系统对文件名有 260 字符的路径长度限制，而学术论文的 PDF 文件名通常很长（如 2509.03505v2Limix.pdf 加上目录路径后容易超限）。为此，convert_pdfs.py 中专门实现了 sanitize_paper_id() 函数：对超长文件名进行截断，并添加 MD5 短哈希后缀避免冲突，同时通过临时文件目录绕过文件名中的空格和特殊字符问题。
两条输入通道
项目设计了两条并行的知识输入通道：
| 通道 | 输入 | 处理方式 | 适用场景 |
|---|---|---|---|
| PDF 论文 | _staging_pdf/ → convert_pdfs.py + Marker → raw/ |
全文转换后交给 LLM 提取概念 | 精读论文 |
| 个人笔记 | _ManuNote/ → process_manunote.py + DeepSeek |
直接交给 LLM 提取概念 | 泛读笔记、课堂笔记 |
manifest.json 记录了每篇论文和笔记的处理状态、来源路径、生成的 wiki 节点列表，避免重复处理。
3.3 阶段二：防止 LLM “幻觉”——优化 DEEPSEEK_SCHEMA.md
直接让 LLM 总结论文容易产生事实错误（“幻觉”）。参考了 andrej-karpathy-skills 项目中关于防止 LLM 胡说的原则，核心思想是：
“The models make wrong assumptions on your behalf and just run along with them without checking.”
—— Andrej Karpathy
基于这一原则，我对 DEEPSEEK_SCHEMA.md 进行了优化，引入了多层保障：
- 明确边界：在规范中明确要求 LLM 只做"格式化和关联建议"，事实内容必须来自原始论文和笔记，不得自行编造
- 格式合规检查（
analyze_format.py）：检查 YAML frontmatter 是否完整、数学公式定界符是否正确、LaTeX 模式是否闭合 - 死链检测（
analyze_links.py）：扫描所有[[...]]双向链接，识别指向不存在节点的引用 - 重复内容分析（
analyze_duplicates.py）：通过标题归一化和词频相似度检测语义重叠的节点 - manifest.json 全链路追踪：每篇论文和笔记的处理状态、来源、生成的 wiki 节点都有完整记录
此外，SOLO 还帮助修复了早期生成的 wiki 文件中的乱码问题（5 个文件因编码问题导致全文乱码，SOLO 根据论文原始内容重新编写了这些节点）。
3.4 阶段三：Token 精简——发现冗余上传问题
在测试阶段，发现了一个严重的 Token 浪费问题：DEEPSEEK_SCHEMA.md 中没有对 Marker 转换得到的文件做区分，导致：
- 不需要上传的图片也被上传了：Marker 转换 PDF 时会提取所有图片（一篇论文 20~40 张），但 LLM 处理时只需要文本内容，图片完全不需要
- 已经分析过的文件被重复上传：
raw/目录中已处理的论文 Markdown 被全量发送给 LLM，包括参考文献、页眉页脚等无关内容
SOLO 对此进行了量化分析：
| 处理方式 | Token 消耗/论文 | 成本估算 |
|---|---|---|
| 全量上传（原方案） | ~200 万 | ¥2（感谢deepseek） |
| 精简后（优化方案） | ~1 万 | ¥0.05-0.1 |
节省 95% 以上的 Token 消耗。优化策略包括：
- 只提取论文的核心章节（摘要、方法、实验），跳过参考文献和相关工作
- 过滤掉图片文件，只选择上传md文本
- 对已处理的论文，只发送摘要而非全文
3.5 阶段四：自动化学习系统——“学而不思则罔”
“学而不思则罔，思而不学则殆。” —— 《论语》
只有记录没有思考，那叫存档，不是个人知识库。在知识库积累了 40 个 wiki 节点后，我与 SOLO 讨论设计了一套"分层出题+间隔重复+邮件推送"的自动化学习系统。
出题结构（自用3:3:1 比例，可以根据自身情况调整）
| 类型 | 频率 | 说明 |
|---|---|---|
 基础巩固 × 3 |
每周 | 围绕已读 wiki 节点的基础概念理解 |
 适度挑战 × 3 |
每两周 | 结合基础知识延伸到前沿方向 |
 前沿思考 × 1 |
每月 | 对标顶会论文级别的开放性问题 |
每道题必须关联 wiki 节点（用 [[节点名]] 标注），必须与乙烯裂解炉炉管温度检测或深度学习时序方法相关。
双重自动化架构
由于 SOLO 运行在本地，电脑关机时无法执行，因此设计了"云端+本地"双系统：
云端（GitHub Actions） 本地（SOLO Schedule）
┌──────────────────┐ ┌──────────────────────┐
│ 每周一 8:30 │ │ 每周一 8:30~12:30 │
│ 发提醒邮件 │ ──提醒──→│ 轮询出题并发邮件 │
│ "请打开SOLO" │ │ 读知识库→生成问题 │
└──────────────────┘ │ →发送到QQ邮箱 │
└──────────────────────┘
实现细节：
- 邮件发送：Python SMTP 脚本（
send_email.py），通过 QQ 邮箱 SMTP 服务发送 - 防重复机制：
last_quiz_sent.json记录本周发送状态，发送成功后标记，后续轮询自动跳过 - 云端提醒：GitHub Actions workflow（
weekly-reminder.yml），每周一 8:30 北京时间自动触发 - 本地轮询：SOLO 定时任务，每半小时检查一次，确保无论用户几点打开电脑都能收到问题
- 出题历史：
quiz_history.json记录所有历史题目，避免出题方向重复
问题状态机
引入了间隔重复机制，不牢固的知识会自然回弹：
新建 → 📖 思考中 → ✅ 已回答 → 🔁 待复习 → 📌 已掌握
↓
⭐ 收藏入库
- 基础题回答后 2 周自动安排复习，通过后标记"已掌握"
- 挑战题标注"思考深度：充分/一般/需拓展"，"需拓展"的 3 周后出相关变体题
- 前沿题不设复习，标记为"已探索"，避免重复方向
收藏题目与回答入库
回答题目后，系统会自动提示是否将题目和回答收藏入库。收藏的内容存放在 wiki/_quiz_archive/ 目录，Obsidian 会自动识别子目录中的 .md 文件，因此收藏的题目会：
- 进入知识图谱，与现有 wiki 节点形成关联
- 可通过 Obsidian 全局搜索找到
- 可通过双向链接
[[题目名]]引用
收藏文件的结构：
---
tags: [quiz, 基础巩固/适度挑战/前沿思考]
date: 2026-05-12
related_nodes: [[PatchTST]], [[通道独立]]
status: 已回答
---
## 题目
[原题内容]
## 我的回答
[用户的思考过程]
## SOLO 点评
[反馈内容]
## 后续思考
[可选的延伸思考]
这样，有价值的题目和思考不会流失，而是沉淀为知识库的一部分，形成"学习→思考→沉淀→复习"的完整闭环。
收藏测试验证
为验证收藏流程的可行性，进行了一次完整的测试：
-
生成测试题：基于知识库中的 [[PatchTST模型]]、[[Channel-independence（通道独立）]]、[[维度倒置]]、[[iTransformer模型]] 四个节点，生成了一道"适度挑战"级别的题目：“PatchTST 的通道独立假设在乙烯裂解炉场景下成立吗？”
-
用户回答：从物理耦合（辐射传热、流体分配、燃烧器布局）角度分析了 CI 假设的失效场景，提出了"通道部分相关（CP）"和"iTransformer 维度倒置"两种改进思路，并从工程角度总结了 CI 的适用边界。
-
SOLO 点评：
亮点：物理直觉准确（抓住"结焦影响流体分配"关键场景）、提出了自己的判断（CP 处于发展前期）、工程视角到位
可深入：iTransformer 捕捉的是静态相关性而非动态耦合、CP 具体是哪篇工作需要追踪
延伸：混合架构设计（CI 底层 + GAT 中层 + 物理约束顶层）
-
收藏入库：将题目、回答、点评、后续思考待办清单整理为 Markdown 文件，存入
wiki/_quiz_archive/目录，并配置了 Obsidian CSS 片段使收藏题目在关系图谱中显示为红色节点。 -
链接验证：修复了 frontmatter 中
related_nodes的 YAML 格式，并在正文添加## 关联节点段落，确保 Obsidian 图谱能正确显示收藏题目与其他 wiki 节点的连接关系。
测试结果：收藏流程完整可行，题目已成功入库并与知识图谱形成关联。
关键 Prompt（出题任务）：
每周一学术思考题出题任务。读取 wiki/ 目录下所有知识节点，按 3:3:1 结构生成问题。每道题必须关联 wiki 节点，必须与[乙烯裂解炉炉管温度检测或深度学习时序方法]相关。
3.6 踩过的坑
- DEEPSEEK_SCHEMA.md 缺失：有时候手贱，要记得完成一个阶段后及时保存副本。
- GitHub MCP 配置失败：Trae 的 GitHub MCP 连接器报 “npx 不合法” 错误。最终改用浏览器工具直接操作 GitHub 完成仓库配置。（因为node.js缺失，现在已经修复）
- 云端+本地同步问题：最初只设计了本地定时任务，忽略了电脑可能未开机的情况。经过讨论后引入了 GitHub Actions 作为云端兜底。
4. 成果展示
项目结构
personal-knowlegel-net/
├── .obsidian/ # Obsidian 配置（图谱、双向链接）
├── .github/workflows/ # GitHub Actions 云端提醒
├── _staging_pdf/ # 待处理 PDF 论文
├── raw/ # Marker 转换后的论文 Markdown
├── _ManuNote/ # 个人手写笔记（~20 篇）
├── wiki/ # 知识节点（40 个 .md 文件）
├── _templates/ # 出题规则模板
├── _config/ # 邮件配置、发送状态、出题历史
├── manifest.json # 论文/笔记处理追踪
├── send_email.py # QQ 邮箱 SMTP 发送脚本
├── convert_pdfs.py # PDF→Markdown 批量转换
├── process_manunote.py # 笔记→Wiki 节点处理
└── analyze_*.py # 质量保障脚本（格式/死链/重复）
知识图谱概览
当前 40 个知识节点，涵盖：
- 时序模型（8 个）：PatchTST、iTransformer、DLinear、Autoformer、TimesNet、TimeXer、Timer-XL、LimiX
- Transformer 基础（3 个）：Transformer 架构、自注意力机制、Attention Residuals
- 核心机制（~15 个）：Patching、Channel-independence、维度倒置、序列分解、自相关机制等
- 数学工具（4 个）：KAN、最优传输、PSW-I、深度混合矩阵
- 应用领域（3 个）：锅炉结渣预测、水冷壁有效系数、清洁度因子
- 框架/工具（2 个）：TSLib、大型结构化数据模型（LDM）
自动化系统
- GitHub 仓库：你自己的github仓库/weekly-quiz-reminder（云端提醒）
- SOLO 定时任务：每周一 8:30~12:30 自动出题并发送邮件
- 邮件测试：已验证 QQ 邮箱 SMTP 发送成功
5. 效果与总结
提效成果
| 环节 | 之前 | 之后 |
|---|---|---|
| 论文知识整理 | 读完后笔记散落，难以回顾 | 结构化 wiki 节点，双向链接形成知识图谱 |
| 知识复习 | 依赖记忆，容易遗忘 | 每周自动出题，间隔重复巩固 |
| 环境配置排查 | 手动搜索、试错 | SOLO 自动诊断并修复 PATH |
| 质量检查 | 人工逐个检查格式和链接 | 一键运行 3 个分析脚本 |
SOLO 在流程中的角色
SOLO 在本项目中承担了多个关键角色：
- 项目分析师：一次对话完成对整个项目的深度分析，输出结构化报告
- 环境诊断师：自动排查 Anaconda、Marker、Python 环境问题并修复
- 系统架构师：参与讨论出题机制、频率控制、防重复策略的设计
- 自动化执行者：通过定时任务实现每周出题+邮件推送的完整闭环
- 全栈工程师：从 Python 脚本到 GitHub Actions workflow，端到端实现
可复用的方法论
- "原子节点+双向链接"知识组织法：受 Karpathy 启发，每个概念一个文件，通过链接形成图谱，适用于任何领域的知识管理
- "云端提醒+本地执行"双系统架构：解决了本地自动化工具在电脑关机时失效的问题，可推广到其他类似场景
- "分层出题+间隔重复"学习机制：3:3:1 的出题结构结合不同频率，平衡了基础巩固和前沿探索
- "LLM 格式化+人工事实把控"的质量策略：参考 Karpathy 的防幻觉原则，让 LLM 负责结构化而非事实生成
总结
这个项目的核心价值不在于某个单点的技术实现，而在于用 SOLO 将碎片化的学术阅读流程整合成了一个闭环系统——从论文输入到知识提取，从质量保障到自动复习，每个环节都有工具和流程支撑。更重要的是，整个系统的设计和迭代过程本身就是与 SOLO 协作完成的，体现了 AI 辅助工作的新范式：不是让 AI 替你思考，而是让 AI 帮你构建思考的基础设施。
GitHub库： BigMo-gdupt/personal-knowledge-net: LLM+obsidian的个人知识库+定期提问
贡献
我：提供了思路、审查、细节修正
Trae Solo CN（windows版本）：提供了平台、具体方法的实现与检查、以上文本的编写
Trae 官方：开启了这次活动和让我免费使用（感谢）