WFGY 被多個 awesome list 收錄，這其實代表一件很現實的事
WFGY 被多個 awesome list 收錄，這其實代表一件很現實的事
最近我做了一件小小的紀錄，算是報喜也算是觀察。
WFGY 這個 repo 以及我整理的「16 問題清單」，開始被幾個 AI 領域的 awesome list 收錄了。裡面包含一些星數很高的 repo，其中也有 4000+ stars 等級的整理型專案。
我知道有些人對「被收錄」這件事會覺得很普通，好像只是清單多了一行文字而已。
但我想講的是，這在開源世界其實是一個很明確的訊號，尤其在現在這個 vibe coding 的年代，訊號比以前更重要。
1. awesome list 為什麼是一種訊號
現實一點講，AI 時代「內容造假」的成本已經很低了。
你可以很快寫出一篇看起來很像論文的文章，也可以很快做出 demo 頁面，甚至把 UI 做得很像產品。
但有一件事很難快速造出來：
被別人願意主動收錄，被別人願意把你放進他們的「常用工具列表」。
尤其 awesome repo 的維護者其實很常被廣告轟炸，他們每天都在過濾：
這個到底是認真做的，還是只是包裝得像很認真。
所以當一個東西被多個列表收錄，它不是「官方認證」，但它是一個很實際的市場訊號：
這東西對某些開發者是有用的，至少值得被放進工具箱。
我自己做開源一路走到現在，其實越來越覺得：
stars 是一種熱度，收錄是另一種「被當成工具」的證據。
2. WFGY 到底是什麼？
很多人看到 WFGY 以為它是一個新模型，或是一個新框架要你換掉一堆 infrastructure。
其實不是。
WFGY 從 1.0 到 3.0 的核心精神都很簡單：
我把「怎麼讓 LLM 更穩、更不亂講、能用在工程現場」這件事拆成可以被文字攜帶的結構，讓你不需要改模型，不需要 fine-tune，也不需要換平台。
它比較像一種 text-level 的 reasoning kernel。
你可以把它當作：
你在把 LLM 當成系統時，需要的一套安全邏輯與推理結構。
3. 那個「16 問題清單」到底在幹嘛
如果要講最白話，16 問題清單其實就是：
AI 工程師每天在踩的地雷大全。
尤其是做 RAG、向量庫、agent、tool calling、prompt injection、資料污染、部署順序、回傳格式崩壞等等，這些不是學術題，是你上線後會爆炸的題。
我把這些問題整理成一份「Problem Map」，每一類問題都有：
根本原因（不是表面症狀）
典型錯誤型態
如何快速診斷
對應的修復策略與 guardrail
它不是「給你一個 prompt 就好了」那種。
它比較像是：
把工程現場的失效模式，變成你可以複製貼上拿去診斷的流程。
你可以把它想成一個語義防火牆，也可以想成一個 Debug 診所。
很多人一開始覺得「這聽起來很抽象」。
但你真的做過 RAG，上過線，遇過 hallucination 把你整個 pipeline 拖下水，你就會懂那份清單的價值。
4. 為什麼我覺得這次收錄值得講一下
因為這等於在說：
不是只有我在講這東西有用。
至少已經有一些整理生態的 repo 維護者，願意把它放進他們的工具地圖裡。
這對我來說是很實際的鼓勵，也是一個提醒：
下一步該把更多「落地 demo」做出來，讓更多人可以直接拿去用。
5. 接下來我想做什麼
我目前的方向很簡單：
把 WFGY 這套東西變成更多可重現的案例，讓它不只是文字上的世界觀，而是真正在不同場景可被測量、可被驗證的東西。
如果你是：
做 RAG 的
做 agent 的
做 tool execution 或 workflow 的
做 benchmark / evaluation 的
或你單純就是喜歡研究「怎麼讓 AI 不亂講」
那你可以來看一下 WFGY。
我也開始慢慢開放更多合作與討論，尤其是偏工程落地、benchmark 任務設計、可重現的 workflow 類型。
你有興趣可以進群聊聊，或直接在 repo 開 issue。
我不急著把它變成行銷，而是希望它在公開壓力測試之下站得住腳。
入口
WFGY 主 repo（MIT open source）
https://github.com/onestardao/WFGY
我會把這次收錄的圖放在本文下面，當作一個小記錄。
接下來繼續做事。
留言
張貼留言