昨天整理了一份自己的程式碼檢查清單，主要分成四個方向：

修改範圍
↓
需求
↓
功能整合
↓
程式碼

但整理完之後我想到一個問題。

既然 AI 已經可以幫我寫程式，那我是不是也可以在它寫完之後直接說：

幫我檢查剛才的修改有沒有問題。

這樣看起來很方便，但仔細想想會發現一個問題：

如果第一次寫錯的原因，是它一開始就理解錯需求，那再叫同一個 AI 檢查一次，它真的會發現嗎？

寫程式和檢查程式，需要的視角其實不太一樣

以前做 Stopwatch 時就遇過一個很明顯的例子。

我希望加入正計時功能，AI 最後做成：

進入 Stopwatch
↓
自動開始計時

如果實作完成後直接問：

幫我檢查剛才的修改。

AI 很可能會開始確認：

時間有沒有增加
Pause 能不能用
Resume 能不能用
結束後有沒有存紀錄
程式能不能編譯

這些全部都可能正常。

但真正的問題是：

「進入頁面就自動開始」這件事，是誰決定的？

如果 AI 在第一次實作時已經把「進入 Stopwatch 就開始計時」當成正確需求，那第二次檢查時，它很可能還是沿用同一個前提。

所以「再檢查一次」不一定真的產生第二個視角。

有時只是：

第一次：
用假設 A 寫程式

第二次：
用假設 A 檢查自己有沒有把 A 寫好

當然很可能看不出 A 本身就是問題。

所以我需要的不是「再看一次」

我開始覺得，比起單純要求：

幫我檢查這次修改。

更重要的是讓第二次檢查刻意換一個角度。

例如第一次的任務是：

實作 Stopwatch

第二次就不要再問「Stopwatch 有沒有實作好」，而是拆成：

原始需求到底要求了什麼？
↓
實際修改增加了哪些行為？
↓
哪些行為需求沒有明確提到？
↓
修改碰到哪些共用狀態？
↓
哪些原有功能可能被影響？

這樣檢查的目標就從：

找程式寫錯的地方

變成：

找「需求」和「實際修改」之間的差距。

這兩種檢查其實不太一樣。

我想把「需求」和「修改結果」分開比較

假設原始需求只有：

加入正計時，從 00:00 開始，每秒增加並顯示時間。

AI 最後做了：

進入頁面自動開始
使用共用 TimeManager
切換 Mode 為 STOPWATCH
啟動背景通知
結束後建立紀錄

這時不要先問這些程式「寫得對不對」。

而是先一項一項問：

自動開始
→ 原始需求有說嗎？

共用 TimeManager
→ 現有架構可以支持嗎？

切換 Mode
→ 會不會影響 Pomodoro？

背景通知
→ 是既有計時功能的必要行為嗎？

建立紀錄
→ 紀錄規則從哪裡來？

這樣很容易發現，有些是「實作方式」，有些其實已經偷偷變成「新的需求決定」。

這也是我覺得 AI 檢查程式時很重要的一件事：

不要只檢查它寫出的程式，要把程式重新對回原始需求。

再來才是檢查影響範圍

第二層才是從修改的地方往外找。

例如 AI 改了：

TimeManager

那就不能只測 Stopwatch。

因為 TimeManager 原本也被 Pomodoro 使用。

所以檢查方向應該變成：

這次改了誰？
↓
還有誰使用它？
↓
那些使用者依賴它的什麼行為？
↓
這次修改有沒有改變那些行為？

這跟單純「搜尋相關檔案」也不太一樣。

真正重要的是依賴關係。

例如：

Stopwatch
      ↓
  TimeManager
      ↑
Pomodoro

只要修改中間這層，就應該知道兩邊都有可能受到影響。

反過來，如果只是改 StopWatchFragment 裡一個純顯示文字，就沒有必要突然把整個 Timer 架構重新檢查一次。

這其實又回到前幾天一直在整理的概念：

不是看越多越安全，而是要沿著真正的影響方向看。

還有一種問題，光看程式本來就看不出來

即使 AI 把需求和影響範圍都檢查過，還有一類問題只能實際操作才容易發現。

之前 Stopwatch 就出現過：

切換 Fragment
↓
回到 Pomodoro
↓
畫面顯示也跟著 Stopwatch 計時

從某一個 Function 單獨看，可能每段都合理。

真正出錯的是多個元件一起運作後的結果。

所以我現在會把檢查再分成：

看程式可以確認
↓
修改範圍
需求差異
依賴關係
資料流
明顯錯誤

實際執行才能確認
↓
畫面切換
生命週期
背景 / 前景
操作順序
多功能交互影響

這也代表 AI 告訴我：

已通過編譯。

其實只完成很前面的一部分。

編譯成功只能告訴我程式至少能被編譯，不能證明使用者操作後的結果正確。

所以我想把 AI 的第二次檢查改成「反向檢查」

目前我比較想嘗試的方式不是：

請檢查你剛才寫的程式。

而是要求它重新從結果往回看：

實際修改
↓
對回原始需求
↓
找出額外假設
↓
沿修改點找依賴
↓
列出需要實際操作確認的情境

最後可以整理成三個問題：

1. 你做了哪些原始需求沒有明確要求的事情？

2. 你修改的程式還被哪些既有功能使用？

3. 哪些風險無法只靠閱讀程式或編譯確認？

這三題可能比一句：

幫我檢查有沒有問題。

更接近我真正需要的檢查。

AI 可以寫，也可以幫忙找錯，但不能用同一個角度看兩次

以前我會覺得，多叫 AI 檢查一次應該就比較安全。

現在反而覺得：

檢查次數不是重點，第二次有沒有換一個角度才是。

第一次的目標是把需求實作出來。

第二次如果還是站在「我要證明這個實作可以工作」的角度，很容易只是確認自己原本的答案。

但如果第二次改成：

假設這份修改可能有問題，重新從需求差異、依賴關係和實際操作去找反例。

才比較像真正的檢查。

所以接下來我想嘗試的，不是讓 AI 在寫完後說一句「已檢查，沒有問題」。

而是讓它告訴我：

這次修改最可能在哪裡出錯，以及哪些地方我一定要自己實際驗證。

如果 AI 能把這些地方找出來，我覺得才真的開始像一個有用的程式碼檢查工具，而不只是幫自己的答案再按一次確認。