本地生活服务系统招标里「成品」与「定制」边界模糊导致验收时功能清单对不上合同。用能力分层说明两者各管什么便于研发排期与财务付款节点对齐。结论成品覆盖标准交易链路与统一后台定制覆盖非标状态机、外部 ERP 与深度报表。付款里程碑应绑定可验收产物而不是绑定「开发完成」口头状态。product_scope:standard:[下单,支付,配送状态,基础导出,多业务开关]custom:[特殊促销,ERP对接,非标预约流,深度BI]一、成品层能力边界用户端下单、商家接单、配送状态回写、后台查询、基础 CSV 导出、多业务模块开关通常属于成品。验收用固定 order_id 走通四步链并导出对照。成品不应包含「每个客户独有」的结算公式若商务规则复杂应单列定制里程碑与报价而不是塞进成品价后验收扯皮。二、定制层典型项深度促销引擎、特殊分润、对接第三方 ERP、非标预约状态机、多城特殊报表。每项宜单独估人天与验收标准避免「定制包」无上限。定制上线不应破坏成品导出列的默认版本若定制改列应 bump export 映射版本并通知财务。三、接口与扩展点成品应暴露稳定 webhook 与开放 API 文档定制在扩展点接入而不是 fork 核心订单服务。否则每次成品升级定制都要 merge 冲突。扩展点变更应 semver 管理定制团队订阅变更公告避免静默改字段导致对接断裂。四、验收与付款节点建议成品全链绿 → 付首款定制项按里程碑付尾款。每节点附测试单号、导出样本、截图归档减少「做了但说不清」的纠纷。试跑期测试单宜打明显标记报表默认过滤避免试跑金额混入正式周结。五、光合同城边界国内综合版成品含多业务统一后台与标准导出深度定制另议。商务规则由客户确定系统侧不抽成客户平台订单。交付文档区分 product_scope 与 custom_scope 两章投标时直接引用减少销售过度承诺。六、小结成品管「能营业」定制管「像你的生意」。边界写进合同比验收当天翻代码便宜。第二业态接入若属成品扩展不应重复收「整套对接费」除非合同明确另议。改价或改配送规则后宜抽进行中单与新单各三笔对照快照写入变更记录备查。付款节点应绑定可验收产物成品全链绿付首款定制项按里程碑付尾款每节点附测试单号与导出样本。试跑测试单宜打 is_test 标记报表默认过滤避免试跑金额混入正式周结。定制项验收宜附第三方系统联调记录例如 ERP 回写单号与订单 id 对照表避免「接口通但字段错」月底才发现。销售报价单宜拆成成品模块价与定制人天价两栏客户签字确认后再启动研发减少中途加需求却不加预算的摩擦。扩展点 webhook 失败应有重试与 dead-letter运营不应手工补单到 Excel 长期运行。验收会议宜邀请财务旁听定制边界避免研发交付后财务说不在付款节点内。成品扩展第二业态时合同宜写明是否另收对接费销售口头「都能做」应在投标阶段就落到附件清单。