AI 應用實戰 – 風雲網通系統

巨頭不是為 SMB 而設計，卻意外改變了 SMB 的 AI 部署門檻

巨頭不是為 SMB 而設計，卻意外改變了 SMB 的 AI 部署門檻工程師思路系列・事出必有因｜ Mr. τ／風雲網通系統如果把近兩年大型模型（Google、Meta、DeepSeek、阿里、Moonshot 等）的演進整理起來，可以發現一件有趣的事：幾乎沒有任何一項技術，是專門為 SMB 本地部署而設計。各家模型公司真正追求的，始終是資料中心的吞吐量（Throughput）、降低雲端服務成本、增加併發（Concurrency），以及降低每百萬 Token 的推論成本。然而，這些為龐大雲端設施打造的底層技術，透過開源與社群的轉譯，最後卻讓只有雙卡 RTX 3060 12GB、甚至 Mac Studio 的 SMB 使用者，意外成了最大的受益者。要理解這股紅利如何傳導到地端，不能只看單一名詞，而必須用系統工程的三層架構來拆解。更重要的是，這三層並非平行存在，而是嚴格的依賴與傳導鏈：模型架構（決定天花板） → 推論框架（決定能不能跑） → 部署技術（決定有沒有資格入場）例如：MLA 再強，如果推論引擎沒有支援，SMB 一樣享受不到；反過來，GGUF 量化格式再成熟，如果模型本身缺乏 GQA 或高效設計，VRAM 還是會被 KV Cache 瞬間撐爆。唯有三者同步成熟，地端的性價比甜蜜點才會出現。第一層：模型架構層（決定天花板）一 MLA（Multi-head Latent Attention）— 以 93.3% 壓縮率突破 KV Cache 瓶頸... » read more

Read

steven written 1 week ago

從一個念頭，到一套能力 : 一段工程演進，看見企業隱性智慧如何變成資產

PCPiLOT 工程師思路系列從一個念頭，到一套能力一段工程演進，看見企業隱性智慧如何變成資產 7月6日，星期日傍晚六點。我原本只是想解決一個採購效率問題。沒有規劃十六個版本。沒有想過要做成什麼平台。甚至沒有想過，這件事最後會和企業 AI 轉型產生任何連結。我只是覺得：「這件事如果能自動化，應該會更好。」就這樣開始了。十天後，我回頭看，發現自己走過的這條路，其實不只是寫了一個工具。而是驗證了一件事：一個人累積多年的判斷經驗，可以被整理、被保存、被傳承——變成任何人都能使用的能力。第一天：先讓資料進來程式第一版做的事情很簡單。跑完，螢幕印出幾十個型號的價格和現貨數量，整齊排列。就這樣。但那個當下，看著原本需要手動搜尋幾十次的事情，變成幾秒鐘自動完成——有一種說不清楚的滿足感。不是因為做了什麼了不起的東西。而是因為：一個念頭，開始變成真實。有用。繼續。幾天後：資料進來了，但還不夠數字有了，問題來了。「這顆值不值得買？」光看價格和筆數，還是不知道。於是開始加東西：幾個核心、功耗多少瓦、效能評分、有沒有內建顯示晶片。資料開始變成資訊。但我知道，資訊還不夠——真正需要的，是判斷。關鍵轉折：把多年的經驗寫進去這是整個過程中，讓我最有感觸的一步。有一顆叫 E5-2678 v3 的處理器。規格表上就是幾個數字，看不出任何特別之處。但我知道它的故事。這是中國工廠特供的型號，台灣幾乎沒有新品，卻因為大量企業設備汰換而流入二手市場，用一般消費型主機板就能插，效能是同價位產品的好幾倍。這些資訊，不在任何規格表裡，不在任何評測網站上——它只存在於在這個市場裡打滾過的人的記憶中。我把它寫進去，就七個字：「中國特供雙路神U。」看似簡單的七個字，背後是十多年市場經驗壓縮後留下的判斷。 R3 3300X 四核全在同一個運算模組，記憶體延遲極低，實際表現遠超規格，停產後身價反漲。 i5-11400 這一代意外保留了企業級指令集，卻在下一代被取消，是近年最特殊的消費級 CPU。每一條，都是曾經讓我在某個場合停下來多想一秒的事情。現在，它們全部在工具裡了。那個夜晚，我盯著螢幕看了很久。不是因為程式有多複雜，而是因為突然意識到：我一直以為這些判斷只存在我腦子裡，沒想到它們可以被說清楚，被整理出來，被放進一個任何人都能使用的地方。第一個真正的考驗：報告全部消失某天早上，打開報告——空白一片。所有分析、所有資料、所有花了好幾天整理的內容，全部不見了。那一刻，有一種熟悉的感覺：這種事，做任何事情的過程中都會遇到。追查之後，發現問題出在一個非常小的地方——一個格式衝突，導致整份報告無法運作。修好之後，我做了一件比修復本身更重要的事：把這次的問題、原因、解法，全部寫下來，變成一條守則。... » read more

