AI 工作流程怎麼設計？先刪掉「假等待」那幾格，別急著加 AI

七月中開始，X 上冒出一個新詞，叫 graph engineering（圖工程）。照 The AI Operator 的考據，引信是 Peter Steinberger 七月十七、十八號前後在 X 上的一句話，然後就燒開了。

先講一句可能會得罪人的話：這個詞紅起來的時候，沒有任何新東西跟著出貨。

沒有新模型，沒有新框架，沒有新功能。詞是後來的討論自己長出來的。

先說清楚：詞是新的，事情不新

Greg Isenberg 在他的 The Startup Ideas Podcast 用一整集講這個題目，他自己開場就先懷疑了一輪。他說他第一次看到這個詞的反應是：「這是真東西，還是我們又發明了一個名詞，讓大家覺得自己落後？」

他順手列了一串跑馬燈：prompt engineering（提示工程）、context engineering（脈絡工程）、agent engineering、vibe coding、loop engineering，然後現在是 graph engineering。

這個懷疑很健康，而且有人幫他驗證了。

Data Science Dojo 寫過一篇專門盤點這件事，結論相當不客氣。他們列了一排框架：LangGraph、Google ADK、微軟 Agent Framework、CrewAI、LlamaIndex Workflows、OpenAI Agents SDK，這些東西用「節點、邊、共享狀態」來蓋 agent，已經蓋了兩年多。

然後補上那句最傷的：「如果你用過上面任何一個，你早就在做 graph engineering 了，只是它以前叫別的名字。」

所以名詞通膨是真的。

但 Greg 那集裡確實有幾樣東西值得抄，而且抄的成本很低。我把它拆完之後，真正還沒被講爛的只剩三件事。

在那之前，他有一句定義我覺得是全片最好的，先給你：

提示工程是「你怎麼問」，脈絡工程是「你餵它什麼資料」，圖工程是「你怎麼設計 AI 周圍的工作流程」。

目的只有一個：讓事情不要全部擠在一個又大又亂的對話框裡。

以前你想把 AI 用好，想的是怎麼把那句話寫得更精準。現在你要想的是，這件事該被拆成幾段、哪幾段可以同時跑、誰來查、誰來拍板。

這幾條我已經寫過了，直接給你連結

先把重複的部分交代掉，這段我不重講。

Greg 那集裡的「拆成步驟、平行研究、放一個獨立的質疑者、最後留一道人工把關」，這幾條站上都寫過了，而且寫得比這篇細：

• 做事的跟查核的要分開、怎麼設計查核的那一關 → 〈用 AI 的高手不寫更長的 prompt，他們設計「驗收迴圈」〉
• 為什麼要有一個專門找碴的角色，以及它什麼時候不划算 → 〈你的 AI 需要一個天敵〉
• 人工關卡該放哪、哪六類事情 AI 絕對不能自己按下去、什麼時候該停 → 〈Codex goal 指令怎麼寫〉

想看就點進去，這裡直接跳過。

第一件事：把「假等待」那幾格刪掉

Greg 講「一張好的圖該做到哪些事」的時候，第一條是 remove fake waiting，刪掉假等待。他講完這一句就過去了。

我覺得這句是全片最值錢的，因為它跟大家現在的思考方向是反的。

大家現在想的都是加法。這個流程要加幾個 agent？要不要加一個查核的？要不要再加一個彙整的？

刪格子這件事，幾乎沒人在問。

怎麼分辨真的要等和假等待

給你一個判準，就一句話：

如果這一格永遠不回你，後面那一格是不是真的做不下去？

做不下去，那是真依賴。做得下去，那就是假等待。

真的要等的，大概是這幾種：

• 等客戶回覆確認素材。對方是外部主體，你控制不了。
• 等主管核准檔期預算。這是授權問題，弄錯代價很高。
• 等金流、物流系統回拋結果。事實還沒發生，你等的是事實本身。
• 等 A/B 測試累積到足夠樣本。統計上的答案還不存在，早看只會看錯。

這四種你急也沒用，因為你在等一個「還不存在的事實」。真依賴要解的是另一個題目：怎麼讓流程停得住、隔幾天還能接回來不掉進度。那題我另外寫。

這篇只處理剩下那一種。

假等待的長這樣：

• 等競品資料收齊，才開始寫自己的定位。這兩件事根本不互相依賴，可以同時跑。
• 等文案定稿，才開始想主視覺。只要 brief 定了，文案跟視覺就能並行，真正要對齊的只有最後那一次。
• 等報表跑完，才開始擬假設。假設你現在就寫得出來，報表是拿來驗證它的。
• 等攝影師交完整批照片，才開始寫商品文案。有規格表就能動筆了。
• 等月結完，才做檔期分析。檔期都打完了才復盤，來不及。

