未來不是 Buy vs. Build，而是 Buy the Capability, Build the Experience

前陣子我寫了兩篇跟 AI Coding 有關的文章。

第一篇是：

《下一個被 AI 改變的，可能不是程式設計，而是「買軟體」這件事》

原因來自我們公司一個很簡單的例子。

PM 覺得 Jira 太複雜。

正常的故事應該是：

「那我們換 Asana。」

或者：

「試試 Monday。」

或者非常有台灣企業精神地說：

「不然先用 Excel。」

結果現在多了一個以前不太可能出現的選項：

「算了，我自己做一套。」

問題是，

他不會寫程式。

但有 AI 之後，

這好像也不再是什麼大問題。

---

後來我又看到兩個 HR 的案例。

一個原本甚至是學烹飪的，半路轉 HR，現在靠 AI 做業務談判訓練、公司網站，甚至開始碰差勤系統。

另一個也做出了一套「看起來可以用」的系統。

直到 IT 打開 Database。

然後沉默。

再看五分鐘。

繼續沉默。

最後大概只剩一個問題：

「你要我修，還是要我重寫？」

所以我上一篇又談：

《AI 讓人人都能做軟體之後，真正的問題才開始》

但後來我發現，我一直站在「企業」這一邊思考：

員工都可以寫 Software 了，

那 IT 怎麼管理？

最近我開始換一個角度。

---

如果每個人都能自己寫軟體，那 SaaS 公司呢？

這可能才是更大的問題。

想像一下。

以前我要做專案管理。

我買 Jira。

因為 Jira 幫我做好：

Task。

Project。

Workflow。

Dashboard。

Report。

Notification。

Permission。

Comment。

Attachment。

Search。

Automation。

UI。

全部包在一起。

所以我買的是：

一套完整的 Application。

然後公司的人開始學：

「Jira 到底怎麼用？」

學什麼是 Epic。

什麼是 Story。

什麼是 Sprint。

怎麼設 Workflow。

怎麼設定 Dashboard。

有時候學到最後，我會開始懷疑：

我到底是在管理專案，還是在管理 Jira？

（笑）

---

但 AI Coding 出現後，這個邏輯可能開始改變。

因為我們其實不一定需要 Jira 幫我們決定：

畫面應該長什麼樣。

我真正需要的可能只是 Jira 背後那些可靠的能力：

• 任務
• 人
• Project
• Status
• Deadline
• Comment
• Attachment
• Permission
• History

至於我今天想怎麼看？

Kanban。

明天想改成「今天最重要的十件事」。

後天想做一個只顯示某三個產品的 Dashboard。

以前這些都叫：

Customization。

通常不是很難，

就是要加錢。

但如果 AI 可以在幾分鐘或幾小時內幫我生成一個介面呢？

突然出現一個非常有意思的問題：

我還需要 SaaS 公司替我決定 UI 嗎？

---

SaaS 可能不會消失，但 SaaS 的「外殼」可能開始變薄

我不認為 Jira、Salesforce、SAP、Workday 這些系統會因為 Vibe Coding 就突然消失。

因為企業軟體真正麻煩的地方從來不只是畫面。

真正難的是：

資料正確。

權限正確。

交易正確。

歷史不能亂。

Audit 要存在。

API 要穩定。

Backup 要有。

Compliance 要有人負責。

Security 出事不能回答：

「可是 Claude 那時候就是這樣寫。」

成熟 SaaS 真正有價值的地方，是這些很無聊的東西。

這些東西平常沒有人會在 Demo 裡鼓掌。

但一旦不見了，

大家都會突然非常尊敬 IT。

---

所以我開始覺得，

AI Coding 不一定會消滅 SaaS。

它比較可能消滅的是：

SaaS 對最後一哩使用體驗的壟斷。

---

從 Software as a Service，走向 Capability as a Service

以前 SaaS 公司的產品邏輯是：

我把功能跟畫面都做好，你進來使用。

未來可能變成：

我提供一組可靠、被治理的企業能力；你要怎麼使用，可以自己決定。

例如 Jira 不只是：

「這裡有一個 Issue 畫面。」

而是提供：

create_issue

update_status

assign_user

search_work

add_comment

get_project

這些 Capability。

然後使用者的 AI Agent 可以說：

「把今天會議裡提到的五件事情建立成任務，分給相對應的人，期限按照會議內容設定。」

完成。

甚至 Jira UI 都沒有打開。

這其實已經不是未來式了。

Atlassian 的 Rovo MCP Server 在 2026 年已經正式 GA，可以讓 ChatGPT、Claude、Cursor 等 AI client 直接讀取、建立與修改 Jira、Confluence 等 Atlassian 工作資料，同時保留 OAuth、原有權限、IP allowlist 與 audit log 等企業治理。2026 年 9 月推出的 MCP v2 又把 Loom、Bitbucket、Goals、Projects、Talent 等更多產品能力納入。(Atlassian Developer)

