做法參考自文章：Raven AI 週報

這篇記錄的是我實際照著概念落地時，每一步怎麼做、又在哪裡卡住。

Step 0｜先申請 Notion Integration（這一步不先做，後面都不用談）

在開始建資料庫、寫程式之前，我先處理的是 Notion Integration。

因為只要你打算用程式寫入 Notion，

不管是 GAS、n8n 還是其他工具，這一步一定逃不掉。

實際做法

1. 前往 Notion Integration 管理頁

   https://www.notion.so/my-integrations

2. 建立一個新的 Integration

   • Name：隨意（例如 Drive Import Bot）
   • Associated workspace：選你要用的 Notion 工作區
   • Capabilities：至少開啟 Read / Insert / Update

3. 建立完成後，Notion 會給你一組

   Internal Integration Token

這組 token 之後會放進 Google Apps Script 的 Script Properties，

程式碼本身不會直接寫死。

⚠️ 這一步還沒結束

Integration 建好之後，還必須被加入到你要操作的 Database，

否則 API 會直接回傳權限錯誤。

Step 1｜先把 Notion Database 建好（而且一開始就為 API 想）

我第一個實際建立的東西，不是程式，而是 Notion Database。

欄位設定刻意保持簡單：

有一個當下沒特別意識到、但後來救了我很多時間的決定是：

欄位名稱一開始就不用空白、不混用格式，直接當作 API key 在命名。

等到真的開始呼叫 Notion API 才發現，

如果這一步偷懶，後面會非常容易踩到「欄位不存在」的雷。

Step 2｜把 Integration 分享進 Database（很多人會漏）

Database 建好之後，我做的下一件事是：

• 打開該 Database
• 右上角點選 Share
• 把剛剛建立的 Integration 加進來（給可編輯權限）

這一步如果沒做：

• 就算你有 token

• 就算 database ID 是對的

  Notion API 一樣會拒絕你。

Step 3｜準備 Google Drive 的「收檔資料夾」

接著我在 Google Drive 建了一個專門用來丟檔案的資料夾，例如：

AI_IMPORT

這個資料夾我一開始就幫自己訂了一個規則：

只放「原始輸入檔」

不放任何轉檔後、處理中產生的檔案。

當時只是直覺這樣分，

直到後面真的踩坑，才知道這個決定有多重要。

Step 4｜寫第一版 GAS：掃資料夾 → 轉文字 → 存 Notion

第一版 Google Apps Script 的流程其實很直線：

1. 定時掃描指定的 Drive 資料夾
2. 找出尚未處理的檔案
3. 依檔案類型轉換
4. 擷取文字
5. 建立一筆 Notion Page

Script Properties 中只放三個值：

• NOTION_TOKEN
• NOTION_DATABASE_ID
• DRIVE_FOLDER_ID

程式碼裡不寫死任何 ID 或 token，

這樣之後專案要搬、要重用都比較乾淨。

Step 5｜第一個卡關：Notion API 說「欄位不存在」

程式第一次寫入 Notion 時，API 直接回傳：

DriveFileId is not a property that exists

ProcessedAt is not a property that exists

最困惑的是：

這兩個欄位我在 Notion 介面裡明明看得到。

後來實際用 API 把 Database schema 抓出來才發現：

• Notion UI 顯示的欄位名稱
• 不一定等於 API 實際使用的 property key

最後的修正方式很單純：

直接把 Database 欄位名稱統一調整成 API 可預期的格式，

而不是在程式裡硬寫一層對應表。

Step 6｜第二個卡關：Excel 無法轉成 Google Docs

解完欄位問題後，Word、PDF 都能正常進 Notion，

但只要上傳 Excel，就立刻報錯：

The requested conversion is not supported

查了 Drive API 的轉檔規則後才發現：

• Word → Google Docs：可行
• PDF → Google Docs（OCR）：可行
• Excel → Google Docs：不支援

Excel 正確的處理路徑其實是：

Excel → Google Sheets → 逐格讀取文字

於是我調整實作方式：

• Excel 先轉成 Google Sheets
• 讀取每個 Sheet、每一個 cell
• 用純文字（tab + 換行）存進 Notion

雖然格式會消失，但內容完整保留，

對後續給 AI 使用反而更友善。

Step 7｜第三個卡關：系統開始處理「自己生出來的檔案」

當三種檔案都能順利進 Notion 後，

我注意到一個不太對勁的現象：

• 第二次執行程式
• 即使沒有新上傳檔案
• 還是開始處理一堆東西

原因其實很單純。

為了轉檔，我用了 Drive.Files.copy()，

Drive 真的會產生新的檔案：

• Word → Google Docs
• Excel → Google Sheets

而這些新檔案，預設會被放回原本的資料夾。

也就是說，監控資料夾裡同時存在：

• 原始輸入檔
• 系統產生的中介檔

於是系統開始分析自己剛剛生出來的東西。

Step 8｜最後的修正：用資料夾結構切開「輸入」與「處理」

這一關我沒有再用 if 判斷或檔名規則硬擋，

而是直接調整結構。

我多建了一個資料夾：

AI_TEMP

所有轉檔產生的 Google Docs / Sheets，

一律指定輸出到 AI_TEMP。

最後整個結構變成：

📂 AI_IMPORT   → 只放原始檔（監控）
📂 AI_TEMP     → 中介檔（不監控）

這一步完成後：

• 重複處理問題直接消失
• 去重邏輯變得單純
• 整條流程才真的穩定下來

最後回頭看：我其實不是在「串服務」

把整個流程跑順之後才發現，

我做的事情已經不是單純自動化，而是：

設計一條會長期累積資料、未來要被 AI 使用的資料管線

很多問題不會在第一次執行時出現，

而是在第二次、第三次，

當系統開始處理歷史資料時才慢慢浮現。

🤖 延伸：我現在會這樣問 GPT

請你站在「長期可維護的資料管線設計」角度，

檢視以下自動化流程在多次執行後，

是否可能出現資料污染、來源混淆或重複處理的風險。

請不要只檢查 API 或語法，

而是聚焦在資料來源、轉換層與儲存層的邊界是否清楚。