用 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

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

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

規格表贏了,然後呢?從 Intel ARC 驅動更新看半導體競爭的真實邏輯
規格表贏了,然後呢?從 Intel ARC 驅動更新看半導體競爭的真實邏輯

工程師思路系列・事出必有因 規格表贏了,然後呢? 從 Intel ARC 驅動更新看半導體競爭的真實邏輯 Mr. τ・風雲網通系統・2025 最近看到 Intel ARC 系列顯示卡發布了新版驅動程式,點進去看更新內容,發現絕大多數都是 bug fix——修這個、修那個,幾乎沒有新功能或性能提升。 這讓我停下來想了一下。 因為如果只看硬體規格,Intel ARC B580 其實不差。12GB GDDR6、192-bit 記憶體介面、繪圖記憶體頻寬 456 GB/s——放在同價位段,這個數字完全不輸競品,甚至超過不少對手。 規格表上,Intel 這次是認真做的。但驅動更新清單告訴你另一件事:規格表贏,不等於產品力贏。 一、NVIDIA 與 AMD 這十幾年鋪了什麼 要理解 Intel ARC 面對的困難,必須先搞清楚對手這十幾年到底累積了什麼。這些東西不會出現在規格表上,但全部都是真實的護城河。 第一層:幾千款遊戲的相容性資料庫。每一款遊戲都有自己的怪癖——特定的渲染 API 用法、記憶體存取模式、多執行緒行為。NVIDIA 和 AMD 的驅動裡,藏著多年來針對個別遊戲調校的 profile,有些甚至是為了修一個特定遊戲的特定場景而存在的 workaround。這個資料庫是時間換來的,沒有捷徑。 第二層:開發者生態的綁定。NVIDIA 的 CUDA 已經成為 AI 運算的事實標準,PhysX、DLSS 讓遊戲開發者主動針對 NVIDIA 優化。AMD 則有 FSR 和 ROCm 在追趕。這些工具不只是功能,而是讓開發者在設計產品時就預設你存在——這種綁定一旦形成,競爭者要切入的成本極高。... » 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

AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話
AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話

PCPILOT 知識中心 ── 產業觀察 AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話 從黃仁勳的水電工論,到外送與 Costco 的悖論,看懂自動化神話背後的人力本質 引言:沙漠中的金字塔 輝達執行長黃仁勳曾說過一句話,讓我反覆思考了好一陣子: AI 時代最搶手的,不是程式設計師,而是水電工;因隨著資料中心的快速增長,未來將需要數十萬名水電工和水管工。 第一次讀到這句話時,我腦中浮現的畫面,竟不是矽谷的伺服器機房,而是法老王金字塔的施工現場。 這個聯想其實一點也不荒謬。金字塔是古埃及人為永生信仰打造的終極硬體基礎設施,而今天的 AI 資料中心,則是現代人為「人工智慧」這個新神打造的終極硬體基礎設施。兩者的共同之處,在於人類把大量資源砸進一場「看不見的崇拜」——你看不到神,但看得到金字塔;你看不到 AI 的「智慧」本身,但看得到一座座吞噬電力與冷卻水的鋼鐵巨獸。 我們總以為 AI 時代是一個「去體力化、腦力至上」的時代,結果繞了一大圈才發現,真正稀缺的,反而是最古老的藍領技能。程式設計師寫完模型之後,要讓 AI 真正跑起來,靠的是電力、冷卻、管線、變電站、備援電源——這些最原始、最物理的東西。就像金字塔再怎麼神聖,最後還是得靠成千上萬人推石頭、拉繩子、抬木槓。只是石塊換成了伺服器機櫃,法老換成了黃仁勳,奴工換成了年薪可能比工程師還高的水電工。 核心對比:外送與 Costco 的悖論 這個「人力填補系統缺口」的觀察,讓我想起兩個生活中再尋常不過的例子。 案例一 外送經濟 年輕力壯的外送員,靠的是迅速響應的服務速率。這套系統把「時間」與「體力」拆解出來販售:付服務費,買的是別人的「執行速率」;選擇自取,則用自身體力與時間置換了溢價。 案例二 Costco 會員制 繳了會員費,再自己開車前往、自己揀貨、自己扛上車。零售業原本該承擔的物流成本,被悄悄轉嫁給消費者,而消費者卻心甘情願,甚至覺得划算。 外送悖論與 Costco 悖論,本質上是同一件事的兩種面貌:系統把效率包裝成自動化的神話,但底層始終靠人力填補設計留下的缺口。 範例 ── 外送服務 系統設計誘因:付費換取「時間壓縮」 人力參與形式:外送員成為即時物流節點 隱含的荒謬感:快速響應成為新階級象徵 範例 ── Costco 系統設計誘因:付費換取「低價與大份量」 人力參與形式:消費者自願成為運輸鏈一環 隱含的荒謬感:自己付錢、自己運貨、自己加油 範例 ── AI 工廠 系統設計誘因:投資換取「智慧與自動化」... » read more

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

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

