Tratopedia
側 NBM
設定

文字大小

語言

EN繁中BMES

佈景

高對比

中文排版

豎排會把內文排成由右至左的直行，如同台灣的實體書籍。

版本

v1.184.0

本頁建置時的版本編號，也是 service worker 快取所依據的版本。

事實

術語 · LLM 工程 · AI 代理 · AI 人工智慧 · 說明這個名詞與這種做法，2024 年 1 月至 2026 年 8 月

五篇之五 · 來了兩次的那一個

同一個詞被命名了兩次，相隔兩週——贏的是那個玩笑

2026 年 7 月 4 日，Josh C. Simmons 發表一篇嚴謹、附有出處的文章，造出「graph engineering」（圖結構工程）一詞：把代理系統設計成一張明確的圖——節點、邊、每一步都存檔的狀態——而不是讓一個模型在迴圈裡打轉。十四天後，7 月 18 日 00:34（UTC），Peter Steinberger 在 X 上問：「Are we still talking loops or did we shift to graphs yet?」（我們還在談迴圈，還是已經改談圖了？），瀏覽 310 萬次。再過四個半小時，Hamel Husain 發表一篇題為〈Loop Engineering Is Dead. Enter Graph Engineering〉（迴圈工程已死，圖結構工程登場）的文章。全文只有一張寫著「Stop it.」的動圖，和一個句點。讓這個詞出名的是那個玩笑。而這種做法比兩者都早：2024 年 1 月已有論文把「flow engineering」（流程工程）與提示工程對舉，七月那篇文章引用的綜述也說，這種做法「常被稱為 flow engineering」。

這個想法有共識，亂的是名字 每一個替它下定義的出處，描述的都是同一個三段式結構。分歧在於它該叫什麼、是誰命名的，以及它到底新不新。

  • 14天：從造出這個詞的嚴謹文章，到讓它傳開的那個玩笑
  • 12個英文字：就是那則貼文——一個問句，什麼也沒主張
  • 1張動圖加一個句點：宣告迴圈工程已死的那篇文章，全文就是這樣
  • 2024年：一篇論文的標題把「flow engineering」與提示工程對舉——這是找得到的最早用例
  • 0項量測：比較「圖」與「迴圈」孰優孰劣

  • 節點

    「好的節點是無聊的」

    一個能力單位——而且人也算一個。

    • 在 Simmons 的定義裡，節點可以是一個跑著「思考—行動—觀察」循環的模型、一個單純的確定性函式、一個檢索步驟，或是一個人。它只做一件事，可以單獨測試，也可以整個換掉而不驚動其他部分。
    • LangChain 描述自家框架時也是同一套說法：節點可以是確定性的程式碼、一次模型呼叫、一次工具呼叫，或是一個自帶內部迴圈的完整代理。

  • 邊

    邊就是決策

    而它們就是將來會出錯的地方。

    • 一條帶著狀態、有型別的轉移。有些是確定的——「測試通過就部署」；有些交由模型判斷——「這張單子該送帳務還是檢舉部門」。用 Simmons 的話說，工作就是分清楚哪個是哪個，「並且在負擔得起的地方一律預設用確定的那種」。
    • 據 Turing Post 轉述，Google 為 Agent Development Kit 2.0 提出的論點也一樣：「可預測的路由交給程式碼控制，需要詮釋或判斷的步驟才交給模型。」

  • 狀態

    一份綱要，每過一條邊就存檔

    不是「當下脈絡視窗裡剛好有什麼」。

    • 好用的性質都從這裡來。失敗不再是「整輪重跑」，而是「重試那個節點」；一件工作可以等三天等人簽核，而不必一直扣著一個脈絡視窗。
    • 預算也放在狀態裡——token、金錢、實際時間——並在邊上強制執行。「如果你沒辦法在花費達到上限時把代理停下來，你跑的就不是自主系統，你只是在累積帳單。」台灣對這個詞的介紹，用幾乎相同的話講了同一件事。

  • 驗證

    驗證必須來自外部

    讓代理檢查代理，是不夠的。

    • Louis-François Bouchard：「叫模型檢查自己的答案仍然有用，但那不是外部驗證。測試執行器、執行結果、一筆交易、客戶的實際結果，或是專家的人工審閱，才是從系統自身推理之外給出的證據。」
    • 他把背後的警告歸功於 Carlos Perez：一張由代理檢查代理的圖，「可能產出極有條理的胡說八道」，因為同樣構造的模型讀著同一份有瑕疵的脈絡，往往彼此附和。

