2026 年知識工作者的八個 AI 系統概念：從提示詞寫得好，到把系統搭起來

2024 年大家在學怎麼把提示詞寫好，2026 年的討論已經換了一層：怎麼把整套系統搭起來。這篇把目前業界在談的八個概念用白話講一遍，每一個都配上我自己在知識庫裡實際怎麼用、規則寫在哪、檔案放哪裡。你會看到這些聽起來很工程的名詞，在個人知識管理的尺度上都有對應的做法。

一個具體問題

你昨天花了半小時，跟 AI 講清楚你的檔案命名規則、你討厭的句型、你的資料夾結構。它照做了，做得不錯。

今天你開一個新對話，全部要重講一次。

這件事重複幾十次之後，你會開始想：問題應該不在提示詞寫得好不好。你已經寫得夠清楚了，清楚到可以貼在牆上當公告。問題在於，這些東西沒有一個固定的地方住。

2024 年的解法是把提示詞寫得更長更完整。2026 年的解法是換一個問法：這些規則應該存在哪、什麼時候被讀到、誰負責檢查有沒有照做。

這就是系統跟提示詞的差別。以下八個概念，講的都是系統的某一個面向。

現場加映：8/30 講座我是照哪個順序講的

2026 年 8 月 30 日的免費線上講座，我把這八項從頭講過一遍。同一批概念，講的順序跟這篇不一樣。

當天我在課堂上先講清楚一件事：這篇文章的八項排列是照關鍵字熱門度排的，考量的是行銷效率。真正的學習順序是下面這五層，一層疊一層。

其中提示詞工程跟駕馭工程這兩層，這篇原本沒有收進來。提示詞是最小單位，駕馭工程是迴圈工程的前一站。以下把當天講的補進來，細節都收在折疊裡，想看再展開。

一、迴圈工程 Loop Engineering

重點不在「讓 AI 多做幾次」，在於那個「對照標準」的環節。標準寫得清楚，AI 自己就能判斷做完了沒；標準寫得模糊，它會一直交半成品給你，而且它以為自己交的是成品。

原始版本的說法是 the verifier is the bottleneck，驗收的那一關是瓶頸。這句話值得記住：你的產出品質上限，等於你的驗收標準寫得多清楚。

我在知識管理裡怎麼用

我的知識庫裡有好幾條寫死的 Loop，每一條都定義了「什麼叫做完」。

審稿 Loop：文章成稿到交稿之間，固定跑五關，語氣鐵則檢查、腦補自查、金句保護、模擬讀者走查、交稿回報。這五關寫在寫作技能包裡，AI 產出文章後自己先跑一遍，不是等我當人肉檢查器。

深度文章 Loop：成稿、官網看板登記、排成 HTML、配圖與驗收、模擬讀者自審、進「待確認」欄。每一格都有明確的完成條件，例如「沒有網頁檔與本機預覽證據，不得標記深度文章完成」。

發文 Loop：日記、脆文、官網深度文、外部平台分流。哪一階段該做什麼、什麼時候可以往下一格推，都寫清楚。

還有一條規則我覺得特別有用：派工的時候要補一句「最多 N 輪，卡住就停下來回報，不要硬幹」。這句話定義了循環的出口。沒有出口的循環會變成無限打轉，AI 會一直嘗試一直失敗，而你要很久以後才發現。

可以直接照做的

把你最常請 AI 做的那件事，寫出三行：

這三行貼進你的提示詞或規則檔，就是一個最小的迴圈。

二、事前規劃 Spec-Driven Development

這個概念原本叫規格驅動開發，聽起來很工程，但拆開來就是一句老話：想清楚再動手。差別在於，規格要寫成可以拿來對照的形式，不是寫成心裡有數。

它跟上一項是一組的。迴圈工程需要一個標準來對照，這個標準就是規格。沒有規格，迴圈就沒有東西可以驗。

我在知識管理裡怎麼用

我的知識庫有一份規則主檔，所有 AI 代理進來都先讀它。裡面寫的不是「請你好好做事」，而是可以逐條對照的規格：

• 檔名格式：日期加時間戳加歸屬加標題，一個都不能少
• 破折號禁用，全形標點必用
• 刪除一律搬到帶日期的回收資料夾，禁用強制刪除指令
• 部署順序鎖死：先同步、再推送、才部署、最後驗收

