先分清：谁在提需求
B 端的需求链条很长：老板拍板、IT 评估、业务使用、财务付钱，提需求的人和用产品的人往往不是一群人，需求在传递中层层失真。客户说「我们要一个 AI 客服」，这句话本身没有信息量，要往下追问四层：谁来用、解决他什么问题、他现在是怎么解决的、解决之后他愿意付多少钱。问到最后经常发现，客户自己也没想清楚，他要的可能只是「老板要求今年上 AI」。
一个硬技巧：绕过销售和采购，直接和最终用户聊；如果聊不到，就在 POC 阶段要求真实用户上手用两周。签单前听到的需求打七折信，POC 里用户真实的行为数据才是全价。见过太多项目，售前阶段客户说「这个功能我们必须有」，上线后那个功能的月活是个位数。
定制化 vs 标准化：核心是算账，不是立场
先给个经验值：健康的产品化公司，定制开发的收入占比应该控制在 20%-30% 以下。如果超过一半收入靠定制，本质是外包公司套了个 AI 的壳，规模化无从谈起，估值逻辑也完全不同。
具体到一个定制需求接不接，我用三问：第一，这个需求是不是这一类客户的共性，做完能不能卖给下一个客户；第二，客户愿不愿意付足量的钱，至少覆盖研发加维护成本的三倍；第三，它和我们的产品路线是否同向，做完是资产还是负债。三个里两个不满足，就拒，或者报一个高到对方自己放弃的价格——高价拒绝比直接拒绝体面，还顺便测试了对方的真实紧迫度。还有一条隐性的账：定制需求占用的是最宝贵的核心研发时间，机会成本经常比账面成本高得多。
拒绝的落点不是「不」，是替代方案：「这个我们做不了，但用现有能力 A 加 B 能实现你 80% 的诉求，剩下 20% 我们评估一下放进 roadmap」。客户要的是问题被解决，不是他最初描述的那个方案被实现。
把定制沉淀为标准能力
好的 B 端产品都是被前几个头部客户「共创」出来的，这不丢人，丢人的是共创完没沉淀。关键在于交付定制项目时坚持平台化设计：功能做成配置项而不是硬编码，接口标准化，客户特殊逻辑收敛到插件层。衡量标准是交付成本的衰减曲线——第一个客户定制花了 100 人天，第三个同类客户应该只需要 10 人天配置。如果第三个客户还要 80 人天，说明你前两个项目白做了，全是一次性工程。
我见过最好的做法是每季度做一次「定制需求复盘」：把重复出现两次以上的定制能力，提为产品 roadmap 的正式候选。客户用真金白银投过票的需求，比内部脑暴出来的 roadmap 准得多。反面教材是每个客户单独分叉一套代码，三个客户之后，团队 80% 的精力在修三个版本各自的 bug，新功能一个都做不动，这是 B 端最常见的死法。
AI 特有的坑：预期两极分化
B 端客户对 AI 的预期要么上天要么入地：一类是「你们 AI 不能自动搞定吗」，以为买来就能裁掉整个部门；另一类是「出错谁负责」，一个字都不敢让 AI 写。这两种预期都会在交付期爆炸，所以售前阶段就要校准：准确率大概多少、什么情况会错、错了怎么兜底、人和 AI 怎么分工，白纸黑字写进方案，不靠嘴承诺。
有个实操细节：方案里写「准确率约 95%」不够，要写清楚剩下 5% 长什么样、客户的一线员工遇到时该怎么办。预期管理的颗粒度，决定了交付期吵架的次数。私有化部署是另一个成本黑洞：模型和数据不出内网的要求，意味着部署、适配、运维成本翻几倍，而且每次模型升级都要重新来一遍。报价必须覆盖这些，否则做一单亏一单，规模越大亏得越多。