监管最难的不是立法，而是取证。但随着司法实践的积累和算法透明度要求的提高，"代码即罪证"的时代正在到来。产品团队需要重新审视一个问题：你的定价算法，经得起法庭的阅读吗？

一、两个案子，一个信号

2023年，杭州。

一名消费者在某在线旅游平台反复搜索同一家酒店，浏览记录越积越多，系统对他的”兴趣浓度”判断越来越高——然后，价格悄悄涨了。最终他支付的价格，比同一时段其他用户高出了将近30%。事后他起诉平台，法院认定：平台利用用户行为数据实施了定向提价，构成欺诈，判决退还差价并赔偿三倍。

2024年，北京。

某头部电商平台被市场监管总局查处。问题不是”老用户比新用户价格高”这种粗暴操作，而是更隐蔽的一招：给不同用户群发不同面额的折扣券，表面上人人都有优惠，实际上新用户券值更高、老用户券值更低，变相制造了价格差。最终以”虚假促销”被罚款50万元。

这两个案子单独看，都只是普通的消费者维权新闻。但放在一起，它们传递出一个共同信号：法律对算法定价的容忍边界，正在快速收窄，而且收窄的速度远远超过大多数产品团队的认知更新速度。

更重要的是，这两个案子有一个共同的技术核心——被当作证据使用的，不是某个高管的内部邮件，不是某份会议纪要，而是代码逻辑本身：系统根据哪些数据做了什么判断，最终输出了什么价格。

“杀熟”已经不是道德问题了。它正在变成一个可以被法庭解读的工程问题。

二、我们在讨论的到底是什么

在正式展开之前，有必要先厘清一个长期被混用的概念群。算法定价领域有四个词被反复交替使用，但它们的法律含义截然不同：

动态定价（Dynamic Pricing）：根据供需关系、库存水位、时间段等市场因素实时调整价格。机票、酒店的价格随淡旺季变化，本质上是这个逻辑。这在全球范围内目前仍被普遍认为是合法的市场行为。

算法定价（Algorithmic Pricing）：用机器学习模型代替人工制定价格策略。它可以只考虑市场因素，也可以引入用户数据。合法与否取决于输入的变量是什么。

个性化定价（Personalized Pricing）：针对不同用户展示不同价格，依据是用户的个人属性或行为数据。这是监管的核心靶区——用户画像越丰富、个性化程度越高，法律风险越大。

监控定价（Surveillance Pricing）：基于对用户的实时监控数据（浏览轨迹、停留时长、搜索频次、设备信息等）动态调整价格。美国马里兰州2026年4月刚刚通过立法明确禁止的，就是这种。

中国语境里的”大数据杀熟”，本质上是个性化定价与监控定价的交集地带：平台用老用户的历史数据判断其”付费意愿”，然后向其展示高于新用户的价格。

这四个概念的区别不是文字游戏。从工程实现的角度看，同样一套定价系统，仅仅因为“输入了哪些特征变量”的不同，就可能从完全合法变成违法。 而这个区别，往往只体现在几行代码里——几行在产品需求文档里甚至不会被专门提及的代码。

三、黑箱里的生意经

要理解为什么这个问题如此棘手，需要先理解算法定价系统在工程层面是如何运作的。

一个典型的互联网平台定价系统，通常由三层构成：

1. 数据层：收集用户行为数据（搜索记录、浏览时长、购买历史、支付方式偏好、设备型号、地理位置）、供给侧数据（库存、竞品价格、历史成交）、以及外部数据（节假日、天气、事件）。
2. 模型层：将上述数据输入机器学习模型，预测每个用户的”价格弹性”——即这个用户在什么价位会放弃购买，以及在什么价位依然会成交。模型会给每个用户打一个”支付意愿分”。
3. 决策层：根据支付意愿分，在一个价格区间内选取对应的展示价格。价格弹性低（愿意付高价）的用户，看到的价格靠近区间上沿；价格弹性高（对价格敏感）的用户，看到的价格靠近区间下沿。

从商业逻辑上看，这套系统无懈可击：它最大化了每笔交易的营收，同时理论上保证了”每个用户都在他能接受的价格内成交”。

但从法律逻辑上看，它制造了一个严重问题：系统在对同一件商品、同等交易条件下，向不同用户展示不同价格，而差异的依据是用户的个人数据——这正是“大数据杀熟”的定义。

更麻烦的是，这套系统的运作全程在服务器端完成，用户看不到，监管机构也看不到。平台可以在用户投诉时解释说”价格波动是因为供需变化”——这在技术上并非谎言，因为模型里确实也包含了供需变量——但不是全部真相。

这就是算法黑箱的本质：它不是一个简单的”是/否”开关，而是一个将几十个变量加权混合之后输出的连续值。在这个混合过程中，用户数据和市场数据被以一种外部无法还原的方式融合在一起。

这个黑箱，长期以来是平台的护城河。但现在，它正在变成一个法律风险的容器。

四、取证的战争

监管最难的确实不是立法，而是取证。