Atlassian 甚至公布，Rovo MCP 上線不到半年後，每個工作日已超過 500 萬次 MCP tool calls，每月使用人數超過 100 萬。這至少顯示一件事：使用者透過 Agent 操作企業軟體，已經不只是 Demo。(Atlassian)

---

這就是我所說的 AI-ready SaaS

「AI-ready SaaS」目前不是我想拿來宣稱的一個嚴格產業標準。

我比較把它當成一個產品設計原則。

以前所謂 AI-enabled SaaS 很容易是：

在產品右下角放一個聊天框。

然後宣布：

我們加入 AI 了！

😂

我覺得這很快會不夠。

真正的 AI-ready SaaS，不是產品裡面有沒有 AI。

而是：

這套軟體本身，能不能成為 AI Agent 可以理解、安全調用、組合與治理的能力。

這個定義差很多。

---

第一個條件：SaaS 必須是可靠的 System of Record

這還是最核心的價值。

例如 HR 系統真正管理：

Employee。

Organization。

Position。

Leave。

Attendance。

Performance。

Learning Record。

公司不希望每個 HR 用 AI 重新發明一次 Employee Table。

尤其是上一個人用：

employee_id

下一個人覺得太難懂，改：

staff_number

第三個 AI Agent 很有創意：

people_code_final_v2

到最後人資資料庫充滿歷史文化。

所以：

資料核心不應該每個人自己生。

AI-ready SaaS 第一個角色就是：

提供可信任的 Domain Model。

---

第二個條件：不能只有 API，還要有 Agent Interface

API 當然不會消失。

但 API 是設計給 Programmer 使用的。

Programmer 要知道：

Endpoint。

Payload。

Authentication。

Response Schema。

Error Code。

Pagination。

Rate Limit。

AI Agent 需要的則不完全一樣。

Agent 更需要知道：

「你可以做什麼？」

「這個 Tool 在什麼情況下應該用？」

「需要什麼權限？」

「執行會造成什麼改變？」

這正是 MCP 變得重要的原因。

Notion 現在也提供 MCP，讓 Claude、ChatGPT、Cursor 等 Agent 可以即時讀寫 Notion workspace，而不是只能叫 AI 產生文字再 Copy/Paste 回 Notion。(Notion)

Slack 的 MCP Server 也已正式 GA，讓外部 AI Agent 在保留 Slack 現有權限與安全控制的前提下，利用企業內即時的對話與工作 context。(Slack)

所以我會認為：

API-first 曾經是 SaaS 很重要的能力。下一步可能是 Agent-first。

---

第三個條件：AI-ready SaaS 不只是讓 Agent「看」，還要讓 Agent「做」

這裡差距更大。

很多企業現在的 AI 還停留在：

Search。

Summarize。

Answer Question。

也就是：

Read。

但真正開始改變工作的，是：

Action。

例如：

AI 不只是告訴你：

「這個 Project 有五個 overdue tasks。」

而是你說：

「把沒有更新超過七天的任務整理出來，依照負責人建立 follow-up，並通知相關主管。」

Agent 能真的執行。

這時 SaaS 提供的不再只是 Data。

而是：

Trusted Action Space。

Agent 可以做什麼。

什麼不能做。

什麼需要 Confirm。

什麼需要 Approval。

全部要被定義。

---

第四個條件：Permission 必須跟著 Agent 走

這會是企業級 AI-ready SaaS 很重要的一條線。

Agent 不是拿到一個 Super Admin API Key，

然後想幹嘛就幹嘛。

不然公司的 AI Assistant 很快就會進化成：

AI Intern with Root Access。

這不是數位轉型。

這叫資安事件預告。

😂

Atlassian 現在 MCP 的做法，就是 Agent 繼續受到既有 Atlassian user permission、OAuth scope、Admin setting、domain/IP allowlist 與 audit logging 控制。(Atlassian Documentation)

Notion 2026 年的新版本也開始替 Custom Agent 提供 audit log，讓 security team 可以追蹤 Agent 做了什麼。(Notion)

所以 AI-ready SaaS 的真正差異，不只是：

Agent 能不能 Call 我。

而是：

我能不能放心讓 Agent Call 我。

---

第五個條件：UI 應該開始接受自己不是唯一入口

我覺得這件事情對 SaaS 公司心理上的挑戰可能最大。

因為過去 Product Manager 花很多時間想：

Button 放哪。

Navigation 怎麼排。

Dashboard 怎麼設計。

User Journey 怎麼走。

