「地」是我非常喜歡的一部作品，動畫作得很不錯，OP 和 ED 也選得很好，每次聽到 「何度でも…何度でも叫ぶ…」 心裡都會回想起前一集的震撼，搭配音樂一起看下去吧！

作品中透過不同的角色產生很多哲學性的對話，探討不同層面的問題例如什麼是知性、什麼是信念等等。其中最讓我有共鳴的一段對話出自動畫第十七集，叔叔在河邊對杜拉卡講的話：

考えろ。そのために文字を学べ、本を読め。物知りになるためじゃないぞ、考えるためだ。
思考。為此，要學習文字、讀書。這不是為了要博學多聞，而是為了學會思考。

一見無関係な情報と情報の間に関わりを見つけ出せ。ただの情報を使える知識に変えるんだ。その過程に知性が宿る
從乍看毫無關係的資訊中，找出其中的關連性，將單純的資訊轉變為可用的知識，在這些過程中，就能累積知性

這段從一個配角口中說出來的話一字一句的打動了我，他傳遞了一個重要的觀念：

讀書是為了讓我們思考

我覺得他說得很好，比起博學多聞，閱讀和寫作是最能刺激思考的兩件事，這在不同的書中已經多次被不同的作者提及，特別是在連思考都能外包的 AI 世代，持續保持思考我覺得是一項需要被注意的全民運動。

雖然有點胃痛，但還是強烈推薦這部作品！

一緒に感動して！

公司最近又換 AI coding tool 了，我怎麼會說又呢，因為 Opencode 太好用啦，絕對不是 Roo Code Sunset 了。

一開始我沒辦法理解工具一直換但最後不是都是在解決問題和產生程式碼嗎

我原本以為差異只是這樣：

• Opencode 是 Multi-Agent 架構
• Roo Code 是 Single-Agent 架構
• Opencode 是 CLI based
• Roo Code 是 VS Code extension

但，真的只有這樣嗎？

先來回顧一下一路走來我們怎麼使用這些工具的

把近幾年的工具發展大致分成幾個階段。

Before AI 時代

代表工具：

• Jedi
• Pylance
• IntelliSense

工作模式：

1
2
3
4
5

Developer
    ↓
敲鍵盤，tab、tab、tab
    ↓
補 function name

這邊只能做到基本的程式碼補齊、Go to Definition 之類現代 IDE 的基本功能。

第一階段：Code Completion

代表工具：

• GitHub Copilot
• Tabnine

工作模式：

1
2
3
4
5

Developer
    ↓
Copilot
    ↓
補程式碼

這個階段 AI 工具的工作就是根據上下文，把剩下的程式碼補齊。

第二階段：Coding Agent

代表工具：

• Cursor
• Gemini Code Assist
• Roo Code
• 現在的 Copilot

工作模式：

1
2
3
4
5
6
7

Developer
    ↓
Roo Code
    ↓
分析專案
    ↓
修改專案

這個階段的 AI 工具不只能補全程式碼，它還可以：

• 閱讀專案
• 分析架構
• 修改多個檔案
• 提出建議
• 執行測試
• 修正錯誤

這個時期的 AI 已經是個稱職的輔助駕駛了。

第三階段：Agent Runtime

代表工具：

• Opencode
• Claude Code
• Codex CLI
• Pi Agent

工作模式：

1
2
3
4
5
6
7
8
9

Developer
    ↓
Opencode
    ↓
Task Decomposition
    ↓
Tool / Agent Orchestration
    ↓
Validated Output

這個時候的用法已經不是只能在 VS Code 中下一句 prompt 說：「幫我實作某某功能」，而是 「某某 team 想要在 Snowflake 下開立新的 table，你幫他跑完所有流程」

那 Roo Code 和 Opencode 到底有什麼區別？

要我來總結的話我會說處理的問題不同，Roo Code 這種 Coding 工具是偏向給開發者使用，通常會和 IDE 整合，但 Opencode 這種 Agent 則把能處理的事情往上提升一個層級，透過 MCP 或是 A2A Opencode 能做到不只是 「Coding」 這件事。

舉例來說，我可以靠 Opencode 組織一個開發團隊，裡面包含 PM、設計師、SA、SWE、QA 等等，交辦任務後就讓這個團隊去完成工作了。

另一個例子是假設今天我是 DevOps 遇到了 GKE 網路問題，我可以同時指派 Network agent、GKE agent、GCP agent 同時下去查問題，這個就會比 Roo Code 透過一次次來回蒐集線索然後決定下一步還會快速。

Multi-Agent vs Single-Agent Runtime

我們可以從 Roo Code 的原始碼來看看它是怎麼建立 subtasks 的 (下面的 Code 都有簡化過)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

export class NewTaskTool extends BaseTool<"new_task"> {
async execute(params: NewTaskParams, task: Task, callbacks: ToolCallbacks): Promise<void> {
const { mode, message, todos } = params

if (!mode || !message) {
return
}

const targetMode = getModeBySlug(mode, state?.customModes)
if (!targetMode) {
pushToolResult(formatResponse.toolError(`Invalid mode: ${mode}`))
return
}

const toolMessage = JSON.stringify({
tool: "newTask",
mode: targetMode.name,        // ← 指定 mode
content: message,             // ← Context 內容
todos: todoItems,             // ← 初始 todo
})

const didApprove = await askApproval("tool", toolMessage)
if (!didApprove) return

const child = await provider.delegateParentAndOpenChild({
parentTaskId: task.taskId,
message: unescapedMessage,
initialTodos: todoItems,
mode,
})

pushToolResult(`Delegated to child task ${child.taskId}`)
}
}

可以看到 Roo Code 雖然可以作 orchestration 建立 subtask，但是它建立的是 child task，不是另一個可獨立配置的 subagent，而是把需要用到的 Mode, Todo 以及 Context 傳遞下去。

而 Opencode 是用兩步驟來建立 subagent

建立新的 session

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

const nextSession =
  session ??
  (yield* sessions.create({
    parentID: ctx.sessionID,
    title: params.description + ` (@${next.name} subagent)`,
    agent: next.name,
    permission: [
      ...deriveSubagentSessionPermission({
        parentSessionPermission: parent.permission ?? [],
        parentAgent,
        subagent: next,
      }),
      ...(cfg.experimental?.primary_tools?.map((item) => ({
        pattern: "*",
        action: "allow" as const,
        permission: item,
      })) ?? []),
    ],
  }))

建立 subagent

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const runTask = Effect.fn("TaskTool.runTask")(function* () {
  const parts = yield* ops.resolvePromptParts(params.prompt)  // 解析 prompt 中的參數
  const result = yield* ops.prompt({
    messageID: MessageID.ascending(),
    sessionID: nextSession.id,  // ← 傳給新 subagent 的 session
    model: {
      modelID: model.modelID,
      providerID: model.providerID,
    },
    variant: next.model ? undefined : variant,
    agent: next.name,
    tools: {
      ...(next.permission.some((rule) => rule.permission === "todowrite") ? {} : { todowrite: false }),
      ...(next.permission.some((rule) => rule.permission === id) ? {} : { task: false }),
      ...Object.fromEntries((cfg.experimental?.primary_tools ?? []).map((item) => [item, false])),
    },
    parts,  // ← 傳遞 prompt 內容（context/task）
  })
  return result.parts.findLast((item) => item.type === "text")?.text ?? ""
})

這兩種執行方式不單單只是多工及速度上的差異，首先來談談 Roo 這樣作有什麼優缺點。

Roo 的作法是使用單一 Agent 搭配不同的 Mode 來做到角色切換。它的 runtime 比較像 task stack 模型，parent task 會暫停，child task 被 push 到 stack top 成為 active task，完成後再回到 parent task，所以一次主要只有一個 task 或 subtask 在推進。我們用起來有時候會覺得 Roo 在執行階段非常慢，但這樣的設計還是可以帶來一些好處:

1. 一次只執行一個 task，使用者可以持續關注當前的 task，隨時介入
2. 不用處理 Race condition 問題
3. 執行是線性的，要 debug 會比較容易

另一方面 Opencode 採用 multi-agent 的設計，可以設計成多個 subagent 平行執行。除了效率外，agent 的客製化會是一個決定性的區別，在 Opencode 中我們可以自己定義 agent 的 workflow、有哪些權限以及工具可以使用，這樣使用 Opencode 這種工具能做到事情從 「hey, 幫我開發這個功能」 進化到 「hey, 幫我解決這個問題」。

為什麼新一代工具開始回到 CLI？

我的看法是，如同前面提到的工具進化，現在 AI 工具能做到的不再只是 Coding 而已，所以跳脫 IDE 的設計勢在必行。IDE 是程式碼的工作空間而 Terminal 是系統的工作空間，擁有系統的權限意味著 agent 能夠為你服務更多事情。

Roo 與 Opencode 的核心差異

最後總結：

關於這本書

這本書是持續買進作者尼克・馬朱利 （Nick Maggiulli）的新書，作者提出了一個很有意思的觀念「財富階梯」，讓想要增加財富但不得其法的人們可以快速了解每個階層的人物側寫、以及如何增加財富。

本書可以分成兩個段落，前面用很大篇幅解釋由統計資料分群出來的六個群組對應財富階梯的六個階層，介紹了每個階層的相異之處，以及位於不同階層要「升級」的建議。後半段則是分享一些作者對於金錢的思考，這段是我覺得比較有趣的部分。

如果只能畫一條重點

鹽之於食物，猶如金錢之於人生。沒有錢，生活將淡而無味且受限，哪怕只是一點點錢，也能讓生活增添無盡樂趣。

