程式碼變便宜之後，誰來承擔軟體的責任？
AI 能幫你把軟體做出來，但三年後，誰負責讓它繼續好用？
當懂客戶流程的人，也能用 AI 開發應用，想法變成產品的距離縮短了。但需求改了誰更新？系統出問題誰處理？當初做的人離開後，誰能接手？
程式碼變便宜，持續維護、產品演進與服務責任，依然需要有人承接。
這也是 AI 時代，值得重新思考的軟體價值。
AI 能幫你把軟體做出來，但三年後，誰負責讓它繼續好用？
當懂客戶流程的人，也能用 AI 開發應用，想法變成產品的距離縮短了。但需求改了誰更新？系統出問題誰處理？當初做的人離開後，誰能接手？
程式碼變便宜，持續維護、產品演進與服務責任，依然需要有人承接。
這也是 AI 時代，值得重新思考的軟體價值。
當顧問也能用 AI 做出應用，軟體業的競爭，正在延伸到長期交付的能力。
最近，越來越多人開始問：當顧問可以用 AI 把客戶需要的系統做出來，軟體公司還剩下什麼價值？
熟悉採購、報銷、工程管理或人資作業的人，如今能把流程理解直接做成可操作的應用。過去需要反覆撰寫需求、交接與等待開發的工作，開始有了更短的實現路徑。對依賴標準表單、查詢、報表與簡單流程差異化的軟體商，這是實際的競爭壓力：場景專家更接近需求，AI 又降低實作門檻，原本必須購買的功能，可能變成客戶或顧問自行建置的工具。
但更值得追蹤的是背後的成本轉移：把應用做出來的成本下降之後，誰來承擔讓它持續正確運作的成本？
常聽到的說法是「程式碼變便宜，可信任變昂貴」。我想把它說得更精確一點：當程式碼更容易取得，可驗證、可持續、有人負責的服務，會在採購判斷中變得更重要。這篇文章想做的，是把「可信任」拆開來算帳——尤其寫給正準備把 AI 做出的應用交給企業使用的顧問與團隊。
這個分工，已經可以從市場上看見。
Lovable 的合作夥伴計畫區分 Experts 與 Solution partners，邀請專家和解決方案業者協助客戶設計、建置與交付應用，官網也刊載了 J&T Promotions 如何用 Lovable 服務客戶的訪談。AI 建置平台正把「替別人做應用」組織成一門可持續經營的生意。來源：Lovable 合作夥伴計畫
大型顧問公司的動作更直接。Deloitte 於 2025 年 3 月推出 Zora AI，採雲端訂閱模式，將財務等領域的專業經驗包進可部署的 AI agents，HPE 是公告中具名的使用與合作對象。PwC 同月推出 agent OS，主打跨平台 AI agent 整合、流程編排與治理。來源：Deloitte，2025/3 來源：PwC，2025/3
這些案例背後仍有工程團隊、技術夥伴與長期投資，不是「非工程師一夕變成 SaaS 廠商」。它們共同指向的是：顧問服務、軟體產品與持續營運的邊界，正在交疊。
但把「前 80% 已經接近免費」當成成本公式，容易看錯帳。
畫面、表單與標準功能，確實容易看見加速成果；可是畫面完成八成，不代表整個產品生命週期的成本也完成八成。
Google 的 2025 DORA 研究調查近 5,000 名技術工作者，超過八成受訪者表示 AI 提升了生產力；但研究同時指出，組織能否真正獲益，仍取決於流程、協作與系統能力。開發正在加速是事實，「維運只剩固定的兩成」則推不出來。來源：Google DORA Report 2025
更合理的看法是：原型與部分實作成本快速下降，驗證、整合、維運與責任承擔，因而在整體成本中變得更顯眼。AI 也能協助測試、除錯與維運，但省下多少工作，和誰要對結果負責，是兩個問題。
最容易漏算的成本，往往從第二家客戶開始。
假設一位顧問替客戶做好請款系統，很快想把同一套賣給另一家公司。第一家按部門主管簽核，第二家按專案負責人；第一家以含稅金額判斷門檻，第二家看未稅；第一家核准後可以補附件，第二家要求重新送審。這些差異未必能靠複製畫面解決。
每家都改一份，短期交付很快；等到修漏洞、調整共用欄位或更新第三方服務時，才會發現自己維護的是多套逐漸分岔的系統。
產品化真正需要累積的，是哪些規則可以共用、哪些差異可以設定，以及一個修正如何安全套用到所有適用客戶。
以下九類成本，應該在報價前算清楚。
| 容易被低估的成本 | 實際上會碰到什麼事 | 應該算進哪一筆帳 |
|---|---|---|
| 資料整理與語意確認 | 客戶代碼重複、歷史資料缺欄位；「已核准」究竟代表主管同意，還是已可付款？ | 導入、資料清理、規則訪談與驗收 |
| 權限與資料隔離 | 能登入的人，不一定能看所有案件；調職、代理、離職與跨客戶存取都要處理 | 權限設計、隔離驗證與持續管理 |
| 客戶差異與版本分岔 | 每家都「只改一點」，最後難以一起修正與升級 | 共用產品研發、設定機制與版本維護 |
| 整合失敗與交易一致性 | 外部系統已收單，本地卻逾時；重試後可能重複建單 | 整合驗證、重試控制、對帳與補償處理 |
| 升級、復原與稽核 | 新規則上線時，舊案件還在跑；備份還原也無法收回已寄出的通知 | 回歸驗證、資料遷移、復原演練與紀錄保存 |
| 長期支援與交接 | 客戶找不到資料、整合失效、原建置者離職；有人必須接手判斷 | 客服、監控、維運、文件與教育訓練 |
| 採購審查與續約 | 客戶要求架構說明、資安問卷、導入訓練與成效證明 | 售前支援、供應商審查、客戶成功與續約服務 |
| 用量與第三方依賴 | 儲存、寄信、API、備份與日誌都可能增加費用；使用中的 AI 才另外涉及推論成本 | 每客戶服務成本、用量監控與額度管理 |
| 商業責任與退場安排 | 事故誰回應、哪些工作另計、程式與資料歸屬、客戶離開時如何交付資料與設定 | 合約協商、風險評估、遷移與交付準備 |
其中最容易混淆的是權限。做好登入，只解決了「你是誰」；誰能看哪筆資料、誰能修改核准後的內容，是另一套需要定義與執行的規則。
買了底層平台，也需要知道責任分到哪裡。
Supabase 的共同責任文件寫得很清楚：平台承接部分基礎設施工作，使用者仍須管理存取權限、資料、安全控制、應用架構及第三方服務。這種分工可以降低負擔，但不會替你決定每家客戶的業務規則。來源：Supabase 共同責任模型
平台本身的品質也必須檢驗。Wiz 於 2025 年 7 月公開 Base44 的驗證漏洞研究，指出當時問題可能讓未授權者存取私人應用；Base44／Wix 在接獲通報後 24 小時內修復，Wiz 驗證了修正，且未發現遭惡意利用的證據。單一事件不代表所有 AI 建置平台都不可靠，但它提醒我們：平台能集中處理問題，也會集中承接風險。選擇平台時，要看隔離機制、修復能力、紀錄與責任安排。來源：Wiz，2025/7
從一次性交付走向持續服務，收費方式也要跟著改。
如果仍以「這次做出來花了幾天」定價，卻承諾未來持續支援、升級與故障處理，省下的開發工時會被後續服務吃掉。
顧問需要分清楚：哪些是首次導入費、客製變更費、平台或維運訂閱，以及哪些用量與服務承諾需額外計價。訂閱收入不代表已有 SaaS 規模效益；每位客戶仍需多少人工照顧，才決定這門生意能否複製。
也不是每套應用都需要做成多客戶 SaaS。短期、低風險、可替代的工具，可以採較輕的交付方式；持續支援單一客戶的專用系統，也是一種合理模式；真正要跨客戶擴張的產品，則需要共用的升級、支援與營運機制。
無論採共享或獨立環境，持續服務的責任都存在。「只給一家公司使用」也不代表可以隨時丟掉。只要承載正式資料、付款依據或關鍵流程，就要有人負責交接、保存與退場。
軟體公司的機會，是讓這些新應用更容易被長期交付。
未來會有更多應用由顧問、部門人員與小型團隊建置，也會有更多人需要可靠的平台承接身分、資料、流程、紀錄與營運能力。
但這個位置不保證由既有軟體商取得。PwC 已往流程編排與治理發展，Supabase 等服務也在供應共用底層能力。既有廠商不能只靠「我們比較懂維運」留住客戶，必須把能力變成容易接入、可以驗證且價格合理的服務。
Retool：開放建置入口，共用治理能力
Retool 的策略調整是一個具體的呼應。David Hsu 在 2026 年 3 月的文章〈Code is free. Now what?〉中，把焦點放在「生成應用」與「安全運作」之間的落差，並說明 Retool 改採 React、讓使用者透過外部 AI 開發工具建置應用的方向。這代表平台開始接受：使用者可以選擇自己喜歡的建置入口，平台的價值則延伸到應用接觸正式資源之後。來源：Retool，2026/3
到了 2026 年 6 月，Retool 推出新平台，讓 Claude Code、Lovable、Replit 等工具建置的 React 應用匯入執行，由共用環境承接已設定的身分驗證、權限、資料存取政策與版本管理。公告同時列出 Artefact、Lingaro 等顧問與系統整合夥伴，協助客戶部署交付。來源：Retool，2026/6
我的解讀是：當應用的創作入口分散，統一承接正式運作的平台，反而有機會服務更多建置者。 顧問可以用熟悉的 AI 工具把場景做出來，平台則把反覆需要的治理與營運能力共用化。更多人能開發，也就帶來更多需要被承接的應用。Retool 目前聚焦企業內部應用，跨客戶的權限、資料連線與業務規則，仍要靠正確的設定與驗證——但方向已經很清楚。
讓企業規則被不同應用共用
沿著這個方向，企業流程平台還可以進一步累積業務規則與流程狀態的管理能力：單據現在是什麼狀態？誰有權讓它往下一步走？核准依據是哪個版本？異常發生時，能否釐清已完成與尚未完成的動作？不同入口產生的應用與 AI 操作，都應依循一致的後端規則。
MCP 與 API 可以讓 AI 更容易呼叫這些能力；真正的權限判斷與流程限制，仍須由後端落實。延伸閱讀：企業軟體如何成為 AI 可操作的工具、AI Agent 權限與資安治理
每次交付，都應留下下一位客戶用得上的能力
回到那個請款系統。第一家與第二家客戶的差異，若停留在「各改一份」，就是前面說的版本分岔；若能被拆成金額判斷、角色指派與補件規則三個設定項，差異就從負債變成了共用能力，第三家客戶只需要調參數。這是產品團隊和一次性交付最根本的差別：不是誰比較會寫程式，而是誰有機制把現場的差異，經過判斷與抽象之後，收回產品裡。
這件事需要取捨，也需要驗證：哪些差異值得成為共用能力？哪些適合透過設定處理？調整之後，既有客戶能否繼續順利使用？為了涵蓋所有情境而讓產品難以理解與維護，是另一種形式的分岔。這個判斷沒有人能替團隊做，也正是持續營運的成本裡，最難被 AI 取代的部分。
因此，長期交付的成本不只是維運，還包含讓產品繼續成長的投資：把現場經驗整理成共用設計，把問題回饋到研發與服務，再用管理制度支持持續變動。這些能力累積得越扎實，下一次導入就少一些重做，既有客戶也持續受益。
顧問的場景理解，加上軟體團隊的工程與營運能力，有機會組成新的交付模式。它可以存在於一家公司的混合團隊，也可以由顧問與平台夥伴共同完成。讓客戶放心把重要的資料與流程交出來，並相信未來需求改變時，仍有人理解問題、持續改善與承擔責任——這才是「可信任」的定價基礎。
如果你正準備把一套 AI 做出的應用交給企業使用，不妨從一個正式流程開始，把資料、權限、簽核與異常處理一起定義清楚，再回頭看那九筆帳，哪幾筆已經有人負責，哪幾筆還沒有。Vital BizForm 的表單與簽核能力，可以是這個討論的起點。
軟體做出來之後，企業真正需要知道的，是接下來誰會把它照顧好。