夜深人靜，隨著 Smooth Jazz 的旋律緩緩流淌，像是在房間裡鋪上一層柔軟的夜色。正當我打開電腦，準備投入一場與程式碼的對話時，喵喵卻早一步蜷縮著身子，靜靜睡在鍵盤上，呼吸隨著樂曲起伏，像一首輕盈的伴奏。那一刻，忽然覺得，也許生活本不該只是日夜交替的 coding 與 debug，有時候，像貓一樣在琴聲與微光中沉睡，才是真正的答案。
不過身為專業邊邊（邊緣人），自然而然的拿起筆電，縮在牆角繼續奮鬥
起身去喝個水，回來就會看到這一幕...
好吧～我輸了，睡覺去ＸＤ
然而，最近出現了一種魔術，AI 不只看得懂英文，也會說中文，還會寫各種程式語言，甚至用說的下指令也行～
創作的靈感往往只有一瞬間，將想法轉成文字已經是一件很燒腦的工作（更遑論還要再畫出流程圖&架構圖），在此同時，執行程式碼主程式的時候，終端機還是會很不客氣的噴出一堆紅色的 Error...
為了儘可能地寫出優質程式碼，AI 出現之前，開始coding之前，都得先花上數個月的時間將網路上的 Docs 至少都喵過一遍。而 AI 出現之後，只要一有靈感，就可以先進入討論的流程，請 AI 先分析現實狀況，以及目前的技術面是否能實現，如果可以，再繼續下一步
最近，AI 從原先被動的 Assist 功能，提升到幫忙整理想法、直接生成程式碼、甚至幫忙想作品名稱的 Agent 地位，人們給這樣的功能取一個名子：
一種自由、療癒、創意流動的開發方式，讓程式變成創作的一部分，而不是壓力的來源。
原因其實很簡單，因為寫網頁的時候，常常會遇到一個關卡，那就是 Jinja2 這種特殊的樣板語法，對於使用 Flask、Django 等框架的開發者來說，Jinja2 幾乎是必經之路，因為它「不是純 HTML，也不是純 Python」，所以有時候調整起來特別容易踩雷。
最常見的 {% ... %}、{{ ... }}，初學時看起來很簡單，但實際應用到專案中，尤其是複雜模板或是從外部拿來的現成網頁模板時，就會發現：
寫程式本來就會遇到 bug，這是很正常的事情。問題在於，有些 bug 修起來是有價值的，例如演算法設計不合理、資料結構需要優化，這些經驗會讓我們的程式思維更上一層樓。但像 Jinja2 這種模板錯誤，大部分時候並不會帶來「知識上的突破」，而只是語法與結構的小細節。
更何況，很多人是直接套用網路上的現成模板，像是 Bootstrap 的範例頁面、商用的 HTML theme，甚至 GitHub 上別人開源的前端專案。這些模板通常功能齊全、設計漂亮，但一旦我們開始「客製化修改」，就容易掉進無止盡的坑：
當我們花太多時間在處理這些瑣碎問題時，很容易本末倒置。因為寫程式的目的並不是為了在語法裡面轉圈圈，而是為了達到優化使用者體驗（UX）的目標。
一個網站最終的價值，不在於模板語法有多乾淨，或是花了多少時間調整一個看不到的縮排錯誤，而是在於使用者能否：
如果我們把大部分的精力都投入在「修模板 bug」，而不是「思考怎麼讓 UX 更流暢」，那整個專案的方向就會偏掉。最後網站可能是「技術上很完整」，但使用者卻覺得 APP 有夠難用、UI有夠醜、畫面有夠卡...。
在 Vibe Coding 的理念下，HTML 與 Jinja2 只是一個工具。不需要為了寫 flask 前端就想說要先成為 Jinja2 大師，因為程式存在的目的，應該是服務設計，而不是反過來被技術限制。
最後筆者要強調的是：
最近鬧得沸沸揚揚的某小白分享自己用 Vibe Coding 的方式做出來的作品，結果收到 Google 的萬元帳單，還有零基礎的熱血志工，用生命做出來的網站，卻被發現有很嚴重的資安漏洞
（圖片來源：友人轉發，應該是 threads 截圖）
好的～只能說，Vibe Coding 讓任何人都可以無痛起步，但不懂資安的話，第一步可能就會摔的很痛～
（本文大部分的圖片皆由 Perplexity 協助生成）
Ref.
iThome鐵人賽
看影片追技術