作者引用了美食作家莎敏納斯瑞特寫過的一段話：「鹽使食物吃起來更像它本來的味道，不加鹽，我們的食物就淡而無味，加了鹽，食物的味道就鮮活起來。」 巧妙的用鹽來比喻金錢，光有金錢並不會讓我們的生活變得更精彩，而是需要有值得灑在上面的食物。

金錢和鹽的價值，都取決於周邊的食物，不然即使爬上了財富階梯，也可能毫無意義。

這段讓我去思考了如果賺到錢了，該把錢用在什麼地方。

和我的關係

看見自己位於哪一階

財富階梯的六個階層

我剛看到這種分階層很怕作者是要把人分等級，但這邊財富階梯的本意不是要讓人分高下，而是像是把遊戲中的戰爭迷霧打開，讓自己可以清楚看到處在哪一個位置，要前往下一個階層可以採用哪些策略。

有趣的是根據作者的觀察，相同階層的人們往往會有類似或相同的行為。我原本無法理解為什麼會有人願意花上千萬去買豪宅，但開了天眼通看到第五階才知道，原來他們是住宅自由的一群人，買龍寶和興復發對資產的影響都不大，那為什麼不買龍寶呢？ 我覺得閱讀財富階梯有趣的地方就在這。

隨著財富增加而增加花費

作者有提到一個觀念是「隨著財富增加而增加花費」，我覺得和《別把你的錢留到死》這本書的提倡的觀念有異曲同工之妙，作者提出了 0.01% 法則告訴我們隨著資產的提升，如果每次的消費都佔資產的 0.01% 你的資產不減反增，這意味著在不同階層下，你有不同的選擇自由，在這個自由下花錢可以讓生活更豐富而不是都不花錢，而這 0.01% 就可以對應到上表的「不同的自由」。

金錢以外的財富

除了講金錢財富的財富階梯外，作者還引用了創業家薩西・布魯姆的其他四種財富讓我們留意：

1. 金錢財富
2. 心理財富
3. 社會財富
4. 健康財富
5. 時間財富

舉例而言，若缺乏社會財富，則需要大量其他形式的財富才能彌補，根據研究：

• 每天幾乎都能見到朋友，相當於每年賺 10 萬美金
• 已婚狀態，相當於每年多賺 10 萬美金
• 經常與鄰居互動，價值相當於每年多賺 6 萬美金

這只是其中一個例子，但作者想要傳達每種財富都很重要，而且這些財富可能唾手可得，哪怕是現在拿起電話打給許久沒碰面的老朋友，或是轉身給陪在你身邊的人一個擁抱，這些平常不會注意到的人際關係，也是我們每個人的重要資產。

在路邊停車讓小孩睡覺的時候，手癢想進 Pokemon Sleep 蒐集一下樹果，剛好手機因為接著 CarPlay 就把遊戲 BGM 放出來了。

今天的地圖是ウノハナ雪原，播放的 BGM 是ウノハナ雪原 (夜)，一聽驚為天人，旋律怎麼這麼好聽，因為平常玩遊戲是不開聲音的，回家馬上聽一波。

這邊有個小彩蛋，如果 Spotify 介面是繁中的話可以看到一隻睡覺的皮卡丘，日文版就沒有喔！

後來去查了一下 Pokemon Sleep OST 的作曲家景山将太，原本是 Game Freak 的遊戲作曲家，有許多神奇寶貝相關的作品。

最後附上 Playlist 一起來欣賞吧，這個很適合當作環境 BGM 或是睡前催眠歌曲。

後記

最近為了製作自己想要的封面圖，學了很多 Photoshop 技巧，原來 PS 要做一個 R 角這麼複雜啊！

週末在家加班有感而發，公司取消在家工作 (Working From Home, WFH) 對我的影響是非常大的，反映了也沒用，只能自己私下偷抱怨。

先來談談我在家工作享受到各種好處。

絕對的專注及生產力

在家工作因為不會被干擾，很容易就能進入心流，不用擔心會被同事打斷或是聽到後面有人在討論技術問題就開始側耳傾聽。

更不用說家中的設備不論是大螢幕、順手的鍵盤、「符合正常人類高度的座椅和桌子」^[1] 都比公司給的破爛設備好，讓我黏在我的書桌上為公司埋頭苦幹一整天我都願意。

至少根據我的經驗，員工 WFH 常常是做到甚至忘了吃飯，最後工時還比在辦公室工作來的多。

一週的家事時間

對於每天要花兩小時來回通勤，家裡還有小孩的家庭，別說做家事了，晚上沒有先累倒就不錯了。

在家工作就能利用休息空檔在沒有小孩的時間把衣服丟進洗衣機、簡單掃掃地、刷刷馬桶，曾經有段時間我都是用這個時間洗一週的衣服。

可以接送小孩的權利

因為公司的位置在一個鳥不生蛋的地方，別說要送小孩上學了，每天都必須在家人還沒起床前就必須要出門，到家的時候天都黑了。

而 WFH 的這天，我不僅可以送小孩上學，下課還能去接，除了在車上可以聊天，還能看到小孩在等候區看到你車來那雙發亮的眼睛，這是一個可以增加親子互動的好機會。

省下來的通勤時間

公司福委會很常舉辦一堆體育活動鼓勵大家運動，我總是覺得非常可笑，辦這些活動不如多給幾天 WFH 讓大家省下來的時間可以自主運用。

早上一小時不用通勤我就能上語言課程，下班不用塞車，我就能出門跑步。兩個小時不斷的累積下來是很可觀的。

· · ·

當然對資方來講，不需要管員工這麼多，反正每個螺絲釘都是可以被替換的，總是會有源源不絕願意拿香蕉的猴子。另一方面，也不是所有員工都像我一樣自律而且有責任感，資方沒必要照顧少數人而承受多數人在家擺爛的風險。

先寫到這了，希望公司哪天可以想通。

因為公司政策改變，現在鼓勵 developer 用 GCP Cloud Workstations 取代 VM，開發上還是習慣用 Terminal 搭配 VS Code 來作業，沒辦法從 WSL 連上 Workstation 就像是心中有個結打不開那樣（以前有成功搞定 tunnel 過，但是 IT 不知道搞了什麼，後來不能用，也沒再花時間搞了）。

最近 Roo Code sunset，迎來 opencode 的時代，這種 CLI 工具沒有 Terminal 一定痛苦死，只好又跳下來弄一弄。

建立 TCP Tunnel

要用 SSH 連到 Cloud Workstation 需要透過 tunnel 來達成，可以使用這樣的指令：

1
2
3
4
5
6
7

gcloud workstations start-tcp-tunnel \
  --project=my-gcp-project \
  --cluster=asia-southeast1-cluster \
  --config=vscode-small-standard \
  --region=asia-southeast1 \
  my-ws-name 22 \
  --local-host-port=:2222

這會開啟一條 TCP tunnel，將 host 的 2222 port 轉發到 Cloud Workstation 上的 22 port。

只要再

1

ssh user@localhost -p 2222

就可以透過 SSH 連進去了，這樣做還有一個好處是，可以用自己 host 的 VS Code 走 remote 的方式進到 Cloud Workstation 開發，這樣就可以使用自己 VS Code 的設定，以及 extensions。

如果覺得上面兩個步驟太麻煩，只是想要快速 SSH 進去操作，可以使用：

1
2
3
4
5
6
7

gcloud workstations ssh \
  --project=my-gcp-project \
  --cluster=asia-southeast1-cluster \
  --config=vscode-small-standard \
  --region=asia-southeast1 \
  --local-host-port=:2222 \
  my-ws-name

繞過公司 Proxy

理論上上面應該都要能動，但是公司的 proxy 會擋長連線，所以 tunnel 必須繞過 proxy。本來以為把環境變數 $HTTP_PROXY 和 $HTTPS_PROXY unset 就沒事了，但是試了很多次還是得到 502。

1
2
3
4

unset HTTP_PROXY
unset HTTPS_PROXY
unset http_proxy
unset https_proxy

後來查到，原來 Cloud SDK 也可以設定 Proxy。

1
2
3
4
5

gcloud config list --format="yaml(proxy)"

proxy:
   address: mycompany.proxy.com
   port: "80"

把這個 proxy 關了就能成功建立 tunnel 了！

1
2
3

gcloud config unset proxy/address
gcloud config unset proxy/port
gcloud config unset proxy/type

這篇文章會紀錄我踩雷以及除錯的過程，如果想直接看結論可以直接跳至結論

前言

最近看到很多人在推廣 Pi Coding Agent 趁著週末來玩玩看，在沒有任何背景知識下嘗試來維護我的 Obsidian 的筆記 Index，由於 Index 之前是交給 Claude Code 整理過一次，用 Pi 來測試應該不會出太大問題，但意外總是來的又急又快。

想說應該是不會很難的 Code 就不看直接測試了，結果發現 Error Log 開始狂噴，電腦逐漸卡頓，最後還收到 5 小時 Token 用量到達 limit 的通知，到底發生什麼事？

背景

我的 Obsidian vault 有一個 _metadata 資料夾，裡面放了所有文章的索引、分類以及每日報告。我想讓這些資料自動更新，不用每次手動叫 agent 跑。

我讓 Pi 幫我設計這個自動化流程。它的方案如下：

1
2
3
4
5
6
7

obsidian-notes/
├── .pi/
│   └── extensions/
│       └── metadata-sync.ts
└── scripts/
    ├── metadata_maintainer.sh
    └── metadata_prompt.md

metadata_maintainer.sh — 排程 script，給 launchd 呼叫，負責啟動 agent 執行任務：

1
2
3
4
5
6

