最近在讀一本書叫做《Vibe Coding 聖經》，在現在 AI 相關的書籍多到爆炸的狀況下，很容易就覺得這只是另外一本在教人用 AI 寫 Code 的過時書籍而略過，但讓我眼睛一亮的是本書的其中一位共同作者 Gene Kim 是我超愛的一本軟體專案管理小說神作《鳳凰專案》的作者，他與另一位骨灰級工程師合著，因此二話不說就立刻買回來看。

這本書是 2025 年中出版的。在那個時間點，Vibe Coding 的說法剛出來不久，所以第一章的篇幅著墨在說服還沒有嘗試過 Vibe Coding 的工程師來實際體驗看看，書中舉了很多矽谷創業圈的例子來佐證，證明 Vibe Coding 是真的會改變軟體設計的一種典範轉移。

Kim 也提到有很多早就因為寫不下去程式碼而離開這個產業的工程師，因為這一波 Vibe Coding 的浪潮又重新找回軟體開發的樂趣，其中就包含他自己。他的本業是協助企業來如何透過 IT 來管理企業，而《鳳凰專案》這本書在講的就是這個的主題。

《Vibe Coding 聖經》提到 AI 協作開發把工程師最討厭的瑣事像是除錯、寫測試、部署流程全部都外包給 AI，自己就可以專注在軟體設計並發揮創意，重拾透過程式碼進行創作的樂趣。這讓我開始回想在我的職業中，寫程式的樂趣從何而來。

我很喜歡打電動，尤其是角色扮演遊戲。從主角踏入一個完全陌生的世界開始，然後遊戲設計師設計各種能夠與這個世界互動的方式，讓你自行探索並學習在這個世界中的各種行為，看著這個世界的物理機制與環境設計，就會產生第一層的樂趣：新奇。

當我知道這個世界是如何運作之後，挑戰就會接踵而來。這些挑戰會根據主角目前自身狀態適時地出現，並會指引你用你剛剛學會的技能來嘗試這些挑戰，等到克服挑戰後，就會產生第二層次的樂趣：實作。

接下來打完小怪後就會出現大魔王，大魔王的戰鬥比較久，而且所需要用到的技能會更多，要把學到的技能組合運用，並且透過觀察與試錯，進而瞭解魔王的弱點，根據弱點重複攻擊，等到第一次打敗大魔王，就會產生第三層次的樂趣：成就。

套用到我工程師的職涯完全是一模一樣的：

新奇：接觸到新技術時理解它的世界觀與設計哲學

實作：透過個人專案來磨練新的技術

成就：一次又一次拿這技術完成複雜的專案

在遊戲的世界中，魔王會越來越強，需要花時間練功，甚至需要強大的耐心，才有辦法完成更難的關卡，但在真實世界中，很少會像遊戲的世界這麼有規律，複雜的專案不一定有機會輪到我負責，或是因為要生活，即使我都已經練到 LV.99 了，有時候還是必須要回到新手村去打小怪，慢慢的樂趣來源就沒了。

再加上 AI 的發展，說得極端一點，AI 讓我不用再花時間去實作磨練技術，面對複雜的專案我要做的就是叫 AI 自己去查文件，然後把需求與規格整理好，剩下的也是叫 AI 自己去根據規格實作。

這就像是如果我玩一款遊戲先叫 AI 去幫我網路上查攻略，知道該怎麼拿到最強的武器，或知道哪裡可以刷經驗值來自動練功，練完之後自動去打怪與魔王，再透過掉下來的寶物讓角色變強，我也不需要理解這世界是怎麼運作就能變強，想當然這樣的遊戲完全沒有樂趣可言。

我第一次進行 Vibe Coding 時興奮到不行，可以一句話就完成複雜的使用者介面與前後端邏輯時實在太震驚了，但這種興奮既不是新奇、實作或是成就帶來的，而是短時間的刺激帶來的爽快，它沒有辦法持續太久，就像我現在看到 AI 只花五分鐘寫出我需要五天才能搞定的功能時，我一點感覺都沒有。

加上現在整個開發圈的主流就是要如何讓 AI 寫出更安全且有效率的程式碼，套用到遊戲的世界，玩家變成是要負責的是讓 AI 找到正確的攻略本，並且要從旁監督它的打怪路線是否最有效率，要這樣玩遊戲我寧願關機不玩。

但真實世界沒辦法，不玩我就活不下去，依照新奇、實作、成就這三個樂趣來源的條件，AI 開發要重新變得有趣，只能換一款遊戲玩，把破關條件放在 AI 無法干涉的情況，像是遊戲全破不是要靠戰鬥打敗最後大魔王，而是…

