做產品有意思的地方在於很多事情看上去理所當然，但做下去又是另一回事。
就像短網址的批次上傳。它在短網址服務裡可說是標配了，大家一開始都只有少量的縮網址需求，用著用著總會有突然要大量轉換的時候，一條一條轉太慢，就需要 Excel 大量上傳。
以前我為公司內部開發的短網址系統也是這樣，做完沒多久就馬上有人開需求，希望可以一次大量上傳。
這種就是屬於有了也不會因此得到用戶、但沒有就會失去用戶的功能。
既然後台有，那麼開發 API 的時候當然也要有。既然 API 有，想讓 AI 對話時也能做類似的事，是不是也應該要有。
但這三種管道面對的用戶與情境，其實都不太一樣。
後台的批次上傳接受 .xlsx 或 .csv，一次最多五百列，站上有範本可以下載，是付費方案才開放的功能。
這個機制說起來不難，就是解析 Excel 而已，難的是用戶的使用體驗。一筆一筆生成時用戶可以用肉眼確認，大批生成時要怎麼讓他也能一一確認。
toui 會在檔案讀進來後列出每一列的狀態，網址空白的標錯誤、格式不對的標錯誤、跟前面重複的作標示。讓用戶有機會先看過，再決定是否要動手生成。
當你針對 API 作批次上傳時，它會用陣列來收存，一樣是五百筆上限，但它不做預覽也不去重複。
去除重複這件事只在後台做。原因是人會犯的錯跟程式不一樣。一張從別處複製貼上的表，裡面有重複的網址是常態，而人在按下上傳之前，會想先知道自己那張表有沒有問題。程式不需要像用戶一樣先看一眼。它要知道的是送完之後哪幾筆沒成功。
所以 API 回傳的是一個結果陣列，每一筆帶自己的短碼，失敗的帶自己的錯誤。它不是全有全無，一批五百筆裡有三筆網址無效，另外四百九十七筆照樣建好。
API 這條也比後台多帶得動東西。逐筆可以帶社群預覽的標題與圖片、可以帶各自的管道標籤，整批可以指定一個活動名稱、可以決定要不要把標籤寫進目的地網址。這些欄位在後台的檔案裡沒有，因為要在試算表上排十幾欄，那張表大概就沒有人要用了。
第三條路是在對話裡把事情講完。「這三十條連結幫我縮，都放進春季活動，來源標 email。」
嚴格說它不是批次。模型是一條一條呼叫的，不是送一個陣列。AI 也不會把整份 Excel 上傳到 toui，因為 toui 沒說可以這樣做。就算那三十條連結就存在 Excel 裡，感覺和後台上傳很像，處理的邏輯仍然不同。以這個角度看，AI 這條路上是沒有批次上傳這個功能的。
但對手上只有三十條的人來說，這個差別不存在。他要的結果拿到了，而且他連檔案都不用開。在還沒有觸及 AI 呼叫上限之前，它可以一直處理下去，對用戶來說，依然像是有批次一樣。差別在速度，一條一條送本來就比一次送一個陣列慢，量越大越明顯。
這條路沒有預覽，也沒有結構化的結果回報。中間有一條沒建成功的時候，前面那些已經建好了，而你會不會知道，取決於你的 AI 會不會回頭去確認。
寫這篇文章時我自己試著跑三十條。第一次用 ChatGPT，跑完少了一條，是 AI 自己回頭去數那個活動底下有幾條、發現只有二十九條，才把漏掉的那條補上。它做得到，但這件事沒有寫在任何規格裡，是它自己決定要做的。
第二次換 Claude，它沒有一條一條送，而是自己先做了一個小工具再跑。那個工具有併發控制、有逐列的紀錄、有失敗重試，中間失敗的那一條是它自己重試補回來的，最後還把結果匯成一張表。那正好是後台和 API 各自提供的那些東西，只是這次長在對話那一端。
我看到的樣子，不一定是別人會看到的樣子。AI 的介面和行為我們保證不了，換一個模型、換一次對話都可能不同。但有一件事我有把握，批次送出這個行為我們沒有提供，AI 確實讓它變得可行，而且送出前後它多半會自己再確認一次，或是做個工具來確認。
這就是我們在這一端沒有多做的原因。toui 能做的，是跟 AI 說清楚它能做什麼、不能做什麼。剩下的空間留給用戶和他的 AI 去找出自己的作業方式。
在 API 上把後台那套「送出前先看一遍」複製一次，做起來麻煩，而且很可能沒有必要。三種管道的用戶要的東西其實不一樣，人要在送出前看見，程式要在送出後知道哪幾筆漏了，而在對話裡的人，兩個都沒有也還是覺得夠用。
而管道的差別也不只在體驗上。批次上傳在 toui 是付費方案才開放，但對話那條走的不是同一個閘，免費的層級就能用到批次的效果，只要不碰到呼叫上限。
所以同一個功能換到不同的管道，1:1 照搬多半不是正確的作法。動手之前要問的不是「這個功能怎麼搬過去」，而是「這個管道的用戶，是靠什麼確認事情做完了」。而那個答案有時候會是，這個管道不需要你做。
AI工作流：Claude為30條網址的上傳工作自動生成一個工具，以便進行上傳
AI工作流：ChatGPT透過 MCP Server 上傳時會自動檢查，補完上傳失敗任務
iThome鐵人賽
看影片追技術