Naly 工程筆記：以 Vercel Blob 作為生成文章資產的不可變媒體層

摘要

TL;DRNaly 將 Vercel Blob 用作生成媒體的發布邊界：封面圖片與社群圖片由文章管線建立、上傳為公開 blob，並以穩定 URL 回寫到文章資料列，供主視覺、卡片與 Open Graph 介面使用。這項技術作為儲存 bucket 的意義較小，更重要的是它代表一種紀律：文章一旦發布，其視覺證據就應該可定址、可快取、可重現。

論點：生成文章媒體應被視為發布產物。模型可以是機率性的，但已發布的資產必須穩定。Vercel Blob 為 Naly 提供了處理這個邊界的實用物件儲存介面，而 Next.js metadata 與文章渲染則把儲存的 URL 轉化為分發介面。

它在 Naly 中的位置

Naly 的文章系統運行在 Next.js 與 React 應用程式堆疊上，並使用 Drizzle ORM 與 Neon 管理關聯式狀態。生成媒體位於編輯生成步驟與公開文章頁面之間：

文章管線會生成封面圖片與社群圖片。
媒體位元組會使用 @vercel/blob.
回傳的公開 URL 會被寫回文章資料列。
文章頁面會讀取這些 URL，用於主視覺圖片、列表卡片圖片，以及 Open Graph 或社群預覽圖片。

這個配置刻意保持平淡。文章資料庫仍是編輯真相來源，而 Blob 儲存較重的二進位產物。爬蟲、社群抓取器、feed 消費者或讀者不需要重現圖片生成工作，只需要一個持久 URL。

技術機制

Vercel Blob 是用於在建置時間或執行時間上傳檔案的物件儲存。官方概覽將封面圖片、影片、截圖與其他展示或下載檔案列為自然使用情境，這直接對應到 Naly 的生成文章媒體。公開 Blob 儲存也是這類資產的正確存取模式，因為任何持有 URL 的人都能直接讀取，而寫入仍需要已驗證的 token。

關鍵 API 形態是伺服器端 put 操作。Naly 風格的上傳合約應將五個值綁定在一起：

pathname: 穩定的命名空間，例如 articles/{articleId}/cover-{hash}.webp 或 articles/{slug}/og-{hash}.png.
body: 生成的圖片位元組。
access: public 用於已發布的文章媒體。
contentType: 精確的圖片 MIME 類型。
cacheControlMaxAge: 與不可變發布行為相容的值。

SDK 會回傳 metadata，例如 pathname, url, downloadUrl, contentType, 和 etag. Naly 只需要公開 URL 來渲染，但額外的 metadata 對對帳與稽核很有用。更強的實作會儲存 URL，加上內容雜湊、尺寸、MIME 類型、生成 prompt 雜湊、模型識別碼與上傳時間戳。這會把圖片資料列從指標變成證據紀錄。

不可變設計選擇是避免覆寫路徑。Vercel 的 SDK 支援隨機後綴，且預設會拒絕相同路徑覆寫，除非明確允許 overwrite。Naly 應順著這個預設：修訂後的圖片取得新的物件 URL，文章資料列再更新為指向新物件。這避免了媒體發布中最棘手的快取問題：瀏覽器與抓取器快取仍保留舊位元組，而資料庫卻認為資產已變更。

在服務端，公開 Blob URL 可透過 Vercel 的 CDN 擷取。Next.js 接著有兩條常見路徑：直接在文章 UI 中渲染儲存的 URL，並透過 metadata 輸出到 Open Graph 與 Twitter 預覽。Next.js 也支援生成式 Open Graph routes，但對 Naly 的生成媒體而言，重要差異是持久性。圖片應生成一次、儲存，然後被引用。請求時圖片生成適合確定性的範本；持久化的 Blob 資產更適合機率性的視覺生成。

文獻怎麼說

儲存文獻反覆指出一點：穩定名稱與穩定內容是不同的事。IPFS 將內容定址模型形式化，讓連結識別內容，而不是可變位置。Naly 不需要 IPFS 來發布文章圖片，但底層教訓適用：如果位元組重要，當位元組改變時，識別碼也應改變。

後續關於以 IPFS 實作去中心化雲端儲存的研究，是對過度浪漫化內容定址的有用警示。去中心化系統帶來可用性、發現與營運取捨。Vercel Blob 是集中式代管物件儲存，因此本身不提供獨立的公開驗證。它的優勢是營運簡單：Naly 可以取得持久物件儲存、公開傳遞與 SDK 整合，而不必運行點對點儲存網路。

