當一個不會寫程式的 PM，也能為自己的團隊做出專屬軟體，我們還需要為每一個需求買一套 SaaS 嗎？

最近我們公司發生了一件，我覺得很值得記下來的事情。

我們的 PM 覺得 Jira 不好用。

倒不是 Jira 做得不好。事實上，Jira 功能非常完整，完整到有時候你只是想記一句：

「這個 Bug 星期五以前記得改。」

結果要先思考它到底是 Epic、Story、Task 還是 Sub-task。

接著決定 Priority。

再選 Assignee。

再確認 Sprint。

最後你可能已經忘記原本那個 Bug 是什麼。

當然，這有點誇張。

但對一個小團隊來說，很多成熟的專案管理系統真正的問題往往不是「功能不夠」，而是：

功能太多。

於是我們 PM 做了一件以前不太可能發生的事情。

他沒有再去找另一套 SaaS。

也沒有寫需求單請工程師排期。

他決定：

自己做一套。

問題是——

他不會寫程式。

---

然後，他真的做出來了

透過現在的 AI Coding Agent，他開始用自然語言描述：

我們要怎麼追任務。

有哪些狀態。

產品跟客戶怎麼分類。

誰負責。

什麼時候到期。

哪些事情緊急。

哪些事情正在測試。

最後真的長出了一套我們自己使用的任務管理工具。

有 Board。

有 Table。

有 Calendar。

有產品分類。

有客戶分類。

有負責人。

有 Priority。

Kairos 是 Kairos。

Psyda 是 Psyda。

我們想怎麼分，就怎麼分。

甚至連工作流程的欄位名稱，都不是某家 SaaS 公司想像中的標準流程，而是：

我們自己平常真的在講的話。

這件事情乍看只是：

「AI 現在寫 Code 好厲害。」

但我後來越想越覺得，真正值得注意的可能根本不是 Coding。

而是另一件事：

當做一套軟體變得足夠便宜，我們還會像以前一樣「買軟體」嗎？

---

過去真正昂貴的，不是軟體，而是「做軟體」

以前如果公司有 15 個人，希望有一套很符合自己工作方式的任務管理工具，正常答案大概都是：

「不要自己做。」

因為自己做一套系統代表：

需求分析。

UI/UX。

前端。

後端。

Database。

登入權限。

測試。

部署。

維護。

一個 PM 如果跑去跟老闆說：

「因為 Jira 用得不順，所以我想花三個月開發自己的專案管理系統。」

老闆大概會先問：

「你是不是工作太少？」

所以我們才會買 Jira、Asana、Monday、Notion。

不是因為這些工具一定百分之百符合我們。

而是因為：

自己做太貴。

這就是傳統 Build vs. Buy 最重要的經濟條件。

但 AI 正在改變的，剛好就是這個條件。

McKinsey 在 2026 年談 AI 軟體開發時就指出，過去幾十年軟體開發一直存在一個基本限制：工程能力永遠不夠把企業想做的東西全部做完。 Coding Agent 正在改變這個限制，原本需要數週的工作，有些開始被壓縮到幾天甚至幾小時。(AI-powered software development: How technology is rewriting the rules)

所以以前的算式可能是：

自己做：100 萬

vs.

買 SaaS：一年 10 萬

當然買 SaaS。

但未來可能慢慢變成：

自己做：PM 跟 AI 搞兩天

vs.

買 SaaS：選產品 + 設定 + Migration + 教大家使用 + 每個月繼續付錢

這時候答案就開始不一定了。

---

這種東西，現在開始有人叫它 Micro Apps

2026 年初，TechCrunch 專門寫了一篇關於 Micro Apps 的報導。

它描述的正是這種新型態軟體：

不是要賣給一百萬人。

不是要募資。

甚至不一定要上 App Store。

而是：

我有一個問題，所以我做一個軟體給自己用。

有人為自己跟朋友做「今天到底吃哪一家」的 App。

有人做 Podcast 翻譯工具。

有人做家庭家事管理。

有人做自己的紀錄器。

