[JS/TS] VSCode插件开发：基于AI模型的智能归档工具自动整理笔记

问题背景

我们在记录笔记时，常常会随手将新建的笔记直接放在笔记项目的根目录下。虽然刚创建时使用频繁，方便查找，但事后却很少会主动将其移动到应有的分类文件夹中。久而久之，根目录下便堆积了大量未整理的笔记文件，显得杂乱无章。

此外，VSCode 的资源管理器默认排序规则并不友好——它无法按字母顺序排列文件夹，而文件则按更新时间排序。这使得在堆积如山的根目录中快速定位某个特定笔记变得非常困难。正是为了解决这一痛点，我决定开发一个能够智能归档笔记文件的功能。

解决方案

首个版本的功能设计较为简洁明了。其核心思路是：

1. 预先创建好分类文件夹，并在每个文件夹下放置一个 DESC.md 文件，用于描述该文件夹应该包含哪类主题的笔记。
2. 执行智能归档命令后，程序会为项目中的所有文本文件生成内容摘要。
3. 系统将文件摘要与各个文件夹下的 DESC.md 进行匹配，智能地为每个文件选择最合适的目标文件夹。
4. 如果匹配结果不够明确，系统会提供几个备选方案，由用户手动选择，最终完成归档。

这套方案在未来还有很大的扩展空间。例如，可以根据目录中已有的文件内容自动生成 DESC.md；通过分析自动归档的结果和用户的手动选择来持续更新 DESC.md，确保目录主题与时俱进；甚至可以直接基于全部笔记内容和现有文件夹结构，自动生成文件夹的元数据描述，从而取消对 DESC.md 的依赖。这些高级功能将留待后续迭代实现。

运行效果

让我们通过实际截图来看看归档前后的对比。

这是执行智能归档操作前的原始目录结构，文件散乱地堆积在根目录下。

图1：智能归档前杂乱的根目录

这是经过智能归档处理后的目录结构，大部分文件已被自动归入相应的主题文件夹中。

图2：智能归档后的目录结构

从结果来看，插件成功自动归档了大量文件。不过，实际运行中也暴露出一些问题：

• 近期文件保留：部分在14天内更新过的笔记被留在了根目录。这是有意为之的策略，因为近期笔记很可能仍需频繁使用，放在最外层最为便捷。
• 短内容误判：有些笔记内容过少（仅一两行），仅从文本难以准确判断归属。虽然AI模型给出了判定，但实际归档位置出现了错误。
• API调用失败：在批量调用模型API时，部分请求出错，导致对应文件无法完成归档。

这些问题指明了后续的优化方向，例如为短内容笔记设计更精确的匹配策略，以及增强批量处理的稳定性。

技术实现

这个智能归档功能被实现为一个 VSCode 插件。整个开发过程颇具趣味性：我直接使用了 Claude Code 和 GLM-4 等大模型辅助编程，几乎是一气呵成完成了初版代码。

在代码审查阶段，我让 GLM 模型复查了一遍，发现并修复了一些问题，不过它也改错了一处地方。之后，我又尝试使用 antigravity 和 Gemini 3 Flash 进行复查和优化，结果发现 Gemini 检查出的问题与 GLM 不同，并且其最终提供的优化建议和代码输出质量更高，感觉更为仔细。综合来看，在当前这个任务上，Gemini 的表现更强，算上修改调试的时间，效率也更高。

整个小项目的开发流程也进行了一次有趣的实践：先撰写产品需求文档（PRD），由大模型根据文档生成实现计划，再依据计划编写代码。后续的需求调整和功能优化，同样是先更新 PRD，然后交由大模型理解文档变化并自行迭代代码。这种“文档驱动开发”的模式效果相当不错，也为开源实战中的AI辅助编程提供了新思路。

一点吐槽

在尝试发布这个 VSCode 插件时，过程却异常坎坷。发布需要在 Azure 上注册一个组织，但我无论如何也无法成功登录，即使开启了代理也无济于事。这不禁让我联想到之前接入其他微软服务时的经历——它们的文档常常让人找不到北，即使找到了也可能晦涩难懂。这种开发者体验，实在令人忍不住想吐槽。如果你也在探索VSCode插件开发或AI应用落地的奇技淫巧，欢迎来开发者广场一起交流探讨。