if ! (
  cd "$WORKSPACE"
  pi -p "$prompt"   # 啟動 pi agent 執行整理任務
) >"$log_file" 2>&1; then
  status="failed"
fi

metadata-sync.ts — Pi 的擴充功能 (extension)，讓 Pi 每次啟動時自動執行 script：

1
2
3
4
5
6
7
8
9
10

pi.on("session_start", async (event, ctx) => {
  if (event.reason !== "startup") return;

  const shouldRun = ctx.hasUI
    ? await ctx.ui.confirm("更新 _metadata", "要在進入 workspace 時先同步嗎？")
    : true;  // 非互動模式直接執行

  if (!shouldRun) return;
  await runSync(pi);  // 執行 metadata_maintainer.sh
});

metadata_prompt.md — 告訴 Agent 要執行 task 的細節

這邊的設計是：每次用 CLI 的 Pi 打開 workspace 時，先問你要不要同步；若是自動排程（非互動）就直接執行。

時間線

開始追查

因為 Codex token 燒光了，只好回頭用 Claude Code 一起看。

先看 _metadata/logs

1
2

$ ls _metadata/logs/ | wc -l
2716

我的天啊，我沒寫 retry 機制，這個 script 怎麼會跑了兩千多次？！

接著看一下 Process

1
2

$ pgrep -f metadata_maintainer | wc -l
743

???

原本以為 Pi 都幫我把程式註冊到 launchd 裡面，但是查了之後也沒有，事情更怪了到底怎麼會有殺不完的 Process ?!

好在萬能的 Pi 有提供好用的 Session Log!

pi 會在 ~/.pi/agent/sessions/ 下為每個 workspace 保存完整的對話與 tool call 記錄。我打開爆炸時的 session 目錄看到：

1
2
3
4
5

2026-05-24T02-40-13-328Z_...jsonl
2026-05-24T02-40-16-978Z_...jsonl
2026-05-24T02-40-17-536Z_...jsonl
2026-05-24T02-40-18-097Z_...jsonl
...

每個 session 的開頭都是同一段 prompt——來自 metadata_prompt.md，也就是 metadata_maintainer.sh 用 pi -p "$prompt" 傳進去的，這代表總共啟動了上面這麼多個 Pi agent。

正常的執行流程應該是這樣：

最多應該也只有五筆 log，但顯然事實不是這樣，而且後面很多 log 都有 prompt 指令，那就可以合理推測第四步時，Pi agent 跑起來的時候又觸發了 2~4 的過程導致一直有 Pi agent 被開起來 （是不是很像 n+1 query）

簡單的時間軸就是這樣

1
2
3
4
5
6
7
8

pi 啟動，被問是否更新 metadata? -> Yes
└→ metadata_maintainer.sh
   └→ pi -p "$prompt"          # 啟動 pi
       └→ 載入 metadata-sync.ts 擴充功能
               └→ session_start
                   └→ 執行 metadata_maintainer.sh
                       └→ pi -p "$prompt"
                           └→ ...

就這樣直接把我的 Codex token 瞬間燒乾了…

要終止這個無限迴圈很簡單，

1. 在 metadata_maintainer.sh 前面加 exit 0，不要跑到 Pi 指令就退出
2. 反覆 pkill -9 -f metadata_maintainer 殺光所有的 process（因為 detached，需要跑好幾輪）

結論

Root Cause：Pi 在同一次對話裡做了兩件會互相觸發的事，但它沒有辦法在設計階段模擬兩者同時存在時的執行結果，需要被 review 或是其他機制來發現它的設計有問題。

清掉 process 就結束了。在 reload 或執行之前，還是需要把 agent 寫的東西讀一遍或是交給其他 agent 審查。

Lessons Learned: 如果有寫 extension 且 hook 在 Pi agent 啟動時，就要特別注意遞迴呼叫的問題。

事後想想，其實把 workspace 拆開就能避免這個問題。排程用的 Pi agent 跑在一個沒有掛 extension 的獨立 workspace，它就只是執行任務的 worker，不會觸發任何自動化邏輯。

1
2
3
4
5
6
7

obsidian-notes/             # workspace 1
└── .pi/extensions/
    └── metadata-sync.ts
obsidian-notes-scheduler/   # workspace 2
└── scripts/
    └── metadata-maintainer.sh

一時想到的解法，也許社群會有其他更好的方法。

這次還好打到五小時 limit 就停了，如果是用 credit 的後果則不堪設想，沒有想到 YOLO 又翻車。

Blog Blog 同樂會 五月的主題是 「改變人生觀的一句話」，由 Eddie 主持。

我認為我的人生觀包含了大部分的工作觀，畢竟現在每天花了大把的時間在工作上。

工作上一直面臨焦慮、自我懷疑，曾經以為作為 SWE^[1] 沒有能力進到 Big Tech^[2] 就是魯蛇，至少到最近我都是這樣看自己的。

我做過自己喜歡但是錢很少的工作；也做過錢還不錯但內容很無聊的。但想想錢變多就表示責任變多，有壓力的情況下再喜歡的工作也會成為負擔吧？

· · ·

如此這般地思考著工作的意義，也和很多朋友、前輩討論過。

有人認為工作就是賺錢，我出賣我的八小時給公司，這段時間就是不抱怨努力做，下班就是自己的時間別煩我。

有人認為錢拿少一點沒關係，但是工作要有意義，要能讓人產生使命感。

也有人認為工作就是工作最好錢多事少能躺平最好。

· · ·

一直無法得出答案的我，在閱讀完《無路之路》這本書後覺得有點方向了。作者在一場大病後體會到把整個人生建立在工作之上，並非這麼理所當然。

書中也提到我們對工作的崇拜來自於宗教、來自於社會、來自於人。我覺察到自己在潛移默化中會特別注重工作，甚至把工作和地位畫上等號了，對別人的好奇心止於職業而不是這個人的其他面向。

既然我是這樣看別人的，代表我也會這樣看自己：

自己沒有像樣的工作 = 魯蛇

William J. Reilly 在《不要工作的方法》中有一段話：你的人生也太寶貴，不該浪費在工作上

這段話道出了很多 FIRE 族^[3] 的心情，對我來說也是一記當頭棒喝，原本我還在想要做到六十歲退休，但想到我會失去什麼後我的人生觀就被改變了。

保羅在《無路之路》中提到，有一群人也是正在走在這條若有似無的路上，尋找自己的志願，他們離開自己的舒適圈不斷的探索，就算還沒找到答案，過程中也會滿載而歸。

尋找值得做的工作，就是我們真正的工作

這讓我有了脫離舒適圈的勇氣，我決定要持續尋找自己真正想做的事。

· · ·

現在的我不會再用公司或是 Title 來定義自己或別人，也認為工作只是一種手段不是使命，我想最好的策略就是一邊累積資產一邊尋找自己可以一直投入的事情，當條件滿足後，就能退休了。

我一直認為退休不是整天無所事事，而是指可以安心做自己想做的事情而不用擔心生存的那種狀態。

最後附上一句：

Find a job you enjoy doing, and you will never have to work a day in your life.^[4]

某個晚上，對就是把小孩送回娘家，我們夫妻倆人獲得短暫空檔組裝樂高的那個晚上。

決定去忠孝路夜市找找美食，說來慚愧，從小到大都沒有來過忠孝路夜市，學生時期都在一中街打轉，偶爾跑去逢甲這樣，但從沒想過要來忠孝路夜市，這是為什麼呢？

ぜんぜん分かんない！

也許只是沒想到吧！

總而言之稍微做了一下功課後兩個人就騎著機車興沖沖前往了。

騎到附近看到到處都是車，心裡暗道不妙，不趕快找車位停後面就會找不到車位。

後來才知道忠孝路夜市正確的吃法是騎機車直接騎到你要的攤位或店面前，沒有人像我們鄉巴佬一樣以為這裡是徒步區。

下面是這次踩點吃的：

熊家湯包

本來兩個人只想吃一籠湯包，留著胃去吃其他美食的，結果看到菜單胃口大開就爆點了一波，原以為鮮蝦腐皮捲是港點那種小小條，結果我們都傻眼，一盤有三條超大蝦捲就這樣端上來。

剝皮辣椒湯包非常好吃，皮很薄湯汁超多，就像其他網友說的一樣湯匙裝不下流出來的湯汁，配上薑絲可以一口接一口吃光光。

小缺點是店內沒有提供小碗，只能用湯匙辛苦的吃湯包，還要小心不能讓湯汁流出來。

忘了名字的地瓜球

台中人不說 QQ 蛋，請正名「地瓜球」！

走了很久都沒看到有傳統那種小小顆，類似逢甲大門口那家的地瓜球，最後隨便買，是大顆的也算很好吃。

炎伯紅茶 （阿義紅茶冰）

就在熊家湯包對面，看到很多人在排隊跟風喝一下，回家才知道原本叫阿義紅茶冰，但紅茶冰我真的喝不出差別

• 阿月紅茶冰
• 老賴紅茶冰
• 炎伯紅茶冰

我喝起來都一樣，不要爆甜我就給過。

南海茶道

以前聽同事推薦過，看到想點現泡茶，一問才知道一杯要等 20 ~ 30 分鐘果斷放棄換一般茶。太太還說他們辦公室很常點，而且他都點現泡茶（店員應該很想翻白眼）

阿緣香雞排

來自一位資深忠孝路夜市專家推薦，號稱地頭最好吃鹹酥雞，必點雞皮然後要馬上吃掉。

本來是想照著上面攻略吃的，但前面實在吃太飽連偷吃的胃口都沒了…

其實應該還有很多好吃的，但是年紀到了，食量不爭氣害我不能好好享用阿，下次再來吃點不一樣的。

