三個不同案例,相同的處理態度與思路
三個不同案例,相同的處理態度與思路

三個不同案例,相同的處理態度與思路 —— 事出必有因系列:不放棄,往問題核心一層層剝去 今天處理了三個 SMB 客戶的現場案件。 網站與信箱突然全部中斷、NAS 權限設定怎麼改都沒用、診所印表機突然不能列印。 三件事看起來毫無關聯,但處理完之後,我發現它們其實在說同一件事: 每一個「突然壞掉」,都只是入口。真正的工作,是從入口走進去,一層一層,直到找到那個改變的點。 案例一|公司網站與信箱同時消失 客戶早上傳訊息過來:「官網打不開,寄出去的信全部退回。」 第一反應不是叫他去問主機商。 因為網站無法存取,不一定是主機壞了。第一順位的懷疑,是 DNS。 查了 WHOIS,果然——域名出現了 clientHold 狀態。 這個狀態代表:域名在註冊商端被暫時凍結,整個 DNS 解析鏈中斷,網站、信箱、所有對外服務,全部同時消失。 問題是,這個案件牽涉四個環節: 環節 負責方 域名註冊 國外供應商 Tucows,台灣由遠振代理 網站架設 另一家廠商維護 郵件服務 Google 代管 現場 IT 客戶自行處理 四個環節,沒有一個有完整的第一手資訊。能做的,是透過即時聊天持續與客戶確認現象,同時用 DNS 查詢工具監測狀態,逐層排查。 大約三、四個小時後,clientHold 自動解除,服務恢復正常。 原因?到現在還沒有明確答案。 這就是某些案件的現實——你找到了問題在哪裡,但「為什麼發生」這個問題,有時候沒辦法有完美的結論。 📌 企業主應該知道的事 域名是你公司數位資產的地基。地基出問題,上面所有東西同時消失——網站、信箱、一切對外的數位服務。 它不在你的主機上,不在你的 IT 人員手裡,它在域名註冊商那裡。 幾個值得確認的問題:你的域名在哪家註冊商?續費通知寄到哪個信箱?負責人離職後,這些資訊還在公司手裡嗎? 案例二|NAS 權限設定怎麼改都不生效 建築師事務所,Synology NAS。 管理員反映說有兩個資料夾的存取權限怎麼設都沒用——帳號正常,操作步驟也對,就是不生效。... » read more

AI 沒有猜錯,但我還是不知道自己在看哪一張 RTX 3060
AI 沒有猜錯,但我還是不知道自己在看哪一張 RTX 3060

AI 沒有猜錯,但我還是不知道自己在看哪一張 RTX 3060 從 GPU Name、Index、Bus ID 到 VBIOS Version,一場關於「可信觀測點」的除錯旅程 最近在研究 Ollama 與 llama.cpp 的 GPU 排程行為。一開始只是想搞清楚幾個小問題:為什麼 Windows 工作管理員看到的數字,跟 nvidia-smi 看到的不太一樣?為什麼有些模型看起來應該跑在某張卡上,行為卻又不像? 查著查著,我突然發現一個更根本的問題: 我根本不知道自己正在看哪一張 RTX 3060。 我的機殼裡插著三張長得一模一樣的 RTX 3060:同晶片、同 12GB 容量、外觀幾乎沒有差別。當兵時學過「四清、兩點、五查、三找」,裝備識別一個都不能少。沒想到二十年後在自己家裡,我被三張顯示卡逼著把這套紀律重新拿出來用——而且用得比當兵時還狼狽。 GPU 識別其實不是問題本身。它是為了驗證推論系統行為,不得不先解決的前置問題。觀測點如果不可信,後面所有的推論都會跟著錯。以下是這趟除錯的完整過程,包含 AI 助理陪我一起猜錯的每一層。 四層誤判 1第一層誤判:GPU Name 三張卡通通顯示 NVIDIA GeForce RTX 3060。完全沒用,毫無區別。 2第二層誤判:nvidia-smi 的 Index(GPU 0 / 1 / 2) 很多人第一反應是看 Index。但這台機器一路從 GTX 750... » read more

