權衡

在 DAY 45 和 DAY 46，我們提到將繁瑣的規則交給 Linter 處理，但實際上不可能完全不提及任何規則。原因是若缺乏規則撰寫，AI 便無法生成 Gherkin 語法以外的用法，畢竟巧婦難為無米之炊。我們需要在 prompt 中釐清我們定義的 VAR-System, CAS-System 以及 TIME-System 的符號意義及其使用方式，最簡易版的說明，最好舉一個範例，讓 AI 知道實際用起來如何，而我們能省下的，主要是關於合法與否的細部規範，這部分才交由 Linter 去把關，我們這麼做能的到效果是省下了幾十或是上百個例子所佔用的 context window，所以我們最好挑選一個比較有代表性的，提升最後的產出品質。

Prompt 之所以能成為資產，是因為經過我們反覆測試後，它符合了我們的預期。由於每個人的期望不同，別人的 Prompt 未必適合你。因為這並非微調模型（Fine-tune Model，通常需要 10 萬筆以上的資料），我們能做的就是不斷反覆迭代並優化我們的 Prompt，這也是我們最接近 Prompt Engineering 的方式。

順便分享一個額外的心得：所謂的規格驅動開發仍有其極限。像我之前嘗試網路爬蟲相關的專案時，其實還不清楚該如何實作，這有時會影響到架構設計。AI 目前仍扮演著工人的角色，若非常見問題，還是需要設計師來評估合理性。也就是說，利用規格驅動讓每一步都變得簡單可行（Baby steps）的前提，是我們已經預先規劃好路徑；對於未知實作案例的流程，目前的技術還無法一步到位。目前我只有一個模糊的方向，等實際有了明確方向後再來分享。

最後在這裡跟大家說聲新年快樂，除夕夜還在花時間逛社群媒體？Get a life！ 或是加入我一起進行 100 天挑戰，就沒有任何藉口了。