這五格有一個共同點：它們等的不是事實，是人的節奏。

這種結構在實體產業裡也一樣。我在雨傘產業待過七年，工廠業務、品牌、百貨專櫃都待過，傳統製造與零售的流程大致是什麼長相，我算有點概念：關卡會隨著時間越積越多，而且新增容易、取消很難。真正需要有人拍板的關卡當然存在，品管站該卡就是要卡，因為不良品流下去代價很高。但一條走久了的流程，裡面通常混著不少純粹是「順便讓誰知道一下」的站。

產線是這樣，你的 AI 工作流程圖也是這樣。

以前你畫流程圖，是為了讓每個人知道自己什麼時候該動。現在你畫流程圖，是為了找出哪幾格根本不用有人動。

一個算術，讓你知道格子為什麼要少

還有一個該把格子壓少的理由，這個理由是算術，不是感覺。

假設你圖上每一格都有 95% 的成功率。95% 聽起來很高吧？五格串起來，0.95 的五次方，剩下 77%。如果每一格是 85%，五格串完只剩 44%。

（這組算式在 The AI Operator 的 graph engineering 指南裡也出現過，我自己按過計算機，數字對得上。）

我要特別標清楚：95% 跟 85% 都是假設值，不是任何工具測出來的效能，也不能拿去推算你會少賺多少錢。

它證明的只有一件結構性的事：格子會互相稀釋。

所以每多留一格沒必要的格子，你付的不只是時間，是整條鏈的可靠度。

第二件事：你在畫的是知識圖，還是代理圖？

Greg 說，大家講「圖」的時候其實在講兩件不同的事，混淆多半是從這裡來的。

知識圖（knowledge graph） 幫 AI 理解「誰跟誰有關係」。這個客戶在這家公司、這家公司用這個產品、這個問題屬於這個功能、這個功能歸這個團隊。

它解決什麼？一般的 RAG（檢索增強生成）做的事，是去撈跟你問題「看起來最像」的那幾段文字。所以你問客服系統：「這個客人上次買什麼、退過什麼、他公司裡還有誰下過單？」它會給你一堆長得很像的段落，然後答不出來。

你知道為什麼嗎？因為答案不在任何一段文字裡，它在關係裡。（Greg 有提到微軟的 GraphRAG 就是走這條路的工具。）

代理圖（agent graph） 管的是另一件事：工作怎麼往前走。

分辨方法很簡單。你卡在「AI 查不到跨資料表的東西」，那是知識圖的問題。你卡在「這件事推不動、每次做出來的品質都不一樣」，那是代理圖的問題。

這個分辨值得花三十秒，因為很多人開口問的是「我們要不要建一個知識庫」，但描述的症狀從頭到尾都是後者。

Greg 說最好的系統兩個都會有，但他那集講的是代理圖，因為那是你這禮拜就能開始做的。

分清楚這件事的實際好處是：你才知道自己該補的是什麼。缺關係，補的是資料；缺推進，該做的是把流程攤開來刪等待。兩邊搞混，你會花好幾個月建一個沒人問得動的知識庫。

第三件事：工具排最後，不是排最前

這一段 Greg 講了一句我很喜歡的話：

如果手動版沒有做出明顯更好的東西，自動化只會讓你用更快的速度產出平庸的東西。

他給了三檔，順序不能顛倒。

第一檔：白板。 拿一張空白的 Excalidraw 或 tldraw（兩個都是手繪風的線上白板，可以免費開始用），把最終產出寫在最上面，然後畫框、畫箭頭。框是工作，箭頭是「誰做完換誰」。他強調第一次一定要手動把整輪跑完，不要偷跑。

第二檔：每一步寫成一個檔案。 用 Claude Code、Codex 或任何一個 repo 都行。規劃的那一步寫 plan.md，研究的那幾步各自寫 customer.md、competitors.md、distribution.md，查核的寫 review.md，合併的寫 recommendation.md。好處是留下一條可追的紀錄，你看得到中間發生什麼、可以比對版本、下個月能直接重用這個結構。

第三檔：這時候才輪到工具。 LangGraph（程式碼優先的 agent 編排框架，強項是狀態檢查點跟人工審核關卡）、AutoGen GraphFlow（微軟 AutoGen 的有向流程功能，處理順序、平行、條件分支跟迴圈）、n8n 跟 Make.com（視覺化自動化平台，強項是接 Slack、email、Airtable、CRM 這些每天在用的系統）。

