當 AI 可以在幾秒鐘內產生一段程式碼，真正的挑戰就從「怎麼寫」變成「要寫什麼，以及怎麼知道它是對的」。
這篇筆記提出一個可實驗的工作方式：讓 AI 參與實作，但把問題定義、技術取捨與驗證留在工程師的責任範圍內。
先定義問題，再要求程式碼
「幫我加搜尋」是一個需求方向，還不是完整的工程任務。先把讀者或使用者的情境說清楚：
- 需要搜尋哪些欄位？標題、摘要，還是文章全文？
- 搜尋結果需要能透過網址分享嗎？
- 資料量有多大？是否真的需要後端搜尋服務？
- 找不到結果時，使用者下一步可以做什麼？
越早回答這些問題，越能避免得到一個看起來完整、實際上不符合需求的功能。
清楚的上下文不是附加資訊，而是實作的一部分。
把任務縮成可以驗證的一步
與其一次要求 Agent 完成整個產品，不如把工作切成有明確邊界的小步驟。
| 階段 | 工程師提供 | AI 協助 |
|---|---|---|
| 理解 | 使用情境與限制 | 整理問題、列出缺漏 |
| 設計 | 技術取捨與驗收條件 | 提出方案與風險 |
| 實作 | 專案慣例與範圍 | 撰寫與修改程式 |
| 驗證 | 重要情境與判斷 | 執行檢查、整理差異 |
例如先完成單一分類篩選，再處理搜尋；先確定資料流，再美化介面。每一步都有可以檢查的結果，也比較容易回頭修正。
一份可重複使用的任務描述
問題：讀者難以在文章列表找到特定主題。
範圍：標題、摘要、標籤搜尋，不搜尋全文。
限制：沿用現有樣式，不增加資料庫。
驗收：搜尋與分類可以組合，網址可以分享，
無結果時有清楚的提示與重設入口。
這不是固定的 Prompt 公式，而是一份讓合作雙方理解同一個問題的簡單契約。
把驗證視為開發流程
程式碼能編譯，是開始，不是結束。
除了型別與建置檢查，也需要實際操作：空字串、中文關鍵字、沒有結果、手機螢幕，以及瀏覽器返回後的狀態。這些情境經常比理想路徑更能看出實作品質。
審查差異時，可以先問三個問題：
- 這些修改是否都與目前任務有關？
- 新的抽象與依賴是否真的必要？
- 如果 AI 沒有參與，自己能解釋這段程式嗎？
好的合作，會保留理解
AI 的價值可以是減少重複工作、協助找出盲點，或讓實驗更快開始。但工程師仍需要理解系統，才能判斷解法是否合適。
下一次使用 Coding Agent，可以先試一個小調整：在要求實作前，多寫三行背景與驗收條件。觀察來回修正的次數，以及自己是否更容易理解最後的結果。