從流程化到 AI 化:2026 年,軟體服務的典範轉移即將到來

2026 年,軟體服務將從流程化邁向完全 AI 化。了解如何把工作流變成 Skill、服務變成 MCP,掌握未來趨勢,效率提升 10 倍以上。

從流程化到 AI 化:2026 年,軟體服務的典範轉移即將到來
從流程化到 AI 化:2026 年,軟體服務的典範轉移即將到來

這一年,我一直在思考一件事:為什麼我們還在打開一個又一個的應用程式?

過去幾個月,我花了大量時間在研究 N8N、Make.com 這些自動化工具,寫了上千行的工作流,連結了十幾個不同的服務。每次發個社群貼文,我得打開 Facebook、Instagram、Threads,一個一個複製貼上,調整格式。即使用了自動化工具,還是得手動觸發,還是得在不同的介面之間切換。

但我發現,這個遊戲規則即將徹底改變。

典範轉移:從「我們去找服務」到「服務圍繞著我們」

你有沒有想過,為什麼企業管理已經從「去工廠訂貨」變成了「工廠為我們量身打造產品」,但軟體服務還停留在「我們去找 App」的階段?

過去,我們必須去各個工廠購買標準化的產品。現在,許多工廠圍繞在我們四周,根據我們的需求做客製化生產。這個典範轉移,現在正要發生在軟體世界。

關鍵的改變是什麼?未來的交互,不會再有 UI 的呈現。不會再有「打開這個 App」、「切換到那個介面」這種事。當你說到某個服務的關鍵字,它就自動跳出來幫你完成任務。純粹、直接、沒有多餘的步驟。

舉個例子,我說「發文到社群」,它就知道要把內容改寫成適合的格式、生成配圖、同時發布到 Facebook、Threads、Instagram 和部落格。我不需要打開任何一個平台,不需要調整任何格式,甚至不需要想「該用什麼圖」。

這不只是數位化和流程化,而是完全的 AI 化

很多人以為,把紙本作業搬到電腦上就是「數位化」,用 N8N 串起幾個服務就是「流程化」。但 2026 年要發生的,是更徹底的「AI 化」。

AI 化的核心,不是「自動執行你設定好的步驟」,而是「理解你的意圖,自己決定要執行什麼步驟」。

我現在做的事情就是這個:把過去所有的工作流,一個一個轉換成 Skill。每個 Skill 背後都有一個強大的 MCP(Model Context Protocol),包含了所有可能需要的 API 節點、客製化邏輯、錯誤處理機制。

這聽起來很技術,但其實概念很簡單:給 AI 一個工具箱,裡面有各種專業工具。當它需要完成某個任務時,它自己知道該拿哪個工具、該怎麼用。

Skill 的關鍵:把所有細節都定義好

很多人以為做 Skill 很簡單,就是寫個 prompt 告訴 AI 該做什麼。但真正要做到「生產級別」的 Skill,需要考慮的細節遠比你想像的多。

以社群發文這件事為例。看起來很簡單對吧?但你得考慮:

  • Facebook 適合長文,要保留完整段落
  • Threads 有字數限制,要切割成串文
  • Instagram 適合視覺為主,要生成吸引人的短標題
  • 部落格需要 SEO 優化、圖文並茂
  • 圖片要支援多種格式、多張上傳
  • 影片要支援各種解析度
  • 留言要能自動回覆,還要標註來源避免影響演算法

這些所有的細節,都要在 MCP 裡面定義好。而且,這個 MCP 要能讓 AI 跟 AI 之間溝通。一個負責內容改寫的 AI,要能把結果傳給負責圖片生成的 AI,再傳給負責發布的 AI。

這就是為什麼我說,接下來這一年最重要的事,不是學更多 prompt 技巧,而是把你的服務變成 MCP、把你的工作流變成 Skill。

現在該做什麼?

如果你已經用過 N8N,已經把工作流程化了,那恭喜你,你已經走在前面了。但接下來,你需要做的是:

把每個流程組件成一個 Skill。

這意味著:

  1. 確認你的所有服務都有完整的 API 支援
  2. 把這些 API 包裝成 MCP
  3. 定義清楚每個 Skill 要完成的任務和所有細節
  4. 測試、調整、優化,直到 AI 可以完全自主執行

我最近在做的,就是把「發文」這件事變成一個完整的 Skill。它包含了內容改寫、圖片生成、多平台發布、留言管理等等功能。當我說「發文助手」,它就自動完成所有步驟。

這個過程很累,要處理很多技術細節,要反覆測試和調整。但當它開始運作的時候,你會發現節省的時間絕對不止十倍。

你準備好了嗎?

問自己幾個問題:

  • 你盤點過哪些工作可以 AI 化了嗎?
  • 你的服務有完整的 API 嗎?
  • 你的工作流可以轉換成 Skill 嗎?