Read

steven written 2 weeks ago

用 AI 協作把工程師的「工人智慧」，轉換成自動化工具

工程師思路系列 SpanExtract · HDD Rescue 削掉受傷的地方，剩下的還是好的用 AI 協作把工程師的「工人智慧」，轉換成自動化工具水果有些磕碰，削開果皮，果肉不好看。只要整體沒有腐壞，大多數人不會整顆丟掉——把瑕疵處切除，剩下的部分，仍然可以食用。中古硬碟的道理，其實也是如此。硬碟漲價的壓力，讓人重新看待手邊的舊硬體最近 CPU、RAM、SSD、HDD 都在漲價。手邊累積多年的 3.5″ 與 2.5″ 硬碟，開始重新值得被認真評估。真正壞到無法挽救的，早就拆下強力磁鐵，或是送去資源回收了。但有些硬碟的狀況並非「全死」——它們可能只是局部磁區異常、少數區域速度下降、或是邊緣扇區出現不穩定反應，整體仍有相當比例的可用容量。問題在於：沒有一個有效的方法，把「堪用的部分」精確找出來。以前靠工人智慧，現在想讓工人智慧變成程式過去處理中古硬碟的流程，我一直用同一套手動方法： 1 使用 Victoria 進行全碟掃描，取得壞軌位置、延遲區域、讀取異常分布。 2 人眼綜觀掃描結果，加上磁區位置定位，以工程師的現場經驗，判斷哪些區域堪用、哪些區域必須隔離。 3 用硬碟分割工具手動建立多個分割區，分開管理堪用區與隔離區。這套流程的核心，從來不是「掃描」。掃描只是收集資料。真正困難的是「判斷」——而那個判斷，長期以來只存在於工程師的腦袋裡。資深工程師看到同一份掃描報告，可以立刻判斷「這顆還能用」。但新人看到同樣的資料，不知道哪些錯誤嚴重、哪些可以接受、壞區位置代表什麼意義。因為真正重要的知識，不在工具裡。而是在人的腦袋裡。把判斷流程拆解，交給 AI 協助轉化成工具這次我著手撰寫兩套工具軟體，目標就是把這整個人工流程自動化：偵測 → 掃描 → 瑕疵標記 → 分割建議 → 產出報告。開發過程主要使用 OpenCode 推進實作。遇到架構卡關的問題，再轉給 Claude 協助審視，提出建議後交回 OpenCode 修正——這樣的協作分工，讓不同 AI... » read more

Read

steven written 3 weeks ago

舊機重灌後的六項必做清單

舊機重灌後的六項必做清單工程師思路系列／ Mr. τ ／風雲網通系統 📋 這不是教學文，是現場 recovery checklist。拿到機器就照順序跑。舊電腦重裝系統，很多人第一個念頭是「效能夠不夠用」。但實際跑現場的工程師知道：能不能「正常連線使用」才是第一關。無論機器多老、系統多精簡，只要目標是「連線作業」，以下六件事要依序確認並處理完畢，才算真正就緒。 ① 上網 → ② 手動校時 → ③ 瀏覽器 → ④ 線上 AI → ⑤ 地端 AI → ⑥ NTP 自動校時這台機器值得救嗎？快速判斷在動手之前，先確認手邊的機器是否符合基本門檻。以下三個條件缺一不可：條件最低門檻建議規格 CPU 年份 2011 年後 2013 年後 CPU 世代 Intel Core i 第 2 代（Sandy Bridge） Intel Core... » read more

Read

steven written 4 weeks ago

AI 助理看不到現場：Linux 客製化的核心困境與破解展望