未來可能有一部分使用者：

根本不進去。

例如：

「幫我查最近三個月所有延遲的 Project。」

Agent 去 Jira。

「哪些客戶最近 30 天沒有 follow-up？」

Agent 去 CRM。

「把高風險案件整理成今天下午會議簡報。」

Agent 做完。

使用者整個過程沒有開：

Jira。

Salesforce。

Notion。

甚至沒有看到它們 Logo。

從傳統 SaaS 的 KPI 看起來很恐怖：

DAU 掉了！

但從產品價值看：

使用量反而可能增加。

只是從：

Human Click

變成：

Agent Call。

Atlassian 公布 MCP 每工作日超過 500 萬 tool calls，我覺得就是一個很值得注意的訊號。(Atlassian)

所以未來 SaaS 公司可能要重新問：

我的成功指標還是 Page View、Session Time 嗎？

還是：

我的 Capability 被多少 Agent 安全地調用了？

這會是完全不同的產品世界。

---

第六個條件：AI-ready SaaS 還必須能「組合」

這也是 MCP 之後更有意思的地方。

例如一個 HR 說：

「找出今年剛升任主管、績效面談能力需要發展的人，安排一場情境演練，完成後把發展建議寫回人才發展紀錄。」

這件事可能同時碰到：

HRIS。

Calendar。

Kairos。

Learning System。

Email / Slack。

如果每個 SaaS 都是一座孤島，

最後還是要寫一堆 Integration。

這時候 Agent Protocol 就開始重要。

MCP 比較像：

Agent ↔ Tool / Data / Application

而 Agent 之間，現在逐漸往 A2A（Agent2Agent） 發展。

Linux Foundation 在 2026 年 4 月表示，A2A 已有超過 150 個組織支持，而且開始進入 Google、Microsoft、AWS 平台與企業 production use。(Linux Foundation)

如果之前在追 IBM 的 ACP（Agent Communication Protocol），現在也要更新一下：IBM 已宣布 ACP 併入 Linux Foundation 下的 A2A，ACP 團隊停止獨立發展並建議使用者往 A2A 移轉。(IBM)

所以現在我會比較傾向講：

MCP + A2A

MCP 讓 Agent 有手。

A2A 讓不同 Agent 可以互相找人幫忙。

---

然後最有趣的事情發生了：員工開始自己生成「最後一哩」

這就是我認為 AI Coding 與 AI-ready SaaS 真正會交會的地方。

例如一家公司使用成熟的 HRIS。

以前 HR 覺得：

「這個差勤介面真的不好用。」

只能提出 Feature Request。

等 Vendor。

等下一季。

等 Roadmap。

未來 HR 可以直接跟 Coding Agent 說：

「幫我做一個手機使用的介面，只要顯示今天上下班、本月異常、請假申請。」

Agent 生成一個小 App。

但注意：

它不建立自己的 Employee Database。

它也不重新實作 Leave Policy。

它不自己決定主管是誰。

底下全部透過正式 HRIS 的 MCP / API 執行。

所以 HR 自己做的是：

Experience Layer。

SaaS Vendor 提供的是：

Capability Layer。

這就開始形成一個我覺得很漂亮的架構：

Stable Core + Generated Edge

核心穩定。

邊緣可生成。

---

這也解決 Citizen Developer 最大的問題

回到我之前說的第二個 HR。

他用 AI 生成一套系統。

UI 很漂亮。

可以跑。

結果 Database 亂七八糟。

IT 看完不知道從哪裡下手。

如果企業軟體都往 AI-ready SaaS 走，

其實 Citizen Developer 根本不需要碰那麼多底層東西。

他不需要重新發明：

Identity。

Employee。

Permission。

Payroll Rule。

Customer。

Product。

Transaction。

Task。

這些全部是公司正式 System of Record 的 responsibility。

Citizen Developer 只需要：

組合能力。

甚至生成一個：

Disposable UI。

今天要 Kanban。

生成。

下個月大家不要 Kanban 了。

刪掉。

資料完全不受影響。

因為資料根本沒有存在這個 App 裡。

這會讓 Micro Apps 安全很多。

---

所以未來不是 Build vs. Buy

我們以前一直問：

自己做，還是買？

Build vs. Buy。

但 AI Coding 出現後，我覺得這個問題開始過時。

未來比較合理的模型可能是：

Buy the Capability, Build the Experience.

企業買：

ERP 的財務能力。

CRM 的客戶能力。

HRIS 的人資能力。

Jira 的工作管理能力。

Kairos 的情境演練與評量能力。

但是最後員工怎麼使用，

不一定全部由 Vendor 決定。

User、PM、HR，甚至 Agent 可以自己生成：

App。

Dashboard。

Workflow。

