好用工具帶來的省思

今天看到一個叫 Ponytail 的開源專案，在社群中有人大量分享。這個專案的起源蠻有趣的，也正中許多人在用 AI 的痛點。雖然現在 AI 在程式實作上，基本能做出各種想得到的功能，但往往會把 5 行能解決的問題，硬是用 500 行的方式來寫。

而 Ponytail 的作者正是因為受不了，於是做了一個簡單的插件，在 AI 代理運行時，提醒 AI 代理不要再用這種既燒 tokens，又讓維護理解成本變高的方式來實作程式。

PonyTail 這個開源專案，會提醒 AI 代理「不寫程式碼是最容易維護的程式碼」。在實測多種情境下 (例如電子郵件驗證器的實作、限流器的實作等)，使用 Ponytail 讓 AI 代理花費 tokens 數下降超過四成，完成速度提高 3 到 6 倍。

要睡覺之前在臉書刷到這篇文章，一時間覺得很不錯
靠AI寫程式的過程中，時常會遇到繞一大圈才解決自己的問題
在這個token=成本的背景下
如果可以有一個「不繞路」又省錢的工具，那真的是再好不過
抱著這樣的想法，我開始研究起要怎麼把這個開源專案運用到自己Vibe Coding的過程中

直到我看到另一篇文章

Ponytail 做的就是把日常中懶到極致的工程師形象變成一個 Skill
作者還幫這個 Skill 設定了一個形象：那個會默默存在於每間公司(並沒有)的綁著馬尾＋戴著橢圓眼鏡的資深工程師，情境是你丟給他 50 行程式碼，他什麼都不說，只是默默的把冗長的程式碼改成 1 行，而且還能正常運作

這種設計乍看是爽到工程師，但我覺得還是要視情況使用，雖然它提醒了我們一個不爭的事實，就是 AI 很愛幫我們多做很多有的沒的，但另一方面，設計師 / 產品、甚至前端本身，可能會有的疑惑是，他優化的方向是使用者真正想要的體驗嗎？

重點回到規劃跟需求，如果今天需求沒寫清楚， ponytail 就會走最短的路徑去優化，可能會產生三個問題：
1. 使用者不明說微互動、動態效果，只期待 AI 自己給出來，這樣的需求就會被當成沒必要而被忽略
2. 那些 loading、錯誤訊息、各種邊界狀況，透過 ponytail 可能只會做一個剛好能用的版本，不會把體驗打磨得很細
3. 同上，各種狀態切換、少見但會發生的情境、還有之後要怎麼擴充… 等等，可能有不會包含在實作內

看到這段文字的時候，我才發現自己的想法根本是本末倒置
完全不懂程式設計的我，透過AI才能寫出自己需要的程式
這過程中除了與AI溝通功能、撰寫spec規格書之外
有更多時候在腳本運行起來之後，才發現AI額外添加功能，讓腳本運行起來更符合使用邏輯
而且這些額外功能都是自己在規劃的時候忽略的部份

作為一個程式寫作門外漢，根本無法知道該怎麼架構自己的程式
也不會知道程式寫作的時候需要設置那些規格
剛開始接觸Vibe Coding的時候，那些大大們不斷提醒Spec的重要性
強調只要能寫出好的Spec，自然就可以有好的程式

但實際接觸之後，才發現門外漢哪能寫出好的Spec
能清楚描述自己的需求就很了不起了
Vide Coding的過程，門外漢能做的就是 「Try and error」
在不斷的摸索中找出解決的方式
其中就享受到很多AI帶來的「貼心」服務
打磨出原本自己沒有設想到的精緻體驗

其實內心還是希望自己可以寫出精簡、好用的程式
所以看到Ponytail這個專案才會想要研究
但根本忽略自己沒有實力寫出好的Spec，使用這個專案結果很可能是弄巧成拙

想到自己在塔羅牌占卜的過程中，也常遇到陷入同樣陷阱的案主
發現了好東西便急忙想投入，一股腦兒鑽進去
但是卻沒有考慮自己是否有足夠的能力去使用
或是沒有靜下心來思考自己的真正需求
還好這些盲點都能靠著塔羅牌的牌陣看出端倪
讓占卜師可以提醒案主，回歸到問題最基礎的癥結