前言

ㄟ...？AI 寫的程式碼也會有技術債？

當然！就算是 AI 也是會有技術債的好嗎？

儘管前面我們用了很多方式去避免欠債，像是...一次盡可能保持一個功能、做完就驗收、commit，甚至還有單元測試，但還是會有一些不可避免的技術債，所以這一篇我們就會來聊一下 AI 技術債的部分。

所以，什麼技術債？

有些人可能不太確定什麼是技術債，所以前面這邊讓我花一點時間稍微解釋以及說明一下。

所謂的技術債呢...簡單來講就是趕工的產物。

什麼意思呢？通常我們在開發一個專案的時候，會為了搶佔市場、趕上 deadline，或者是先把功能做出來，可能會先寫一些不夠乾淨、不夠一致的程式碼，或者是沒有做好測試、文件不完整等等，這些都是為了快速交付而暫時犧牲的品質。

而這個品質就是我們所說的「技術債」。

如果以比較生活面的例子來講，假設我們買了一棟房子，東西都很快的進駐、放置，但紙箱我們都先丟到角落，反正可以開始住、開始用就好，但過了一段時間後，你會發現你要找一條充電線可能就要翻三～五個箱子，因為你當初搬進來的時候根本沒有好好考慮東西的擺放位置導致。

將這件事情放眼程式碼也是一樣，同樣的程式碼，同樣的邏輯兩份，時常改 A 檔案忘了改 B 檔案，或者是文件跟程式碼講的不一樣，雖然當下並不會影響功能的運作，但當你要做維護、擴充時，就會開始需要支付利息，這就是技術債的概念。

那為什麼會提到這件事情呢？因為 Vibe Coding 的開發模式，反而容易產生大量的技術債。

以傳統快速開發來講，我們每次開發可能就只是留下一點點屎（意指不好的程式碼），但是 Vibe Coding 開發的模式讓開發速度除了加速之外，也加速了大量的屎。

先釐清，不急著重構

那要清理技術債這個過程我們稱為「重構」，重構的定義是「改結構不改行為」，也就是說，重構的目的是讓程式碼更乾淨、更一致、更容易維護，但不會改變程式的功能，這也是為什麼前面會規劃一個測試章節了。

畢竟重構雖然可以讓程式碼更乾淨、更一致、更容易維護，但是終究還是會更改到程式碼，難保你更改之後的結果跟原本的結果是一樣的，所以也會稱測試是一個「安全網」概念。

那我們該怎麼開始動作呢？其實就兩個字「盤點」。

所以一樣打開我們的練習專案，接著進入 Claude Code 並在對話框中輸入 /clear，確保清除對話框的內容，然後按 Shift+Tab 切到 Plan Mode（看到 plan mode on 就對了），接著輸入：

請盤點這個專案的技術債：

- 重複的邏輯
- 過大的元件（超過 300 行）
- 不一致的寫法

以及與 CLAUDE.md 或既有文件講的不一樣的地方。

這次我只要清單，不用給我修改計畫，每一條附嚴重程度跟建議。

接下來你應該會看到修改建議，而這就是我們請 AI 盤點出來的技術債清單。

但，你會發現我這邊使用的 Plan Mode 來做盤點，而不是直接在 Accept Edits Mode 下請 AI 盤點，為什麼呢？

其實你就把 AI 當作一個很雞婆的人，盤點著...盤點著，就不知道哪根筋不對就直接順便開始改了，接著就出現一大堆 Diff（修改記錄），你根本來不及判斷哪些該改、哪些不該改，所以這邊才會使用 Plan Mode 來做盤點，等你看完清單之後再決定要不要改。

我相信你一定會講：「直接 Prompt 裡面寫一句『先不要改』不就好了？」

老實講也沒有錯，但如果他的 Context 爆掉的話，終究還是會忘記這件事情，所以我才會建議你使用 Plan Mode 來做盤點。

很方便吧？透過這個方式，我們可以很快的找出專案中存在的技術債，並且可以依照嚴重程度來決定要不要改。

但開始之前，你務必要確認當前測試都是正常的（全綠），否則你根本分不出來是原本就壞的，還是你剛剛改壞的唷！

AI 最常欠的四種債

那這邊我想特別拉出來講一件事情回顧一下剛剛的 Prompt，因為我在 Prompt 裡面特別點名了四種東西，分別是：

• 重複的邏輯： 同樣功能與事情寫了兩次以上。
• 過大的元件： 一個檔案塞了太多事情，超過 N 行。
• 不一致的寫法： 同一件事情在不同地方有不同的寫法。
• 文件跟程式碼講的不一樣： CLAUDE.md、SPEC.md 與程式碼不一致。

ㄟ...為什麼我會特別點名這四種呢？因為這四種是 AI 最常欠的債。

這個根本原因其實還是圍繞在我們前面一直在講的 Context 有關係，每一次的使用 AI 其實都是從零開始，除非你有特別把這些東西寫在特定的檔案裡面，然後搭配 CLAUDE.md 或 SPEC.md 來引導 AI 閱讀，否則它根本不會知道你之前的程式碼是怎麼寫的。