從一次 OOM 事件,看見企業地端 AI 的隱藏成本
從一次 OOM 事件,看見企業地端 AI 的隱藏成本

從一次 OOM 事件,看見企業地端 AI 的隱藏成本 Steven Lai(Mr. τ)|風雲網通系統有限公司 PCPiLOT  ·  2026-06-06 最近在開發 PCPiLOT 專案時,我遇到了一個很有意思的現象。 測試環境裡有兩張 RTX 3060 12GB。 照理說,許多人會認為:兩張顯示卡,應該比一張顯示卡更穩、更快、更有餘裕。 然而實際情況卻不是如此。 現場觀察 在模型推理與功能驗證過程中,我發現其中一張顯示卡長時間維持高負載,另一張顯示卡卻幾乎處於待命狀態。隨著上下文(Context)逐漸增加,系統開始出現記憶體不足(OOM)與推理中斷的現象。 短短不到十分鐘,就發生了多次模型重新載入與執行環境重建。結果最花時間的,並不是 AI 在思考問題,而是在等待系統恢復工作狀態。 企業導入 AI,真正的成本不一定是硬體 很多人談 AI 時,第一個想到的是: ✔ 顯示卡夠不夠大? ✔ VRAM 有沒有 24GB? ✔ 要不要再多買一張 GPU? 這些當然重要。但當系統真正進入長時間運行階段後,往往會發現另一個問題: 真正影響效率的,未必是算力本身,而是資源如何被使用。 如果兩張顯示卡的資源無法有效協同運作,即使帳面上擁有更多的 VRAM,也未必能獲得理想中的穩定性。 AI Runtime 的設計取向,決定了資源如何被消耗 目前許多地端 AI 推理框架,都傾向於優先追求低延遲(Low Latency)。這種設計有其合理性——對聊天機器人而言,使用者通常希望輸入問題後,幾秒鐘內就能得到回應。 為了達成這個目標,系統往往會盡量減少顯示卡之間的資料交換。結果就是: ✅ 好處 回應速度較快,使用者體驗流暢,適合短對話場景。 ⚠️... » read more

AI 時代最容易被遺忘的能力:保留替代路徑
AI 時代最容易被遺忘的能力:保留替代路徑

AI 時代最容易被遺忘的能力:保留替代路徑|PCPiLOT PCPiLOT 技術觀點 AI 時代最容易被遺忘的能力:保留替代路徑 Mr. τ/風雲網通系統 · 2026 昨天找鍵盤滑鼠的 USB 接收器,找了半天,沒找到。工作用電腦沒有輸入裝置可操作,第一個反應很直接:上網下單。火箭速配,Logitech MK275 一組,昨夜按下去,今天到貨。這大概也是現代人最自然的解法——缺什麼,就買什麼。 等貨的空檔,腦子突然轉了一圈。 我家地下室不是有一堆有線鍵盤滑鼠嗎? 於是下樓翻找。一落整理好的 PS/2 鍵盤,挑了一把看得順眼的;牆上掛鉤還有幾支 USB 有線滑鼠,拿下一支,插上去,電腦重新上線。MK275 還在物流車上,問題已經解決了。 看起來只是件小事。但事後回頭想,真正有意思的地方不在於我找到了鍵盤,而是:我第一時間想到的是購買,而不是盤點現有資源。效率,正在悄悄改變我們解決問題的方式。 公理號的隱喻 《瓦力》(WALL-E)中的公理號(Axiom)是個有趣的隱喻。船上一切都被最佳化了:移動由懸浮椅代勞,資訊由螢幕主動推送,生活由自動化系統全面照顧。人類不需要規劃,不需要修理,不需要尋找替代方案,更不需要處理意外狀況。 這艘船最可怕的地方,其實不是機器人管理人類,而是整個系統已經把「解決問題的能力」從人類身上逐漸抽離。當一切正常運作時,這種設計看起來非常成功。但當系統失效時,人類已經失去了接手的能力。 皮克斯在 2008 年就把這個場景拍出來了。不是預言,是觀察。 企業現場也在發生同樣的事 這讓我想到許多企業資訊系統的現況: 交換器故障了 買新的 NAS 空間不足了 買新的 伺服器效能不夠了 升級硬體 AI 額度不夠了 升級方案 這些決策未必錯誤。但很多時候,問題並非資源不足,而是對既有資源缺乏理解。 許多企業追求極致效率時,最先被犧牲的往往就是那些看似多餘的東西:備品庫存、備援設備、技術文件、知識庫、交接紀錄、替代流程。它們平常不產生營收,看起來佔空間,甚至讓人覺得浪費成本。於是被逐步裁撤。直到某位資深員工離職、某台核心設備故障、某個雲端服務中斷,大家才發現,系統其實沒有第二條路。 那落 PS/2 鍵盤的系統工程意義 回到那批 PS/2 鍵盤。它們平常幾乎沒有存在感,甚至十年都未必會被拿出來一次。但昨天,它們扮演了重要角色。 從系統工程的角度來看,它們其實就是一種 Cold Standby——平時閒置,必要時接手。 關鍵前提 我能翻出那落 PS/2 鍵盤,有一個前提——我當初沒有丟掉它。這不是節儉,也不是囤積癖,而是一個主動的決策:對未來不確定性的預判與準備。... » read more

