定制软件项目谈价时，甲乙双方最常对齐的单位是「人天」：多少工程师、干多少天、单价多少。这个模型在需求稳定、交付边界清晰时尚能运转；一旦现场规则频繁变、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 替了几个程序员更有价值。下次立项评审时，可先问一句：若明天乙方全员休假，我们能否凭脚本判断当前里程碑是否达标——答不上来，说明验收还没写清楚。里程碑写进合同不是为难乙方，而是让双方在同一页纸上讨论「做完了没有」。这一点在 AI 提效越明显的项目里，越要提前说清楚。