如果還沒有,我建議你可以從最簡單的開始:每天寫一點東西,試著讓 AI 幫你發布到社群。逼自己的大腦去理解這個新的工作方式,去適應「我只說意圖,AI 完成細節」的流程。

這是一個令人興奮的時代。所有的服務即將完全 AI 化,而能夠掌握這個趨勢的人,將會擁有巨大的優勢。

不是因為你比別人更懂技術,而是因為你比別人更早理解:未來不是我們去適應工具,而是工具來適應我們。

Read more

Claude 的 Project、Skill、Connector 到底怎麼分?一次搞懂三者的關係

Claude 的 Project、Skill、Connector 到底怎麼分?一次搞懂三者的關係

很多人問我,在 Claude 裡面,Project、Skill、Connector 這三個東西到底差在哪裡? 什麼時候該用哪一個? 老實說,我一開始也搞得很混亂。 但實際用了一段時間之後,我發現其實邏輯很簡單。 先從最基本的開始:Connector 是對外的資料來源 如果你需要從外部拿資料,比如說接 Google Calendar、接 Notion、接你自己的資料庫,你就需要 Connector。 它就是一個 MCP 的連結,讓 Claude 可以去外面抓資料回來。 沒有 Connector,Claude 就只能用它自己知道的東西,沒辦法碰到你的資料。 Skill 則是內部的運算邏輯 Skill 沒有辦法對外連接。 它只能在內部用 Python 或程式碼執行。 你可以把它想成是一個 Controller,專門負責處理運算的部分。 比如說,你想讓 Claude 用特定的格式改寫文章、

By Andy Lin
讓 AI 認識你 — Memory is All You Need

讓 AI 認識你 — Memory is All You Need

讓 AI 認識你 — Memory is All You Need 最近我在 Claude 上快速搭建了七大 Agent。 原因很簡單:你的助理應該是越使用越懂你。 而 Claude Project 有個關鍵功能叫 Memory,它會根據你不斷詢問的過程,主動提取記憶。 這就是我認為 AI 助手真正強大的地方。 GA 分析助手:從進階到客製化 自從我串接 GA MCP 後,這位助手已經變得非常厲害。 漏斗分析、訪客來源、異常事件追蹤、站上任何問題都難不倒它。 但我想要的不只是這些。 我希望它隨著時間,能夠對齊我的知識,知道我要什麼。 你不用想太多,不用一次設定好整個 instructions。 試著使用一週,再回頭看看 memory,你會發現它已經根據你的行為開始學習客製化了。 許多助手不需要懂老闆要什麼,但網站分析不一樣。 因為我沒有那麼多美國時間,

By Andy Lin
AGI 來臨:兩大 AI 巨頭的預測與警示

AGI 來臨:兩大 AI 巨頭的預測與警示

在近期的達沃斯論壇上,Anthropic 執行長 Dario Amodei 與 Google DeepMind 執行長 Demis Hassabis 進行了一場關於「AGI 之後的世界」的深度對談,揭示了 AI 發展的最新進展與未來展望。 AGI 時間線預測 Dario 重申了他去年的預測:在 2026-2027 年,AI 模型將能夠在諸多領域達到諾貝爾獎得主的水準。他表示目前 Anthropic 的工程師已經不再親自寫程式碼,而是讓模型來完成編寫工作,人類只負責編輯和周邊任務。他預估在 6-12 個月內,模型將能端到端完成大部分工程師的工作。 Demis 則持稍微保守的態度,認為在十年內有 50% 的機會實現 AGI。他指出編程和數學領域較容易自動化,因為結果可驗證;但自然科學領域則更具挑戰性,需要實驗驗證,且目前模型在「提出問題」和「建立理論」

By Andy Lin
讓 AI 當你的健康顧問:我用 Apple Watch 數據打造個人健康分析 Agent

讓 AI 當你的健康顧問:我用 Apple Watch 數據打造個人健康分析 Agent

最近我嘗試做了一個 Agent,專門用來分析我的身體健康狀況。 這不是什麼有商業潛力的專案,純粹是出於好奇。 我想知道現在的 AI 到底能幫我們把健康分析做到什麼程度。 資料從哪來? 要讓 AI 分析任何東西,首先得有資料。 我第一個想到的就是 Apple Health。 因為我每天戴著 Apple Watch,它本來就會自動記錄睡眠、運動、心跳這些數據。 除此之外,我也在嘗試另一個經絡檢測的儀器,有點像中醫把脈的概念,只是還沒整合進來。 我覺得如果未來能把更多資料源串在一起,應該可以做出更有意思的應用。 技術架構其實不難 我用了一個叫「Apple Health Auto Export」的 App。 這個 App 可以把健康資料透過 REST API 自動傳送到你指定的伺服器。 資料打到伺服器後,我再處理並存到 Database 裡。 接著寫一個 MCP Server,然後在

By Andy Lin