甚至有些程式只打算存在幾個星期，需求結束，軟體也就跟著退休。(The rise of ‘micro’ apps: non-developers are writing apps instead of buying them)

這其實非常接近我們 PM 做的事情。

他不是想：

「我要打敗 Jira。」

他只是想：

「我們公司到底要怎麼追事情比較順？」

這兩個產品的目標完全不同。

Jira 必須服務幾十萬種組織情境。

我們這套只需要服務：

我們。

突然之間，規模小反而成了一種優勢。

---

SaaS 的設計邏輯是「找到最大公約數」

這也是成熟 SaaS 一個無法避免的問題。

它必須服務：

軟體公司。

製造業。

銀行。

顧問公司。

五人新創。

五萬人大企業。

所以產品必須提供很多彈性。

而為了提供很多彈性，就需要很多設定。

為了管理很多設定，又需要更多設定。

最後你只是想把一張卡片從 A 拉到 B，

但後面站著一整套企業級 Workflow Engine。

這不是 Jira 的錯。

這是所有通用型 SaaS 都會面對的 Product Design Trade-off。

它必須做：

Software for Everyone。

但 AI 開始讓我們可以做：

Software for Us。

甚至：

Software for Me。

---

以前是人適應軟體，現在可能開始反過來

這是我覺得更重要的改變。

以前公司導入系統時，我們常常聽到：

「這是系統標準流程。」

所以大家開始修改自己的工作方法。

本來我們有五個步驟。

系統只有四個狀態。

好，那我們改成四個。

本來大家習慣這樣分類。

系統沒有。

好，那我們改用它的分類。

慢慢變成：

人去適應 Software。

但是當生成一套小型軟體的成本快速下降之後，方向可能反過來：

Software 開始適應人。

我們 PM 覺得「產品」跟「客戶」一定要同時出現在任務上。

那就做。

想多一個：

「需求待整理／再討論」

就加一欄。

明天發現「測試與驗收」應該另外拆出去？

改。

沒有 Roadmap Committee。

沒有 Feature Request。

沒有等下一季 Release。

這種 Hyper-customization 以前是企業軟體非常昂貴的功能。

現在它可能慢慢變成：

Default。

---

更瘋狂的是：有些軟體可能根本不需要活五年

我們過去談 Software Engineering，會非常重視：

Scalability。

Maintainability。

Extensibility。

Architecture。

這些當然仍然很重要。

尤其是正式產品。

但 AI 可能正在創造另一種過去很少被認真看待的 Software：

Situational Software

因為某個情境出現，所以做一套軟體。

例如：

公司接下來三個月要準備某項認證。

以前：

Excel。

現在：

「幫我做一套認證進度追蹤系統。」

三個月後認證結束。

系統？

可以退休。

半年後又有新的專案？

重新做一套。

工程師聽到這裡可能已經開始心悸：

「等等，那 Technical Debt 怎麼辦？」

答案可能是：

沒有 Debt，因為公司倒掉的是那套程式，不是我們。

（笑）

這個觀念很反傳統 Software Engineering。

但如果開發成本真的變得非常低，它未必不合理。

TechCrunch 訪問的研究者甚至直接把這些工具稱為 personal、micro 或 fleeting apps：極度針對特定需求存在，需求消失之後，軟體也可以跟著消失。( Apps The rise of ‘micro’ apps: non-developers are writing apps instead of buying them)

---

但先別急著把 Jira 取消續約

講到這裡，很容易得到一個過度興奮的結論：

「以後不用買 SaaS 了，全部叫 AI 做！」

我倒不這麼認為。

因為我們 PM 做的這套系統，有一個非常重要的前提：

它是小團隊內部工具。

如果明天出現一個 Bug：

「咦，這張任務怎麼不見了？」

大家可能研究一下。

還找得到。

頂多有人碎念兩句。

但如果同一套開發方式拿去做：

薪資。

信用卡付款。

醫療資料。

客戶個資。

企業 ERP。

身份權限。

金融交易。

那就不是：

「AI 幫我做一個登入頁。」

這麼浪漫了。