中国在2021年通过《个人信息保护法》，在2022年出台《互联网信息服务算法推荐管理规定》，在2024年开展四部门联合专项整治，在2026年4月颁布《互联网平台价格行为规则》正式施行——这条立法时间线相当密集，覆盖了从原则禁止到细则认定的完整链条。

但执法效果呢？

现实是：有据可查的”大数据杀熟”处罚案例相对稀少，且罚款金额与平台营收相比微不足道。根本原因就是取证困难。

困难一：用户难以自证。 用户感知到价格不对，但很难构建完整的举证链条。你需要同时、同地、同设备条件地比较两个不同账号看到的价格，还需要排除优惠券、会员等级、库存等合法差异因素。这在技术上非常繁琐，对普通消费者基本不可能完成。

困难二：监管机构缺乏技术手段。 要证明”差价源于用户数据而非市场因素”，需要获取算法模型的源代码和训练数据，然后做因果推断分析——这既需要高水平的技术人员，也需要相应的法律授权。目前的监管体系在这两方面都存在明显短板。

困难三：算法本身的不可解释性。 即使拿到了代码，深度学习模型的决策逻辑也难以被人类语言直接翻译。模型说”这个用户的支付意愿分是0.87″，但说不清楚这个分数里，用户的”浏览了3次”这个行为到底贡献了多少权重。

这些困难共同构成了一个现实：平台在事实上处于举证责任倒置的有利位置——你无法证明我在歧视，所以我就没在歧视。

但这个局面正在发生变化，而且变化的速度比大多数人预期的快。

五、三条正在改变游戏规则的趋势

趋势一：算法透明度义务从”软性倡导”变成”硬性要求”

中国的《互联网信息服务算法推荐管理规定》已经要求平台”以适当方式公示算法推荐服务的基本原理、目的意图、主要运行机制”。《互联网平台价格行为规则》进一步要求，对不同交易条件的消费者实行不同价格的，须在服务页面显著位置公开相关规则并告知消费者。

欧盟的《数字市场法》（DMA）和《人工智能法案》（AI Act）对大型平台的算法解释义务更为严格，要求算法决策具备”可解释性”，且监管机构有权要求平台提供算法审计报告。

美国纽约州已在2025年通过了算法定价透明度法律，要求平台披露个性化定价的存在及其依据。

这意味着什么？ 意味着”你无法证明我在歧视”这个防御策略正在被侵蚀。平台将被要求主动证明自己没有歧视，而不是等待外部证明其有歧视。举证责任在悄悄转移。

趋势二：司法实践中”代码审查”能力的积累

杭州案和北京案之所以能够成立，部分原因是原告方和监管机构都采用了”对照实验”式的取证方法——用多个测试账号、在控制变量的条件下，系统性地比较价格输出，从统计学意义上证明差异的存在和规律性。

这种取证方法并不需要读懂源代码，但它可以构建出”算法歧视”的统计证据。当这种证据积累到一定程度，法庭会要求平台举证反驳——而平台一旦需要主动拿出算法来自证清白，黑箱就不再是防护罩了。

随着数字取证技术的成熟和专业律师的积累，这条路径的可复制性越来越强。

趋势三：基础设施层的监管渗透

值得高度关注的是一个新的监管思路：不只盯着平台本身，而是从应用分发的基础设施入手。

中国监管机构已经开始探讨让应用商店承担算法合规的审核责任——手机厂商审核入驻 App，要求其符合算法透明度的最低标准。这意味着算法合规的压力将从政府执法端延伸到平台分发端，覆盖范围将大幅扩展。

这三条趋势合在一起，指向同一个结论：算法黑箱的防御价值在衰减，而合规风险的暴露面在扩大。

六、从工程设计端重构”定价正当性”

大多数团队面对监管压力的反应，是在产品层面加一层”用户须知”，或者让法务审核一遍用户协议。这是一种典型的误判——把结构性的工程问题当成了文案问题。

真正的合规，需要从算法设计阶段就介入。以下是几个可操作的工程原则：

原则一：特征变量的”合法性审计”

定价模型的输入特征，是合规风险最集中的地方。一个实用的做法是建立”特征分类清单”，将所有可能输入定价模型的变量分为三类：

• 绿色特征：供需数据、库存水位、竞品价格、时间段、地理区域（非用户级别）——这些反映市场条件，普遍被认为合法。
• 黄色特征：会员等级、历史购买量、优惠券使用情况——这些与交易条件挂钩，需要配合透明的规则公示才合规。
• 红色特征：用户的搜索频次、页面停留时长、设备类型、支付能力推断、消费偏好画像——这些直接指向个人支付意愿的推断，在中国现行法律下被明确列为禁止项。

每次定价模型迭代上线，都应当有一份特征变量审计记录，明确标注哪些特征被引入、每类特征的法律风险评级，以及是否经过合规审查。这份记录本身，就是未来应对监管调查时最有价值的”自证材料”。

原则二：价格决策的”因果链可还原性”

