今天在開發一個新功能時犯了一個錯誤，代價是一個工作天。

事情是這樣的，我們需要同時在新舊系統上實作一個新功能，舊的系統已經由同事開發完成，我只需要在新系統上實作一樣的功能就好。

在我還沒看文件前，先看了一下程式碼沒有很多，想說偷懶一下全部交給 AI 來改好了，所以我的作法是這樣：

1. 用 git diff 找出有修改的地方，讓 AI 根據變動寫成 spec。
2. 讓 AI 拆解成可以被單獨驗證的 tasks
3. 執行

一邊驗證測試一邊讓 AI 持續開發，但是驗證到某個功能的時候覺得不太對，某個功能在這次的改動應該要被移除怎麼還在，而且被改成四不像。於是回頭檢查是不是 spec 有錯，後來發現 spec 沒有明確寫到這個要被移除，而且在舊有的 contract 中有寫到這個功能，所以 AI 還是遵守 contract 把這個功能保留下來，但產出了錯誤的程式碼。

接著我嘗試了第二種作法：

1. 用 git diff 找出修改的地方，並且把變動的 before 和 after 也一起寫進 spec 文件中
2. 要求寫 code 前要先更新 contract
3. 執行

我發現這樣在實作的速度上快很多，而且產生的 spec 文件非常好讀，很快就能做一些調整後進到開發。

紀錄一下這次的 lesson learned：

1. 如果是讓 AI 先進行一次 summarize 產生的 spec 如果太過抽象，可能會漏掉細節。
2. 如果專案有用到 contract，當需求有變動時務必要更新 contract，可以把這個寫進 workflow 中避免這樣的事情。
3. 最後是提醒自己一定要把規格和文件都讀完再來實作，不然連 review AI 產生的 spec 都沒辦法看出問題。

為什麼會想讀這篇文章

在現在人人都在用 AI 加速的時代，實在很想知道別人是怎麼使用這些工具在開發的，在社群平台看到有人分享了太空人的 Kaxil 寫的文章讓我很感興趣。

文章中有段文字讓我印象深刻：

Your workflow IS your IP.

你怎麼使用 AI 工具的方式，才是你真正的競爭優勢，換句話說工具人人都能用，但能設計出高效 workflow 的人才是少數。

Take Away

1. Skills：把你的知識轉成可重複執行的指令

Skills 是一組明確的指示，告訴 AI 在特定情境下應該怎麼做，同時 Skill 可以呼叫其他 Skill，形成組合技。

這就像是把你的工作 SOP 編碼化。你只需要設計一次，之後每次執行都能得到一致的結果，不用每次都重新解釋背景和期望。

以這個部落格為例，我就設計了幾個 Skill，例如「幫文章插入封面圖」、「依照 Kevin 的寫作風格潤稿」。每個 Skill 都有明確的輸入和輸出，組合起來就能完成完整的發文流程。

2. Hooks：讓 AI 不會暴衝的護欄

這是我覺得最實用的一個概念。

在平常使用 Roo Code 開發的過程中，發現即使在 Skill 裡寫了「遇到 A 情況就要執行 B」 這樣明確的指示，AI 有時候還是會選擇忽略它，這對 AI 來說沒有強制力，如果沒有自己看程式碼檢查就不會注意到這個不該犯錯的地方。

和 Skill 不一樣的是，Hooks 是在事件觸發時，由工具本身自動執行的 shell 指令。例如：每次 AI 寫完一段 code 就自動編譯或執行測試，沒過就無法繼續，這是系統層面的護欄。

3. 不同模型，不同用途

不是每件事都要用最強的模型。以 Claude Code 為例，Kaxil 的觀察是：

• Sonnet：適合寫 code、日常任務，速度快、夠用
• Opus：適合深度規劃、架構設計，思考更全面

用 Opus 寫 code 反而容易 overengineering，AI 會想得太複雜。選對模型不只是省錢，也是在保護你的結果品質。

