系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄

一個我當時很得意的觀察

工具上線三天後，GitHub 的數字是：

12 Stars / 15 Forks

Fork 比 Star 多。

我當時的解讀是這樣的：Star 是收藏，Fork 是拿走。

按 Star 只需要零點五秒，代表「這看起來不錯，我先存著」。而 Fork 是把整份程式碼複製到自己的帳號下，通常意味著你打算改它、跑它、部署它。

所以 Fork > Star 的意思是：看到這個工具的人，比較傾向於「拿去用」而不是「先收藏」。

對一個工具型專案來說，這是一個很好的訊號。我還為這件事寫了一篇 LinkedIn。

兩個月後我回去看數字

27 Stars / 23 Forks / 0 Watching

三件事發生了。

1. 模式反轉了

Star 增加了 15，Fork 增加了 8。

後來的訪客更傾向於收藏，而不是拿走。

2. 我原本的解讀，只在特定時期成立

如果 Fork > Star 代表「傾向部署」，那 Star > Fork 就代表「傾向收藏」。

而如果兩個時期的解讀都成立，那我得到的結論是：

最早來的人比較會拿去用，後來的人比較會先收著。

這個現象其實不難理解。最早找到一個小眾工具的人，通常是正在找解法的人——他有問題要解決，所以他拿走。

而後來的人，很多是從 LinkedIn、從 iT 邦文章、從搜尋結果過來的——他們是看到有趣東西的人，不一定當下有問題要解。

所以模式反轉，可能只是說明流量來源變了。

3. 那個 0

0 Watching。

二十六個人按了 Star，二十三個人 Fork 了，沒有一個人在追蹤這個專案。

Watch 的意思是「這個專案有活動的時候通知我」。

而 Star、Fork、Watch 三個動作，代表三種不同的意圖：

前兩個是關於「現在」，第三個是關於「未來」。

而關於未來的那一個是零。

所以我到底知道什麼

寫到這裡我必須誠實面對一件事：我對這個工具的實際使用狀況，知道得非常少。

把「有多少人真的在用」這個問題，用我自己在 Day 12 到 Day 15 講的那套標準來檢驗一次。

哪些是已成立的事實？

只有兩件：

1. tskerpnext 真的在用。 因為 Issue #1 那個 bug——切到 Gemini 分頁存 Key 但 provider 沒切——你必須真的去填 Gemini Key 才會撞到。 這不是看程式碼看得出來的。

2. kuang1963 真的在用。 Ollama 的 CORS 錯誤，你必須真的裝了 Ollama、真的去切換、真的按下送出，才會看到 Failed to fetch。

兩個人。這是我唯一有硬證據的數字。

（還有一個間接證據：程式碼裡那段 it_key → it_key_claude 的搬遷邏輯之所以存在，是因為早期版本有使用者。但我不知道那是幾個人，也不知道其中有沒有包含上面那兩位。）

哪些是假設？

• 23 個 Fork 裡有多少是真的部署了？不知道。 Fork 也可以只是一種收藏方式——按 Star 之外的另一種「先存著」。
• 27 個 Star 裡有多少人打開過工具？不知道。
• 有沒有企業真的部署了？不知道，而且沒有任何人回報過。

所以誠實的結論是：50 個訊號，2 個確認的使用者。

我原本的解讀錯在哪裡

回頭看，我在六月的解讀有一個方法上的問題。

我看到 Fork > Star，然後為這個現象找了一個對我有利的解釋。

「Fork 代表部署」這個解釋是合理的。但「Fork 代表另一種收藏方式」也一樣合理，而我當時沒有認真考慮後者。

我做的不是分析，是為一個好看的數字找理由。

而檢驗的方法其實很簡單，就是 Day 13 那條決策相關性測試：

如果我知道 Fork 到底是部署還是收藏，這會改變我接下來做什麼嗎？

會。差別很大：

• 如果是部署 → 我該優先做的是穩定性、README 疑難排解、企業導入文件
• 如果是收藏 → 我該優先做的是降低第一次使用的門檻（還記得 Day 11 那個「五個步驟申請 API Key」嗎）

這是一個會改變行動的問題。所以它值得問。

而我當時沒有問，我直接跳到了對我有利的那個答案。

Day 12 的規則 1：不要在證據不足時跳到結論。 我論證了三天，然後在自己的專案數據上違反了它。

那個 0 Watching 才是最該看的數字

如果要挑一個數字來看，我現在會挑 Watch。

因為 Star 和 Fork 都是一次性的動作——你按了就走，之後不需要付出任何東西。

Watch 是一個持續性的承諾。你願意讓這個專案的動態出現在你的通知裡，代表你在意它會變成什麼樣子。

0 Watching 的意思是：沒有人把這個專案當成一個會持續發展的東西在看。

它被當成一個現成品：拿走、用了、結束。

這對一個工具來說不一定是壞事——一把好用的螺絲刀，你也不會想知道它的下一個版本。

但對一個想發展成產品的專案來說，這是一個需要正視的訊號。

結構化地看這些數字

可控 vs 不可控

我控制不了有多少人按 Star。

我控制得了：README 寫得多清楚、疑難排解章節多完整、Issue 回覆多快、第一次使用的門檻多低。

而這四件事，全部都不會反映在 Star 數上。

核心 vs 外部

核心問題是：有沒有人因為這個工具，把一個故障修好了？

Star、Fork、Watch 全部都是外部代理指標。它們跟核心問題有相關性，但沒有一個能直接回答它。

而我唯一有的兩個真實回答，來自兩個回報 bug 的人——而他們回報的正好是「工具在他們手上壞了」。

我對這個工具最確定的兩個使用事實，都是失敗案例。這不是諷刺，這就是開源的常態：只有壞掉的時候，使用者才有理由開口。

假設 vs 已成立

我該怎麼真的知道

如果我想把「有多少人在用」從假設變成事實，可行的方法：

不可行的： 加使用追蹤。這違反整個專案的前提——零後端、零依賴、資料不出使用者的瀏覽器（Day 11、Day 19）。我不能為了知道有多少人在用，而破壞「不收集任何資料」這個承諾。

可行的：

• 在 README 加一個「如果你部署了，歡迎在 Discussions 說一聲」
• 主動去問那 23 個 Fork 的帳號（有點侵擾，但至少是誠實的方式）
• 接受這個工具的性質就是「發出去就不知道了」，把力氣放在讓拿到的人自己能搞定

第三個可能是對的答案。 一個純靜態、零後端、可離線的工具，本質上就是一個發出去就失去聯繫的東西。

而那正是它的價值。 我不能同時要求「完全不追蹤使用者」和「知道使用者在做什麼」。

這是我自己選的架構帶來的必然後果，我得接受它。

今天的反思

這篇文章原本的標題和論點，是「Fork > Star 代表實際部署」。

數據反轉之後，我可以換一個新的、同樣好看的解讀（「Star 成長更快代表知名度擴散」之類的）。

但我覺得誠實的版本更有用：我在六月看到一個好看的數字，然後為它找了一個對我有利的解釋，而我沒有檢驗它。

而更有用的部分是那個 0——它一直都在那裡，只是我在意 Star 和 Fork 的時候沒有看它。

一個你沒有在看的指標，通常比你天天在看的那個更誠實。

明天預告： 說到企業。企業版是我規劃裡的下一步，但我必須先講清楚一件事——關於企業部署，我手上的實際回饋是零。所以明天那篇會是一篇關於「還沒被驗證的商業計畫」的文章。

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