昨天我開始把 Code Review 的規則整理到 CLAUDE.md 裡，讓 Claude Code 知道專案如何運作，也知道我希望它遵守哪些開發規範。

但做到這裡，我又想到一個問題：

如果今天要新增一個比較大的功能，是不是也可以不要一開始就叫 AI 寫 Code，而是先讓它幫我規劃？

所以今天我拿一個實際功能來測試。

例如我想新增「文章搜尋功能」，讓使用者可以輸入關鍵字，搜尋文章標題或內容。

我沒有直接叫 Claude Code 開始寫，而是先給它：

我想在目前的專案新增「文章搜尋功能」。

使用者可以輸入關鍵字，
搜尋文章的 title 或 content。

請先分析目前專案，
確認需要修改哪些檔案，
並提出完整的實作計畫。

Claude Code 先重新分析目前的專案結構，確認目前的文章功能主要分布在：

module.py
model.py
api.py
test_account_and_article_api.py

接著它提出了一個實作方案：不另外建立 /articles/search，而是在原本的 GET /articles 增加 keyword Query Parameter。

例如：

GET /articles
→ 取得全部文章

GET /articles?keyword=Python
→ 搜尋 title 或 content 包含 Python 的文章

它也進一步列出預計修改的地方，包括 ArticleService.list_all()、api.py、model.py，以及新增對應的 Test。

比較讓我意外的是，它沒有直接開始修改 Code，而是最後先問我：

「這個方向可以嗎？確認後我再開始寫程式碼跟測試。」

這正是我這次想測試的東西。

以前我比較習慣直接告訴 AI：

「幫我新增文章搜尋功能。」

然後 AI 就開始寫 Code。

但這次改成先要求它：

「先分析，先規劃，不要修改。」

我就可以在 Code 還沒有被修改之前，先確認它選擇的 API 設計是否符合我的需求。

例如這次它選擇使用：

GET /articles?keyword=xxx

而不是另外建立：

GET /articles/search

這種差異如果等到 Code 都寫完才發現，可能就需要重新修改。

所以我開始發現，Planning 的價值不是讓 AI 多寫一份計畫書，而是在真正修改 Code 之前，先把「要怎麼做」確認清楚。

這也讓我從原本的：

我要什麼 → AI 直接寫

慢慢變成：

我要什麼 → AI 分析 → AI 提出計畫 → 我確認 → 開始實作

下一步我想繼續測試：

如果我確認這份計畫沒問題，Claude Code 能不能按照計畫自己完成多個檔案的修改與 Test？

明天研究主題:把大任務拆成小任務，讓 Claude Code 一步一步完成。