文章目錄
我們不是花八小時修 bug，是花八小時才發現沒有 bug
一次 App 開發的真實除錯紀錄，以及它告訴我們關於 AI 協作、資訊可視化與決策品質的事
這篇文章不需要你懂程式。
它講的是一個管理者和決策者都熟悉的問題：當你的團隊花了很長時間解決一個問題，最後發現問題根本不在他們找的地方——那段時間，是怎麼浪費掉的？
我最近第一次開發 Android 手機 App，親身經歷了這件事。過程很痛苦，但教訓很值得分享。
起點：一個真實的市場需求
台灣有超過五百萬慢性病患，他們每天面對一個沒有人幫他們解決的問題：
「站在超商貨架前，拿起一包零食，我能吃嗎？吃多少？今天已經吃太多了嗎？」
我開發的「好口福」App，就是要回答這個問題。使用者輸入身高體重和慢性病狀況，App 掃描食品標示後，給出一個簡單的顏色燈號：
安心買
注意量
地雷區
今日已爆
問題：一個小圖示消失了
App 的主要功能都做好了。最後一個待辦很小：在每個營養素旁邊加一個「ⓘ」圖示，讓使用者點擊後看到健康說明。
程式碼寫好了。系統檢查通過。部署完成。
但手機上，那個圖示完全不見了。
接下來的八小時
我和 AI 協作工具花了將近八小時排查這個問題。每一個假設都被否定：
我們不是花八小時修 bug，是花八小時才發現根本沒有 bug。
問題從來不在 UI 層，而在資料層。但我們沒有任何工具可以「看見」資料層的狀態，所以只能從最表面的地方開始猜。
這對你的組織意味著什麼
這個故事不是在講程式。它在講每個有團隊、有系統、有流程的組織都會遇到的三件事：
不論是設備監控、業績追蹤、還是 App 開發——沒有可視化的即時狀態，問題出現時只能逐一假設、逐一排除。每一個錯誤假設都是時間成本。
Claude Code 每次說「部署完成」，因為它確實執行了部署的動作。但它看不到手機螢幕，無法確認實際結果。AI 協作工具的能力很強，但它的「看見範圍」有邊界。導入 AI 的主管需要理解：AI 負責執行，人負責確認結果。
二十年前做系統整合時，我見過客戶花一天查設備故障，最後發現是網路線沒插好。問題的根因，往往比你預期的更基礎。最先應該確認的，是最底層的輸入——資料存在嗎？
可以帶走的方法：三個問題
不管是 IT 問題、業務問題、還是流程問題，遇到「應該有但看不到」的狀況，先按順序問這三個問題：
| 優先順序 | 問題 | 意義 |
|---|---|---|
| 先問 | 資料（輸入）存在嗎？ | 這個功能需要的前提條件，真的都齊備了嗎？ |
| 再問 | 流程有被執行到嗎？ | 設計好的邏輯，有沒有在某個環節提前被中斷？ |
| 最後問 | 結果真的送達了嗎？ | 「送出」和「送達」是兩件事。確認最終端的真實狀態。 |
結語：能看見，才能管理
好口福 App 最後做好了。這八小時的繞路，代價是時間，換來的是一個清楚的認知：
如果當時有一個簡單的狀態指示燈，顯示「使用者資料：無」，可能五分鐘就找到答案。
這個道理叫做「可觀測性（Observability）」——讓系統的內部狀態變得可見。這不是工程師的術語，這是所有管理者應該追求的能力：
能看見，才能管理。能管理，才能改善。
這個道理，在網通機房成立，在 AI 推論平台成立，在 Android App 開發也成立。如果你的組織正在導入數位工具或 AI 協作，值得認真問一次：我們有足夠的觀測點嗎？
Comments