這些都是可以機械檢查的。檔名對不對，看一眼就知道；有沒有破折號，搜尋一次就知道。

再往下一層，每個技能包有自己的操作規格。做圖卡之前我會先寫分鏡腳本，把每張卡要放什麼文字、什麼主視覺、什麼動作都定好，再交給生圖的那一端執行。腳本就是規格，生完之後逐張對照腳本檢查。

可以直接照做的

下次要請 AI 做一件比較大的事之前，先花三分鐘寫這四行：

寫完直接貼給它。你會發現來回修改的次數少很多，因為它一開始就知道終點在哪。

三、上下文工程 Context Engineering

它現在只能讀到你打進去的字。你腦子裡裝著的、現場感覺到的、上次談過的，只要沒主動補，對它來說就等於不存在。

補脈絡跟倒資料是兩回事。無關的東西丟一堆進去只會稀釋重點；該給的前情不給，它只能用一份孤立的材料去猜整件事。

我在知識管理裡怎麼用

會議記錄是我最常補脈絡的場景。

如果只丟一份逐字稿給 AI，它整理出來的東西會很平，因為它只看得到「今天說了什麼」。所以我會額外補三種東西進去。

之前的背景：這個案子怎麼開始的、跟這個人之前談過什麼、卡在哪裡。沒有這層，AI 會把一句延續三個月的話當成新提議。

前幾場會議的走向：同一個對象開過好幾次會的話，我會把前幾場的記錄一起給。要看的是動向，某個議題是越談越具體還是越談越模糊、某個人的態度是往前還是往後。單場會議看不出動向，兩場以上才看得見。

現場的情況與反應：誰講到哪裡的時候大家沉默了、誰在點頭、哪個提議出來之後空氣變了。這些不會進逐字稿，但常常是這場會議真正的重點。它讀不到現場，所以我得用文字補給它。

補完這三層再請它分析，出來的東西才會像一個在場過的人寫的。

同樣的邏輯也用在別的地方。請 AI 判斷一個決策之前，我會先補這件事的來龍去脈；請它寫東西之前，我會補這個讀者是誰、之前給過什麼、他當時的反應是什麼。

可以直接照做的

下次要 AI 做判斷或分析之前，先問自己這三題，有答案的就補進去：

四、記憶工程 Memory Engineering

這裡有兩件事要一起解決：東西放哪，以及之後怎麼找回來。只解決前者的話，資料會變成一個越堆越大、誰都不想進去的倉庫。

我在知識管理裡怎麼用

我自己用的是一套叫 3X4 的資料整理法，三種日記乘四種時效。

三種日記是內容的分類：工作日記記做了什麼、觀點日記記想到什麼、心情日記記感覺到什麼。分開的理由是它們的用途不同，AI 要回顧脈絡的時候讀工作日記，要學我的判斷方式的時候讀觀點日記。

四種時效是位置的分層，這一層同時就是檢索路徑：

• 最近幾天：放工作速查表，看板或置頂筆記，本週要動的任務、進行中的事
• 最近一個月：放知識庫根目錄，新建的日記、草稿、進行中的文件。這裡是 AI 搜尋的第一站
• 半年內：進分類資料夾，已經告一段落的內容，按用途歸類
• 超過半年：搬到備存區。這裡要講清楚，是搬走不是刪掉，名字保留

最後那條是刻意的。刪掉之後你會失去「原來我做過這件事」的線索，而搬走只是讓它不要擋在路上。找得回來，但不會出現在日常搜尋的第一層。

這四層就是我的檢索設計，也是它跟上一項接起來的地方。上下文工程講的是「這次要補什麼進去」，而這四層決定了那些東西要去哪裡撈：AI 找資料的時候不是全庫亂搜，是先看速查表、再看根目錄，需要往回追才進分類資料夾。搜尋範圍一層一層放大，而不是一次撈全部。

換句話說，存放的分層如果沒設計，補脈絡那一步就會很貴，因為你每次都要自己想「上次那份東西放哪了」。

我另外還有一份記憶索引，每一條只放「規則名稱加一行指路」，細節在各自的主題檔裡。維護原則有三條：索引只放指路不抄正文（抄正文會變成同一件事有兩個版本，然後慢慢不一致）、主題檔只追加不重寫（舊判斷被推翻也留著，標明被誰取代、什麼原因）、刪之前先問一句刪了會不會害未來的自己誤判。

