外燴線上提案系統的做法：四步問卷、規格計價與 3D 餐桌

乖獸的外燴線上提案包含問卷與提案網站、3D 餐桌網站，以及管理規格、菜色與提示詞的後台。客人在問卷填完服務、時段、人數與場地，再補一句描述，就取得依規格分級的菜單；西式婚宴、圓桌合菜與半位上 Buffet 確認方案後，同一張訂單接續進入 3D 餐桌。

菜單生成沿用AI 批次內容的品質關卡中的做法：可由規格決定的欄位由程式填入，模型只寫文字，輸出再經程式驗證。這類系統的建置屬於AI 導入與開發。

四步問卷的欄位與驗證

下表列出四步的欄位與送出時的伺服器端檢查。

可預約日期依所選時間窗向伺服器查詢：當月已有訂單且時段重疊的日期會被排除，重疊以「既有訂單的起始早於所選結束，且結束晚於所選起始」判斷，回傳的日期都晚於今天。

四步的內容在每次變動時寫入瀏覽器的本機儲存，重新整理後已填的服務、日期、場地與描述仍在，訂單送出後清除。填寫期間不需註冊：訂單先建立，再以 Email 驗證碼綁定到客人的信箱。

第四步的一句描述會原文放進提示詞，標示為「客戶心中的畫面」，是模型調整菜單的主要依據。例如寫明長輩多、有人吃素，菜單會預留素食菜色並避開忌口。

提案生成：候選菜、相似案例與提示詞組裝

提案由獨立的服務產生，前台向該服務取得結果。生成期間訂單設為生成中狀態，同一張訂單不會同時啟動第二次生成；前台每 3 秒查詢一次，完成後方案寫回訂單。

提示詞分成兩部分。系統提示詞由後台維護的規則組成；使用者提示詞則在每張訂單生成時即時組出，內容依序為：

1. 訂單資料：服務、日期與推得的季節、時段、人數、場地，以及客人的一句描述
2. 規格區塊：每個規格的計價方式、各分類的道數範圍與附加服務
3. 相似案例：同類服務的過往案例與菜單組合
4. 候選菜色池：已篩選的菜色，附葷素與辣度標示
5. 輸出規範：依規格順序輸出的方案數量與 JSON 結構

候選菜在資料庫查詢階段篩好，模型不處理原始食譜資料。季節由活動日期的月份推得；自有場地的類型含戶外或庭院時視為戶外，其餘視為室內；描述或備註出現「素」字時，同分類內優先取素食菜色。符合季節與場地條件的菜色再依過往使用次數排序。各分類的名額是所有規格道數上限中的最大值乘上 2，至少 4 道，規格中道數上限為 0 的分類不進候選池。

相似案例以同類服務優先，再依距離排序：人數差距乘上 5，加上每人預算差距，數值越小越接近。總價制的案例先換算成每人金額，預設取最接近的前 5 筆。同類案例不足時，由相近服務的案例補上。

2026 年 8 月，這些資料整理成資料表：食譜約 1,500 筆、過往案例約 250 筆、服務規格 19 筆。案例裡的菜名與食譜庫逐一對應，比對一律用食譜代碼，因為同名的菜可能分屬不同分類；未能自動對上的菜名經逐一判斷建檔，對應率補到 100%。後台修改食譜、價格或規格，下一張訂單生成時立即生效，中間沒有快照。

模型輸出先驗證，再以後台規格覆蓋

外燴的報價會直接變成交易條件，模型輸出的風險可對照公開清單。OWASP Gen AI Security Project，2025的大型語言模型應用風險清單，列有 LLM09:2025 錯誤資訊與 LLM05:2025 輸出處理不當。模型輸出上線前的評估方式，見AI 問答上線前的評估方法。

模型須回傳 JSON，包含各方案的名稱、副標、描述、菜單，以及一則整體說明。程式先確認結構完整，再依規格逐項處理：方案數量對齊規格組數；計價方式、金額與附加服務一律寫入規格的值，不論模型回填了什麼；某分類的菜色超過規格上限時截斷到上限，上限為 0 的分類整類移除。方案名稱、描述與菜名維持模型的寫法。

方案送到前台時再整理一次：菜色依八個分類分組，單品價格移除，提案頁只顯示方案總價與各分類的道數。每道菜可附短備註，標籤取自後台維護的標籤池，例如「長輩口味」「現場製作」。

提示詞與用量在後台管理

提示詞拆成主廚口吻、方案命名、描述樣板、菜名規則、品項規則、需求解讀、等級差異與硬性規則等分段，連同溫度、輸出上限、相似案例筆數與候選池大小，都存在後台直接編輯。每次儲存，該段規則的版本號加 1 並保留舊內容；回滾是把舊版本的內容再存成新版本。修改後重新載入規則即生效，不必重新部署。

後台的試跑頁可預覽既有詢價單組出的系統與使用者提示詞，改寫後單次試跑，結果標示為測試，用量統計可排除。

每次呼叫都記錄完整提示詞、結果、耗時，以及輸入、輸出、快取寫入與快取讀取的 token 量。系統提示詞不含時間等變動內容，前綴固定，並標記為可快取。後台用量頁依日期彙總並換算費用，費率與匯率放在可調的設定中，並顯示快取命中率。費用的估法見AI 專案的費用怎麼估。

