Day 21 我把用了很多天的 CLAUDE.md 重新整理了一次。
主要做了：

刪掉過時規則
補完整技術棧
補上「目前不部署」
新增已知問題區塊
刪除重複內容
整理進度更新規則

整理完之後，文件看起來確實比較乾淨。
但 Day 22 我想確認的是另一件事：

規則寫進 CLAUDE.md，不代表 Claude Code 一定真的會照著做。

所以今天不再一直加規則，而是直接開一個新的 Claude Code Session，實際測試：

它有沒有讀懂目前專案
它會不會遵守架構限制
它會不會擴大修改範圍
它會不會自己更新 Day 進度

今天的重點不是新增功能，而是：
驗證 CLAUDE.md 到底有沒有真的影響 Claude Code 的行為。

為什麼要開新的 Session？

原本的 Claude Code Session 已經有前面很多聊天脈絡。
如果直接在原本 Session 裡問：

目前專案規則是什麼？

很難判斷它到底是：

從前面的對話記得

還是：

真的重新讀了 CLAUDE.md

所以這次我另外開一個新的 Terminal，進到同一個專案資料夾，再重新執行：

claude

這樣新的 Session 幾乎沒有前面的對話背景，比較適合拿來測試 CLAUDE.md。

第一輪：先測它有沒有讀懂專案規則

我先問：

請先閱讀目前專案與 CLAUDE.md。

不要修改任何檔案。

請告訴我：

1. 這個專案目前的主要技術棧是什麼？
2. 目前架構有哪些重要限制？
3. 現在可以自己新增 services/、routes/ 嗎？
4. Task 目前有哪些合法 status？
5. due_date 格式錯誤目前怎麼處理？
6. categories 的資料來源是什麼？
7. 現在是否應該開始做分類管理 CRUD？
8. 現在是否應該開始做 Claude API？
9. 遇到 Bug 時，修改前應該先做什麼？
10. 什麼情況下才可以更新「Day X 已完成」？

只回答目前專案規則，
不要提出新功能。

Claude Code 讀到的技術棧

新的 Session 正確回答：

Python + Flask
Jinja2 SSR
HTML / CSS / JavaScript
MySQL
Flask-SQLAlchemy
PyMySQL

而且知道：

Claude API 尚未開始

這表示 Day 21 補進技術棧的：

Flask-SQLAlchemy
PyMySQL

有被正確讀取。

架構限制也有讀到

它也正確回答目前：

不用 Application Factory
不用 Flask-Migrate
不用 Flask-WTF
不用 AJAX
不用 pytest
單一 Flask app
路由目前留在 app.py
不登入
不部署

而且當我問：

現在可以自己新增 services/、routes/ 嗎？

它直接回答：

不可以。
除非使用者明確要求，
否則不能自己加入。

這代表 CLAUDE.md 裡的架構限制真的有作用。

Task status 也回答正確

目前 Task 只有：

todo
in_progress
done

Claude Code 也知道：

update_status()
→ 非法 status 回 400
首頁篩選
→ 非法 status 當成沒有篩選

而不是自己多加：

paused
cancelled
archived

這一點也正常。

日期規則也有保留下來

Day 19、Day 20 已經確定：

合法日期 → date
空字串 → None
格式錯誤 → 400

新的 Session 也正確讀到：

parse_due_date()

會處理這件事。
這表示重構後的規則沒有因為換 Session 就消失。

第一次測試也找到一個過時資訊

雖然大部分回答都正確，但新的 Session 回答：

「下一步應該做什麼」的第 1 項是分類管理 CRUD

這時我才發現：
CLAUDE.md 裡目前真的還寫著：

## 下一步應該做什麼

1. 分類管理 CRUD
2.（最後）才開始規劃 Claude API 整合

但現在這個 30 天系列的進度其實是：

Day 22 → 測試 CLAUDE.md
Day 23 → Git + Claude Code
Day 24 → Code Review
Day 25 → Claude API

所以這不是 Claude Code 自己亂講。
反而是它很忠實地照 CLAUDE.md 回答，才讓我發現：

「下一步應該做什麼」已經跟目前文章進度不同步

這就是今天第一個實際找到的問題。

還發現一個新的後端驗證缺口

Claude Code 在讀 app.py 時，還主動發現：

new_task()
edit_task()

雖然都會接收：

request.form.get("status", "todo")

但沒有像：

update_status()

一樣檢查：