每一項有多確定 依確定程度排列：文件本身呈現的，其次是文件僅止於宣稱的，再來是被有日期的出處反駁的，最後是本文自己的解讀。

確定程度內容依據
已讀原文這個詞，以三部分定義——無聊的節點、有型別的邊、存檔的狀態——以及「迴圈沒有死，只是被降級了」。Josh C. Simmons，2026 年 7 月 4 日
已讀原文那十二個字與 310 萬次瀏覽；最早的回覆都是玩笑——「im tired boss」「bro stop I'm on vacation」Peter Steinberger 於 X，2026 年 7 月 18 日 00:34（UTC）
已讀原文〈Loop Engineering Is Dead. Enter Graph Engineering〉：一張封面插圖、一張寫著「Stop it.」的動圖、一個句點。此外什麼都沒有Hamel Husain，X 文章，2026 年 7 月 18 日 05:09（UTC）
已讀原文「flow engineering」出現在一篇論文的標題裡，與提示工程對舉Ridnik、Kredo 與 Friedman，arXiv，2024 年 1 月 16 日
已讀原文一份綜述裡談圖式編排的章節，說這種做法「常被稱為 flow engineering」——而造詞的那篇文章，正是為了這一點把這份綜述列在自己的出處裡Arunkumar V、Gangadharan 與 Buyya，arXiv，2026 年 1 月 18 日；Simmons 的出處清單
已讀原文「迴圈本來就是一張圖，只不過是一張路徑會回到先前節點的圖。」Ksenia Se，Turing Post，2026 年 7 月 20 日
已讀原文「兩則推文都是玩笑」——以及「這個玩笑之所以奏效，是因為它指向了真實的東西」Louis-François Bouchard，2026 年 7 月 22 日
已讀原文把迴圈看成「就緒集合只有一個」的排程器——以及論文自己的聲明：「並非生產實作，也沒有實證結果」Hu Wei，arXiv，2026 年 4 月 13 日
文件自己的宣稱圖結構工程是「一種新穎的工程範式」一份 35 位作者的綜述，arXiv，2026 年 8 月 21 日
被有日期的出處反駁在七月那篇文章「追溯命名」之前，沒有人替迴圈工程取過名字Simmons，2026 年 7 月 4 日；對照 2026 年 4 月至 6 月的貼文與文章
本文的解讀這個詞有兩個起點，而傳開的是那個玩笑標明為解讀，並非有出處的事實

時序

