做到 Day 27 之後，這個專案已經累積了不少功能。
一路從：

Flask
  ↓
MySQL
  ↓
CRUD
  ↓
任務狀態
  ↓
 分類
  ↓
 篩選
  ↓
 Git
  ↓
Code Review
  ↓
Groq API
  ↓
Structured Outputs
  ↓
Prompt 調整

前面幾天幾乎都在加東西。
但專案做到這裡，如果還一直往上疊，很容易出現另一種問題：

功能都能跑
但程式越來越難整理

所以 Day 28 我先不加新功能。
今天的重點是：

把目前專案完整檢查一次，確認哪些東西真的有用、哪些只是以前留下來的、哪些設定和文件已經過期。

今天不新增功能

Day 28 我先把範圍限制住。
今天不做：

• 不新增 Flask route
• 不改資料庫 schema
• 不修改 Task / Category model
• 不把 Groq API 接進首頁
• 不讓 AI 寫入 MySQL
• 不加 retry
• 不繼續調 Prompt
• 不新增 services／routes 分層
• 不做 Application Factory
• 不安裝新套件
• 不部署
  今天只做：

Review
 ↓
確認
 ↓
清理

先看目前專案結構

目前我的專案大概是：

ai-task-manager/
│
├─ __pycache__/
│
├─ models/
│  ├─ __pycache__/
│  ├─ category.py
│  └─ task.py
│
├─ static/
│  └─ css/
│     └─ style.css
│
├─ templates/
│  ├─ add_task.html
│  ├─ edit_task.html
│  └─ index.html
│
├─ venv/
│
├─ .env
├─ .env.example
├─ .gitignore
│
├─ app.py
├─ CLAUDE.md
├─ config.py
├─ db.py
├─ groq_api_test.py
├─ requirements.txt
├─ scenario_test.log
└─ schema.sql

目前其實沒有很複雜。
所以今天也不打算為了「看起來比較專業」硬拆成：

routes/
services/
repositories/
utils/

現在這個規模，簡單反而比較容易看懂。

pycache 和 venv 要不要刪？

VSCode 左邊可以看到：

__pycache__/
models/__pycache__/
venv/

這些都不是專案程式碼。
__pycache__ 是 Python 執行後自動產生的快取。
而 venv/ 是這個專案的虛擬環境。
目前 .gitignore 已經有：

venv/
.env
__pycache__/
*.pyc
*.log

所以這些雖然會出現在 VSCode 左側，但不會被 Git commit。
因此今天不用特別刪。

scenario_test.log 也先不處理

專案根目錄還有：

scenario_test.log

這是一個之前留下來的測試紀錄。
因為 .gitignore 已經有：

*.log

所以它：

只存在本機
不會被 Git 追蹤

Review 時也確認內容沒有 API Key 或密碼類資訊。
所以今天不需要為了整理而硬刪。

先讓 Claude Code 做唯讀 Review

今天沒有直接叫 Claude Code 開始刪檔案。
而是先讓它檢查整個專案。
我請它讀：

CLAUDE.md
app.py
config.py
db.py
models/
groq_api_test.py
requirements.txt
.env.example
.gitignore
schema.sql
templates/
static/

另外使用唯讀 Git 指令：

git status
git diff
git log --oneline
git ls-files
git check-ignore
git grep

先回答幾個問題：

有沒有沒使用的程式碼？
有沒有過期註解？
requirements 有沒有漏套件？
.env.example 是否正確？
.gitignore 是否正常？
CLAUDE.md 是否跟目前狀態一致？
有沒有敏感資訊被 Git 追蹤？

這次 Review 完後，實際發現需要清掉的東西其實很少。
這反而是好事。

Python 程式沒有明顯 dead code

Review 結果裡：

app.py
config.py
db.py
models/
groq_api_test.py

都沒有發現明顯：

沒用到的 import
沒用到的變數
沒用到的函式

也就是前面雖然一路加功能，但 Python 程式目前沒有累積很多明顯垃圾。
所以 Day 28 不需要為了整理而硬改 Python。

