昨天讓 Claude Code 先分析文章搜尋功能，並提出完整的實作計畫。

這時候我又想到一個問題：

如果一個功能需要修改很多檔案，AI 能不能自己把大任務拆成比較小的任務？

所以今天我延續昨天的文章搜尋功能來測試。

昨天 Claude Code 已經分析出需要修改 module.py、api.py、model.py，以及 test_account_and_article_api.py。

這次我直接要求它：

請根據剛才的計畫，
把這個功能拆成可以逐一執行的小任務。
每個任務請說明： 
1. 要修改哪個檔案 
2. 要完成什麼內容 
3. 完成後要驗證什麼 

請先不要修改程式碼

這次 Claude Code 實際拆出了 5 個任務。

第一個任務是先建立搜尋功能的 Test，測試 title、content、大小寫、搜尋不到結果，以及沒有提供 keyword 等情況。

第二個任務是在 model.py 定義 keyword Query Parameter，讓 API 的 Swagger 文件也可以正確顯示這個參數。

第三個任務修改 module.py 的 ArticleService.list_all()，讓它可以根據 keyword 搜尋文章的 title 或 content。

第四個任務再修改 api.py，讓 /articles 可以接收 keyword，並把參數傳給 ArticleService.list_all()。

最後第五個任務則是做完整驗證，確認所有 Test 都通過，而且原本的文章 CRUD 和帳號功能沒有受到影響。

這次我覺得比較有趣的是，它並不是單純把工作拆成：

修改 model.py
修改 module.py
修改 api.py
修改 test.py

而是有考慮到實作順序與依賴關係。

例如先建立 Test，確認預期行為；接著處理參數定義，再處理 Service 的搜尋邏輯，最後才由 API 把這些功能串起來。

而且每一個任務都有自己的驗證方式。

例如 Service 修改完成後，可以先確認 list_all() 原本不帶參數的行為沒有被破壞；API 修改完成後，再實際測試：

GET /articles
GET /articles?keyword=Flask
GET /articles?keyword=不存在的文字
這讓我發現，Task Decomposition 並不是單純把一個大工作切成很多小工作，而是要讓每個小任務都有明確的目標、修改範圍和驗證方式。

這樣做的好處是，如果其中一個任務出現問題，我可以很快知道是哪一個部分出了問題，也比較容易讓 Claude Code 根據結果繼續處理。

而且在真正修改程式碼之前，我還可以先檢查這份任務清單。

如果我發現某個任務不合理，就可以先要求 Claude Code 調整，而不是等 Code 全部寫完才發現方向錯了。

經過這幾天的實驗，我開始覺得「給 AI 一個大目標」和「讓 AI 能夠完成一個大目標」其實是兩回事。

前者只需要告訴它我要什麼，而後者還需要讓它知道：

要做哪些事情、哪些事情要先做，以及每個階段怎麼確認結果

明天研究主題:讓 Claude Code 自己完成一個完整功能