先有做法和名字，再來新名字，然後是一個玩笑 爆紅的過程只有十六個小時，位在一條始於 2023 年的鏈條末段。7 月 18 日的時間均為 UTC。

  1. 2023 年 8 月一個給代理用的圖框架起步。LangChain 的 LangGraph 程式庫建立。第一個版本在 2024 年 1 月 8 日發布——所以 LangChain 在 2026 年 7 月說它有三年歷史，別人卻把它的推出定在 2024 年 1 月，兩者並不矛盾。
  2. 2024 年 1 月 16 日「flow engineering」，出現在標題裡。CodiumAI 的一篇論文題為〈From Prompt Engineering to Flow Engineering〉（從提示工程到流程工程）：不靠一段精心寫好的提示，而是一條分階段、以測試驅動的流程，產生、執行、修正程式碼。在它自己的基準上，GPT-4 每題五次嘗試可解出 44% 的驗證題，單一提示只有 19%。
  3. 2025 年 10 月LangGraph 1.0。這些出處最常提到的圖框架，推出第一個主要版本。
  4. 2026 年 1 月 18 日這種做法，在一份綜述裡有了名字。一份代理式 AI 綜述有一節題為「Graph based orchestration and flow engineering」（圖式編排與流程工程）：生產系統把工作流程建模「成狀態機，節點代表工具呼叫或 LLM 調用，邊代表允許的轉移。這種做法常被稱為 flow engineering。」
  5. 2026 年 4 月 13 日反對迴圈的正式論證。一篇單一作者的立場論文把代理迴圈描述為「單一就緒單元排程器」，下一步「出自不透明的 LLM 推論，而非可檢視的策略」，並提出「Structured Graph Harness」（結構化圖駕馭框架）。摘要最後一句是：並非生產實作，也沒有實證結果。
  6. 2026 年 4 月 15 日先有迴圈，後有這個詞。在舊金山的 Acquired Unplugged 台上，主導 Claude Code 的 Boris Cherny 說他的工作就是寫迴圈——Addy Osmani 後來引述他的話：「我的工作就是寫迴圈。」當晚他在 X 上向主持人道謝。
  7. 2026 年 6 月 7 日迴圈工程有了名字。Peter Steinberger 發文說，你應該「設計去對代理下提示的迴圈」；同一天 Addy Osmani 發表題為〈Loop Engineering〉的文章。
  8. 2026 年 6 月 30 日一個流行詞。吳恩達（Andrew Ng）稱迴圈工程是「當紅的流行詞」；Anthropic 的 Claude Code 團隊發表迴圈入門指南。
  9. 2026 年 7 月 4 日認真的造詞。Josh C. Simmons 發表〈We Are Entering the Graph Engineering Phase〉（我們正進入圖結構工程階段）：三部分的定義、七條實踐，和六項出處——其中一項正是那份一月綜述，引用理由是「圖式編排與 flow engineering」。同一篇文章寫道：「所以做法已經收斂，詞彙卻沒有。好吧，詞彙在這裡：graph engineering。」
  10. 7 月 18 日 · 00:34十二個字。Peter Steinberger 在 X 上寫道：「Are we still talking loops or did we shift to graphs yet?」它什麼也沒提出，卻達到 310 萬次瀏覽。最早的幾則回覆：「im tired boss」（老闆我累了）、「bro stop I'm on vacation」（兄弟別鬧，我在度假）、「接下來三週的 YouTube：『為什麼你該跑圖而不是跑迴圈』」。
  11. 7 月 18 日 · 02:10第一次試著賦予意義。Shubham Saboo：「圖到底是什麼鬼。迴圈讓代理的行為可以程式化，圖讓代理組織可以程式化。」
  12. 7 月 18 日 · 05:09訃聞。Hamel Husain 發表一篇 X 文章：〈Loop Engineering Is Dead. Enter Graph Engineering〉。封面是一個迴圈展開成網絡的插圖，底下內文是一張寫著「Stop it.」的反應動圖，和一個句點。
  13. 7 月 18 日 · 05:16眨眼暗示。Husain 引用自己的文章：「如果我在動態上看到這個，我自己都會怕得不敢點。但我保證，它不是你想的那樣。」
  14. 7 月 18 日 · 16:26口號。Santiago：「迴圈工程已死，圖結構工程萬歲！」九分鐘後，Husain 再次引用自己的文章：「被加入書籤 100 次 🤣🤣」。
  15. 2026 年 7 月 20 日它是真的嗎？Turing Post 把那則起頭的貼文讀成玩笑——「Peter 在玩」——報導到了週日已經冒出「課程、路線圖、工具組合」，數出人們口中的「圖」有四種不同意思，並落下整個論證的關鍵一句：迴圈本來就是一張圖。
  16. 2026 年 7 月 22 日有人說破了，而且說了兩次。Louis-François Bouchard：「這大多只是圍繞造新詞的一場大型迷因」——以及「這個玩笑之所以奏效，是因為它指向了真實的東西」；同一天較長的版本裡則說「兩則推文都是玩笑」。同樣在這一天，LangChain 的創辦人寫道，圖結構工程「不是新點子，只是一種早已成熟做法的最新名字」。
  17. 2026 年 7 月 28 日它以詞彙之姿抵達台灣。《數位時代》把它當成五種 AI 工程術語之一刊出，出處註明 X 與 Josh C. Simmons，揭露初稿由 AI 撰寫，並直說這五層怎麼排「目前還沒有定論」。
  18. 2026 年 8 月 21 日又被「提出」了一次，而且說是新的。一份 35 位作者的綜述：「我們提出 Graph Engineering，一種新穎的工程範式」。它完全沒提七月的那些貼文，也沒提「flow engineering」這個說法，而且已經點名下一層：本體工程（ontology engineering）。修訂版在 8 月 26 日發布。

