餐廳 QR Code 菜單 —— 一次製作，永不需重新列印

大家都在建議同樣的做法：生成一個 QR code，把菜單連結放進去，列印出來，搞定。在我看來，這是最愚蠢的作法。稍後我會說明原因。

首先是畫面。週五，餐廳座無虛席，服務生忙得像著了火一樣。在七號桌，有三位客人在一片油膩的貼紙上方揮舞手機五分鐘了。掃描代碼卻導向兩個賽季前的 PDF 檔。一半的菜品都沒供應。價格也是隨便編的。最後他們還詢問已經不再印製的紙本菜單。你感同身受嗎？就是說啊。

QR Code 菜單並非僅僅是一個噱頭。它是您整個店內被觸碰頻率最高的「按鈕」。而通常在製作它的過程中，問題從第一天起就已經註定發生了。

編碼檔案的程式碼是單次使用的（只是你不知道而已）

經典做法。你生成一個包含 menu-wiosna-2025.pdf 直接位址的 QR Code。列印、護貝、刻在吊牌上，然後擺放在桌上。非常漂亮。只要菜單內容沒有變動，這招就一直有效。

因為你更換了啤酒供應商。或者你將漢堡的價格調高了三塊錢。或者推出了季節性菜單。突然間，那個漂亮的塑封代碼指向了過時的內容。你有兩個選擇：把謊言留在桌上，或者全部重新列印。

QR Code 本身很蠢。它字面上就是一張編碼了某段文字的圖片。如果你在其中嵌入了一個長且固定的檔案位址，那你就會與該位址終身綁定。無論好壞皆然。

整個治療方法可以用一句話概括。程式碼不應導向選單，而應導向一個短連結，你可以隨時更改其目標位址。

在實踐中，情況如下

與其將小怪物編碼進 QR 碼中，例如：

https://twojarestauracja.pl/uploads/2025/menu-final-v3-NEW.pdf

你正在編碼一個短中間地址：

https://cutty.dev/u/menu

這個連結永遠不會改變。改變的只有它指向的目的地，而你只需在控制面板中三十秒即可完成設定。今天它開啟春季菜單。明天則是冬季菜單。一個月後，你可以將它切換到酒吧吧台的葡萄酒 PDF。桌上的貼紙呢？維持不變。你更換的是目標，而不是紙張。這就是全部的竅門，而且真的沒有任何隱藏的套路。

一次編寫，終身忘記的程式碼配方

依序。

首先，請將菜單製作成網頁，而不是 PDF。這點非常重要。在手機上查看 PDF 簡直是一場災難：你必須不斷縮放、左右滑動，而且如果店內地下室訊號不好，載入速度會慢得要命。一般的 HTML 子頁面可以立即開啟，且在任何螢幕上都很清晰，即使是那台花五十塊買的裂掉的螢幕也沒問題。

然後建立一個帶有具意義結尾的短連結。例如 /u/menu 或 /u/karta。當客人更喜歡用手指輸入地址，或者你在電話預訂時提供給他們時（「kropka dev, 斜線 menu」），這會非常有用。

你可以透過這個短連結生成 QR Code。只需一次。在 cutty.dev，你可以直接使用現成的連結完成，因此不需要在三個工具之間切換，也不用費心確認哪一個 PNG 檔案才是正確的。

列印並展開。掛牌、貼紙、入口處的貼紙、櫥窗內的海報，專為外帶族群設計。

就這樣。從現在起，更換卡片只需在控制面板中進行一次編輯。紙張保持不變。

掃描結果告訴你的店面資訊比你想像的還要多

這就是大多數餐廳經營者都會忽略的事情。短連結可以提供掃描統計數據。而這些並非僅供裝飾的死板數字，而是關於你店鋪本身的知識。

你可以看到在週五晚上和週二下午分別有多少次打開菜單的情況。為午餐建立一個獨立的代碼，並為晚間菜單建立另一個獨立的代碼，你就會發現你的晚餐究竟是什麼時候開始的（通常不是你以為的時間）。酒單的獨立代碼會向你展示殘酷的真相：是否真的有人在看它。

現在請注意，因為這非常重要。在 cutty.dev 中，我們收集這些數據而不需要建立訪客檔案。IP 會經過雜湊處理，沒有廣告追蹤器，也沒有客戶資料夾。你得到的是掃描次數和時間趨勢，也就是能真正幫助經營餐廳的資訊，而不是將一盤義大利麵轉換成個人資料。在 GDPR 規範嚴格的歐盟餐飲業中，這就是「我們擁有統計數據」與「我們面臨稽查員問題」之間的差別。

一些能省去煩惱的小細節。選單和掃描數據都保留在歐盟境內的伺服器上，所以與會計溝通時少了一個議題。訪客不需要建立帳號，也不必點擊一堆同意聲明，因為沒有什麼比在享用鱈魚前先遇到 Cookie 牆更掃興的了。而且，同樣的替換機制也可以用於處理「今日優惠」或「訪後問卷」。只需暫時重新導向現有的連結即可。

好的 QR code 菜單很無聊。你印一次，它就掛在那裡好幾年，而且價格永遠不會出錯。在這裡，「無聊」是一種讚美。

所以下次當有人建議你「把菜單連結直接貼進程式碼並列印」時，微笑著並換個做法。在下方使用一個簡短且可替換的連結（例如 cutty.dev），讓你只需點擊一下即可更新菜單，而不是去黏貼三十張桌子的標籤。你 7 號桌的服務生會感謝你的。