1. 背景與痛點(diǎn)

在 IT 工程交付、政府項(xiàng)目或大型企業(yè)管理中，“資料歸檔” 往往是項(xiàng)目收尾階段最令人頭禿的環(huán)節(jié)。
C:\myApp\project-archive
場(chǎng)景通常是這樣的：

1. 原始文件一團(tuán)糟：你手里有一個(gè)幾百兆的文件夾，里面堆滿了 PDF、掃描件、Word 文檔，文件名五花八門（例如 2024-10-12 會(huì)議記錄_最終版.pdf）。
2. 歸檔要求極嚴(yán)格：客戶給了你十幾個(gè) Word 文檔（案卷目錄），每個(gè)文檔里有一個(gè)表格，規(guī)定了該案卷必須包含哪些文件，而且必須重命名為標(biāo)準(zhǔn)格式（例如 01-01 項(xiàng)目會(huì)議紀(jì)要.pdf）。
3. 人工耗時(shí)極長(zhǎng)：傳統(tǒng)的做法是人工逐個(gè)打開文件看內(nèi)容，然后去目錄里找對(duì)應(yīng)項(xiàng)，重命名，拖進(jìn)去……幾百個(gè)文件需要耗費(fèi)數(shù)天，且極易出錯(cuò)。

解決思路：
能不能寫個(gè)程序，讓它像人一樣“看懂”文件名，自動(dòng)跟目錄里的標(biāo)題配對(duì)？
答案是肯定的。通過(guò)結(jié)合 Node.js 的文件處理能力與 DeepSeek LLM（大語(yǔ)言模型） 的語(yǔ)義理解能力，我們構(gòu)建了一套自動(dòng)化歸檔系統(tǒng)。

2. 系統(tǒng)架構(gòu)設(shè)計(jì)

為了確保工具在實(shí)際工程中落地（可用、穩(wěn)定、抗造），我們經(jīng)歷了從“全云端處理”到“本地+云端混合”的架構(gòu)演進(jìn)。

核心流程

1. 輸入：用戶上傳多個(gè)“案卷目錄” Word 文件 (.docx)。
2. 掃描：后端自動(dòng)掃描本地磁盤的一個(gè)指定文件夾（存放所有雜亂的原始文件）。
3. 解析：提取 Word 文檔中表格的“序號(hào)”和“標(biāo)準(zhǔn)題名”。
4. 思考（AI Agent）：將“原始文件名列表”和“標(biāo)準(zhǔn)題名列表”發(fā)送給 DeepSeek API，讓 AI 進(jìn)行模糊語(yǔ)義匹配。
5. 執(zhí)行：根據(jù) AI 的匹配結(jié)果，自動(dòng)復(fù)制文件、重命名、分類存放到對(duì)應(yīng)文件夾。
6. 生成：自動(dòng)生成符合檔案 局標(biāo)準(zhǔn)的“案卷封面”和“卷內(nèi)目錄” Word 文檔。
7. 輸出：打包成 ZIP 供用戶下載。

技術(shù)棧

• Runtime: Node.js (Express)
• AI Engine: DeepSeek V3 (via API)
• Word Process: mammoth (讀取內(nèi)容), docxtemplater (生成模版)
• File System: fs-extra (增強(qiáng)的文件操作)

3. 核心代碼深度解析

讓我們通過(guò)分析 server.js 的關(guān)鍵邏輯，來(lái)看看這個(gè)系統(tǒng)是如何運(yùn)轉(zhuǎn)的。

3.1 啟動(dòng)自檢與目錄“防崩”設(shè)計(jì)

在早期的版本中，用戶經(jīng)常遇到 ENOENT 錯(cuò)誤，原因是上傳目錄不存在。我們?cè)谙到y(tǒng)啟動(dòng)時(shí)加入了強(qiáng)制自檢：

// 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');

// 核心優(yōu)化：?jiǎn)?dòng)即創(chuàng)建目錄，防止找不到文件夾報(bào)錯(cuò)
fs.ensureDirSync(DOCX_UPLOAD_DIR);
fs.ensureDirSync(RAW_FILE_DIR);

設(shè)計(jì)意圖：利用 fs-extra 的 ensureDirSync，確保無(wú)論部署在什么環(huán)境，程序運(yùn)行的第一秒，所有必要的基礎(chǔ)設(shè)施都已就緒。

3.2 解析 Word 表格（提取歸檔需求）

Word 文檔本質(zhì)是 XML，直接解析很痛苦。我們使用 mammoth 將 Word 轉(zhuǎn)為 HTML，再用 cheerio（類似 jQuery）提取表格數(shù)據(jù)。

// 解析目錄 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();
    // 啟發(fā)式校驗(yàn)：第一列是數(shù)字才認(rèn)為是有效數(shù)據(jù)行
    if (cols.length >= 3 && /^\d+$/.test(cols[0])) {
        items.push({
            seq: cols[0],       // 序號(hào)
            title: cols[3],     // 題名 (這是我們要去匹配的目標(biāo))
            // ...其他元數(shù)據(jù)
        });
    }
});

