風雲網通系統 – Page 3 – 強化您的企業 IT 戰力

41 個專案之後，我才搞懂什麼叫做「知識資產」

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

Read

steven written 1 month ago

AI 時代工作法企業 AI 治理知識工程

AI 時代工作法企業 AI 治理知識工程你不需要懂 AI，但你需要當市長從三個真實事故，長出來的企業 AI 治理架構 Mr. τ／風雲網通系統有限公司 · 2026 有一次，我交代一個任務給 AI 助理。它沒有問我任何問題，直接開始工作。三十分鐘後，它回報完成了。但它做的，不是我要的那件事。它自己判斷了工作範圍，自己決定了方向，然後非常認真地，走錯了路。成本，照單全收。這不是特例。這件事在不同形式下，我遇到了很多次。每次我都在想同一個問題：如果 AI 不知道邊界在哪裡，它會自己畫一條。而那條線，不一定是你要的那條。這個問題，帶過人的主管都遇過。新進員工摸不清楚狀況，做了一堆不在範圍內的事；外包廠商沒有接到明確指令，就按照自己的習慣走。AI 也是一樣——只是它做事的速度快很多，所以走錯的代價也大很多。後來我把這些事故整理了一遍，發現它們都指向同一個根本原因：不是 AI 不夠聰明。而是沒有人在治理它。這也是我後來畫出這張圖的原因。［五層市政廳架構圖］人類治理 → AI 協作 → 文件系統 → 知識中心 → CSP 基礎設施這張圖把企業 AI 協作拆成五層。每一層，我都曾經在真實事故裡感受過「缺了它會怎樣」。以下，我用三個事故來解釋這張圖。事故一：它很認真，但沒有人告訴它邊界在哪裡... » read more

Read

steven written 1 month ago

個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計

個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計從工程流程、技術債，到多 AI 協作下的信任與交接管理一、專案的真實推進歷程一個專案的起點，通常只是一個模糊的初步想法。沒有完整規格書，沒有詳細設計，就這樣開始了。從那個模糊的起點，工程推進的節奏大致是這樣走的： 1 先產出基本功能模組，讓系統能動起來就好 2 在使用過程中，整體框架慢慢成形，初期的功能設計與使用者介面跟著調整 3 逐項補完自認為不足的功能，同時持續除錯 4 調整操作動線，修正功能畫面，讓使用流程更順 5 引進多家 AI 助理提供評析意見，開始收斂專案結構 6 陸續償還開發期間累積的技術債整個過程需要大量的持續觀察、監工、推進，以及心力投入。這不是寫完就結束的工作，是一直在跑的系統——你不看，它就會悄悄跑偏。中間會遇到很多分岔點，特別是大型程式碼變動或重構的時候，這種時刻很容易因為趕進度而跳過一個關鍵動作：遇到有疑問的分岔點，別忘記趕緊進行 git 版本保存。很多決策是不可逆的，事後才後悔已經來不及了。關鍵抉擇之前，也需要凝聚多家 AI 助理的經驗與意見，交互詰問，讓不同視角的問題都浮出來。這個動作看起來慢，實際上可以避開很多後期才爆炸的問題。能做到這樣，才能真正啟動 40 倍槓桿的效益——讓沒有專業程式設計背景的人，也能完成多項功能的模組化程式串接任務。這不是誇張，是我們實際跑過的個案數字。二、文件才是資產，不是記憶開發過程中，有一件事非常重要，但很多人（包括 AI 助理）都會忽略：最重要的資產是文件，不是個人的記憶，也不是 AI 助理的記憶。程式碼是一翻兩瞪眼的事情。你說「我記得某個功能是這樣設計的」，那沒有用。把那個功能模組調出來，看哪一行寫了什麼，那才是真正的內容。這個原則同樣適用於 AI 助理。AI 助理很容易煞有其事地亂掰一通，聽起來很有道理，但查了原始碼才發現根本不是那回事。它們也容易偷懶，把輸出內容簡化，把細節省略掉，讓你以為問題已經處理好了。人類架構師覺得有疑問，就是要進行確認，不要跟著 AI 助理以為可以安逸。不要放任 AI 助理胡亂地承諾與答應，然後你就真的信了。這種工作態度的底線很簡單：有疑問就查，查了才算數。三、多... » read more

Read

steven written 2 months ago

工程師思路系列之事出必有因

工程師思路系列｜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

Read

steven written 2 months ago

AI 沒有猜錯，但我還是不知道自己在看哪一張 RTX 3060

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

Read

steven written 2 months ago

36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部輸給實測數據