Microsoft Research 對 Vibe Coding 的研究也發現，AI 並沒有讓專業能力消失，而是把專業能力轉移到其他地方：context management、快速判斷 AI 產出的 code，以及知道什麼時候不能再完全依賴 AI。(Vibe coding: programming through conversation with artificial intelligence)

換句話說：

Prototype 變簡單了，不代表 Production 也一起變簡單。

這條線一定要畫清楚。

---

我覺得未來會出現一條新的「Build or Buy」分界

以前我們問：

「這是不是公司的 Core Competency？」

不是？

Buy。

未來的問題可能變成：

這套軟體的風險有多高？使用範圍有多大？生命週期有多長？

個人管理工具？

自己做。

10 人團隊的 Task Board？

非常適合。

三個月的活動管理？

自己生。

PoC？

更不用說。

但如果是：

數百人共同使用。

公司核心資料。

Authentication。

Payment。

Audit。

Sensitive Data。

Mission-critical workflow。

那成熟 SaaS 與專業工程團隊的價值依然非常大。

因為成熟產品真正賣給你的，從來不只是一堆畫面。

它還包括：

Security、Governance、Availability、Audit、Permission、Backup、Compliance、Integration、Support。

這些東西很無聊。

直到出事那天為止。

---

真正可能被 AI 吃掉的，是 SaaS 的 Long Tail

所以我反而不認為：

AI 會消滅 SaaS。

我覺得 AI 最先改變的，可能是 SaaS 市場很長很長的尾巴。

以前我們會花錢買很多工具：

一個做任務。

一個追活動。

一個管內部需求。

一個整理客戶訪談。

一個管理某個短期專案。

它們通常都「大致符合」。

但都不是完全符合。

因為以前沒得選。

現在可能會開始出現：

「這麼小的需求，我幹嘛每個月付 20 美元？」

這不是 Price Sensitivity。

而是：

替代方案第一次出現了。

而且替代方案不是另一套 SaaS。

是：

我自己生一套。

這會是一個很有意思的市場變化。

---

下一代 Citizen Developer，甚至不一定知道自己在「開發」

我們以前就有 Citizen Developer。

Excel VBA。

Access。

Power Apps。

Bubble。

各種 Low-code / No-code。

但它們還是需要你學一套「開發工具」。

要知道：

Table。

Workflow。

Trigger。

Component。

Formula。

現在最大的不同是：

Interface 變成自然語言。

使用者不一定需要知道自己是在：

建立 relational database。

寫 API。

做 frontend state management。

設定 SQL query。

他只是在說：

「這張任務完成後，我希望它自動移到測試區，而且負責人要收到通知。」

然後 AI 開始做。

所以未來 Citizen Developer 最重要的能力，可能不再是：

懂多少程式。

而是：

懂多少問題。

---

這也會重新定義 PM

這是我們公司這次最讓我有感的地方。

以前 PM 的工作方式是：

想需求。

寫 Spec。

開會。

跟工程師解釋。

工程師開發。

PM 驗收。

有問題。

再開 Ticket。

未來可能變成：

想需求。

跟 Agent 講。

看結果。

改。

再看。

Deploy。

Microsoft 對 Vibe Coding 的觀察已經顯示，這種工作方式本質上變成一種反覆的「描述目標 → AI 產生 → 人快速評估 → 再調整」循環。(Vibe coding: programming through conversation with artificial intelligence)

McKinsey 也觀察到，當 Coding 速度快速提高，瓶頸便開始往其他地方移動：Code Review、Product Management，以及「到底下一步該做什麼」。(AI-powered software development: How technology is rewriting the rules)

這件事情很有意思。

因為以前最稀缺的是：

能把需求變成 Code 的人。

未來更稀缺的可能變成：

知道什麼值得被做成 Software 的人。

所以 AI 不一定讓 PM 變成工程師。

更準確的說法可能是：

PM 不需要先變成工程師，也開始擁有 Software Creation 的能力。

---

那工程師呢？

每次講到這裡一定有人問：

「那工程師是不是沒用了？」

我覺得剛好相反。

只是工程師的價值會往上移。

以前大量時間花在：

CRUD。