在 2025 年趁著特價買回來準備放在玄關，但是一直找不到時間來組裝。

趁著某個週末小孩回阿公阿嬤家，配著宵夜和飲料和太太卯起來組，本以為幾個小時可以搞定，信誓旦旦的發下豪語沒組完不睡覺，但…

在開始之前，「神奈川沖浪裏」這句到底該怎麼斷詞？

神奈川沖（かながわおき）是地名，指神奈川的外海；浪裏（なみうら）是指波浪之中。合在一起就是「神奈川外海的巨浪之中」。

我一直都很喜歡北齋的浮世繪，特別是這幅以及凱風快晴，在家裡想擺一幅但是沒有空間豪邁地掛上一大幅，最後折衷買樂高 （？）。

葛飾北齋（1760–1849），江戶時代的浮世繪大師。他最狂的地方是，一生換了30幾個名號、搬了90幾次家，然後在70歲才畫出富嶽三十六景，神奈川沖浪裏就是其中最有名的那張，這是告訴我們退休還是要持續創作嗎？

一開始看到 1800 多片想說怎麼可能拼的完，後來才知道連那種一個點的也算一片，和之前拼 F1 有些組合需要想像一下不同，只要不眼殘拼起來是很快的。雖然說很快，但從八點開始也是到十二點才完成。

一邊看著說明書組裝，背後放著輕快的 LoFi 很容易就進入心流狀態，一轉眼時間就晃過去了，等到有睡意了才發現原來已經這麼晚了，最後看到成品非常有成就感。

最近突然思考起這樣一個問題：

為什麼同樣發一篇文章，發在臉書上跟寫在自己的部落格上，成就感、滿足感完全不同呢？

畢竟部落格這種東西可能沒什麼人會看到對吧?

儀式感

在臉書或 Instagram 這些社群平台發文很快。寫完、送出，結束。

寫部落格不一樣。要挑封面圖片、裁切、壓縮、處理浮水印，寫完後還要佈署。

這個流程雖麻煩，但麻煩本身就是意義的一部分。像是在告訴自己：這篇文章是我花時間產出的。

自己的空間

社群平台的 UI 不是我們決定的，而部落格是自己的地方。想改什麼就改什麼，想加上某個 feature 就叫 AI 刻出來。

主題如果看膩了還可以隨時切換，最重要的是每篇文章都有一份備份在自己的硬碟中。

沒有回饋機制

社群平台強調互動，所以會有很多回饋機制像是留言按讚分享等等。
在臉書寫東西結果發現沒幾個讚或是有人互動真的會非常失落 （就算寫的東西很廢也來吐槽我一下啊）。
而寫部落格沒有這個壓力。有人來讀，很開心；沒人看也不會患得患失。

持續有在看一些日文部落格，發現很多日本人把它當雜誌在經營，從封面到排版都看得出用心，讓讀者享受瀏覽的過程。
現在還在練習攝影、排版，希望也能把部落格當成雜誌在經營。

從 2025 年寫下第一篇文章到現在，每次完成一篇，成就感都還是如第一次一樣。

推薦大家擁有一個專屬自己的小天地。

記得我在第一次寫 Leetcode 的時候，寫完馬上按下 Submit，然後看哪個測試沒過就改到讓他過。

後來才知道這個感覺很接近測試驅動開發(Test-Driven Development，TDD) 的精神，差別是 TDD 是你自己先寫測試，不是等別人的測試來告訴你哪裡錯了。

TDD 的宗旨就是:

先寫測試，再寫程式。

有別於傳統先開發再測試的流程，TDD 有以下好處:

1. 測試本身就是一種規格，撰寫的過程可以對規格有更深入的理解
2. 如果規格有問題或是不明確，可以在寫測試的時候就發現
3. 開發的過程就一邊在重構了，不用等到最後一刻才發現不敢改

而 Red-Green-Refactor 是 TDD 中一個重要的觀念。
透過 寫測試 -> fail (Red) -> 寫 Code (Green) -> 重構 的迭代流程讓程式碼變完整。

這個練習只需要兩個檔案

1
2
3

fizzbuzz-kata/
├── fizzbuzz.py          ← 主程式
└── test_fizzbuzz.py     ← 測試

Red-Green-Refactor 三步驟

FizzBuzz Spec

在寫測試之前，必須先了解需求：

⚠️ TDD 之前就需要了解規格，才能把所有情況和邊界都納入測試。

TDD 練習過程

Cycle 1：fizzbuzz(1) → "1"

🔴 Red — 加測試

1
2
3

# test_fizzbuzz.py
def test_1_returns_1():
    assert fizzbuzz(1) == "1"

1
2
3

# fizzbuzz.py
def fizzbuzz(n):
    pass

執行結果（失敗）：

1

AssertionError: assert None == '1'

🟢 Green — 寫最少程式碼

1
2
3

# fizzbuzz.py
def fizzbuzz(n):
    return "1"

執行結果：

1

1 passed

🔵 Refactor

是的你沒看錯，寫這樣也算通過測試可以進到下一個 cycle

Cycle 2：fizzbuzz(2) → "2"

🔴 Red — 加測試

1
2
3

# test_fizzbuzz.py
def test_2_returns_2():
    assert fizzbuzz(2) == "2"

執行結果（失敗）：

1

AssertionError: assert '1' == '2'

🟢 Green — 寫最少程式碼

return "1" 只能處理 1，改成通用的字串轉換：

1
2
3

# fizzbuzz.py
def fizzbuzz(n):
    return str(n)

執行結果：

1

2 passed

🔵 Refactor

只有一行不太需要重構

Cycle 3：fizzbuzz(3) → "Fizz"

🔴 Red — 加測試

1
2
3

# test_fizzbuzz.py
def test_3_returns_fizz():
    assert fizzbuzz(3) == "Fizz"

執行結果（失敗）：

1

AssertionError: assert '3' == 'Fizz'

🟢 Green — 加入 3 的倍數判斷

1
2
3
4
5

# fizzbuzz.py
def fizzbuzz(n):
    if n % 3 == 0:
        return 'Fizz'
    return str(n)

執行結果：

1

3 passed

🔵 Refactor

不用重構

Cycle 4：fizzbuzz(5) → "Buzz"

🔴 Red — 加測試

1
2
3

# test_fizzbuzz.py
def test_5_returns_buzz():
    assert fizzbuzz(5) == "Buzz"

執行結果（失敗）：

1

AssertionError: assert '5' == 'Buzz'

🟢 Green — 加入 5 的倍數判斷

1
2
3
4
5
6
7

# fizzbuzz.py
def fizzbuzz(n):
    if n % 3 == 0:
        return 'Fizz'
    elif n % 5 == 0:
        return 'Buzz'
    return str(n)

執行結果：

1

4 passed

🔵 Refactor

不用重構

Cycle 5：fizzbuzz(15) → "FizzBuzz"

🔴 Red — 加測試

1
2
3

# test_fizzbuzz.py
def test_15_returns_fizzbuzz():
    assert fizzbuzz(15) == "FizzBuzz"

執行結果（失敗）：

1

AssertionError: assert 'Fizz' == 'FizzBuzz'

🟢 Green

1
2
3
4
5
6
7
8
9

# fizzbuzz.py
def fizzbuzz(n):
    if n % 3 == 0 and n % 5 == 0:
        return 'FizzBuzz'
    elif n % 3 == 0:
        return 'Fizz'
    elif n % 5 == 0:
        return 'Buzz'
    return str(n)

執行結果：

1

5 passed

🔵 Refactor

這邊可以思考兩種寫法

n % 3 == 0 and n % 5 == 0 或是 n % 15 == 0

• n % 3 == 0 and n % 5 == 0：意圖更清楚（同時是 3 和 5 的倍數）
• n % 15 == 0：更簡潔

如果效能不會差很多的話通常我都是選易讀的選項

Cycle 6、7、8：驗證通用邏輯

加入更多測試案例，確認邏輯真的通用：

1
2
3
4
5
6
7
8
9

# test_fizzbuzz.py
def test_6_returns_fizz():
    assert fizzbuzz(6) == "Fizz"

def test_10_returns_buzz():
    assert fizzbuzz(10) == "Buzz"

def test_30_returns_fizzbuzz():
    assert fizzbuzz(30) == "FizzBuzz"

執行結果：

1

8 passed

Final Code

1
2
3
4
5
6
7
8
9

# fizzbuzz.py
def fizzbuzz(n):
    if n % 3 == 0 and n % 5 == 0:
        return 'FizzBuzz'
    elif n % 3 == 0:
        return 'Fizz'
    elif n % 5 == 0:
        return 'Buzz'
    return str(n)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz

class TestFizzBuzz:

    def test_1_returns_1(self):
        assert fizzbuzz(1) == "1"

    def test_2_returns_2(self):
        assert fizzbuzz(2) == "2"

    def test_3_returns_fizz(self):
        assert fizzbuzz(3) == "Fizz"

    def test_5_returns_buzz(self):
        assert fizzbuzz(5) == "Buzz"

    def test_15_returns_fizzbuzz(self):
        assert fizzbuzz(15) == "FizzBuzz"

    def test_6_returns_fizz(self):
        assert fizzbuzz(6) == "Fizz"

    def test_10_returns_buzz(self):
        assert fizzbuzz(10) == "Buzz"

    def test_30_returns_fizzbuzz(self):
        assert fizzbuzz(30) == "FizzBuzz"

心得

雖然之前就有讀過類似概念，但也只是看過去而已，這次搭配 AI 教練自己下來動手作很有感。

