系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄

「你的工具在手機上跑版了」

工具上線之後，我把連結傳給幾個朋友試用。

其中一個朋友過沒多久傳來一張截圖：按鈕超出畫面邊界，文字擠在一起，底部的語言切換按鈕消失不見。

我在電腦前把瀏覽器視窗縮小測試——看起來沒問題。

問題是他用的是手機，不是縮小的瀏覽器視窗。

我的處理方式：截圖轉發給 Claude

說實話，我沒有自己去 debug CSS。

我把那張截圖和一句話傳給 Claude：

「朋友說手機版跑版了，你看一下怎麼修。」

這大概是這個系列最誠實的一句話了。

2026 年的 IT 工作現實就是這樣：你不需要自己找出 CSS 哪行出問題，你只需要把問題描述清楚，讓 AI 去處理。

Claude 找到的問題

Claude 看了程式碼之後，找出了幾個主要原因：

問題 1：缺少 viewport meta tag

<!-- 這行沒加，手機瀏覽器不知道要用實際螢幕寬度顯示 -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">

沒有這行，手機瀏覽器會預設網頁是 980px 寬，然後縮小顯示，整個介面變得很小且行為怪異。

問題 2：按鈕用了固定寬度

/* 修正前：固定寬度，手機螢幕不夠寬就溢出 */
.option-button {
  width: 300px;
}

/* 修正後：自適應 */
.option-button {
  width: 100%;
  max-width: 400px;
  box-sizing: border-box;
}

問題 3：觸控目標太小

原本按鈕高度只有 32px，手機上用手指點很容易點到旁邊。

Claude 把所有互動按鈕的 min-height 改成 48px，符合 Google 的觸控目標建議尺寸。

問題 4：語言切換按鈕被推出畫面

這個是 position: fixed 配合 bottom 定位的問題，在某些手機上軟鍵盤彈出時會出現位移。調整了 z-index 和 padding-bottom 之後解決。

修完之後 Claude 給的測試建議

Claude 同時給了一個測試方法，讓我以後可以自己先驗證：

Chrome DevTools 手機模擬：
按 F12 → Ctrl+Shift+M（或點左上角的手機圖示），選擇不同設備模型測試。

常用的測試尺寸：

• 375px — iPhone SE、舊款 Android
• 390px — iPhone 14
• 430px — iPhone 14 Pro Max
• 768px — iPad 直式

「但真實設備還是最準，」Claude 說，「模擬器不能完全還原手機瀏覽器的行為。」

這句話，是從這次 bug 得到的教訓。

這個工作流程的意義

這個事件的流程是：

朋友測試 → 截圖 → 我轉發給 Claude → Claude 找問題修好 → 朋友確認正常

我在這個流程裡做的事：收集回饋、描述問題、驗證結果。

技術實作的部分，全部是 Claude 完成的。

這不是我偷懶，這是合理的分工。我的時間和注意力應該放在：哪些使用者回饋是值得優先處理的？這個工具的核心邏輯對不對？下一個功能是什麼？

CSS 的 width: 100% 該怎麼寫，不需要是我的專業。

今天的反思

很多工程師對「靠 AI 寫程式」還有一種心理上的抗拒，覺得這樣不夠「真材實料」。

但工具存在的意義就是讓人更有效率。

你不會要求木匠「不能用電鋸，要展現手工精神」。

重要的是你做出來的東西是否解決了真實問題，不是你用什麼方式解決它。

第二章小結

Day 06 到 Day 10，走完了從技術選型到前端實作的主要里程碑：

• ✅ 純靜態 HTML 的架構決策
• ✅ GitHub Pages 部署（master:main 的坑）
• ✅ 繁中優先，後來加英文的 i18n 系統
• ✅ 深色預設，朋友要求加淺色 → Claude 修 → 文字消失 → Claude 再修
• ✅ 手機版跑版 → 截圖給 Claude → 修好

這章最大的主題，其實不是技術，而是：一個人 + AI 的小型開發流程長什麼樣子。

明天預告（第三章）： 讓這個工具真正「會思考」——把 AI 接進來。Claude API 怎麼從純前端呼叫？Prompt 設計花了多少時間？為什麼一開始就要設計 Adapter Pattern？

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