真正找到的是 4 組沒用到的 CSS

static/css/style.css 裡找到 4 組沒有被任何頁面使用的規則：

.category-study
.category-project
.submitted-preview
.submitted-preview ul

其中：

.category-study
.category-project

是以前分類樣式留下來的。
後來分類顏色已經改成直接使用：

category.color

所以這兩組 CSS 就沒有任何地方再引用。
另外：

.submitted-preview
.submitted-preview ul

則是早期「送出預覽」功能留下來的樣式。
目前 templates 和 Python 都沒有再使用。

不是看到沒用就直接刪

刪之前，先用：

git grep

確認這 4 個 class 到底還有沒有被引用。
結果是：

templates/
*.py

都完全找不到。
修改前，這 4 個 class 只剩下：

style.css 自己的定義

也就是典型的 dead CSS。
這時候才真的適合刪。

最後只刪了 21 行

Day 28 真正的程式修改只有：

static/css/style.css

總共刪除：

21 行

沒有新增任何一行。
刪掉的就是：

.category-study
.category-project
.submitted-preview
.submitted-preview ul

其他 CSS：

.category-dot
button:focus-visible
.task-form

等等都沒有動。
也就是：

只刪已經確認沒有任何引用的東西。

修改後再驗證一次

刪除後，我又重新搜尋整個專案。
結果：

4 個 class 都沒有任何符合

也就是：

exit code = 1

代表找不到。
接著：

git diff --stat

結果只有：

static/css/style.css | 21 ---------------------

再看：

git diff static/css/style.css

也只有兩個 CSS 刪除區塊。
沒有其他檔案被改到。
最後：

git status

也只有：

M static/css/style.css

所以這次整理範圍非常乾淨。

requirements.txt 先不動

目前 requirements.txt 有：

Flask
Flask-SQLAlchemy
PyMySQL
python-dotenv
openai==2.47.0

Review 後確認這些都有實際使用。
沒有漏掉明顯套件，也沒有多出完全沒用的套件。
比較特別的是：

openai==2.47.0

有固定版本。
其他幾個目前沒有固定版本。
本機實際版本則是：

Flask==3.1.3
Flask-SQLAlchemy==3.1.1
PyMySQL==1.2.3
python-dotenv==1.2.1

要不要全部固定版本，其實是另一個專案管理決策。
所以今天沒有順便改。

.env.example 也有確認

目前程式實際使用的環境變數有：

DB_HOST
DB_PORT
DB_NAME
DB_USER
DB_PASSWORD
GROQ_API_KEY

Review 後確認：

.env.example

和程式實際使用的名稱一致。
而且裡面只有 placeholder。
沒有真正的：

資料庫密碼
Groq API Key

所以這部分也不用修改。

.gitignore 目前也正常

實際用：

git check-ignore

測試後確認：

.env
venv/
__pycache__/
*.pyc
*.log

都有被正確忽略。
所以像：

.env
scenario_test.log
__pycache__

即使在電腦上存在，也不會被 Git commit。
Review 有看到一些可以額外補的東西，例如：

.venv/
.env.local
IDE 設定資料夾

但目前專案沒有使用。
所以今天不為了「可能以後會用」先加一堆規則。

敏感資訊沒有進 Git

這次還特別檢查了 Git 追蹤內容。
結果：

.env 沒有被追蹤
.env.example 只有 placeholder
schema.sql 沒有帳號密碼
沒有搜尋到 gsk_ 開頭的 Groq API Key
Git 歷史裡也沒有 .env

所以目前：

GROQ_API_KEY
資料庫密碼

沒有被 commit。
這是 Day 28 我覺得很值得確認的一件事。

groq_api_test.py 今天不刪

雖然檔名叫：

groq_api_test.py

但它現在已經不只是最早 Day 25 的簡單測試。
目前裡面有：

SYSTEM_PROMPT
TASKS_SCHEMA
MIN_TASKS / MAX_TASKS
parse_tasks()
Groq client 建立方式
Structured Outputs
reasoning_effort
max_completion_tokens
錯誤處理

