前幾天讓 Claude Code 自己寫 Test、執行 Test，甚至可以根據失敗結果找到 API 的問題。

這時候我開始思考：
如果 Test 全部通過了，Code 就一定沒有問題嗎？

答案其實不一定。

Test 主要是在確認我預先定義的情境，但有些問題可能根本沒有被 Test 覆蓋到。

所以今天我想讓 Claude Code 幫我做 Code Review，看看它能不能從另一個角度檢查目前的程式

這次我沒有要求它修改 Code，而是先讓它單純分析：

請幫我 Review 目前的 API Code。 請不要直接修改任何程式碼。
請檢查： 1. 是否有潛在 Bug
        2. 錯誤處理 是否完整 
        3. API 設計是否合理 
        4. 是否有安全性問題 
        5. 是否需要補充 Test 
        請列出發現的問題， 並說明問題原因與建議修改方式。

Claude Code 開始分析後，實際找到了不少問題。

首先在 潛在 Bug 的部分，它發現文章 ID 使用：

"id": len(ARTICLE_DB) + 1

來產生。

如果中間刪除文章後再新增，len(ARTICLE_DB) 就可能造成新的 ID 與原本的文章重複。

另外，註冊功能也可能存在 Race Condition。兩個相同帳號的請求同時進來時，即使前面都檢查「帳號不存在」，後面的 INSERT 仍可能發生 sqlite3.IntegrityError，但目前程式沒有完整處理。

在 例外處理 部分，Claude Code 發現 SQLite 連線與操作沒有完整使用 try/finally 或 context manager。假如 Database 操作發生例外，可能造成連線沒有正常關閉。

接著是我覺得比較重要的 安全性問題。

它發現目前密碼是直接以明文儲存在 Database：

password TEXT NOT NULL

而且 app.py 裡還有寫死的：

app.secret_key = "dev-secret-key"

另外，/login 沒有失敗次數限制，而文章新增與刪除 API 也沒有完整檢查登入權限。

這些問題可能不一定會讓目前的 Test 失敗，但實際部署到正式環境時就需要特別注意。

Claude Code 也發現部分 API 即使發生「找不到文章」、「帳號或密碼錯誤」等情況，仍然回傳 HTTP 200，而不是使用適合的 HTTP Status Code。

這次 Code Review 讓我發現：

Test
→ 實際執行功能
→ 確認結果是否符合預期

Code Review
→ 閱讀程式碼
→ 找出潛在 Bug
→ 檢查例外處理
→ 檢查 API 設計
→ 檢查安全性

而且這次我沒有讓 Claude Code 直接修改 Code，而是先讓它把問題列出來，再由我判斷哪些問題需要處理。

所以目前我的 AI 開發流程已經慢慢變成：

需求
↓
AI 規劃
↓
AI 寫 Code
↓
AI 寫 Test
↓
執行 Test
↓
Debug
↓
Code Review
↓
人工確認

這次實驗也讓我開始思考另一個問題：

如果每次 Code Review 都要檢查這些項目，那能不能把這些規則直接寫進 CLAUDE.md？

這樣之後 Claude Code 開發時，就可以直接依照這些規則進行檢查，而不用每次重新告訴它。
明天研究主題:把 Code Review 變成 Claude Code 的固定規則