確認方案後進入 3D 餐桌

西式婚宴、圓桌合菜與半位上 Buffet 在提案頁確認方案後，帶著同一張訂單進入 3D 餐桌網站。網站啟動時一次取得整份配置資料：桌子、椅子、餐盤、餐具、杯具、口布、餐墊、桌旗、花藝與菜卡共十個分類，每個分類下有品項，品項下有選項，另含相機參數與各分類的視角限制。內容由後台維護，上新餐盤只需新增品項與模型檔。這一段屬於3D 互動網站開發的範圍。

座位的擺放由隱藏的定位點模型決定。每種桌型各有一份，內含的每個子節點記錄一個座位的位置與旋轉；場景讀出這些座標，椅子、餐墊、餐盤、餐具、杯具、口布與菜卡依座標逐座複製擺放。換桌型時換上另一份定位點模型，座位數與位置隨之重排。相機位置同樣由模型檔中的命名節點提供：每種桌型有遠景與近景兩個機位，切換時預設以 1.2 秒的緩動移動，時間與曲線可由後台的環境設定調整。

品項與選項帶有顯示條件欄位：-1 表示一律顯示，其餘值對應到特定品項被選取時才出現。餐墊只在方桌出現，桌旗依桌型換用不同的模型，杯組的選項依杯具種類過濾。切換桌型時，系統重新計算各分類的可見品項，並記住每種桌型先前的選擇，換回來時還原。

口布與桌旗以貼圖套在共用模型上，同一個模型能換多種花色；花藝的透明材質設為雙面並關閉深度寫入。

預設方案是一組「分類對應品項」的對照，存在後台，只有啟用中的方案會出現在頁面。載入完成後自動套用第一組；點選其餘方案時一次寫入整桌的選擇並觸發重排。六組預設方案為方桌與圓桌各三組，客製化則可在十個分類中逐項替換。方案卡片顯示總額，客製化時頁面即時加總已選品項與選項的加價。頁面註明為示意，實際佈置由團隊依現場調整。

整桌由客人自己選配，研究可供參考。Franke 等，2010對大量客製化商品的研究指出，自行設計的產品支付意願較高，效果經由完成感產生。該研究的對象是商品配置工具，餐宴不在其範圍內，這裡只取方向。

手機版針對效能降階：陰影貼圖的解析度由 2048 降為 512 並改用基本陰影，關閉接觸陰影與抗鋸齒，像素比上限由 2 降為 1.5；鏡頭依桌型拉遠，總覽視角為桌機的 2 倍、座位視角為 1.5 倍，窄螢幕也能看完整張桌面。

旋轉時的效能另有處理。玻璃杯使用透光材質，拖曳旋轉時改為 20% 不透明並關閉透光，省下額外的繪製階段，停手後漸變回復，對應的著色器變體在載入後先預編譯一次，避免第一次旋轉時才編譯。陰影在內容變動後重算 45 幀即凍結，旋轉期間不逐幀重算。配置資料取得後，所有模型與貼圖預先載入，切換選項不必等待下載。

模型的幾何以 Draco 壓縮（Khronos 的 glTF Draco 擴充規格），解碼器隨網站自行託管，不依賴外部服務。場景有戶外與室內兩種環境，切換時淡入淡出，桌面配置保留。

完成佈置後，選配以品項與選項代碼連同所選方案存回同一張訂單，業者的團隊在後台就能看到客人選了哪組方案與品項。先看成品再決定的流程，也用在訂製招牌，見訂製招牌付款前先看成品。

搜尋與 AI 引擎讀得到的頁面

問卷網站首頁的服務卡片在伺服器端取得資料並預先渲染，每小時重新驗證一次，爬蟲第一次載入就讀得到服務名稱與介紹。Google 的說明文件指出，Google 分抓取、渲染、索引三階段處理，渲染後看得到的內容才能被索引，並建議使用伺服器端渲染或預先渲染。

頁面內嵌三組結構化資料：網站應用程式、組織與常見問答。可見的問答文字與結構化資料取自同一份後台資料，兩邊字句一致，符合Google 對結構化資料的要求：標記的內容須是讀者看得到的內容。個別提案頁屬於客人的私人內容，不列入 sitemap，robots 規則也予以排除。

不適合的情況

• 報價必須逐次勘查、現場議價，沒有固定規格可寫入後台的服務：金額無法交給程式決定，問卷只能收集需求
• 品項少、看文字就能想像成品的服務：用不上 3D 餐桌，問卷與規格化報價已足夠
• 菜色每天由主廚臨時決定、沒有固定菜色庫的服務：候選菜無法事先篩選

要準備什麼

先備齊三項資料：各項服務的規格，包括計價方式、每人價格、可加購項目與各分類的道數範圍；現有的菜色清單，連同葷素、辣度、適用季節與場地的標示，以及過往成交的菜單組合；客人常問的日期、人數、場地與忌口條件。要上 3D 餐桌，另需要各桌型的模型，以及桌椅、餐具、花藝等分類的品項清單。資料就緒後，與開發團隊確認範圍，再評估哪些服務適合先上線。