最近看到一個滿有意思的文件工具案例：作者把二十多個 PDF 小工具整理成瀏覽器端的 node-based workflow，使用者可以串起抓圖、轉檔、合併、加密，以及 AI OCR 等步驟。HN 上的反應其實不算熱烈，所以我不會把它當成產品成熟度的證明。對我來說，它更像是一個很好的系統設計問題：當 OCR 或 LLM 被放進文件流程，真正決定能不能用的，通常不是 prompt 寫得多漂亮。

第一個關鍵是輸入輸出契約。OCR 節點收到的到底是整份 PDF、單頁影像，還是帶有版面座標的文字區塊？輸出是純文字、欄位 JSON，還是每個欄位都附上來源頁碼與信心資訊？如果契約不清楚，下一個節點只能靠猜測接資料，流程看起來能連線，實際上卻很難驗證。嚴格來說，讓模型輸出 JSON 不等於建立了可靠契約，還需要 schema validation、型別檢查，以及遇到缺欄位時明確失敗。

第二個關鍵是人工檢查點。文件中的姓名、金額、日期或合約條款，不應該因為模型給出一個流暢答案就直接進入下游系統。比較合理的做法是在高風險欄位旁保留原始片段，讓人能快速核對，並設定低信心或格式異常時暫停。這不是否定自動化，而是把人的注意力集中到模型最可能出錯、也最值得追責的地方。

第三個關鍵是失敗的可重跑性。大型 PDF 可能只在某幾頁 OCR 失敗，外部模型也可能逾時或回傳不完整結果。若每次都只能從頭跑，不僅浪費成本，也會讓使用者不敢修正流程。節點應該保存輸入雜湊、版本、參數與中間結果，支援從失敗節點重跑，並且讓重跑結果可以和前一版比較。這些看似無聊的紀錄，往往比再加一個更大的模型更能提升實際可靠性。

最後是隱私邊界。主要處理在瀏覽器端，確實能減少文件上傳的範圍，但只要 OCR 節點呼叫雲端 LLM，就要清楚標示哪些頁面、哪些欄位會離開裝置，是否會被保存，以及使用者能否改用本地模型。視覺化流程的價值，正在於把這些資料流與權限變得可見。AI 節點不是魔法方塊，而是帶有成本、錯誤率與資料風險的系統元件。把它放進工作流後，prompt 只是其中一個可調參數，契約、檢查、重跑和邊界才是產品能否被信任的基礎。