基于Node.js+DeepSeek打造一个智能档案归档系统

说起来，在IT工程交付、政府项目或者大型企业管理里，最让人头疼的收尾环节，往往就是“资料归档”。

想象一下这个场景：你手里有一个几百兆的文件夹，里面塞满了各种PDF、扫描件、Word文档，文件名五花八门，比如“2024-10-12 会议记录_最终版.pdf”。另一边，客户甩过来十几个Word文档（也就是案卷目录），每个文档里有一个表格，清清楚楚规定了某个案卷必须包含哪些文件，而且必须重命名为标准格式，比如“01-01 项目会议纪要.pdf”。

然后呢？传统做法就是人工一个个打开文件看内容，再去目录里找对应项，重命名，拖进去……几百个文件折腾下来，好几天就这么过去了，还特别容易出错。

所以，一个很自然的想法就冒出来了：能不能写个程序，让它像人一样“看懂”文件名，自动跟目录里的标题配对？

答案当然是肯定的。把Node.js的文件处理能力和DeepSeek LLM（大语言模型）的语义理解能力结合起来，我们就能搭建一套智能化的自动归档系统。

1. 背景与痛点

这里需要先明确一下，这个工具要解决的核心问题是什么。简单说，就是在IT工程交付、政府项目或大型企业管理的收尾阶段，把一团乱麻的原始文件，按照客户给定的严格标准，自动整理成规范格式。

痛点其实很明确：

• 文件混乱：几百兆的文件夹，文件名毫无规律，内容混杂。
• 要求严苛：客户给的案卷目录是Word文档里的表格，定义了每个文件的标准名称和位置。
• 耗时耗力：人工操作，几百个文件，几天时间，还容易出错。

解决思路的核心，就是让程序具备“理解”文件名语义的能力，从而完成自动匹配。

2. 系统架构设计

为了让这个工具真正落地，而不是停留在demo阶段，我们经历了从“全云端处理”到“本地+云端混合”的架构演进。最终的核心流程是这样的：

1. 输入：用户上传多个“案卷目录”Word文件 (.docx)。
2. 扫描：后端自动扫描本地磁盘上指定的文件夹，也就是存放所有杂乱原始文件的地方。
3. 解析：提取Word文档中表格的“序号”和“标准题名”。
4. 思考（AI Agent）：把“原始文件名列表”和“标准题名列表”发给DeepSeek API，让它来做模糊语义匹配。这一步是关键。
5. 执行：根据AI的匹配结果，自动复制文件、重命名，并分类存放到对应的文件夹里。
6. 生成：自动生成符合档案局标准的“案卷封面”和“卷内目录”Word文档。
7. 输出：把所有整理好的文件打包成ZIP，供用户下载。

技术栈方面，选型也很清晰：

• Runtime: Node.js (Express)
• AI Engine: DeepSeek V3 (via API)
• Word Process: mammoth (读取内容), docxtemplater (生成模板)
• File System: fs-extra (增强的文件操作)

3. 核心代码深度解析

光说不练假把式，我们来看看关键代码，这个系统到底是怎么跑起来的。

3.1 启动自检与目录“防崩”设计

早期版本里，用户经常遇到ENOENT错误，原因就是上传目录不存在。所以我们在系统启动时加入了强制自检，确保万无一失：

// server.js 片段
const BASE_UPLOAD_DIR = path.join(__dirname, 'uploads');
const DOCX_UPLOAD_DIR = path.join(BASE_UPLOAD_DIR, 'docx_temp');
const RAW_FILE_DIR = path.join(BASE_UPLOAD_DIR, 'temp');

// 核心优化：启动即创建目录，防止找不到文件夹报错
fs.ensureDirSync(DOCX_UPLOAD_DIR);
fs.ensureDirSync(RAW_FILE_DIR);

设计意图很直接：用fs-extra的ensureDirSync，保证程序一启动，所有必备的基础设施就已经就绪，省得后面出幺蛾子。

3.2 解析Word表格（提取归档需求）

Word文档本质上是XML，直接解析非常痛苦。我们用了mammoth把Word转成HTML，再用cheerio（类似jQuery的库）来提取表格数据，这样容错性更好：

// 解析目录DOCX
const { value: html } = await mammoth.convertToHtml({ path: docFile.path });
const $ = cheerio.load(html);

