好心辦壞事？談 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

0
Read
steven
從 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

0
Read
steven
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

0
Read
steven
資深 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

0
Read
steven
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

0
Read
steven
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

0
Read
steven
AI 開發體驗像坐雲霄飛車：當法力無邊的不是你，而是雲端 LLM
AI 開發體驗像坐雲霄飛車：當法力無邊的不是你，而是雲端 LLM

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

0
Read
steven
為何公司同仁突然拿不到 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

0
Read
steven
在 AI 會寫程式之前，你需要先會的那件事
在 AI 會寫程式之前，你需要先會的那件事

PCPiLOT 觀點 在 AI 會寫程式之前，你需要先會的那件事 Mr. τ｜風雲網通系統 · 2026 很多人看到 Vibe Coding、AI 協作開發的浪潮，直覺反應是： 「趕快找工程師學 AI 工具，就能跟上了吧？」 這個想法只對了一半。工具是可以學的。但工具放大的，是你原本就有的東西——如果原本就沒有，放大之後只是更快地製造混亂。 我想用自己的經歷說清楚這件事。 三年級的閱讀訓練，是一切的起點 小學三年級，我的樂趣是翻家裡那些數百頁、密密麻麻小字的章回小說。很多內容當時看不懂，但就像現代人追劇一樣，情節緊湊、有延續性，自然捨不得放下。囫圇吞棗、前後對照，久了也就略知其意。 這段經歷練出了兩件事：快速閱讀的速率，以及對長文資訊的耐受度。 這兩件事，在三十年後的 AI 協作開發裡，每天都用得到。 寫作是腦內的文字串流處理 從國小作文比賽，到後來網路時代的討論區、部落格、臉書，持續寫作這件事，本質上是一種持續的腦內訓練：怎麼把模糊的想法整理成可以傳遞的結構、怎麼適當描繪、怎麼來回修改。 這種能力，在與 AI 協作時變成了最關鍵的東西——不是打字速度，而是你能不能把自己的需求說清楚，讓 AI 往正確的方向走。說不清楚的人，AI 給的答案只會讓他更困惑。 這個能力，不是三天學會的。 現場跑出來的軟體品味 長年 FAE / CSO / Technical Support 的經歷，讓我看過太多現場狀況——使用問題、產品瑕疵、老化、人為疏失、原廠設計缺陷……跑多了，對「好產品」的直覺與感應就自然生成。 這種直覺延伸到軟體開發，就是 Vibe Coding 裡很在意的那個東西：軟體品味。它決定你在 AI 生成一段程式碼的時候，能不能感覺到「這裡有問題」——即使你說不出精確的技術原因。 沒有這個，AI 產出的東西你照單全收，遲早出事。 AI 出現之後，這些積累才真正有了出口 說實話，過去我有想法、有實務積累，卻苦於程式掌控與熟練度不足，很多專案構思推遲了十年以上，始終停在空想階段。 直到 2025～2026 年，AI 助理協作開發的現象出現。短短兩個月內，我把數十年累積的閱讀力、組織力與產品直覺一次灌注進去，開發出超過... » read more

0
Read
steven
AI 助理一本正經瞎猜，然後被官方文件打臉——<br>一次 OpenCode v1.14.40 + Ollama 的 Windows 排錯完整故事
AI 助理一本正經瞎猜，然後被官方文件打臉——
一次 OpenCode v1.14.40 + Ollama 的 Windows 排錯完整故事

這篇文章有三個主角：一個固執的排錯工程師、一個聽起來很有把握的 AI、以及一份他們都沒去讀的官方文件。 結局是：工程師手動挖對了一半，AI 說中了一半又說錯了一半，官方文件早就把答案寫好了——只是沒人第一步就去查。 一、故事的起點：Qwen 在哪裡？ 環境是 Windows 11，Ollama 本地跑著 qwen3.5:9b-q8_0，OpenCode v1.14.40 剛裝好。按理說一切應該順暢——但 OpenCode 每次啟動，都自作主張地選回了一個叫做 minimax-m2.7:cloud 的雲端模型。 ⚠️ 問題明確：你設定好的本地模型，隔一次重啟就消失了。minimax 幽靈般地回來，像是設定根本沒被寫進去。 排錯的直覺是：設定檔的問題。但 哪個 設定檔？ XDG 規範遷移的陷阱 OpenCode 在某個版本之後，悄悄從 Windows 慣例路徑遷移到了符合 XDG 規範的新路徑。舊版使用者習慣去改的地方，新版根本不理。 # 舊版慣例（不再生效） %APPDATA%\opencode\opencode.json # 新版 XDG 規範路徑（這才是有效的） %USERPROFILE%\.config\opencode\opencode.json 在這個路徑下，把 model 欄位手動修正為 ollama/qwen3.5:9b-q8_0，重啟，終於有效。Qwen 3.5 開始正常接管工作，而且 tool calling 能力也確認正常——它主動調用 read 工具讀取了本地的 CONSTITUTION.md，完全符合 agentic 工作流的期待。 ✔️ 第一階段結論：路徑找對了，模型確認上線，憲法執行能力驗證通過。... » read more

