最近在規劃日本的行程,丟了一句很普通的需求給 Claude:
幫我找福島市區住宿,距離火車站走路 10 分鐘內。
它很快回了一份漂亮的清單。X間飯店,標好評價、畫了地圖,每一間後面都掛著「約 5 分」「約 3 分」這種步行時間。看起來無可挑剔,我差點就直接拿去訂房了。
然後我多問了一句:「你有用 skill 找嗎?」
它老實說沒有。而且接著補了一刀——那些「走路幾分鐘」,是它用經緯度目測推的,不是真的算過。
這篇想講的,就是這一句「不是算的,是猜的」背後的東西。因為工具型 AI 最危險的失效,從來不是「它不會做」,而是「它做出一個看起來完全正確、其實沒有根據的結果」。不會做你看得出來,看起來對的你看不出來。
我手邊本來就有一套自己寫的 Claude skill(技能腳本),其中一個叫 gmap-sweep,專門做「以某個點為中心、把周圍某類店家一網打盡畫成地圖」。照理說,「車站周邊走路十分鐘內的住宿」正中它的觸發條件。
但 Claude 沒讀那個 skill,直接憑手感把答案生出來了。結果是——答案剛好沒錯(那八間確實都在範圍內),但「剛好沒錯」跟「有根據」是兩回事。它喊的步行時間,是把地圖上兩點的直線距離大概換算出來的,連這套換算保守不保守都沒人把關。
對住宿來說,這個誤差方向最傷的是喊太近。你看到「走路 3 分」就放心訂了,到現場才發現要拖著行李、過地下道、繞一大圈走十幾分鐘。錯的不是地圖,是那個沒人驗證過、卻講得很篤定的數字。
要把這件事做對,得先知道「走路 N 分鐘」到底該怎麼算。查下去才發現,日本不動產業界對這件事有法定規則。
依「不動産の表示に関する公正競争規約」施行規則(由不動產公正取引協議會連合會制定、經公正取引委員會認定),廣告上的徒步時間一律以「道路距離 80 公尺 = 徒步 1 分鐘」換算,不足一分鐘無條件進位。這個 80 公尺的基準,據說源自 1963 年一位公正取引委員會的女性職員,穿著高跟鞋實際走出來的速度。
這條規則裡有兩個細節,剛好就是 Claude 第一版漏掉的:
所以正確的做法不是不准用直線距離,而是:先用工具老老實實算出直線距離,再誠實地往上加保守修正,而不是反過來,憑印象喊一個聽起來合理的數字。
我請 Claude 寫了一支很短的腳本,把這件事釘死。核心邏輯就一行哈弗賽因(haversine)公式算直線距離,再除以一個保守的步行速度:
# 直線換算實走的保守係數:實際路網約是直線的 1.2~1.4 倍
# 取 80(m/分) ÷ 1.2 ≈ 67,寧可把時間估多一點,不要喊太近害人
WALK_M_PER_MIN = 67.0
拿福島那份清單回頭驗,差別立刻出來。最遠的那間飯店,直線距離 N 公尺,Claude 原本目測喊「約 X 分多」,用保守係數重算是 Y 分。結論沒變(還是在 10 分內),但這次的「10 分內」是有底的,前一次只是矇對。
把矇對變成算對,是這整件事的第一個收穫。
後來我把這套流程沉澱成一個專門找住宿的新 skill,叫 stay-search。寫到「篩選與分級」這一步,我很自然地給了一條規則:用評論數當可信度門檻。評論越多越可信,評分高但評論少的就標「樣本不足、僅供參考」。聽起來天經地義對吧?我自己寫的時候也覺得沒問題。
結果這條被一句話打掉了:這會系統性誤殺新開的飯店。
而且不只新開的,還有一些評論數本來就少的住宿選項也被濾掉了,只因為它「看起來很合理」,幾乎不會有人去質疑它。
寫到這我才意識到,這跟前面那條日本的 80 公尺規則,是同一個病。日本那條規則有個副作用:一間房子標「徒步 8 分」,就會從旅客「7 分以內」的搜尋條件裡直接掉出去——它根本沒機會被看見,不是因為它不好,是因為它卡在門檻的另一邊。門檻決定的不是排序,是『什麼東西存在』。
講到這裡要踩個煞車。這整件事不是要證明 AI 不可靠,也不是炫耀我多會抓錯。剛好相反——這套流程從頭到尾是人跟 AI 一起跑出來的,腳本是它寫的、skill 是它打包的、查證也是它做的。
真正的重點是:工具型 AI 的盲點,往往藏在「合理的預設」裡。 目測一個步行時間、用評論數當門檻,這些都不是低級錯誤,反而是「太合理了,合理到沒人想質疑」。
這個 stay-search skill 到現在還沒寫完,還有一些部分空著。但一個誠實留白、知道自己缺哪一塊的工具,好過一個用「看起來很合理的規則」把缺口補滿、卻默默誤殺一票選項的工具。
(本文的 80 公尺換算規則出自日本「不動産の表示に関する公正競争規約」施行規則第 9 條;福島飯店的距離與評價為搜尋當下的快照,實際數字會隨時間變動,訂房前請以官方與訂房平台為準。)