除了開發，Kaxil 也把 AI 整合進更多日常工作，像是自動把會議記錄寫進 Obsidian。工作流不只是 coding，而是整個知識管理和溝通流程。

對我的影響

學習到了 Hooks 的用法 (因為平常工作使用的 Roo Code 工作流沒有這個功能)。在 Skill 裡寫各種規範，但 AI 不一定會遵守，尤其在執行到一半、遇到模糊問題的時候，很容易就憑感覺自由發揮了。

這也給了我在公司開發的 side project – Roo Code CLI 一些靈感，例如實作 hooks 機制以及自動切換模型，讓整個 workflow 的可靠性會大幅提升。

讀到這段像是當頭棒喝，目前 AI 的產出速度已經超過我的 review 速度了，有時候測試跑過了就會偷懶不 review (So bad!)

Learn to review code you didn’t write. This was always important. Now it’s the whole job.

看樣子還是要認真把每一行看過。

最後複習這段我最喜歡的一句話:

Your workflow IS your IP.

這給了我一個明確的學習方向： 創造自己的工作流

參考資料

• 原文：I Haven’t Written a Line of Code in 4 Months (But I Ship More Than Ever)

今天正是電玩排毒 - 刪光電腦中所有遊戲後的第三十天，紀錄一下。

為什麼會開始電玩排毒

總是想著有好多事情想做以及學習，但是自己處於一種一放鬆就想打電動的「殭屍模式」^[1]。
在閱讀《多巴胺國度》這本書時，學習到了成癮的機制還有延後享樂的好處，就趁這個機會來實驗一下吧。

因為要讓爽痛平衡^[2]回歸正常，需要遠離刺激（對我來說就是電玩）30 天左右，加上最近太想買一顆後背包，結合這兩項的規則就變成：

• 連續 30 天不玩任何電玩，
• 如果有達成可以購買想要的背包
• 紀錄過程中的感受

其實很久之前在準備面試或讀書時就有成功戒癮，但總是會在抱持「玩一下下也無妨」的情況下再度淪陷，特別是打了一個晚上都贏不了的英雄聯盟。

這次在過程中將注意力轉去從事閱讀、嘗試寫作、修照片甚至是和小孩一起倒頭就睡。轉眼間一個月就過去了，過程中有注意到幾個身體向外尋求多巴胺的信號：

1. 想要吃一堆垃圾食物，越油越鹹越好
2. 想狂滑蝦皮或是淘寶等購物平台

這些狀況大概過了兩週後就好轉了，給想要戒除自己「毒品」的每個人一點鼓勵，撐下去就好！

現在可以自由安排自己的 Me Time，看是要閱讀還是學習都可以，累了就直接去睡覺，這樣的晚上也挺不錯的。

註解

關於這本書

逆行人生這本書是韓國一位 30 歲實現財務自由退休的作者自青寫的，書中介紹了他如何從一位外貌、收入、課業都不起眼的年輕人，蛻變成擁有諸多事業的創業家。

作者提出了一個觀念，把過人生的方法分為兩類：

1. 順理人生者： 依循命運規劃，走上理所當然之路的人，和無路之路中保羅提到的「跳圈者」有異曲同工之妙。
2. 逆行人生者： 違背命運，靠自己力量另闢路徑的人。

而這本書，就是作者給每一個想成為逆行人生者的人，最具體的行動指南。

如果只能畫一條重點

我認為我人生中做的最好的一點是實踐了「22策略」

作者認為人生要成功、達成財富自由是有攻略的，因此他根據自己從谷底翻身的經驗，為逆行人生者整理出七個人生升級的階段，從自我意識的解體，一步步走向財務自由，但所有步驟方法都是圍繞著兩件事在進行： 「閱讀」和「寫作」。

作者自己每天堅持會花兩小時閱讀以及寫作，這就是有名的「22策略」。

我認為作者的觀念非常簡單：

