先说结论
同一个需求，甲报一个价、乙报三倍的价，多数时候不是谁在宰客，而是两边算的根本不是同一件事。把报价拆开看，差异集中在六个地方。你拿这六条去问任何一家，都能问出对方的报价里到底包了什么。
一、场景数量：一个场景和四个场景，不是加量，是加倍数
「做个客服机器人」听起来是一件事，实际包含：政策问答、订单查询、退换货判定、转人工摘要。每个场景都要单独做资料治理、单独调提示词、单独定义「答对」的标准。
只做一个场景，两周能跑通；四个场景，不是四周，是六到八周，因为场景之间会互相干扰——同一个问题在两个场景里的正确回答可能相反。
问法：报价里包含几个场景？再加一个怎么算？
二、系统对接：接口好不好用，比数量更重要
对接 CRM 和对接一个十年前的自建系统，工作量差一个量级。接口有文档、有测试环境、有鉴权，一天能通；接口没文档、没人维护、字段还叫拼音缩写，光摸清字段含义就要一周。
问法：对接几个系统？对方有没有文档和测试环境？对接不顺利算谁的成本？
三、POC 和交付，是两件事不是一件
POC 验证「这条路走得通」，交付要「能上线、能运维、能交接」。把 POC 直接当交付卖，价格会低很多，因为省掉的正是后面那些不性感的活：权限、日志、异常处理、部署文档、验收清单。
问法：POC 是单独收费还是含在项目里？POC 到正式上线之间还有多少工作量？
四、部署形态：公有云和私有化，是两个产品
私有化要准备服务器、模型、依赖、内网穿透方案，还要处理「客户机房不能连外网」这类问题。同一套代码，私有化的工程量和公有云不是一个量级。
问法：报价按哪种部署形态算？换形态怎么补差？
五、数据治理：这块最容易被忽略，也最容易翻车
知识库答不准，八成不是模型不行，是资料本身脏：同一份制度有五个版本、PDF 里的表格切块切碎、老文件没人下架。治理要么由客户自己做，要么写进报价里由我们做——这块不写清楚，最后一定扯皮。
问法：资料治理包含吗？谁负责去重、定版本、下架旧文件？
六、交付边界：源码、许可、二次开发
业务侧源码给不给、通用组件归谁、能不能自己改、能不能转售，这四条在签约时最容易被跳过，出问题时最贵。
问法：交付哪些源码？后续我们要自己改，有没有限制？
怎么用这六条
不要只比总价，让每家按这六项给出分项的结构——不是数字，是「包不包含、由谁负责」。分项对不齐的两份报价，总价没有可比性。
我们自己的做法是：先做一次 30 分钟诊断，把场景数、对接数、部署形态定下来，三个工作日内给分项报价单。不定清楚范围就报价，对双方都不负责。
本文为方法说明，不构成对任何具体项目的报价承诺。