論點

他手上有舊名字，卻選了新名字 造詞的那篇文章對論文很謹慎，對前一個詞卻說錯了，而且它知道這種做法早就有名字。

Josh C. Simmons 的文章是嚴謹的那一篇。兩個 arXiv 引用，都是真的；一個 60% 的綜述數字，引得準確；對某篇論文某一節的概括，和那一節自己的標題幾乎一字不差。

有意思的正是那個概括。他在出處清單裡列了那份一月綜述，理由是「graph orchestration and flow engineering as an identified industry shift」（圖式編排與流程工程，一個已被辨識出的產業轉向）——而那份綜述談這件事的章節說，這種做法「常被稱為 flow engineering」。在文章正文裡，他寫道：「所以做法已經收斂，詞彙卻沒有。好吧，詞彙在這裡：graph engineering。」這種做法有名字，他讀過，然後提出了另一個。

同一篇文章對前一個詞卻說錯了。「沒有人替這門功夫取名……那就讓我追溯地替它命名：loop engineering。」它四週前就有名字了。Boris Cherny 4 月 15 日在舊金山的台上說他的工作就是寫迴圈；Peter Steinberger 與 Addy Osmani 在 6 月 7 日把「設計迴圈」和「loop engineering」這個說法公開提出；6 月 30 日，吳恩達稱之為「當紅的流行詞」，Anthropic 的 Claude Code 團隊也發表了入門指南。Turing Post 在這篇文章兩週後，把這個詞的年紀定為「大約六週」。

沒有任何跡象顯示惡意，本文也不作此指控。本文提出的解讀，並標明為解讀：一位仔細讀論文、卻錯過了一個月 X 的作者，正好說明了這套詞彙活在哪裡。它活在動態時間軸上，以天為單位移動；一個新名字，可以在善意之下，被提給一個早就有名字的東西。

那篇訃聞裡什麼都沒有 宣告迴圈工程已死的那篇文章，是一個標題、一張插圖，和一張寫著「Stop it.」的動圖。

那篇文章發表十四天後，7 月 18 日 00:34（UTC），Peter Steinberger 在 X 上問了十二個字：「Are we still talking loops or did we shift to graphs yet?」它得到 310 萬次瀏覽，回覆也都是同一種語氣。

四個半小時後，Hamel Husain 發表一篇 X 文章，題為〈Loop Engineering Is Dead. Enter Graph Engineering〉。標題下方是一張插圖：一個環狀箭頭展開成節點網絡。插圖下方是一張寫著「Stop it.」的反應動圖，和一個句點。整篇文章就是這樣。幾分鐘後他寫道：「如果我在動態上看到這個，我自己都會怕得不敢點。但我保證，它不是你想的那樣。」十一個小時後，他再次引用它：「被加入書籤 100 次 🤣🤣」。

