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

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

0
Read
steven
AI 沒有猜錯，但我還是不知道自己在看哪一張 RTX 3060
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

0
Read
steven
36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部輸給實測數據
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

0
Read
steven
工作管理員說 llama-server 吃了 17GB RAM 我把整個過程錄下來了
工作管理員說 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

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

0
Read
steven
從一次 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

0
Read
steven
Prototype 能動，不代表 Product 能活
Prototype 能動，不代表 Product 能活

軟體工程 AI 協作 SMB 數位轉型 委外 CKO Prototype 能動，不代表 Product 能活 AI 時代的「原型膨脹幻覺」與複雜度治理，一篇給想動手者、也給評估委外者的清醒文 這兩年，很多人第一次有了「原來我也能做軟體」的感覺。 對著大型語言模型（LLM）下幾段精準的指令，網頁登入畫面會自己長出來，資料庫結構會自己建，API 串接、Docker 容器化、前後端框架——AI 助理都能在幾分鐘內幫你完成初稿。這是一個非常真實的突破。過去阻擋許多企業與領域專家的，是程式語言本身的高門檻。而現在，那道牆正在鬆動。 許多原本因為「缺人缺錢缺時間」而永遠啟動不了的專案，終於第一次有了「從 0 到 1」的可能性。這件事，我們是真心欣喜的。 但也因為進入門檻的全面民主化，市場正在出現一種全新的治理盲區——我們在現場看了二十年，必須把實情說清楚。 📌 什麼是「Prototype Inflation（原型膨脹幻覺）」？ 越來越多團隊第一次成功做出了 Demo，看著畫面上會跑會動的介面，就誤以為自己已經完成了產品。網路上充滿「用 AI 10 分鐘做一個 App」的激情短影音，卻極少有人以「在 Production 生產現場活過二十年」的視角，冷靜地指出後面那個會爆炸的修羅場。 Prototype 能動，不代表 Product 能活。 這句話，是這篇文章最想傳遞的一件事。 先說給「想自己動手」的你聽 LLM 是一個真實的能力放大器。如果你在自己的領域有深厚的知識與經驗，你現在確實是最適合動手嘗試的一群人——因為你知道痛點在哪、知道答案對不對、知道什麼才算「真正能解決商業問題」。 但是，軟體工程是非常現實的事情。Demo 階段的美好，和實際營運階段的考驗，是兩個完全不同的世界。當你的系統脫離實驗室、準備承擔商業責任時，真正的複雜度治理挑戰，才正要開始。 如果試了之後發現自己或內部團隊確實不那麼擅長軟體架構與生命週期管理——請點頭承認，這也是非常正常且理性的經營判斷。交給相熟且具備實戰經驗的 IT 專家處理，是最務實的選擇，不是認輸。 ⏳ 時代的隱形風險：限制消失了，系統在理解複雜度前就已長大 在過去，軟體開發緩慢的步調，某種程度上其實是對企業的一種隱形保護。因為開發慢、成本高，團隊在初期就會被迫面對各種預算、人力與技術限制，這反而促使團隊提早去思考模組劃分、運維流程與權限資安。 但 AI 時代打破了這個保護機制。現在最大的風險，不是做不出系統，而是開發速度太快了——快到團隊還來不及建立系統防禦力，就已經利用 AI 把系統盲目堆大了。這種缺乏地基的補丁式系統，一旦進入市場，隨之而來的工程現實一個也逃不掉。... » read more

0
Read
steven
AI 不再是「大雄的安慰機器人」
AI 不再是「大雄的安慰機器人」

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

0
Read
steven
2026 Local AI 的典範轉移: 從「硬體軍備競賽」走向「系統工程調校時代
2026 Local AI 的典範轉移: 從「硬體軍備競賽」走向「系統工程調校時代

從「硬體軍備競賽」走向「系統工程調校時代」 風雲網通系統 ｜ 技術深度報告 2026 Local AI 的典範轉移 從「硬體軍備競賽」走向「系統工程調校時代」 LOCAL AI MoE ARCHITECTURE llama.cpp SMB AI 落地 許多中小企業（SMB）在評估地端 AI 落地時，最常聽到一個問題：「我們是不是非得採購動輒數十萬的高階 AI 伺服器，才能跑動夠聰明的大型語言模型？」 在傳統「暴力堆砌硬體（Hardware Brute Force）」的思維下，答案似乎是肯定的。然而，邁入 2026 年，Local AI 的技術底層已悄悄迎來一場革命性的典範轉移。 實測案例 ／ 觸發本文的關鍵數據 技術頻道 Codacus（YouTube）發布實測影片《Running a 35B AI Model on 6GB VRAM, FAST》，以一張 8 年前的 GTX 1060 6GB、搭配 i3 處理器與 24GB DDR4，成功流暢運行 350 億參數（Qwen 3.6 35B... » read more

0
Read
steven
資深 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

0
Read
steven
按下 Enter 的那 1.2 秒，世界裡發生了什麼事？
按下 Enter 的那 1.2 秒，世界裡發生了什麼事？

按下 Enter 的那 1.2 秒， 世界裡發生了什麼事？ 你的腦袋要讀 15 分鐘的東西，AI 為什麼幾秒就懂了 #AI科普  #LLM  #雲端運算  #ChatGPT  #Claude  #地端AI 下午三點，你打開一份 PDF——季報、技術文件、或者一份你根本不想讀的會議紀錄。密密麻麻，滑鼠往下捲了三下才到底。 你嘆了口氣，把整份文字框選，貼進 ChatGPT 或 Claude，打了幾個字：「幫我抓重點。」 然後按下 Enter。 你端起咖啡杯。 還沒喝到嘴邊——答案已經出現在螢幕上了。 「等等……這份文件我自己看，要花至少 15 分鐘。 它怎麼可能幾秒就……讀完了？」 這個問題，值得認真回答。 AI 根本沒有在「閱讀」 在解釋「為什麼這麼快」之前，要先打破一個根本性的錯覺： AI 沒有在讀你的文字。 人類閱讀是線性的。你的眼睛從第一行掃到最後一行，大腦一邊解讀、一邊建立理解，遇到難的段落還要回頭重看。這個過程有前後順序，快不起來。 AI 做的事，完全不同。 它把你貼進去的所有文字，瞬間打散成數萬個數字（每個詞、每個標點都變成一串向量），然後用一種叫做「矩陣運算」的方式，讓所有詞語同時互相對照——哪些詞跟哪些詞有關聯、哪裡是重點、哪裡是細節——一次算完。 一個比喻： 人類閱讀，像是一個人拿著手電筒在黑暗中逐行照。 AI 處理，像是整個房間的燈同時打開——所有角落一眼看清。 1000 行的程式碼，對 AI 而言不是「1000 行要逐行理解」，而是「幾萬個數字，做一次大規模的平行矩陣計算」。 按下 Enter 之後，那 1.2 秒裡發生了什麼 跟著一個請求，從你的鍵盤出發，往下走一遍。... » read more

0
Read
steven
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

0
Read
steven