從一個念頭,到一套能力 : 一段工程演進,看見企業隱性智慧如何變成資產
從一個念頭,到一套能力 : 一段工程演進,看見企業隱性智慧如何變成資產

PCPiLOT 工程師思路系列 從一個念頭,到一套能力 一段工程演進,看見企業隱性智慧如何變成資產 7月6日,星期日傍晚六點。 我原本只是想解決一個採購效率問題。 沒有規劃十六個版本。沒有想過要做成什麼平台。甚至沒有想過,這件事最後會和企業 AI 轉型產生任何連結。 我只是覺得:「這件事如果能自動化,應該會更好。」 就這樣開始了。 十天後,我回頭看,發現自己走過的這條路,其實不只是寫了一個工具。 而是驗證了一件事: 一個人累積多年的判斷經驗,可以被整理、被保存、被傳承——變成任何人都能使用的能力。 第一天:先讓資料進來 程式第一版做的事情很簡單。 跑完,螢幕印出幾十個型號的價格和現貨數量,整齊排列。 就這樣。 但那個當下,看著原本需要手動搜尋幾十次的事情,變成幾秒鐘自動完成——有一種說不清楚的滿足感。 不是因為做了什麼了不起的東西。 而是因為:一個念頭,開始變成真實。 有用。繼續。 幾天後:資料進來了,但還不夠 數字有了,問題來了。 「這顆值不值得買?」 光看價格和筆數,還是不知道。 於是開始加東西:幾個核心、功耗多少瓦、效能評分、有沒有內建顯示晶片。 資料開始變成資訊。但我知道,資訊還不夠——真正需要的,是判斷。 關鍵轉折:把多年的經驗寫進去 這是整個過程中,讓我最有感觸的一步。 有一顆叫 E5-2678 v3 的處理器。規格表上就是幾個數字,看不出任何特別之處。 但我知道它的故事。 這是中國工廠特供的型號,台灣幾乎沒有新品,卻因為大量企業設備汰換而流入二手市場,用一般消費型主機板就能插,效能是同價位產品的好幾倍。這些資訊,不在任何規格表裡,不在任何評測網站上——它只存在於在這個市場裡打滾過的人的記憶中。 我把它寫進去,就七個字: 「中國特供雙路神U。」 看似簡單的七個字,背後是十多年市場經驗壓縮後留下的判斷。 R3 3300X 四核全在同一個運算模組,記憶體延遲極低,實際表現遠超規格,停產後身價反漲。 i5-11400 這一代意外保留了企業級指令集,卻在下一代被取消,是近年最特殊的消費級 CPU。 每一條,都是曾經讓我在某個場合停下來多想一秒的事情。現在,它們全部在工具裡了。 那個夜晚,我盯著螢幕看了很久。不是因為程式有多複雜,而是因為突然意識到: 我一直以為這些判斷只存在我腦子裡,沒想到它們可以被說清楚,被整理出來,被放進一個任何人都能使用的地方。 第一個真正的考驗:報告全部消失 某天早上,打開報告——空白一片。 所有分析、所有資料、所有花了好幾天整理的內容,全部不見了。 那一刻,有一種熟悉的感覺:這種事,做任何事情的過程中都會遇到。 追查之後,發現問題出在一個非常小的地方——一個格式衝突,導致整份報告無法運作。 修好之後,我做了一件比修復本身更重要的事: 把這次的問題、原因、解法,全部寫下來,變成一條守則。... » read more

原來整理 GPU,也是在做裝箱演算
原來整理 GPU,也是在做裝箱演算

