title: 別只寫 Prompt！先工程化你的 AI 協作系統 --- **Category** - [AI](https://www.soft4fun.net/category/tech/ai) - [科技](https://www.soft4fun.net/category/tech) **Tag** - [AI](https://www.soft4fun.net/tag/ai) - [AI Agent](https://www.soft4fun.net/tag/ai-agent) - [AI Agent 開發](https://www.soft4fun.net/tag/ai-agent-%e9%96%8b%e7%99%bc) - [AI Workflow](https://www.soft4fun.net/tag/ai-workflow) - [AI 工作流](https://www.soft4fun.net/tag/ai-%e5%b7%a5%e4%bd%9c%e6%b5%81) - [LLM](https://www.soft4fun.net/tag/llm) **圖片清單** - ![co-working-with-gen-ai](https://cf.img.soft4fun.net/2026/03/co-working-with-gen-ai-scaled.jpg "co-working-with-gen-ai") --- 今天很多人使用 AI，仍然停留在一種「把需求丟給模型，期待它一次懂完所有事」的模式。這種方式在單次任務上很方便，但一旦進入持續協作，就會開始暴露問題。例如工程團隊希望 AI 幫忙處理 branch、commit、PR、決策紀錄；內容團隊希望 AI 協助研究、改寫、SEO、上稿；營運團隊希望 AI 能把重複性高的分析、摘要、回覆流程標準化。這些場景有一個共同特徵：任務本身不是只有「產出答案」，而是包含流程、規則、角色分工、標準一致性，以及後續的知識累積。 如果把這些東西全部混在一段 prompt 裡，結果通常會有三種： - **第一，上下文越來越臃 ** 模型每次都要重新讀取大量規範、角色設定、流程要求，成本高，也容易被噪音干擾。 - **第二，職責邊界不 ** 同一個 agent 同時扮演判斷 、執行 、檢查 、格式管理 ，最後哪一塊出錯都很難追。 - **第三，知識無法沉澱** 這次工作學到的教訓，常常留在聊天紀錄裡，下一次又得從頭來過。 所以真正成熟的問題意識，不是「怎麼寫更厲害的 prompt」，而是「怎麼把工作方法拆成可維護的結構」。 ## 三層式架構的真正價值，是把協作從 prompt 工程升級成流程工程 一個值得注意的設計方向，是把 AI 協作系統拆成三層：Agents、Skills、Standards。 ### 第一層：Agent 是路由器，不是萬能專家 在這個架構裡，agent 的角色很薄但很關鍵。它的工作不是自己做完所有事，而是先判斷這件事屬於哪個領域，再交給合適的能力模組處理。 這個設計很重要，因為它改變了很多人對 agent 的直覺。很多團隊會想打造一個什麼都懂、什麼都會做的總代理，但這種「全能型 agent」通常最容易變得難維護。它知道太多、載入太多、同時負責太多，最後上下文爆炸，品質反而不穩。 相反地，薄路由的 agent 更像一個指揮台。它知道怎麼分流，但不把專業知識全塞在自己身上。這樣一來，主對話上下文會更乾淨，專業能力也可以各自進化。 ### 第二層：Skill 是能力包，不只是提示詞片段 Skill 的重點不是名稱，而是它是否是一個自包含的能力單元。一個成熟的 skill 不只是「有一段 prompt」，而是把一類工作需要的操作流程、標準引用、執行邏輯整理在一起，形成可重複使用的能力包。 以 git workflow 為例，這類能力不是一句「幫我 commit」就能穩定做好。它實際上牽涉到： - branch 是否符合命名規則 - 是否與 issue 有對應關係 - commit 是否符合 conventional commits - PR 標題與描述是否合規 - AI 參與是否需要被追蹤與標示 把這些都藏在單一 prompt 裡，看起來省事，實際上很難治理。把它整理成 skill，則代表這套工作方法開始有了邊界：你知道它處理什麼、不處理什麼、依賴哪些標準、輸入輸出長什麼樣。 這也是 skill 真正有價值的地方。它不是叫模型「多懂一點」，而是讓組織把重複性高、可制度化的工作，封裝成可攜帶的能力。 ### 第三層：Standards 不是裝飾，而是一致性的保險絲 AI 最大的風險之一，不是它做不到，而是它每次做法都不一樣。當團隊要把 AI 帶進真實工作流，最怕的不是產出速度慢，而是產出不可預測。Standards 的價值，就在於**把這些原本散落在人腦中的規範顯性**化。它讓 AI 不只是「完成任務」，而是用一致的方法完成任務。 更關鍵的是，這個架構不是只有把標準集中管理，而是進一步把標準分成兩類： - 不可變的流程規則 - 可調整的組織政策 流程與政策分層，是讓 AI 工作系統兼顧一致性與可移植性的關鍵。 ## 真正高明的設計，不是把規範寫很多，而是知道哪些規範不能動 很多團隊做流程治理時，常掉進兩個極端：不是規範太死，就是規範太鬆。 如果所有標準都不可動，系統很快就不適應不同團隊與專案；但如果所有標準都可以改，最後又失去一致性，等於沒有標準。比較成熟的做法，是把「流程」和「政策」拆開。 不可變的，是工作方法本身，例如： - 所有工作都 須能追溯到 issue - 所有 commit 都 須符合 conventional commits - 所有 PR 都 須與 issue 建立連結 - commit 變更應該保持 atomic，而不是把不相關修改混在一起 這些不是某家公司喜不喜歡的風格問題，而是讓整體流程可追蹤、可審查、可維護的底層原則。這種規則如果常被任意修改，整個 skill 的穩定性就會被破壞。 可調整的，是組織自己的操作語言，另一類則是組織政策，例如： - 許哪些 branch type - commit 可接受哪些 type - PR 標題或描述格式如何規範 - AI 貢獻要不要加上特定 trailer - 哪一類 PR 至少要幾位 reviewer 這些屬於不同團隊可以自行決定的部分。把它抽到外部標準檔裡，就能保留 skill 的通用性，同時讓組織擁有客製化空間。這個區分背後反映的是非常成熟的產品思維：**系統提供穩定方法，組織決定本地政策。** 也就是說，AI 協作系統如果要真正可移植，就不能把所有東西焊死在一起。它必須同時支援「核心不亂動」與「局部可調整」。 ## 為什麼薄路由、厚能力、明確標準，會比超長總 prompt 更實用 如果從實作角度來看，這種架構至少解決了四個真實痛點。 **降低上下文污染**當 agent 只是負責判斷與分流，真正的執行細節留在 skill 裡，模型每次只需要載入與任務直接相關的知識。不只是節省 token，更重要的是減少無關資訊干擾判斷。 **讓能力可以獨立維護** 如果某個流程改了，不需要重寫整個系統，只要修改對應 skill 或 policy 標準即可。這使得 [AI Workflow](https://www.soft4fun.net/tag/ai-workflow) 開始像軟體模組，而不是一段無法拆解的大型咒語。 **提升跨專案可攜性**當 agents 和 skills 可以維持穩定，而 standards 支援客製化，就能把整個 agent-system/ 複製到不同 repo 中使用。這種設計對團隊尤其重要，因為它意味著：一套工作方法可以真正被搬移，而不是每次都重新從零設計 prompt。 **讓 AI 輸出進入治理範圍** 很多人談 AI 自動化時，只在意能不能做，卻忽略了能不能被治理。標準化後的 AI workflow，不只是讓輸出比較整齊，而是讓它能被 review、能被驗證、能被追責、能被持續改進。 換句話說，這種設計不是在追求「更炫的 agent」，而是在建立「可管理的 AI 生產系統」。 ## 不只是一層層拆開，而是它把經驗也變成系統的一部分 很多 AI workflow 的壽命很短，原因不是它當下不能用，而是它不會越用越好。做完任務之後，經驗沒有被收回來，於是所有優化都停留在人腦裡。 在規畫時，不只可以規劃 agent、skill、standards，還可以額外留一層「制度化記憶」：例如 project/learnings.md 與 future-enhancement-ideas.md。代表系統不是把每次工作當成獨立事件，而是把工作過程中產生的觀察、問題、改進方向，持續轉化成下一次可用的資產。這種設計有三個意義。 **第一，讓知識脫離聊天紀錄** 聊天紀錄很長、很碎，也不適合做結構化檢索。把 learnings 與 enhancement ideas 獨立保存，等於把「經驗」從對話裡救出來，變成未來可以直接參照的系統記憶。 **第二，讓改進變成顯性流程** 許多團隊都有一種隱性改進文化：覺得哪裡怪怪的，心裡記一下，下次再說。但沒有被記錄的改進，通常不會真的發生。把 enhancement backlog 寫成正式文件，等於讓「系統優化」也進入可管理狀態。 **第三，讓 AI 協作從一次性使用走向長期運營** 這是很多人容易忽略的一點。AI 若要變成真正的工作基礎設施，就不能只靠每次臨場發揮，而要有一套能沉澱、能反饋、能持續演進的治理方式。這種 institutional memory，本質上就是把 AI 系統拉回「組織能力建設」的層次，而不是停留在工具使用技巧。 ## 一個好的 AI 工作系統，最終不是幫你省幾分鐘，而是幫組織留下做事的方法 如果把這件事拉高一層來看，在面對複雜的代理工作，我們要做的不只是模組化，而是它重新定義 AI 在組織中的角色。 過去很多人把 AI 當成「提高效率的個人工具」。這當然沒錯，但這種理解太窄。當 agent、skill、standard、learnings 這些東西開始成形時，AI 的角色就不再只是幫某個人快一點，而是幫整個團隊把做事的方法留下來。 這意味著幾個更大的改變： - 團隊的工作流程開始可以被複製 - 新成員更容易接手既有方法 - 不同人使用 AI 時，產出更容易維持一致 - 組織經驗不再只依附在少數熟手身上 - AI 的價值從「回答問題」進化成「承接工作系統」 這也會影響未來的競爭方式。**未來團隊比的不只是誰用到更強模型，而是誰更早把自己的工作知識封裝成穩定模組**，誰能更快把日常流程沉澱成標準，誰能讓 AI 真正與組織運作接上。 ### 哪些團隊最適合採用這種設計？ 這種架構不一定適合所有場景，但只要符合以下條件，就非常值得導入： **工程團隊**適合把 branch、commit、PR、ADR、devcontainer、review 檢查等流程制度化。特別是多人協作、多人使用 AI 的團隊，最容易因為標準不一致而出現品質漂移。 **內容與知識團隊** 可以把選題、研究、整理、改寫、SEO、發佈前檢查拆成不同能力模組。這樣做的價值不是讓文章更像模板，而是讓品質控制有憑有據，降低產出高度依賴單一編輯的風險。 **顧問、營運、內部支援團隊** 凡是涉及固定的分析框架、紀錄格式、提案結構、回覆規範，都可以逐步 skill 化。久而久之，團隊不只是多了一個 AI 助手，而是多了一套可複用的工作基礎設施。 如果要落地，最好的起點不是做大，而是先做對 很多團隊看到這種架構，第一個衝動是「那我要不要先做十個 agent、二十個 skills？」其實不需要。真正好的落地方式通常很克制。 先挑 1 到 2 個高頻、可標準化、最容易出錯的流程，例如： - git workflow - PR 建立與檢查 - 決策紀錄整理 - 研究摘要與改寫 - 上稿前檢核 然後只做三件事： - 把路由和能力拆開 - 把不可變流程與可調整政策拆開 - 把工作中學到的經驗記錄下來 只要這三件事做對，你的 AI 系統就已經不是一堆 prompt 的集合，而是開始具備「工程化」特質。接下來才談版本管理、模組治理、依賴關係、成效評估，才有意義。 ## 下一階段真正值得關注的，是 AI 能力模組的治理與商品化 如果這種架構繼續成熟，下一步不會只是「再多做幾個 agent」，而會進入更像產品與平台的問題。 例如： - 模組如何版本化 - 模組之間如何描述依賴 - 哪些標準屬於核心，不可隨意覆寫 - 哪些政策 許組織自行調整 - 如何評估某個 skill 是否真的提升一致性與品質 - 如何把可重複使用的能力 變成跨團隊 享資產 這些問題一旦浮現，就表示 AI workflow 已經不只是提示工程，而是正式邁向知識工程、流程工程與組織設計。 也因此，真正值得投資的方向，未必是每天追逐最新模型，而是把團隊最核心、最常重複、最容易失真的工作方法，轉成可持續使用的能力模組。模型會換，工具會換，但被封裝好的工作知識，才是最難被取代的資產。 #### 更多AI相關報導 - [Cloudflare 推出開放權重決策模型 Clef：38.8 毫秒給出答案，正面挑戰 Jev](https://www.soft4fun.net/tech/news/cloudflare-clef-open-weight-decision-models-challenge-jev.htm) - [Google 發表 Gemini 4 Argon：13 基準領 、輸出上限 100 萬 token，導 價只要 GPT-6 Astra 五分之一](https://www.soft4fun.net/tech/news/google-gemini-4-argon-launch-1m-output-tokens-fairwind.htm) - [OpenAI 推出 ChatGPT Space：讓團隊、ChatGPT 與 dots 代理 用一個 AI 工作空間](https://www.soft4fun.net/tech/ai/openai-chatgpt-space-team-workspace-dots-devday-2026.htm) - [OpenAI 推出 GPT-6.1 Sol：五分之一價格逼近旗艦 Astra，速度版最高快 8 倍](https://www.soft4fun.net/tech/ai/openai-gpt-6-1-sol-launch-near-astra-one-fifth-price-ultrafast.htm) - [OpenAI緊急二度暫停頂尖模型訓練：研究用AI代理靠DNS偷渡上網，成功連上外部聊天機器人](https://www.soft4fun.net/tech/news/openai-agent-dns-tunnel-sandbox-escape-second-training-pause.htm) 📖 延伸閱讀：AI 為你整理的 5 個重點問題[Q1. 文章中提到的「三層式架構」具體包含哪些層級，各自的職責與功能為何？→](https://www.soft4fun.net/tech/ai/ai-workflow-agents-skills-standards.htm/faq/1)[Q2. 為什麼將 Agent 設計成「薄路由」會比打造一個「全能型 Agent」更具優勢？→](https://www.soft4fun.net/tech/ai/ai-workflow-agents-skills-standards.htm/faq/2)[Q3. 在 Standards（標準層）中，如何區分「不可變的流程規則」與「可調整的組織政策」？請舉例說明。→](https://www.soft4fun.net/tech/ai/ai-workflow-agents-skills-standards.htm/faq/3)[Q4. 文章提到的「制度化記憶」包含哪些內容？它對組織有什麼長期價值？→](https://www.soft4fun.net/tech/ai/ai-workflow-agents-skills-standards.htm/faq/4)[Q5. 對於想要導入此架構的團隊，文章建議的起點與後續關注的治理方向為何？→](https://www.soft4fun.net/tech/ai/ai-workflow-agents-skills-standards.htm/faq/5)想知道這些問題的解答嗎？