1

閱讀 + 寫作 -> 大腦升級 -> 有了各種解決問題的能力 -> 邁向成功

假設整本書讀完內容全忘光了，但只要記得持續做到 Input 和 Output，就能夠獲得解決問題的能力，在未知的人生中不再感到害怕。

和我的關係

老實說在 AI 的浪潮下，身為軟體工程師我感到非常害怕，害怕有天跟不上變化。但自青的這本書給了我一個努力的方向，讓我看到了不同的可能。「只要持續做到閱讀和寫作，就算是我也能獲得解決問題的能力吧」，我心理是這樣想的，希望能持續透過寫自己的部落格來訓練思考。

我們可能都聽過「注意力經濟」這個詞，可以說在這個時代誰掌握了注意力就能獲得巨大的財富。

下班了在通勤的火車上，用 Facebook 犒賞自己，滑過一則一則貼文，偶爾看看跳出來的愚蠢影片，不一會兒就回到家了。

用餐完，把孩子撂倒後終於迎來自己的小確幸時間，打開 Instagram 看看喜歡的攝影師有沒有新的作品，「喔！這則 Reels 好有趣他怎麼拍攝的？」… 回頭看時間已經一點了。

這就是每天發生在我身上的事情，白天總記掛著許多想做的事情，但回到家就把所有想法拋諸腦後。

但這其實不是我的問題，許多公司正是利用「成癮性」來綁架我們的注意力，而目的就是要透過大量的廣告獲得利益。這種系統不勝枚舉，舉凡讓人滑不停的社群平台、一直推薦優質好物的電商、贏或輸都會想來下一局的遊戲等等。

這難道不是我自己的選擇嗎？

直到某天坐在書桌前讀《多巴胺國度》，讀到每個人都有自己的「毒品」這件事，我愣了一下——原來我以為的「選擇」，只是大腦在追求多巴胺。

當經過精挑細選的貼文、短影音充斥在我眼前時，就不會注意到那些被冷落在一旁「真正想做的事」了。

因為這個時代注意力是一項很重要的資產，沒有好好留意，就會被偷走。你還記得上次在心中想著「總有一天我要學會…」嗎？

關於這本書

《多巴胺國度》(Dopamine Nation) 的作者是史丹佛大學醫學院的精神科教授安娜・蘭布克 (Anna Lembke)。安娜在這本書中透過和病患的對談，解釋了各式各樣的上癮狀況，並提供了一些治療的建議。
最重要的是，本書深入探討了「多巴胺」這個神經傳導物質如何影響我們的快樂與痛苦，以及大腦中「爽痛平衡」的機制。

如果只能畫一條重點

「愉悅與痛覺的處理現場在大腦中有重疊的地方，且這兩者知覺的運作是透過一種拮抗機制。用白話講，就是爽與痛存在彼此消長的關係。」

上面在講的就是爽痛平衡 (Pleasure and Pain Balance)。在腦中，爽與痛的感覺如同在玩一座翹翹板，在「爽」的這側下壓我們就會感到快樂，下壓的力道越大我們就越快樂。但同時，身體的平衡機制會對翹翹板的另一端「痛」下壓：這就是我們爽快地打完電動、吃完油膩炸雞後，會產生欲求不滿甚至空虛感的原因。
而大腦為了緩解這個空虛，會繼續鼓勵我們追求更多的多巴胺來往「爽」的方向壓，於是我們的遊戲一場接一場、垃圾食物一盤接一盤。

漸漸地，翹翹板開始對「爽」產生耐受性，亦即同樣的刺激已經沒辦法在「爽」這端下壓了。作者安娜用了一個生動的比喻：支點位移了。
當支點往「爽」這端靠近時，力臂變短，且相對的「痛」那端力臂變長了。這時生活中只要有一點不愉快在「痛」那端下壓，就能讓人感到巨大的痛苦與憂鬱——這就是現代人為什麼普遍不快樂的原因。

