从项目事实整理器到本地资料档案馆

这篇还是一段和 AI 有关的杂谈。原始想法比较散，后来顺着项目方向重新整理了一下。

最近在想一个小工具。最初的想法其实很简单：

能不能利用 AI 理解整个项目，然后帮助开发人员调查问题？

例如：

• 为什么当年修改了这个功能？
• 这个设计是谁决定的？
• 类似的问题以前出现过吗？
• 对应的设计书在哪里？

在很多项目现场，这类问题经常出现。

回答这些问题的人，往往需要翻阅大量资料：

• 设计书
• 会议记录
• 调查报告
• 邮件
• Issue
• 代码提交记录

于是我想到，也许可以利用 AI 来帮助调查。

最初的设想

最开始，我希望做一个“项目事实整理器”。

理想状态下，用户提出问题，AI 自动阅读整个项目资料，然后直接给出答案。

这个设想听起来很美好，但很快就会遇到几个现实问题。

第一，本地模型能力有限

我目前主要关注本地部署。

但无论是显存还是计算能力，都很难支撑 AI 在每次查询时重新理解整个项目。项目文档越多，这种方式成本越高。

第二，全文理解并不现实

即使未来模型能力变强，让 AI 每次查询都重新阅读全部资料，也不一定合理。

因为绝大部分文档与当前问题无关。真正需要阅读的内容，往往只占很小一部分。

第三，缺少真实项目数据

没有大量真实设计书、会议记录和历史调查资料。

很多想法都停留在理论阶段。

而项目现场的问题，远比演示环境复杂。

后来的发现

想了一段时间以后，我逐渐意识到一个问题：开发人员调查问题时，真正缺少的往往不是答案，而是资料定位能力。

• 很多时候：

• 我知道答案一定存在。

• 我知道以前有人讨论过。

• 我知道设计书里写过。

• 但我不知道它在哪里。

• 于是调查过程变成：

• 搜索 -> 阅读 -> 判断 -> 形成结论

• 而不是：

• 提问 -> 获得答案

这时候我突然发现，我需要的也许不是一个 AI 项目专家，而是一个更好的档案馆。

档案馆的思路

如果把所有项目资料看作档案，那么系统首先应该做的是：

• 收集资料
• 建立索引
• 记录版本
• 保存来源
• 提供搜索

AI 的职责则变成：

• 阅读资料
• 整理资料
• 总结资料

而不是代替档案馆本身。

这样一来，系统架构就开始发生变化。

第一步：文档入库

扫描本地资料，建立文档索引，并记录：

• 文件路径
• 文件版本
• 更新时间
• SHA256

第二步：文档切片

将文档切分成较小的片段，例如：

• 按章节
• 按标题
• 按段落

这样未来查询时，就不需要重新阅读整份文档。

第三步：建立向量索引

每个切片生成向量。

保存到向量数据库。

未来用户查询时，问题向量与文档向量进行匹配，先找到最相关的资料片段。

第四步：AI 生成调查报告

找到相关片段后。

AI 不再阅读整个项目。

它只阅读这些已经筛选出的内容。

然后生成调查报告。

例如：

• 修改原因
• 影响范围
• 历史背景
• 相关文档

这样 AI 的能力可以得到更有效的利用。

AI 不是档案馆

这次最大的收获是：

AI 很适合阅读。

AI 很适合总结。

AI 很适合发现关联。

但 AI 不适合替代档案馆。

资料管理、版本管理、索引维护、切片更新，这些依然是传统系统需要解决的问题。

AI 只是一个优秀的馆员。

而不是档案馆本身。

如果档案馆本身混乱，AI 再会总结，也只能在混乱里找线索。它可以帮忙阅读和整理，但不能凭空保证资料一定完整、版本一定正确、来源一定可信。

结语

这个项目目前还停留在想法阶段。

甚至没有真实项目数据进行验证。

但有一点已经越来越明确：

未来如果要利用 AI 帮助开发人员调查项目，也许正确的方向不是让 AI 理解整个项目。

而是先建设一个可靠的本地资料档案馆。

然后让 AI 在这些资料之上工作。

毕竟，很多时候，找到资料本身就已经解决了一半问题。

答案可以慢慢判断，结论也可以由人来下。但如果资料散落在各个角落，连入口都找不到，那调查就会一直卡在原地。

所以这个工具最后可能不是一个“全知全能的 AI 项目助手”。它更像是一个本地资料档案馆，加上一个会阅读、会归纳、会帮忙写调查报告的馆员。

这个边界比较朴素，但也更像是真正能落地的方向。