0
Read
steven
委外系統越建越多，你知道誰在幫你管嗎？
委外系統越建越多，你知道誰在幫你管嗎？

委外系統越建越多，你知道誰在幫你管嗎？ 很多企業主有一個直覺：資產當然是越多越好。這句話只在一個前提下成立——那些資產不需要你花心力去維護。不動產要顧結構與設施，機械設備會老化折舊。資產一多，人的時間與注意力就跟不上，問題只是「什麼時候爆出來」而已。 軟體系統，其實也是同樣的道理。只是它的折舊方式，不那麼直觀。 💻 軟體不會壞，但會失控 軟體資產有個特性：備份做好，它就不會消失。所以很多企業主以為，「系統建好就算了」。但現實是，軟體不會只是放著不動。只要有需求，就會有修改；只要有修改，就會有版本；只要版本開始累積—— 原本設計來共用的模組，可能成為最難處理的依賴來源。這個系統要升版，那個系統得跟著測。改了這裡，那裡不知道什麼時候默默壞掉。 這不只是工程師的日常煩惱，這是企業的隱性成本。 ⚠️ 沒有專職開發團隊的企業，請特別注意 委外開發、零散購買、各部門各自為政——這是台灣中小企業最常見的 IT 現況。初期看起來沒問題，因為每套系統都在運作。但隨著時間過去： ✔ 同樣的問題，在不同系統裡各自要花錢修一次 ✔ 沒有人真正掌握全貌，每次出事都像在拆炸彈 ✔ 想整合，才發現各系統的邏輯根本對不起來 軟體開發的工作量與深度，遠比外表看起來複雜。這不是在嚇人，而是業主在委外之前，應該理解的基本現實。 🤖 用了 AI 之後，很多業主開始有個念頭 「AI 這麼強，我找個員工來，應該也能自己開發吧？」 這個念頭不完全錯。小型工具、內部雛型、流程自動化的草稿——在 AI 助理的幫助下，一個有基礎概念的員工，確實可能在短時間內做出「看起來能用」的東西。 問題在於，「看起來能用」跟「真的能用」之間，有一道業主通常看不見的牆。 雛型階段 vs 營運階段 雛型階段 進入營運後 邏輯簡單 例外情況不斷增加 資料量小 資料累積，效能開始出問題 使用者一兩人 多人使用，衝突與權限問題浮現 出錯重來就好 資料與流程已難以回頭 軟體開發有一條隱形的複雜度曲線：前期平坦，後期陡峭。沒有足夠經驗的人，很難在雛型階段就預見營運規模的需求。等到問題爆發，往往已經騎虎難下——改吧，牽一髮動全身；重寫吧，之前累積的資料與流程怎麼辦？ AI 降低了「開始」的門檻，但沒有降低「做好」的難度。 🛠️ 在失控之前，先建立清單與架構 我們最近正在做一件事：掃描所有在用的工具與模組，統計造冊，分析用途，找出重疊與矛盾的部分，整理成真正可以共用、可以維護的結構。這就是重構的前置工程。 重構的本質不是寫新東西，而是把過度複雜、開始失控的結構，重新整理回「可理解、可維護」的狀態。即使現在有 AI 協助編輯程式碼，管理者還是得緊盯每一次修改後的結果——系統行為有沒有偏移、整體有沒有維持穩態。AI 提升的是效率，判斷與責任，還是在人這一側。 🔄 軟體資產要增值，需要一套有紀律的循環... » read more

0
Read
steven
企業數位心臟的延壽與汰換：中小企業 IT 設備管理與「避坑」全指南
企業數位心臟的延壽與汰換：中小企業 IT 設備管理與「避坑」全指南

IT 系統整合顧問 · Steven Lai · 2026 年 4 月 企業數位心臟的延壽與汰換 中小企業 IT 設備管理與「避坑」全指南 ▌ 前言 在多數中小企業中，IT 設備長期被視為「能用就好」的工具。電腦可以開機、網路可以上、印表機可以印，表面上一切正常。但身為技術顧問，我必須直言：這種「看似正常」，往往是風險正在高度累積的過程。 當電腦開始變慢、檔案開啟延遲、網路偶爾斷線，那不只是單點故障，而是整體系統失控的訊號。 真正的風險不在設備「壞掉」，而在於——你不知道它什麼時候會徹底崩潰。 第一章：性價比的陷阱——你買的是設備，還是風險？ 1.1 家用設備「誤入」商用環境的代價 很多企業採購時只看一個指標：價格。於是家用電腦、便宜無線分享器、無網管交換器被直接搬進辦公室。 這不是品牌差異，而是設計哲學的不同： 家用設備 設計給「每天 4–8 小時」使用，著重外觀與初期購入成本。 商用設備 為了「24/7 穩定運作」而生，著重散熱設計、電容耐用度與資料安全性。 💡 顧問提醒 用家用機跑企業 ERP 與高負載工作，本質就是「過勞使用」，其電容乾涸與電源不穩的速度是商用機的數倍。 1.2 真正的成本：總持有成本（TCO）對比 項目 路徑 A 家用／低階 路徑 B 商用／專業 購入價格 $20,000 $30,000 保固期限 1 年（送修制） 5 年（到府服務） 維修成本（3... » read more

0
Read
steven