AI 不再是「大雄的安慰機器人」 今天是第二場次的中小企業知識系統推進簡報與交流。 這次主要分享近幾個月大型語言模型(LLM)在企業現場的應用演進, 以及「地端 AI + 雲端 AI 協作」逐漸成熟後,中小企業可以真正落地的實作模式。 很多企業主對 AI 的理解仍停留在:寫文案、摘要、做簡報。 但實際上,架構已經開始往「企業雙層思考系統」演進。 地端 AI × 雲端 AI 的分工開始成形 地端 AI 可以處理企業內部的第一層知識與資料: 內網資料整理與索引 私有文件檢索與分析 NAS / ERP / SOP 系統串接 第一線設備與網路資料監控 雲端 AI 則負責更高階的推理與整合: 策略規劃與決策輔助 跨領域資訊整合 高階文件生成與整理 抽象問題建模 兩者結合之後,其實已經形成一種「企業第二思考層」的雛型。 中小企業反而更有機會 有趣的是,這一波 AI 架構轉變,中小企業不一定落後,甚至可能更有優勢。 因為 SMB 的特性是: 決策距離短、現場經驗集中、問題回饋速度快。 真正的瓶頸往往不是資料不足,而是: 如何把「隱性經驗」轉換成「可累積的知識系統」。 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

在 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

「當企業開始部署地端 AI,真正困難的其實不是模型」
「當企業開始部署地端 AI,真正困難的其實不是模型」

公司官網部落格版本(WordPress Gutenberg 適用) PCPiLOT 技術觀察 當地端 LLM 開始進入「工作負載工程」: 我們如何重新理解模型、Prompt 與商業效率 這不是一篇單純比較模型分數的 benchmark 報告,而是一場對「本地 AI 系統工程」的重新理解。 最近這段時間,我們在 PCPiLOT 內部進行了一輪相當完整的本地 LLM 壓力測試與工作負載分析。 測試對象包含多種模型架構、多個 Context Window、不同量化設定,以及六種企業常見知識工作場景。我們不只看模型回答「像不像」,而是開始量測: 知識密度 推理穩定性 字數控制能力 tok/s 與 wall time Context 使用效率 不同 workload 下的商業效益 而真正有趣的地方,是測試結果開始顛覆許多人對 LLM 的直覺。 一、大模型,不一定帶來更高商業價值 我們原本預期,27B 等級模型應該會明顯優於 9B 模型。但在實際測試中,結果並非如此。 某些 9B q8 模型,在多數企業知識工作場景下,輸出品質幾乎貼近 27B q4;但延遲更低、推論更快、VRAM 壓力更小。 這代表一件重要的事: 真正影響企業 AI 導入成本的,往往不是模型能力本身,而是整體推論系統效率。 在企業環境裡,真正的成本來自:... » read more