第二次嘗試 Vibe Coding 後的一些雜感
tl;dr
第二次小小嘗試了 vibe coding，成品如下，請勿認真檢視
前言
一時之間從某處取得了一個小玩具的靈感，本來打算動手挑戰看看，後來想下是個再次嘗試 vibe coding 或 AI assist 的機會。
一直以來都對 AI 在程式方面的各種應用很冷感，雖然是蠻排斥這股風潮的，但我從來都不否認 AI 在這方面確實能帶來前所未有的助益，既然如此我為什麼還是興趣缺缺？
純粹是出於動手親自一行一行寫出來的過程是充滿樂趣（以及挫折）的想法，這正是我認為寫程式最有意思的部份，沒什麼交給其他人代勞的理由。
先前曾經在一個極小且完全確定我手刻要怎麼辦的小小小測試程式上嘗試過，那時就有稍微改觀過，確認到其實並沒有那麼排斥這種做法，但也不特別喜愛，而且看起來可維護性或說永續性有點… 不樂觀？當時是用 vscode 免錢的 Copilot 搭配 GPT-5 mini。
連平常的網頁聊天提問一個禮拜都不見得會用上一次，但還是有訂閱 ChatGPT Plus，畢竟免費仔真的是稍微有真正的需求立刻就會不夠用，況且還不是程式這類的一般人需求。加上我完全認同 LLM 在語言方面的表現，之前預訂新琴的日文 email 都靠他了。
加上近期總算是比較積極去了解一些現在 AI 相關生態、工具的概念，便利用這個機會來稍微更深入的摸索下 Codex CLI。
正題
需求背景說明
先來解釋下我想做的是什麼樣的小玩具，沒什麼難度也冷門的東西，搞不好早就有人做過但我也懶得去找了，反正我就是想藉機玩玩看。
簡訊這東西是論則計費的，有點年紀的人大概會知道，一則簡訊有其文字長度上限，若超過會再追加一則來容納，早年似乎甚至要自己切分，後來自動分割寄送、接收端自動合併似乎已經很普遍。
還需要前情提要一件事情是近年詐騙猖獗，公司行號若想要大量發送含有網址連結的簡訊內容，是需要事先和簡訊商申請網域白名單的，只能以白名單內的網域網址發送，否則會被系統阻擋。
現在有同樣內容的簡訊，有的號碼發送成功也有的失敗，推測原因在於不同的電信商遇到超過長度被切開的簡訊內容採取的掃瞄手段有差異而致，或許有的聰明點會合在一起看，有的比較懶就是切開來個別單獨看，那麼要是簡訊的連結正好在網域的部份被切開，或許就有可能導致被認為發送一個不在白名單內的網域的網址。
而我想到的輔助解方，就是搞個網頁小工具從視覺上提示訊息哪些部份會在第一則內，哪些會跑進下一則之類的，讓撰寫文案的人知道有被切分的可能，進而修改內文，看是要填充空格換行或是乾脆改寫，來避免踩上這顆地雷。
雖然老實說這年頭了還堅持要用簡訊根本莫名其妙，尤其是硬要塞網址在裡面…
不過不管那麼多，就是給我找到了一個小題目。
實際操作過程
確立了目標，動手前我就有稍微想過親自來的話會怎麼做，然後以此為出發點參考，去思考要如何運用 Codex 來替我達成。
於是打開了 Codex CLI，使用的是預設的模型 gpt-5.2-codex medium，建立了專案目錄，先幫他裝好我認為可能會用上的 lodash，寫了一份小需求文件 markdown，請他看一下，問他這樣能不能幫我做出來，或是有沒有什麼需要補充的？
Codex 很爽快的回答沒問題，但我沒有立刻讓他動手，而是先和他確認實作細節，像是如何分辨一個字會佔用幾個字元的額度（在我印象中一封簡訊是 70 個字，我人比較老以前傳得多…），也是這時候才想要更明確或者說去查明簡訊的行規，在這兩三句來回中馬上幫我把原本超級粗糙只打算 70 bytes 為分割單位的想法給完善且貼近現實許多，原來簡訊長度計算不是單看 bytes 而是有另外的編碼規則，來自大手簡訊商的 Twilio 的相關說明我放進最後的參考資料，專案的小需求文件裡也有放。
要不了幾分鐘立刻就生出了一個非常像樣也滿足需求的原型，是早就聽聞各種吹捧，但是親自來體驗仍然有些震撼，儘管只是一個小到不行，js 也不出 100 行的小玩意依舊如此。
後續就是我逐一去了解生出來的內容在幹嘛，有些也是直接問他那麼寫的用意。
既然被我稱作原型就說明還有很多值得加強、完善的地方，後頭密集地請他完成，我很少有親自介入的部份，想看他能做到什麼程度，當然有些很小條的還是乾脆自己動手比較快，有些問題光用講的他似乎無法理解問題出在哪，即便我有信心不是我描述不到位，然而圖片終究勝過千言萬語，有兩三次這種情況都是截圖給他看過就即刻得到解決了。
個人粗略心得淺見
先聲明，我的前端能力自認應該是連 AI 浪潮掀起前的轉職班出身一年經驗的前端工程師都不如的程度，所以一些關於做法上的心得看法或許外行到令人看不下去。
- 生原型超級迅速，處理方法，或者貼金一點叫演算法，和我原先規劃的幾乎一模一樣，可能是需求真的太沒什麼，所以解決方法也就這樣了。
- 衍生的修改調整，特別是請他拿掉一些東西，他很容易會真的只拿掉那樣東西，用來容納他的元素或相關的隨著其消失而跟著失去意義的東西例如樣式，他不太會考慮進去也一起順便拿掉。有幾分像是拿翹的老害養老員工的做事態度，我不是說給我的感覺像，是成果上來看蠻像，好像沒什麼眼界不會多深入思考又懶惰的員工會做的事的感覺。
- 有時提新的改動需求給他，他又超級善解人意，連自己都沒想到的部份都幫你想出來了，並且非常切中要害。
- 最初的原型還算乾淨，一旦開始追加功能以後，就像我說的很容易留髒東西，要是都不管的話，應該不出多久就會完全無法給人看，他自己也越來越難改得動吧，所以我中間還有停下來叫他重新檢視下有沒有已經變廢物可以清理掉的東西，有清出一些但我沒有很認真的親身下來檢查個徹底。
- 後來想加上授權條款，我大致挑了下想用 GPLv3，然後問他我的相依是否能夠相容這個授權，這方面我真的是大外行，Codex 給我的回答是需要一路追到底才有辦法知道，請他看了以後他的第一個想法竟然是自己寫 js 整個跑過，看起來是蠻誇張的，我立刻說不要，能不能用現成的工具，跑了出錯我就先放置了，但他想要自幹的心態真的是有點常冒出來。像是我中間想導入 astro，看起來他對這個 framework 的理解似乎不是很深，可能不夠熱門的緣故吧，他有些理解和文件是有出入的。另外 lodash 的部份他竟然說打算乾脆自己把 debounce 的部份做進來，我也是回絕他這個建議。astro 這邊就有稍微多一點是我自己來的，說到底也是沒有多少啦。
- 後來有個以其前後是否有相鄰元素來決定樣式的需求，我心理有個想法，正好看他會不會用和我預想的一樣的方式實現，想不到他竟然選擇用 js 來處理，這似乎是蠻舊時代的做法，用 css 的 has() 及 + 來達成應該已經蠻普遍了才對？而且個人認為這樣更好理解，這種純粹 presentation 的東西寫在原本就不多又不太複雜的邏輯內對我來說也略嫌噁心。不過我跟他說應該可以用 has() 和 + 來做吧？他馬上就用如我預想的方式做到了。類似的情況還有一兩個，一時想不起來。
- 對於樣式的小細節調整，例如對齊，有時候會講很多遍都改不好，我有相當的信心確定不是我語表能力有問題，總之還是轉個彎，截圖給他看，通常都是圖一給就能馬上修好了，好像不能完全怪他，畢竟我沒有給他任何測試手段，所以他等同是在盲寫。有時候這種問題，我會先看看 code 並用 dev tools 查找下大概是什麼原因，然後告訴他說不定問題出在這，這種情況效率確實蠻好的。
- cli 版本的廢話非常少不會油腔滑調動不動就想捧人，也相對不會自作主張非常多，這點在上次使用時加上摸 Gemini CLI 的時候就隱約有察覺，現在更是完全確信。這回唯一的自作主張只有預覽框的統計資訊，這個我沒想到，但的確是我會想要的，還不賴。
結論
成效出乎我預料的好，無怪乎完全不會寫程式的傢伙們各個興奮度更勝興奮哥，不過我也只是用於這般小小小玩具上，不曉得在真正的大專案及至渾身是病的畸形老害專案上效果如何，後者的話有嘗試請 Gemini CLI (當時用免費仔配的 Gemini 2.5) 幫忙翻看盤點整理某一段的 DB 操作過，覺得有些許幫助。
我會認為這和大家現在說的純手工屬於不同型態的做事方式，要有一個測試用原型，靠 vibe coding 毫無疑問是極具速度優勢的，一旦需要開始完善並在其上追加功能的話，有明顯感受到能熟練使用 IDE 並且已有腦內藍圖的話，vibe coding 便沒有快上那麼多了，越小的改動越不具備，然而在精雕細琢的過程往往就是多次細微的修改調整。
此外遇上預期外的結果或錯誤的時候，自身對正在雕塑的整體不熟悉沒掌握的話，全靠 AI 來修正，效率很可能會嚴重低下，先承認從中間開始我就沒有很仔細地檢視他幫我生的 html 和 css 了，一是量大，二是這種表現層的部份真的是相對枯燥，也正是我會想交由 AI 代勞的部份，前述對不齊之類的問題反應三番兩次還是改不到位的時候親自下去看就會花上較多的時間，看別人的 code 從來都不是見簡單迅速的事。反觀若是自己正在密集調改的專案程式的話，看出問題大概在哪、要上哪修正都只是一瞬的事情。
html, css 是偷懶了，但主要功能邏輯的 js 部份我都會先搞明白才接受修改並往後推進。
所以說對成品的掌握度是一個顯而意見的區別，這便導出了我的外行結論：vibe coding 可以迅速的產生會動的成品，即刻帶來高度的做出了些什麼東西的成就感；手工則是因對成品瞭若指掌能自然產生安全感，在製作過程中靠著學習，應用了原先不具備的技能或早先不知道的知識，還有碰壁親手解決所獲得的成長喜悅，綜上再結合成踏實感。
日前我是絲毫沒有嘗試此般方法的念頭，嚴正鄙視正統 vibe coding（正統的定義私以為是真的完全不看產出的 code，純靠 monkey test 驗收、回饋後續修正方向，會去看產出的內容，知道自己在幹嘛的就不能算正統 vibe coding），後來 vibe coding 這個詞彙的定義似乎越來越寬鬆，好像只要不是在 IDE 上的輔助就算數，界線逐漸模糊。
經過又一次輕度嘗試，改觀了不少，未來我會更樂於、更積極的在有需要進行相關工作的時候優先使用看看。
不得不說前端或 app 這種介面類的差事真的很適合交給 AI，可以像個慣老闆一樣吹毛求疪瘋狂要求調整，馬上就能驗收。
本次的簡短摸索也讓我蠻肯定要是真的全靠 vibe 只提需求和修改其他都不管的話，那麼程式三兩下就會失控到完全不可讀的程度，至於 AI 能否繼續在其上有效作業，不看好，出錯率跟奇妙的 bug 多半也會跟著大幅增加我猜。
我已經有見識到沒有全盤考慮進去只針對提問局部修，讓 css specificity 造成他改了兩三遍還是改不對的問題了，看起來應該都要錯到一定次數後他才會把考慮進去的範圍擴大。
後記
小玩具做完，想要回頭好好了解業界相關規範，去細讀當初查到的 Twilio 說明網頁，才發現果然已經有更進階的工具 Messaging Segment Calculator 存在，不過即便當初就知道有還是會以同樣的題目來試試啦。
此外關於技術上的決定，可能某些部份會令人感到莫名其妙，最直接的原因還是我學藝不精，列出幾個我認為可能會讓人問號的：
- 用 astro 純粹是我還不會用 vite 之類的打包工具，加上前陣子才開始學 astro，就直接套上來利用他的打包效果了。
- 事後去摸了下 Twilio 的那個工具，才發現我很可能對簡訊編碼的相關細節理解太淺，因此預覽的效果說不定會和實際的簡訊有出入，真有這個問題的話全是我對相關規格不夠了解，而以不正確的規格進行實作導致，不是 AI 的問題，做出來的有滿足我訂的規格。