1
客人四步問卷卡片與按鈕作答
(案例) 餐飲外燴・Polish AI / Polish 3D
四步問卷取得分級菜單，確認後於 3D 場景擺好整桌
婚宴外燴客人需要確認菜色，也需要看到餐桌的樣子。客人以四個步驟說完需求，取得分級菜單，確認後直接進入 3D 場景，擺好整張餐桌。
同樣做法適用於外燴、宴會場地、婚禮顧問、餐具與花藝租賃，以及任何需要組合起來才看得懂的服務。
7種外燴服務
6組預設方案
4步問卷
(挑戰)
外燴客人需要同時確認菜色與餐桌的樣子
外燴客人購買的是一場餐宴的畫面：菜色，加上當天那張桌子的樣子。服務共有七種，從西式婚宴、圓桌合菜、週歲派對到個人餐盒，規格各不相同；日期、人數、場地與忌口，也都會改變菜色與價格。
詢價單以人工逐題詢問、逐份配菜時，提案速度會影響可承接的數量，也影響客人比價的時間。
(做法)
由 AI 撰寫菜單，價格一律依規格
讓 AI 直接面對客人，最大的風險是自行報價。因此工作切成兩半：計價方式、每人價格與附加服務依後台規格，道數也依規格上限修剪；AI 只負責方案命名、菜單與描述。價格若有出入，後端以規格覆蓋。
AI 參考的菜色也先經過篩選：依日期推算季節，依場地判斷室內外，從描述判斷素食，再由菜色庫挑出一池候選菜交給 AI。
提案依規格由經典、升級到主廚款逐級遞進，系統另將同類服務、價位與人數相近的過往案例交給 AI 參考。
客人
- 四步問卷
- 一句描述例如長輩多、有人吃素
需求分級方案
開發團隊的服務
- 候選菜預篩依季節、室內外與素食需求
- 規格覆蓋計價方式、每人價格、附加服務與道數上限
候選菜命名與描述
模型供應商
- 語言模型方案命名、菜單與描述
不交給模型價格、計價方式與道數上限。
範圍：提案生成。
菜單由 AI 撰寫，價格由後台規格決定。
看完整內容 RAG 企業知識問答的逐字驗證流程(關鍵設計)
三項關鍵設計
四步問卷
問卷以卡片與按鈕作答，可預約日期由系統即時提供，填到一半重新整理也不會遺失。填寫不必註冊，送出後以 Email 驗證即可保存提案。最後一步只需寫一句描述，例如長輩多、有人吃素，AI 便調整菜色、預留素食菜色並避開忌口。
3D 餐桌
選了西式婚宴、圓桌合菜或 Buffet 的客人，確認方案後帶著訂單直接進入 3D 餐桌。每種桌型內建座位定位點，椅子、餐盤、杯具、口布到菜卡依定位點就位，方桌換圓桌，整桌自動重排。
預設方案
六組預設方案一鍵套用，桌椅、餐具到花藝整桌一次換好；想自行搭配，可在十個分類中逐項替換。佈置完成後，選配存回同一張訂單，團隊於後台即可看到客人選了哪組方案與品項。
桌機
六組預設方案，整桌一次換好
3D 餐桌下方列出六組預設方案，方桌與圓桌各三組，點選後桌型、桌椅、餐具與桌旗整桌重新排列；切到客製化，可在各分類中逐項替換。
手機
手機同樣能一鍵換整桌
手機上的 3D 餐桌保留同一組預設方案與客製化分頁，單指旋轉視角，點選方案後整桌重新排列。
(成果)
交付兩個串接的網站與一套可調校的 AI
現在有兩個串接的網站，與一套可自行調校的 AI：主廚口吻、命名規則等提示詞在後台分段管理，每次修改皆留版本，可回滾。品項與方案也在後台增減，上新餐盤不必改程式。
3D 模型經過壓縮，手機自動降階，客人以手機即可佈置；介紹與問答寫進網頁原始碼，搜尋與 AI 引擎皆能讀取。
問卷
提案
佈置
確認
客人
系統
團隊
2
系統產出分級方案經典、升級到主廚款
3
客人進入 3D 餐桌套用預設方案或逐項替換
4
系統選配存回訂單
5
團隊後台查看方案與品項
3D 餐桌適用西式婚宴、圓桌合菜與 Buffet。
服務與常見問答由後台資料庫供應，文字仍在網頁原始碼裡。
- 內容來源靜態檔，或後台資料庫
- 更新頻率固定，或常常更新
- 3D 載入失敗時使用者是否仍看得到文字
- 內容固定，路徑數量有限建置期預渲染磨人官網：不換框架，建置多一步，逐路由輸出靜態 HTML
- 內容來自資料庫，常常更新伺服器渲染加增量靜態再生服務卡片與 FAQ 由後台資料庫供應
- 3D 是互動主體，載入可能失敗伺服器文字層，3D 接手後拆除某公共機構網站：3D 載不起來或逾時才顯示文字
- 文字只為爬蟲而放，使用者看不到不採用內容必須與使用者所見相同
(工程紀錄)
做法與實測，逐張可展開
3D 網站的搜尋與 AI 爬蟲可讀性：預渲染、爬蟲分流與結構化資料
預渲染讓磨人官網首頁的原始 HTML 從 730 位元組增加到 39,516 位元組，畫面沒有改變 相關做法・數字來自其餘專案
首頁原始 HTML 大小（位元組）原始 HTML 中的 h1 數量
- 730 位元組預渲染前（單頁應用，空容器）前0
- 39,516 位元組預渲染後（建置時逐路由輸出靜態 HTML）定案1
磨人前一版官網首頁。h1 數量依預渲染的做法說明。
三類爬蟲讀同一份 HTML，用途不同，robots.txt 能管的範圍也不同 相關做法
爬蟲
- 搜尋索引爬蟲OAI-SearchBot、Claude-SearchBot、PerplexityBot：取文字，用於搜尋與助理的結果
- 訓練爬蟲GPTBot、ClaudeBot；Google-Extended 是權杖，沒有自己的 user agent
- 使用者觸發的爬蟲ChatGPT-User、Claude-User、Perplexity-User：使用者提問時才取一頁
請求與 user agentHTML 文字
網站（開發團隊設定）
- 預渲染的 HTMLh1、直答段與內文都在原始碼裡
- robots.txt 分組搜尋與助理開放，訓練依商業決定
- 伺服器層 user agent 判斷拒絕不遵守 robots.txt 的請求
robots.txt 不是存取控制RFC 9309 說明這些規則不是存取授權；使用者觸發的抓取，官方文件說明規則不一定適用。
依 OpenAI、Anthropic、Perplexity 與 Google 的官方文件整理，查核日 2026-11-05
AI 專案的費用怎麼估：為什麼估出來常差好幾倍
每則發現各派一個驗證代理，代理數就隨發現數漲到 136 個；批次驗證後降到約 7 個 相關做法・數字來自其餘專案
- 每則發現各派一個驗證代理136 個代理代理數隨發現數放大
- 合併後少掉的代理成本約為原本的 5%一個代理驗 15 到 20 則
- 批次驗證約 7 個代理派工前先算出發現數乘以驗證者數的上限
稽核流程。成本為依牌價換算，不是帳單。
關閉思考能把寫作時間縮到 6 到 17 秒，但標題成功率從 11/11 掉到 2/13 相關做法・數字來自其餘專案
寫作時間標題成功率
- 15 到 75 秒啟用思考，一次寫完保留11/11
- 6 到 17 秒關閉思考，一次寫完不採用2/13
測試站、真模型，13 題。被驗證程式刪掉的句子，關閉思考時是啟用思考的 3 倍。
最貴的模型只處理抽審後標出的難例，沒有逐篇讀完全部語料 相關做法・數字來自其餘專案
- 全部語料標註約 1,500 篇一篇一個子任務，由 Haiku 標註
- 未抽審的篇數只過程式驗證器結束碼 0 才收
- 依風險抽審約 160 篇約一成，由 Sonnet 審查
- 升級給 Opus9 個子任務只處理標出的難例與驗證器過不了的
子任務數：Haiku 約 1,600 個、Sonnet 約 50 個、Opus 9 個。篇數與子任務數均為約略值。
(聯絡)
Start a project.
三個步驟，取得可判斷的做法與預算區間。
- 01預約第一場會議：選擇時段，不需要完整規格。
- 02線上諮詢 15 至 30 分鐘：取得做法方向、預算區間與時程草案。
- 03檢視素材後，約 3 至 5 個工作天提供報價單暨交付規格明細表。
- 信箱
- hello@polish-design.com.tw
- 通訊地址
- (104) 台北市中山區植福路191-1號3F