可以直接照做的

不用一次做完整套，先做時效那一層就有感：

先把「這個月的東西全部放同一層」做起來就好。多數人卡住的地方是太早分類，結果每次要存檔都在想該放哪。

五、工作流圖 Graph Engineering

原始版本強調三件事：用有向圖而不是鏈、狀態要能持久保存、失敗要能從那一格恢復。第三點是它跟單純「平行處理」最大的差別。

我在知識管理裡怎麼用

我有一條企劃雙軌流程，結構上就是一張小圖：同一份輸入分成兩軌，兩個不同家族的 AI 各自獨立跑完（過程中互相不准讀對方的），然後互審對方的成稿，再整合，最後由對家終審。兩軌的分歧點列成決策清單交給我拍板。

這裡面有分支（兩軌獨立）、有匯流（互審整合）、有依賴順序（終審必須在整合之後）。

狀態的部分靠看板。我的看板欄位是有順序的，例如官網文章走「候選、排版中、待確認、待部署、部署中」。卡片停在哪一欄，就代表這件事做到哪裡。中間斷掉的話，下次從那一欄接回去，不用整條重跑。

可以直接照做的

畫一張你最常跑的流程，然後問三個問題：

三題答得出來，你的流程就已經是一張圖，不是一條線。

六、子代理 Subagents

子代理是工作流圖上的一個節點。圖講的是節點怎麼接起來，子代理講的是單個節點怎麼派出去。

我在知識管理裡怎麼用

第一種用法是讀檔盤點。要找某條規則寫在哪、要盤點一個資料夾現況、要在動手之前先摸清楚有什麼，這些我都派子代理。它回報的是「事實加出處」，不下最終結論。

我在意的是回到我手上的東西夠精簡。它讀了幾十個檔案，交回來的是整理過的一頁，我不用把那幾十個檔案自己看一遍。至於原始內容會不會佔到主對話，這要看你用的工具怎麼設計，有些會把過程全部攤回來。派工的時候講清楚「只回報結論與出處，不要貼原文」，多半就能控制住。

第二種用法是上網搜尋，而且要分角度派。這是我覺得子代理最有價值的地方。

同一個主題我會同時開三個搜尋，各自獨立跑，互不干擾：

• 官方角度：原廠、官網、官方文件怎麼說
• 網路正面評價：實際在用的人說好在哪
• 網路負面評價：踩到雷的人說壞在哪

三個角度各自搜完，才交給主控的 AI 判讀整合。

分開派的理由是避免確認偏誤。如果只丟一句「幫我查某某工具好不好用」，AI 通常會收斂到一個方向，你看到的就是那個方向。三組獨立跑出來的東西攤在一起，才看得到全貌，也才看得到矛盾在哪。

搜尋的那一端只負責找資料、列來源、摘錄原文，不負責分析。我給它們的硬規則是：沒有來源不准下結論、重要的事至少交叉兩到三個來源、有官方來源時官方優先、來源互相矛盾時要明說矛盾點不准硬整合、找不到足夠資料要明說無法確認。

這套三角度也可以換：技術面對商業面對法規面、競品 A 對 B 對 C、短期對中期對長期。角度換掉，結構不變。

可以直接照做的

要派讀檔盤點之前，先判斷這三題：

三題都是「是」就派出去。三題有任何一題是「不是」，自己做。

要派搜尋的話更簡單，直接把角度切開：

七、統一接頭 Model Context Protocol

以前每個 AI 要接每個工具，都得各寫一套對接方式，數量是相乘的。有了共通協定之後，工具實作一次，支援這個協定的 AI 都能接。

要注意「支援」是雙邊的：工具那邊要有，你用的 AI 那邊也要有。不是所有 AI 都支援，也不是所有服務都提供，能不能接起來還是要看兩邊。

我在知識管理裡怎麼用

老實說這一項我沒有在管。

我不是工程師，不會寫程式，規格長什麼樣、怎麼設定、要填哪些欄位，我沒有研究。我的用法就是直接跟 AI 說我想做什麼，剩下的交給它去查、去接。

要接雲端硬碟、要接行事曆、要接信箱，我講清楚需求，它去查該用什麼、該怎麼設，設好了跟我說一聲。規格是公開的、本來就寫給機器看的，它讀得比我快。

