好心辦壞事？談 AI 協作時代的 Silent Failure
好心辦壞事？談 AI 協作時代的 Silent Failure

PCPiLOT 技術觀點｜AI 協作工程 比系統崩潰更危險的，是「看起來還活著」 Mr. τ／風雲網通系統　｜　2026 年 5 月 最近一個通宵的開發過程中，我們遇到了一個值得記錄下來的 AI 協作事故。 它不像傳統系統故障那樣劇烈。沒有 Exception，沒有 Crash，沒有 Pipeline 中斷。所有燈號都是綠的。但核心產出，已經悄悄死亡。 事故現場 我們正在開發一條本地端的影音知識萃取流水線——目標是把原廠官方教學影片，自動轉換成結構化的知識筆記：摘要、建議程序 SOP、術語對照表。 流水線分三段：音訊擷取 → 語音辨識 → LLM 知識萃取。硬體是本地工作站，雙 RTX 3060，全程不上雲，知識不離開機房。 開發進行順利。直到深夜，高階 AI 協作工具的使用額度耗盡，我們換用幾個次級工具繼續收尾。 它們確實完成了工作。有修改，能執行，Pipeline 有輸出，系統沒有報錯。 直到隔天清晨，才發現事情不對。 Silent Failure 的面貌 語音辨識的結果讓人傻眼。一段五十幾分鐘的中文教學影片，逐字稿只有 1,587 個字元。正常應該有一萬三千字以上。 Pipeline 說它成功了。辨識出了 103 個語音段落。但實際內容只有正常的 9%。 這不是傳統 Bug。沒有任何錯誤訊息告訴你系統出了問題。你必須自己去量測輸出，才能發現核心已經掏空。 這，就是 Silent Failure。 真正的元凶：三層疊加 事後重新調回高階模型逐一排查，找到的不是一個 Bug，而是三個問題同時存在： 1 語言參數硬指定導致機器翻譯... » read more

0
Read
steven
用 AI 做決策這件事，其實是火箭工程的延續
用 AI 做決策這件事，其實是火箭工程的延續

工程思維 × 知識管理 用 AI 做決策這件事，其實是火箭工程的延續 從挑戰者號到多模型投票機制——容錯從電路搬到了語言層 Mr. τ／風雲網通系統  |  PCPiLOT 知識管理實驗室 最近在收斂一個客戶專案的解決方案規格時，我刻意做了一個設計上的決定： 不再依賴單一 AI 給答案，而是同時讓 3～4 個模型互相審查、主動挑錯、填補盲點，最後才收斂成可以落地的方案。 這件事乍看像是「AI 工具的用法選擇」，但它其實更像一個老到不能再老的工程問題：如何避免關鍵系統在最後一刻因為「大家都同意」而悄悄崩潰。 1986 與 2003：不是技術失誤，是裁決機制失敗 挑戰者號（1986）與哥倫比亞號（2003）的兩場災難，事後復盤都不是單點錯誤，而是暴露出同一種結構性缺陷： ✗ 工程師的警告訊號存在，但在層層彙報中被稀釋 ✗ 邊界條件被逐步「正常化」——這次看起來跟上次一樣，應該沒事 ✗ 最終裁決壓縮成一個二元問題：Go / No-Go，沒有灰度，沒有異議空間 真正的問題不是火箭的材料或設計，而是：錯誤被系統性地放行了。決策系統說服了自己「這次應該也沒事」。 火箭工程早就給過答案：TMR 三模冗餘 阿波羅任務與土星五號時代的導航電腦，採用了一個當時極為硬派的工程解法——TMR（Triple Modular Redundancy，三模冗餘）： 機制 說明 三套獨立系統 同時計算同一個問題，彼此不知道對方的答案 硬體投票裁決 少數服從多數，異常值直接被隔離 無 rollback 設計 太空中沒有重試機會，容錯必須在決策當下完成 這個設計的核心哲學不是「讓系統更聰明」，而是：假設任何單一系統都可能出錯，所以在架構上就不允許它單獨做最終裁決。 現在的 AI，重新打開了同一個問題 單一大型語言模型的問題不在於能力不足，而在於它有幾個結構性弱點： ▸ 幻覺（Hallucination）——以高度自信的語氣輸出不存在的事實 ▸... » read more

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

0
Read
steven
AI 開發體驗像坐雲霄飛車：當法力無邊的不是你，而是雲端 LLM
AI 開發體驗像坐雲霄飛車：當法力無邊的不是你，而是雲端 LLM