1. 原來真的可以為了讓綠燈通過，寫出 return "1" 這種程式碼（雖然很快就會在下一輪被改掉）。
2. 做起來真的和傳統 SDLC 不同，我的感覺是在寫測試階段，就會逼自己去了解規格，並思考各種邊界。
3. 不確定這樣的開發方式會不會比傳統快，傳統的開發方式是大腦連貫的把已知邏輯順暢的寫完但不會管測試，而 TDD 則是片段式的慢慢把功能補齊，可以有預感 TDD 不會 overengineering。
4. 拿 Leetcode 的題目練習感覺是個不錯的主意。

思考：

1. 為什麼要用 Red-Green-Refactor 來執行 TDD，一次把所有想到的測試都寫完然後開發不好嗎？

關於這本書

Morgan Housel 是《致富心態》的作者，在《一如既往》中他提出一個核心問題：在這個快速變化的世界裡，什麼事情是永遠不變的？

書中用了二十多個小故事傳達各種不變的事物，有些故事我看了很有感，有些可以理解但沒有共鳴，建議可以隨心所欲閱讀，有些章節只是現在道行不夠無法理解，過陣子回頭再讀便是。

如果只能畫一條重點

從來不曾改變的行為是歷史最有力的教訓，因為它們預告未來的景象。

我認為這就是本書的精華所在，世間萬物的變化是很難預測的，但是考慮到「人性」一切都變得清楚起來。

人們會被貪婪迷惑、被恐懼支配，會低估風險、學過數學但不相信數學。

作者提到要預測未來，就要從人的行為下手，當你發現這一切都不是巧合，你會笑著說：「對，一如既往」。

歷史總是一再重演，一如既往。

和我的關係

我最有感觸的一章是「期望與現實」這個章節，在讀這章時處於一個極度羨慕身邊的人，覺得只有自己是收入最低的那個人，總是焦慮又悶悶不樂。

但作者在書中提到幾個重點：

你的幸福取決於你的期望，在這個大多數時候對大部分來人來說持續變得更好的世界裡，如何不讓期望值跟著上升，就是一項重要的生活技巧。

如果你只想要幸福，很容易就能實現；可是我們總想要比別人更幸福，這件事就永遠很難達成，因為我們會高估別人的幸福。

人們會根據周遭人的狀況來衡量自己的幸福感。

換句話說，幸福感來自於知足，知足可以讓自己的期望不會超過現實太多。期望來自於和身邊的人做比較，但我們無法知道別人實際上的情況，因此很容易被自己幻想出來的狀況影響我們的期望。

無路之路這本書有一句話我也很喜歡：「足夠就是知道衣服、大餐或是最新的玩意兒不會讓我更快樂，但偶爾買買，也不至於會破產」。這句話非常貼切的描述了庶民如我期望，想買很多喜歡的衣服、想蒐集各種鏡頭，但我知道這些事物帶來的多巴胺來的快去的也快，但偶爾買買也不失為一種樂趣。

用這些文字勉勵自己持續學習知道自己的足夠，才能找到幸福。

受老師邀請和一位高中朋友一起回學校和現在的學弟妹分享、聊聊工作。

在事前準備有先發了 Google Form 調查一下學弟妹對什麼樣的問題有興趣，也針對各個問題寫下了自己的想法。

但是在當天排練時雖然有小抄還是覺得腦袋轉不過來，一直以來我的報告方式都是準備好 slide 後在每頁註解的地方標示關鍵字，剩下靠即興發揮，但這次似乎踢到鐵板了。

手上只有小抄和有 slide 的報告感覺完全不一樣，而且我們是兩人互動的方式，當下其實很難掌握說話的節奏以及內容範圍，導致雖然順利講完，但是有些我覺得很重要的事情沒有好好傳達到。

有位同學下課後來問我問題，提到如果都讓 AI 寫扣了，那工程師要做什麼呢？

這個問題其實我也問過自己很多次了，當下就把我現在的答案告訴他，也許之後還會持續改變。

我是這樣回答的：「當 coding 這些事情交給 AI 後，每個人都可以成為資深工程師了，因為省去了敲鍵盤的時間，可以花更多的時間去設計系統、確認規格，過去被 deadline 追著跑而捨棄的東西，有了 AI 現在都可以做到」

另一位同學的問題是關於工時的，我只能回答說每間公司不同，不同部門與職位也不同。但這個問題讓我覺得有趣的點是，背後是不是想了解 work life balance 呢？ 這會是 GenZ 關注的重點嗎？

事後想了幾個可以做更好的地方。

對方只有 16 歲，我講太多抽象概念了。我一直強調「不要把大腦外包」、唸書是在練習思考，老師當場提醒我要說清楚是思考「什麼」——才意識到這些話對我有意義，但對他們來說可能只是聽起來有道理的空話。

沒有 slide 真的很難控制節奏，以後類似場合主題要爛熟到不需要提示也能展開。

最後是發現打字寫作的時候可以把想法整理得很好，但講話的即時反應沒這麼快，需要多練習這種口頭報告。

前言

今天幫同事解決了一個 NiFi 上設定 mTLS 的問題。

由於公司最近換了內部的 CA，同事在更新憑證的過程中發現使用者無法用自己的憑證登入 NiFi，起初大家都覺得是 Server 憑證的問題，直覺告訴我和 Client 應該也有關。

mTLS 是怎麼運作的

一般我們透過 SSL/TLS 連線到網站，瀏覽器只需要驗證網站的憑證就好，Mutual TLS（mTLS）則是 Server 和 Client 互相驗證，用前面的例子來說，就是網站也需要驗證使用者的憑證。

先來看 TLS 的流程：

再來看 mTLS 的流程：

在 Server 發出 Certificate Request 時，如果有合適的憑證，就會要求使用者選擇。

NiFi 的設定出了什麼問題

在 NiFi 的設定中可以透過 nifi.security.keystore 來選擇 Keystore，這邊的 Keystore 就是 NiFi Server 自己的 Private Key + 憑證的組合。

如果有設定 nifi.security.needClientAuth 為 true 的話，就會啟用 mTLS 要求 Client 提供憑證，而且需要另外設定信任的 CA nifi.security.truststore。

這次的問題就是出在我們把 Server 從舊憑證（CA1 發行）更新成新憑證（CA2）後，同時也把 nifi.security.truststore 換成只含 CA2 的版本。

這樣雖然網頁打得開，但一般使用者的憑證是由 CA1 發行的，NiFi 的 truststore 不認識 CA1，所以無法通過 mTLS 驗證。

解決方法是讓 nifi.security.truststore 同時信任 CA1 和 CA2，可以透過 keytool（Java 內建的憑證管理工具，用來對 Keystore / Truststore 做新增、刪除、列出等操作）來匯入：

1
2
3
4
5

# 將 CA1 匯入 truststore
keytool -importcert -alias ca1 -file ca1.pem -keystore truststore.jks -storepass <password>

# 將 CA2 匯入 truststore
keytool -importcert -alias ca2 -file ca2.pem -keystore truststore.jks -storepass <password>

產生同時信任 CA1 和 CA2 的 Truststore，或是直接指定為 Root CA 也行，在公司內 CA1 和 CA2 的 Root CA 是同一個。

Take Away

1. truststore 要涵蓋所有需要被驗證的對象的 CA，包含 Server 自己的以及 Client 的。
2. 升級 CA 時，要確認 Client 也都更新憑證了再換過去，或是暫時設定成 Root CA。

後記

很久沒有這樣解決問題了，像這樣解決別人的問題又能學到東西才是成長的動力。

寫到第三篇時，距離出遊已經過了快一個月，發現真的要馬上把當下的想法和感受都記下來，不然很多記憶快煙消雲散。

如果想看 KidZania 心得可以直接跳到 這裡

Day 5

因為油布院的商店要大約十點才開，所以規劃 Day 4 就把這邊走完，這樣隔天早上可以直接前往下一個景點。

秋月城跡

原本沒有排這個景點，但是聽福岡回來的同事說這裡也是個賞櫻名點，前一晚看了一下 Threads 的消息，感覺還行就決定前往。

看地圖離油布院沒有很遠，但開車從交流道下來到秋月城跡還是開了一小段小路，在城跡附近就有停車場，停車費 400 日幣，離場前自行去一個窗口繳費就好。

杉の馬場真的是兩排超密集的櫻花樹，可惜來晚了枝頭都已經冒出綠芽，如果是滿開一定非常漂亮。即使如此，從枝葉間穿透的陽光在地上形成的光影也非常美麗。

路上遇到的遊客幾乎都是日本人，有對爺爺奶奶兩個人一起來到這邊旅行，看到我們帶著小孩就來寒暄了幾句。

午餐在黑門茶屋解決，如果是旺季這間位在杉の馬場中的小店根本是不可能吃到的，特色是他的葛餅和蒸雜煮（有點像是茶碗蒸但放了很多料，甚至有麻糬？），點了烏龍麵給小孩吃，他的麵條一吃驚為天人，非常Q彈而且入味，甜點是一杯混合黑糖和當地食材的冰沙。

路上有個小插曲是我和太太撿地上櫻花嘗試要拍出櫻吹雪的感覺，坐在一旁的日本歐吉桑就說要示範給我們看怎麼拍，接著就起身去搖櫻花樹，此舉實在太驚人，但讓我想到台灣有個網紅只是扶著櫻花枝拍照就被台灣人罵死，結果日本人是…

太宰府

秋月城跡到太宰府天滿宮不遠，可以沿著山邊開小路過去，一邊欣賞難得的景色一邊開車，路上車非常少久久才看到對向有一台車經過。

因為和一般遊客來的方向不同，我們直接把車開到九州國立博物館後面的停車場，這樣一下就能走到天滿宮。停車場很酷的是沒有人收費，要繳費是拿著放在桌上的小袋子裝 500 日圓然後寫上車號後丟進桶子裡。