好心辦壞事?談 AI 協作時代的 Silent Failure
好心辦壞事?談 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

從 AI 額度焦慮,到 SMB 的生存作業系統
從 AI 額度焦慮,到 SMB 的生存作業系統

從 AI 額度焦慮,到 SMB 的生存作業系統 SMB 不是短視,而是高頻即時作業系統 額度用完,會覺得「差一點就完成了」。 額度用不完,又覺得「好像浪費了」。 這不是 AI 的問題。這是我們面對有限資源時,本能的不安。 但如果你每天在 SMB 現場工作,你會發現——這種不安,其實是 SMB 老闆的日常作業系統。 一、SMB 不是短視,是即時運行系統 外界常說中小企業比較短視。 但用工程語言翻譯,事實是: SMB 是一種 Real-time Runtime System(即時運行系統) 它的參數是: ✔現金流週期短 ✔人力沒有冗餘 ✔每個決策直接影響生存 所以不是不能做長期規劃,而是:長期規劃必須先通過「今天能不能活下去」這一關。 有限資源在這裡不是限制,而是系統的排序機制——逼你收斂、逼你取捨、逼你用最小成本完成最關鍵的事。 二、邊跑邊補:SMB 真正的核心能力 在這個條件下,SMB 鍛鍊出的能力其實很獨特: 在資源極度受限下,持續讓系統不崩潰的即時重構能力。 它像一個邊運行、邊修補、邊演化的 live system。不是優雅最佳化,而是:不斷 patch,但不能 crash。 這是真實的生存能耐,不是缺陷。 三、代價:可以動,但結構是堆出來的 這種模式長期下來,會出現一個現象: 網路、設備、資料流、權限設計,逐步變成——疊床架屋、patch over patch、無文件、依賴人腦記憶。 平時沒問題。但一旦遇到以下任何一個時刻—— ✔業務突然成長,系統要擴張 ✔導入 AI 工具,需要整合資料流 ✔資安稽核,要求文件與權限梳理 ✔關鍵人員離職,知識隨人消失... » read more

2026 Local AI 的典範轉移: 從「硬體軍備競賽」走向「系統工程調校時代
2026 Local AI 的典範轉移: 從「硬體軍備競賽」走向「系統工程調校時代