分析的內容很多，要一次還嗎？

老實講，不用，但也不能忽視。

你應該要先挑出影響程度比較高的功能來實作，先做修正並逐步去更新，並非一次到位。

當然這邊我還是要交代一件事情：

AI 給的高、中、低只是它的意見，並不是聖旨，你才是這個專案的主人，所以你要自己判斷哪些債是你要先還的。

如果沒想法，你可以回顧一下前面章節所說的 MVP，先把最重要的功能做好，其他的就慢慢來，畢竟一個記帳軟體最核心的就是「計算」絕對不能出錯，其他功能只要不影響操作都可以往後排。

那因為 Plan Mode 出來的結果別忘記叫 AI 儲存下來，所以你可以輸入以下：

請把剛剛那份技術債清單完整存成 docs/TODO.md，每一條保留嚴重程度跟建議，先不要處理任何一條。

接下來你就慢慢閱讀這份 TODO.md 即可。

試試看還一些技術債

這邊我們就來實際還一下技術債，以我這邊來講，AI 掃出來的其中一條是 Day 22 掛上去的排版 Hook 沒有 Prettier 設定檔，所以它一直都是拿 Prettier 自己的預設值在排版（雙引號、加分號），可是專案原本的程式碼是單引號、不加分號。

也就是說，之後 AI 每改一個檔案，那個檔案就會被排成另一種風格，這就是前面講的不一致的寫法，也算是技術債的一種，另外當時拿來測試 Hook 的 src/hook-test.js 也還留在專案裡沒有刪。

那這個其實相對比較小，不太需要特別開到 Plan Mode，直接在 Accept Edits Mode 下請 AI 幫你做就可以了。

請幫我新增 Prettier 設定檔 .prettierrc，規則請依照專案現有程式碼的風格來訂（引號、分號、一行的寬度），不要用 Prettier 的預設值。

加完之後跑一次 npx prettier --check src，確認現有的檔案幾乎都不需要變動，順便把之前測試 Hook 留下來的 src/hook-test.js 刪掉。

做完請跑一次 npm test，並把 docs/TODO.md 裡「沒有 Prettier 設定檔」這一條標註為已完成。

Note
.prettierrc 是一個 Prettier 的設定檔，裡面可以設定程式碼的格式化規則，例如使用單引號還是雙引號、是否加分號、每行的最大長度等等。

這邊我並沒有告訴它要用單引號還是雙引號，而是請它自己去看現有的程式碼風格。

驗收：重構要驗的是什麼都沒變

那麼最後假設你已經重構完畢了，接著你務必要讓 AI 跑以下指令：

• npm test： 確認算錢的邏輯沒有被動到，Day 23 花時間寫的那些測試今天會成為你的防護網。
• npm run build： 確認專案可以正常打包運作，畢竟重構後許多檔案可能會被搬移。
• 自己走一遍畫面： 儘管可以透過一些自動化測試工具來驗證畫面，但我們主要是針對功能的正確性來驗收，所以這一層只能靠你自己。

跑的方式也很簡單，只需要給以下 Prompt 即可：

請幫我跑以下指令，並把結果回報給我：

1. npm test
2. npm run build

剩下的部分就留給你自己試著重構看看囉。

多久該盤點一次？

這個我認為滿沒有標準答案的，你可以依照專案的大小、複雜度以及開發進度來決定盤點的頻率。

例如...以我們這個記帳 App 來講，從開工到現在為止，中間一次都沒有盤點過，結果今天一盤就是 30 條，這個數量雖然不多，但還是建議趁早處理。

所以如果真的要講一個標準的話，與其用「多久」來算，我會建議你改用「時機」來判斷，只要遇到下面這幾個時機就盤一次：

• 大改版之後： 像前面章節我們針對畫面做了修正，這時候就可以順便調整一下。
• AI 開始出現怪怪的行為： 例如改 A 壞 B、同樣的東西它又寫了一份。
• 上線前： 這時候不管怎樣都會建議檢查一下，畢竟牽扯到給使用者使用。

這邊我也順手把今天的流程畫成一張圖：

結語

那時間也差不多到結尾了，這邊也幫你總結一下：

• 技術債不是 Bug，而是現在不痛、以後才痛的東西，AI 一次只看一個任務，所以回頭整理這件事要由你發起。
• AI 最常欠四種債：重複的邏輯、過大的元件、不一致的寫法、文件跟程式碼不一致。
• 盤點用 Plan Mode，清單存進專案，先挑影響最大的還，小事直接做、要動刀的走 Plan Mode 一次只還一條。
• 重構驗的是什麼都沒變，測試、build、畫面三層都過才 commit，沒過就直接退回去，不要硬修。

債盤點過了、測試也是全綠的，所以明天我們就直接把 App 部署上線，讓它有一個真正的公開網址。
希望這一篇有讓你把債還乾淨哩～
我們明天見囉～