舊機重灌後的六項必做清單 工程師思路系列 ／ Mr. τ ／ 風雲網通系統 📋 這不是教學文，是現場 recovery checklist。拿到機器就照順序跑。 舊電腦重裝系統，很多人第一個念頭是「效能夠不夠用」。但實際跑現場的工程師知道：能不能「正常連線使用」才是第一關。 無論機器多老、系統多精簡，只要目標是「連線作業」，以下六件事要依序確認並處理完畢，才算真正就緒。 ① 上網 → ② 手動校時 → ③ 瀏覽器 → ④ 線上 AI → ⑤ 地端 AI → ⑥ NTP 自動校時 這台機器值得救嗎？快速判斷 在動手之前，先確認手邊的機器是否符合基本門檻。以下三個條件缺一不可： 條件 最低門檻 建議規格 CPU 年份 2011 年後 2013 年後 CPU 世代 Intel Core i 第 2 代（Sandy Bridge） Intel Core... » read more
工程師思路系列・事出必有因 AI 助理看不到現場：Linux 客製化的核心困境與破解展望 Mr. τ・風雲網通系統・2026 你不是不夠努力。你只是一個人，扛了不該一個人扛的事。 一、那些年，我們獨自面對的黑畫面 深夜。機器前。一整頁白字在黑色終端機畫面上靜靜燃燒。 你不確定是驅動問題、套件相依性衝突、還是這個發行版的版本差異。你查到的解法，是別人的環境、別人的套件版本、別人的硬體——不是你眼前這台機器的現場。改了一個，壞了另一個。再查，再改，再壞。 這不是技術能力的問題。這是資訊孤島的問題。 二、AI 助理出現了，但它看不到現場 AI 助理的出現，讓很多人以為問題解決了。但在 Linux 現場客製化這個場景，一道新的牆出現了——不是 AI 不夠聰明，而是 AI 根本看不到你的現場。 1 現場資訊出不來 錯誤畫面往往不只一頁。工程師能做的，只有舉起手機，對著滿屏白字拍照。拍到的是圖片，不是可以複製的文字——AI 讀圖還可能漏字或誤判關鍵訊息。 2 AI 回應進不去 手機 AI 給出的往往是成串甚至成段的指令。工程師必須把這些文字「人工搬運」回標的電腦的 terminal——一個字抄錯，全盤皆輸，一切重來。 3 資安顧慮讓選擇更少 新安裝的系統，環境未知、安全性未確認。為了不留下個人帳號足跡，不敢在標的電腦上登入 AI 助理，反而被迫改用最低效的手機模式求助。 4 語言障礙讓表達品質下降 沒有中文輸入法，使用者被迫用蹩腳英文慢吞吞描述問題。表達不完整、脈絡殘缺，AI 收到的是失真的現場描述，給出的答案自然也偏差。母語輸入不是舒適度問題，是 AI 協作品質的基礎條件。 沒人說出口的附帶代價：手機相簿裡莫名多了一堆黑底白字的終端機畫面，夾在生活照之間。忘記刪除就佔用空間，同步雲端則連備份都跟著污染。當下解決了不會去看，沒解決放棄了更不會去看——幾乎注定永遠躺在那裡。 四重障礙合起來，形成一個惡性循環：錯誤發生 → 資訊出不來（拍照）→ 語言殘缺地描述問題 → AI 回應進不去（手抄）→ 抄錯又出錯 → 再拍照…… 這不是使用者的問題。是工具的設計，還沒跟上現場的需求。... » read more
工程師思路系列 事出必有因 現場實錄 一個 Ctrl+Space，卡了一整晚 antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂 我有一台 Acer Aspire 4745G，第一代 i5，4GB RAM，說老不老，說新不新。 它的任務是跟我跑現場——去客戶公司做網路勘查，掃設備、抓封包、出報告。 為了讓這台老筆電跑得動勘查工具，我裝了 antiX 26——一個極度輕量的 Linux 發行版。 裝完之後一切都好，只剩一件事：打不了中文。 「這有什麼難的？」——我當時這樣想 在 Windows 上裝中文輸入法是五分鐘的事。Linux 嘛，查一下文件，跑幾行指令，應該也差不多吧。 結果我低估了這件事。 先裝 fcitx5，按照網路教學一步一步來，裝完重開機——Ctrl+Space，沒反應。 換 fcitx4，一樣。換 ibus，還是一樣。 三套輸入法框架，全部裝了又刪，刪了又裝，環境變數在系統裡留下一堆殘骸互相打架。 讓 Google Search AI 幫我試了四種不同版本，全都失敗。 「是不是 antiX 根本就不支援中文輸入？」 「還是我哪個步驟做錯了？」 「還是這台機器有什麼特殊問題？」 這種時候最消耗心力——不是累，是不知道問題出在哪裡，所以不知道從哪裡修。 換個工具，換個思路 後來我換了方法：不再自己亂試，而是讓 Claude Fable 5 協助我做系統性的診斷。 做法很直接——先寫一支診斷腳本，把系統狀態全部挖出來： 目前裝了哪些輸入法套件、環境變數是什麼值、Display... » read more
PCPiLOT FIELD NOTES ✦ 工程現場實錄 Windows 11 更新，有時，不是越新越好 一台 Q470 主機板，三層電源管理的通關紀錄 2026-06 ✦ Mr. τ／風雲網通系統 這篇文章不需要你懂 BIOS 或 Windows 更新機制。 它講的是一件很多人用過幾年的電腦都可能碰到的事：Windows 11 更新越裝越新，機器卻開始出現各種說不清楚的怪現象。睡眠有問題、關機有問題、更新裝不進去——每一個問題看起來都不一樣，但追到最後，指向的是同一個方向。 這是一次真實的維修通關紀錄，也是我交機時跟客戶說的那段話。 起點：以為只是換一顆 SSD 鄰居送來一台 ASUS 商用機（Q470 晶片組），SSD 故障。好消息是還在保固內；壞消息是原廠更換要等兩週。最近 SSD 漲價四到六倍，客戶很冷靜：「等就等。」 於是我用工程部備用的 SATA SSD，做了一次乾淨的 Windows 11 24H2 安裝，讓機器先恢復正常使用。等原廠 SSD 修返，再用系統複製工具把整個環境搬過去。補完主機板驅動，讓 Windows Update 慢慢跑。一切看起來只是例行維修——直到更新開始跑。 ⚠️ 關卡一：DISM 都過了，更新還是卡在 98% KB5095093（選用預覽更新）安裝 → 重新開機 → 更新到 98%... » read more
PCPiLOT FIELD NOTES ✦ 數位工具開發實錄 我們不是花八小時修 bug，是花八小時才發現沒有 bug 一次 App 開發的真實除錯紀錄，以及它告訴我們關於 AI 協作、資訊可視化與決策品質的事 2026-06-25 ✦ Mr. τ／風雲網通系統 這篇文章不需要你懂程式。 它講的是一個管理者和決策者都熟悉的問題：當你的團隊花了很長時間解決一個問題，最後發現問題根本不在他們找的地方——那段時間，是怎麼浪費掉的？ 我最近第一次開發 Android 手機 App，親身經歷了這件事。過程很痛苦，但教訓很值得分享。 起點：一個真實的市場需求 台灣有超過五百萬慢性病患，他們每天面對一個沒有人幫他們解決的問題： 「站在超商貨架前，拿起一包零食，我能吃嗎？吃多少？今天已經吃太多了嗎？」 我開發的「好口福」App，就是要回答這個問題。使用者輸入身高體重和慢性病狀況，App 掃描食品標示後，給出一個簡單的顏色燈號： 🟢 安心買 🟡 注意量 🔴 地雷區 ⚫ 今日已爆 問題：一個小圖示消失了 App 的主要功能都做好了。最後一個待辦很小：在每個營養素旁邊加一個「ⓘ」圖示，讓使用者點擊後看到健康說明。 程式碼寫好了。系統檢查通過。部署完成。 但手機上，那個圖示完全不見了。 接下來的八小時 我和 AI 協作工具花了將近八小時排查這個問題。每一個假設都被否定： 假設一 程式碼沒有寫對 逐行核查後確認程式碼正確。❌ 不是這個。 假設二 手機作業系統的顯示 bug 查到真實存在的 bug 並修正，還是看不到。❌... » read more
從一次客戶故障，到一套診斷工具的誕生 工程師思路系列：好心辦壞事 —— 一台印表機故障，如何長出一套診斷工具 有些問題，看起來像設備故障。 有些問題，看起來像驅動程式損壞。 但真正深入追查後才發現， 問題其實來自一個原本出於善意的設計。 這次的個案，就是如此。 問題出現 家中有一台 HP Smart Tank 510 無線印表機。 多台 Windows 11 電腦長期正常使用。 但其中一台電腦，某天開始突然無法列印。 更奇怪的是： 測試頁正常 印表機狀態頁正常 Ping 正常 印表機顯示 Online 唯獨 PDF 與 Word 文件送出後， 印表機只動一下就停住。 彷彿設備正常， 卻又無法真正工作。 第一輪排查 遇到這種問題時，最重要的不是急著修復， 而是先排除錯誤假設。 於是開始逐項驗證： 重新安裝 HP 官方完整驅動 確認 Wi-Fi 連線正常 確認其他電腦可正常列印 確認印表機韌體正常 確認網路可正常 Ping 通 結果全部通過。 問題依然存在。 此時可以確定： 印表機本身並沒有壞。... » read more
41 個專案之後，我才搞懂什麼叫做「知識資產」 AI 讓開發速度提升十倍之後，最大的敵人不再是寫程式，而是遺忘。 作者：Mr. τ／風雲網通系統 | 標籤：知識工程 PCPiLOT SMB AI 「你有沒有一個機制，讓 AI 幫你掃描、萃取、歸檔過去寫過的好東西？」 我問過很多工程師。沒有人說有。 事件：29 次掃描，0 次成功 AI 助理出現之後，有一件事悄悄發生了。 開發速度變快了。快很多。以前一年做三個專案，後來一個月可以做三個。SPA、Python 串接、API 模組、診斷小工具……專案數量在我幾乎沒有意識到的情況下，突破了四十個。 然後，遺忘開始追上來。 「哪個專案有 OAuth 模組？」「上次那個 Ollama 串接，是在哪裡寫的？」「GPU 監控的邏輯，我記得優化過，但是在哪一個專案？」——這些問題開始頻繁出現。最大的敵人，不再是開發速度，而是自己累積的東西太多、太快、太散。 我試過用程式自動比對這 41 個專案的相似度，希望找出可以重用的部分。跑了 29 次，設計了各種比對邏輯，結果全部失敗。不是技術問題，是方向錯了——我一直在找「哪裡一樣」，而不是在想「什麼值得留下來」。 發現：掃描工具的方向，一直對齊錯誤的問題 工程師寫工具，有一個慣性：從「發現問題」出發。程式碼有沒有重複？有沒有 bug？有沒有技術債？ 但知識萃取需要的不是這個。開一個新案子的第一個問題，從來不是「我之前有沒有寫過類似的 bug」——而是「我之前有沒有解決過類似的需求」。 這是 PCPiLOT 工程日誌裡記下的一條教訓： 掃描工具應該對齊「開案時的需求」，而不是對齊「發現問題」。這兩個方向，工具架構完全不同。 說穿了就是：你需要的不是程式碼比對器，你需要的是架構解剖台。 抽象：三個步驟，把 41 個專案變成一座知識素材庫 我重新設計了 PCPiLOT 的專案解剖流程，分三個階段： 1 專案群組化 自動掃描目錄，排除實驗性的零散檔案，以「專案」為單位識別核心模組。不是每一個 .py... » read more
個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計 從工程流程、技術債，到多 AI 協作下的信任與交接管理 一、專案的真實推進歷程 一個專案的起點，通常只是一個模糊的初步想法。沒有完整規格書，沒有詳細設計，就這樣開始了。 從那個模糊的起點，工程推進的節奏大致是這樣走的： 1 先產出基本功能模組，讓系統能動起來就好 2 在使用過程中，整體框架慢慢成形，初期的功能設計與使用者介面跟著調整 3 逐項補完自認為不足的功能，同時持續除錯 4 調整操作動線，修正功能畫面，讓使用流程更順 5 引進多家 AI 助理提供評析意見，開始收斂專案結構 6 陸續償還開發期間累積的技術債 整個過程需要大量的持續觀察、監工、推進，以及心力投入。這不是寫完就結束的工作，是一直在跑的系統——你不看，它就會悄悄跑偏。 中間會遇到很多分岔點，特別是大型程式碼變動或重構的時候，這種時刻很容易因為趕進度而跳過一個關鍵動作： 遇到有疑問的分岔點，別忘記趕緊進行 git 版本保存。 很多決策是不可逆的，事後才後悔已經來不及了。 關鍵抉擇之前，也需要凝聚多家 AI 助理的經驗與意見，交互詰問，讓不同視角的問題都浮出來。這個動作看起來慢，實際上可以避開很多後期才爆炸的問題。 能做到這樣，才能真正啟動 40 倍槓桿的效益——讓沒有專業程式設計背景的人，也能完成多項功能的模組化程式串接任務。這不是誇張，是我們實際跑過的個案數字。 二、文件才是資產，不是記憶 開發過程中，有一件事非常重要，但很多人（包括 AI 助理）都會忽略： 最重要的資產是文件，不是個人的記憶，也不是 AI 助理的記憶。 程式碼是一翻兩瞪眼的事情。你說「我記得某個功能是這樣設計的」，那沒有用。把那個功能模組調出來，看哪一行寫了什麼，那才是真正的內容。 這個原則同樣適用於 AI 助理。AI 助理很容易煞有其事地亂掰一通，聽起來很有道理，但查了原始碼才發現根本不是那回事。它們也容易偷懶，把輸出內容簡化，把細節省略掉，讓你以為問題已經處理好了。 人類架構師覺得有疑問，就是要進行確認，不要跟著 AI 助理以為可以安逸。 不要放任 AI 助理胡亂地承諾與答應，然後你就真的信了。 這種工作態度的底線很簡單：有疑問就查，查了才算數。 三、多... » read more
工程師思路系列｜PCPiLOT 開發日誌 事出必有因 AI Agent 的執行成本，誰來負責？ Mr. τ／風雲網通系統 與 AI 協作，本質上是一種資源管理問題。 最近使用 Claude Code 的時候，忽然發現五小時的使用額度直接前進了 18%。回頭看工作紀錄，完全找不到對應的大型功能產出。 我把 console log 貼給 Claude 分析。 真正發生的事情 分析結果出來：Claude Code 因為找不到目標檔案，直接啟動了全硬碟搜尋。 它執行了 recursive directory scan、數次 PowerShell 呼叫、嘗試多組路徑，最後甚至準備啟動 llama-server 做測試驗證。 問題是，這件事只需要問我一句「檔案在哪裡？」就能解決。十秒鐘。但它沒問。 然後同樣的事情又發生了一次。額度直接燒到 37%。 Claude Code 事後的自我分析是： 使用者的輸入被解讀成「繼續調查」，而不是「停止確認」。 事實上，真正的問題早就結案了：rope.dimension_sections = 3 vs 4。後面所有的行動，全部是多餘的成本。 AI 與人類的成本模型不同 這個問題的核心，不是 AI 太積極，而是： 👉 AI 不知道「執行成本」是什麼。 對... » read more
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 的隱藏成本 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
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