13K用戶零注冊：這個聊天工具把"反人類"設計做到了頭

13,000人每天用它聊天，卻沒人知道對方是誰，甚至不需要注冊。Chatzyo的開發者用WebRTC做了一件聽起來很矛盾的事——把技術復雜度拉滿，把用戶體驗降到零。

這像什么？像自動售貨機。投幣，拿飲料，走人。沒人讓你填會員表。

大多數聊天應用的第一步是勸退用戶。郵箱驗證、手機號綁定、設置密碼、上傳頭像——還沒開始聊，耐心已經耗光。Chatzyo的開發者算過一筆賬：快速對話場景里，每多一步操作，流失率就跳一次。他的解法干脆利落：砍掉所有步驟，打開網頁直接連。

WebRTC的"作弊"用法

技術選型上，他沒走常規路線。WebRTC（網頁實時通信技術）通常被拿來做視頻通話，他用來搞文字聊天，屬于大材小用。但恰恰是這個"浪費"，解決了兩個核心問題。

第一，延遲。消息不經過服務器中轉，瀏覽器之間直接建立點對點連接。第二，隱私。聊天內容不留存，服務器只干一件事——幫雙方找到彼此，然后退場。用開發者的原話：「No media is handled here.」

這套架構有個隱蔽的代價。WebRTC的直連成功率并非100%，防火墻和NAT（網絡地址轉換）會攔路。這時候需要TURN服務器兜底，把流量中繼一下。開發者沒回避這個坑，但也沒讓用戶感知到——連接慢了幾毫秒，總比連不上強。

瀏覽器的兼容性更麻煩。Chrome和Safari對WebRTC的實現細節有差異，Firefox偶爾抽風。他的測試清單很長，但用戶端永遠只看到同一個按鈕：「開始聊天」。

零注冊的流量悖論

沒投廣告，13K+點擊量從谷歌搜索自然流入。這個數據反直覺——匿名工具通常被認為"不好做SEO"，因為沒有用戶生成內容，沒有社交鏈條，沒有留存數據可以優化。

他的解法是把內容當產品做。圍繞"匿名聊天""無需注冊"這些搜索意圖，做了大量場景化解答。用戶搜的是"怎么快速找人聊天"，不是"Chatzyo是什么"。

這里有個產品經理的冷觀察：復雜系統的營銷成本，往往比簡單系統高一個數量級。你得教育用戶為什么需要這么多功能，而簡單系統的賣點自帶傳播性——"打開就能用"四個字，比任何廣告語都狠。

毫秒級的人心計算

開發者在復盤里提了一個細節：連接延遲對 engagement（用戶參與度）的影響，精確到毫秒級別。這不是抽象結論，是A/B測出來的。多等500毫秒，跳出率明顯上揚。

這個發現解釋了為什么他要死磕WebRTC的直連成功率。每多一次TURN中繼，都是用戶體驗的微小折損。技術債務在這里不是比喻，是字面意義上的債務——以毫秒為單位，復利計息。

平臺至今沒有消息記錄功能。用戶問過很多次，開發者的回應很克制：「No persistence.」 persistence（持久化存儲）是大多數聊天應用的默認設置，他主動放棄。代價是用戶沒法翻舊賬，收益是服務器不碰任何聊天內容——隱私承諾從技術架構層面就鎖死了。

這種設計選擇有代價。有用戶反饋想保存重要對話，開發者沒妥協。產品定位因此更清晰：這不是你的第二個微信，是特定場景下的工具——需要快速、匿名、不留痕跡的對話時，用它。

你現在打開Chatzyo，看到的界面和三年前幾乎一樣。沒有功能膨脹，沒有會員體系，沒有"你可能認識的人"。開發者把"不做"的清單列得比"做"的更長，這在功能競賽的社交賽道里，算是一種反向操作。

WebRTC的瀏覽器支持還在進化，TURN服務器的成本隨著用戶量線性增長。下一個技術決策可能是自建中繼網絡，也可能是探索WebTransport等新協議。但核心原則沒變：用戶不該為技術細節買單。

最后一個數據點：那13K日活里，平均會話時長4分32秒。足夠聊完一件事，不夠建立一段關系——這正是設計意圖。

如果讓你設計一個"反社交"的社交產品，你會先砍掉哪個功能？