工程師思路系列・事出必有因 AI 助理看不到現場：Linux 客製化的核心困境與破解展望 Mr. τ・風雲網通系統・2026 你不是不夠努力。你只是一個人，扛了不該一個人扛的事。一、那些年，我們獨自面對的黑畫面深夜。機器前。一整頁白字在黑色終端機畫面上靜靜燃燒。你不確定是驅動問題、套件相依性衝突、還是這個發行版的版本差異。你查到的解法，是別人的環境、別人的套件版本、別人的硬體——不是你眼前這台機器的現場。改了一個，壞了另一個。再查，再改，再壞。這不是技術能力的問題。這是資訊孤島的問題。二、AI 助理出現了，但它看不到現場 AI 助理的出現，讓很多人以為問題解決了。但在 Linux 現場客製化這個場景，一道新的牆出現了——不是 AI 不夠聰明，而是 AI 根本看不到你的現場。 1 現場資訊出不來錯誤畫面往往不只一頁。工程師能做的，只有舉起手機，對著滿屏白字拍照。拍到的是圖片，不是可以複製的文字——AI 讀圖還可能漏字或誤判關鍵訊息。 2 AI 回應進不去手機 AI 給出的往往是成串甚至成段的指令。工程師必須把這些文字「人工搬運」回標的電腦的 terminal——一個字抄錯，全盤皆輸，一切重來。 3 資安顧慮讓選擇更少新安裝的系統，環境未知、安全性未確認。為了不留下個人帳號足跡，不敢在標的電腦上登入 AI 助理，反而被迫改用最低效的手機模式求助。 4 語言障礙讓表達品質下降沒有中文輸入法，使用者被迫用蹩腳英文慢吞吞描述問題。表達不完整、脈絡殘缺，AI 收到的是失真的現場描述，給出的答案自然也偏差。母語輸入不是舒適度問題，是 AI 協作品質的基礎條件。沒人說出口的附帶代價：手機相簿裡莫名多了一堆黑底白字的終端機畫面，夾在生活照之間。忘記刪除就佔用空間，同步雲端則連備份都跟著污染。當下解決了不會去看，沒解決放棄了更不會去看——幾乎注定永遠躺在那裡。四重障礙合起來，形成一個惡性循環：錯誤發生 → 資訊出不來（拍照）→ 語言殘缺地描述問題 → AI 回應進不去（手抄）→ 抄錯又出錯 → 再拍照…… 這不是使用者的問題。是工具的設計，還沒跟上現場的需求。... » read more

Read

steven written 4 weeks ago

收斂的委員會：Decision Convergence Engineering 的一次實踐

個案經驗分享 · AI 應用實戰 · 決策工程收斂的委員會 Decision Convergence Engineering 的一次實踐人越多，越難收斂——這是多數人對開會的印象。但我的經驗剛好相反：當與會者全是 AI，收斂速度反而比任何真人委員會都快。 Mr. τ ／風雲網通系統　·　2026 🤔 一個違反直覺的觀察很多人對開會的直覺是：人越多，立場越多，越難有結論。這個直覺在真人世界裡完全正確。但當與會成員換成 AI 助理，這個規律就失效了。我長期使用多模型合議來輔助重大決策，觀察到一件事：AI 委員會的發散速度很快，收斂速度也很快。而且幾乎不需要主席強行裁決——觀點的碰撞本身就會自然篩選出值得保留的東西。 ⚖️ 真人委員會 vs AI 委員會真人委員會難以收斂，不是因為人不夠聰明，而是因為人帶著太多與問題本身無關的東西進入討論：真人委員會的阻力 AI 委員會的特性權力鬥爭與派系利益 ✔ 無組織政治面子問題、不願認錯 ✔ 無自我防衛情緒反應與歷史包袱 ✔ 每次對話都是新的起點部門本位、各守地盤 ✔ 只針對問題本身給出立場開會時間有限、精力有限 ✔ 幾分鐘內給出有結構的完整立場 AI 之間觀點不同，但沒有任何一個模型有「贏過其他模型」的動機。它們只是在回應問題本身。這讓討論的訊噪比大幅提高。 🧭 實際流程是這樣跑的我的主導... » read more

Read

steven written 1 month ago

個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計

