昨天說好了，今天不寫程式，也不測新工具。

先停下來，回頭看看這五天到底走過什麼路。

一、這五天，我其實只做了一件事

回頭看 Day 02 到 Day 06，做的事情表面上很不一樣：

• 設定免費額度、避開結算陷阱
• 在網頁上寫出第一個代碼審查提示詞
• 用 Few-Shot 和 CoT 讓 AI 看懂代碼
• 塞爆百萬 Token，順便踩了一個 Context Window 的坑
• 丟一張手繪架構圖，看 Gemini 能不能看懂

但拉遠來看，其實我一直在重複做同一件事：

觀察 AI 的反應，然後調整我跟它說話的方式。

沒有寫任何一行「正式」的程式碼，但這五天累積的東西，一點都不比寫代碼少。

二、第一個轉折：從「亂問」到「懂得設規則」

Day 03 剛開始玩提示詞的時候，我問的問題大概長這樣：

這段代碼有什麼問題？

得到的答案通常也很籠統，看完等於沒看。

到了 Day 04、Day 06，我開始學會做一件事：先講規則，再問問題。

例如指定回答格式、要求它標示「推測」而非直接下結論、給它 Few-Shot 範例當作參考答案。

同樣是 Gemini，回答品質差很多。

這五天最大的心得大概就是這句：

AI 能力很重要，但你怎麼問，同樣重要。

三、第二個轉折：模型不是萬能，是「有限但可控」

Day 05 讓我印象最深。

原本以為「上下文越長越好」，結果實測發現畫面顯示的 Token 數跟送出去真正計算的並不一樣，超標了照樣出錯。

Day 06 又補了一刀：就算 Gemini 能看懂手繪架構圖，也不代表它推測的內容一定正確。

這兩件事合起來，讓我對 AI 的看法有了一個很重要的調整：

它不是一個「無所不知」的黑盒子，而是一個有明確限制、但只要摸清楚規則就能穩定發揮的工具。

知道限制在哪裡，反而比一開始盲目相信它更有用。

四、第三個轉折：從焦慮到建立信心

老實說，開賽前最擔心的不是代碼寫不出來，而是「我技術不夠強，會不會撐不到 30 天」。

但這五天全部都在網頁上點一點、試一試，沒有環境設定地獄，也沒有半夜除錯到崩潰。

反而因為每天都有一個小小的「原來可以這樣」，慢慢把信心堆起來了。

至少到目前為止，這個策略是有效的。

五、給自己的提示詞心法小抄

趁記憶還新鮮，把這五天學到的東西整理成一份簡單的 checklist，之後寫提示詞可以直接照著檢查：

□ 有沒有清楚定義輸出格式？（不要只問「這是什麼」）
□ 有沒有給至少一個範例？（Few-Shot 比純文字說明更有效）
□ 不確定的地方，有沒有請 AI 標示「推測」而非武斷下結論？
□ 內容太長時，有沒有先確認實際 Token 用量，而不是只看畫面顯示？
□ 圖片 / 文件輸入時，有沒有明確說明「這份資料要拿來做什麼」？

這張小抄，應該會一路用到系列結束。

六、下週開始，正式動手寫代碼

免代碼的舒適圈，到今天正式結束。

明天開始，要跟網頁點擊說再見，改成用 10 行 Node.js 呼叫 Gemini API，讓 DevPulse 從「腦中的構想」變成「終端機裡真的會動的東西」。

第一週：建立信心。

第二週：開始動手。

走吧。