#為什麼 Pin 用「按鈕」不用「對話」— 一個消費級 AI runtime 的架構取捨

過去兩年，幾乎所有 AI 產品都長一個樣子：一個聊天框，叫你「有什麼想問？」我們做 Pin 的時候，刻意反過來 —— 按鈕和模板是主菜，LLM 只是 fallback。

這聽起來不夠潮，但背後是一個很實際的架構取捨。這篇講為什麼。

#一、一個反直覺的決定

Pin 是一個「消費級的 AI Skill runtime」：你把一個產品的能力丟進去，它就在 LINE / Telegram 上長出一個一般人按幾下就能用的介面。

大部分人會直覺地把它做成對話式：用戶打字 → LLM 理解 → 執行。我們沒有。Pin 的主介面是按鈕、Flex 卡片、選單；自由打字只是退路。

為什麼？因為我們的對象不是工程師，是一般消費者。

#二、消費者的真相：他們不會、也不想打 prompt

工程師很容易忘記一件事：會寫 prompt 的人是極少數。

一般人面對一個空白聊天框，第一個反應不是「太自由了好棒」，而是「我要打什麼？」。他要的不是一個無所不能、但要他想清楚怎麼問的助理，而是：打開、看到幾個選項、按一下、事情辦好。

這就帶出一個核心取捨：確定性 vs 聰明。

• 自由對話很「聰明」，但每一句都要 LLM 即時判斷意圖 —— 慢、貴、而且偶爾會錯（理解錯、執行錯）。
• 按鈕流程很「笨」，但它是確定的：按「看我的物件」就一定是看物件，不會解讀錯，零延遲，零成本。

對一個要給一般人天天用的消費產品，確定性的可靠，比聰明的偶爾驚艷重要太多。 所以 Pin 把 LLM 從「主廚」降級成「備胎」—— 它只在按鈕覆蓋不到的長尾情況才出場。

（這也是 Pin 跟我們另一套東西 OpenClaw 的根本差異：OpenClaw 是給進階 agent 場景的 LLM-first 艦隊；Pin 是給一般人的、determinism-first 的入口。兩者是光譜的兩端，服務不同的人。）

#三、架構：一份 SKILL.md，長出多個介面

那這些按鈕從哪來？我們不想每接一個產品就手刻一套 UI。

核心是一份 SKILL.md —— 它是一個產品的「單一真相」：宣告這個產品有哪些東西（entities）、能做哪些動作（actions）、文案、多步驟的 wizard 流程。

Pin 讀這一份 SKILL.md，就自動長出：

• LINE / TG 的按鈕介面（Flex 卡片、inline keyboard）；
• 一個 MCP server，讓 Claude / Cursor 之類的 agent 也能驅動同一個產品（目前主要供 agent 工具自行接入，非公開服務）；
• 一個 webhook 接收器，產品端推一個事件（例如「收到新 lead」），Pin 就渲染成帶按鈕的通知，送到用戶的 LINE / TG。

換句話說：你只要把產品宣告成一份 SKILL.md，消費者介面、agent 介面、通知，就一起長出來了。

#四、The seam：產品出 endpoint，Pin 出介面

這裡有一個我們很在意的設計原則：接縫要乾淨。

產品端（例如 UD House）只負責一件事：把能力做成乾淨的 API + 宣告一份 SKILL.md。Pin 端只負責另一件事：把那份 spec 渲染成人看得懂的按鈕介面。

兩邊靠 SKILL.md 這個「接縫」對接。產品端加一個動作，不用碰 Pin 的程式；Pin 改一個渲染方式，不用碰產品。一份 spec、多個介面、互不綁死。

實際上這已經在跑：UD House 跟 MindThread 兩個產品，各自宣告自己的 SKILL.md，同一套 Pin runtime 就能分別長出它們的 LINE/TG 介面 —— 我們不用為每個產品重寫一次前端。（Pin 目前仍在內測 dogfooding 階段，未開放外部註冊，正式上線會再公佈。）

#收束：消費級 AI 的難點，不在模型多強

做 Pin 最大的體會是：面對一般人的 AI，難的從來不是模型多聰明，而是「怎麼讓一個不懂的人，三秒鐘就上手」。

而三秒上手的答案，往往不是更強的對話，而是更少的選擇、更確定的按鈕、更清楚的下一步。

把聰明留給需要它的長尾，把確定性給每天用它的大多數人 —— 這就是 Pin 的架構選擇。