> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # AI 工作流程怎麼設計？先刪掉「假等待」那幾格，別急著加 AI - URL: https://growthhackers.tw/blog/ai-workflow-fake-waiting/ - Published: 2026-08-13T13:00:00.000Z - Updated: 2026-08-13T13:00:00.000Z - Description: 大家都在問這張圖要加幾個 AI，真正該問的是反的：有幾格可以直接刪掉？而且該刪的那幾格裡通常沒有 AI，是「等」。解碼 Greg Isenberg 的 graph engineering，只留下三件你真的還沒做的事。 - Author: Lewis wang - Tags: AI agent, AI 工作流, 趨勢解碼, 電商經營, AI 七月中開始，X 上冒出一個新詞，叫 graph engineering（圖工程）。照 [The AI Operator](https://theaioperator.io/p/what-is-graph-engineering-a-field?ref=growthhackers.tw) 的考據，引信是 Peter Steinberger 七月十七、十八號前後在 X 上的一句話，然後就燒開了。 先講一句可能會得罪人的話：這個詞紅起來的時候，沒有任何新東西跟著出貨。 沒有新模型，沒有新框架，沒有新功能。詞是後來的討論自己長出來的。 ## 先說清楚：詞是新的，事情不新 Greg Isenberg 在他的 The Startup Ideas Podcast 用一整集講這個題目，他自己開場就先懷疑了一輪。他說他第一次看到這個詞的反應是：「這是真東西，還是我們又發明了一個名詞，讓大家覺得自己落後？」 他順手列了一串跑馬燈：prompt engineering（提示工程）、context engineering（脈絡工程）、agent engineering、vibe coding、loop engineering，然後現在是 graph engineering。 這個懷疑很健康，而且有人幫他驗證了。 [Data Science Dojo](https://datasciencedojo.com/blog/graph-engineering-frameworks/?ref=growthhackers.tw) 寫過一篇專門盤點這件事，結論相當不客氣。他們列了一排框架：LangGraph、Google ADK、微軟 Agent Framework、CrewAI、LlamaIndex Workflows、OpenAI Agents SDK，這些東西用「節點、邊、共享狀態」來蓋 agent，已經蓋了兩年多。 然後補上那句最傷的：「如果你用過上面任何一個，你早就在做 graph engineering 了，只是它以前叫別的名字。」 所以名詞通膨是真的。 但 Greg 那集裡確實有幾樣東西值得抄，而且抄的成本很低。我把它拆完之後，真正還沒被講爛的只剩三件事。 在那之前，他有一句定義我覺得是全片最好的，先給你： > 提示工程是「你怎麼問」，脈絡工程是「你餵它什麼資料」，圖工程是「你怎麼設計 AI 周圍的工作流程」。 目的只有一個：讓事情不要全部擠在一個又大又亂的對話框裡。 以前你想把 AI 用好，想的是怎麼把那句話寫得更精準。現在你要想的是，這件事該被拆成幾段、哪幾段可以同時跑、誰來查、誰來拍板。 ## 這幾條我已經寫過了，直接給你連結 先把重複的部分交代掉，這段我不重講。 Greg 那集裡的「拆成步驟、平行研究、放一個獨立的質疑者、最後留一道人工把關」，這幾條站上都寫過了，而且寫得比這篇細： - 做事的跟查核的要分開、怎麼設計查核的那一關 → 〈[用 AI 的高手不寫更長的 prompt，他們設計「驗收迴圈」](https://growthhackers.tw/blog/ai-agent-verification-workflow/)〉 - 為什麼要有一個專門找碴的角色，以及它什麼時候不划算 → 〈[你的 AI 需要一個天敵](https://growthhackers.tw/blog/adversarial-agents-ai-critic-loop/)〉 - 人工關卡該放哪、哪六類事情 AI 絕對不能自己按下去、什麼時候該停 → 〈[Codex goal 指令怎麼寫](https://growthhackers.tw/blog/codex-goal-command-verifiable-contract/)〉 想看就點進去，這裡直接跳過。 ## 第一件事：把「假等待」那幾格刪掉 Greg 講「一張好的圖該做到哪些事」的時候，第一條是 remove fake waiting，刪掉假等待。他講完這一句就過去了。 我覺得這句是全片最值錢的，因為它跟大家現在的思考方向是反的。 大家現在想的都是加法。這個流程要加幾個 agent？要不要加一個查核的？要不要再加一個彙整的？ 刪格子這件事，幾乎沒人在問。 ### 怎麼分辨真的要等和假等待 給你一個判準，就一句話： **如果這一格永遠不回你，後面那一格是不是真的做不下去？** 做不下去，那是真依賴。做得下去，那就是假等待。 真的要等的，大概是這幾種： - 等客戶回覆確認素材。對方是外部主體，你控制不了。 - 等主管核准檔期預算。這是授權問題，弄錯代價很高。 - 等金流、物流系統回拋結果。事實還沒發生，你等的是事實本身。 - 等 A/B 測試累積到足夠樣本。統計上的答案還不存在，早看只會看錯。 這四種你急也沒用，因為你在等一個「還不存在的事實」。真依賴要解的是另一個題目：怎麼讓流程停得住、隔幾天還能接回來不掉進度。[那題我另外寫](https://growthhackers.tw/blog/ai-agent-multi-day-workflow-automation/)。 這篇只處理剩下那一種。 假等待的長這樣： - 等競品資料收齊，才開始寫自己的定位。這兩件事根本不互相依賴，可以同時跑。 - 等文案定稿，才開始想主視覺。只要 brief 定了，文案跟視覺就能並行，真正要對齊的只有最後那一次。 - 等報表跑完，才開始擬假設。假設你現在就寫得出來，報表是拿來驗證它的。 - 等攝影師交完整批照片，才開始寫商品文案。有規格表就能動筆了。 - 等月結完，才做檔期分析。檔期都打完了才復盤，來不及。 這五格有一個共同點：它們等的不是事實，是人的節奏。 ![真的要等 vs 假等待：左邊那格在等一個你控制不了的外部事實，右邊那條箭頭則是可以剪掉的，兩件事本來就能各做各的。](https://growthhackers.tw/content/images/2026/08/inline-real-vs-fake-wait-v1.png) 真的要等 vs 假等待：左邊那格在等一個你控制不了的外部事實，右邊那條箭頭則是可以剪掉的，兩件事本來就能各做各的。 這種結構在實體產業裡也一樣。我在雨傘產業待過七年，工廠業務、品牌、百貨專櫃都待過，傳統製造與零售的流程大致是什麼長相，我算有點概念：關卡會隨著時間越積越多，而且新增容易、取消很難。真正需要有人拍板的關卡當然存在，品管站該卡就是要卡，因為不良品流下去代價很高。但一條走久了的流程，裡面通常混著不少純粹是「順便讓誰知道一下」的站。 產線是這樣，你的 AI 工作流程圖也是這樣。 以前你畫流程圖，是為了讓每個人知道自己什麼時候該動。現在你畫流程圖，是為了找出哪幾格根本不用有人動。 ### 一個算術，讓你知道格子為什麼要少 還有一個該把格子壓少的理由，這個理由是算術，不是感覺。 **假設**你圖上每一格都有 95% 的成功率。95% 聽起來很高吧？五格串起來，0.95 的五次方，剩下 77%。如果每一格是 85%，五格串完只剩 44%。 （這組算式在 [The AI Operator](https://theaioperator.io/p/what-is-graph-engineering-a-field?ref=growthhackers.tw) 的 graph engineering 指南裡也出現過，我自己按過計算機，數字對得上。） 我要特別標清楚：95% 跟 85% 都是假設值，不是任何工具測出來的效能，也不能拿去推算你會少賺多少錢。 它證明的只有一件結構性的事：格子會互相稀釋。 所以每多留一格沒必要的格子，你付的不只是時間，是整條鏈的可靠度。 ## 第二件事：你在畫的是知識圖，還是代理圖？ Greg 說，大家講「圖」的時候其實在講兩件不同的事，混淆多半是從這裡來的。 **知識圖（knowledge graph）** 幫 AI 理解「誰跟誰有關係」。這個客戶在這家公司、這家公司用這個產品、這個問題屬於這個功能、這個功能歸這個團隊。 它解決什麼？一般的 RAG（檢索增強生成）做的事，是去撈跟你問題「看起來最像」的那幾段文字。所以你問客服系統：「這個客人上次買什麼、退過什麼、他公司裡還有誰下過單？」它會給你一堆長得很像的段落，然後答不出來。 你知道為什麼嗎？因為答案不在任何一段文字裡，它在關係裡。（Greg 有提到微軟的 GraphRAG 就是走這條路的工具。） **代理圖（agent graph）** 管的是另一件事：工作怎麼往前走。 分辨方法很簡單。你卡在「AI 查不到跨資料表的東西」，那是知識圖的問題。你卡在「這件事推不動、每次做出來的品質都不一樣」，那是代理圖的問題。 ![知識圖管「誰跟誰有關係」，代理圖管「工作怎麼往前走」。查不到跨資料表的東西是前者的問題，流程推不動是後者的問題。](https://growthhackers.tw/content/images/2026/08/inline-knowledge-vs-agent-graph-v1.png) 知識圖管「誰跟誰有關係」，代理圖管「工作怎麼往前走」。查不到跨資料表的東西是前者的問題，流程推不動是後者的問題。 這個分辨值得花三十秒，因為很多人開口問的是「我們要不要建一個知識庫」，但描述的症狀從頭到尾都是後者。 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 還有一句：「你不理解一個流程就把它自動化，你會得到一團亂。」 切入重點，工具不是問題，順序才是。 ![三檔的順序不能顛倒：先在白板上手畫、再讓每一步各自寫成檔案，最後才輪到 LangGraph、n8n、Make.com。](https://growthhackers.tw/content/images/2026/08/inline-tool-ladder-v1.png) 三檔的順序不能顛倒：先在白板上手畫、再讓每一步各自寫成檔案，最後才輪到 LangGraph、n8n、Make.com。 ## 收尾補兩個提醒（一）：跑完留下來的東西，才是真正在累積的 三件事講完了，最後補兩個提醒，都跟「不要把圖畫大」有關。 工具之所以排最後，還有一個理由：你真正要累積的東西，第二檔就開始長了。 state（狀態）講白了就是一句話：這個系統目前知道什麼。 這是整集裡我覺得最被低估的一段。Greg 說，一張圖跑完，除了給你那份產出以外，還會留下筆記、證據、草稿、決策紀錄。每跑一次客戶研究，你就多一份客戶筆記；每跑一次內容，你就多一批可用的範例跟受眾洞察。 圖產出的是工作，但它同時也在產出讓下一張圖變聰明的記憶。 而且這件事會回頭幫你刪格子。第一次跑，你不知道哪一格是多餘的，只能全留著；跑過三次、留下三份紀錄之後，哪一格從來沒改變過結論，你一眼就看得出來。 護城河就是這樣長出來的：不是圖越畫越大，是你越來越知道哪幾格可以不要。 ## 收尾補兩個提醒（二）：那「圖越大越厲害」呢？ Greg 的答案是不會。他說有時候是五個 AI 很有自信地重複同一個錯，有時候是系統協調的時間比思考還多。他也提到，他看到有人在 X 上靠貼超大的圖爆紅，但那不是重點，目標是**能改善品質的最小的圖**。 這條我寫過了，這裡不重講：企業規模版看〈[Stripe 的 AI agent 治理](https://growthhackers.tw/blog/stripe-kai-agent-platform-governance/)〉，團隊分工版看〈[別再迷信一個 agent 搞定一切](https://growthhackers.tw/blog/ai-agent-team-division-of-labor/)〉。 ## 你這禮拜可以做的事 ► 第一：挑一個你每週都在用 AI 做的流程。檔期企劃、競品追蹤、客服回覆、商品文案，隨便哪一個都行。 ► 第二：把最終產出寫成一句話。像是「我要一頁的檔期建議，決定這檔要不要加碼」。 ► 第三：列出一個厲害的人會做的那幾件事，一件一個框，每格用動詞開頭（查競品、擬假設、寫初稿），然後畫箭頭連起來。 ► 第四：對每一個箭頭問那句話。如果上一格永遠不回我，下一格真的做不下去嗎？然後把每個箭頭標成三種之一：**保留**（真依賴）、**刪掉等待**（把箭頭拿掉，兩件事各做各的）、**改並行**。注意你刪的是那條箭頭，不是那格工作本身，工作還是要有人做。 ► 第五：手動跑完整一輪，先不要碰工具。判斷跑順了沒有，看一件事就好：哪幾格真的改變了你最後的決定？從來沒改變過結論的那幾格，下一輪就可以拿掉。 如果你問我，這波名詞裡真正會留下來的，大概不是 graph engineering 這五個字。 留下來的是那個動作：把工作攤開來看，然後刪掉不需要的等待。 這件事在 AI 出現以前就成立了。只是以前刪掉一格，省的是人力；現在刪掉一格，省的是可靠度。 ## 常見問題 **graph engineering 是新東西，還是舊事情換一個名字？** 以實際出貨的東西來看，比較接近後者。[Data Science Dojo](https://datasciencedojo.com/blog/graph-engineering-frameworks/?ref=growthhackers.tw) 的盤點指出，這個詞紅起來的時候，沒有任何框架、模型或能力跟著出貨。新的是講法，不是能力。 **知識圖譜和 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](https://www.youtube.com/watch?v=JWhICz1QR8M&ref=growthhackers.tw)。 該集為 Greg Isenberg 個人論述，未提供第三方實測數據。影片標題的「10x」是他的標題用語，正片內容並未提出任何效益保證，本文亦不引用。文中「有人靠貼超大的圖在 X 上爆紅」為他個人的觀察陳述。交叉查證另引用 [Data Science Dojo](https://datasciencedojo.com/blog/graph-engineering-frameworks/?ref=growthhackers.tw) 與 [The AI Operator](https://theaioperator.io/p/what-is-graph-engineering-a-field?ref=growthhackers.tw)。 **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。