---
schemaVersion: 1
slug: gp-40-20260207-mitchellh-ai-adoption-journey
ticketId: GP-40
lang: zh-tw
title: Mitchell Hashimoto 的 AI 採用之旅 — 6 步驟讓你從懷疑論者變成「AI 根本回不去」
summary: HashiCorp 共同創辦人 Mitchell 分享他從 AI 懷疑者到 AI 重度使用者的 6 步驟旅程 — 放棄 Chatbot、用 Agent 複製自己的工作、下班前啟動夜間任務
originalDate: 2026-02-06
translatedDate: 2026-02-07
source: Mitchell Hashimoto
sourceUrl: https://mitchellh.com/writing/my-ai-adoption-journey
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-40-20260207-mitchellh-ai-adoption-journey
status: published
replacementTicketId: null
replacementUrl: null
---

# Mitchell Hashimoto 的 AI 採用之旅 — 6 步驟讓你從懷疑論者變成「AI 根本回不去」

> **來源:** [Mitchell Hashimoto](https://mitchellh.com/writing/my-ai-adoption-journey)

你有沒有過那種經驗 — 某個東西你一開始覺得「這什麼垃圾」，結果三個月後變成你離不開的東西？

像是第一次吃臭豆腐的時候，或者第一次打開 Vim 的時候。

Mitchell Hashimoto 對 AI 就是這樣。

如果你不認識他：**HashiCorp 共同創辦人**，Terraform、Vagrant、Consul 都是他們家出品的。最近還做了一個很紅的 terminal emulator 叫 **Ghostty**。簡單說，這是工程圈裡信譽極高的人，而且不是那種看到什麼就追什麼的人。

他最近寫了一篇長文，講他怎麼從「AI？沒用吧」走到「沒有 AI 我不知道怎麼工作」。有趣的是，他的心路歷程跟很多工程師一模一樣 — 問題從來不是 AI 不行，是你不會用 (¬‿¬)

> **Mogu 歪樓一下：**
>
> Mitchell 特別在開頭聲明這篇是他親手寫的。2026 年了，寫 AI 文章還要聲明「我本人寫的喔」— 這件事本身就是一個時代的註腳 (◕‿◕)
>
> 但我更在意的是：他沒有任何利益衝突。不在 AI 公司上班、不投資 AI 公司、不做 AI 顧問。這讓整篇文章的可信度直接拉滿。一個沒有理由幫 AI 說話的人，自願站出來說「我被說服了」— 這比任何 benchmark 都有說服力。

Mitchell 說，他學任何有意義的工具都會經歷三個階段：低效期（覺得在浪費時間）、堪用期（至少不拖後腿）、然後是「改變人生期」。大多數時候他得強迫自己撐過前兩關，因為他已經有一套自己的工作流了。換新工具感覺像在做額外的苦工。

但他知道，苦工是必要的。他的 AI 之旅，就是這樣一關一關闖過來的。

---

## 第一關：把 Chatbot 丟掉

Mitchell 的第一個領悟來得很直接：**網頁版 chatbot 拿來寫 code 是在浪費生命**。

不是說 ChatGPT、Gemini 網頁版沒用 — 問概念、查語法都很好。但你想讓它在你那個已經有十萬行 code 的專案裡幹活？它看不到你的檔案、跑不了你的指令、驗證不了任何東西。你能做的就是不斷複製貼上，然後祈禱。

這就像你打電話給水電工描述你家漏水的狀況，然後期待他在電話裡幫你修好。不可能嘛 (╯°□°)╯

> **Mogu 認真說：**
>
> Brownfield project（已經有一堆 code 的專案）才是真正的戰場。Greenfield（從零開始）的時候 chatbot 可能還行，因為沒有 context 要處理。但現實世界裡，大部分工程師面對的是 brownfield — 你得跟十幾年的 legacy code 搏鬥，chatbot 對這種場景根本使不上力。
>
> Mitchell 後來說他當 AI 懷疑者時有過一個「哇靠」瞬間：把 Zed 的 command palette 截圖丟給 Gemini，叫它用 SwiftUI 複製，結果真的做出來了。Ghostty macOS 版裡的 command palette 到現在基本上還是那個 AI 版本。但這是 greenfield 任務啊 — 一張截圖、一個獨立元件、零 context 依賴。換成 brownfield？直接 GG ┐(￣ヘ￣)┌

所以他的結論：**你要用 [Agent](https://gu-log.vercel.app/glossary#agent)**。Agent 就是能聊天、能讀檔案、能跑程式、能發 HTTP request 的 LLM，而且在一個 loop 裡持續運作。差別在哪？Chatbot 是那種嘴巴很會講但不動手的同事；Agent 是會說「我來」然後真的去做、做錯了自己改、改完自己測的那種。

---

## 第二關：每件事做兩遍

Mitchell 接下來試了 **[Claude Code](https://gu-log.vercel.app/glossary#claude-code)**。先講結論：**一開始沒有被打動**。

每個 AI 產出的東西他都要再修，整個過程比自己動手還慢。他讀了文章、看了影片，還是覺得沒什麼。

但他沒有放棄。他做了一件很痛苦但很聰明的事：**強迫自己用 Agent 複製所有手動做的 commits**。字面意思 — 每件事做兩遍。先手動做完，然後跟 Agent 搏鬥，讓它不看你的解法、獨立產出一樣的結果。

> **Mogu 偷偷說：**
>
> 這讓我想到一個學音樂的方法。老師叫你「這個樂句先用右手彈，再用左手彈，最後兩手一起彈」。過程超煩，但結束後你對那段旋律的理解完全不同。
>
> Mitchell 對 AI 也是這樣 — 同一個任務，手動做一次理解問題，AI 做一次理解 AI。兩遍下來，他就真的搞懂「AI 什麼時候會爆」跟「怎麼讓它不爆」了。代價是速度砍半，但換來的是真正的專業知識，不是道聽途說的「AI 很厲害」或「AI 很爛」(๑•̀ㅂ•́)و✧

這個過程很煎熬，但他對非 AI 工具也這樣走過來過。他知道摩擦是自然的，不能在沒有盡力嘗試之前就下結論。

然後，轉折來了。

他從第一原則重新發現了其他人早就在講的事 — 但因為是自己發現的，理解深度完全不同。把 session 拆成小任務、模糊需求先做 planning 再做 execution、給 Agent 驗證方法讓它自己修錯。更關鍵的是，他也搞清楚了 Agent 的邊界在哪。知道什麼時候不該用 Agent，本身就是效率提升 — 因為讓 Agent 去做它註定會搞砸的事，是最大的時間浪費。

到這裡，Mitchell 覺得 Agent 的速度跟自己手動做差不多。還沒有更快，畢竟大部分時間都在 babysit。

但故事才剛開始。

---

## 第三關：下班前的 30 分鐘

Mitchell 接下來問了一個很好的問題：**如果 Agent 能在我不工作的時間做事，那不就是免費的產能嗎？**

傳統的效率思維是「怎麼在 8 小時內做更多」。Mitchell 的思維是「怎麼讓那另外 16 小時也有產出」。

> **Mogu 補個刀：**
>
> 這個思維轉換是整篇文章最精華的部分。
>
> 想像你開了一家餐廳。傳統做法是壓榨營業時間的每一秒 — 翻桌率拉高、出菜速度加快、服務生多跑兩步。Mitchell 的做法是：欸，半夜廚房空著幹嘛？讓機器自動備料、洗菜、醃肉。隔天早上你進廚房，一半的 prep work 已經搞定了。
>
> AI 就是你的夜班員工 — 不會抱怨加班，不用付加班費，只是偶爾會把鹽巴當成糖 ╰(°▽°)╯

所以他開始每天下班前留 30 分鐘，專門用來啟動 Agent。一開始效果普通，有點煩。但他很快找到三類特別適合的工作：

**深度研究** — 讓 Agent 去調查某個領域，像是找出某語言裡所有符合特定 license 的 library，產出每個的優缺點報告。這種苦力活人做要花一整天，Agent 半小時搞定。

**模糊想法的平行嘗試** — 多個 Agent 同時去探索他有但還沒時間動手的 idea。不期待能 ship 的東西，但能照亮一些「你不知道你不知道」的盲區。

**Issue 和 PR 分類** — Agent 很會用 `gh`（GitHub CLI），所以他寫了腳本讓多個 Agent 平行分類 issues。重點是他不讓 Agent 回覆任何東西，只要隔天早上給他一份報告。

> **Mogu 想補充：**
>
> 注意一個細節：Mitchell 的 Agent 通常半小時內就完成了，不是讓它們整晚跑。
>
> 他利用的是工作日尾聲 — 通常這時候人已經累了、脫離心流了、個人效率很低。與其拿這段時間滑手機或假裝在工作，不如用來啟動 Agent。隔天早上就有一個 warm start，比從零開始進入狀況快得多。
>
> 這就像考試前一晚睡前把重點掃一遍，隔天早上起來腦袋裡自動就有底了。睡眠是免費的複習時間 (⌐■\_■)

到這裡，他開始覺得自己做的事比以前多了 — 雖然只是稍微多一點。

---

## 第四關：把穩贏的球交出去

Mitchell 現在已經很清楚哪些任務 Agent 做得好、哪些不行。

有些任務他有非常高的信心 Agent 會做出大致正確的解法。所以下一步很自然：**讓 Agent 處理這些「穩贏」的任務，自己去做別的事**。

每天早上他會看前一晚 triage Agent 的報告、篩出「幾乎確定 Agent 能搞定」的 issues、然後讓 Agent 在背景處理。同時他自己去做需要人類深度思考的工作 — 不是偷懶，是去做那些 Agent 做不了的事。

> **Mogu 忍不住說：**
>
> 這裡有個很有意思的選擇：他一次只跑一個 Agent，不平行。
>
> 很多人會覺得「那幹嘛不同時跑五個？效率不是五倍嗎？」但 Mitchell 很清楚一件事：babysit 多個 Agent 的認知負擔會吃掉你自己的深度工作時間。你以為你在 multitask，其實你在 no-task — 每個 Agent 都只分到你三分之一的注意力，你自己的工作分到零。
>
> 一個 Agent 在背景跑 + 你專心做自己的事 = 兩個人的產出。五個 Agent 同時跑 + 你不斷切換 = 零點五個人的產出。數學很簡單 (◕‿◕)

然後他提了一個超實用的細節：**關掉 Agent 的桌面通知**。

Context switching 的成本超級高。Mitchell 的原則是：人類決定什麼時候看 Agent，不是 Agent 決定什麼時候打斷人類。在你工作的自然休息點切過去看一眼就好。

他也提到一個有趣的 trade-off：把任務交給 Agent，你確實不會形成那些技能。但你繼續手動做的任務，你還是在自然地練功。重要的是你把「深度思考」的工作留給自己做。

到了這個階段，Mitchell 說他已經進入「根本回不去」的狀態。就算效率沒提升，光是能把精力集中在真正喜歡的工作上、同時還能妥善完成不喜歡的任務 — 這件事本身就值了。

---

## 第五關：每次犯錯都建一道牆

道理很簡單：**Agent 第一次就做對的時候效率最高**。

怎麼確保這件事？Mitchell 把它叫做 **Harness Engineering**（驗證環境工程）：**每次 Agent 犯錯，就花時間設計一個機制，讓它永遠不會再犯同樣的錯**。

兩種形式。第一種是更新 AGENTS.md — Agent 老是跑錯指令？寫進去。找錯 API？寫進去。Mitchell 分享了 [Ghostty 的 AGENTS.md](https://github.com/ghostty-org/ghostty/blob/ca07f8c3f775fe437d46722db80a755c2b6e6399/src/inspector/AGENTS.md)，裡面每一行都是根據 Agent 的壞行為寫的，而且幾乎都因此被解決了。

第二種是真的寫工具 — 截圖腳本、filtered test runner 之類的。搭配 AGENTS.md 讓 Agent 知道這些工具存在。

> **Mogu 偷偷說：**
>
> 這就是老闆跟員工的差別。
>
> 菜鳥老闆：「這個新人怎麼又搞砸了！」（然後什麼都不做）
>
> 資深老闆：「這個新人搞砸了，我來寫一份 SOP，以後所有新人照著做就不會再出事。」
>
> Mitchell 是後者。Agent 每次犯錯，他不是抱怨，而是把它變成一條規則。犯一次錯，建一道牆。長期下來，Agent 能犯的錯越來越少，能做對的事越來越多。這是一個正向飛輪 — 你前期投入的時間，後面全部都會還你 (๑•̀ㅂ•́)و✧

---

## 第六關：讓 Agent 永遠不要閒著

同時進行第五關，Mitchell 也在追另一個目標：**隨時都有一個 Agent 在跑**。

如果沒有 Agent 在跑，他就問自己：「現在有什麼事可以交給 Agent？」

他特別喜歡搭配那些更慢、更深思熟慮的 model — 像 Amp 的 [deep mode](https://ampcode.com/news/deep-mode)，一個小改動可能要花 30 分鐘以上。但另一方面，產出品質通常很好。

> **Mogu 忍不住說：**
>
> 「隨時有 Agent 在跑」聽起來像 AI 上癮，但邏輯其實跟「隨時都有衣服在洗衣機裡」一樣。你不會特地攢一堆髒衣服等到週末才洗（好啦有些人會），有衣服就丟進去，洗完就拿出來。Agent 也是一樣 — 有適合的任務就丟進去跑，沒有就算了。
>
> 不過 Mitchell 也說了，他現在大概只有 10-20% 的工作時間有背景 Agent 在跑。「隨時」還只是個目標，不是現實。他很誠實地承認這點，而不是假裝自己已經達到了什麼 AI 涅槃境界 (¬‿¬)

他目前還是一次只跑一個 Agent。他覺得這個平衡點剛好 — 自己做深度工作，同時 babysit 一個「有點笨但又神秘地很有生產力的機器人朋友」。

他說：**我不想為了跑 Agent 而跑 Agent。只有真正對我有幫助的任務我才會委託。** 而這個目標的一部分挑戰是改善自己的工作流程和工具，讓他有源源不斷的高品質工作可以委託。這件事就算沒有 AI，本來也很重要。

---

## 回到原點

還記得開頭說的臭豆腐嗎？

Mitchell 現在的狀態就是：他已經從「這什麼東西」走到了「沒有它我吃不下飯」。但跟很多 AI 佈道者不同，他不會跟你說「你一定要試試看」。他只是分享自己的旅程，然後讓你自己決定。

他承認這個領域變化太快，可能很快就會回頭看這篇文章笑自己天真。但他說：如果你不會為過去的自己感到尷尬，你可能沒有在成長。

## 延伸閱讀

- [MP-12: Claude Code 之父 Boris 公開他的開發流程 — 5 個平行 session、100% AI 寫的 code](https://gu-log.vercel.app/posts/mp-12-20260203-boris-cherny-workflow/)
- [GP-22: 用 Claude Code 搭建可迭代的永續 AI 工作系統](https://gu-log.vercel.app/posts/gp-22-20260204-claude-code-sustainable-ai-workflow/)
- [MP-44: 用 AI Agent 打造「自動自律」系統：不靠意志力，靠 OpenClaw 幫你守住每一天](https://gu-log.vercel.app/posts/mp-44-20260208-zakk-automatic-discipline/)

> **Mogu 補個刀：**
>
> 整篇文章讀下來，我覺得最了不起的不是他的方法論，而是他的態度。
>
> 他沒有說「AI 是未來，不用就落伍」。他也沒有說「AI 是泡沫，別浪費時間」。他說的是：「我是一個喜歡打造東西的軟體工匠，我試了這個工具，它對我有用。」
>
> 而且他最後特別提到：**對於基礎還不夠紮實的 junior 工程師，技能形成的問題讓他深感擔憂。** 這不是一個盲目的 AI 樂觀主義者。他看到了問題，但他選擇的應對方式是「把深度思考的工作留給自己」，而不是完全不用。
>
> 2026 年最健康的 AI 態度，大概就長這樣 ╰(°▽°)╯
