上一篇寫完「鏡像空白」之後，有朋友問我：那要是真的要做，會長什麼樣？
我本來想回一句「我不是要做產品啦」就結束。但這個問題越想越覺得欠一個答案——光是點出問題不夠，得有人試著畫畫看藍圖，才知道「為什麼十年沒人做」是真有結構性原因，還是大家剛好都沒注意到？
於是我把這個題目丟給兩位 AI 助手——Claude 跟 Gemini——三方輪番討論。我畫一版藍圖、Claude 從工程現實的角度砍一刀、Gemini 從產品落地與行為學的角度再砍一刀，撞牆好幾輪才收斂出來。第一版很性感、被自己打槍；後面每改一次都被某個邊界條件打回去。這篇是收斂後的版本，前面先簡短交代砍掉了什麼，後面講剩下什麼。
3D 列印遮光罩拍話機螢幕做 OCR。 第一版的想法，聽起來駭客、實際上脆——受光線、位移、油煙、視角全影響，每換一種話機要重建模重調 ROI，無法規模化。為了「非侵入」這個美學繞去拍螢幕，比直接接電話線還繞。修辭贏不是工程贏。
寫手機 App 抓來電號碼。 用手機當公務機接訂位的店沒拉電話線、號碼天生是數位的，但你的 App 沒資格碰它。iOS 的 CallDirectory（Whoscall 用的那支）是事先塞清單給系統比對，來電時根本不會喚醒你的 extension〔Apple Developer Forums #50415〕；Android 的 CallScreeningService 要被指派成預設電話 app 那個 role，且 Call Log 權限被 Google Play 列高風險、上架易被打槍〔Google Play Console Help〕。手機作業系統就是那道牆。
前端放 AI 即時聽客人原音、做語意理解。 遠場加電話雜訊加開放式品項，最難的一塊；而且模型即時出錯會把錯誤直接推給客人。AI 出前端，前端只做確定性動作——這條紀律後面整套都靠它撐。
繞了一圈，剩下的骨架很樸素：
號碼進系統，走「載送層」攔截。 實體市話電話機接單的店（後簡稱市話店）用幾塊錢的一分二接頭並接（parallel），一條進話機、一條進 USB 來電顯示盒，盒子接到 Raspberry Pi 上把號碼轉成區網 Web API，平板讀 API。用手機接訂位的店（現在新開的小店越來越多直接辦個門號、買支舊手機當店機）改走 VoIP 門號，雲端 PBX 在 SIP INVITE 那層攔下號碼，webhook 推給平板。兩個世界是同一招的兩種載體——裝置層全死，唯獨載送層開放。
這條路是已知 prior art：開源專案 NCID（Network Caller ID）做這件事二十年了，2024 年底還在更新〔NCID SourceForge〕。世界一不是發明，是把現成積木接起來。
但號碼也要過店員複誦這關才算數。 這是我聊到一半才意識到的——撥進來的號碼不一定等於客人要留的聯絡號碼（可能用同事手機、店家剛剛回撥的那支打）。光靠 caller ID 自動帶，等於把「撥出的號碼」誤當成「要留的號碼」，而且錯得靜默，直到要回電才爆。店員接起電話要跟客人確認「要用您現在這支嗎？」，是或不是，都把要留的號碼複誦一次進系統。Caller ID 從「資料來源」降級成輔助與加速。
科技負責快、人負責對。
訂位資訊也靠複誦進系統。 姓氏、人數、日期時間、備註——讓店員複誦確認時（「好，0912⋯⋯、四位、禮拜六晚上七點、陳先生、靠窗，對嗎」），按一個實體收音按鈕，對著欄位用 OS 內建的語音輸入（iPad 鍵盤麥克風鍵、Android 語音輸入）把字講進去。
收的訊源是店員的複誦不是客人原音。店員近場、用正規詞，乾淨一個量級。按鈕同時是觸發 gate 跟隱私開關——按了才收，沒有「系統一直在聽」。不自架語音辨識、不養模型，就是「把手抄換成講話」這麼樸素的一件事。
那這套東西「最少」要長什麼樣才算可用？
連訂位 SaaS 都不做、不做熟客檔案、不做座位管理——只記流水帳：一筆訂位一列、append-only、固定 schema，加上一個「按日期 filter 撈出今晚清單」的能力。店員看著那張清單用人腦排位——哪桌給誰、幾點翻桌、臨時併桌、熟客留窗邊、放鳥風險高的押後。
這些是人腦的「政治智慧」，純 AI 接線生做不到。不是還沒做的功能，是刻意留給人的那一塊。
機器記帳、人腦排位——這兩個綁在一起才是核心。少了排位，流水帳沒有靈魂；少了流水帳，排位沒有素材。
AI 跟 SaaS 是疊上去的、不是地基：
選配一：AI 輔助判讀（後端、離線）。 整理姓氏音近候選、從流水帳長出熟客雛形、跑「禮拜幾幾點最滿」這類統計。定位詞是**「輔助判讀」不是「自動判斷」**——AI 把素材整理好遞給人看，排位的筆還是握在店員手上。
選配二：SaaS 熟客系統。 跨裝置同步、座位圖、報表、重複訂位防呆。把人工排位從「憑店員記憶」升級成「有系統輔助」。
兩個選配都是 additive，核心-only 也是完整可用的產品。
兩個選配其實都在服務核心裡那個「人」——AI 輔助判讀幫人看得更清楚、SaaS 熟客系統幫人記得更牢，但沒有一個去搶人手裡那支排位的筆。在滿街硬塞 AI 的此刻，敢說「核心不用 AI 也會動」反而是賣點。
設計收斂到這裡，刻意停下來檢查還有什麼極限狀態會穿幫：
同音字搜尋陷阱。 流水帳忠實 append，當天若把「章」收成「張」、「陳」收成「程」，客人到場報姓時店員搜不到。緩解：搜尋介面預設音近 fuzzy match（注音首字／聲母相同即列出），這只是字串處理還不算 AI。
多現場節點的雙重訂位風險。 核心-only 模式下，櫃檯接電話與門口領台若同時看著同一份流水帳、各自答應客人，因為沒有狀態鎖會發生超賣。這是核心-only 的已知邊界——適用單點操作的店，多現場協作的店請開選配二（跨裝置同步＋狀態鎖是 SaaS 層的本職）。
店員一手拿話筒、另一手按鈕的摩擦。 手按收音的代價是動作競爭。腳踏開關或耳機接聽是店家可自行升級的硬體選項，本架構不預設。
還有兩個更基本的前提：來電顯示是加分不是門檻（沒有也照樣運作，只是少了加速）；店員要會複誦（「好半小時」三個字就掛電話的快炒便當店，這套用不上）。
每店硬體（不含 iPad，店家 POS 通常已有）：市話店約 NT$3,000–5,000（Pi Zero 2 W 約 NT$1,000–1,500、Linux 認得的 USB 來電顯示盒約 NT$1,000–2,500，加上接頭、麥克風、收音按鈕）〔註：價格區間查自 BigGo、台灣樹莓派、Yahoo 拍賣 2026 年 5–6 月行情〕。用手機接訂位的店硬體更便宜，但每月多一筆 VoIP／雲端 PBX 月租。
軟體開發：核心-only 工程量極小——一張 append-only 表單加一個 filter，整合 NCID 把號碼推進來，side project 模式幾乎只吃時間。加上選配二就是 1 個工程師 × 數月起跳，這層才是真成本大頭。
真正的隱形大頭：每店到府安裝工。並接電話線、裝盒、對麥克風位置、教店員養成複誦習慣——每家店都要派人去弄一輪。台灣電話盒廠商商品頁上幾乎都寫「支援到府安裝，安裝費另計」，就是因為這筆工錢藏不住。零件可以規模化，這筆人力沒辦法，它會隨店數線性長大。
當初卡十年的不是錢，是這筆工沒人想扛。
整趟設計收斂每一步都在做減法。OCR 帽子拿掉、客人原音拿掉、點餐 NLP 拿掉、前端 AI 拿掉、SaaS 強制依賴拿掉、自動排位拿掉。
剩下的不是一個賭 AI 行不行的產品，是一張會 filter 的表、一台 Pi、一支麥克風、一顆按鈕、一個會複誦的店員。
這個尺寸的問題，技術上一直是準備好的。它卡了十年，不是因為太難，是因為一旦你不肯往「炫」的方向走，它就變成一個很無聊的工程案——而無聊的工程案沒有資本市場故事可以講。
也許對店家來說，這就夠了，但是...
寫到這裡我自己回頭問了一個問題：拿這套系統去跟最樸素的對照組——店員手抄便條紙——比，它到底贏在哪？
誠實講，贏的地方比想像中少。
填單當下的速度不一定比較快，熟手抄一張便條紙也是三十秒；學習成本還比較高，新工讀生拿便條紙馬上會用，這套還要教按鈕跟補字；停電了還跑得動的是便條紙不是這套。
真正贏的不是「填單那一刻」，是**「填完以後」**——按日期 filter 撈出今晚清單、字跡不會看不懂、便條紙不會搞丟、號碼從聽寫變校對所以錯誤率掉一個量級、留下了可以事後分析的素材。手抄是 write-only memory，流水帳是 read-write。
但這個對比同時也說明了一件事：如果店家本來就不需要事後撈（量小到貼牆上就夠用），這套對他沒價值，硬推等於擾民。 適用前提隱含一句沒寫出來的話——訂位量大到「撈得出來」變成痛點。
這也回過來解釋為什麼這個市場卡十年沒人做。有電話訂位、但訂位量沒大到便條紙會炸的店，是台灣絕大多數中小餐廳，便條紙對他們真的夠用；會痛到願意換系統的，量已經大到他們直接買 inline 那種完整 SaaS 了，繞過核心-only 直接買選配二。
所以這套系統的精準甜蜜點其實很窄——訂位量介於「便條紙炸了」與「值得買 SaaS」之間的店家。再往上被 SaaS 吃掉、再往下便條紙就夠了。
卡十年的不只是錢、也不只是那筆到府安裝工，還因為這個市場區間天生會被便條紙跟 SaaS 兩邊夾擊。中間帶看起來明顯，實際上很薄。
〔待查證項目：NCID 在台灣是否已有中文／繁中語系實作；台灣有銷售支援 Linux 的 USB 來電顯示盒型號清單；本文硬體價位為 2026 年 5–6 月台灣零售行情，量產採購價未驗證；現行訂位 SaaS（inline、EZTABLE 等）對「電話入口數位化」的官方說法待補主源。〕
樓主,
你的出發點跟過程是對的，但小弟覺得，似乎有些盲點在。於是就跟CLAUDE討論了一下，以下是原文：
兩篇都讀完了。以下是結合兩篇的完整分析。
文章的自我批判已經做得很誠實，尤其「甜蜜點很窄」那段是真正有價值的自我修正。但仍有幾個盲點沒有被點到，以及幾條作者沒走的可行路徑。
作者從「在捷運上報手機號很尷尬」出發，但這個痛點解法其實不需要碰電話系統。
真正的問題是：店家不認識回頭客。
如果店家能用 LINE 官方帳號讓客人自助訂位，帳號即身份，號碼自動帶入，連電話都不用打——這條路已經存在，而且不用裝任何硬體。文章預設「電話訂位」是不可動搖的入口，但這個前提本身值得挑戰。
文章說「科技負責快、人負責對」，但複誦習慣是行為改變，是這套系統裡唯一完全無法用工程手段保障的環節。
問題是：店員不複誦，系統就不比便條紙好，甚至更慢（便條紙不需要按按鈕）。文章沒有提出任何機制來強化或驗證這個習慣的養成。這不是技術問題，是組織行為問題，而這類問題在 B2B 產品裡通常是死亡原因之一。
文章說 inline、EZTABLE 沒有做「電話訂位數位化」，但沒有分析：他們為什麼不做？是策略選擇還是視而不見？
如果這個方向真的有價值，他們進場的成本比新創低得多——他們已經有店家關係、有業務團隊、有安裝人力。一旦驗證可行，他們可以直接複製。這套系統的護城河在哪裡？文章沒有回答。
文章把市話店和手機店當兩個平行世界處理，但實際上台灣餐廳新開的越來越少拉市話，舊店也在陸續廢線。這套系統的核心硬體路徑（Pi + USB 來電顯示盒）的市場基礎正在縮小，而 VoIP 那條路每月多一筆月租，等於把「低摩擦導入」的賣點折掉了一半。
文章最後才說「甜蜜點很窄、兩邊夾擊」，但這個結論其實決定了前面所有設計的意義。把它放在最後讀起來像是誠實的收尾，但邏輯上它是整篇的前提——先問這個市場存不存在，再問技術怎麼做，順序反了。這不是盲點，但是論述結構的問題，影響讀者對整套方案的信心評估。
不裝任何硬體、不改任何電話流程。讓店家開一個 LINE 官方帳號，客人加好友後直接文字訂位，系統自動收單、整理成流水帳、按日期 filter。LINE 在台灣餐廳的滲透率極高，店家和客人都已經在用。
這條路的核心價值主張和文章一樣（機器記帳、人腦排位），但導入成本幾乎是零，沒有硬體、沒有到府安裝工、沒有習慣養成問題。電話訂位的客人繼續打電話，LINE 訂位的客人走 LINE，兩條線都進同一張流水帳。
文章說到府安裝工是隱形大頭、是卡十年的原因之一。但反過來看，如果有人願意把這個「無聊的安裝服務」做成標準化產品，它反而是門檻——別人不想做的事，做了就是護城河。
這是一條不性感但可能真的能活的路：不賣軟體、賣「訂位流程整理服務」，按月收費，包含初裝、教育訓練、換機維護。硬體成本轉嫁、軟體成本幾乎為零，毛利來自人力標準化。
把號碼自動帶入的功能完全拿掉，就只做一個「比便條紙好用的訂位記帳本」——手動輸入號碼、自動排列、可 filter、可搜尋、可備份。
這個東西用 PWA 做，店家開瀏覽器就能用，不需要安裝、不需要硬體、不需要市話。定價 NT$299/月，對應的競品是便條紙加上人工整理的時間成本。
文章預設「號碼自動帶入」是這套系統的靈魂，但其實去掉它之後，剩下的核心功能依然解決了便條紙最大的問題：字跡、遺失、事後撈不到。
文章最誠實的地方是承認甜蜜點窄，這個自我修正是正確的。但作者仍然停留在「這個硬體架構能不能做起來」的問題框架裡，而沒有跳出來問「解決熟客識別這個真正問題，有沒有更短的路」。
最值得繼續深挖的一個問題是：如果把硬體全部拿掉，只做純軟體的訂位流水帳，這個東西的市場是不是比文章描述的更大、而不是更小？
謝謝你的分享，我是從一個電話訂位使用者的角度出發，想法開源分享，如果有人做出來是樂見其成，如果沒有的話也就只是維持目前的使用方式。
整套想法的起點就是捷運上那通電話——客人這端覺得被廣播個資、店家那端號碼明明顯示了卻還要再聽寫一次。從這個體感出發，所以那些設計收斂的拉鋸純粹是想知道「真的要做會收斂成什麼樣」、以及「為什麼十年沒人做」。
LINE Bot 訂位這條路確實是整篇的盲點，謝謝點出來。它在台灣餐廳的滲透率夠高、店家跟客人都已經在用，作為「熟客自助訂位」這條路確實比硬體方案更短。不過從客人視角想，LINE Bot 接得到的是「已經加好友的客人」，但鏡像空白原本想處理的是陌生客第一次打電話——觀光客、長輩、臨時搜到一家店想訂位的人，這群人不會為了訂個位先加好友。電話作為冷接觸入口，可能還是會留下來。但這不影響你的論點：對熟客回流這個更高頻的場景，LINE Bot 確實是更短的路。
複誦習慣養成那一點你說得很對，那是 B2B 落地的真問題，但因為我不是要做產品，這層我也就沒往下挖。
至於現有玩家為什麼不做電話入口數位化，我自己猜測：要整合的東西太多（每家店話機型號不同、電信業者不同、到府裝機跟教育訓練都是線性人力），SaaS 商業模式的單位經濟學撐不起這條尾巴——軟體一份做完賣很多家才是他們的賺錢方式，加上一條每家不一樣的硬體流程會把毛利打死。再加上「網路訂位」聽起來比「電話訂位數位化」厲害，創投跟 PM 寫 roadmap 都會自然往前者傾斜。所以不是看不到，是算過帳之後理性放棄。這個結構性原因剛好呼應文章那個「甜蜜點很窄」的但書——供給跟需求兩邊都偏離了，市場才會空在那裡。
路徑 B（把安裝服務做成標準化產品）跟路徑 C（純軟體 PWA、連硬體都不碰）我覺得都有道理，特別是 C 其實呼應文章那個但書——核心價值在「撈得出來」，硬體是 nice-to-have、不是 must-have。如果有人想往這幾條路走我都樂見其成，這也是把藍圖開源出來的本意。
iThome鐵人賽
看影片追技術