Greg 還有一句：「你不理解一個流程就把它自動化，你會得到一團亂。」

切入重點，工具不是問題，順序才是。

收尾補兩個提醒（一）：跑完留下來的東西，才是真正在累積的

三件事講完了，最後補兩個提醒，都跟「不要把圖畫大」有關。

工具之所以排最後，還有一個理由：你真正要累積的東西，第二檔就開始長了。

state（狀態）講白了就是一句話：這個系統目前知道什麼。

這是整集裡我覺得最被低估的一段。Greg 說，一張圖跑完，除了給你那份產出以外，還會留下筆記、證據、草稿、決策紀錄。每跑一次客戶研究，你就多一份客戶筆記；每跑一次內容，你就多一批可用的範例跟受眾洞察。

圖產出的是工作，但它同時也在產出讓下一張圖變聰明的記憶。

而且這件事會回頭幫你刪格子。第一次跑，你不知道哪一格是多餘的，只能全留著；跑過三次、留下三份紀錄之後，哪一格從來沒改變過結論，你一眼就看得出來。

護城河就是這樣長出來的：不是圖越畫越大，是你越來越知道哪幾格可以不要。

收尾補兩個提醒（二）：那「圖越大越厲害」呢？

Greg 的答案是不會。他說有時候是五個 AI 很有自信地重複同一個錯，有時候是系統協調的時間比思考還多。他也提到，他看到有人在 X 上靠貼超大的圖爆紅，但那不是重點，目標是能改善品質的最小的圖。

這條我寫過了，這裡不重講：企業規模版看〈Stripe 的 AI agent 治理〉，團隊分工版看〈別再迷信一個 agent 搞定一切〉。

你這禮拜可以做的事

► 第一：挑一個你每週都在用 AI 做的流程。檔期企劃、競品追蹤、客服回覆、商品文案，隨便哪一個都行。

► 第二：把最終產出寫成一句話。像是「我要一頁的檔期建議，決定這檔要不要加碼」。

► 第三：列出一個厲害的人會做的那幾件事，一件一個框，每格用動詞開頭（查競品、擬假設、寫初稿），然後畫箭頭連起來。

► 第四：對每一個箭頭問那句話。如果上一格永遠不回我，下一格真的做不下去嗎？然後把每個箭頭標成三種之一：保留（真依賴）、刪掉等待（把箭頭拿掉，兩件事各做各的）、改並行。注意你刪的是那條箭頭，不是那格工作本身，工作還是要有人做。

► 第五：手動跑完整一輪，先不要碰工具。判斷跑順了沒有，看一件事就好：哪幾格真的改變了你最後的決定？從來沒改變過結論的那幾格，下一輪就可以拿掉。

如果你問我，這波名詞裡真正會留下來的，大概不是 graph engineering 這五個字。

留下來的是那個動作：把工作攤開來看，然後刪掉不需要的等待。

這件事在 AI 出現以前就成立了。只是以前刪掉一格，省的是人力；現在刪掉一格，省的是可靠度。

常見問題

graph engineering 是新東西，還是舊事情換一個名字？

以實際出貨的東西來看，比較接近後者。Data Science Dojo 的盤點指出，這個詞紅起來的時候，沒有任何框架、模型或能力跟著出貨。新的是講法，不是能力。

知識圖譜和 AI 工作流是同一件事嗎？

不是。知識圖處理「資訊之間怎麼連」，代理圖處理「工作怎麼往前走」。判斷方法：AI 答不出跨資料表的問題，是知識圖的事；流程推不動、每次品質不穩，是工作流的事。

什麼情況根本不用畫圖？

Greg 講得很直白：叫 AI 想 10 個名字、摘要一封短信，這種不用。當工作有多個步驟、多個資料來源、可以平行的路徑，或是需要查核、需要有人核准的時候，畫圖才開始划算。

一定要會寫程式才能做嗎？

第一檔跟第二檔完全不用。第一檔只需要一塊白板，第二檔只需要會建資料夾、寫 markdown 檔。真的要寫程式是第三檔的事，而且多數人不會走到那裡也沒關係。

來源

本文編譯自 Greg Isenberg 在 The Startup Ideas Podcast 的單集講述〈Graph Engineering Clearly Explained〉（2026 年 8 月 3 日）：Why Graph Engineering will 10x your Claude/Codex。

該集為 Greg Isenberg 個人論述，未提供第三方實測數據。影片標題的「10x」是他的標題用語，正片內容並未提出任何效益保證，本文亦不引用。文中「有人靠貼超大的圖在 X 上爆紅」為他個人的觀察陳述。交叉查證另引用 Data Science Dojo 與 The AI Operator。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。