這些在 Day 29 要把 Groq 正式接進 Web App 時，都還有參考價值。
所以今天沒有因為它叫 _test.py 就刪掉。

哪些東西之後可以重用？

groq_api_test.py 裡，之後真正接進 Web App 時，比較值得保留的包括：

SYSTEM_PROMPT

TASKS_SCHEMA

parse_tasks()

OpenAI(
    base_url="<https://api.groq.com/openai/v1>"
)

model="openai/gpt-oss-20b"

response_format=json_schema

reasoning_effort="low"

max_completion_tokens=2048

另外錯誤處理順序也可以參考：

AuthenticationError
			↓
RateLimitError
			↓
APIStatusError
			↓
APIConnectionError

但像：

命令列參數
print()
print_info()
sys.exit()
終端機提示

這些就比較偏向 Day 25～27 的測試用途。
Day 29 真正接 Flask 時，不一定會直接照搬。

還看到一些重複邏輯，但今天不改

Review 過程也發現一些之後可以整理的地方。
例如：

new_task()
edit_task()

都有各自讀：

title
description
status

模板裡的：

status 選項

也在：

index.html
add_task.html
edit_task.html

重複寫。
分類部分也有：

add_task.html
edit_task.html

寫死：

學習
專案
生活

但 index.html 的分類篩選卻是：

從資料庫動態讀取

這些確實可以再整理。
但 Day 28 不做。
因為：

整理不等於看到任何重複就全部重構。

分類管理按鈕目前只是預留

首頁目前還有：

<button class="category-link">分類管理</button>

但這個按鈕現在沒有實際功能。
它是之後分類 CRUD 的預留 UI。
目前：

分類新增
分類編輯
分類刪除

都還沒有做。
所以今天也沒有因為它「看起來可以按」就順便實作。
這是後續功能，不是 Day 28 清理工作。

已知問題今天也沒有全部修

目前專案還有一些之前已經知道的問題。
例如：

new/edit 的 title 後端沒有完整驗證

new/edit 的 status 驗證不一致

不存在的 category 名稱可能被轉成 None

description 空字串和 due_date NULL 的處理方式不一致

這些今天都沒有修。
因為只要開始修：

表單驗證
資料庫錯誤
route 行為

Day 28 就會從「整理」變成「功能修改」。
所以今天只確認它們仍然存在。

有些只是推論，不能直接當 Bug

Review 還提出：

Task.title 是 VARCHAR(200)
但後端沒有長度限制

理論上如果輸入超過 200 字，可能會出問題。
但這次沒有真的測。
所以我沒有直接寫成：

超過 200 字一定會 500

因為這只是推論。
同樣地：

finish_reason=length

目前程式有防呆。
但實際 API 呼叫還沒有真的遇過。
這也不是 Bug。
Day 28 讓我再次看到：

程式碼推論、尚未測試的風險、實際確認的 Bug，三個要分開。

Day 27 的 json_validate_failed 也先不修

前一天已經查到：

模型偶爾產生語法錯誤 JSON
	 ↓
Groq 驗證失敗
	 ↓
HTTP 400
	 ↓
json_validate_failed

目前沒有加入：

retry

Day 28 也沒有處理。
因為 retry 不是整理。
它會改變程式行為。
例如還要決定：

哪些錯誤要 retry？
最多幾次？
429 要不要 retry？
失敗後網頁顯示什麼？

這些等 AI 真正接進 Web App 時再處理比較合理。

今天最大的收穫

Day 28 幾乎沒有新增任何功能。
但我反而更清楚現在這個專案到底有哪些東西。
整理專案不等於：

一定要大改

有時候 Review 完後發現：

大部分東西其實都合理
只有 21 行真的該刪

這也是一個好結果。
比起為了「今天一定要有很多修改」而亂重構，我更希望：

該留的留
確定沒用的才刪
不確定的先不動

這樣 Git diff 也比較容易看懂。