#我為什麼這樣做產品 — 從一個房仲的痛點，到為 AI 而生的平台

很多人做 AI 產品，是先看到一個很炫的技術，再回頭找問題套上去。我習慣反過來：先問究竟想解決什麼問題、該把什麼事情自動化，技術才上場。

這篇想老實講一下，我這陣子做的兩個東西 —— 一個給房仲的平台、一個給一般人的 AI 入口 —— 背後到底在想什麼。

#一、問題先行：我去訪談身邊的房仲

我沒有一開始就決定「我要做房仲 SaaS」。我是先去問。

我訪談身邊做地產的朋友，再對著香港市場分析了一輪，發現他們每天的時間其實大量耗在三件重複的事上：

• 放盤：影完相，要自己想文案、逐個平台貼，一個盤花掉一個鐘。
• 接客：放工後、半夜的查詢沒人回，客戶轉頭就找下一間。
• 跟進：傾完沒留到聯絡、約睇樓沒人跟，lead 就這樣無聲無息流走。

這三件事有個共同點：它們都不是「成交」本身，卻吃掉了成交前最多的時間。 那這就是該自動化的東西。

於是有了 UD House —— 影一張相，AI 幫你寫好盤文、噴上各大平台、24 小時當值接客、主動約睇樓、把 lead 收進來。房仲只需要按一下快門，剩下交給系統。

重點從來不是「我們有 AI」，而是「我們把房仲最痛、最重複的那一段拿掉了」。

#二、第一個賭注：AI agent 是未來，所以產品要讓「AI 也讀得懂」

我相信 AI agent 一定是趨勢。未來幫你做事的，未必是你親手點按鈕，而是一個 agent —— 你的、或是別人的。

如果這是真的，那產品就不能只「給人看」。網站、後台、API，都要讓 AI 和程式也讀得懂。

所以 UD House 從第一天就同時做了三件事：

• 給人看的介面（房仲的後台、客戶的分享頁）；
• 給 agent 用的開放 API + 公開 OpenAPI 規格；
• 給爬蟲 / LLM 自我引導的 llms.txt。

一個 AI agent 可以讀我們的 spec，然後直接幫房仲建物件、生成文案、查 lead —— 不用人手點任何一個按鈕。這在今天的房仲 SaaS 裡還很少見，但我認為這會是基本門檻。

#三、第二個賭注：但一般人離「原生 agent」還很遠

這裡有個容易被忽略的現實：雖然 agent 是未來，但一般消費者離原生的 agent（像 OpenClaw 那種）其實還有很大一段距離。

要一般人去配環境、寫 prompt、接 API，是不可能的。他們要的是：打開手機、按幾個按鈕、事情就辦好。

所以我做了 Pin —— 一個消費級的入口（目前小範圍內測中）。把產品的能力包成 LINE / Telegram 上的按鈕介面，跨領域整合、操作直觀。你不用懂 agent，你只要會按。背後是同一套能力，前面換成人看得懂的樣子。

換句話說：agent 是給未來的，直觀的入口是給現在的人的。兩個都要，缺一不可。

#收束：一份規格，同時餵人，也餵 AI

把上面三點接起來，其實是同一件事：

每個產品宣告一份 SKILL.md —— 它是這個產品的單一真相（有哪些東西、能做哪些動作）。然後這一份規格，同時長出四個介面：

• Pin：給一般人的 LINE / TG 按鈕 app；
• MCP / API：給 AI agent 操控；
• Web 後台：給人工管理；
• 內部艦隊：給自動化。

一份 spec、四面同步。人從 Pin 進來，agent 從 API 進來，走的是同一條路。（目前 API 與 Web 後台已上線；Pin 與 MCP 在內測中 —— 但它們吃的是同一份規格。）

這就是我做產品的方式：先確定要解決什麼、自動化什麼；再讓人和 AI 都讀得懂；然後給現在的人一個直觀的入口，同時為未來的 agent 鋪好路。

技術會一直變，但「先想清楚要解決什麼問題」這件事，永遠不變。