但這個機制還沒完，因為痛苦會促使人們追求更多「爽」的刺激來逃避，進而陷入了一個無窮迴圈，這就是成癮的機制。

好消息是，只要我們透過隔絕「爽」的刺激來打破這個迴圈，就能讓翹翹板自動回到當初平衡的狀態。回到平衡的狀態有許多好處：其中一個是只要一點微小的刺激就能獲得幸福感與快樂，同時也不用承受強烈的「痛」的反噬，讓我們在平常的生活中找到平靜及喜樂。

和我的關係

過去上課被教導多巴胺會帶來快樂和幸福感，但讀完這本書才知道，多巴胺只是一個神經元間的傳導物質。它會刺激腦中的獎勵路徑，讓我們在「期待」的過程中感到興奮。這完美驗證了為什麼每次下訂東西前都會很興奮，但是這種興奮感在開箱後的一天、兩天內就會迅速消散。

意識到自己沉迷於電玩，並浪費了許多寶貴的自由時間後，我決定讓大腦的平衡回到正常的狀態。我馬上把 PC 中的遊戲都刪了，展開為期 30 天的「自縛」療程，並重拾閱讀、寫作等興趣來填補這中間多巴胺的落差。

同時，了解這個原理後，我也能更客觀地檢視自己的購物上癮習慣。我現在學會透過「延遲享樂」來平衡大腦，例如把最近想買的新玩具當成是 30 天自縛成功的獎勵——不僅找回了平靜，也讓獲得獎勵時的快樂更加純粹，一舉兩得。

終於買了網域名

最近剛把網誌從 GitHub Pages 搬到 Cloudflare Pages 上，發現 Cloudflare 提供了不少好用的功能，像是自訂網域、SSL、CDN 等等甚至連 Web Analytics 都有，而且後台介面操作也很直覺，就順手把網域也一起買了（之前都習慣在 Gandi 買）。

挑了很久，喜歡的太貴，便宜的又不符合需求，尋尋覓覓終於找到一個價錢不錯又有相關性的。

開心的下單後才發現，不對啊，如果網域名直接帶了 blog 字串，那子網域的彈性就少很多 (weiblog.me)，買都買了，這一年就加減先用吧。

我是一個很容易衝動購物的人，但我沒想到連買域名都能後悔。

網域小科普：為什麼帶有特定字眼的網域不夠泛用？

前面提到我買了 weiblog.me 後突然有點後悔，原因在於這會限縮未來擴充子網域（Subdomain）時的彈性。

在購買網域時，如果我們買了一個比較中性、沒有特定含義的主網域（例如 wei.me），未來就可以依照不同服務拆分出很多直覺的子網域配置，例如：

• blog.wei.me (用來放部落格)
• api.wei.me (用來放後端 API 服務)
• shop.wei.me (用來放個人電商)
• portfolio.wei.me (用來放作品集)

但當我的主網域直接包含了 blog 這個字串（變成 weiblog.me），未來如果要架設非部落格的服務，子網域配著唸起來就會變得很奇怪：

• api.weiblog.me (部落格的 API 嗎？)
• shop.weiblog.me (在部落格周邊商店？)

如果域名帶有特定用途的字眼，就很容易被綁死。在選購網域時，最好先思考一下未來有沒有擴充其他類型服務的可能。如果只打算拿來寫文章，那買帶有 blog 的網域當然沒問題；但如果考慮到未來想在同一個主網域下掛載各式各樣的 side project 或服務，一個乾淨、中性的名字會是更好的選擇。

OAuth 2.0 的四種核心角色

在了解 OAuth 2.0 的運作之前，我們需要先認識參與其中的四個關鍵角色：