回覆說明了它是怎麼傳開的。「這是 AI 版的『被 Rick Roll 了』。」還有：「這招完全對我有效。我看到它，連點都沒點，就開始跟身邊的人嘲諷它，哈。」標題自己在流傳。到了傍晚，Santiago 貼出「迴圈工程已死，圖結構工程萬歲！」；據 Turing Post 報導，到了週日已經冒出「課程、路線圖、工具組合」，以及聲稱 Microsoft、Stanford、Anthropic 同時發現了圖結構工程的長串討論——還附帶一個「準確率高 18%、成本低 85%」的說法，Turing Post 追查出它來自一項針對工業工程圖的狹窄研究。

本文的解讀，並標明為解讀：讓這個詞出名的兩則貼文，都沒有定義——一則是問句，另一則是叫你住手的動圖。定義來自別處，主要是那篇兩週前的文章，台灣的介紹也註明了它；而 Turing Post 在幾天之內就數出人們口中的「圖」有四種不同意思。這個玩笑講的是這個領域改名改得有多快，結果卻被當成了又一次改名。

補充

實際上要做的是什麼 Josh C. Simmons 的七條實踐，台灣的介紹把它濃縮成三條。把那兩週拿掉，底下的建議很具體，而且比這個名字還老。

  1. 1寫提示之前，先畫出狀態狀態綱要就是架構。「如果你寫不出系統在一次執行的每個時間點知道些什麼，你手上的只是展示品。」
  2. 2讓節點保持無聊每個只做一件事，才能測試、快取、重試、替換。「一個做五件事的節點，就是多了幾個步驟的迴圈。」
  3. 3把判斷放在邊上，並且好好觀測圖系統的聰明之處在於路由，所以交給模型判斷的邊，恰恰就是它會出錯的地方。
  4. 4每過一條邊就存檔失敗變成「重試那個節點」，而不是「整輪重跑」；一張圖也可以等三天等人簽核。
  5. 5把人當成節點一條邊進、一條邊出，中間是一個人。把核准硬接成例外處理，「就是你得到『名義上有監督、實際上沒有』的系統的方式。」
  6. 6把預算放進狀態token、金錢與實際時間都放在狀態物件裡，並在邊上強制執行。
  7. 7評估軌跡，不只評估輸出「輸出評估告訴你這次執行結局不錯；軌跡評估告訴你它有沒有以合理的成本走上合理的路，而你下一個失敗就藏在路上。」

誰的階梯，有幾階 每一把階梯最底下都是提示，靠近頂端都是圖。分歧在於「駕馭」（harness）——而最新的那一把，已經在圖之上又加了一階。

誰的階梯有沒有駕馭？
Josh C. Simmons · 7 月 4 日提示 → 情境 → 迴圈 → 圖沒有。「每一階都是抽象層次的一次提升」
Louis-François Bouchard · 7 月 22 日提示、情境、駕馭、迴圈、圖有。它們「大幅重疊，即使並不完全相同」
LangChain · 7 月 22 日提示、情境、駕馭、迴圈、圖有，稱之為「X 那座 AI 內容工廠最新產出的詞」
《數位時代》 · 7 月 28 日提示、情境、駕馭、迴圈、圖有——而且哪一層包住哪一層，「目前還沒有定論」
35 位作者的綜述 · 8 月 21 日提示、情境 → 駕馭、迴圈 → 圖 → 本體有：「Agent = Loop(LLM + Harness)」
Hu Wei · 4 月 13 日沒有階梯——這是一份設計提案它把自己的設計命名為「Structured Graph Harness」——四階階梯上漏掉的那個字，正出現在那把階梯所引用之設計的名稱裡

反駁之間的共識，比宣告之間的還多。

