iT邦幫忙

2026 iThome 鐵人賽

DAY 19
0
Vibe Coding

四個番茄鐘,三次重新來過:我跟 AI 的 30 天開發考古系列 第 19 篇

Day 19|貓走到第二個螢幕就消失:一個問了三次才問對的 bug

  • 分享至 

  • xImage
  •  

Pomofocus 有一隻貓,工作時間到了會從螢幕邊緣走出來提醒我。
我用兩個螢幕,而這隻貓在多螢幕環境下出過兩次問題。

兩次的處理方式不一樣,結果也不一樣。

第一次:先問「這是壞掉還是正常的」

6 月 16 日,我看到畫面上有兩隻貓,其中一隻卡在螢幕邊緣不動。

我當時打的三則 prompt:

會多一隻卡在螢幕邊是正常的嗎?

幫我確認是「正常巡邏停頓」還是「多螢幕造成的真卡住」

直接照這兩點改並測試是否有成功修改好

三段:觀察、診斷、修正。

第一則的重點是我沒有說「有 bug 幫我修」。因為貓本來就設計成「走到邊緣會停一下再折返」,停在那裡有可能是正常的。如果我直接說「它卡住了,修一下」,AI 會很配合地開始改巡邏邏輯——然後把本來正常的行為改壞。

第二則把可能性收斂成兩個選項,逼它去查證而不是猜。

第三則才是動手,而且要求它自己測。

18:37 修正進 repo(f3d8b06),20 行,scenes/overlay/cat_overlay.gd。

這個習慣後來變成規則

7 月我做 prompt 健檢的時候,把這個模式抓出來寫進了全域設定:

Bug 或異常回報:先診斷並回報原因——區分「預期行為」與「真的壞掉」——等我確認方向後再修,不要直接改 code。

現在我只要說「這個怪怪的」,它會先回報診斷結果,等我確認才動手。

第二次:貓走進第二個螢幕就不見了

一個月後,7 月 17 日,同一隻貓出了新問題。交接文件 12.22 記的是:

使用者回饋兩點:
(1) 邊緣貓走出螢幕後 30-60 秒才回來,等太久;
(2) 多螢幕下貓走進第二顆螢幕幾步就憑空消失

第二點的原因是 6 月那次修正埋下的——當時的折返點和停靠隱藏位置,算出來剛好落在兩個螢幕的交界處。

14:49 改好(d6895b3,105 行):停靠時間從 30-60 秒縮短成 8-15 秒,巡邏範圍從「單一螢幕」改成「一整條水平相鄰的螢幕鏈」,走到整條鏈的最外緣才折返,跨到高度不同的螢幕時跟著各自的底邊走。

然後同一天下午,我實際用的時候發現還是不對。

真正的原因:從作業系統讀回來的座標

交接文件裡這段寫得很清楚:

貓從第二顆螢幕右緣折返時,錯從第一顆螢幕回場。原因:行走位置每幀 var p := position 從 OS 讀回視窗實際位置再累加,而右側停靠點如今在整個虛擬桌面之外,隱藏/重顯間 Windows 會把視窗 clamp 回可見螢幕,讀回的就是被搬走後的座標。

翻成白話:貓走出畫面之後,Windows 覺得「這個視窗跑到看不見的地方了」,就把它搬回可見範圍。而程式每一幀都去問作業系統「我現在在哪」,於是拿到的是被搬過的位置,貓就從錯的地方走回來。

修法是不再問作業系統,改用自己內部的浮點數當唯一的位置來源,每幀單向寫進去(7104693,43 行)。順便解掉了整數累加的誤差。

驗證方式很有意思:

一次性腳本在停靠隱藏期間強制把視窗搬到 (100,100),貓仍從第二螢幕右緣 (1799,496) 回場

寫一個腳本模擬 Windows 的搗亂行為,確認修正真的有效,測完把腳本刪掉。

這個 bug 教我的事

1.「狀態放在哪裡」是個要想清楚的問題。 位置這種東西,看起來從 OS 讀最準,實際上 OS 會自己動手腳。誰是唯一的真相來源,要先決定。

2. 同一個功能修第二次時,要回頭看第一次改了什麼。 7 月那個 bug 是 6 月那次修正的副作用。如果當時沒有交接文件記著「6/16 改了折返點計算」,這次大概又是從頭猜起。

3. 多螢幕是 AI 的盲區。 它看不到我的螢幕配置——我這台是主螢幕 1920×1200 縮放 150%、副螢幕 1920×1080 縮放 100%,兩個混合 DPI。這種環境的問題,只能靠我描述、靠實機測,自動測試完全抓不到(screen_count 在無畫面模式下是 0)。

帶走這個:回報 bug 的三段式句型

直接照抄,把底線換成各種狀況:

第一段(觀察,不下結論)
  ______ 這樣是正常的嗎?

第二段(逼它二選一,而不是猜)
  幫我確認這是「______(預期行為)」還是「______(真的壞掉)」。

第三段(確認方向後才動手,並要求自驗)
  直接照這兩點改,並測試是否有成功修改好。

為什麼第一段不能寫「這裡有 bug,幫我修」?因為 AI 會立刻進入修理模式,開始改那個可能本來就正常的邏輯。

這個模式也可以寫成規則,讓它變成預設行為:

Bug 或異常回報:先診斷並回報原因——區分「預期行為」與「真的壞掉」——
等我確認方向後再修,不要直接改 code。

還有一個額外好處:第二段逼 AI 講出判斷依據,而那段依據常常就是沒想清楚的部分。我這次的依據是「折返點跟停靠位置落在螢幕交界」,那句話後來變成一個月後另一個 bug 的線索。

明天講個番茄鐘有趣的功能:讓 App 自己產生一段 prompt,我貼給 AI 分析我的用眼數據,然後把 AI 的結論改回 App 裡。


上一篇
Day 18|623 行的交接文件,是我讓 AI 接力的方式
下一篇
Day 20|讓 App 自己產生 prompt,再把 AI 的結論改回 App
系列文
四個番茄鐘,三次重新來過:我跟 AI 的 30 天開發考古 共 21 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言