從 Word 檔到互動時間軸：一條半自動的路

整理《艷世紀》一段地方大事紀時，素材攤在桌上的樣子，永遠是這樣：一個我們自己愈存愈亂、叫「大事紀(最終版)_修改3.docx」的檔案，和一個資料夾，裡面兩百多張田野拍回來的照片，檔名還是相機自動編的 IMG_4821。

Word 裡面沒有表格。年份、事件、人名混在敘述句裡，有的段落開頭寫「民國七十二年」，有的寫「1998 那年」，還有一段直接說「隔年冬天」——隔哪一年的冬天，要往上讀三段才知道。這不是誰的錯，這就是一份給人讀的文件本來的樣子。問題是，我們要把它變成一條能在瀏覽器裡滑動、點開、跳年份的互動時間軸。

這篇記的是中間那條路。它是半自動的——一半是機器省下的力氣，一半是我們刻意留在手上的判斷。

第一步：先把文件攤平，而不是急著理解它

新手容易犯的錯，是一拿到 Word 就想讓 AI「讀懂並生成時間軸」。我們試過，結果是機器很自信地編了三個根本不在原文裡的事件，年份還都對得很漂亮。

所以現在第一步反過來：先不要求理解，只要求不遺漏。

我們把 docx 轉成純文字，連同段落順序、標題層級一起保留。這一步是純機械的，沒有 AI 介入。目的只有一個——確保後面每一個結構化的條目，都能往回指到原文的某一段。這條「回溯線」很重要，是後面人工查核的命根子。

第二步：讓 AI 猜結構，但要它承認自己在猜

這是 M-01（田調資料結構化引擎）真正上場的地方。

我們給模型的指令，不是「幫我做時間軸」，而是「把這段文字拆成事件條目，每一條標出：年份、事件標題、原文出處段落、以及你對年份的把握程度」。

最後那欄——把握程度——是整個流程的關鍵設計。我們要的不是一個乾淨漂亮、看起來全對的 JSON，而是一個誠實標出自己哪裡不確定的 JSON。

輸出大概長這樣：

{
  "year": 1983,
  "year_raw": "民國七十二年",
  "title": "溪邊的舊橋改建",
  "source_paragraph": 4,
  "confidence": "high"
}

遇到「隔年冬天」那種，confidence 就會是 low，year 欄位機器會給一個推測值，但同時老實說「這是從上文推算的」。這些低把握的條目，後面會被自動挑出來，排在人工查核清單的最前面。

機器一次跑完兩百段，大概十分鐘。省下的就是這十分鐘背後、原本要一條一條敲進試算表的一整個下午。

第三步：人工查核——這一關我們不讓

到這裡，誘惑很大：JSON 有了，時間軸幾乎能直接生成了，為什麼不一鍵到底？

因為機器省下的是整理的力氣，不是判斷的責任。以下這幾件事，我們堅持留在人手上：

• 年份的最終定奪。 「民國七十二年」換算 1983 機器不會錯，但「隔年冬天」到底是哪一年，常常要翻回田野筆記、必要時再走一趟現場問清楚。這一步，AI 做不了。
• 事件的取捨。 原文一百多個時間點，不是每一個都該進時間軸。哪些是關鍵轉折、哪些只是背景，這是敘事判斷，是我們作為設計者的觀點，不外包。
• 照片配對。 兩百張 IMG_開頭的照片配到哪一年、哪個事件，機器完全幫不上——它讀不出照片裡那座橋是改建前還是改建後。這一步是純人工，靠的是把照片一張張打開，對著原文的描述慢慢認。

查核完的清單，我們會把每一次「機器猜錯、人工改對」的地方記下來。不是為了究責，是因為這些錯誤有模式——久了就知道模型在哪類年份表述上特別容易失手，回頭去修指令。

第四步：結構化資料生成時間軸，這一步又交回機器

人工查核過的 JSON，乾淨了，也可信了。這時候再讓機器接手，就安全了。

一份確認過的 JSON，同一份資料可以餵給不同的前端：網頁上是可滑動、可跳年份的互動時間軸（這部分接的是 M-02）；未來要做成展場的觸控牆、或印成一張長折頁，底層資料完全不用重做。這也是我們一開始堅持要「結構化」而不是「直接生成畫面」的原因——資料乾淨了，才有再製的餘地。

回頭看這條路

整條流程走下來，機器碰了兩頭——把文件攤平、把資料變成畫面；人守住了中間——判斷年份、取捨事件、認出照片。

我們不覺得這是「AI 還不夠強所以人得補位」。恰恰相反：把繁瑣的整理交給機器，人才有餘力去做那些真正需要判斷的事——回頭翻筆記、走一趟去確認那個年份，決定哪個時間點值得被記住。

半自動，不是通往全自動路上的一個過渡站。它就是我們想停下來的地方。