所以有了 AI，你的工作是變得更有趣還是開始乏味呢？

一對一教學實戰

這週完成了一場線上一對一 AI 架站教學的課程，我們採用的環境是 Google Meet 搭配 Claude 桌面應用程式，考量到學生的程度，要選擇最容易讓他上手的工具，並且設計好基礎設施，能透過自然語言就架好網站。

由於課程只有 2 小時，所以我在課前已經先用 Claude Design 把上課要用到的 Demo 先設計好，然後在本機開 WP，用 Claude Code 接手 Claude Design 的設計物做成 WordPress Block Theme，最後部署到 InstaWP 的主機做教學。

在實際授課時只要教會學生怎麼把 MCP 的網址貼到 Claude Desktop 的 Connector 設定裡面，接下來就是可以透過自然語言來修改網站文案與新增文章。但實作時踩到一個雷，在上傳圖片時因為 Claude Desktop 讀的不是圖片路徑，而是用二進制的轉換。

然後 InstaWP 的 MCP 對於上傳檔案的參數只提供網址或是二進制的字串，導致花費了超多時間在上傳一張圖片，然後二進制的字串因為太長，讓 Claude Code 一直轉換錯誤，所以當在示範上傳圖片就能替換首頁 Banner 的環節就無法成功。

另外一個問題是 InstaWP MCP 對於檔案編輯的方式是整個替換，如果今天要修改的檔案沒有太多的內容就還好，但如果是超過兩三千行的程式碼，這樣的替換方式就會非常吃 token 而且沒有效率。

相關的經過與解決方法我整理在這篇文章：https://oberonlai.blog/mcp-limitations-binary-files/​

鐵人賽三分之一完賽

三十天的挑戰已經完成三分之一了，差不多把概念說明完畢，準備進入技術細節的實作，由於最近的案子我都全面採用 Block Theme 來處理，時常發現到 AI 還是會用傳統佈景主題的做法把東西塞在 functions.php 跟 style.css 裡面，剛好可以趁機來更新一下該怎麼跟 AI 溝通的部分～

​https://ithelp.ithome.com.tw/users/20133765/ironman/9139​

如何讓 AI 的回覆內容更容易理解

當 Claude Code 越用越多，就越常發現自己看不懂它到底在幹嘛，我的做法就是請它把它完成這個功能的經過，用白話文的方式幫我寫成一篇文章，我再從文章之中去理解他做了哪些事情。

但由於要寫成文章，勢必要讓人家可以看得懂，所以都會儘量以淺顯易懂的角度去撰寫。但往往很多東西太過簡化之後，在學習上就會忽略很多關鍵的細節，下次遇到相同的問題時，我還是無法看懂它到底在幹嘛。

剛好在社群上面看到原來 Claude Code 有內建 Output Style 這個設定，你可以跟他講說你希望以什麼樣的方式來回答你的問題，可以設定成「解釋給五歲小孩聽得懂的內容」，或者是「它解釋一半，剩下要讓自己嘗試」的回覆模式。

真心覺得這功能很不錯，但突然想到 AI 會把每一次的回覆也作為上下文，如果它的回覆內容都是被簡化過的結果，那會不會跟我自己在整理成文章一樣，反而會讓 AI 對於這個專案的理解程度趨於淺薄？

最後思考的結果，我覺得我應該還是會傾向於讓 AI 保有原始的回答風格，然後用斜線 /btw 的模式，去詢問它剛剛的回覆結果是什麼。/btw 這個指令很實用，它可以不佔據上下文空間直接回答你對它提出的問題。所以我覺得用這個方法來進行理解跟學習，好像比較不容易干涉到既有的上下文。

關於 /btw 的用法可以參考這篇文章：https://www.aidenlin.dev/blog/claude-code-context-hygiene-btw-fork-rewind​

( 很喜歡這個網站是用貓咪來當作閱讀進度條XD )

本週小結

近期有一些新的計劃想要嘗試，但前提是要放下舊有的累積，還不太確定這個比例該如何拿捏，以及要跟過去的自己說再見真的很不容易…

本週主題你有想聊的話可以加入社群，很想聽看看你是怎麼用 AI 讓工作變有趣，或是也跟我一樣開始有一點乏味感，歡迎加入 AI x 自由工作者社群：

​https://line.me/ti/g2/smnoz5XJSIj6gY9sixYG_jagOCdGh8nb7hijRw​

以上就是本週電子報的所有內容，我們下週見！😃