從「硬體軍備競賽」走向「系統工程調校時代」 風雲網通系統 | 技術深度報告 2026 Local AI 的典範轉移 從「硬體軍備競賽」走向「系統工程調校時代」 LOCAL AI MoE ARCHITECTURE llama.cpp SMB AI 落地 許多中小企業(SMB)在評估地端 AI 落地時,最常聽到一個問題:「我們是不是非得採購動輒數十萬的高階 AI 伺服器,才能跑動夠聰明的大型語言模型?」 在傳統「暴力堆砌硬體(Hardware Brute Force)」的思維下,答案似乎是肯定的。然而,邁入 2026 年,Local AI 的技術底層已悄悄迎來一場革命性的典範轉移。 實測案例 / 觸發本文的關鍵數據 技術頻道 Codacus(YouTube)發布實測影片《Running a 35B AI Model on 6GB VRAM, FAST》,以一張 8 年前的 GTX 1060 6GB、搭配 i3 處理器與 24GB DDR4,成功流暢運行 350 億參數(Qwen 3.6 35B... » read more

資深 IT 工程師如何用 AI 對話,把二十年現場經驗轉化成可傳承的方法論
資深 IT 工程師如何用 AI 對話,把二十年現場經驗轉化成可傳承的方法論

知識中心 · 方法論 · 2026-05-20 · Mr. τ|風雲網通系統有限公司 起點很小很具體:只是想做一個 MTU 自動偵測工具,解決 DrayTek 搭配中華電信 PPPoE 時,LINE 電腦版卡在「正在搜尋最佳網路環境」的問題。結果這一聊,就像打開了一個開關。 對話是怎麼一層一層往上走的 和 AI 的對話沒有停在技術細節,而是像螺旋一樣,一層一層往上旋轉。 層級提升的對話過程 v0.8 腳本怎麼寫?PPPoE MTU 1492、MSS 1452、PMTUD Black Hole 成因——純工程師思維。 ↓ v1.0 這份報告要怎麼寫,才不會被客戶資安部門打回票? ↓ v1.1 這其實應該是一套結構化的現場診斷方法,而不是單一工具。 ↓ v1.2 這套方法如何變成 SI 廠商可重複交付、可培訓傳承的服務閉環? 真實案例:醫美診所的多年冤案 昨天在一家醫美診所,解決了一個讓多名工程師束手無策、拖了多年的問題。 實戰案例 · 醫美診所 症狀:網路連線極慢、換過多名工程師,問題始終沒有解決。 根因:數據機多個 LAN 埠各自建立獨立 NAT 網段,院長電腦與檔案來源主機被割裂在兩個不互通的孤島。加上檔案來源主機的無線網卡被裝潢遮蔽,訊號嚴重衰減。 解法:在三個重點位置用手機掃描 Wi-Fi 訊號,發現多個不同網段的 SSID。追出院長電腦的網路線,插回正確的... » read more

Windows 11 New Outlook 郵件黑盒事件:一個月後才看到真正的 Mail Flow
Windows 11 New Outlook 郵件黑盒事件:一個月後才看到真正的 Mail Flow

Windows 11 New Outlook 郵件黑盒事件:一個月後才看到真正的 Mail Flow 作者:Steven Lai | 日期:2026-05-14 📌 前言 這個案例,我追了快一個月。 整個過程幾乎沒有證據。 沒有退信 沒有 Sent Items 沒有 Outbox 沒有 SMTP log Windows Event Viewer 也沒有有效線索 直到今天,才因為一封偶發退信,讓整條郵件路由真正浮出水面。 Windows 11 New Outlook 的實際寄信路徑, 和我們以為的 SMTP 模型,根本不是同一件事。 🧩 事件背景 Windows 11 內建新版 Outlook(New Outlook) ISP 信箱(Seednet) 收件端:Gmail / Hotmail 📨 客戶沒收到信 但奇怪的是: Outlook 沒顯示寄送失敗 沒有退信... » read more

AI coding 最大成本不是 token,而是「熵」:從 Claude Code 到 Big Pickle 的地端 AI 生存工程學
AI coding 最大成本不是 token,而是「熵」:從 Claude Code 到 Big Pickle 的地端 AI 生存工程學

PCPiLOT 部落格文章 AI coding 最大成本不是 token,而是「熵」:從 Claude Code 到 Big Pickle 的地端 AI 生存工程學 作者:Mr. τ|PCPiLOT 日期:2026-05-12 一、AI coding 的真正問題,可能不是「模型能力」 這幾天,我幾乎完整經歷了一輪 AI coding 工具鏈的「生存演化」。 從最初令人驚艷的 Claude Code,到後來不得不因額度耗盡轉往 Cursor,再到 Antigravity 的高度 autonomous coding 體驗,以及後期的大翻車,最後進入 Gemini CLI、OpenCode 與 Big Pickle 的多 Agent 協作模式。 原本我以為: AI coding 最大問題會是: 但這幾天實際與大型專案長時間協作後,我開始認為: 真正的問題,其實是「熵(Entropy)」。 不是 token。 不是 benchmark。 而是: 長時間 AI 協作後,整個工程系統逐漸失控的現象。... » read more

AI 開發體驗像坐雲霄飛車:當法力無邊的不是你,而是雲端 LLM
AI 開發體驗像坐雲霄飛車:當法力無邊的不是你,而是雲端 LLM

AI 開發體驗像坐雲霄飛車:當法力無邊的不是你,而是雲端 LLM 「我是不是突然變強了?」 最近幾週的 AI 開發體驗,真的像在坐雲霄飛車。 之前因為 Cursor 的 free tier 管控非常嚴格,只要短時間內把 tokens 用光,就會進入很長的冷卻期。長到我幾乎已經徹底棄用它,甚至快忘記自己有安裝過這套工具。 剛好這週,平常主要使用的 AI 服務付費額度也用完了。 對於目前已經習慣 AI 協助開發的人來說,這種感覺有點像: 「平常開車都開高速公路,突然被迫回去騎腳踏車。」 於是只好重新打開 Cursor,外加 Antigravity,想說至少多少補一點開發進度。 結果重新使用 Cursor 後,我其實滿驚訝的。 順暢度、理解力、執行成功率,都比我之前印象中的狀態好很多。 甚至已經開始有種: 「這東西現在真的能工作了。」 的感覺。 這其實是一件很危險,也很容易讓人產生錯覺的事情。 因為當 AI 助理開始能穩定完成工作時,人很容易進入一種: 「自己是不是法力無邊了?」 的狀態。 功能一直完成。 Bug 很快被修掉。 開發速度暴增。 原本可能要花兩三天研究的東西,現在幾小時內就能推進。 那種感覺真的很像: 一個人突然變成小型研發團隊。 但後來我慢慢發現。 真正法力無邊的,其實不是你。 而是背後那群正在燃燒 GPU 與資本支出的雲端大型語言模型。 AI 的超能力,其實是用錢燒出來的 很多人第一次大量使用 AI 開發工具時,都會被那種「超能力感」震撼到。... » read more

為何公司同仁突然拿不到 IP?NAS 與印表機間歇性失聯?
為何公司同仁突然拿不到 IP?NAS 與印表機間歇性失聯?

RFC 9797 與企業 DHCP Pool 危機 為何公司同仁突然拿不到 IP?NAS 與印表機間歇性失聯? 近年來,企業 IT 現場開始頻繁出現一種「難以定位」的網路異常: 許多管理者第一時間會懷疑: 然而,真正的原因,可能與現代行動裝置導入的 MAC Randomization(隨機 MAC 位址)機制有關。 而此一趨勢,也與 RFC 9797 所代表的裝置隱私方向密切相關。 MAC Randomization 正在改變企業網路環境 現代作業系統為了降低裝置被追蹤的風險,開始大量採用: 目前常見於: 其核心目的在於: 避免使用者透過固定 MAC 位址,被長期識別與追蹤。 從隱私保護角度而言,這是正向發展。 但對企業 DHCP 管理而言,卻帶來新的挑戰。 同一台設備,可能重複取得多組 IP 在企業 Wi-Fi 環境中,行動裝置會頻繁出現: 若裝置使用 Randomized MAC, DHCP Server 可能會視其為: 「新的設備」。 因此: 同一台手機、筆電或平板, 短時間內可能重複取得 2~3 個 IP。 /24 網段其實很快就會耗盡... » read more