1. Resource Owner (資源擁有者)：通常就是指「使用者本人」。使用者擁有那些客戶端準備代為存取的受保護資源。
2. Resource Server (資源伺服器)：實際裝載並保管使用者受保護資源的地方。
3. Client (用戶端 / 第三方應用程式)：代替使用者去存取受保護資源的應用程式。
4. Authorization Server (授權伺服器)：負責驗證使用者的身分與授權意願，並核發 Token 給第三方應用程式的伺服器。

OAuth 2.0 的基本運作流程

OAuth 的核心精神在於透過授權碼與 Token 交換權限，一個最標準的基本流程可以拆解為以下四個步驟：

• 步驟 A：使用者在 Authorization Server 進行登入，並同意授權給 Client。
• 步驟 B：Authorization Server 確認授權後，回傳一組授權碼 (Authorization Code) 給 Client。
• 步驟 C：Client 拿著這組授權碼，去向 Authorization Server 換取 Access Token (存取權杖)。
• 步驟 D：Client 拿著 Access Token，正式向 Resource Server 請求並取得受保護的資料。

四種常見的授權模式 (Authorization Grants)

根據不同的應用場景需求，OAuth 2.0 定義了四種授權模式。這些模式實際上都是基於上述的「基本流程」進行適當的微調或刪減而來：

1. Authorization Code (授權碼模式)
2. Implicit (隱式授權模式)
3. Client Credentials (用戶端憑證模式)
4. Resource Owner Password Credentials (使用者密碼模式)

1. Authorization Code (授權碼模式)

這是最常見、也是安全性最高的模式。它的流程就是完整走完上述基本流程的 A 到 D 步驟。

在這個模式中，回傳的「授權碼」本身並不能直接用來存取資源，而且它的有效期限極短。Client 必須在後端伺服器拿著這個授權碼去 Authorization Server 換取 Access Token，才能真正去存取目標資源。這樣的設計能確保 Access Token 不會在瀏覽器或前端外洩。

下面來看一個我們最常見的例子：

2. Implicit Grant (隱式授權模式)

這個模式跳過了「用授權碼換 Access Token」的步驟 (即跳過步驟 C)。

當使用者同意授權後，Authorization Server 會直接把 Access Token 放在網址中回傳。這個模式通常應用於沒有後端的 SPA (Single-Page Application) 單頁式應用程式，讓前端可以直接拿著 Access Token 去呼叫 API。

因為 Access Token 在交換過程中會直接暴露在 URL 中，這個方法非常不安全，在現代的開發中已經不被推薦使用。甚至在 OAuth 2.1 中已經被棄用。

3. Client Credentials (用戶端憑證模式)

這個模式跳過了需要使用者參與的步驟 A 與 B。

在這種情境下，Client 自己本身就是資源擁有者。Client 擁有一組自己的 Secret Key，它可以直接拿著這組 Key 去向 Authorization Server 證明自己的身分，並直接換取 Access Token。通常用於內部微服務或伺服器對伺服器 (M2M) 的 API 溝通。

4. Resource Owner Password Credentials (使用者密碼模式)

這個模式同樣跳過了步驟 A 與 B。

作法是讓使用者直接把帳號密碼交給 Client，然後讓 Client 在步驟 C 拿著使用者的帳號密碼去向 Authorization Server 取得 Access Token。

這個作法也就是把密碼完全交付給了第三方，極度不安全，所以只能用在「絕對可信任」的 Client 上，例如作業系統內建的 App 或公司自家的內部應用系統。

Summary

OAuth 2.0 是一個規範，主要用來解決如何在不給出密碼的情況下，安全地讓第三方應用程式可以存取使用者在某個服務上的資源。共有四種不同模式，其中最常被應用也是最安全的為授權碼模式。

最後補充一點，包含我自己，很多人會把 OAuth 和 SSO 搞混，以為看到授權頁面就是在做登入。這其實只對了一半：SSO 通常會搭配 OIDC (OpenID Connect) 來達到「認證 (Authentication)」及「授權 (Authorization)」，而 OAuth 這個機制本身，嚴格來說只負責處理**「授權」**的部分，像是授權第三方應用存取使用者的 FB 大頭照、信箱等等。