好的定价系统设计，应当能够回答这样一个问题：对于任意一笔交易，系统能否事后解释”这个价格是怎么得出来的，哪些因素起了多大作用”？

这不是要求取消机器学习，而是要在工程架构上预留决策日志——记录每次定价时的主要输入变量权重快照，以备事后审计。

很多团队没有这个习惯，因为日志存储有成本，而且”从来没人要过这些数据”。但监管压力到来之后，这套数据就是你证明自己合法经营的原始证据。没有日志，就是没有辩护材料。

原则三：区分”促销逻辑”与”歧视逻辑”的代码边界

北京案中的电商平台之所以被罚，不是因为给用户发了折扣券，而是因为折扣券的发放逻辑本质上是”用优惠券形态实现的差异定价”，且这个逻辑对用户不透明。

这说明，“发折扣”和“差异定价”在代码层面可能共用同一套逻辑，但法律对它们的判断截然不同。 区别在于：促销逻辑是”所有用户面对相同的基准价，部分用户获得额外优惠”；歧视逻辑是”不同用户面对不同的基准价，包装成优惠券的形式呈现”。

从代码架构上，这意味着基准价格计算和优惠策略计算应当是严格分离的两个模块，且优惠策略的输入变量不能包含前述”红色特征”。这个分离，需要在系统设计阶段就确立，而不是在法律风险出现后再做拆分——后者的代价会高出十倍不止。

原则四：建立”定价解释权”的用户接口

《互联网平台价格行为规则》第七条要求平台明确标示价格及相关计费规则，不得收取任何未予标明的费用。这在产品层面意味着什么？

意味着当用户质疑某个价格时，平台应当能够给出一个有意义的解释，而不是”价格受多种因素影响实时浮动”这种套话。

一些头部平台已经开始做这方面的探索：在价格展示页面增加”为什么是这个价格”的说明入口，解释当前价格反映了哪些市场因素（库存、需求强度、时段等）。这不只是用户体验的优化，它也是算法透明度义务的一种落地形式。

七、商业机密与算法透明度：一场没有完美解法的博弈

诚实地说，上面列举的这些工程原则，在实践中面临一个真实的张力：算法透明度与商业机密保护之间的矛盾。

一家平台的定价算法，是其核心竞争力之一。要求完全透明，意味着将商业策略完全暴露给竞争对手。这不是借口，而是一个真实的商业风险。

监管机构也意识到了这个矛盾。目前主流的破解思路有两种：

监管沙盒式的“受限披露”：平台不需要向公众公开算法细节，但需要向经过认证的第三方审计机构或监管部门开放审查权限。这保护了商业机密，同时确保了外部监督的可能性。欧盟在《数字市场法》中采用的就是类似路径。

“算法影响评估”制度：类似于环境影响评估，要求平台在上线重大定价算法变更前，主动出具一份评估报告，说明该算法对不同用户群的价格影响是否存在歧视性模式。这份报告不需要暴露算法本身，但需要证明算法的结果公平性。

这两种思路在中国的监管框架中都有雏形，但尚未系统化落地。可以预期的是，随着监管精细化程度的提高，类似机制会逐步出现在实操层面。

对于平台而言，与其等待监管机构制定强制标准，不如提前建立内部的”算法公平性审计”流程。这既是主动合规的姿态，也是在未来监管谈判中占据主动位置的筹码。

八、写给产品团队的最后一段话

这篇文章的主要读者，可能是产品经理、工程师，或者兼而有之的创业者。我想用一个具体的问题来结束：

你上一次认真看你们产品的定价代码是什么时候？

不是看需求文档里的定价策略描述，不是看数据报表里的 ARPU 曲线，而是真正看那些决定”某个用户在某个时刻看到什么价格”的代码逻辑——看它的输入变量，看它的判断分支，看它在不同用户画像条件下的输出分布。

大多数 PM 的回答可能是：从来没有，或者很久之前。

这本来不是问题。定价系统是工程团队的领域，PM 关注的是定价策略的商业目标，代码实现是实现手段。这个分工在监管真空时代是合理的。

但我们已经不在监管真空时代了。

2026年4月10日起，中国《互联网平台价格行为规则》正式施行。同一个月，马里兰州成为美国第一个明确立法禁止监控定价的州，而加州、科罗拉多、伊利诺伊等州的跟进立法也已在路上。

这些法律的核心罚则，落点都在”平台行为”而非”个人决策”。监管部门不会去追查是哪位工程师写的代码，他们追查的是这家平台的系统是否对消费者实施了不公平定价。而”系统”是什么？就是代码。

所以，问题不是你的法务团队有没有读过新法规，而是你的代码有没有准备好接受法律的阅读。

真正的合规，不是在用户协议末尾加一行免责声明，也不是在被查时临时组织应对小组。它是在系统设计时就把”这套逻辑站得住法庭阅读”当作一个工程约束条件——和性能、安全性、可扩展性一样，作为架构设计的基本标准之一。

这是一次思维方式的转变，也是这个时代要求产品团队必须完成的转变。

越早开始，越主动。