設(shè)計(jì)意圖：這種方式比直接解析 XML 更具容錯(cuò)性，即使 Word 表格格式稍微不規(guī)范，只要它是 HTML 表格結(jié)構(gòu)，就能讀取。

3.3 AI 大腦：DeepSeek 語(yǔ)義匹配

這是本系統(tǒng)的靈魂。傳統(tǒng)的正則匹配（Regex）無(wú)法處理文件名差異（如“合同掃描件” vs “咨詢服務(wù)合同”）。而 LLM 天生擅長(zhǎng)這個(gè)。

async function callDeepSeekMatcher(rawFiles, targetItems) {
    // Prompt 工程：明確任務(wù)、輸入和輸出格式
    const prompt = `
    任務(wù)：文件匹配。
    【原始文件名】: ${JSON.stringify(rawFiles)}
    【標(biāo)準(zhǔn)標(biāo)題】: ${JSON.stringify(targetItems.map(t => ({ id: t.id, title: t.title })))}
    請(qǐng)根據(jù)語(yǔ)義將標(biāo)準(zhǔn)標(biāo)題與原始文件名配對(duì)。
    要求：
    1. 忽略日期格式差異、版本號(hào)差異。
    2. 返回 JSON 格式: {"目標(biāo)ID": "原始文件名"}。
    `;
    
    const response = await axios.post(DEEPSEEK_API_URL, {
        model: "deepseek-chat", 
        messages: [{ role: "user", content: prompt }],
        response_format: { type: "json_object" } // 強(qiáng)制 JSON 輸出
    }, ...);
    
    return JSON.parse(response.data.choices[0].message.content);
}

亮點(diǎn)：我們利用了 DeepSeek 的 json_object 模式，確保 AI 返回的不是閑聊，而是機(jī)器可讀的結(jié)構(gòu)化數(shù)據(jù)。

3.4 自動(dòng)化執(zhí)行與容錯(cuò)

拿到 AI 的匹配結(jié)果后，Node.js 開始搬運(yùn)文件。這里處理了幾個(gè)關(guān)鍵的工程問(wèn)題：

1. 文件缺失處理：如果 AI 沒(méi)找到文件，生成一個(gè) .txt 占位符，提示人工后續(xù)補(bǔ)充。
2. 非法字符清洗：Windows 文件名不支持 \ / : * ? " < > |，代碼中自動(dòng)替換為下劃線。
3. 格式強(qiáng)校驗(yàn)：嚴(yán)厲拒絕老舊的 .doc 格式，避免解析器崩潰。

if (matchedName) {
    // 構(gòu)造標(biāo)準(zhǔn)化文件名：01-01 標(biāo)準(zhǔn)題名.pdf
    const safeTitle = item.title.replace(/[\\/:*?"<>|]/g, '_');
    const finalName = `${volNum}-${seqNum} ${safeTitle}${ext}`;
    
    await fs.copy(srcFile.fullPath, path.join(targetFolder, finalName));
} else {
    // 優(yōu)雅降級(jí)：生成缺失提示文件
    await fs.writeFile(path.join(targetFolder, `【缺失】${item.title}.txt`), "AI未找到匹配文件");
}

4. 踩坑與填坑記錄

在開發(fā)過(guò)程中，我們解決了幾類典型問(wèn)題，這些經(jīng)驗(yàn)非常寶貴：

4.1 ZIP 亂碼與上傳超時(shí)

• 問(wèn)題：最初允許用戶上傳幾百兆的 ZIP 包。結(jié)果導(dǎo)致 Nginx 超時(shí)，且 Windows 上傳的 ZIP 解壓后中文全是亂碼（GBK vs UTF-8 問(wèn)題）。
• 解決：改為**“本地目錄掃描模式”**。用戶只需將原始文件解壓到服務(wù)器指定目錄，網(wǎng)頁(yè)端只上傳輕量的 Word 目錄文件。既解決了亂碼，又秒傳秒開。

4.2 .doc vs .docx 的噩夢(mèng)

• 問(wèn)題：用戶上傳了老版本的 .doc 文件，后端報(bào)錯(cuò) Can't find end of central directory。
• 原因：.doc 是二進(jìn)制文件，.docx 是 ZIP 包。Node.js 的現(xiàn)代庫(kù)大多只支持 ZIP 結(jié)構(gòu)的 Office 文檔。
• 解決：在后端增加嚴(yán)格的文件擴(kuò)展名校驗(yàn)，遇到 .doc 直接拋出友好的錯(cuò)誤提示，要求用戶另存為 .docx。

4.3 臨時(shí)文件夾丟失 (ENOENT)

• 問(wèn)題：multer 不會(huì)自動(dòng)創(chuàng)建上傳目錄，導(dǎo)致首次運(yùn)行直接崩潰。
• 解決：引入 fs.ensureDirSync，在應(yīng)用啟動(dòng)層解決環(huán)境依賴。

5. 運(yùn)行界面

以上就是基于Node.js+DeepSeek打造一個(gè)智能檔案歸檔系統(tǒng)的詳細(xì)內(nèi)容，更多關(guān)于Node.js DeepSeek檔案歸檔的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論