Automation。

Interface。

---

這對 SaaS 公司其實不是壞消息

一開始看起來很可怕。

如果使用者自己做介面：

「那我的產品不就沒用了？」

不一定。

反而可能代表你的產品從：

一個 Application

升級成：

Enterprise Infrastructure。

例如未來一家公司的 AI Agent 每天幫五千個人做工作。

背後每一次：

查客戶。

改任務。

建立訓練。

讀文件。

送出請假。

其實都在使用 SaaS Vendor 的 Capability。

你可能少了一次 Login。

卻多了 100 次 Tool Call。

從商業模式上看，

甚至可能從：

Seat-based pricing

慢慢出現更多：

Consumption / Action / Agent-based pricing。

這對 SaaS business model 也會造成下一輪改變。

---

我甚至覺得 SaaS 的產品護城河會重新洗牌

過去護城河可能是：

功能多。

UI 好用。

大家已經習慣。

未來我會更重視：

Domain Model

你是不是真的理解這個領域？

Data

你是不是企業可信任的 System of Record？

Business Rules

那些十幾年累積的 edge cases 有沒有被處理？

Permission & Governance

Agent 能不能安全操作？

MCP / Agent Interface

你的 Capability 能不能被 Agent 找到與使用？

Interoperability

能不能跟其他 Agent 與系統組合？

Auditability

Agent 到底做過什麼，能不能追？

這些才可能變成：

AI-ready SaaS 的新護城河。

---

所以未來 SaaS 最危險的一句話，可能是：「我們也有 AI」

我猜接下來幾年我們會看到很多產品首頁：

AI-powered XXX

然後點進去。

就是多一個聊天視窗。

這跟 2018 年每家公司都說：

Powered by Blockchain

有一點熟悉。

（笑）

真正值得問的不是：

你有沒有 AI？

而是：

如果我的 Agent 要使用你的產品，它能不能不靠人類幫忙操作 UI？

它能不能：

發現 Capability？

取得 Context？

安全執行 Action？

遵守原本 Permission？

留下 Audit Trail？

跟別的 Agent 合作？

如果答案都是可以，

我才會認為：

這是一套 AI-ready SaaS。

---

這也讓我重新思考自己的產品

例如 Kairos。

今天的設計還是典型 SaaS：

登入。

選情境。

開始演練。

看報告。

但如果真的相信這篇文章的論點，

未來 Kairos 不應該只是一個網站。

它還應該是一組可以被企業 Agent 使用的能力。

例如：

find_scenario

generate_scenario

create_practice_session

start_simulation

get_evidence_chain

get_assessment

get_development_plan

於是企業自己的 HR Agent 可以說：

「把最近三個月升任主管、溝通能力需要發展的人找出來，針對每個人的弱項建立一場新的情境演練。」

HRIS Agent 找人。

Kairos 建情境。

Calendar 安排。

Kairos 完成評量。

Talent System 收回 Evidence Chain。

員工甚至可能一次都沒有登入 Kairos 首頁。

以前我可能會覺得：

「慘了，沒有人來我的網站。」

現在反而會覺得：

很好，我的產品已經從 UI 變成 Capability。

這是完全不同的產品思維。

---

最後，我覺得 AI Coding 真正改變的可能不是「誰會寫 Code」

以前軟體公司的基本假設是：

使用者不能自己寫軟體。

所以軟體公司幫使用者決定：

流程。

畫面。

操作方式。

功能。

然後賣給他。

但如果這個基本假設消失了呢？

如果每個 PM、HR、業務主管，都可以跟 AI 說：

「幫我做一個比較符合我工作方式的東西。」

那麼 SaaS 公司真正應該守住的，

可能就不是：

那個畫面。

而是畫面背後真正難的東西：

Data。

Domain。

Rules。

Transaction。

Security。

Governance。

以及：

一組可以安全地被 AI 使用的 Capability。

所以，當每個人都可以自己寫軟體之後，

SaaS 公司當然還有東西可以賣。

甚至可能比以前更重要。

只是賣的東西會從：

「這是我們幫你做好的 Software，你照這個方式使用。」

逐漸變成：

「這是我們替你維護好的企業能力，你可以用任何方式使用。」

這就是我認為 AI-ready SaaS 真正應該長成的樣子。

而 SaaS 的下一場競爭，

可能不再只是：

誰的 UI 最好用？

而是：

誰最值得成為 Agent 背後，那個你看不到、但每天都在被使用的能力。

這也讓我現在更喜歡另一句話：

Buy the Capability. Build the Experience.

因為下一個被 AI 改變的，

可能不只是我們怎麼寫軟體。

而是：

我們究竟還需要軟體公司替我們決定多少「軟體應該長什麼樣子」。