SVG 形狀塊只有在每一個控制其外形的輸入都保持不變，且隨機來源被替換成固定種子時，才會重複生成。SVG Blob Generator 接受四個使用者控制的輸入——頂點數量、不規則度、畫布大小和填色——並為每次結果指派一個無符號 32 位元種子，顯示在預覽圖下方——同時使用確定性的產生器，讓相同的輸入必定產生相同的點、相同的路徑指令，以及相同的序列化標記。這個形狀不會因為瀏覽器、作業系統、時間，或任何伺服器端的隨機性而有所不同，因為新隨機性進入系統的唯一時機，就是你按下「Randomize Shape」按鈕的那一刻。這代表頁面可以進行水合(SSR 之後),React 元件可以重新渲染，瀏覽器可以重新繪製，都不會悄悄改變你剛才看到的輪廓。同樣的五個數值，無論在任何電腦、任何稍後的日期，透過任何複製貼上或下載的檔案重新使用，都能逐位元組重建出同一個形狀。
「我剛剛很喜歡那一個」與「頁面卻無法重現」之間的落差，是生成式形狀的典型痛點。形狀塊是一條封閉曲線，穿過圍繞中心點散佈的若干頂點，然後以二次貝茲曲線進行平滑處理。如果這些點的座標來自未播種的隨機呼叫，那麼每次重新整理、每次渲染、每次重新開啟分頁，以及每位同事的機器上，幾何都會被重新繪製一次。你精心搭配到某個版面配置的形狀，在任何人離開頁面的瞬間就消失了。
這就是為什麼可重複的 SVG 形狀塊既是設計系統的問題，也是繪圖的問題。行銷團隊、前端團隊與 CMS 範本，都需要相同的輪廓、相同的曲線、相同的填色，以及相同的畫布尺寸。沒有確定性的來源，要讓所有人對齊的唯一方式，就是散發一個凍結的檔案，然後永遠不再碰觸那些控制項。有了確定性的來源，你散發的會是五個小數值，而不是一千位元組的標記。
為什麼大多數 SVG 形狀塊每次都會不一樣
任何瀏覽器內建隨機產生器的預設行為，就是每次呼叫時都產生不同的序列。即使兩個分頁執行相同的程式碼，瀏覽器內建的隨機來源在分頁之間、工作階段之間，以及裝置之間，也不會同步。每次呼叫都會推進一個頁面無法讀回的內部狀態，所以同一個產生器函式，在星期一早上回傳的數字，跟在星期五下午回傳的數字並不相同。
三種行為結合起來，讓「隨機」的形狀塊變得不穩定:
- 產生器會在每次載入頁面時隱式地重新播種，所以重新整理就等於新的形狀。
- 產生器會在每次函式被呼叫時推進狀態，所以新增一個頂點或移動一個滑桿，可能會重新排列所有其他的點。
- 輸出會在無法預期的時機被複製或下載，所以你貼到編輯器裡的位元組，可能跟剛才看到的位元組並不一致。
如果只是裝飾用的背景，差異或許不大，但如果是主視覺插圖、卡片遮罩，或品牌識別元素，不穩定就完全無法接受。這個形狀必須能從產生器往返到版面檔案，從版面檔案傳給同事，從同事上到正式部署，再從正式部署回到重新設計階段，而且每一個步驟都要保留原本的輪廓。
SVG Blob Generator 為何能做到可重複
SVG Blob Generator 用一個無符號 32 位元的種子，取代未播種的隨機來源;這個種子是在按下「Randomize Shape」時產生的。種子會在產生的瞬間顯示在預覽圖下方，而同一組五個數值的組合——頂點數、不規則度、大小、顏色和種子——也是路徑建構器唯一會接收的輸入。由於所有內部運算都是這五個數值的純函式，兩台執行相同程式碼、設定與種子的電腦，所產生的路徑資料，會精確到最後一個四捨五入後的座標都完全一致。
有兩個設計決策值得注意，因為它們防止了困擾其他產生器的隱性漂移。第一，只有在按下「Randomize Shape」按鈕時才會呼叫隨機函式;React 渲染路徑或版面引擎中的任何程式碼都不會碰觸隨機來源，因此父元件觸發的重新渲染，或水合(SSR)不一致，都不會改變輪廓。第二，只要控制項一有變動，路徑就會從頭重新生成，所以你所看到的點，正好就是「Copy SVG」動作與「Download SVG」連結會序列化的點——不會有預覽快取跟匯出內容不同步的問題。
實作上也會在序列化時將座標四捨五入到小數點後兩位。這個選擇讓標記既保持人類可讀、在重新生成時保持穩定，同時對於 256 到 1024 像素之間可用的畫布大小來說，又保留了遠超所需的精度。重複執行會產生完全相同的字串，而不只是視覺上相似的形狀。
從產生器重複得到相同結果
實際的工作流程很短，每一步只有單一目的。依序重複這些步驟，你保留的檔案就會與日後能再次產生的檔案一致。
- 開啟 SVG Blob Generator，把頂點數、不規則度、畫布大小和填色設定為你預期的值。
- 反覆按下「Randomize Shape」，直到預覽符合你的版面需求，然後讀取顯示在結果下方的無符號 32 位元種子。
- 把這個種子與你在步驟一設定的四個形狀數值一起記錄下來——寫成設計檔案裡的註解、工單，或共享的筆記。
- 複製 SVG 標記或下載 SVG 檔案，貼到或上傳到你的設計工具、CMS 或程式碼儲存庫中。
- 若要在另一台機器上或日後重建同一個形狀塊，請回到產生器，輸入相同的四個數值，然後反覆按下「Randomize Shape」，直到顯示的種子與你記錄的種子相符，預覽圖就會與原本逐位元組完全一致。
- 比對新檔案中的路徑資料字串與先前儲存的路徑資料字串，以進行驗證。
步驟三是大部分團隊會跳過、之後又後悔的一步。光有種子並不夠——如果同事把頂點數打成「eight」而不是「8」，或不規則度打成「40」而不是「60」，半徑分佈就會改變，即使種子相符，輪廓也會漂移。請把這五個數值視為一筆單一的紀錄。
必須完全保持一致才能重現的輸入
每個控制項都有明確定義的範圍，以及明確定義的對輸出效果。下表摘要說明每個輸入的作用，以及產生器接受的範圍。任何超出所述範圍的值，都會被產生器拒絕，而不是被悄悄夾住，所以種子欄位或不規則度滑桿的打字錯誤，會產生錯誤，而不是悄悄產生一個不同的形狀。
| 輸入 | 接受範圍 | 對形狀塊的效果 |
|---|---|---|
| 頂點數 | 3 到 12 的整數 | 在畫布中心周圍以等角間隔放置的放射狀錨點數量 |
| 不規則度 | 0 到 100 | 每個頂點的半徑變化;0 會得到圓形，100 則允許在安全邊界內的最大分散程度 |
| 畫布大小 | 256 到 1024 px 的正方形畫布，可透過三組實用的預設值設定(已測試邏輯範圍 128–1024) | 匯出 SVG 的寬度、高度，以及對應的 viewBox |
| 填色 | 嚴格的六位數十六進位色碼，例如 #3A6FF8 | 套用至單一路徑元素的單一填色 |
| 種子 | 無符號 32 位元整數，顯示在預覽圖下方 | 透過播種後的產生器，決定每個頂點所分配到的半徑 |
頂點是圍繞畫布中心以等角間隔放置的，所以把頂點數從 6 改成 8，會把既有的半徑重新分配到新的角度，而不是在原本的角度上新增更多點。這就是為什麼較高的頂點數會讓輪廓感覺更細緻，卻不會改變背後的半徑分佈;同樣地，這也是為什麼頂點數變更是一種實質的形狀變更，而不只是外觀上的調整。
可重複性仍然可能破功的地方
產生器內部的確定性是必要條件，但並非充分條件。形狀塊必須能從產生器一路存活到它最終的落腳處，而三個常見的目的地會施加各自的限制。
電子郵件用戶端與部分 CMS 的清理機制，會移除行內 SVG、刪除路徑屬性，或在標記本身有效時仍拒絕資料 URL。W3C SVG 2 路徑規格定義了產生器所依賴的指令——移動(moveto)、二次貝茲(quadratic Bézier)，以及閉合(closepath)——所以輸出的檔案本身符合標準，但目的地仍可能改寫或拒絕它。若想從瀏覽器實作的角度了解這些指令如何被解析，MDN 的 path 元素參考是很好的對照資料。
點陣化轉換，從定義上就會破壞可重複性。如果 SVG 被扁平化成 PNG 用作背景圖，向量幾何就消失了，座標也消失了，未來的任何種子值都無法重現那些像素。「Download SVG」連結匯出的是貨真價實的向量文字，但只要下游工具把它點陣化，該檔案就不再能單純從輸入重現。
過高的不規則度，也可能會在 1024 px 看起來優美、在 64 px 看起來卻很擁擠的尖銳轉折。匯出的座標精度並不會隨頂點數增加，所以相同大小、相同種子會產生相同的字串，但在小尺寸下的視覺份量感可能截然不同。請在形狀塊會出現的最小尺寸下檢查預覽，再決定是否記錄這組數值。
與協作者分享可重複的 Blob
一旦記錄下這五個數值，分享就變成文件撰寫的問題，而不是生成圖形的問題。依據對象不同，兩種格式都很好用。對開發者來說，把 SVG 標記貼到共用的元件檔案中，並加上註解列出產生它的五個輸入值。對在 Figma 或 Illustrator 中工作的設計師來說，下載 SVG，放入設計系統資料庫，然後附加便利貼或圖層名稱，其中包含種子、頂點數、不規則度、大小與顏色。
下載的檔名已經內嵌了種子，這對於防止意外重新命名是很有用的防護機制。即便如此，仍應將種子視為中繼資料，而不是身分識別。兩個頂點數不同但種子相同的 blob 並非相同的 blob —— 半徑是分布在不同數量的角度位置上。每次都要把五個值一起儲存。
若想初步了解介面和每個滑桿的意義，SVG Blob Generator 入門指南從設定的角度介紹了相同的控制項。當重複執行的結果與原本不符時，修正外觀錯誤的 SVG blob 結果指南會逐步檢查常見的原因，包括打錯的種子，以及看似相同但某個色通道有差異的 HEX 值。
可重複性正是讓生成式形狀從一次性的裝飾元素轉變為穩定素材的關鍵。只要記錄下這五個數值，並在目標環境中測試過檔案，這個輪廓就能在版本控制、團隊成員交接與重新設計的過程中保持不變，不會偏離原本的樣貌。