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

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

antiX 26 × fcitx5 × 新酷音:從懷疑人生到徹底搞懂
antiX 26 × fcitx5 × 新酷音:從懷疑人生到徹底搞懂

工程師思路系列 事出必有因 現場實錄 一個 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

一次 CDN 與防火牆互動造成誤判的排查案例
一次 CDN 與防火牆互動造成誤判的排查案例

CPU 很閒,卻幾乎連不上? 一次 CDN 與防火牆互動造成誤判的排查案例 / Mr. τ・風雲網通系統 工程師最怕的,不一定是 CPU 100%。 有時候,CPU 很閒、RAM 很閒、SSD 很閒,但外面就是幾乎連不上。 這種情況,通常代表真正的問題,根本不在主機裡面。 🗓 事情是這樣開始的 這次的案例,並不是監控報警發現的。 是因為我自己要去官網新增一篇部落格文章,打開編輯器之後,發現反應比平常異常地慢——才開始往下查。 這種情況其實很常見。很多問題不是被監控抓到的,而是「剛好要用」的時候才現形。 🔄 推翻假設的過程 第一直覺當然是先看主機硬體資源——CPU、RAM、磁碟,全部正常。 接著看外網流量,也沒有異狀。 切換到防火牆日誌,才看到大量 SYN Flood 告警。 第一反應:被攻擊了?來源 IP 一看——幾乎清一色是 Cloudflare 的全球節點。 原本以為是來自任意來源的攻擊,查詢後才發現,大多是來自 Cloudflare 全球各地的節點。 那問題真的是 Cloudflare 造成的嗎? 不是。 💡 根本原因 根本原因不是 Cloudflare 出問題,而是它改變了流量型態,而防火牆不知道。 Cloudflare 的代理機制,會把大量真實用戶的連線,集中由少數 Edge IP 節點轉送進來。如果防火牆的 SYN Flood 偵測門檻,沒有配合 CDN... » read more

一個 CMOS 斷電事件,如何引爆 BIOS 預設值、舊顯卡驅動、Linux 相容性的三重連鎖崩潰
一個 CMOS 斷電事件,如何引爆 BIOS 預設值、舊顯卡驅動、Linux 相容性的三重連鎖崩潰

工程師思路系列・事出必有因 那顆 16 年沒換的小電池, 讓一台筆電同時得了三種病 一個 CMOS 斷電事件,如何引爆 BIOS 預設值、舊顯卡驅動、Linux 相容性的三重連鎖崩潰 硬體診斷 Linux 老舊設備維護 BIOS 一台「前陣子還好好的」筆電,今天開機全壞了 前陣子才剛在一台 2010 年出廠的 Acer Aspire 4745G 上裝好 antiX Linux,視窗介面正常、自動登入正常,一切運作順暢。 今天把它拿出來,按下電源鍵,螢幕——沒有畫面。 接上外接螢幕之後,終於看到了一個文字終端機介面,靜靜地等著輸入帳號密碼。問題來了:帳密早就忘光了。 好不容易進入救援模式改了密碼,回到系統輸入 startx——失敗。 📋 本次故障症狀清單 ✔內建螢幕無畫面(外接螢幕正常) ✔開機停在文字模式 TTY,要求輸入帳號密碼 ✔原本的圖形介面自動登入功能消失 ✔手動執行 startx 失敗,無法進入視窗環境 四個症狀,看起來像四個問題。但工程師的直覺告訴我:一定有一個共同的根源。 第一直覺:「電池沒電,老電腦嘛,正常的」 這台 i5-460M 的機器距今快 16 年了,電池早就蓄不了電,是人之常情。 但仔細想一想:鋰電池耗盡,頂多就是筆電不能離開變壓器使用。它不會讓作業系統崩潰,不會讓螢幕沒畫面,更不會讓 X Window 開不起來。 所以,真正的問題不在那顆大電池。 真兇,是另一顆沒人記得的小電池。 主角登場:那顆 16 年從沒被換過的 CMOS... » read more

Windows 11 更新,有時,不是越新越好
Windows 11 更新,有時,不是越新越好

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

一台印表機故障,如何長出一套診斷工具
一台印表機故障,如何長出一套診斷工具

從一次客戶故障,到一套診斷工具的誕生 工程師思路系列:好心辦壞事 —— 一台印表機故障,如何長出一套診斷工具 有些問題,看起來像設備故障。 有些問題,看起來像驅動程式損壞。 但真正深入追查後才發現, 問題其實來自一個原本出於善意的設計。 這次的個案,就是如此。 問題出現 家中有一台 HP Smart Tank 510 無線印表機。 多台 Windows 11 電腦長期正常使用。 但其中一台電腦,某天開始突然無法列印。 更奇怪的是: 測試頁正常 印表機狀態頁正常 Ping 正常 印表機顯示 Online 唯獨 PDF 與 Word 文件送出後, 印表機只動一下就停住。 彷彿設備正常, 卻又無法真正工作。 第一輪排查 遇到這種問題時,最重要的不是急著修復, 而是先排除錯誤假設。 於是開始逐項驗證: 重新安裝 HP 官方完整驅動 確認 Wi-Fi 連線正常 確認其他電腦可正常列印 確認印表機韌體正常 確認網路可正常 Ping 通 結果全部通過。 問題依然存在。 此時可以確定: 印表機本身並沒有壞。... » read more

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

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

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

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

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

24GB 顯示記憶體,為什麼跑不動 16GB 的本地 AI 模型?
24GB 顯示記憶體,為什麼跑不動 16GB 的本地 AI 模型?

技術觀察 · AI Infrastructure 24GB 顯存,為什麼跑不動 16GB 的本地 AI 模型? Mr. τ/風雲網通系統 · 本地 LLM 部署實測觀察 很多玩家的第一反應:「我有兩張 3060,加起來 24GB,跑個 16GB 的模型理論上完全沒問題啊?」 實測結果卻是:載入沒事,一開始對話就隨機崩潰。這不是顯卡壞了。是 VRAM 的本質被誤解了。 💡 核心觀念:VRAM 是預算,不是倉庫 很多人把 VRAM 想成靜態的硬碟空間。但跑 LLM 推論時,它更像是一個「會呼吸的緩衝區」。16GB 的模型進了顯存之後,只是第一筆支出,後面還有更多看不見的隱形成本持續消耗。 一個更直觀的比喻:VRAM 是電梯的「額定載重」,而 16GB 的模型只是乘客的體重。電梯運行時的機械摩擦、剎車瞬間的衝擊力(推論峰值)——這些才是讓系統超載的真正原因。 📦 消失的顯存去哪了?三層隱形成本 1 靜態模型權重(固定 16GB) 這是你看得見的部分——模型進了 VRAM 就不動了。誤區正是從這裡開始,很多人以為「剩下 8GB 就是安全空間」,但實際上那 8GB 要承擔後面所有的動態壓力。 2 KV Cache 的「呼吸效應」(4~8GB,且隨時間膨脹) 這是最關鍵的時間變數。LLM 是有記憶的,每一輪對話都要把前面的內容儲存進... » read more