36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部被數據打臉 Mr. τ／風雲網通系統 · 2026-06-10 · 地端 AI 基礎設施一、心動的開始前幾天，社群裡流傳一篇文章。有人用 RTX 5090 在本地跑 Gemma 4 12B，透過一個參數調整，TPS 從 27 直接飆到 103。將近四倍。看完之後，我盯著螢幕想了很久。「我手上有三張 RTX 3060 12GB，加起來 36GB VRAM。應該也能跑得很猛吧？」其實買第三張卡的初衷很務實。不是為了炫耀規格，而是有實際需求：兩張卡跑大一點的模型，偶爾會 OOM（顯存不足），動不動就崩想測試 26B、27B 等級的模型，需要更寬裕的 VRAM 緩衝不希望因為顯存限制，就把好不容易找到的優質模型放棄帶著這個期待，我做了一件很多人都會做的事：先去問 AI。 💡 小科普：什麼是 TPS？ TPS = Tokens Per... » read more

Read

steven written 2 months ago

看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南

看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南從模型名稱看懂參數規模、MoE 架構、量化格式與推理優化當你開始接觸地端 AI（Local AI）之後，很快就會發現一件事：最大的障礙不一定是顯示卡，也不一定是 Linux。而是模型名稱。第一次看到： Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW 很多人的反應通常都是：「這到底是模型名稱，還是 Wi-Fi 密碼？」事實上，這串名稱並不是亂命名。它其實是在用最短的字數，描述模型的架構、規模、量化方式、推理特性與用途。如果能看懂這些縮寫，你幾乎可以在下載前就判斷：需要多少記憶體？跑起來快不快？適合聊天還是寫程式？是否支援特殊優化？是否有安全限制？一、30B 是什麼？ 30B 指的是： 30 Billion Parameters 也就是 300 億參數。參數可以理解成模型在訓練過程中學到的知識權重。模型規模常見用途 3B 輕量聊天助手 7B 個人 AI 助理 14B 進階推理 30B 高品質通用模型 70B+ 接近大型商業模型能力通常參數越大，能力越強，但所需記憶體也越高。二、A3B 是什麼？... » read more

Read

steven written 2 months ago

工作管理員說 llama-server 吃了 17GB RAM 我把整個過程錄下來了

本地 AI 推論 · 記憶體診斷工程筆記 · 實測紀錄 Mr. τ／風雲網通系統 · 2026-06-09 我有一台 64GB RAM 的地端 AI 主機，平常系統總用量很少超過 16GB。那天睡眠喚醒後，瞄到用量靠近 32GB，直覺就覺得不對。打開工作管理員，最顯眼的那行是 llama-server.exe，排在所有程式最上面，佔了 17GB。第一個念頭：GPU offload 掛了，Qwen3.6 27B 整個跑回 CPU 了？但 nvidia-smi 一查，GPU1 8153MB、GPU2 8701MB，紋絲不動。推論速度 18.6 tok/s，也沒事。 GPU 好好的，模型在跑，但 RAM 突然多了將近一倍的用量。那個 17GB 到底是什麼？我沒有重開機。我寫了一個監控程式，把整個過程錄下來。實測數據：163 筆，每 2 秒一筆程式從喚醒前就跑著，Sleep/Resume 全程自動記錄。以下是這次事件的完整時間軸。 19:31:52 ── 基準線 llama-server Working... » read more

Read

steven written 2 months ago

原來整理 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

Read

steven written 2 months ago

從一次 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

Read

steven written 2 months ago

今天，我在客戶的網路裡
發現了一台沒有人知道存在的設備

今天，我在客戶的網路裡發現了一台沒有人知道存在的設備 — PCPiLOT PCPiLOT Your IT Knowledge, Distilled. 風雲網通系統有限公司現場紀實 · 2026.06.04 今天，我在客戶的網路裡發現了一台沒有人知道存在的設備這不是駭客入侵的故事。這是一個關於「問題一直都在，只是沒有人看見」的故事。以及，為什麼每一次現場的發現，都值得被好好記錄下來。 Mr. τ（Steven） · 風雲網通系統 · 2026 年 6 月 4 日早上九點，客戶現場掃描工具告訴我，這個辦公室的網路上有 35 台設備在線上。但我知道有些不對勁。因為其中 30 台，根本不是真實的設備。花了一段時間，才找到原因。現場有一套監控攝影機系統，它持續發送的網路廣播訊號污染了掃描工具的記憶體，讓工具把一堆幻象當成真實設備回報給我。換了工具，重新掃描，換了方法交叉比對。一台一台確認。漸漸地，這個網路的真實樣貌才開始浮現。然後我發現了那台沒有人知道存在的設備在一個不起眼的角落，接著一台八埠的小交換器。後面連著六台監控攝影機——這部分有人知道。但還有另一台設備，接在同一台交換器上。它可以獨立對外連線，完全繞過辦公室的防火牆與路由器。我問客戶：「這台是誰裝的？」沒有人知道。查了一段時間，才確認是當初監控系統廠商施工時，順手接進來的設備。客戶完全不知道它已經在那裡存在多久了，也不知道它一直在做什麼。問題不是沒有人在意。而是沒有人看見。這讓我想到一件更大的事這樣的情況，我在不同的現場反覆遇到。形式不同，但本質相似：某個問題已經存在很久，只是一直沒有被完整地看見、記錄、以及理解。... » read more

Read

steven written 2 months ago

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

Read

steven written 2 months ago