天滿宮人潮實在有夠多，參道上都是人，摸個御神牛都要排一條超長人龍讓我直接放棄，直接進入神社內。

主殿好像在維護，所以另外在前面搭建了一個臨時的主殿，並且把祀器都移出來了。

建築都很漂亮，超級飽和的橘色居然不會讓畫面很突兀。

為了要買限定招財貓特地跑去 Beams，結果發現店內幾乎沒什麼可以買的，商品都被掃光了，而那隻熱門橘色招財貓店員跟我說要等五天才會再進貨。

忘了先查好這邊要吃什麼，只好在路上隨便看隨便吃，是沒買到特別難吃的食物，但好像就這樣，梅枝餅滿有特色的，熱的吃和冷的吃是兩種不同的風味。

Budget 租車

經過豪豪推薦，這次在福岡選了 Budget，我覺得優點是據點很多，線上預約全中文介面，ETC 和兒童座椅都能一起按完，搭配旅遊促銷折扣下來還算便宜。

還車的時候發現走國道的過路費高達 7000 日幣，看來這趟也是很會跑。第二次日本自駕完全沒打錯雨刷和方向燈，特此紀念。

博多麵街道．Shin Shin 拉麵

因為飯店距離博多車站不遠，晚餐就去車站二樓的博多麵街道，上樓只能搭乘手扶梯對嬰兒車不友善，經過很多家看起來很厲害的拉麵店，但是看到那個座位就知道帶小孩的人無緣，聽說 Shin Shin 拉麵親子友善，這邊剛好也有。

預約後很快進去了，雖然沒有兒童座椅，但餐點選擇還算多，而且因為很吵完全不怕影響到其他人，在這邊享用了拉麵啤酒大餐，麵條是我吃過最細的拉麵麵條，但口味只能說還好。

The Basic

老飯店翻新，看很多網紅推薦過一直想定看看但是價格都很貴，但太太意外用七折撿到超大坪數房間，算一下發現櫻花季這樣買沒有特別貴還是咬牙訂下去了。

有點可惜就是樓層夠高但是沒有住到面運河的那側，但是這個空間大人小孩都很舒適，值得!

Day 6

Lalaport KidZania

從博多車站到 Lalaport 可以直接搭公車 (46 或 46L) 直接到達。

早上直衝 KidZania 讓小孩玩個過癮，門票不便宜兩大一小要將近 5000 日幣，進去後發現完全不知道預約的規則浪費了不少時間，建議想去的人一定要做好功課！

每個小朋友在 KidZania 可以有一個銀行帳戶，在這邊活動有分成兩種，就業（賺錢）和消費（花錢）。參與賺錢的活動後會獲得工資，可以存入銀行帳戶，裡面也有提款機可以領現金。參與消費活動時例如買筆、搭觀光巴士就需要刷卡付費。

在 KidZania 裡面所有活動都是要預約了，一個小朋友一次可以預約兩項體驗，但是只能「向前預約」，這是什麼意思？

規則是這樣，入場後每個小朋友會拿到一張預約卡，每個體驗都有場次開始和結束的時間，預約第一個活動完想要預約第二個時，只能挑選結束時間比第一個預約開始「早」的活動，簡單來說就是禁止連續卡位，而且去預約只能小朋友本人。

舉例來說：

分享一下懶人攻略：

1. 事先查好想體驗的活動，這超級重要，因為熱門的像是消防員、Pizza 店、空服員這種會直接被預約到秒殺當天直接結束。
2. 開門進去就直衝最想體驗活動預約。
3. 如果還有時間在開始前去銀行開戶，取得金融卡。
4. 如果前面還有時間可以插入第二個活動就去預約。

午餐可以直接在裡面吃烏龍麵，簡單快速，因為一個活動體驗都差不多 40 ~ 50 分鐘，整天下來能玩到的有限，我們是滿幸運平日來人沒有很多，花了很多時間搞懂規則還能玩到四項，其中有一個是熱門的新生兒室照顧者。

但真的覺得超對不起小孩，兩位大人沒有先做功課搞懂玩法，以為現場排隊就能玩到好玩的，導致最後沒有玩到超好玩的消防員。

Lalaport

最後，我不是很推薦在 Lalaport 購物逛街，這邊觀光客超級多，本來以為來這邊可以把我們想買的東西買齊，結果要什麼沒什麼，ABC Mart 所有 Salomon 的鞋子都沒尺寸，想帶盞 Akari 也都沒貨…

要說這邊的優點就是美食街很大，帶小孩吃東西一樣沒壓力，除此之外我認為沒有要拍牛鋼或是玩 KidZania 真的可以不用浪費時間過來。

最後離開 Lalaport 只帶了草莓回飯店。

後記

這趟講最多日文居然是在從飯店到機場這段時間，因為坐在前座可以跟司機好好聊天，原來想聊天就是要坐前座嗎？！

這次就先寫到這邊，感謝大家耐心閱讀，有想到什麼再補充。

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

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

在我還沒看文件前，先看了一下程式碼沒有很多，想說偷懶一下全部交給 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 都沒辦法看出問題。

算上這次我已經數不出來看過幾次夏日大作戰了，記得第一次是大學的時候，窩在宿舍用 PPS 殘破不堪的畫質把它看完，這次則是第一次在電影院看。當熟悉的主題曲響起，彷彿跟著健二一起回到學生時期的夏天，重新喜歡上學姐 (?)

劇情沒有什麼轉折，流暢地講一個夏天發生在陣內家族的事，但每次看到奶奶抄起電話簿開始打電話以及花扎大戰的畫面，配上松本晃彥的音樂，眼淚都會不自覺流下來，我幾乎是每看必哭。

本來以為入場觀看的人會很少，出乎意料還滿多人的，我以為這是像我們這樣有點年紀的人才會想進來回味？真令人好奇他們是為了海報進來看，還是這個時間沒有其他選擇。

有一個運鏡是所有陣內家人坐在緣側上，鏡頭從右帶到左邊，照出所有人的剪影，這個畫面讓我印象深刻的是，畫面沒有用到明顯的透視，以及前後景的大小，單純利用物體間移動的速度差來表現遠近，我覺得這個手法真的非常厲害（如果有講錯請指正我）。

第一次領海報，原來電影院給的不會有任何塑膠套或是海報筒的嗎！？ 還好當天沒有下雨，順利帶上車回家了。

Blog Blog 同樂會 四月的主題是 「生產力」，由 Wen 主持。

談到生產力我會回想起數年前的工作，那是一個年輕人每天在燃燒自己獲得最大產出的情景，不知道是被責任感還是績效的焦慮推動著，時時刻刻都在想著不能浪費任何一點時間。

工作了一段時間，也閱讀了許多關於工作、人生的書籍，發現對於工作這件事情，是有很多種不同想法的。因此在這篇文章我想要來反思，生產力所為何事。

生產力之於工作

談到生產力一定會先想到工作，所以在那之前先來談談工作。

在古希臘時期，比起「工作」，「閒暇」才是最重要的。亞里斯多德曾說過：「我們不處於閒暇，就是為了要處於閒暇。」換句話說 「工作就是為了不工作」，可以看出早期西方對工作的態度是「工作是一個不得已的手段」。

回到現代，我們被夢幻工作 (Dream Job) 吸引著，認為進到夢想中的公司就能獲得幸福、認為好的 Title 或者公司識別證能夠代表我們。每天奉獻大把時間，回到家卻只想上床睡覺，殷切地盼著週末來臨，然後開始下一個輪迴。

西方從鄙視工作到工作變成天命，這中間是發生了什麼變化？

韋伯在《新教倫理與資本主義精神》中解釋了喀爾文教派的邏輯：信徒為了確認自己是否能得救，瘋狂地在世俗工作中追求成功。而教會讓「勞動」從生存手段變成了神聖的「天職」。

這樣的觀念即使過了幾百年還殘留在我們的思想中，不知不覺變成沒有好好工作，就不算「成功」。有趣的是，在亞洲也鼓勵「勤勞是美德」，加上儒家及科舉制度，金榜題名就能光宗耀祖，這些思想沉澱了幾百年，讓我們不知不覺用工作來衡量一個人的成就。

現在回到生產力，如果說我們提高了生產力是為了「工作」，那我想反問，這些提高的生產力真的有讓我們遠離工作嗎？

追求高效的代價

著名的帕金森定律告訴我們：「工作總會不斷膨脹，直到占滿所有可用的時間。」我們可能都有過這樣的經驗——下定決心要提早把事情做完，於是用番茄鐘保持專注，用時間箱規劃好每一個時段，終於把該做的都做完了。但主管發現有人手空出來，於是新的工作來了。效率提升的紅利，往往不是還給自己，而是被更多的工作填滿。

而過度追求高效，可能帶來負面的影響，作家摩根豪瑟在《一如既往》這本書中提到一個概念：「大部分事物都有自然發展的規模與速度，如果踰越限度，很快就會適得其反」。為了追求效率我們長期讓大腦滿載，我們以為多工可以不浪費任何一秒，但大腦在頻繁切換工作時也會造成損耗，沒有空出時間給大腦進行「發散模式」^[1]，長久下來注意力和創意下降，即使停下來休息也難以真正恢復。

小結

以前在專案中估工時，我都會估一個最樂觀的時間，以為這樣可以逼自己做更多。在重新了解工作與我的關係後，我越來越保守，還會刻意加上緩衝——不是因為變懶了，而是我知道「餘裕」的重要，是讓事情真正做好的空間。

