我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。
我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。
上一篇討論了 AI Coding 如何改變軟體開發的成本與 Lead Time，以及為什麼傳統的工時計價、固定價格和階段式交付，都面臨不同的挑戰。這次想繼續討論企業軟體經常遇到的另一個問題：客製化修改。
過去企業在導入 ERP、CRM 或其他管理系統時，除了購買軟體本身，往往還需要支付額外費用，才能調整操作介面、增加功能或修改既有的業務流程。隨著 AI Coding 逐漸成熟，這些修改的實作成本有機會降低，客戶自然也會期待修改速度提高、費用下降。
對軟體服務商來說，這也產生了一個需要重新思考的問題。即使 AI Coding 能夠加快修改速度，每次客戶提出需求，仍然需要確認工作範圍、評估影響、安排開發與測試。如果客戶持續提出新的需求，這些工作仍然會累積相當多的交付成本。
不過，最近一次使用 Notion AI 的經驗，讓我開始思考另一種可能。如果軟體本身就能夠讓 AI Agent 調度既有功能，有些原本需要額外客製開發的需求，是否可以直接讓使用者自行完成？
之前參與 ERP 導入時，曾經遇到一個採購流程的討論。當時 ERP 顧問介紹系統可以直接從需求產生採購單，不需要先建立請購單，但導入方很明確地表示，公司規定採購一定要經過請購，而且還需要一層審核，因此希望保留請購流程。
從系統功能來看，這兩種方式都能產生採購單，但實際的管理流程並不相同。如果採用直接產生採購單的方式，代表採購需求可以直接進入執行階段；如果必須經過請購與審核，就需要確認誰可以提出請購、誰有權核准，以及未通過審核的需求應該如何處理。
這個案例是在 ERP 導入過程中確認流程，當時尚未發生功能完成後要求修改的情況。不過，如果系統原本已經按照直接採購的方式完成開發，後續才要求增加請購與審核，影響的範圍就可能超出新增一個表單或按鈕。
即使 AI Coding 可以快速完成程式修改，仍然需要先確認企業真正採用的管理規則，以及修改後是否會影響其他流程。類似的情況也出現在料號管理。兩項物料名稱相近，但規格不同，究竟應該使用相同料號，還是分開管理？這個營運流程決定會影響後續採購、庫存及生產資料的正確性，無法單純交由程式決定。
從這些案例可以看到，部分客製化需求涉及企業的業務規則、資料結構及跨部門責任。即使修改程式的成本下降，仍然需要先釐清需求與相關限制，才能決定系統應該如何調整。
然而，企業提出的客製化需求，並不一定都涉及這麼多業務規則。
最近使用 Notion 管理工作時，我遇到一個需求，希望批次重新命名許多任務，並且將原本的 Task 改成一般 Page。
當時我找不到可以透過既有操作介面快速完成這些工作的方式。如果按照過去使用軟體的經驗，可能需要逐筆修改，或另外尋找可以批次操作的工具。
但這次我直接向 Notion AI 描述希望完成的工作，讓它自行操作。大約五到十分鐘後，原本需要逐筆處理的資料就完成了調整。
這個經驗讓我注意到，當時我其實有一個新的功能需求，但最後並沒有真的需要軟體開發商新增功能。Notion 原本就具備建立、修改頁面及管理資料的能力，只是既有的操作介面沒有提供我想要的快速操作方式。AI Agent 可以根據自然語言指令，組合這些既有能力，完成原本需要大量人工操作的工作。
如果是在過去，我可能會希望 Notion 新增一個批次修改功能，或是另外開發小工具。但當 Agent 已經能夠完成這些操作，新增固定功能的必要性就降低了。
這也讓我開始思考，過去企業提出的客製化需求，有多少其實只是因為既有操作介面不夠方便，或是無法將幾個原本就存在的功能組合起來？如果軟體本身可以讓 Agent 調度這些功能，使用者就有機會自行完成一部分過去需要委託軟體商處理的工作。
當然，這次經驗只能說明 Notion AI 在當時成功完成了我的操作需求，不能因此認為所有客製化功能都能以相同方式處理。但它提供了一個值得研究的方向：軟體商是否應該從系統架構開始，就考慮如何讓使用者透過 AI Agent 操作既有功能？
進一步研究後，我發現 Notion 本身也正在朝這個方向調整產品架構。Notion 在 2025 年發表的技術文章 Notion's hosted MCP server: an inside look，介紹了如何透過 Model Context Protocol（MCP），讓 AI Agent 使用 Notion 的功能。MCP 可以讓 AI 應用取得外部系統提供的工具與資源，再根據使用者需求呼叫對應的操作。
值得注意的是，Notion 一開始嘗試將既有 REST API 轉換成 MCP Tools，但實際使用後發現，原本設計給傳統程式使用的 API，不一定適合讓 LLM 操作。因此，Notion 重新設計部分工具，例如 create-pages、update-page，並採用更適合 Agent 理解的資料格式，減少完成任務時需要的工具呼叫次數。
這代表讓軟體可以被 Agent 調度，可能還需要重新思考系統應該提供哪些操作，以及如何讓 Agent 更容易理解與組合這些能力。單純將既有 API 包裝成 MCP Server，未必能得到最好的效果。
另一個值得參考的案例是 Salesforce。Salesforce 已經提供將既有 Flow 開放成 MCP Tool 的能力。企業原本透過 Flow Builder 建立的業務流程，例如建立紀錄、分配商機、送出審核要求或發送通知，可以進一步讓 AI Agent 呼叫。（參考：Salesforce — Flows as MCP Tools）
這種方式有一個重要特性：Agent 可以根據使用者需求，決定何時呼叫既有的業務流程，但實際的流程仍然由 Salesforce 執行，並受到原本的權限與業務規則限制。
例如企業原本已經建立一套 CRM，具有查詢商機、修改狀態、建立報價與發送通知等功能。當業務主管希望將一批符合特定條件的商機重新分類，並通知對應的業務人員時，如果系統已經提供必要的操作工具，Agent 就有機會直接組合這些功能完成工作。這是一個可能的應用情境，並非我目前參與的 CRM 專案已經實作的功能。
從 Notion 和 Salesforce 的做法可以看到，企業軟體未來可能同時提供兩種使用方式。一種是使用者透過固定的操作介面執行工作，另一種則是透過 AI Agent，根據需求組合系統已經提供的能力。這兩種方式可以並存，也適合處理不同性質的工作。
回到軟體服務商的角度，我認為可以重新分類客戶提出的客製化需求。
| 需求類型 | 具體情境 | Agent 可能提供的協助 |
|---|---|---|
| 資料批次操作 | 批次修改任務名稱、報價分類或訂單狀態 | 呼叫既有資料操作工具 |
| 既有功能組合 | 查詢資料後分類、更新紀錄並發送通知 | 組合多個 API 或工具 |
| 系統配置調整 | 新增欄位、修改檢視或設定自動化 | 在系統允許的範圍內調整配置 |
| 業務規則與架構變更 | 修改審核規則、資料模型或權限架構 | 協助分析與實作，但仍需正式決策及工程治理 |
這個分類主要是用來判斷需求需要動用多少既有系統之外的能力，並不代表所有資料操作都可以直接交由 Agent 執行。例如批次修改報價分類，如果系統本身已有明確規則及安全的操作方式，就可能適合由 Agent 處理。但如果修改會影響後續財務報表或其他部門的工作，仍然需要確認資料使用範圍，以及是否應該經過人工審核。
這裡還存在一個重要限制：MCP 或 API 只能讓 Agent 使用系統已經提供的能力，無法自行補足不存在的業務邏輯與操作權限。例如 ERP 系統如果沒有提供修改採購單的受控操作，即使建立 MCP Server，也不代表 Agent 就能直接修改採購單。而且在企業系統中，有些功能涉及採購、成本、財務或其他重要資料，仍然需要保留必要的審核與權限控管。
以之前的 ERP 採購流程為例，假設 Agent 可以協助使用者批次建立請購單，但公司規定所有請購都需要主管審核，那麼 Agent 就應該依照既有規則操作，不能因為使用者下指令，就直接跳過審核。這些限制應該由系統本身的權限及業務邏輯處理。Notion 也在官方文件中說明，Agent 需要遵守使用者原有的存取權限，不能操作使用者沒有權限編輯的內容。（參考：Notion Agent）
因此，讓軟體可以被 Agent 調度，仍然需要考慮資料驗證、操作紀錄、錯誤處理及權限管理。尤其涉及大量資料修改時，可能還需要提供預覽、人工確認或復原機制，才能降低誤操作的風險。
從前面的案例來看，我認為 FDE 在設計企業系統時，可以開始考慮另一個問題：當客戶提出新的客製化需求，是否一定要開發成固定功能？
以之前參與的印刷業報價系統為例，客戶原本希望將報價、詢價與成本計算流程整合至 CRM。如果未來業務主管希望定期整理過去三十天尚未成交的報價，依照毛利或產品類型重新分類，再通知負責的業務人員，傳統作法可能需要新增一個報表或批次處理功能。
但如果系統原本已經提供報價查詢、資料分類與通知等受控操作，這些工作也許可以交由 Agent 組合完成。相較之下，如果需求是修改報價計算方式，或是新增一套原本不存在的成本分攤規則，就需要重新確認業務邏輯，甚至調整系統架構。
這兩種需求都可能被客戶稱為客製化修改，但需要投入的工作性質不同。
因此，未來在設計企業系統時，可以考慮 將核心業務能力透過受控 API 提供，再評估哪些操作適合開放給 Agent 使用。
固定的操作介面仍然有其價值，尤其是高頻、標準化或對可靠性要求較高的工作。Agent 則可以協助處理低頻、非標準，或需要組合多種既有功能的需求。
但這也意味著，軟體開發商需要在前期投入更多架構設計。例如哪些功能應該被設計成獨立的服務、哪些資料可以被讀取或修改、如何檢查使用者權限，以及 Agent 執行多個步驟時，如果中間發生錯誤，應該如何處理。這些工作仍然需要專業工程人員負責，也可能增加系統初期的開發成本。不過，如果這些能力可以減少未來大量的小型客製修改，長期下來可能降低系統維護與調整的成本。
目前我還沒有足夠的專案數據，可以證明這樣的架構在所有企業系統中都比較經濟。但從 Notion 與 Salesforce 的做法來看，這已經是一個值得納入系統設計的方向。
回到這個系列最初討論的問題：客戶會為了 FDE 模式而付更多錢嗎？上一篇已經提到，AI Coding 降低了許多程式實作成本，客戶期待開發速度提高、價格下降，有合理的依據。
這次的 Notion AI 經驗則讓我看到另一個可能性：有些需求甚至不需要再進入客製開發流程。如果企業軟體本身就能讓 Agent 調度既有功能，部分批次操作、資料整理或跨功能工作，就可以由使用者自行完成。
因此，未來的服務價值可能需要重新分配。一部分仍然來自核心功能開發、架構調整與系統整合，另一部分則可能來自提供可供 Agent 調度的系統能力，以及維持這些能力安全、穩定運作的服務。
這也讓我開始思考，軟體商是否應該將部分資源，從持續承接小型客製需求，轉移到建立更完整的 API、Agent Tools 與治理機制。不過，這種做法也有需要承擔的成本。當使用者可以透過自然語言直接修改大量資料，軟體商仍然需要負責工具設計、權限管理、錯誤處理與維運。若 Agent 操作造成資料錯誤，客戶也不一定會因為操作是由 AI 完成，就認為軟體商沒有責任。
因此，讓使用者自行完成更多工作，並不代表軟體商可以完全退出後續服務。真正需要評估的，是前期增加的架構與治理成本，能否換來後續客製需求與維護成本的下降，以及客戶是否願意為這些能力支付費用。
從這次的案例來看，我認為至少可以增加一個 FDE 的設計原則：當客戶提出客製化需求時，可以先確認是否能利用既有系統能力完成，再決定是否需要開發新的固定功能。如果希望讓更多需求可以由使用者自行完成，系統從一開始就需要考慮 API、Agent Tools、權限與操作驗證的設計。
這可能讓軟體商未來減少部分客製開發，也可能改變服務商的收入來源，但能否形成更好的商業模式，仍然需要透過實際專案驗證。
下一篇，我想再往前討論一步。既然 AI Coding 已經讓企業內部人員也能快速建立工具，而 Agent 又可能讓使用者自行完成更多系統操作，外部 FDE 應該如何和企業內部的開發能力分工？
有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！
iThome鐵人賽
看影片追技術