Turing Post：「迴圈本來就是一張圖，只不過是一張路徑會回到先前節點的圖。」這些出處最常提到的框架 LangGraph 出自 LangChain，他們從另一頭說了同樣的話——「迴圈是簡單的圖」，以及「代理的圖通常不是 DAG（有向無環圖）」，因為生產環境中的代理會重試、會發問、會修改、會暫停。Bouchard：「圖裡面包含迴圈。」Simmons 最早提出這一點：迴圈沒有死，只是被降級了，它仍在每一個節點裡運轉。

這些都不新，出處自己也這麼說。狀態機、DAG 與工作流程引擎「已經以各種形式做這件事幾十年了」（Turing Post）；Anthropic 2024 年那份打造代理的指南，早已畫出串接、路由、平行工作者與評估迴圈（Bouchard）；LangGraph 的程式庫始於 2023 年 8 月。LangChain 自己的結論——「這只是一種早已成熟做法的最新名字」——出自一家在文末推薦自家產品的公司。

有兩個警告值得記住。「圖」至少有四種意思：決定下一步跑什麼的控制圖、由實體與關係構成的知識圖（GraphRAG）、一次執行的軌跡，以及一張由互相檢查的迴圈組成的圖——而圖結構工程講的只有第一種。還有，大多數代理根本不需要圖：「如果工作流程是線性的，就讓它保持線性。」

而且至今沒有任何量測 那篇正式論文聲明自己沒有實證結果；提出這個範式的綜述也說，所需的量測還不存在。

這個想法最嚴謹的表述，是 Hu Wei 四月那篇立場論文，它這樣形容自己：「這是一篇立場論文與設計提案……並非生產實作，也沒有實證結果。」它的比較表把自己的設計評為「只有設計，未經實證驗證」，旁邊的 LangGraph 則是「廣泛部署，經社群驗證」，表頭寫著「公平性聲明」。

從它流傳出去的唯一數字——70 個開源代理專案中有 60% 是單純的迴圈——確實是論文自己的數字，而論文稱這份調查「未經同儕審查」，是「質性證據，而非量化證明」。它的數字彼此對不上。正文說 70 個中有 42 個；附錄標題說 41 個；附錄在那個標題下列了 50 個專案，其中 8 個同時列在另一個類別——而 50 減 8 正好是正文的 42。五個類別合計，清單列出 69 個不重複的專案，各標題數字加總為 68，另一張表則給狀態機 10%，附錄給的是 6%。

八月那份 35 位作者、把圖結構工程作為範式提出的綜述，對這個缺口說得很直白：效能提升「可能來自更強的基礎模型、更長的脈絡、更多的推理樣本或更多運算成本，而非更有效的任務組織」，未來的基準應提供「對等的執行預算」。這整條脈絡裡唯一有量測的結果，是 AlphaCodium 2024 年 1 月的數字：GPT-4 用分階段流程解出 44% 的驗證題，單一提示只有 19%。那是流程對上提示，題目是程式競賽，量測者是打造該流程的公司——不是圖對上迴圈。

結論

該帶走什麼 想法站得住腳。推出的方式是個玩笑，而那個玩笑講的正是命名。把兩者分開。

評判想法，不是評判推出方式

兩則起頭的貼文都是玩笑，於是很容易就下結論說這個詞毫無價值。Bouchard 拒絕走這一步，本文也是。造詞的文章、LangChain 的創辦人、Turing Post 和台灣媒體，描述的是同樣的節點、同樣承載決策的邊、同樣會存檔的狀態，也都同意什麼時候不該用它。這是對想法的收斂。分歧只在它該叫什麼。

打開那份起頭的文件

宣告迴圈工程已死的那篇文章，內容是一張寫著「Stop it.」的動圖，作者也保證它不是看起來那樣。只靠標題被轉傳，它就成了又一次改名。本文的解讀，並標明為解讀：當一個詞以這種方式到來，先打開那份起頭的文件，再決定要不要轉述——這次只需要點一下，而點下去就真相大白。

這種做法早有名字，造詞者還引用了它

