## 使用LLM和Obsidian构建个人知识库 受Andrew Karpathy的工作启发,作者详细介绍了一种长达十年的实践:使用简单文件系统(Obsidian和markdown文件)——而非复杂的向量数据库——作为强大的个人知识库,并利用LLM进行增强。核心思想是超越零散的笔记,创建一个用于*上下文工程*的系统。 与其无休止地为设计文档或项目交接等任务重新收集信息,不如将所有内容——会议记录、Slack对话、文档——集中起来,并使用受PARA启发的文件夹结构(项目、领域、人物、每日/会议)进行组织。Markdown文件中的维基链接创建了一个可导航的互联知识“图谱”。 然后,LLM充当该图谱的自然语言查询引擎。通过向LLM提供相关项目文件夹的访问权限,输出将得到显著改善,因为模型使用*实际*的历史记录,而不仅仅是概括性的回忆。这使得LLM交互从基本的辅助转变为高度知情、感知上下文的工作。 最大的挑战仍然是自动化收件箱处理——有效地分类和整合新信息。然而,即使从小处着手——建立基本的文件夹结构并坚持在会议后做笔记——也能立即获得好处,让工作随着时间的推移而积累。
在开始编写代码之前,使用五个关键的 Git 命令快速评估新代码库的健康状况。首先,识别**变更热点** (`git log --format=format: --name-only ... | sort | uniq -c | sort -nr | head -20`) – 经常修改的文件,通常表明复杂性或开发者避免的区域。 接下来,确定**公交系数** (`git shortlog -sn --no-merges`),通过识别关键贡献者;高度集中,特别是如果这些个人不再参与,则表示风险。
通过分析提交消息中的错误相关关键词,找出**错误集群** (`git log -i -E --grep="fix|bug|broken" ...`),然后与变更热点交叉引用,以确定高风险区域。 使用**提交速度图** (`git log --format='%ad' ...`) 评估项目势头,寻找持续的活动或令人担忧的下降。 最后,评估**紧急修复频率** (`git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'`) – 频繁的回滚表明部署问题或不可靠的测试。
这些命令提供快速诊断,在代码审查*之前*揭示潜在问题,从而节省时间并专注于最需要关注的地方。