生產力不是把每一秒都填滿，而是讓事情有空間好好完成。

Day 3

海之中道

海之中道位在福岡市北邊，離市區有段距離，需要開車或搭乘大眾運輸前往，這次我們是開車前往，路程大約半小時。

自駕而且想租自行車的話可以考慮從東口、西口或奇妙世界入園，租車現在似乎沒有一日券了，一次租三小時，超時以一小時計價就看想玩多久。

我們很幸運剛好碰到櫻花季尾聲，可以一邊騎著腳踏車一邊欣賞櫻吹雪，因為是平日遊客沒有想像多，玩起來非常舒服。

園區內有很多大型兒童遊具、可愛動物區、水族館等等，如果是帶小孩來玩建議停留半天到一天，在奇妙世界可以買點東西吃。

博多運河城

因為飯店停車場非常便宜但車位很少，在四點左右把車停回飯店接著散步去運河城逛街吃飯。

運河城還算好逛，是這次旅程僅次於天神的逛街地點，但逛一逛後看了一下時間，不知道哪根筋不對，發現好像有機會去吃一蘭，退完稅後就直奔位於中州的一蘭本店。沿著運河走，一邊欣賞河邊的建築一邊散步拍照，我想這就是看不到表演的原因吧。

一蘭拉麵總本店

大約六點四十到一蘭門口，已經有很多人在排隊了，有很多韓國人和香港人，感覺台灣人是少數。

店員會把推娃娃車的客人排到一樓，店內有兒童座椅，適合一家人來吃。

一蘭有個特別的活動是只要下載一蘭 APP （iOS 需要在日本 App Store 下載）可以獲得兒童拉麵券，趁這次去體驗了一下兒童拉麵到底是怎樣。

本來興高采烈期待會吃到傳說中的五角碗，但後來才知道是太宰府店才有。因為排隊排太久最後連八點的表演也沒看到，還在外面吹風吹了一個小時，為了吃拉麵也沒在運河城逛個過癮。

吃一蘭是這次旅行第二個錯誤決定。

Day 4

早上退房完就發生一件令人膽戰心驚的事情，正當我們享用完早餐準備把行李搬上車時，發現放在置物區的行李箱不見了，外頭停了一台遊覽車，而司機正在一個接一個把地上的行李弄上車，原來是一團雄獅的旅行團準備要離開，把我們的行李也當成了他們團員的，我只好一件一件檢查，幸好手把上有掛一個 Line Friends 的吊牌，可以在遊覽車底快速的找到我們的行李。

說實話在看到遊覽車之前，我根本不知道有團客入住，加上放行李的地方都是吃早餐的人臨時放置的區域，他們這團也沒有作記號或是把行李圍起來，我們的行李就這樣被誤認了。

雖然我自己覺得很扯就是，難道不該是團客吃完早餐後把自己的行李推出去嗎，不是自己的就別碰。

這次學到兩個教訓：

1. 行李箱一定要有特別的記號，掛東西或是特殊貼紙都好
2. 放行李的時候留意一下

九州自然動物園

這個動物園的賣點就是「マイカーサファリ」 也就是自駕遊園啦，意思就是可以開著自己的車進去繞園區一圈，這邊的動物在園區內是可以自由活動的，也就是說可能會遇到動物跑到路上造成汽車大排長龍這種事，畢竟這是他家嘛。 正常開車繞一圈走走停停加拍照大約花費四十分鐘到一小時。

除了開車探險外，園區內還有叢林巴士（ジャングルバス）可以搭乘，搭乘叢林巴士可以近距離餵食動物，我們因為沒有預定到，當天大約十一點到整天的車次都賣光了，建議要搭乘叢林巴士的人一定要提前預約，或是當天早一點到。

每一區都會有工作人員駕駛的斑馬車在旁邊待命。

動物園我們只排半天多一點，開車慢慢繞了一圈吃完午餐後就前往由布院了，順帶一提，餐廳長得很像員工餐廳，但是漢堡排非常好吃。

由布院

從九州動物園到由布院大約半小時，來玩動物園的人通常會住在別府或是由布院。

中間又發生一個驚魂記，在找停車場的過程中開過頭，路上又是單線道實黃線，我不敢迴轉掉頭，就一直開下去想說前面應該有地方可以迴轉，但越開越不對，開始爬山了還是沒有看到任何路口可以迴轉，只好在旁邊的避車灣等待時機迴轉。最後還是跨了實黃線迴轉…..

去民宿 Check In 完已經三點多了，剛好附近就有櫻花河堤，趁著還有光線我們沿著河堤前往最有名的湯之坪街道。

湯之坪街道和想像的有點不一樣，但也說不上為什麼，大概就是一條小小的街兩側都是商店，可以眺望遠處的由布岳。人潮很多，從語言上可以輕易判斷是韓國人還是香港人，日本人感覺都是在地人不是遊客。

因為走到湯之坪的時間已經有點晚了加上隔天早上想直接衝秋月城跡，就乾脆把花卉村、金麟湖也一起走完，大約五點多遊客就越來越少了，店家也陸續在打烊。

很糗的是，想說回程可以在車站附近買晚餐回去，殊不知走到這邊店也幾乎都打烊了，經過 Lawson 時還猶豫了一下要不要進去，這是這趟旅程第三個錯誤的決定：我們決定繼續走下去碰碰運氣，結果就是地圖上標了很多餐廳，但一間都沒開，只買了一份貴貴鰻魚飯回去民宿三個人分，差點沒被交誼廳傳來的泡麵味香死。

這次住的民宿就有湯屋，可以全家人一起進去洗澡泡湯，另外有兒童遊戲室，女兒第一次體驗在榻榻米和室中玩耍，玩到關門還不想回房睡覺。

後記

覺得油布院這邊時間排太少有點可惜，我們走到金麟湖的路上發現很多很好逛的小店，可惜都已經打烊，今天的時間也不足以讓我們好好逛，如果來這邊會想逛街的話，建議預留多一點時間逛逛走走。

關於這本書

作者芭芭拉‧歐克莉是密西根大學教授，也是暢銷書《大腦喜歡這樣學》的作者，本書就是她與其他作者一起將「Learning How to Learn」這門課程的精華，以淺顯易懂的方式整理寫給年輕讀者。

書中不僅從神經科學的角度解釋了大腦是怎麼儲存記憶的，也提供了許多能夠幫助學習的技巧。

這邊列出本書最重要的幾點：

1. 想要有效學習，最重要的就是要「專注」，專注是任何有效學習的重點。
2. 大腦會在「專注」和「發散」模式中切換，專注模式進行深度思考，發散模式則是讓思緒任意遊走。
3. 針對不同主題進行「交錯」學習，可以混入不同的思考方式，有助於提升理解。
4. 運動可以提供神經元需要的營養物質 BDNF，讓神經元長得更大更強健。
5. 刻意練習： 針對較難的教材持續且重複學習會比「懶惰的學習」更能刺激神經元生長。
6. 積極回想： 不斷的讓大腦去回想已經學過的東西，可以將資訊放入記憶中。
7. 番茄鐘工作法是一個符合腦科學的方法，讓我們可以在專注和發散模式間切換。

如果只能畫一條重點

專注模式和發散模式。大腦以兩種方式運作：專注和發散模式。你可以將它們想像成緩衝器密集和分散設置的兩種彈珠檯。我們需要轉換這兩種模式，以便能夠有效學習

我認為了解大腦的這兩種模式可以提升我的學習成效，因為沒有人天生就知道要刻意在兩種模式間切換可以提升學習效果，過去唸書的方法可能都是埋頭苦讀，一次就是 K 一個上午的書，沒有人告訴我放空和專注一樣重要。

和我的關係

讀完這本書後，開始嘗試書中提到的閱讀方式： 先用文本散步把章節標題都掃過，在腦中建立基本印象，接著在專注讀完後透過積極回想來強化記憶。

我會更積極的使用番茄鐘來學習和工作，強迫自己進入「專注」和「發散」的循環，只要想到，隨時隨地都能練習「積極回想」這個技巧，讓它變成安裝在腦中的預設軟體。

這本書沒有很多頁，但是非常多精彩的重點，真希望過去在唸書的時期就能夠學到這些學習技巧，可以有大把的時間練習和運用。

為什麼會想讀這篇文章

在現在人人都在用 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)

原本沒有打算在清明連假出遊，但二月時不知道哪來的衝動訂了福岡的機票，和東京大阪相比福岡的班機選擇真的比較少，票價還不便宜。

一直以來都在 Instagram 上被推播各種福岡飯店名單，但因為太晚訂又遇到櫻花季尾聲，選擇實在不多，在快速規劃完想玩的景點後馬上把飯店刷了。

這次的行程大致如下，遊記會分成上中下三部。

Day 1

原本小擔心清明連假北上桃機會塞車，意外地一路順暢，難得遇到一個不會亂開的機場接送司機，在車上舒服的睡了一覺。習慣上會提前兩小時多到機場報到，有充裕的時間可以在二航美食街慢慢閒晃，走著走著居然瞄到了雙月，而且還有供應雞湯和愛恨交織麵！

去程是搭空巴 A321，機體很小又沒有娛樂系統，原本搭飛機就會很緊張的我在上面如坐針氈，靠著手機上的單機小遊戲成功度過了這兩小時。

到達福岡機場大約是六點多，在排隊入境時看到有機邊托運娃娃車的家長都拿到車了但我們手上沒有，很緊張是不是我們下空橋應該要在那邊等，好在在行李轉盤旁邊發現我們的推車，而且是展開的狀態（地勤原來知道怎麼展開嗎？）。