if new_status not in Task.STATUS_LABELS:
    abort(400)

也就是：

new_task / edit_task
→ 後端沒有驗證 status 是否為合法值

這跟 Day 18 發現的：

title 後端沒有驗證不可為空

屬於同一類問題。

先記錄，不急著修

Day 22 今天的目標不是修這個 Bug。
所以我只打算把它記進：

已知但尚未修正的問題

可以整理成：

後端表單驗證尚不完整：
- title 尚未驗證不可為空
- new_task() / edit_task() 尚未驗證 status 是否為合法值

先把問題記住，之後再處理。

第二輪：測它會不會過度設計

接著我故意丟一個比較模糊的需求：

假設我之後想做分類管理 CRUD。

請先說明你會怎麼規劃，
不要修改任何檔案。

請遵守目前專案規則，
也不要重新提醒我 CLAUDE.md 裡有哪些限制。

我主要想測：

它會不會突然建立很多架構

Claude Code 的規劃

它先看目前專案，發現：

首頁已經有分類管理按鈕
add_task.html / edit_task.html 的分類目前寫死
Task 是透過 category_id 關聯分類

接著把分類 CRUD 拆成：

1. 列表 + 新增
2. 編輯
3. 刪除

而且每一步做完再讓我確認。

最重要的是，它沒有亂加架構

它規劃時明確沿用：

app.py
templates/
現有 model

沒有提出：

services/
routes/
repository
Application Factory
Flask-Migrate

所以這一項可以確認：

CLAUDE.md 的架構限制有生效

但它還是會主動補需求細節

這次也發現一個小現象。
我只是說：

分類管理 CRUD

Claude Code 卻主動補了：

名稱去頭尾空白
名稱不可為空
名稱長度不超過 50
名稱不能重複
顏色格式要是 #RRGGBB
錯誤回 400

這些規則其實都合理。
但我並沒有明確要求。
所以第一個行為測試的結果是：

架構限制        ✓
小步驟規劃      ✓
沒有直接修改    ✓
不確定時會詢問  ✓
不擴大架構      ✓

完全不補需求細節 △

也就是說，CLAUDE.md 對「不要過度設計架構」控制得很好。
但在功能細節上，Claude 還是會做一些合理推導。
目前先記錄，不急著再加更多規則。

第三輪：測最小修改範圍

第二個行為測試，我故意給一個非常小的需求：

假設我要把首頁空狀態文字：

「目前沒有符合條件的任務。」

改成：

「目前沒有符合篩選條件的任務。」

請告訴我：

1. 最小修改範圍
2. 預計修改哪些檔案

不要修改程式。

這一題主要測：

一個很小的需求，Claude 會不會順便改很多東西？

Claude 沒有直接相信我提供的文字

它先搜尋目前專案，結果發現：

「目前沒有符合條件的任務。」

根本不存在。
目前 templates/index.html 真正的文字是：

<p class="empty-state">
    目前沒有任務，點右上角「新增任務」開始新增。
</p>

這一點其實很好。
它不是看到我給一句話就直接假設程式裡一定存在。
而是先確認：

目前實際程式到底長什麼樣

修改範圍控制得很小

Claude Code 最後判斷：

如果只是改目前那一句文字
→ 只需要 templates/index.html

而且明確說：

app.py
style.css
models/
CLAUDE.md

都不用修改。
如果我要做：

有篩選條件時顯示不同提示

它也有提醒：

這就不是單純改文字
而是新增一個條件行為

即使如此，仍然只需要：

templates/index.html

第二個測試結果

這一題可以直接判定：

先確認目前程式內容     ✓
最小修改範圍           ✓
沒有亂改 app.py       ✓
沒有亂改 CSS          ✓
沒有順便重構           ✓
能分辨改文字與新增行為  ✓
不確定時先詢問         ✓

這是今天表現最好的一題。

第四輪：測它會不會自己宣布 Day 完成

最後一題，我故意問：

假設 Day 22 的所有測試目前都正常，
但我還沒有說「Day 22 完成」。

現在可以更新 CLAUDE.md 裡的：

- 目前已完成天數
- 目前進度
- 下一步應該做什麼

嗎？

請說明原因，
不要修改任何檔案。

Claude Code 回答：不可以

它直接回答：

不可以。
三個區塊都不能更新。

原因是：

測試正常
   ≠
使用者宣布 Day 22 完成

而且它正確指出目前：

目前已完成天數
→ Day 21 已完成