表單。

API。

Dashboard。

Layout。

小功能修改。

未來這些事情越來越容易被 Agent 吃掉。

工程師更重要的地方可能變成：

Architecture。

Platform。

Security。

Identity。

Data Governance。

Observability。

Infrastructure。

Integration。

以及最重要的：

哪些東西不能隨便讓 AI 寫完就上線。

這其實跟我上一篇談 AI Agent 的感覺很像。

AI 把 Execution Cost 降低之後，

Judgment 反而變貴了。

---

所以 IT 部門的角色也可能改變

我甚至覺得企業下一步真正要處理的，不是：

「准不准員工用 AI Coding？」

因為很可能已經擋不住了。

比較務實的做法是：

建立一個 Internal Software Governance Layer。

例如：

員工自己做 internal app 可以。

但是：

只能 Deploy 到公司指定環境。

帳號必須接公司 SSO。

Secret 不准寫在 Code 裡。

Database 有統一備份。

不能把敏感資料亂送外部模型。

Dependency 要掃漏洞。

正式給客戶使用之前必須 Code Review。

超過某種風險等級，就必須升級成正式 IT Project。

這樣 IT 就不一定是：

「所有軟體都由 IT 幫你做。」

而是：

「你可以自己做，但公司幫你準備一條安全的路。」

我覺得這才是 Citizen Development 真正成熟之後會走向的樣子。

---

Excel 當年其實已經演過一次

想想看 Excel。

Excel 出現之後，發生了一件很有趣的事情：

世界上突然出現幾億個「不是工程師的人」開始寫：

公式。

報表。

流程。

財務模型。

甚至小型 ERP。

他們沒有因此自稱 Software Engineer。

但大量原本可能要請 IT 做的事情，

從此再也沒有進 IT Department。

Micro Apps 很可能是 Excel 的下一階段。

TechCrunch 採訪的投資人也用了非常接近的比喻：這類個人化 App 很可能填補 Spreadsheet 與 full-fledged product 之間的巨大空白。(TechCrunch)

以前：

這需求太小，不值得寫程式。

所以：

Excel。

未來：

這需求太小，不值得買 SaaS。

所以：

AI，幫我做一個。

---

回頭看我們公司的這套任務管理工具

我不知道它最後會用多久。

半年？

兩年？

也可能有一天大家發現還是 Jira 比較好。

都沒關係。

它真正有趣的地方，不是這套軟體本身。

而是：

它原本根本不應該存在。

按照過去的 Software Economics，

這種需求太小。

使用者太少。

客製程度太高。

商業價值不足以支撐開發成本。

所以我們只能找一套「差不多」的 SaaS 來配合。

但是 AI 把開發成本往下壓之後，

突然有一整類以前「不值得被開發的軟體」，

開始值得被開發了。

這可能才是這波 AI Coding 真正深遠的地方。

---

下一個被 AI 改變的，可能不是程式設計

我們現在很常問：

AI 會不會取代 Programmer？

但我開始覺得，這可能不是最有趣的問題。

真正值得問的也許是：

當每個人都可以用自然語言把自己的需求變成一套小型軟體，我們還會像今天這樣購買軟體嗎？

未來 Software 可能會慢慢分成兩種。

一種是：

Software as a Product

大型。

穩定。

標準化。

被大量使用。

有人負責安全、維運與治理。

另一種則是：

Software as a Thought

我今天有一個工作方法。

把它描述出來。

AI 把它變成 Software。

工作方法改了。

Software 跟著改。

事情結束了。

它也可以消失。

到了那一天，

我們可能不再覺得：

「為自己做一套軟體」

是一件很大的事情。

就像今天沒有人會因為自己做了一個 Excel 表格，而宣布：

「我要進軍 Software Industry。」

所以我們 PM 做的這套任務管理工具，

真正讓我覺得有意思的並不是：

「一個不會寫程式的人，居然寫出了程式。」

而是：

「一個不會寫程式的人，已經開始覺得某些軟體根本不需要買了。」

這兩句話看起來很像。

但對 Software Industry 來說，

可能是完全不同的未來。