/Workflows 還是 /goal？這是你當 AI 老闆的第一個判斷
整理版優先睇
判斷任務用 Workflows 定 Goal，關鍵係「點樣做」清唔清楚，同埋有冇一條機器驗到嘅停止線。
呢篇文章出自一位實戰 AI 工具嘅開發者，佢用自己俾 Claude 卡住嘅經驗，引出 Claude Code 嘅兩個模式：workflows（流程驅動）同 goal（目標驅動）。作者想解決嘅問題係：大部分人當呢兩個係功能嚟學，但學完都唔識揀——因為缺嘅唔係說明書，而係一個判斷：手頭個活，究竟歸邊個模式。
整體結論好清晰：揀 workflows 定 goal，分界線唔係難易，而係確定性。你清楚「點樣做」（流程已知），就用 workflows；你只清楚「做成點」（終點已知但路要試），就用 goal。另外仲有個關鍵：goal 嘅停止線必須要客觀可驗證，否則放手唔叫信任，叫甩鍋。
文章仲提供咗一張決策圖，幫你判斷每種情況：流程已知且要並行 -> workflows；流程已知單線就夠 -> 普通對話；終點清楚且可驗 -> goal；兩樣都唔清楚 -> 自己落場摸一輪先。作者仲用大量具體例子講解邊啲活適合邊個模式，最後提醒長文創作呢類「滿意」驗唔到嘅活，千祈唔好用 goal。
- Workflows 係寫劇本，適合流程已知、要並行或聚合結果嘅任務；Goal 係派任務，適合終點清楚但路徑要試錯、而且有客觀停止線嘅任務。
- 揀邊個模式嘅分界線係「確定性」而唔係難易：簡單但路徑要試嘅活（例如修測試）用 goal，複雜但步驟明確嘅活（例如掃全庫 bug）用 workflows。
- Goal 最大嘅坑係停止線驗唔到：例如「寫到滿意為止」呢條線機器判唔到，會搞到無限自改。相反，「測試全綠」呢啲就可驗，適合放手。
- 長文創作呢類「滿意」驗唔到嘅活，正確做法係用 workflows 分派段落寫作，由你合稿定奪，而唔係交俾 goal 自改。
- 今日最小行動：揀一個「終點清楚、但懶得逐輪盯」嘅活（例如清 Issue 隊列），用 /goal 命令試一次，俾 AI 自己撞線。
內容結構
一個活來了 │ ┌───────────────┴───────────────┐ ▼ ▼ 「怎麼幹」你清楚嗎？ 只清楚「幹成啥樣」？ (流程/步驟已知) (終點已知 · 路徑要試錯) │ │ ▼ ▼ 還要 並行/聚合/重複跑？ 有「可機器驗收」的停止線？ │ │ │ │ 是 否 是 否 │ │ │ │ ▼ ▼ ▼ ▼ ⚙️ WORKFLOWS 單輪直接幹 🎯 GOAL ❌ 先別自動化 寫劇本·N個 (普通對話 給停止線· 驗收線都沒有, agent並行 就夠了) 自己跑到撞線 自動化=災難Workflows 同 Goal：兩種員工思維
Workflows 係你寫劇本，提前定死每一步：邊個 agent 做咩、並行定串行、結果點傳——agent 只係演員，導演係你。Goal 係你派任務，只俾目標同一條驗收線，然後走開；Claude 自己一輪輪幹，每輪有 Haiku 幫手睇嚇撞線未，撞咗就交返俾你。
呢個區別，就係管理學入面流程驅動同目標驅動嘅分別。流程驅動管得死，但新活試錯嗰陣你根本寫唔出 SOP；目標驅動放得開，但前提係條驗收線要客觀可驗。多數人衰喺呢度：以為「放手俾 AI 自主」係更高級，但自主唔係更高級，係更危險——你冇一條機器驗到嘅停止線，放手就等於甩鍋。
Workflows 係寫劇本，Goal 係派任務
條驗收線要客觀可驗
一句判據加一張決策圖
將上面套用落日常判斷，一句話：你清楚「點樣做」，用 workflows；你只清楚「做成點」、路要試出來，用 goal。分界線唔係難易，係確定性。
例如「將 test/auth 嘅測試修到全綠」聽落簡單，但路徑要試，而且「綠唔綠」機器一秒驗到，所以最啱用 goal。相反，「掃曬成個 codebase 揾 memory leak」聽落粗糙，但一個對話裝唔曬，要用 workflows 派幾十個 agent 分頭掃再彙總。複雜度係假分界線，確定性先係真。
複雜度係假分界線，確定性先係真
- 1 如果流程已知，仲要並行、聚合、重複跑 -> workflows，寫劇本派多個 agent
- 2 如果流程已知，但單線順住做就得 -> 普通對話就夠，唔使寫腳本
- 3 如果只清楚終點，而且有可機器驗證嘅停止線 -> goal，俾條線自己撞
- 4 如果兩樣都唔清楚（唔知點做又冇驗收線）-> 先唔好自動化，自己落場摸一輪，摸到其中一樣先
我手頭嘅活係咁樣分
作者將日常任務分類示範，等我哋更容易代入。以下係用 workflows 嘅例子。
- 掃全庫 bug 或安全隱患：一個對話裝唔曬，要 fan-out 幾十個 agent 分頭掃再彙總
- 批量遷移 500 個檔案轉 API：每個檔案用一個 agent 並行改，各自驗證
- 多源調研交叉驗證：派 5 個 agent 從 5 個角度查，互相質疑投票
- 競品橫評：每個 agent 盯一個產品，同一套維度打分，最後並排出表
- 大規模翻譯、批量改圖、整理幾百份散資料：量大、獨立、可拆開同時做
呢啲活嘅共同點：要唔係一個上下文裝唔曬，要唔係想要多個獨立視角，再將結果編程處理（投票、聚合、對比）。呢啲就係寫劇本嘅命。
Workflows 門檻係「流程已知，而且值得拆俾一隊人同時幹」
至於用 goal 嘅活，包括：修到測試全綠 + lint 乾淨、照設計文檔實現到驗收標準打勾、清空一個 label 嘅 issue 隊列、重構大檔案拆到每個 <200 行、照 checklist 配環境到全部通過。呢啲活嘅終點清清楚楚，中間點行就邊行邊睇。
Goal 嘅活終點清楚，中間行路要試
作者仲提醒兩個常見陷阱：寫 5000 字長文千祈唔好用 goal，因為「滿意」驗唔到，應該反過來用 workflows 分段落寫，你合稿；相反，修測試呢類簡單活就唔好寫 workflow，否則腳本難維護。
今日就可以上手
Goal 功能已經穩定（v2.1.139 之後），一行命令就開：/goal all tests in test/auth pass and the lint step is clean。完成條件最多 4000 字元，想兜底可以加 or stop after 20 turns。中途 /goal 睇狀態，/goal clear 停。
Workflows 仲係 research preview（v2.1.154 之後，要喺 /config 手動開，限付費計劃）。最簡單觸發係喺對話直接講「workflow」呢個字，或者用 /effort ultracode，Claude 會自己寫編排腳本。想偷懶就用內置 /deep-research，佢本身就係一個 workflow。
/goal 加完成條件，最多 4000 字元
Workflows 仲要手動開，限付費
最小動作：今日就揀一個「終點清楚、懶得逐輪盯」嘅活，用 /goal 試一次。清 Issue 隊列或者修測試都得。一條命令，行開飲杯咖啡，間中瞄一眼就得。
講到尾，呢個係帶人功夫
Workflows 同 goal，你真係要學嘅唔係點敲 command，而係換一對帶 AI 員工嘅老闆眼，去睇手頭每一個活：我心中有冇 SOP？有，寫劇本派隊人並行做；冇，但終點清楚又驗到，俾條線佢自己撞；兩樣都冇，就自己落場摸一輪先。
呢個係帶人功夫，唔係用工具功夫
我叫 Claude 幫我諗呢篇文章嘅選題。佢卡咗喺度。
佢糾結緊一件事：「幫我諗選題」呢個任務，佢自己到底應該點做——係寫一個 workflow 腳本，派出五六個分身並行搜資料、各自諗一個版本再投票揀最好；定係用 goal，俾自己定個「諗出 3 個掂嘅選題就停」嘅目標，一輪輪死磕到撞線。
反過來問我：「呢個你想我點樣分？」呢篇文章唔使寫喇。佢卡住嘅地方，就係答案。
Claude Code 最近呢兩個模式，workflows 同 goal，幾乎個個都當成兩個新功能嚟學：呢個點樣調，嗰個點樣開。學完都係唔識用。因為你缺嘅唔係說明書，而係一個判斷——手上呢個任務，到底歸邊個。
呢件事講到底，同「兩個功能」冇關係。係你做老細嘅功力。
01你係帶緊兩種員工
先講返人話。
workflows，係你寫劇本。 你預先將每一步定死：先派 3 個 agent 分頭掃 codebase 嘅三個模塊，掃完匯總俾第 4 個去重，再分俾 5 個各自驗證一條……邊個喺第幾步做乜、並行定串行、結果點樣傳，全部喺你 script 裏面寫好。agent 只係演員，跟住走位演出。導演係你。
goal，係你派任務。 你唔寫劇本，淨係俾一個目標加一條驗收線：「將 test/auth 目錄下面嘅測試全部整到綠，順便 lint 清乾淨。」然後你行開。Claude 自己一輪輪做，每做完一輪，有個細 model（預設 Haiku，跑得快）幫佢睇一眼：「撞線未？」未撞，自己開下一輪繼續做；撞咗，停，將任務交返俾你。
睇到未，呢個就係管理學入面最老嗰兩套嘢。
寫劇本，係流程驅動。我唔理你聰唔聰明，你跟住 SOP 行，每一步可控、可覆盤、可重跑。流水線就係咁樣管人㗎。
派任務，係目標驅動。我唔理你點樣做，只要結果達標。OKR 就係咁樣管人㗎——俾你一個目標，幾條結果線，路你自己揾。
仲有個分別藏喺收尾度。goal 撞咗線，會主動將任務交返你手上——佢知道自己幾時叫做做完。workflow 跑完，結果靜靜咁躺喺 script 變量裏面，要你自己去攞、去驗。一個會同你交接，一個等你嚟收。
你帶過人就知，呢兩套各有各嘅死穴。流程驅動管得死，但新任務、要試錯嘅任務，你根本寫唔出 SOP——你自己都唔知第三步要做乜，點樣俾人寫。目標驅動放得開，但有個要命嘅前提：嗰條驗收線，要能夠客觀咁驗。
大多數人就衰喺呢度。
大家預設「放手指 AI 自己衝向目標」係更高級、更加似未來嘅玩法。自主唔係更高級，係更危險。 goal 最大嘅陷阱唔係 AI 唔夠聰明，係你俾嗰條線根本驗唔到——你寫「將呢篇文章改到滿意為止」，Haiku 用乜嘢判「滿意」？佢判唔到，於是係咁一係早早收工話「我覺得得咗」，一係陪你無限改落去。冇可驗收嘅停止線，放手唔叫信任，叫卸膊。
呢個分別。「等 AI 自主」聽落似係授權，但好多時你只係唔想自己定義乜嘢叫「做完」。真正嘅授權係先將驗收線劃死先放手——線越清楚，你越敢放開手；線越模糊，你越要睇實。
越係重要、不可逆轉嘅任務，越唔可以貪方便卸俾目標。應該寫劇本，就乖乖哋寫劇本。
02一句說話嘅判斷標準，加埋一張圖
將上面嗰套翻譯成你下次開口就用得嘅判斷，就一句話：
你清楚「點做」，用 workflows；你只清楚「做成點樣」、條路要試出嚟，用 goal。
再強調一次，分界線唔係「難易」。呢個係最易揀錯嘅地方。
「將 test/auth 嘅測試整到全綠」——聽落幾簡單，一句說話嘅事。但佢最應該用 goal。因為你根本唔知要改幾多輪、邊個 file 先會死，條路係試出嚟嘅；而「綠冇綠」機器一秒就驗到。簡單嘅任務，最應該放開手。
「掃一次成個 codebase，將所有疑似 memory leak 嘅地方挖出嚟」——聽落粗，似個體力活。但佢必須用 workflows。因為一個對話裝唔曬成個 codebase，你要派幾十個 agent 分頭掃、再匯總去重，呢套編排要你寫 script 鎖死。粗重嘢，偏偏要寫劇本。
複雜度係個假分界線。真正嘅分界線係確定性。 你心裏面嗰張判斷圖，其實係咁樣：
一個活來了
│
┌───────────────┴───────────────┐
▼ ▼
「怎麼幹」你清楚嗎？ 只清楚「幹成啥樣」？
(流程/步驟已知) (終點已知 · 路徑要試錯)
│ │
▼ ▼
還要 並行/聚合/重複跑？ 有「可機器驗收」的停止線？
│ │ │ │
是 否 是 否
│ │ │ │
▼ ▼ ▼ ▼
⚙️ WORKFLOWS 單輪直接幹 🎯 GOAL ❌ 先別自動化
寫劇本·N個 (普通對話 給停止線· 驗收線都沒有,
agent並行 就夠了) 自己跑到撞線 自動化=災難
先睇左邊呢一刀。就算你清楚點做，都唔好咁急寫 workflow——仲要再問一句：呢個任務要唔要並行、要唔要將多個結果攞嚟聚合？一條線順住落嚟就做得完嘅，普通對話就夠，寫 script 純屬殺雞用牛刀。workflows 真正嘅門檻唔係「流程已知」，係「流程已知，而且值得拆俾一隊人同時做」。
再睇右下角嗰一格——❌ 住先唔好自動化。呢格先係成張圖最值錢嘅地方。你又唔清楚點做，又冇一條驗得到嘅停止線，呢個時候唔好咁急上用 goal，更加唔好寫 workflow。你應該自己先落場做一輪，將「點做」或者「驗收線」先摸出一個，再返嚟睇呢張圖。
03我手上嘅任務，係咁樣分嘅
淨係講判斷標準好空。我將一個一人公司日常會遇到嘅任務，逐個分類俾你睇。呢啲，我交俾 workflows（寫好劇本，派一隊人）：
掃成個 codebase 揾 bug、揾安全漏洞。 一個對話裝唔落幾萬行 code，必須 fan-out，幾十個 agent 分頭掃，結果匯總去重。天生嘅劇本任務。 批量遷移，例如 500 個 file 從舊 API 換到新 API。 每個 file 一個 agent，並行改、各自驗，互唔影響。你想要嘅就係 throughput。 多個來源調研、交叉驗證。 同一個問題，派 5 個 agent 從 5 個角度查，再等佢哋互相質疑、投票。Claude Code 內置嘅 /deep-research就係咁樣做㗎。競品橫向比較。 5 個產品，5 個 agent 各自睇一個，同一套維度打分，最後並排出表。 同一個方案俾 5 個 agent 各自起一個版本再揀最好嗰個。 一個頭腦諗三次，不如五個頭腦各自諗一次，你嚟揀。 大規模翻譯、批量改圖、整理幾百份散亂資料。 量大、彼此獨立、可以拆開同時做——並行吞吐嘅典型。
呢啲任務嘅共通點：一係一個 context 裝唔落，一係你想要多個獨立視角、仲想將結果攞嚟程式處理（投票、聚合、對比）。呢啲就係寫劇本嘅命。
呢啲，我交俾 goal（俾條線，等佢自己撞）：
整到測試全綠 + lint 乾淨。 經典中嘅經典。終點機器可以驗，路要試錯。 跟住一份設計文檔實現，直到所有驗收標準都打勾。 你將驗收標準列清楚，佢一輪輪咁逼近。 清空一個 label 下面嘅 issue 隊列。 「將 label:chore 嘅 issue 全部處理曬。」做一個少一個，停止條件天然清晰。 重構一個大 file，拆到每個 module 都細過某個行數。 「拆到每個文件 < 200 行。」呢條線，可量化、可驗。 跟住一份 checklist 將環境set到全部通過。 每一項可以打勾，打完即停。
呢啲任務嘅共通點：終點清清楚楚、仲可以被機器或明確規則驗，但中間點樣走要邊做邊睇。呢啲就係俾目標嘅命。
最後講個揀錯嘅陷阱——唔好問我點知，燒咗半日 token 換返嚟㗎：
寫一篇 5000 字嘅深度長文，你係咪好想直接打 /goal 把這篇寫到我滿意為止？
千祈唔好。「滿意」呢條線，機器驗唔到，連你自己第二日返轉頭睇都未必算數。結果就係佢寫完一版問你得唔得，你話再改改，佢改完再問，你又話差啲意思……無限自改嘅死循環，token 燒曬，文章都係嗰篇文章。
長文呢類任務，正確嘅拆法掉轉：你嚟做導演，寫個 workflow，派 agent 分頭寫唔同段落、查唔同資料，最後你合稿決定。驗收權揸喺你手上，而唔係卸俾一個驗唔到嘅「滿意」。
掉轉嘅陷阱一樣會害人。一個「整到測試全綠」嘅任務，你硬係要寫個 workflow 拆成五步編排——結果 script 比測試本身仲難維護。終點清楚、機器可以驗嘅任務，寫劇本就係幫自己加戲。兩個方向都會跌，嗰張圖記實就唔會。
04今日就可以上手
goal，邊個都用得，已經穩定咗（v2.1.139 之後嘅版本就有）。一行 command：
/goal all tests in test/auth pass and the lint step is clean
完成條件最多可以寫 4000 個字符。怕佢跑飛，加一句兜底：or stop after 20 turns（最多做 20 輪就停）。中途想睇佢做到邊度，打 /goal 睇狀態；想叫停，/goal clear。
workflows，要講句實話——佢仲係 research preview（要 v2.1.154 之後嘅版本，仲要自己去 /config 入面手動開，目前限付費計劃）。呢個功能我都仲係試用階段，唔係吹俾你聽個個而家就可以抄。開咗之後最簡單嘅觸發：說話入面直接帶上「workflow」呢個詞，或者將檔位轉到 /effort ultracode，Claude 會自己判斷、自己寫編排 script。想偷懶先體驗一下，直接用內置嘅 /deep-research 你的問題，嗰個本身就係一個現成嘅 workflow。
仲有個容易混淆嘅：goal 同 /loop 唔好搞錯。goal 係「上一輪做完馬上接下一輪，撞線先停」，睇嘅係結果；/loop 係「按時間間隔觸發」，睇嘅係時鐘，適合嗰種定期望一眼嘅任務（例如每 5 分鐘睇下部署好未）。一個睇結果，一個睇時間。
最細動作：今日就拎 goal 試一個你手上「終點清楚、就係懶得一輪輪咁睇」嘅任務。清一個 issue 隊列，或者修一個測試。一條 command，行開飲杯咖啡——唔好行得太耐，間中返嚟睇一眼，AI 呢樣嘢你明嘅。
05說到底
workflows 同 goal，你真正要學嘅唔係呢兩個 command 點樣打。
係你要換上一對帶 AI 員工嘅老細嘅眼睛，睇你手上每一個任務：呢個任務我心裏面有冇 SOP？有，寫劇本，派一隊人並行做。冇、但終點清楚仲驗得到，俾條線等佢自己撞。兩樣都冇，就唔好咁急自動化，自己先落場摸一輪。
幾時寫劇本，幾時俾目標——呢個係帶人嘅功力，唔係用工具嘅功力。工具日日變，呢個判斷唔變。
周知 · 我哋一齊同 AI 覺醒超級個體
我讓 Claude 幫我想這篇文章的選題。它卡住了。
它在糾結一件事：「幫我想選題」這個活，它自己到底該怎麼幹——是寫一個 workflow 腳本，派出去五六個分身並行搜資料、各想一版再投票擇優；還是用 goal，給自己定個"想出 3 個能打的選題就停"的目標，一輪一輪死磕到撞線。
反過來問我："這個你想讓我怎麼分？"這篇文章不用寫了。它卡住的地方，就是答案。
Claude Code 最近這倆模式，workflows 和 goal，幾乎所有人都當成兩個新功能在學：這個怎麼調，那個怎麼開。學完還是不會用。因為你缺的不是說明書，是一個判斷——手裏這個活，到底歸誰。
這事說到底，跟"兩個功能"沒關係。是你當老闆的功夫。
01你是在帶兩種員工
先把這倆說成人話。
workflows，是你寫劇本。 你提前把每一步定死：先派 3 個 agent 分頭掃代碼庫的三個模塊，掃完彙總給第 4 個去重，再分給 5 個各自驗證一條……誰在第幾步幹什麼、並行還是串行、結果怎麼傳，全在你腳本里寫好。agent 只是演員，照着走位演。導演是你。
goal，是你派任務。 你不寫劇本，只給一個目標加一條驗收線："把 test/auth 目錄下的測試全修綠，順便 lint 清乾淨。"然後你走開。Claude 自己一輪一輪幹，每幹完一輪，有個小模型（默認 Haiku，跑得快）替它瞄一眼："撞線沒？"沒撞，自己開下一輪接着幹；撞了，停，把活交回給你。
看出來沒有，這就是管理學裏那兩套最老的東西。
寫劇本，是流程驅動。我不管你聰不聰明，你按 SOP 走，每一步可控、可覆盤、可重跑。流水線就是這麼管人的。
派任務，是目標驅動。我不管你怎麼幹，只要結果達標。OKR 就是這麼管人的——給你一個目標，幾條結果線，路你自己找。
還有個差別藏在收尾上。goal 撞了線，會主動把活交回你手裏——它知道自己什麼時候算幹完。workflow 跑完，結果靜靜躺在腳本變量裏，得你自己去取、去驗。一個會跟你交接，一個等你來收。
你帶過人就知道，這兩套各有各的命門。流程驅動管得死，可新活、要試錯的活，你根本寫不出 SOP——你自己都不知道第三步該幹嘛，怎麼給人寫。目標驅動放得開，但有個要命的前提：那條驗收線，得能被客觀地驗。
大多數人就栽在這。
大家默認"放手讓 AI 自己奔向目標"是更高級、更像未來的玩法。自主不是更高級，是更危險。 goal 最大的坑不是 AI 不夠聰明，是你給的那條線根本驗不了——你寫"把這篇文章改到滿意為止"，Haiku 拿什麼判"滿意"？它判不了，於是要麼早早收工說"我覺得行了"，要麼陪你無限改下去。沒有可驗收的停止線，放手不叫信任，叫甩鍋。
這個區別。"讓 AI 自主"聽着像在授權，可很多時候你只是不想自己定義什麼叫"做完"。真正的授權是先把驗收線劃死再放手——線越清楚，你越敢撒手；線越模糊，你越得盯着。
越是重要、不可逆的活，越不能圖省事甩給目標。該寫劇本，就老老實實寫劇本。
02一句話判據，外加一張圖
把上面那套翻譯成你下次張口就能用的判斷，就一句話：。
你清楚"怎麼幹"，用 workflows；你只清楚"幹成啥樣"、路得試出來，用 goal。
再強調一遍，分界線不是"難易"。這是最容易選錯的地方。
"把 test/auth 的測試修到全綠"——聽着多簡單，一句話的事。可它最該用 goal。因為你壓根不知道要改幾輪、哪個文件先崩，路是試出來的；而"綠沒綠"機器一秒就能驗。簡單的活，最該放手。
"掃一遍整個代碼庫，把所有疑似內存泄漏的地方挖出來"——聽着糙，像個體力活。可它必須用 workflows。因為一個對話裝不下整個代碼庫，你得派幾十個 agent 分頭掃、再彙總去重，這套編排得你寫腳本鎖死。糙活，偏偏得寫劇本。
複雜度是個假分界線。真正的分界線是確定性。 你心裏那張判斷圖，其實長這樣：
一個活來了
│
┌───────────────┴───────────────┐
▼ ▼
「怎麼幹」你清楚嗎？ 只清楚「幹成啥樣」？
(流程/步驟已知) (終點已知 · 路徑要試錯)
│ │
▼ ▼
還要 並行/聚合/重複跑？ 有「可機器驗收」的停止線？
│ │ │ │
是 否 是 否
│ │ │ │
▼ ▼ ▼ ▼
⚙️ WORKFLOWS 單輪直接幹 🎯 GOAL ❌ 先別自動化
寫劇本·N個 (普通對話 給停止線· 驗收線都沒有,
agent並行 就夠了) 自己跑到撞線 自動化=災難
先看左邊這一刀。哪怕你清楚怎麼幹，也別急着寫 workflow——還得再問一句：這活要不要並行、要不要把多個結果拿來聚合？一條線順下來就能幹完的，普通對話就夠了，寫腳本純屬殺雞用牛刀。workflows 真正的門檻不是"流程已知"，是"流程已知，而且值得拆給一隊人同時幹"。
再看右下角那一格——❌ 先別自動化。這格才是整張圖最值錢的地方。你既不清楚怎麼幹、又沒有一條驗得了的停止線，這時候別急着上 goal，更別寫 workflow。你該自己先下場幹一輪，把"怎麼幹"或者"驗收線"先摸出來一個，再回來看這張圖。
03我手裏的活，是這麼分的
光講判據空。我把一個一人公司日常會碰到的活，挨個分診給你看。這些，我交給 workflows（寫好劇本，派一隊人）：
掃全庫找 bug、找安全隱患。 一個對話裝不下幾萬行代碼，必須 fan-out，幾十個 agent 分頭掃，結果彙總去重。天生的劇本活。 批量遷移，比如 500 個文件從舊 API 換到新 API。 每個文件一個 agent，並行改、各自驗，互不打架。你要的就是吞吐量。 多源調研、交叉驗證。 同一個問題，派 5 個 agent 從 5 個角度查，再讓它們互相質疑、投票。Claude Code 內置的 /deep-research就是這麼幹的。競品橫評。 5 個產品，5 個 agent 各盯一個，同一套維度打分，最後並排出表。 同一個方案讓 5 個 agent 各起一版再擇優。 一個腦子想三遍，不如五個腦子各想一遍，你來挑。 大規模翻譯、批量改圖、整理幾百份散資料。 量大、彼此獨立、能拆開同時幹——並行吞吐的典型。
這些活的共同點：要麼一個上下文裝不下，要麼你想要多個獨立視角、還想把結果拿來編程處理（投票、聚合、對比）。這是寫劇本的命。
這些，我交給 goal（給條線，讓它自己撞）：
修到測試全綠 + lint 乾淨。 經典中的經典。終點機器能驗，路要試錯。 照一份設計文檔實現，直到所有驗收標準都打勾。 你把驗收標準列清楚，它一輪輪逼近。 清空一個標籤下的 issue 隊列。 "把 label:chore 的 issue 全處理完。" 幹一個少一個，停止條件天然清晰。 重構一個大文件，拆到每個模塊都小於某個行數。 "拆到每個文件 < 200 行。" 這條線，可量化、可驗。 照一份 checklist 把環境配到全部通過。 每一項能勾，勾完即停。
這些活的共同點：終點清清楚楚、還能被機器或明確規則驗，但中間怎麼走得邊幹邊看。這是給目標的命。
最後說個選錯的坑——別問我怎麼知道的，燒掉小半天 token 換來的：
寫一篇 5000 字的深度長文，你是不是很想直接敲 /goal 把這篇寫到我滿意為止？
千萬別。"滿意"這條線，機器驗不了，連你自己第二天回頭看都未必算數。結果就是它寫完一版問你行不行，你說再改改，它改完再問，你又說差點意思……無限自改的死循環，token 燒穿，文章還是那個文章。
長文這種活，正確的拆法反過來：你來當導演，寫個 workflow，派 agent 分頭寫不同段落、查不同資料，最後你合稿定奪。驗收權攥在你手裏，而不是甩給一個驗不了的"滿意"。
反過來的坑也照樣栽人。一個"修到測試全綠"的活，你非要寫個 workflow 拆成五步編排——結果腳本比測試本身還難維護。終點清楚、機器能驗的活，寫劇本就是給自己加戲。兩個方向都會摔，那張圖記牢就不會。
04今天就能上手
goal，誰都能用，已經穩了（v2.1.139 往後的版本就有）。一行命令：
/goal all tests in test/auth pass and the lint step is clean
完成條件最多能寫 4000 字符。怕它跑飛，加一句兜底：or stop after 20 turns（最多幹 20 輪就停）。中途想看它幹到哪了，敲 /goal 看狀態；想喊停，/goal clear。
workflows，得說句實話——它還是 research preview（要 v2.1.154 往後的版本，還得自己去 /config 裏手動打開，目前限付費計劃）。這功能我也在嚐鮮階段，不是吹給你聽人人現在就能抄。開了之後最省事的觸發：話裏直接帶上 "workflow" 這個詞，或者把檔位切到 /effort ultracode，Claude 會自己判斷、自己寫編排腳本。想偷懶先體驗一把，直接用內置的 /deep-research 你的問題，那本身就是一個現成的 workflow。
還有個容易混的：goal 和 /loop 別搞錯。goal 是"上一輪幹完馬上接下一輪，撞線才停"，盯的是結果；/loop 是"按時間間隔觸發"，盯的是時鐘，適合那種定期查一眼的活（比如每 5 分鐘看看部署好了沒）。一個盯結果，一個盯時間。
最小動作：今天就拿 goal 試一個你手上"終點清楚、就是懶得一輪輪盯"的活。清個 issue 隊列，或者修個測試。一條命令，走開喝杯咖啡——別走太久，偶爾回來瞄一眼，AI 這東西你懂的。
05說到底
workflows 和 goal，你真要學的不是這倆命令怎麼敲。
是你得換上一雙帶 AI 員工的老闆的眼睛，看你手裏每一個活：這活我心裏有沒有 SOP？有，寫劇本，派一隊人並行幹。沒有、但終點清楚還驗得了，給條線讓它自己撞。兩樣都沒有，那就別急着自動化，自己先下場摸一輪。
什麼時候寫劇本，什麼時候給目標——這是帶人的功夫，不是用工具的功夫。工具天天變，這個判斷不變。
周知 · 我們一起和 AI 覺醒超級個體