$('table tr').each((i, elem) => {
    // 提取表格列
    const cols = $(elem).find('td').map((j, td) => $(td).text().trim()).get();
    // 启发式校验：第一列是数字才认为是有效数据行
    if (cols.length >= 3 && /^\d+$/.test(cols[0])) {
        items.push({
            seq: cols[0],       // 序号
            title: cols[3],     // 题名 (这是我们要去匹配的目标)
            // ...其他元数据
        });
    }
});

这种方式的优势在于，即使Word表格格式稍微不规范，只要它还是HTML表格结构，就能被正确读取，比直接解析XML要健壮得多。

3.3 AI大脑：DeepSeek语义匹配

这个模块才是真正的灵魂。传统的正则匹配（Regex）处理不了文件名差异，比如“合同扫描件”和“咨询服务合同”之间的模糊关系。但大语言模型天生就擅长这个：

async function callDeepSeekMatcher(rawFiles, targetItems) {
    // Prompt工程：明确任务、输入和输出格式
    const prompt = `
    任务：文件匹配。
    【原始文件名】: ${JSON.stringify(rawFiles)}
    【标准标题】: ${JSON.stringify(targetItems.map(t => ({ id: t.id, title: t.title })))}
    请根据语义将标准标题与原始文件名配对。
    要求：
    1. 忽略日期格式差异、版本号差异。
    2. 返回JSON格式: {"目标ID": "原始文件名"}。
    `;
    
    const response = await axios.post(DEEPSEEK_API_URL, {
        model: "deepseek-chat", 
        messages: [{ role: "user", content: prompt }],
        response_format: { type: "json_object" } // 强制JSON输出
    }, ...);
    
    return JSON.parse(response.data.choices[0].message.content);
}

亮点在于，我们利用了DeepSeek的json_object模式，确保AI返回的不是闲聊，而是机器可以直接读的结构化数据，后续处理起来非常方便。

3.4 自动化执行与容错

拿到AI的匹配结果后，Node.js就开始搬运文件了。这里处理了几个关键的工程问题：

1. 文件缺失处理：如果AI没找到匹配文件，就生成一个.txt占位符，提示人工后续补充，不会让流程卡死。
2. 非法字符清洗：Windows文件名不支持\ / : * ? " < > |这些字符，代码里自动替换成下划线，避免出错。
3. 格式强校验：直接拒绝老旧的.doc格式，避免解析器崩溃，同时给出友好的提示。

if (matchedName) {
    // 构造标准化文件名：01-01 标准题名.pdf
    const safeTitle = item.title.replace(/[\\/:*?"<>|]/g, '_');
    const finalName = `${volNum}-${seqNum} ${safeTitle}${ext}`;
    
    await fs.copy(srcFile.fullPath, path.join(targetFolder, finalName));
} else {
    // 优雅降级：生成缺失提示文件
    await fs.writeFile(path.join(targetFolder, `【缺失】${item.title}.txt`), "AI未找到匹配文件");
}

4. 踩坑与填坑记录

开发过程中，我们解决了几类典型问题，这些经验非常宝贵，值得总结一下：

4.1 ZIP乱码与上传超时

• 问题：最初允许用户上传几百兆的ZIP包。结果吐了，Nginx超时，而且Windows上传的ZIP解压后中文全是乱码（GBK vs UTF-8的老问题）。
• 解决：改成“本地目录扫描模式”。用户只需要把原始文件解压到服务器指定目录，网页端只上传轻量的Word目录文件。这样一来，既解决了乱码问题，上传速度也快，秒传秒开。

4.2 .doc vs .docx的噩梦

• 问题：用户上传了老版本的.doc文件，后端直接报错Can't find end of central directory。
• 原因：.doc是二进制文件，而.docx本质上是ZIP包。Node.js的现代库大多只支持ZIP结构的Office文档，对.doc无能为力。
• 解决：在后端增加严格的文件扩展名校验，遇到.doc直接抛出友好的错误提示，要求用户另存为.docx再上传。

4.3 临时文件夹丢失 (ENOENT)

• 问题：multer这个中间件不会自动创建上传目录，导致首次运行直接崩溃。
• 解决：引入fs.ensureDirSync，在应用启动层就解决环境依赖问题，确保目录永远存在。

5. 运行界面