「flow engineering」出現在 2024 年 1 月的一篇論文標題裡，也出現在 2026 年 1 月一份綜述的章節標題裡，而七月那篇文章在提出新名字之前，已把那份綜述列進出處。八月，一份 35 位作者的綜述把圖結構工程當成「一種新穎的工程範式」提出，既沒提七月的貼文，也沒提那個較舊的說法，還點名了下一階：本體工程。名字以週為單位在變，做法本身幾乎沒動。

仍然沒有量測

圖結構工程沒有屬於自己的量測。它最嚴謹的論文聲明沒有實證結果，它最常被引用的數字來自一份作者自稱屬質性的調查，而提出這個範式的綜述也說，結構帶來的好處還沒和更多運算帶來的好處分開來。本系列寫到第五個詞，詞彙依然跑得比證據快。

無法查證的部分

「傳言」——「flow engineering」曾是圖結構代理工作流程的通用名稱。一份 2026 年 1 月的綜述說這種做法「常被稱為」如此，但為此引用的只有兩個框架的程式庫，而它們都沒有用這個說法；一篇 2024 年的論文曾把它放進標題。找不到更廣泛使用的證據。

核心要點與來源

  • Tal Ridnik、Dedy Kredo 與 Itamar Friedman，〈AlphaCodium〉，arXiv（2024 年 1 月 16 日）
  • LangGraph 程式庫，GitHub（2023 年 8 月 9 日建立）
  • LangGraph 版本紀錄，PyPI（2024 年 1 月 8 日至 2025 年 10 月）
  • Arunkumar V、Gangadharan G.R. 與 Rajkumar Buyya，arXiv（2026 年 1 月 18 日）
  • Hu Wei，arXiv（2026 年 4 月 13 日）
  • WorkOS，Acquired Unplugged 活動頁（2026 年 4 月 15 日）
  • Boris Cherny 於 X（2026 年 4 月 16 日，UTC）
  • Peter Steinberger 於 X（2026 年 6 月 7 日）
  • Addy Osmani（2026 年 6 月 7 日）
  • Andrew Ng 於 X（2026 年 6 月 30 日）
  • Delba de Oliveira 與 Michael Segner，Claude 部落格（2026 年 6 月 30 日）
  • Josh C. Simmons（2026 年 7 月 4 日）
  • Peter Steinberger 於 X（2026 年 7 月 18 日 00:34，UTC）
  • Shubham Saboo 於 X（7 月 18 日 02:10，UTC）
  • Hamel Husain，X 文章（7 月 18 日 05:09，UTC）與貼文（05:16 與 16:35，UTC）
  • Santiago 於 X（7 月 18 日 16:26，UTC）
  • Ksenia Se，Turing Post（2026 年 7 月 20 日）
  • Louis-François Bouchard，Substack 與 louisbouchard.ai（2026 年 7 月 22 日）
  • Sydney Runkle 與 Harrison Chase，LangChain（2026 年 7 月 22 日）
  • 陳建鈞，《數位時代》（2026 年 7 月 28 日；依其文末說明，初稿由 AI 撰寫）
  • Yuyuan Feng 等 35 位作者，arXiv（2026 年 8 月 21 日，8 月 26 日修訂）。皆於 2026 年 9 月 28 日讀取。本詞是常設主題〈LLM 工程〉涵蓋的五個名詞之一，該頁把它與另外四個並排。

可不可靠

可靠，但有立場又可信又可靠兩者皆弱，謹慎採用立場可信，但材料薄弱

值不值得相信

每一點代表一項採用的來源，依兩項判斷置於六級量尺上。點不具名：本圖呈現的是證據的樣貌，而非對任何出版者的評價。

共享主題

共享來源網域

版本

本文內容需要更動時即改寫為新版本，每個版本都保留在自己的網址。

  1. v0002 目前
  2. v0001 已被取代

目前版本也位於 latest/。