AI 能做出像樣的軟體介面，能接住你的檔案嗎？
想像一個小團隊要把提案交給客戶。有人找到一套新文書工具，介面清爽，開啟檔案也沒跳出錯誤。文件寄出去，客戶重開後卻發現頁面換行跑了、表格擠出頁尾。這是用來思考遷移風險的假設情境，不是我測試任何一款軟體的結果。交件需要的能力，本來就不會全部出現在畫面上。
十月出現的 WordCraft、GridCraft、DeckCraft，讓這個問題變得具體。媒體報導它們是開發者 Brandon Thomas 借助 AI 製作的開源 Office 類型專案；WordCraft 的專案說明自稱支援 DOCX 讀寫，也標明仍在 alpha 階段。GridCraft 對自己的試算表格式相容性同樣保持保留。這些是早期專案與開發者的描述，不能據此斷言某份既有文件已能無損往返，更不能把它們寫成已經成熟的替代品。
畫面是入口，檔案才是交接
AI 讓一個人能更快把編輯器、工具列和可互動的原型做出來。想比較這類介面的做法，可以看看 生成式 UI 案例，裡面有不同產品的互動介面與原型；但這不是 Office 文件相容性的測試清單，也不能拿來替 WordCraft 等專案背書。
對要選工具的人來說，「能打開」只是起點。一份文件裡有中文字型、頁碼、表格、插圖和別人留下的修改；保存時還得讓下一個人用原本的工具接著工作。介面做得像，未必能保住這些細節。反過來說，一個外觀還不熟悉的工具也可能很好用，只是要先弄清楚自己願意在哪些檔案上承擔轉換成本。
我會把展示畫面和檔案往返分開看。前者讓團隊判斷操作是否順手；後者決定這份工作能否交出去。兩者都重要，但前者通過，不能代替後者的驗收。
先拿一份不怕退回的文件試
假設手上有一份對外提案，先留下原始 DOCX，在內部做一份移除個資的複本，別拿正在交件的唯一版本試。用候選工具打開複本，改動一小段文字，另存或匯出；再請同事用團隊原本的工具重開輸出檔。要看的不是檔案能否開啟而已，而是中文字有沒有變形、頁碼與換行是否還對、表格及圖片的位置有沒有改變。請同事實際接續修改一次，才能看到交接處會不會卡住。
如果測的是試算表，檢查項目要換成公式、儲存格格式與工作表結構；不能拿文書工具的測試結果替試算表下結論。每次發現失真，就記下檔案類型、最小重現步驟和回退方法。這套流程只是我建議的驗證方式，並非上述產品的實測紀錄或通過率。
做這種小範圍試驗會比較慢，尤其在大家想趕快擺脫昂貴訂閱的時候。但若團隊一開始就把正式提案當測試檔，最後替工具補洞的人很可能是收件的客戶。先保留原工具和原檔，並不是否定新選項，而是讓試用還有退路。
出問題時，找得到誰來修嗎
檔案第一次往返成功，後面還會遇到新樣板、新版本，或合作方寄來一份結構複雜的舊文件。這時評估一個替代品，我會去看它怎麼收問題、哪些格式限制已經寫清楚，以及有人回報失真後是否有修補的路徑。開源本身提供了參與修復的可能，卻沒有保證維護者能及時替每個團隊處理壞掉的檔案。
對獨立開發者也是一樣：做出一個令人願意點開的介面，是產品的開始。真正難的是接下那些已經在流通的工作，以及使用者下週還會帶回來的問題。要不要換工具，最後不必由一張功能對照表決定。拿一份自己的文件走完交接，看看對方能不能接著做；不行時，至少知道怎麼退回。
資料來源與範圍
產品與報導原頁在準備本文時無法直接擷取全文；上述概述依據同日來源摘要及可讀的搜尋索引片段，不代表對原始文件的完整審讀。本文沒有實際操作這些專案，也沒有測試 DOCX 或試算表往返；提案交接只是供讀者自行驗證的假設情境。