iT邦幫忙

2026 iThome 鐵人賽

DAY 9
0
Software Development

AI 時代的 Android Engineer:30 天打造我的 AI 開發工作流系列 第 9 篇

Day 09 - AI 找到 Existing Pattern,就一定應該照著做嗎?

  • 分享至 

  • xImage
  •  

前幾天我一直在要求 AI 做一件事:

先看 Project 現在怎麼做,再決定新的 Code 怎麼寫。

原因很簡單。如果每次新增功能,AI 都按照自己的想法重新設計,很快就會出現不同的命名、不同的處理方式,甚至多出原本根本不需要的抽象。

所以我在 Skill 裡也一直強調:

Follow Existing Architecture
Prefer Existing Pattern
Minimum Necessary Change

但整理到這裡,我突然發現另一個問題。

如果 Existing Pattern 本來就有問題呢?

沿用既有寫法,不一定代表它是對的

前面實作正計時時,我曾經發現一個原本就存在的問題。

Pomodoro 設定超過一小時,例如 70 分鐘時,畫面上會顯示:

70:00

但通知顯示的是:

01:10:00

同一個時間,在不同地方用了不同格式。

如果今天我要替 Stopwatch 做超過一小時的時間顯示,然後告訴 AI:

請參考現有 Pomodoro 的寫法。

那它到底應該參考哪一個?

如果只是單純 Follow Existing Pattern,它甚至可能把原本的不一致一起複製到新功能。

這時候「參考既有功能」就開始變得沒有想像中簡單。

Existing Code 比較像證據,不是答案

我前幾天會要求 AI 比較 Existing Behavior,是因為很多 Requirement 根本不會完整寫在需求裡。

像是少於 5 分鐘不建立紀錄、結束後要不要存資料、計時中其他功能能不能操作,這些都可能藏在現有 Code 裡。

所以 Existing Code 很重要。

但現在我覺得更準確的說法應該是:

Existing Code 可以告訴我現在怎麼做,但不一定代表新的功能就應該完全照做。

它比較像是判斷時需要的一份證據。

例如 AI 發現:

Pomodoro Fragment → 70:00
Notification       → 01:10:00

這時最不應該做的,就是隨便挑一個當成「Project Pattern」。

因為這裡根本還沒有一致的 Pattern。

那什麼情況可以直接沿用?

我目前會把它簡單分成兩種。

如果 Project 裡的做法很一致,例如相似畫面的字串都放 strings.xml、相同類型的 UI 都使用同一套命名方式,而且沒有看到明顯衝突,那 AI 直接沿用通常很合理。

但如果找到的是:

Feature A → 做法 1
Feature B → 做法 2

或甚至同一個 Feature 裡就已經有兩種結果,那它就不應該再把其中一個直接當成標準答案。

這時比較合理的流程應該是:

找到 Existing Pattern
↓
確認是否一致
↓
一致 → 優先沿用
↓
不一致 → 找出差異
↓
判斷能不能從 Code 確認原因
↓
不能確認 → 告訴我

這跟昨天整理的「什麼事情 AI 可以自己決定」其實也接得起來。

如果 Project 已經給了很強的證據,AI 可以自己處理。

如果 Project 本身就在互相矛盾,就不應該假裝已經找到答案。

我不希望 AI 為了「一致」把 Bug 複製下去

這也是我現在對「遵守既有架構」比較在意的地方。

遵守 Existing Architecture 不代表:

看到什麼就 Copy 什麼。

而應該比較像:

先理解現在為什麼這樣做,再判斷這個 Pattern 是否真的適合這次修改。

尤其舊 Project 很容易存在歷史留下來的不一致。有些是刻意的,有些可能只是不同時間寫的,有些甚至就是還沒被發現的 Bug。

如果 AI 把 Existing Code 全部當成正確答案,它雖然看起來很「融入 Project」,卻也可能很有效率地把舊問題複製到新的 Code。

所以我想再補一個判斷

目前我希望 AI 面對 Existing Pattern 時,不只是:

找到 → 沿用

而是:

找到
↓
確認是不是穩定而且一致的 Pattern
↓
是 → 沿用
↓
不是 → 不要自行選一個當標準

這不代表每次都要重新檢討整個 Project,也不是看到兩種寫法就要開始大規模 Refactor。

如果這次需求跟那個問題沒有關係,甚至可以先不處理。

但至少 AI 應該知道:

「Project 現在這樣寫」和「這就是 Project 正確的做法」不是同一件事。

寫到 Day 9,我發現我一開始想做的「讓 AI 更懂 Project」,好像也慢慢變得不太一樣。

不是讓它記住更多 Class、Architecture 或 Coding Style,而是希望它能慢慢分辨:

哪些東西是可以沿用的慣例,哪些是需要確認的需求,哪些又只是 Project 裡剛好存在的歷史寫法。

理解 Existing Code,不只是找到 Pattern,也包含知道什麼時候不該盲目複製 Pattern。

這可能才是我真正想讓 AI 學會的 Project Context。


上一篇
Day 08 - AI 可以自己推論,但哪些事情不該讓它自己決定?
下一篇
Day 10 - 用了十天 AI 寫 Code,我反而更確定 Android 還是要懂
系列文
AI 時代的 Android Engineer:30 天打造我的 AI 開發工作流 共 17 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言