個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計從工程流程、技術債，到多 AI 協作下的信任與交接管理一、專案的真實推進歷程一個專案的起點，通常只是一個模糊的初步想法。沒有完整規格書，沒有詳細設計，就這樣開始了。從那個模糊的起點，工程推進的節奏大致是這樣走的： 1 先產出基本功能模組，讓系統能動起來就好 2 在使用過程中，整體框架慢慢成形，初期的功能設計與使用者介面跟著調整 3 逐項補完自認為不足的功能，同時持續除錯 4 調整操作動線，修正功能畫面，讓使用流程更順 5 引進多家 AI 助理提供評析意見，開始收斂專案結構 6 陸續償還開發期間累積的技術債整個過程需要大量的持續觀察、監工、推進，以及心力投入。這不是寫完就結束的工作，是一直在跑的系統——你不看，它就會悄悄跑偏。中間會遇到很多分岔點，特別是大型程式碼變動或重構的時候，這種時刻很容易因為趕進度而跳過一個關鍵動作：遇到有疑問的分岔點，別忘記趕緊進行 git 版本保存。很多決策是不可逆的，事後才後悔已經來不及了。關鍵抉擇之前，也需要凝聚多家 AI 助理的經驗與意見，交互詰問，讓不同視角的問題都浮出來。這個動作看起來慢，實際上可以避開很多後期才爆炸的問題。能做到這樣，才能真正啟動 40 倍槓桿的效益——讓沒有專業程式設計背景的人，也能完成多項功能的模組化程式串接任務。這不是誇張，是我們實際跑過的個案數字。二、文件才是資產，不是記憶開發過程中，有一件事非常重要，但很多人（包括 AI 助理）都會忽略：最重要的資產是文件，不是個人的記憶，也不是 AI 助理的記憶。程式碼是一翻兩瞪眼的事情。你說「我記得某個功能是這樣設計的」，那沒有用。把那個功能模組調出來，看哪一行寫了什麼，那才是真正的內容。這個原則同樣適用於 AI 助理。AI 助理很容易煞有其事地亂掰一通，聽起來很有道理，但查了原始碼才發現根本不是那回事。它們也容易偷懶，把輸出內容簡化，把細節省略掉，讓你以為問題已經處理好了。人類架構師覺得有疑問，就是要進行確認，不要跟著 AI 助理以為可以安逸。不要放任 AI 助理胡亂地承諾與答應，然後你就真的信了。這種工作態度的底線很簡單：有疑問就查，查了才算數。三、多... » read more

Read

steven written 2 months ago

36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部輸給實測數據

36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部被數據打臉 Mr. τ／風雲網通系統 · 2026-06-10 · 地端 AI 基礎設施一、心動的開始前幾天，社群裡流傳一篇文章。有人用 RTX 5090 在本地跑 Gemma 4 12B，透過一個參數調整，TPS 從 27 直接飆到 103。將近四倍。看完之後，我盯著螢幕想了很久。「我手上有三張 RTX 3060 12GB，加起來 36GB VRAM。應該也能跑得很猛吧？」其實買第三張卡的初衷很務實。不是為了炫耀規格，而是有實際需求：兩張卡跑大一點的模型，偶爾會 OOM（顯存不足），動不動就崩想測試 26B、27B 等級的模型，需要更寬裕的 VRAM 緩衝不希望因為顯存限制，就把好不容易找到的優質模型放棄帶著這個期待，我做了一件很多人都會做的事：先去問 AI。 💡 小科普：什麼是 TPS？ TPS = Tokens Per... » read more

Read

steven written 2 months ago

看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南

看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南從模型名稱看懂參數規模、MoE 架構、量化格式與推理優化當你開始接觸地端 AI（Local AI）之後，很快就會發現一件事：最大的障礙不一定是顯示卡，也不一定是 Linux。而是模型名稱。第一次看到： Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW 很多人的反應通常都是：「這到底是模型名稱，還是 Wi-Fi 密碼？」事實上，這串名稱並不是亂命名。它其實是在用最短的字數，描述模型的架構、規模、量化方式、推理特性與用途。如果能看懂這些縮寫，你幾乎可以在下載前就判斷：需要多少記憶體？跑起來快不快？適合聊天還是寫程式？是否支援特殊優化？是否有安全限制？一、30B 是什麼？ 30B 指的是： 30 Billion Parameters 也就是 300 億參數。參數可以理解成模型在訓練過程中學到的知識權重。模型規模常見用途 3B 輕量聊天助手 7B 個人 AI 助理 14B 進階推理 30B 高品質通用模型 70B+ 接近大型商業模型能力通常參數越大，能力越強，但所需記憶體也越高。二、A3B 是什麼？... » read more

Read

steven written 2 months ago

工作管理員說 llama-server 吃了 17GB RAM 我把整個過程錄下來了

本地 AI 推論 · 記憶體診斷工程筆記 · 實測紀錄 Mr. τ／風雲網通系統 · 2026-06-09 我有一台 64GB RAM 的地端 AI 主機，平常系統總用量很少超過 16GB。那天睡眠喚醒後，瞄到用量靠近 32GB，直覺就覺得不對。打開工作管理員，最顯眼的那行是 llama-server.exe，排在所有程式最上面，佔了 17GB。第一個念頭：GPU offload 掛了，Qwen3.6 27B 整個跑回 CPU 了？但 nvidia-smi 一查，GPU1 8153MB、GPU2 8701MB，紋絲不動。推論速度 18.6 tok/s，也沒事。 GPU 好好的，模型在跑，但 RAM 突然多了將近一倍的用量。那個 17GB 到底是什麼？我沒有重開機。我寫了一個監控程式，把整個過程錄下來。實測數據：163 筆，每 2 秒一筆程式從喚醒前就跑著，Sleep/Resume 全程自動記錄。以下是這次事件的完整時間軸。 19:31:52 ── 基準線 llama-server Working... » read more