Reference

1. RFC6749
2. Microsoft Learn

閱讀、閱讀、閱讀

目前的閱讀習慣是紙本書和電子書雙管齊下。能帶紙本就帶紙本，出門則拎著 Kobo Sage，利用零碎時間繼續閱讀。在看了《逆行人生》這本書後，我為自己建立了一個「只要有空檔就閱讀」的習慣，期望能放大輸入的資訊量。

於是我開始物色可以放進口袋的電子閱讀器。正好 Kobo 就有一台 Clara —— 六吋的螢幕、可一手掌握，還能輕鬆塞進口袋，各方面都滿足我的需求；而且它有漂亮的白色版，還是彩色的。下訂的當下沒想太多，單純覺得彩色螢幕用起來應該只會更爽吧。

Clara Colour vs Sage

在網路上下訂後，很快就拿到實機了。拆封、開機、登入帳號，我熟練地操作著 Clara Colour，將正在閱讀的書都準備好。快速瀏覽了幾頁，使用上很順暢，UI/UX 和手上的 Kobo Sage 相同，主要只差在螢幕大小和有無實體按鍵。讓人印象深刻的是，彩色的書封非常賞心悅目。

快速地和我的 Kobo Sage 作個比較：

• 螢幕與尺寸：Clara 是六吋彩色，Sage 是八吋黑白。
• 手感與操作：Clara 裸機的握感非常好，翻頁主要透過點擊和滑動；Sage 則有實體按鍵，操作起來非常方便。
• 螢幕設計：Sage 的螢幕和機身是全平面的，手指滑動到邊界時沒有段落感；而 Clara 的螢幕則是稍微下凹的。除了手感差異，還有美觀考量 - 同樣是六吋的機器，我覺得 Kindle Paperwhite 的全平面設計更勝一籌。
• 額外功能：Sage 支援觸控筆寫字劃線，Clara 則無此功能。
• 亮度與對比：Clara Colour 的彩色螢幕亮度偏暗，即使在陽光下也必須開啟背光才能閱讀；相比之下，黑白的 Sage 在戶外陽光下對比度極高，字體清晰，讀起來非常舒服。

我真的讀不下去了

然而，就在我看了大約五分鐘後，眼睛開始感到刺痛，竟然連一頁都無法再看下去。起初我以為是今天太累或用眼過度，便先去吃飯、洗澡，稍作休息後再次坐回書桌前閱讀。但同樣看了幾頁，又開始感到頭暈和眼睛痠痛。

我開始懷疑是不是自己身體出了什麼狀況，於是跑到 Reddit 和臉書社團爬文。後來才得知，彩色螢幕因為多了一層彩色濾光片，不僅會降低螢幕亮度，也會讓文字的對比度下降。在我的眼裡，Clara Colour 的文字看起來真的是模糊的，越看越疲勞、越看越刺痛。我試過網友提供的各種方法：調整色溫、改變字型、調整字體間距等，但還是無法讓我連續閱讀超過三分鐘。

最後只好忍痛退貨，並重新訂了一台黑白版的 Clara BW。

回歸純粹：Clara BW

收到 Clara BW 後，可以說沒有什麼新鮮感，因為這完全符合我的預期，有一種「老朋友回歸」的踏實感。輕巧的手感、高對比度的清晰顯示，丟進口袋就能隨時帶出門。

其他同事使用 Kobo Libra Colour 都非常開心，整天閱讀下來也沒有出現像我這樣的症狀，看來單純是我的眼睛與 Kobo 的彩色螢幕不對盤。

針對我目前閱讀純文字書籍的需求來說，黑白螢幕還是最合適的選擇，看一整天也不容易累。至於彩色閱讀器只好期待電子墨水技術能持續進步，希望未來有一天，我也能入手一台漂亮白色 Kobo 閱讀器。