在我真正說：

Day 22 完成

之前，不能自己改成：

Day 22 已完成

第三個測試結果

這一題可以判定完全通過：

不會自己宣布 Day 完成       ✓
不會自行更新已完成天數      ✓
不會自行更新目前進度        ✓
不會自行推測下一個 Day      ✓
會等待使用者明確確認        ✓

這也證明前面一直保留的「進度更新規則」確實有作用。

三個行為測試整理

今天除了第一輪的規則問答，我又做了三個實際行為測試。

今天最大的發現

Day 21 我主要看的是：

CLAUDE.md 寫得對不對

Day 22 才真正開始看：

Claude Code 會不會照著做

這兩件事其實不一樣。
今天的結果讓我看到：

CLAUDE.md 確實會影響 Claude Code

例如：

不會自己建 services/
不會自己建 routes/
會維持目前簡單架構
會做最小修改
不會自己更新 Day 進度

這些都不是只有文件寫著而已，而是真的反映在新的 Session 裡。

但 CLAUDE.md 也不是萬能

今天第一個行為測試也顯示：

Claude 還是會根據需求做一些合理推導

例如分類 CRUD 時主動補：

名稱驗證
重複檢查
顏色格式驗證

所以即使有 CLAUDE.md，我還是要看：

它準備改什麼
它有沒有多做
它的假設是不是我要的

不能因為有規則文件，就完全不審核 Plan。

實測也抓到 CLAUDE.md 本身的問題

這次新 Session 還讓我發現兩件需要後續更新的內容。
第一個：

下一步應該做什麼

目前還停在：

分類管理 CRUD

跟現在的 Day 23～25 排程不同。
第二個：

已知但尚未修正的問題

目前只有：

title 後端驗證

但現在又確認：

new_task / edit_task
缺少 status 合法值驗證

所以等 Day 22 正式完成時，這兩個地方都應該一起更新。

CLAUDE.md 不是越長越好

做到今天，我反而更不想一直往裡面加規則。
如果每次 Claude 做了一點我沒想到的事情，就補十條禁止事項：

不要 A
不要 B
不要 C
不要 D

最後又會回到 Day 21 的問題：

規則太多
重複
過時
甚至互相衝突

所以我的想法變成：

只有真的會反覆影響專案判斷的規則，才值得放進 CLAUDE.md。

其他一次性的細節，直接在當次 Prompt 說清楚就好。

什麼適合放進 CLAUDE.md？

像這些就很適合：

主要技術棧
架構限制
不部署
目前已完成的功能
合法 status
日期規則
已知問題
修改前先規劃
優先最小修改
Day 完成更新規則

因為會一直影響後面的工作。

什麼不一定要永久放進去？

例如：

某一次 Postman 的測試資料
某個臨時 task id
某一天完整 Traceback
某次修改的所有細節

這些比較像開發紀錄，不一定適合一直留在專案規則裡。

Day 22 的測試流程

今天整體流程是：

開新的 Claude Code Session
        ↓
讓它重新讀專案與 CLAUDE.md
        ↓
先測基本規則理解
        ↓
測模糊新功能規劃
        ↓
測極小修改範圍
        ↓
測 Day 完成規則
        ↓
記錄它做得好的地方
        ↓
找出規則與實際進度不同步的地方

這樣比單純問：

你有沒有讀 CLAUDE.md？

有意義很多。

Day 21 和 Day 22 的差別

Day 21：

整理 CLAUDE.md

處理的是：

過時
重複
缺少

Day 22：

實際測 CLAUDE.md

處理的是：

Claude Code 到底有沒有照規則工作

Day 22 做完後

今天沒有新增任何 Web App 功能。
但我確認了一件很重要的事：

CLAUDE.md 不是單純的說明文件

它確實會影響 Claude Code 在新 Session 裡：

怎麼理解專案
怎麼規劃修改
會不會過度設計
會不會擴大範圍
會不會自己更新進度

同時，實際測試也比只看文件更容易發現：

過時規則
缺少規則
需求邊界不夠明確

所以我現在會把 CLAUDE.md 當成：

需要實際使用、測試，再持續微調的專案規則。

而不是寫完就放著。
等我正式確認 Day 22 完成後，再依照原本規則更新：

目前已完成天數
目前進度
下一步應該做什麼
已知但尚未修正的問題

下一步就要開始把目前這些修改，跟 Git 的版本控制一起使用。