原來整理 GPU,也是在做裝箱演算法 最近在研究本地 AI 推理環境時,遇到一個非常有趣的問題。 我的測試主機配置了三張 RTX 3060 12GB 顯示卡。其中兩張透過 PCIe x16 運作,另一張則作為亮機卡使用,只連接 PCIe x4。 乍看之下,總共有 36GB VRAM 可供運用。然而在實際部署大型語言模型時,事情遠比想像中複雜。 有些模型可以獨立運行於單張 GPU;有些模型則需要跨兩張 GPU 分攤權重;還有些模型雖然容量不大,卻需要與其他服務共同分享有限的記憶體空間。 這讓我開始思考一個問題: 如何讓有限的 GPU 資源,發揮最大的模型部署效益? Bin Packing:經典的裝箱問題 深入研究之後,我發現自己面對的其實是一個經典的電腦科學問題:Bin Packing(裝箱問題)。 所謂裝箱問題,可以用生活中的行李打包來理解。 每張 GPU 就像一個行李箱。 每個 AI 模型就是一件行李。 GPU VRAM 就是行李箱容量。 模型大小則是行李體積。 目標是在不超過容量限制的前提下,把所有行李放進有限的箱子裡,並盡可能提高空間利用率。 這看似簡單,實際上卻是著名的 NP-Hard 問題之一。 真實世界比數學題更複雜 如果只是比較模型大小與 VRAM 容量,問題其實不難。 然而在實際部署環境中,還會出現許多額外限制: 某些模型禁止部署於亮機卡。 某些模型必須跨兩張 GPU 運行。... » 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 不再是「大雄的安慰機器人」 今天是第二場次的中小企業知識系統推進簡報與交流。 這次主要分享近幾個月大型語言模型(LLM)在企業現場的應用演進, 以及「地端 AI + 雲端 AI 協作」逐漸成熟後,中小企業可以真正落地的實作模式。 很多企業主對 AI 的理解仍停留在:寫文案、摘要、做簡報。 但實際上,架構已經開始往「企業雙層思考系統」演進。 地端 AI × 雲端 AI 的分工開始成形 地端 AI 可以處理企業內部的第一層知識與資料: 內網資料整理與索引 私有文件檢索與分析 NAS / ERP / SOP 系統串接 第一線設備與網路資料監控 雲端 AI 則負責更高階的推理與整合: 策略規劃與決策輔助 跨領域資訊整合 高階文件生成與整理 抽象問題建模 兩者結合之後,其實已經形成一種「企業第二思考層」的雛型。 中小企業反而更有機會 有趣的是,這一波 AI 架構轉變,中小企業不一定落後,甚至可能更有優勢。 因為 SMB 的特性是: 決策距離短、現場經驗集中、問題回饋速度快。 真正的瓶頸往往不是資料不足,而是: 如何把「隱性經驗」轉換成「可累積的知識系統」。 AI 的真正角色,不是安慰,而是放大觀察力 AI 很擅長整理與生成內容,但真正的洞見仍然來自第一線的經驗。 企業主與主管往往已經知道:... » 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

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

「當企業開始部署地端 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

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

30 分鐘換來的 12 倍加速<br>本地 LLM 效能異常的根因拆解與 Debug SOP
30 分鐘換來的 12 倍加速
本地 LLM 效能異常的根因拆解與 Debug SOP

工程實戰 · Mr. τ · 2026 年 5 月 30 分鐘換來的 12 倍加速 本地 LLM 效能異常的根因拆解與 Debug SOP ▌ 這篇文章在講什麼 我花了整個上午,讓 AI 助理幫我 debug 一個本地 LLM 效能異常。六輪下來沒解決,最後靠一個三字參數位置錯誤找到根因。這是那次事件的完整記錄——以及我從中整理出來的 Debug SOP。 現象:200 字的文件,為什麼要跑 30 分鐘? 測試場景很單純:6 筆文件,每筆約 200–300 字,交給本地模型做結構化評分。正常情況下,這種規模的任務應該在幾分鐘內完成。 實際結果是:每筆 140–150 秒,6 筆合計接近 30 分鐘。 硬體監控數字正常,GPU 在線,模型已載入顯存。從表面看,系統沒有任何問題。 六輪 Debug,每輪都沒打到點 我請 AI 助理協助排查。接下來發生了一段很典型的「AI 時代 Debug 迴圈」: 1 加入串流顯示... » read more

不能永續經營的模式, 是走不遠的.
不能永續經營的模式, 是走不遠的.

PCPILOT 知識中心 ── 產業觀察 AI 產業的「撥接時代」即將結束? 從 GitHub Copilot 收緊限制、OpenAI 砍服務,看懂三條路並進的產業重組邏輯 Mr. τ|風雲網通系統 2026.05.01 產業觀察 / AI 商業模式 「不能永續經營的模式,是走不遠的。但產業總是會找到出路的。」這句話,在 2026 年的 AI 服務市場,正在被一件一件的具體事件所驗證。 訊號同時出現,背後只有一個原因 最近幾週,幾個看似各自獨立的動作,在業界接連發生: 🔧 GitHub Copilot:暫停 Pro / Pro+ / Student 新用戶註冊、收緊用量上限、將頂級 Claude Opus 模型從一般 Pro 方案移除。 🎬 OpenAI:收掉 Sora 影片生成服務,反手推出運算成本較低的 Image 生成。 🧪 Anthropic:測試性縮減約 2% Claude Pro 用戶的 Claude Code 使用權益。 ⚡... » read more

《Stacked Harness Engineering:從提示詞操作到多模型意圖調度系統》
《Stacked Harness Engineering:從提示詞操作到多模型意圖調度系統》

📘 方法論白皮書 《Stacked Harness Engineering:從提示詞操作到多模型意圖調度系統》 🧭 0. 核心問題定義 傳統 Prompt Engineering 的隱含假設是: 使用者知道自己要什麼,並且能精確描述 但現實是: 因此問題轉換為: ❌ 如何寫出正確 prompt✅ 如何設計「讓 AI 自動收斂意圖的系統」 🧩 1. 兩個核心概念 1.1 套疊與修正(Stacking & Refinement) 不是一次生成,而是: 多層輸出 → 比對 → 修正 → 再生成 可以抽象成: 📌 重點不是「生成一次」,而是: 讓錯誤在系統內被逐層消化 1.2 Harness Engineering(調度工程) Prompt Engineering 在做的是: 「寫輸入」 Harness Engineering 在做的是: 「設計 AI 行為路徑」 包含四個層次: (1)... » read more