三九九項測試先被寫進了說明書：Edge-Cloud Gateway 的徵求測試貼文，是一頁被設計過的誠實

先從一個數字看起：399。

在 V2EX 的「分享創造」節點裡，一位開發者貼出了自己的開源專案 Edge-Cloud Gateway，並希望找三到五位開發者實際跑一遍。貼文不長，但開頭沒有願景宣言，沒有「重新定義」之類的字眼，第一段就講清楚這個東西放在哪裡：它位於 OpenAI 相容客戶端與本地、雲端模型之間，依安全規則決定一份請求要完整上雲、先在本地篩選上下文再上雲，或者幹脆留在本地模型處理。

然後才是那個 399。它出現在功能清單裡，和「36 個合成安全場景」「MIT 許可證」「公開 CI」並列。一個實驗性專案的說明文字，把測試數量寫得這麼精確，本身就是一種設計選擇。

誠實被排成了清單的順序

多數開源專案的 README 有一種常見的表情：功能寫得滿滿，限制藏在最後，或者幹脆不寫。這則貼文的做法剛好相反。它先給功能，再給一句先聲明：「項目目前不是生產可用版本，沒有客戶端認證、TLS 和多租戶隔離，請勿直接暴露到公網。」

這句話的位置值得停下來看。它出現在功能列表之後、徵求測試之前，恰好在讀者最可能心動、也最可能誤用的那個節點上。資訊設計裡有所謂的「及時警示」：警告要在使用者即將行動的那一刻出現，才會被讀進去。放在文首會被略過，放在文末來不及。這位開發者未必學過資訊設計，但貼文的排序自然長成了這個樣子，這與我們先前分析過的字節跳動面經作為一種篩選介面有相似的邏輯：順序本身就是訊息。

再看回退機制的描述。「項目不會強制壓縮請求。如果本地篩選失敗、不安全或者沒有產生實際縮減，就恢復完整請求。」這是整段文字裡最誠實的一句，因為它描述的是產品何時決定「不要做它被期待做的事」。多數專案只講 happy path，這裡卻先講了三種放棄的條件。工程上的回退邏輯，被翻譯成了使用者能讀懂的承諾。

三到五位：一個被刻意壓小的人數

徵求測試的人數寫的是「3 到 5 位」。對照這個社區的規模，貼文發布十幾小時有三百多次瀏覽，這個數字小得近乎固執。

但小有人數的道理。貼文要的回饋很具體：安裝與首次啟動是否順利、README 有沒有看不懂的步驟、Ollama 與 Open WebUI 等相容服務能否接入、路由與回退設計是否符合實際需求。這四個問題都是需要真的把專案跑起來才答得出來的，答題成本高，人數就得收窄。三到五位是作者對自己專案此刻能承受的回饋量的估算，也順手把「刷 Star」的期待排除在外，貼文裡那句「不求幫忙刷 Star，真實 Issue 和兼容性回饋更有價值」講得直白。

這種把樣本數寫進徵求文案的做法，在開源世界不算常見。更常見的是「歡迎大家試用」，一種不設上限、也就不承諾任何後續的寫法。寫明三到五位，等於承認維護者的回應頻寬有限，也讓每一位來測試的人知道自己算數。這是一份被設計過的期待管理。

v0.1.0 的自我克制

版本號是另一個細節。399 項自動化測試、36 個安全場景，配的卻是 v0.1.0。照一般開源專案的版本慣例，這個號碼等於明說：什麼都可能變，包括介面。

這種組合構成了一種不多見的版本敘事。很多專案在測試覆蓋率還很薄的時候就敢標 1.0，把版本號當行銷；這裡把兩者對調，用工程投入撐住說服力，用版本號壓低承諾。使用者在打開倉庫的那一刻，從版本號讀到的訊息與貼文裡那句「不是生產可用」完全一致。介面與文案講同一種話，這正是好的產品溝通該有的樣子。

同場景可以對照的，是各種 AI 閘道與路由類專案的常見寫法：強調效能數字、強調省了多少 token、把本地模型講成隱私的萬靈丹。這則貼文講的卻是「篩選失敗就恢復完整請求」，等於承認本地判斷可能出錯，而且出錯時不走捷徑。相較於把不確定性包裝成賣點，這是反方向的修辭。

沒有留言的頁面，與它考驗的東西

截至寫作時，這則貼文還沒有留言。三百多次瀏覽、零回覆，對一個 v0.1.0 的實驗專案來說是常態，卻也讓貼文本身成了唯一的介面。

這正是此類文案真正被考驗的地方。沒有討論串來補充語境時，README 與貼文的每個措辭就是全部的第一印象。這個專案的第一印象做得扎實：功能、限制、測試規模、許可證、明確的請求，各自站在該站的位置上，沒有一句話在推銷。就像一份好的衛教清單會把「何時該就醫」寫在醒目處，這份貼文把「請勿暴露到公網」寫在行動之前，兩者共享同一套資訊設計的直覺。

一個閘道類的基礎設施專案，最終賣的是信任。信任沒有辦法用形容詞建立，只能靠可查驗的細節：測試數量、CI 連結、回退條件、不存在的功能的坦白。這則貼文把這些細節排成了順序恰當的一頁文字，對一個還沒有人留言的專案來說，這頁文字就是它的門面，而這扇門做得比多數 1.0 版本還誠實。