這是 AI 上手系列的第三篇。第一篇講怎麼裝起來，第二篇講怎麼跟它講話、怎麼設關卡。
第二篇的結尾我說：難的從來不是「怎麼問」，是「怎麼設計流程」。
這篇要把那句話收掉。答案可能跟你想的相反：流程不是設計出來的，是長出來的。
最常見的卡點：「我不知道要怎麼開始規劃」
我被問過很多次類似的問題：「你那套自動化好厲害，我要怎麼規劃我自己的？」
老實說，我從來沒有規劃過。我三月的時候只做了一件事：挑了一件每週都在重複的小事，叫它做一次。
今天回頭看，我的規則檔、十幾個 skill、一堆自動排程，沒有一個是事先設計的。每一個都是同一件事重複了幾次之後，才「升級」成現在的樣子。
所以如果你卡在「不知道怎麼開始」，好消息是：你不需要想清楚才開始，你只需要開始得夠小。
起手式：五件事講清楚，其他都不用
挑好那件小事之後，交代它的時候把這五件事講清楚。這不是我發明的，是把官方 best practices 濃縮成非工程師版本：
① 目標講清楚：你要什麼、給誰用、拿去做什麼。「幫我整理逐字稿」不如「整理成 SOAP 格式，這是要放進病歷系統的」。
② 只補它不知道的：你們科的慣例、單位的格式、只有你知道的眉角。模型已經會的不用教：SOAP 是什麼不用解釋，你們科的 SOAP 長什麼樣才要講。每一句廢話都在稀釋它的注意力（原因寫在第二篇「為什麼它會越聊越笨」那節）。
③ 界線先講：哪些檔案不准動、哪些事要先問過你。而且真正的紅線不要只用嘴巴講，第二篇的三層機制（hooks / permissions / CLAUDE.md）就是拿來放這個的。
④ 訂「怎樣算做完」：這條是官方排第一優先的建議，也是我覺得投資報酬率最高的一條。給它一個它能自己跑的檢查：
- ❌「幫我整理這些逐字稿」
- ✅「整理完自己檢查一遍：每一份都要有四段、每段都要有內容，缺的標出來給我」
⑤ 先跑一個爛版本：不滿意再一句話改。迭代永遠比一次寫滿快。
就這樣。不用畫流程圖、不用寫規格書。
流程怎麼長大：重複第三次，就升一級
真正的重點來了。你的「流程」不是某天坐下來設計的，它是照一個很簡單的規則長出來的：
同一件事重複到第三次，就往上升一級。
| 你發現自己在… | 升級動作 | 成本 |
|---|---|---|
| 同一句話講第三次（「回我繁體中文」） | 寫進 CLAUDE.md | 一行字 |
| 同一套多步驟流程做第三次（先轉檔、再整理、再歸檔） | 包成 skill：跟它說「把剛剛這整套存成一個 skill」 | 一句話 |
| 發現某件事絕對不能出錯（改到原始檔、送出病人資料） | 交給程式關卡（hook / permissions） | 要動手設定，但一勞永逸 |
三層的差別在第二篇講過了，這裡只補一句：寫在規則裡是建議，做成機制才是保證。 界線越重要，就該住在越下面那層。
這個階梯還有一個隱藏的好處：每一級都是你已經驗證過的東西。你不是在憑空設計一個 skill，你是把一套「已經手動跑成功三次」的流程存起來而已。設計可能會錯，重複不會。
驗收的習慣：這篇最重要的一節
起手式的第④點（訂「怎樣算做完」）值得單獨拉出來講，因為它不是五件事之一而已。它是整套方法裡唯一「做與不做會決定你能走多遠」的習慣。
驗收有三個層次，照順序養成：
層次一：單次驗收。 每個任務交代時就附上檢查方法，讓它做完自己查（「每一份都要有四段、缺的標出來給我」）。這是起手式教的。
層次二：可重跑的驗收。 把檢查存下來，變成隨時可以再按一次的按鈕。差別很大：單次驗收保證「這次做對了」，可重跑的驗收保證「以後改東西也不會弄壞它」。工程師管這個叫回歸測試（regression test），但概念本身跟程式無關：哪怕你的檢查只是「數一數每份紀錄都有四段」，能重跑，就有資格叫驗收。
層次三：驗收先行。 這是官方 best practices 裡明講的工作流：先寫檢查、確認它現在會失敗，再叫 AI 做到通過。聽起來像工程師的儀式，翻成白話就是：開工前先給它看一個「做對了長這樣」的具體例子。它有目標可以自己迭代，你也不會做完才發現彼此想的不一樣。
然後是習慣面的三條紀律，跟層次一樣重要：
- 沒有驗收的流程，不算完成。哪怕檢查很陽春，也要有
- 「它說做完了」不算數，檢查跑過才算。AI 回報成功的語氣，跟真的成功一模一樣
- 檢查失敗要明講，不能靜默跳過。一項沒跑的檢查，讀起來跟「檢查過了沒問題」長得一模一樣，這是最陰險的一種錯
在醫院工作的人應該很有感：我們靠的從來不是「大家都很小心」，是 checklist、雙人核對、機器警報。對 AI 也一樣，你不是在監工，你是在設計流程。
而且可重跑的驗收還有一個更大的用途。它是下一節的入場券。
順帶一提，這個習慣不只用在寫程式。我後來做臨床資料去識別化的工具（chart-scrub）時，最後一步就是讓程式拿它知道的每一個真名，回頭搜自己剛產出的輸出，有殘留就判定整筆失敗。同一個道理，換一個場景而已。
長大的代價：你的專案會變成貼布屋
先開始、先跑爛版本、重複了再升級，這套方法有一個必然的副作用，遲早會找上你：專案是用貼的長大的。
每次你都只叫 AI「補一個功能」「修一個地方」，它也真的就只補那一塊。幾個月後你回頭看，東一塊西一塊，同樣的邏輯散在三個地方，整體長得不像一個規劃過的東西，像一間貼滿補丁的房子。
先說清楚：這不是 AI 的缺陷，這是「先求能動」的天然代價。 軟體工程界甚至有個專有名詞叫技術債（technical debt）：為了快，先跟未來的自己借時間，之後連本帶利要還。人類工程師寫了幾十年程式都是這樣，AI 只是把「蓋得快」放大了，債也累積得快。
重點不是避免欠債（避免不了，那是起步快的代價），是知道什麼時候該還。這幾個訊號出現任兩個，就是還債的時候：
- 改 A 會壞 B，而且你事先猜不到會壞哪裡
- 同一段邏輯出現在三個地方，改一處要記得改三處
- 你開始「怕」動某一塊，繞著它走
- AI 越補越吃力：每次修補，它都要先花大把時間搞懂之前的補丁
還債的方法不是「請它整理一下」，那只會多一層補丁。是重蓋，具體三步：
- 先畫現況地圖：請它把整個專案讀一遍，寫一份「這裡面有哪些功能、資料怎麼流、哪裡最亂」的盤點。不急著動手，先看清楚
- 基於地圖重新設計，開新版本搬過去：不是在原地大改（原地大改 = 最大張的補丁），是架好新結構，把功能一塊一塊搬進去
- 搬一塊，跑一輪驗收，再搬下一塊：這就是上一節說的入場券。沒有可重跑的驗收，重蓋是賭博；有，每搬一步你都知道有沒有壞
還有一個很實際的建議：重蓋的時刻，值得用你手上最強的模型。 平常修修補補，一般的模型就夠；但架構決策做錯，後面每一步都在錯的地基上蓋。我自己的用法是：日常的活交給快的便宜的，動骨架的時候才請出最強的，這也是省額度最合理的分配方式。
那，要不要一開始就給它一張地圖？
講到這裡你可能會想：既然貼布是宿命，那我一開始就把架構規劃好，不就沒這個問題了？
問題在於：專案第一天的你，是最不了解這個專案的你。 你還不知道哪些功能會留下來、哪些三天後就發現不需要。這時候做的詳細設計，大部分會錯，然後你會捨不得丟（都畫那麼久了）。這正是「先跑爛版本」想避免的陷阱，別讓它從另一個門走回來。
官方的工作流也是這個立場：複雜任務拆成「探索 → 計畫 → 執行」，但那個「計畫」是方向確認，不是詳細設計。先讓它講打算怎麼做、你看過再動手，就這個層級。
所以我的答案是折衷的：給一張輕地圖，一頁就好，只回答三件事：
- 這個專案為了什麼存在、給誰用
- 大概分幾塊（例如：抓資料的、整理的、輸出的）
- 什麼東西絕對不能混在一起（例如：病人資料跟程式碼永遠分開放；原始檔跟產出檔分開）
邊界先畫死，細節讓它長。一句話總結這節：地圖要粗，驗收要細。 方向用粗的地圖管、品質用細的驗收管，中間留給它自由發揮，這是我目前覺得最不吃力的平衡點。
說明書會過期：定期刪，跟定期加一樣重要
最後這節，是整個系列我最想講、也最少人講的一件事。
「它做錯一件事，我就加一行規則」——這個習慣短期完全正確（第二篇就是這樣教的），但它有一個很少人提的下半場：AI 的說明書會過期。
模型大約每半年明顯變聰明一次。你半年前為了防呆寫的規則，現在很可能不但沒用，還在幫倒忙：
- 官方自己的文件就寫明：規則檔越長，每一條被遵守的機率越低。你加的每一條防呆，都在稀釋真正重要的那幾條
- 新一代模型對指令的解讀更字面。舊時代那種「如有疑問，務必使用某某工具」的保險句，現在反而會讓它過度使用工具。以前的保險，變成現在的 bug
- 還記得 2023 年那些教學嗎？指派角色、防編造咒語、手動貼資料。第二篇開頭破掉的那三招，當年可都是「最佳實踐」
所以要養成一個跟「加規則」對稱的習慣：定期回頭刪規則。 判斷標準一句話：
這條規則存在，是因為它做不到，還是因為我以前被雷過？
前者留著。後者？先拿掉試一次，十之八九你會發現它早就不需要了。
（Claude Code 甚至有內建工具幫你做這件事：/doctor 會主動建議刪掉那些「它自己看就知道」的段落。）
順帶一提，要定期瘦身的不只說明書，你的硬碟也是。agent 工作時會產生一堆中間產物：轉檔的半成品、下載的暫存、跑壞重跑的舊版本，放著不管會無限膨脹。哪天發現電腦莫名其妙滿了，別自己翻，直接跟它說：「我的電腦太滿了，幫我找出可以刪的東西，列出來讓我看過再清」。兩個重點：讓它列、你來裁決，別讓它自己決定刪什麼；然後把「暫存檔放哪、多久清一次」寫進規則檔，之後它自己會守。
收尾
把這篇串起來，是一條完整的生命週期：
- 開始得夠小：挑一件每週重複的小事，五件事講清楚
- 重複的事升一級：講三次的寫進規則、做三次的包成 skill、不能錯的交給機制
- 每個流程都配可重跑的驗收：它說做完不算，檢查跑過才算
- 長歪了就重蓋：訊號出現就畫現況地圖、開新版搬家，搬一塊驗一輪，這時才動用最強的模型
- 每半年回頭刪：砍掉那些「以前被雷過」才加的規則
地圖要粗，驗收要細，說明書要定期瘦身。
你的流程半年後長什麼樣，不是今天設計出來的——是每次多寫一行、每半年刪掉幾行，長出來的。
我三月的那個「小事」，是把一個資料夾的逐字稿整理成筆記。就一句話的事。
你的呢？
—