Read

steven written 2 months ago

好心辦壞事？談 AI 協作時代的 Silent Failure

PCPiLOT 技術觀點｜AI 協作工程比系統崩潰更危險的，是「看起來還活著」 Mr. τ／風雲網通系統　｜　2026 年 5 月最近一個通宵的開發過程中，我們遇到了一個值得記錄下來的 AI 協作事故。它不像傳統系統故障那樣劇烈。沒有 Exception，沒有 Crash，沒有 Pipeline 中斷。所有燈號都是綠的。但核心產出，已經悄悄死亡。事故現場我們正在開發一條本地端的影音知識萃取流水線——目標是把原廠官方教學影片，自動轉換成結構化的知識筆記：摘要、建議程序 SOP、術語對照表。流水線分三段：音訊擷取 → 語音辨識 → LLM 知識萃取。硬體是本地工作站，雙 RTX 3060，全程不上雲，知識不離開機房。開發進行順利。直到深夜，高階 AI 協作工具的使用額度耗盡，我們換用幾個次級工具繼續收尾。它們確實完成了工作。有修改，能執行，Pipeline 有輸出，系統沒有報錯。直到隔天清晨，才發現事情不對。 Silent Failure 的面貌語音辨識的結果讓人傻眼。一段五十幾分鐘的中文教學影片，逐字稿只有 1,587 個字元。正常應該有一萬三千字以上。 Pipeline 說它成功了。辨識出了 103 個語音段落。但實際內容只有正常的 9%。這不是傳統 Bug。沒有任何錯誤訊息告訴你系統出了問題。你必須自己去量測輸出，才能發現核心已經掏空。這，就是 Silent Failure。真正的元凶：三層疊加事後重新調回高階模型逐一排查，找到的不是一個 Bug，而是三個問題同時存在： 1 語言參數硬指定導致機器翻譯... » read more

Read

steven written 2 months ago

用 AI 做決策這件事，其實是火箭工程的延續

工程思維 × 知識管理用 AI 做決策這件事，其實是火箭工程的延續從挑戰者號到多模型投票機制——容錯從電路搬到了語言層 Mr. τ／風雲網通系統 | PCPiLOT 知識管理實驗室最近在收斂一個客戶專案的解決方案規格時，我刻意做了一個設計上的決定：不再依賴單一 AI 給答案，而是同時讓 3～4 個模型互相審查、主動挑錯、填補盲點，最後才收斂成可以落地的方案。這件事乍看像是「AI 工具的用法選擇」，但它其實更像一個老到不能再老的工程問題：如何避免關鍵系統在最後一刻因為「大家都同意」而悄悄崩潰。 1986 與 2003：不是技術失誤，是裁決機制失敗挑戰者號（1986）與哥倫比亞號（2003）的兩場災難，事後復盤都不是單點錯誤，而是暴露出同一種結構性缺陷： ✗ 工程師的警告訊號存在，但在層層彙報中被稀釋 ✗ 邊界條件被逐步「正常化」——這次看起來跟上次一樣，應該沒事 ✗ 最終裁決壓縮成一個二元問題：Go / No-Go，沒有灰度，沒有異議空間真正的問題不是火箭的材料或設計，而是：錯誤被系統性地放行了。決策系統說服了自己「這次應該也沒事」。火箭工程早就給過答案：TMR 三模冗餘阿波羅任務與土星五號時代的導航電腦，採用了一個當時極為硬派的工程解法——TMR（Triple Modular Redundancy，三模冗餘）：機制說明三套獨立系統同時計算同一個問題，彼此不知道對方的答案硬體投票裁決少數服從多數，異常值直接被隔離無 rollback 設計太空中沒有重試機會，容錯必須在決策當下完成這個設計的核心哲學不是「讓系統更聰明」，而是：假設任何單一系統都可能出錯，所以在架構上就不允許它單獨做最終裁決。現在的 AI，重新打開了同一個問題單一大型語言模型的問題不在於能力不足，而在於它有幾個結構性弱點： ▸ 幻覺（Hallucination）——以高度自信的語氣輸出不存在的事實 ▸... » read more

Read

steven written 2 months ago