福岡機場因為靠近市區很方便，飯店在附近的話可以直接搭計程車節省時間。但就在和司機溝通飯店時發生了小插曲，我們住的飯店有很多家分店，司機大哥以為就是博多市區那家，剛好分店中洲川端 (なかすかわばた) 漢字不會念，司機看地址看了很久才成功輸入到導航。

因為沒有很餓晚餐就去附近便利商店隨便買，順路去附近超市找找有沒有新鮮草莓，途中經過冷泉公園，雖然沒有點燈，但櫻花樹在路燈照射下依舊很美。

Day 2

櫛田神社

櫛田神社是舉辦博多祇園山笠祭典重要的場所，剛好在飯店附近，在搭地鐵前順道去走走。

舞鶴公園

接近櫻花季尾聲，決定調整行程先去舞鶴公園欣賞櫻花。天氣很好，但適逢假日遊客很多，櫻花樹下許多人帶著野餐墊和食物在樹下野餐。

賞櫻過程臭寶一直鬧事，一天下來不知道講了幾次「下次不帶你出門了」。

因為時間不夠，只能一邊遙望隔壁大濠公園滿開的櫻堤，一邊前往車站。

麵包超人博物館

有帶小孩到福岡必去的景點，在博多 Riverain 百貨的五樓，可以從中洲川端站六號出口直接搭電梯前往。

裡面可以玩的設施很多，也有陪玩姊姊，如果小朋友想盡情放電，推薦抓個兩小時以上。

SL 號小火車在入場時會拿到一張整理券，到指定搭乘時段後可以去月台搭乘，雖然說是月台，其實就是 Riverain 建築的一樓，要從特定的電梯搭下去一樓，到廣場後就會看到工作人員接待。

天神

本來應該是要來這邊盡情逛街的，但昨天吃壞肚子加上沒睡好，準備開逛時頭痛欲裂，兩個人只想隨便解決晚餐趕快回飯店睡覺。

本來想說後面還有運河城和 Lalaport 可以逛，天神踩個點就好，事後回想這整趟旅行最好逛的就是這了。

受到李唯邀請參加 Blog Blog 同樂會 的投稿活動，三月的主題是 「理想的日常」，由 Alex Hsu 主持。

「週日早上和太太及家人一起在院子草地上野餐，小孩在一旁玩耍，我則獲得一個在陽光下悠哉看書的下午。有時下去陪小孩溜滑版，有時坐著思考。這是一個非常棒的週末早晨」

說到理想的日常會讓我想起今年年初在一篇「最棒的週末」筆記中寫到的這段話。

沒有出門旅遊或是參與特別的活動，暫時放下了各種煩惱只專注在當下：有小孩、有溫暖的陽光、涼爽的微風還有短暫的空閒可以閱讀。

「那麼有辦法讓每天都感受到幸福嗎，天天都是理想的日常嗎？」

我認為是可以的，但前提是要先把感受幸福的能力找回來——而這需要一點自律。讓像是陪小孩玩、手沖咖啡、閱讀甚至是洗奶瓶這些稀鬆平常的瑣事也能夠創造出幸福感。

生活の中に個人的な「小確幸」を見出すためには、多かれ少なかれ自己規制みたいなものが必要とされる。

—— 村上春樹《蘭格漢斯島の午後》

最近讀了些書，才發現村上說的自律，和校正爽痛平衡的概念不謀而合，也許村上先生早就領悟到了吧。

能夠無時無刻感受這些微小的幸福，就是我理想的日常。

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

為什麼會開始電玩排毒

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

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

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

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

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

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

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

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

註解

關於這本書

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

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

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

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

如果只能畫一條重點

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

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

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

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

1

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

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

和我的關係

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

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

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

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

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

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

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

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

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

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

終於買了網域名

最近剛把網誌從 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 閱讀器。

我平時都會有想要學習或研究的東西以及各種不同的想法，但是過去一段時間覺察到自己變成了一個無聊、停止思考的人。

某天突然領悟到這是因為資訊的 Input 太少，當我在 FB 技術社團看到一些應用，發現腦袋開始轉起來了：「家裡剛好有一台閒置的 Mac Mini，是不是可以拿來養龍蝦？」「有了龍蝦後是不是可以幫我自動過濾 FB 上對我有價值的資訊並推播給我」一連串的想法接踵而來。

在「逆行人生」這本書中作者提到了「大腦自動化」這個概念。當大腦被不斷的訓練後，即使沒有在學習也能夠無時無刻的進行思考，要訓練大腦就要有 Input，因此大量接收資訊以及閱讀就是最好的方法。

雖然現在是個資訊爆炸的時代，但不是所有資訊都是有意義的。如果只是被動的接受「推式資訊」，光是過濾演算法給出的垃圾就已經筋疲力盡了。閱讀書籍當然是一個最簡單的方法，但我還是要找到一個方法來大量獲得有益的網路資訊。

前言

最近看完書領悟到了一點 「要解決財務焦慮的第一步，就是要知道家庭支出」，於是開始研究了一下市面上的可以協作的記帳軟體，但不是要付費就是功能太複雜，最後決定自己開發一個來試試看。

目標與設計

我目前想要的功能很簡單，就是有個介面可以輸入記帳項目，然後可以把交易記錄到 Google Sheet 上就好，反正要整理分析最後人工來作也不會花上太多時間。

想到之前一直想要來玩玩看 Google Apps Script (以下都簡稱 GAS)，加上 GAS 又能無縫串接 Google Sheet，正好符合這次的需求。

初步架構就決定是這樣了:

開發過程

全程 Vibe coding 都讓 AI 寫，我只負責測試以及驗收功能，還有設定 Line Channel 這些後台設定而已。

GAS 其實就是一個 PaaS 服務，使用者只需要照自己的業務邏輯撰寫程式碼，後面的執行環境、部屬等等 GAS 都會幫你準備好，讓像我這樣的懶人可以很快的直接看到成果。難怪很多人會拿 GAS 當作軟體工程啟蒙，這比寫爬蟲什麼有趣多了。

要開發 GAS 可以直接在 GAS 的網頁上開發;或是像我一樣在自己的 IDE 上開發完，再利用 clasp 這個 CLI 工具推送到 GAS 上完成部屬，後者的好處是會有一份程式碼在 local，可以使用 IDE 或是 AI 工具協助開發。（相信我你不會想在 IDE 寫完程式碼，然後用複製貼上的方式去網頁版編輯器）

GAS 執行時的運作也很簡單，就是兩個入口：

1
2
3
4

function doGet(e) {}

function doPost(e) {}

我們把需要的 callback 邏輯寫在這兩個函式中，以我的案例要接 Line Messaging API 打過來的請求，大概會長這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13

function doPost(e) {
  var contents = JSON.parse(e.postData.contents);
  var events = contents.events;

  events.forEach(function(event) {
    if (event.type === 'message' && event.message.type === 'text') {
      var eventId = event.webhookEventId;
      ...

      // do something
    }
  });
}

要存取 Google Sheet 也很簡單，直接在程式碼中呼叫 SpreadsheetApp.openById(sheetId); 就可以透過 ID 取得，但是要注意後面在部屬的時候要設定執行身分，如果這個 sheet 只有本人可以存取，那執行身分就要設定為本人。

部屬也是非常簡單，只要在網頁上點選右上角的「部屬」按鈕，就能完成部屬了。

部屬成功後會得到一個像這樣的 URL: https://script.google.com/macros/s/AKfycbxOFRfffExrffffsaaa63opssssss-kffsssFRffT5Y-y8hBBBBCCC/exec，這個就是我們服務的對外 URL。是的你沒看錯，連 HTTPS 都幫忙搞定了。

拿到這個後就可以把這個 URL 貼到 Line Channel 上的 webhook 欄位使用。當 Line Message API 接收到特定 Channel 的訊息後就會發送一個請求過來這個 URL。

到這邊其實就算是完成一個簡單的 Line Bot 了。

遇到的問題

在 Line Developer 頁面測試 webhook 都不會過

這個我真的卡了一陣，但最後找到保哥 2025 的貼文，知道Bot 還是能正常回應就不管他了。

沒有 Log 超難 debug!

GAS 在開啟「所有人都能呼叫」時，在執行項目那邊會看不到 log，即使呼叫的人是自己，GAS 也會把 log 隱藏。

有看到社團有人是把 log 寫到另一份 Google sheet，或是乾脆通靈 (?!)。我是為了看 log 把這個專案綁定到我的 GCP 專案中，就可以在 Cloud Logging 上看到 log 了。

執行太慢，超過 Line Messaging API 的 1s timeout 時間

這個是目前唯一沒解決的問題，從 Line Messaging API server 發送過來的請求要在 1s 內回覆 HTTP 200 不然就會被視為失敗，觸發 Line Messaging API 的重試機制，會每隔一段時間重新發送重複的訊息 (記帳 sheet 上會多出一堆相同的紀錄)。

為了解決這個問題我也嘗試把執行時間較久的 callback 改成先建立一個 Time Trigger 在一秒後執行寫入 Google sheet 的操作。但我怎麼樣都無法把執行時間壓在一秒內，最後還是會觸發重試。

另一方面針對重試發過來的請求可以用一個 cache 阻擋他，至少讓重複的資料不要寫入 Google sheet。

這個問題最後還是沒解決，雖然一切都能正常運作，但是看到 log 中有 Line Messaging API 送過來的請求還是會很阿雜。

結論

作為一個全託管服務，GAS 以他親民的使用方式讓很多非工程師也能快速自動化工作，除了 Google Sheet，GAS 也能串接其他 SaaS 服務如 Drive, Forms 甚至是 Big Query 等等，如果工作上都會用到這些服務，GAS 不失為一個自動化的選擇！