← 返回電子報封存

有了 AI,你的工作是變得更有趣還是開始乏味?

2026-08-14

最近在讀一本書叫做《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​

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

​

​