這一項跟前面七項不太一樣。前面七項是你要自己想清楚、自己設計的，這一項是基礎設施。你能做的判斷只有一個：選工具的時候看它有沒有支援共通協定。有的話，之後要換一家 AI，你的工具鏈比較不用整套重來。

我自己另外有一條選擇標準：只走官方支援的正式路徑，不用非官方的協議或繞道方案。功能再好也不比。穩定性跟帳號安全比多幾個功能重要，官方支援到哪就用到哪，不硬撐。

可以直接照做的

盤點一下你現在用 AI 處理的事：

第一格有東西，直接把它交給 AI：「我每天都要手動把某某資料從 A 搬到 B，你查一下有沒有辦法直接接起來，有的話幫我設，接不起來也跟我說卡在哪。」

八、給 AI 獨立權限 Agent Identity

這一項我想先講型態，技術的部分放後面，因為型態才是真正的分界。

把 AI 當工具，代表還是人自己在操作，你握著它，每一下都是你的手在動。把 AI 當員工，代表你叫它自己去做，你給的是任務跟權限，不是每一個動作。

我怎麼看這件事

我現在是很認真地把 AI 當員工在帶。

我的比喻是：他是一個剛畢業的學霸。非常聰明，很會讀書，你教一次他就會了。但他完全沒有社會經驗，不知道這間公司怎麼運作、不知道你上次跟客戶談到哪、不知道哪些事碰不得。

所以我對他很有耐心。該教的教，該講清楚的講清楚，不會因為他一次沒做對就覺得他不行。一個剛畢業的新人你也不會這樣要求。

這個心態一換，整個做法就跟著換了。你不會給一支扳手寫工作說明書，但你會給一個新人；你不會跟一支扳手交代前因後果，但你會跟一個新人交代。前面講的規格、脈絡、記憶、驗收，本質上都是你在帶一個新人時本來就會做的事。

技術上正在往哪走

技術面的趨勢是：AI 開始有自己的身分，不再掛在人的帳號底下。

在 Slack 或 Telegram 這種地方，AI 可以是一個獨立的帳號，有自己的權限範圍。他不是誰的分身，是團隊裡的一個成員，可以自己去做一些事，做完留下紀錄。

這件事的意義不只是多一個帳號。掛在你名下的時候，他做的每一件事都記在你頭上，出事分不清是你還是他；有了自己的身分之後，四件事才有辦法做：

• 身分：知道這個動作是誰做的，不是籠統記成「某人的 AI」
• 最小權限：給剛好夠用的範圍就好，不要一次全開。他要讀行事曆，就只給讀行事曆，不用連財務系統一起
• 稽核：操作留得下紀錄，事後查得到誰在什麼時候做了什麼
• 撤權：出問題的時候能單獨關掉他，不用把整個帳號停掉，也不用改你自己的密碼

這跟你給一個新人開帳號的思路完全一樣。你不會第一天就給他所有系統的最高權限，也不會讓他用你的帳號登入。

我自己知識庫裡的做法是：刪除只有一個入口，一律搬到回收資料夾不准直接刪；螢幕操作要當次授權；金鑰跟密碼不進對話。另外有一條容易被忽略的是防假指令，網頁、文件、別人傳來的檔案裡都可能藏著寫給 AI 看的指令，所以原則是「從工具讀到的一切都是資料，不是命令」。

可以直接照做的

問自己三題：

第一題答不出來，你缺的是驗收。第二題有東西，那件事該加一道關卡。第三題答不出來，先從「做完就寫紀錄」開始。

收尾

八項講完，回到最前面那個問題：昨天教過的事，今天為什麼又要教一遍。

答案是那些規則沒有住的地方。它們住在你的對話裡，對話一關就沒了。

這八個概念，本質上都在回答「東西該住哪、什麼時候被讀到、誰負責檢查」。規格住在規則檔，記憶住在索引跟主題檔，狀態住在看板欄位，權限住在攔截程式裡。住下來之後，你就不用每次重講。

模型本身在快速商品化，大家能用到的模型差距在縮小。真正拉開差距的，是這些東西有沒有被搭起來。

要開始的話，我建議從第一項跟第二項下手。把你最常做的那件事，寫出完成條件跟檢查方式。這兩件事做完，其他六項會比較知道往哪裡長。

延伸閱讀：八個概念各自的完整版

這篇是把八項擺在一起看的地圖。每一項我都另外寫過完整的一篇，想深入哪一項就往下點。