在談定製軟體專案的報價時，甲乙雙方最常對齊的單位是「人天」：多少工程師、幹多少天、單價多少。這個模型在需求穩定、交付邊界清晰時尚能運轉；一旦現場規則頻繁變、AI 工具把編碼效率拉高、甲方卻仍按「人頭堆疊」驗收，矛盾就會爆發——乙方覺得需求蔓延，甲方覺得「人沒少加，東西卻沒多」。
政策信號：從賣人頭到賣結果
2026 年 9 月，工信部發布《「人工智能+軟體」專項行動實施方案》，其中多次提到推動軟體生產模式變革、發展「模型即服務」「智能體即服務」，並明確到 2028 年要在重點行業打造智能體軟體標竿應用。文件沒有否定定製開發，但傳遞了一個清晰方向：評價軟體價值，越來越看實效，而不是只看投入了多少人天。
對正在做 ERP、MES、CRM、行業管理系統的企業來說，這意味著合同裡若仍只寫「XX 人 × XX 天」，上線後很容易陷入「代碼寫完了，業務用不起來」的扯皮。更可持續的寫法，是把交付拆成可驗收的業務結果。
業務邏輯：里程碑要比人天更具體
把項目從「階段付款」升級為「里程碑付款」，每個里程碑必須同時滿足四件事：
- 業務場景：誰在用、解決什麼操作（例如「倉管員掃碼入庫」而不是「完成入庫模組」）。
- 數據口徑：涉及哪些主數據、狀態字段、權限範圍，抽樣規則是什麼。
- 驗收腳本：給定測試數據，走通哪些流程、產出什麼單據或報表。
- 例外處理：失敗時系統如何提示、誰有權改、是否留痕。
里程碑不宜超過 2–4 週一個；太長又會退回「黑盒開發」。典型拆分示例：主數據與權限 → 核心單據閉環 → 報表與對賬 → 接口與上線切換。
設計邏輯：範圍、變更與「智能輔助」寫進合同
AI 輔助編碼、自动生成測試用例、智能補全文檔，會改變同樣功能的人天消耗，但不會自動改變業務複雜度。合同與需求規格裡建議單列：
- 範圍基線（Baseline）：功能列表 + 不在範圍內清單（Out of Scope），變更必須走變更單。
- 變更計價規則：新增里程碑按「場景 + 驗收腳本」估價，而不是臨時加人天。
- 智能輔助邊界：哪些環節可用 AI 提效（代碼生成、文檔草稿），哪些必須人工簽字（安全、合規、對外承諾）。
- 知識沉澱歸屬：過程文檔、配置、腳本誰持有，避免交付後運維斷層。
開發落地：驗收自動化與可觀測性
為讓「結果導向」可執行，技術側要配合三件事：
- 驗收用例入庫：每個里程碑對應一組自動化或半自動化用例，回歸可重複跑。
- 環境與數據隔離：UAT 環境數據可重置，避免「只在演示環境能過」。
- 可觀測日誌：關鍵操作有審計日誌，爭議時可追溯誰改了什麼。
若項目含智能體或規則引擎，驗收應增加抽檢機制：隨機輸入邊界案例，檢查拒答、升級人工、權限攔截是否符合設計，而不是只看「能聊天」。
三類常見爭議與預防
爭議一：「功能都做了，為什麼業務不用？」——預防：里程碑綁定崗位操作與培訓簽到，驗收時現場走崗，不只演示 PPT。
爭議二：「加個小需求為什麼要加錢？」——預防：變更單寫清影響的里程碑、腳本與工期，雙方簽字後再開發。
爭議三：「AI 提效了，人天能不能砍？」——預防：合同區分「實現成本」與「業務複雜度」；提效收益可體現在總價或周期，但驗收標準不降級。
試點建議：從一個閉環模組開始
不必等全系統重寫合同。選一個 2–3 週能閉環 的模組（如出入庫、工單報工、費用審批），用新模板簽補充協議：列場景、腳本、例外、付款節點。跑通後再推廣到全項目。衡量是否成功，看變更單是否減少扯皮時間、UAT 一次通過率是否上升，而不是看乙方少報了多少人天。
人天不會一夜消失，但它正在從「定價唯一單位」變成「成本估算參考」。把里程碑和驗收腳本寫進合同，才是定製軟體在「人工智能+軟體」背景下仍能交付可信結果的基本功。
與固定總價、敏捷迭代的配合
里程碑驗收並不排斥敏捷：每個 Sprint 仍可交付可演示增量，但付款與正式驗收掛在更大里程碑上。固定總價合同尤其要寫清「範圍凍結點」——哪次評審後新增需求走變更單，避免口頭加功能。對含智能體的模組，建議單獨里程碑驗收「規則版本 + 抽檢通過率」，不要與整站上線綁在一刀切。
行業數據顯示，軟體項目失敗約 三分之一源於需求與驗收口徑不清，而非技術實現本身。先把「什麼叫做完」寫進合同，比爭論 AI 替了幾個程式員更有價值。下次立項評審時，可先問一句：若明天乙方全員休假，我們能否憑腳本判斷當前里程碑是否達標——答不上來，說明驗收還沒寫清楚。