AI 開發體驗像坐雲霄飛車：當法力無邊的不是你，而是雲端 LLM 「我是不是突然變強了？」 最近幾週的 AI 開發體驗，真的像在坐雲霄飛車。 之前因為 Cursor 的 free tier 管控非常嚴格，只要短時間內把 tokens 用光，就會進入很長的冷卻期。長到我幾乎已經徹底棄用它，甚至快忘記自己有安裝過這套工具。 剛好這週，平常主要使用的 AI 服務付費額度也用完了。 對於目前已經習慣 AI 協助開發的人來說，這種感覺有點像： 「平常開車都開高速公路，突然被迫回去騎腳踏車。」 於是只好重新打開 Cursor，外加 Antigravity，想說至少多少補一點開發進度。 結果重新使用 Cursor 後，我其實滿驚訝的。 順暢度、理解力、執行成功率，都比我之前印象中的狀態好很多。 甚至已經開始有種： 「這東西現在真的能工作了。」 的感覺。 這其實是一件很危險，也很容易讓人產生錯覺的事情。 因為當 AI 助理開始能穩定完成工作時，人很容易進入一種： 「自己是不是法力無邊了？」 的狀態。 功能一直完成。 Bug 很快被修掉。 開發速度暴增。 原本可能要花兩三天研究的東西，現在幾小時內就能推進。 那種感覺真的很像： 一個人突然變成小型研發團隊。 但後來我慢慢發現。 真正法力無邊的，其實不是你。 而是背後那群正在燃燒 GPU 與資本支出的雲端大型語言模型。 AI 的超能力，其實是用錢燒出來的 很多人第一次大量使用 AI 開發工具時，都會被那種「超能力感」震撼到。... » read more

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

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

0
Read
steven
深夜收到「陌生 IP 登入警報」，<br>你知道該怎麼處理嗎？
深夜收到「陌生 IP 登入警報」，
你知道該怎麼處理嗎？

資安實務 ｜ NAS 維運筆記 ｜ 2026 深夜收到「陌生 IP 登入警報」，你知道該怎麼處理嗎？ 從一封 NAS 警告信，學會判讀、鑑別、封鎖的完整 SOP 某天下班後，手機收到一封主旨為「嚴重｜來自陌生 IP 的登入嘗試」的警報信。來源地：東歐某國家。登入帳號：公司管理員信箱。——你的第一反應是什麼？ 一、這封警報信在說什麼？ Synology Active Insight 會在偵測到非常規地理位置登入時自動發信通知。信中包含三個關鍵資訊： ✔ 哪個帳號被嘗試登入 ✔ 連線類型（HTTP/HTTPS） ✔ 來源所在位置（國家/地區） 收到這封信不代表帳號已被入侵，但也不能置之不理。關鍵在於：你是否能識別這次登入是否為授權行為。 二、先做鑑別診斷：正常還是攻擊？ 在採取任何行動前，先冷靜確認以下三個問題： 1 這段時間有人出差或出國使用 VPN 連回公司設備嗎？ 2 有委外廠商或協作夥伴被授權遠端存取嗎？ 3 登入是否成功？（失敗嘗試 vs. 實際進入是完全不同的嚴重程度） 若三個問題都答「否」，就需要啟動應急處置流程。 三、哪些國家是高風險來源？ 根據實際日誌分析，以下地區出現高頻率的自動化掃描與暴力破解嘗試： 風險等級 國家代碼 常見攻擊手法 高風險 CN、RU、UZ、KZ 自動化腳本掃描、帳號暴力破解 中風險 DE、NL、UA、PL 租用 VPS 作為跳板進行中繼攻擊 中風險... » read more

0
Read
steven
斷斷續續的無線網路
斷斷續續的無線網路

作者：Mr. τ 分類：現場排障案例 標籤：Wi-Fi／藍牙／2.4GHz／無線網路 在 IT 現場，有一類問題特別難抓——症狀看起來像網路故障，換個時間又自動恢復，偏偏找不到明確的硬體損壞跡象。本文記錄一個真實案例：Wi-Fi 播放卡頓，根本原因卻藏在一支藍牙耳機裡。 一、問題現象 使用情境：室內距離無線基地台較遠的位置，以手機連線 Wi-Fi 觀看 YouTube，同時透過藍牙耳機收聽音訊。 觀察到的異常：影片播放頻繁緩衝、斷斷續續卡頓，網路連線表面上仍顯示正常。 二、快速排查驗證 1 切換至 4G 行動網路播放 → 影片立即恢復正常，確認問題在 Wi-Fi 端，非內容來源或設備本身故障。 2 保持 Wi-Fi 連線，關閉藍牙耳機 → Wi-Fi 傳輸立即順暢，確認藍牙裝置是干擾來源。 兩步驗證完成，方向明確：藍牙與 Wi-Fi 之間存在無線干擾。 三、根本原因分析 3.1 頻帶重疊是核心問題 Wi-Fi 的 2.4GHz 頻帶與藍牙使用相同的無線頻譜範圍（2.400–2.4835 GHz）。當兩者同時運作，且距離接近時，訊號會相互競爭通道，造成封包碰撞與重傳，導致實際吞吐量下降。 Wi-Fi 2.4GHz 傳輸距離較遠，穿牆能力強，但頻段擁擠，干擾源多（微波爐、藍牙、鄰居 AP 等） Wi-Fi 5GHz 頻道數多、速度快、干擾少，但傳輸距離相對較短，穿牆能力較弱 藍牙（Bluetooth） 工作在 2.4GHz，採跳頻展頻（FHSS）技術，雖有抗干擾設計，但在弱 Wi-Fi 環境下仍會形成競爭 實際情境... » read more

1
Read
steven