--- title: 食品3D列印卡關，八成是配方不是機器 lang: zh-Hant source: https://mindsprt.dev/zh-TW/knowledge/research-brief-rheology-tunable-food-3d-printing-ink/ --- # 食品3D列印卡關，八成是配方不是機器 *麥策研究室 · 8 分鐘閱讀 · 2026-08-18* > 客戶拿造型圖來，你報得出印刷規格，卻報不出「這團料撐不撐得住」。食品3D列印的成敗多半在墨水的流變窗口，不在噴頭。這篇把配方，擠出，成形這條鏈拆成打樣現場問得出口的三個問題。 **快速解答:** 客戶拿造型圖來，你報得出印刷規格，卻報不出「這團料撐不撐得住」。 ## 概覽 客戶帶著一張渲染圖坐下來，說想做一款有稜有角的立體造型軟糖，要能站在包裝裡不塌、拍照要有陰影層次。你翻了一下手上的設備清單，覺得應該做得出來，直到第一批打樣出爐，第三層開始緩慢塌陷，稜線變成圓角。 這種翻車，在食品3D列印裡幾乎是常態，且問題往往並非出在噴頭或路徑規劃，而是早在擠出前就已決定成敗的「墨水」。近期一份以大豆蛋白，麥芽糊精共軛物（soy protein，maltodextrin conjugate）作為可調流變結構劑的研究，把問題直接放在擠出式食品3D列印墨水上：材料配方要怎麼調，才能讓擠出與成形變成可控的事 [1]。 因此我們必須先釐清：究竟是哪些機制決定了一份配方能否順利印出並維持結構。 ## 為什麼是配方決定成敗，不是設備參數？ 因為擠出式列印的物理窗口是材料先給定的，設備只能在那個窗口裡動。 擠出式食品列印要同時滿足兩件互相打架的事。料在噴頭裡受剪切時要夠稀，才能連續、穩定地被推出來；一離開噴頭、剪切消失，又要在幾秒內恢復到夠硬，才撐得住上面即將疊上來的層。這是剪切稀化（shear thinning）與結構回復（thixotropic recovery）的取捨，屈服應力（yield stress）則決定了自重之下會不會塌。 設備端能調的只有噴頭直徑、擠出速率、移動速度、層高、溫度。這些參數放大或縮小可用區間，但無法創造區間。如果一份配方的屈服應力根本不足以支撐五層自重，把速度放慢十倍也只是塌得慢一點。 上述研究把大豆蛋白，麥芽糊精共軛物定位為「rheologically tuneable structuring agent」，這個說法點出了核心差異 [1]，將蛋白質從單純的「營養成分」或「膠體成分」，轉化為可隨需求調整的結構旋鈕。對做打樣的人來說，這是把材料選擇從二選一（能印／不能印）變成一條可以校準的軸。 ## 蛋白質，多醣共軛物做了什麼，讓料變得「可調」？ 它讓一種材料同時具備乳化能力與結構支撐能力，而且兩者的比重可以透過反應程度去調。 蛋白質，多醣共軛物走的是 Maillard 型的共價接枝：蛋白質提供界面吸附與網絡形成的能力，多醣（此處為麥芽糊精）貢獻親水體積與空間穩定性。接上去之後，蛋白質在等電點附近或高鹽環境下的溶解度與穩定性通常會改善，這對食品墨水很關鍵，因為墨水配方裡幾乎一定會有糖、鹽、酸、風味與機能成分，純蛋白系統很容易在這些條件下先垮掉。 該研究把這類共軛物明確設定為擠出式3D列印墨水的結構劑 [1]。至於最佳接枝程度、最佳添加比例、能達到的成形精度數值，該研究的公開題名與研究定位並未提供可引用的定量結果，因此不宜宣稱具體數字，這點必須說清楚，任何「XX% 添加最佳」的說法都需要回到原文的實驗數據去核對。 以我在打樣現場的經驗判斷（此為作者觀點）：共軛物真正的價值不是把某個指標推到最高，而是把配方的「可操作寬度」拉開。量產時常遇上批次與溫濕度波動，單一甜蜜點的配方很容易失效，因此配方的操作寬裕度遠比追求單一峰值更重要。 ## 打樣時該問哪三個問題，才不會做到一半才翻車？ 評估時應依序確認材料、設備，最後才是造型，順序顛倒往往會導致專案失敗。 第一關，流變窗口。要求對方（或自己實測）提供三組資料：剪切稀化曲線、屈服應力值、剪切停止後的結構回復時間。第三項最常被忽略，卻直接決定可疊層數，回復太慢，第二層壓下去時第一層還是液態。 第二關，擠出可行性。同一份料在目標噴頭直徑下能不能連續擠出而不斷線、不積料、不因壓力累積而爆量。這裡的失敗模式跟油墨轉移不良很像：不是印不出來，是印得不穩定，而不穩定在量產放大時會被指數放大。 第三關，成形保持。印完到消費者拿到之間，這個結構要經歷什麼，冷藏、冷凍、烘乾、殺菌、運輸震動？含水配方的結構強度會隨脫水、回凝、相分離而變化，打樣當下站得住不等於七天後站得住。 這套「先流變、再擠出、後成形」的三段檢核，可以直接寫進打樣需求單，讓造型討論在有邊界的前提下進行。造型依然重要，但應排在流變與擠出參數之後才做確認。 ## 這對台灣的設計、包裝與印刷企劃，實際意味著什麼？ 意味著報價與提案的語言要換一套，從「能不能做」換成「在什麼材料窗口下能做」。 食品3D列印在台灣多半出現在幾種場景：機能軟糖與營養補充品的差異化造型、禮盒內容物的品牌化立體件、展示樣品與展會道具、以及少量客製化的節慶食品。這類專案多半是視覺先行，由設計端畫好圖後再讓製造端評估可行性，雙方很容易在此產生落差。 如果在提案階段就把材料流變條件當成規格書的一部分，設計端會得到一組有意義的限制：最小特徵尺寸、最大懸空角度、最高可疊層數、最短固化等待時間。這些限制不會扼殺設計，反而讓設計不必在後段被整張推翻。 包裝端同理。立體食品件的支撐、防震、防脫水，本來就會回頭改寫內襯與封膜的設計；如果印製件的結構特性在打樣後期才確定，包裝設計就只能倉促跟改。 實務上建議在打樣需求單中增加三欄：目標屈服應力區間、可接受的結構回復時間，以及成形後的加工儲運條件。若無法確認這些參數，建議暫緩討論造型。 適用邊界要說明白：以上判斷針對含水、以生物聚合物（蛋白質、多醣、膠體）為基礎的擠出式食品列印。若是巧克力這類以溫度相變主導固化的材料、或黏結式（binder jetting）粉體系統，固化機制不同，流變窗口的權重會下降，控溫與粉體特性才是主軸，檢核順序需要重排。 ## 重點整理 擠出式食品3D列印的物理窗口由配方先給定，設備參數只能在窗口內微調，無法創造窗口。 剪切稀化、屈服應力、結構回復時間是三個必須同時看的指標，其中結構回復時間最常被忽略卻直接決定可疊層數。 大豆蛋白，麥芽糊精共軛物被定位為可調流變的結構劑，用於擠出式食品列印墨水 [1]。 配方的價值在於可操作寬度而非單點最佳值，量產時的批次與環境波動會懲罰只有單一甜蜜點的配方。 打樣需求單應納入目標屈服應力區間、結構回復時間、成形後的加工與儲運條件三欄。 ## 延伸思考 食品3D列印對印刷製造端的意義，是把「材料規格書」這件事從油墨延伸到可食性基質，而印刷業對於黏度、轉移、乾燥、疊印的既有語彙其實可以大量遷移過去，擠出斷線與轉移不良、層間塌陷與疊印乾燥不足，本質上是同一類流變問題。設計端要習慣在造型之前先拿到材料邊界，這需要一套能被設計軟體理解的參數格式，目前業界尚無共識，是明確的空白。AI 與 SaaS 的切入點也在這裡：把流變量測數據、擠出參數、成形結果三者對齊成可查詢的資料集，讓打樣不必每次從零試錯；再往前一步，是從目標造型反推可行配方區間的推薦系統。待解的問題有兩個，一是缺乏跨材料、跨設備的公開基準資料集，二是「印得出來」與「撐得住到消費者手上」之間的加速老化驗證方法尚未標準化，後者在商業案上的風險遠高於前者。 ## 參考文獻 [1] Bae、Lee、Lee（2027）. [Soy protein，maltodextrin conjugates as rheologically tuneable structuring agents for extrusion-based 3D food printing inks](https://doi.org/10.1016/j.foodhyd.2026.113234). Food Hydrocolloids. DOI: 10.1016/j.foodhyd.2026.113234 ## FAQ / 常見問題 ### 食品3D列印失敗，通常是機器問題還是配方問題？ 多數情況是配方問題。擠出式列印的可操作物理窗口由材料的剪切稀化行為、屈服應力與結構回復速度決定，設備參數只能在既有窗口內調整，無法補救屈服應力不足導致的塌陷。 ### 判斷一份食品墨水能不能印，要看哪些指標？ 至少三項，剪切稀化曲線（決定能否穩定擠出）、屈服應力（決定自重下是否塌陷）、剪切停止後的結構回復時間（決定可疊層數）。三者需同時滿足，缺一項就會在特定層數或特定造型上失敗。 ### 大豆蛋白，麥芽糊精共軛物在食品3D列印裡的角色是什麼？ 它被定位為可調節流變性的結構劑（rheologically tuneable structuring agent），用於擠出式食品3D列印墨水，讓蛋白質同時承擔乳化與結構支撐功能 [1]。 ### 打樣時應該先討論造型還是先確認材料？ 先確認材料。建議順序為流變窗口 → 擠出可行性 → 成形保持，造型應在材料邊界確定後才鎖定，否則設計成果容易在量產可行性評估階段被整體推翻。 ### 這套判斷適用於所有食品3D列印嗎？ 主要適用於含水、以蛋白質與多醣等生物聚合物為基礎的擠出式列印。巧克力等以溫度相變固化的材料、以及黏結式粉體系統的固化機制不同，控溫與粉體特性的權重更高，檢核順序需要重新排列。 --- > HTML version: https://mindsprt.dev/zh-TW/knowledge/research-brief-rheology-tunable-food-3d-printing-ink/ > MINDS — 麥思印刷整合有限公司 · https://mindsprt.dev