這篇在講什麼
工程師圈從七月開始在講「圖譜工程」。聽起來又是一個新名詞，但它的核心跟寫程式沒關係。這篇做三件事。先用一間辦公室把它講清楚，全程不用程式例子。再把「圖譜」這個字的另一個主人切開，因為這兩個東西同名，我自己就遇過一次 AI 把它們答混。最後誠實盤點我那套機制，哪些真的算、哪些其實不算，不硬湊。
- 已經會讓 AI 自己跑完一件事，想知道再上去那層是什麼的人。
- 同時在做好幾種產出，覺得它們各做各的、串不起來的人。
- 看到「圖譜工程」到處被討論，想知道它跟自己有沒有關係的人。
- 一個辦公室場景，看完就記得住定義。
- 一張判別表，分清楚同名的兩種「圖譜」。
- 一份誠實的對照：什麼樣的東西算圖，什麼樣的不算。
- 一段可以直接複製的審查提示詞，今天就能用。
一、一間辦公室
想像一間辦公室，裡面有三樣東西。
桌子中間放著一本交接本。誰都看得到，上面寫著這件事現在的進展。
牆上貼著一張派工規則表。誰都看得到，上面寫著什麼情況下換誰上場。
助理們坐在旁邊等。一個一個上場，做完把結果寫進交接本，然後照規則表喊下一個人。這裡的「助理」是廣義的：可以是一個 AI、一支自動執行的小程式、一個工具，也可以是你自己。
整間辦公室就這樣運轉：助理做完事寫回交接本，規則表看一眼交接本，喊下一個人上場。這就是圖譜工程的核心長相。
三個容易看錯的地方
第一，規則表不是主管。主管會判斷、會裁量、會看情況通融。規則表只做條件對照，上面寫什麼就照什麼。規則表上有兩種常見寫法：
| 寫法 | 長什麼樣 | 什麼時候用 |
|---|---|---|
| 寫死順序 | 排版做完換校對，永遠一樣 | 步驟固定的流程 |
| 看狀況決定 | 看交接本，對外的送審查，內部的直接發 | 需要分岔的流程 |
還有第三種：讓 AI 讀完交接本自己決定下一個誰上。那確實比較像主管，有裁量空間。三種都可以，重點是你要知道自己用的是哪一種。
第二，助理不自己決定要不要插手。沒被喊到就不動。這點很重要，少了它就會滑成一群人各自為政，那正好是這套東西要解決的問題。
第三，可以同時開工，但那是規則表寫的。規則表可以寫「文字稿定稿之後，配圖跟排版同時開始」，兩邊做完各自寫回交接本，規則表再決定下一步。同時開工是被安排的，助理不會自己揪團。
二、這三樣東西的正式名字
| 辦公室裡的東西 | 正式名字 | 它在做什麼 |
|---|---|---|
| 桌上的交接本 | 狀態 | 記錄現在進行到哪、手上有什麼 |
| 牆上的派工規則表 | 邊 | 決定接下來輪到誰。可以寫死順序，也可以看交接本的狀況分岔 |
| 上場的助理 | 節點 | 做事的那一步，做完把結果寫回狀態 |
一句話定義（這是我採用的那套官方文件的講法，不是唯一版本，第七節會講定義還在浮動）：圖譜工程，就是把好幾條各自能跑完的線接起來，讓它們共用同一份紀錄、講好誰等誰。
要精確一點的話，官方文件講的狀態是「這個應用當下的完整快照」，比「進度」大一些。用交接本去想大致不會偏。
「邊」這個字最容易接錯
中文的「邊」很容易讀成邊界、界線、誰管到哪裡。這裡完全不是那個意思。
邊的工作只有一件：決定接下來輪到誰。它是流程圖上的箭頭，不是組織圖上的框線。把邊理解成權責界線，整張圖就會被讀成組織分工圖，那是另一回事。我自己在跟人討論的時候真的接錯過。
交接本上放什麼，不放什麼
放的是這件事的進展，還有做到現在手上有哪些東西。不放各個助理自己的事：這個 AI 記得什麼、環境怎麼設定。那些全部塞進去，交接本會變成誰也看不懂的雜物櫃。
判準是：其他人需不需要看到它才知道下一步怎麼走。需要就放上去，不需要就留在各自手上。
三、「圖譜」這個字有兩個主人
這一節放在所有混淆之前講，因為我自己遇過一次 AI 把兩者答混。
世界上有兩個東西都叫「圖譜」，都有節點跟連線，管的事情完全不同：
| 圖譜工程（這篇講的） | 知識圖譜（另一個同名的） | |
|---|---|---|
| 連起來的是 | 工作跟工作：誰做完換誰上場 | 概念跟概念：誰跟誰有關 |
| 你問它 | 這件事做完之後輪到誰 | 這個題目牽涉到哪些東西 |
| 成品長怎樣 | 一條跑得動的流程 | 一張可以瀏覽、可以查的關聯網 |
| 我自己的例子 | 官網文章看板、發布前的檢查關卡 | 官網頁面裡給搜尋引擎看的身分資料（我的標籤連結網往這側靠，但還不到位，第五節會講） |
知識圖譜那側的核心概念只有一個：連線本身有名字、有方向。「江昱德，講授，AI 知識管理課」是一條有名字的線，跟單純「這兩篇筆記有連結」不一樣。因為線有名字，電腦才回答得了「這個人講授過的所有課」這種問題。Google 搜尋人名時右邊跳出來的資訊卡，背後就是這種圖。那一側自己也是一門工程，這篇不展開。
我遇到的一次真實答錯
為什麼我要專門寫這一節：八月底我問一個 AI「AI 圈現在講的圖譜工程是什麼」，它很有條理地整頁講成知識圖譜那一側，講得都對，但答的是另一個東西。
我的推測是：「圖譜工程」當工作流講是七月才被放大討論的用法，那個 AI 的知識更新可能停在這個詞爆紅之前，聽到「圖譜」就對到它認識的老詞。這只是推測，模型內部我驗證不了。可以確定的是結果：它答成了另一個東西，而把它拉回來的，是我知識庫裡自己寫過的定義，就是你現在在讀的這篇。
這件事我拿來當「你的文件就是你的系統」的一個例子：AI 的知識有更新週期，你寫下來的定義留得住、也查得到。這一次是因為查得到正本，才把答錯抓了回來。
四、還有五個容易混淆的
迴圈工程
這是前一層，六月那篇專門寫過。
| 迴圈工程 | 圖譜工程 | |
|---|---|---|
| 講的是 | 一件事自己跑完 | 好幾件事接得起來 |
| 做完的樣子 | AI 自己檢查、自己修，直到過關 | 各條線共用一份進度，誰等誰講清楚 |
| 辦公室裡的對應 | 一個助理自己把事情做到好 | 交接本加規則表，讓一群助理接得起來 |
一句話分清楚：迴圈管一條線怎麼跑完，圖譜管好幾條線怎麼接在一起。這個分層是我用來理解的方式，方便記。實務上一張圖裡面也可以有迴圈，兩者不互斥。
- 用我寫一篇文章的工作流，講清楚什麼是迴圈工程：一件事怎麼讓它自己跑完，先讀這篇也可以。
專案管理
你可能會想：這不就是專案管理嗎？我看板本來就這樣用。最關鍵的差別是：助理從人變成 AI 了。
傳統看板是給人看的。人看到卡片停在「待確認」，心裡會自己補上一句「喔對，我還沒給主管看過」。人有常識，會覺得怪怪的先問一下。這些判斷從來沒寫在看板上，它們在人的腦袋裡。當你開始讓 AI 跑其中幾格，那些沒寫出來的判斷就跟著消失了。
| 助理是人 | 助理是 AI | |
|---|---|---|
| 完成條件 | 可以寫得模糊，人會自己補 | 要寫到不用猜 |
| 遇到怪事 | 多半會停下來問 | 多半照跑 |
| 誰等誰 | 大家心裡有數 | 沒寫就是沒有 |
| 出錯的速度 | 慢，中間有人會發現 | 快，而且一路跑到底 |
所以你原本的看板不用打掉重練，它已經是地基了。要補的是那些你一直放在腦袋裡、沒寫出來的判斷。
互相監督
有些文章把圖譜工程講成「多個 AI 互相監督、互相修正」。換一家 AI 來審確實很有用，理由第六節會講。但那是一種節點，串在邊的後面，跟「圖是什麼」是兩件事。把一種好用的節點當成整張圖，會讓人以為沒有互審就不算圖。
自動化
「整條線更自動化」聽起來像圖譜工程，但自動化程度跟是不是圖沒有直接關係。全手動也可以是一張圖（交接本跟規則表都在紙上，人照著跑），全自動也可以完全不是圖（跑得很順，但沒人說得出現在到哪、下一步憑什麼）。
流程設計的老方法
如果你做過流程設計，可能覺得這跟狀態機、工作流編排講的是同一件事。很大程度上確實是：有狀態、有步驟、有轉移條件，這個骨架流程設計領域早就有，這不是新發明。新的地方在於圖上跑的是 AI，而且一個節點自己可能就是一個會自己跑完的迴圈。
五、我自己的機制裡，哪些真的算
這一節的原則：有就有，沒有就不硬選。
算的
官網文章看板。最標準的一個。欄位是候選、排版中、待確認、待部署、已發布，每一格有明確的進入條件，沒到條件不准往下移。交接本、規則表、助理三樣都齊。
發布前的檢查關卡。推上線之前要過十一關，查的都是很具體的事：連結有沒有斷、有沒有不小心把機密資料推出去、用字有沒有踩到自己的地雷清單。前一關過才到下一關，任何一關沒過就整批停住。這是一串節點加上很嚴格的邊。
不算的
這些是我原本以為算、後來想清楚不算的。
我的標籤連結法。一萬多個檔案用標籤互相連。它管概念關聯，跟工作順序無關，方向上靠第三節那張表的右邊；但照那節自己講的標準，它也還不到位：連線有了，名字還沒有。所以兩邊都不算，它就是一張還在長的關聯網。
技能包系統。一櫃子工具，助理需要時拿來用。工具櫃不是圖。
換一家公司的 AI 審稿。我很重視的規則，但它是節點的一種。
寫單篇文章的流程。寫、檢查、修、再檢查。它可以拆成一張小圖，但我實際上沒那樣建，它就是一個助理自己反覆做到好，歸迴圈工程。
介於中間的
這幾天做內容的四條線。一個網站搬家的經驗，同時長出社群短文、深度文章、圖卡、免費工具包。素材查證一次四條線共用，深度文章要等圖卡好才能收尾。有共用的東西，也有誰等誰，但我不把它放進「算的」，因為實際的協調是我自己在腦袋裡做的，沒有一個系統在執行它。它是「可以建成一張圖」，還不是一張圖。
這個區別值得記住：畫得出來、講得出來，跟真的有東西在跑，是三件事。上面「算的」那兩項，是真的有東西在把關，沒到條件就是過不去。
我用的判斷方法
這是我自己的判斷法，不是業界標準。問兩個問題：有沒有一份大家共用的紀錄？有沒有一張決定誰下一個上場的規則表？
兩個都有，我就把它當一張圖。少一個，它可能很有用，但我先不叫它圖。
六、你的第一步
如果只做一件事，我建議做這個，因為它最便宜也最有感：你平常用哪個 AI 產出，就固定用另一家的 AI 審。
ChatGPT 寫的用 Claude 或 Gemini 審，反過來也一樣。重點是換公司，不是換對話視窗。
理由是我的假設：同一家的模型訓練來源接近，看不到的地方可能也接近。這個假設我沒有實測數據，但實際跑下來，換一家審確實抓到過好幾次同一家審不出來的東西。
舉一個真的發生的：我讓 AI 寫一段價格比較，年費算出來是 8,744 元，月費寫的是 729 元。你自己乘一下，729 乘 12 等於 8,748。我沒看出來，寫的那個 AI 也沒看出來。換一家審，三十秒指出這個矛盾。
後來查清楚，月費是四捨五入後的數字，用原始金額換算的答案確實是 8,744。結論對，但文章裡沒交代推導過程，讀者自己乘就會覺得算錯。
審的時候不要問「這樣可以嗎」，那種問法很容易拿到客套話。把這段貼給審查的那一方：
這個節點裝上去、跑順了，再考慮讓條件自動擋人。順序反過來會很痛苦，因為你會先蓋一堆規則，然後發現沒人執行。
七、誠實的邊界
這個詞很新，定義還在浮動。圖譜工程是 2026 年 7 月起被廣泛討論的詞，起源怎麼算、誰先講的，網路上說法不一致，我沒有一手考據，這篇不做起源判斷。可以確定的是技術骨架早就存在（第四節最後那段講過），七月發生的是這個詞被放大討論。看到「新典範」這種說法可以先打個折。
圖不保證正確。它降低的是「錯的東西一路跑到底」的機率。上面那個算錯的價格抓到了，但一定還有沒抓到的。
每加一關都有成本。我的發布流程現在要跑十一道檢查加線上驗收，大概五到十分鐘。值不值得看你的產出出錯的代價。對外發布、客戶交付我認為值得，內部草稿不用。
這篇寫的是一個人工作的尺度。大公司在這件事上做得更早也更系統，用的是專門的開發框架。我做的是把同樣的觀念縮到個人與小團隊能用的大小。
想繼續聊這個
我每個月固定辦兩場免費線上講座，分享 AI 應用與知識管理的實戰做法。如果你正在把手上的工作接成一張圖，歡迎先從社群開始。
本篇引用來源
- 狀態、節點、邊三個組成：LangGraph 官方文件
- 729 乘 12 那個例子、十一道檢查、看板五欄、四條內容線：2026 年 8 月我自己這邊實際發生與跑過的紀錄
- 一次 AI 把兩種「圖譜」答混的事件：2026 年 8 月 30 日我自己知識庫裡的實際紀錄
- Google 資訊卡背後是知識圖譜：Google Knowledge Graph（2012 年推出）公開資訊