2026年7月25日那份处罚通报出来的当天下午，一个做搜索排序的朋友来问我：我们组去年改过一版商家权重规则，产品说给「独家合作」的商家加权，非独家的往后压两位，这事儿有没有问题？
通报里，市场监管部门认定一家头部在线旅游平台滥用市场支配地位，对商家实施「二选一」并要求「全网最低价」，罚没51.79亿元。
金额上了热搜，可技术人更该琢磨另一层：「二选一」不是会议室里的口号，它要落进代码才生效。
落到哪些地方？搜索降权规则里的一段权重系数；流量分配策略中对「多平台上架商家」单独分桶；比价爬取任务的调度频率与目标站点清单；下单链路上的价格锁定校验；还有商家后台那个默认勾选、取消时弹出「将影响店铺曝光」提示的选项。
这些不是抽象决策，它们有提交记录、配置版本、审批人、灰度时间点。执法机关取证，取的就是这些。
一、边界先说清楚
反垄断法禁止具有市场支配地位的经营者没有正当理由限定交易相对人只能与其交易。二选一、强制低价承诺落在这一条上，主要是行政责任。
那为什么还要谈平台经济反垄断刑事风险？两处会交叉。一处是执行手段，为了做比价和价格锁定去抓取另一家平台需要登录才能看到的后台数据，性质就转成了数据获取的边界问题。另一处是调查阶段的动作，接到通知后删除策略配置、清理日志、补签审批单，性质会立刻变化。把技术人卷进去的，往往不是那条排序规则，而是后面这一步。
二、需求里带排他条款，技术侧按这五步走
- 把需求原文和决策记录原样留住。
产品文档里写的是「对同时在其他平台上架的商家，搜索结果下沉两位」，就照这句留档，别在转述时改写成「搜索质量优化」。需求系统的版本历史、评审前的原始附件、口头追加要求的书面确认，都挂在同一个需求编号下。把它美化一遍，等于替别人把痕迹擦掉了。
- 评审纪要里写明实现方式和影响范围。
别只写「按需求实现」。写清楚改的是哪个策略模块、覆盖多少家商家、预计流量变化区间、能不能回滚。有人担心写细了留把柄，实际相反：纪要越具体，越能说明技术侧按既定口径执行并如实上报过影响面。
- 商家流量分配规则做成可回溯配置，不要硬编码。
权重系数、分桶条件、白名单商家 ID 放进配置中心，带版本号、生效时间、操作人。硬编码进服务代码，一次发版之后连自己什么时候改的都查不清。可回溯配置对内能回滚，对外能说明某条规则在某个时段是什么状态、由谁调整。这类规则单独开一组命名空间，权限收窄。
- 留下策略变更的审批链和灰度记录。
一条影响商家流量的规则上线，审批链上至少要有产品、技术负责人、业务侧三方确认。灰度阶段的分流比例、观察指标、每次扩量的时间点，都留在发布系统里。用即时通讯里一句「上吧」当审批，事后是没有效力的痕迹。灰度记录还能说清规则实际覆盖到什么程度，是全量商家还是某个类目试了三天。
- 判断出规则实质是排他时，书面异议往上走。
如果这条规则的区分变量只有一个，就是商家有没有在别处经营，跟服务质量、履约率、评分这些指标无关，它的性质就要重新掂量。这时候别在群里发一句「这样合适吗」然后照做。写一份简短的书面异议，讲清楚识别到的问题、依据、可替代的实现方案，发给直接负责人，抄送合规或法务岗位。有了这份记录，你就从执行者变成提出过异议的执行者。这两者在责任划分上不是一回事。
三、哪些日志和配置必须留，留多久
第一类，策略配置的版本快照。每次权重规则变更前后存完整快照，不要只存差异行。
第二类，审批与发布记录。审批人、时间戳、灰度比例、回滚操作，一样都不能少。
第三类，商家侧的通知记录。后台勾选项的文案版本、上线时间、商家取消勾选后系统的实际反应。
第四类，抓取任务的调度日志。抓的是谁、取了哪些字段、频率多高、有没有触碰对方的访问控制。
保留时长，行政调查追溯通常按三年考虑，涉及数据获取行为的可能更长。做法是策略配置和审批记录留满五年，抓取日志留三年，全部放进只追加、不能原地改写的存储。能被随手删掉的日志，在证据意义上跟没有日志差不多。日志本身的访问记录也要留一份。
四、坐过审判席之后想说的
在审判岗位上坐了三十七年，看卷宗我养成一个习惯，先翻技术材料，再看笔录。技术材料不带情绪，一条规则几点上线、谁点的发布、灰度到百分之多少，白纸黑字摆在那儿。写代码的人常觉得自己离决策很远，可当决策只靠口头传达、只有代码留下痕迹时，痕迹上署着谁的名字，谁就得先出来解释。
作者韩宝玉，37年法院审判经历，曾任某省直属法院高级法官，现执业于北京百环律所深圳办案团队。
本文仅为经验分享，不作为具体个案的判断依据。