生成媒體文獻加入了第二項要求：來源證明不是可選項。近期關於 AI 生成圖片浮水印的 arXiv 研究，綜述了在編輯、壓縮與對抗性移除之下，讓生成圖片身分保持穩健的困難。另一篇 2026 年論文提出用於 AI 生成圖片來源證明的感知雜湊註冊表，強調一旦媒體被複製與轉換，精確位元組身分就過於脆弱。

對 Naly 而言，實務結論比全球來源證明系統更窄。Blob URL 與資料庫資料列不能證明普遍真實性。它們確實給了 Naly 一套受控的發布帳本：這篇文章使用了這張生成圖片，在這個時間上傳，帶有這個雜湊與 metadata。這足以除錯發布失敗、重現編輯決策，並讓社群預覽與已發布紀錄保持連結。

設計取捨

不可變 URL 在信任上勝過覆寫，但需要生命週期管理。舊的被拒圖片可能變成孤立儲存，除非管線明確標記候選、勝出與已被取代的資產。

公開 Blob 存取能改善分發與快取，但在編輯核准前並不適合。草稿資產應保持私有、使用獨立儲存，或只在文章獲准發布後才上傳。

持久化生成媒體在可重現性上勝過請求時生成。代價是儲存與清理。好處是公開文章、卡片、RSS 消費者與社群預覽都會收斂到同一個視覺產物。

資料庫指標讓渲染保持簡單，但資料庫不能是唯一的稽核層。如果資料列只儲存 imageUrl, 之後的除錯工作無法區分問題是糟糕的生成、糟糕的上傳、錯誤的 MIME 類型，還是糟糕的資料列更新。儲存尺寸、內容類型、雜湊與 etag 會讓物件關係可檢查。

內容雜湊路徑名稱比隨機後綴更具確定性，但隨機後綴更容易，且 SDK 已經支援。務實的 Naly 模式是：方便時計算雜湊，可用時將其放入 pathname，同時仍保持 overwrite 停用。

失敗模式

第一種失敗模式是部分發布：上傳成功，資料庫更新失敗。結果是孤立 blob。這不會被讀者看見，但會產生成本與稽核雜訊。修正方式是建立對帳工作，列出近期 Blob 物件並與文章媒體資料列比對。

第二種失敗模式是斷裂指標：資料庫指向一個不可用、已刪除、私有或內容類型錯誤的 URL。發布步驟應在將文章標記為 ready 前，驗證回傳的 URL 與 metadata。

第三種失敗模式是快取偏斜。如果覆寫相同 pathname，Vercel 快取傳播與瀏覽器快取可能與新的資料庫狀態不一致。不可變 pathname 會讓這類錯誤大多消失。

第四種失敗模式是媒體過大。Vercel 的伺服器上傳文件特別指出伺服器上傳受 Vercel Function 請求 body 限制。生成文章封面在上傳前應先壓縮並限制尺寸；較大的媒體應使用用戶端上傳或 multipart 模式。

第五種失敗模式是預覽分歧。社群抓取器通常會積極快取 Open Graph 圖片。如果 Naly 更換圖片但保留相同 URL，舊預覽可能持續存在。新的位元組應意味著新的 URL 與 metadata 重新整理路徑。

第六種失敗模式是來源證明債。生成圖片可能在視覺上正確，卻失去 prompt、模型、來源文章與核准狀態的紀錄。應將媒體 URL 與生成 metadata 一起儲存，而不是作為孤立字串。

實作筆記

最小化的 Naly 實作應使用兩階段發布合約：

將媒體生成到記憶體或暫時外部儲存。
驗證 MIME 類型、尺寸、檔案大小與審核結果。
以公開存取且停用 overwrite 的方式上傳至 Vercel Blob。
在文章資料列記錄回傳的 URL 與 metadata。
從儲存的 URL 渲染主視覺、卡片與 Open Graph 介面。
將未被引用的 blob 對帳，與請求路徑分開處理。

文章資料列不應在文字、來源、生成媒體與 metadata 全部存在前，被標記為完全可發布。這給了 Naly 一個一致的 ready gate，而不是分散的 best-effort 介面。

對 Open Graph 而言，當圖片在語意上與生成文章綁定時，優先使用儲存的 Blob URL。將 Next.js 生成圖片 routes 用於確定性範本、fallback，或輕量文字預覽。差異在於圖片是否是之後需要稽核的產物。Naly 的生成封面就是產物。

建議的媒體 metadata 欄位包括：公開 URL、pathname、MIME 類型、位元組大小、寬度、高度、內容雜湊、Blob etag, 生成器名稱、生成 prompt 雜湊、來源文章 ID、核准狀態與上傳時間戳。URL 服務讀者；metadata 服務操作者。