写代码的、卖软件的、点鼠标的:抢票软件全链条刑事责任

抢票软件产业链往往很短。一个人写程序，一个人负责推广和收款，另一批人用软件去抢火车票、演出票、医院号源。案发以后，开发者说自己只是接单，销售者说自己只是做代理，使用者说自己只是按了几下鼠标。

司法实践并不会只看每个人在链条上的称呼。刑法第二百八十五条第三款关心的是程序、工具是否专门用于侵入、非法控制计算机信息系统，以及提供者是否明知他人会用它实施侵入、非法控制行为。帮助信息网络犯罪活动罪则关心行为人是否明知他人利用信息网络实施犯罪，仍然提供技术、支付、推广或者其他帮助。

开发、销售、使用之间没有一条自动划线。责任要靠功能和证据一层一层推出来。

判断工具是否“专门用于”非法侵入或控制，不能只看软件名称，也不能只看软件能不能用于合法场景。

第一看功能设计。软件是否绕过验证码、批量维持登录状态、自动切换账号、规避限流、隐藏请求来源，是否把普通用户需要逐步完成的操作压缩成后台自动化流程。这些功能组合越集中于规避平台安全控制，专门性越强。

第二看目标系统。一个通用的浏览器自动化框架，可以用于测试、无障碍辅助和企业内部流程自动化。一个只针对某个票务或挂号系统开发、持续跟随该系统接口变化更新的工具，通常更能说明实际用途。

第三看销售方式。公开提供合规测试工具，和在群组里承诺“绕过验证”“稳定锁票”“批量出号”，主观明知完全不同。宣传话术、客户名单、售后记录和价格逻辑，常常比程序员的口头解释更能说明问题。

技术中立有其合理范围。自动化测试、网页可访问性辅助、官方开放接口调用、内部压测和正常的浏览器扩展，本身都不是犯罪。

但技术中立不能成为一张万能护身符。如果开发者明知客户要利用软件突破实名、限流和排队机制，仍然按客户要求定制绕过模块，持续更新接口并分享使用教程，再声称“软件也能做别的事”，说服力就很弱。

判断技术中立是否成立，可以问四个问题。软件是否有明确合法客户和合法场景，是否依赖未经授权的后台接口，是否把规避验证作为核心卖点，是否在发现客户用于犯罪后仍继续维护和分成。

真正的技术中立，是功能中立、场景中立和交易中立同时存在。只要其中一项明显偏向非法用途，抗辩就要进入细化证明阶段。

很多案件没有一封写着“我知道这是犯罪”的邮件。司法实践通常通过间接证据推定明知。

软件功能是第一组证据。若程序专门针对某平台，能够自动处理验证码、批量切换账号、绕过前端限制，开发者很难完全否认其用途。

销售话术是第二组证据。承诺“零人工”“百分之百成功”“不封号”“内部接口”的表述，可能说明行为人知道软件的非法竞争优势来自哪里。

价格和客户是第三组证据。普通自动化工具往往按授权数量或技术支持收费，面向黄牛群体的工具则可能按抢票数量、票价等级或成功订单抽成。

持续维护是第四组证据。平台规则变化后，开发者立即更新绕过方案，并根据客户反馈调整策略，这种行为比一次性出售程序更能证明持续明知。

间接推定必须形成闭环。单个功能异常、单句宣传话术或者单笔转账，都不足以替代整体证据。否则，任何提供自动化技术的人都可能因为客户的违法使用被倒推有罪。

开发者可能是产业链的源头，也可能只是受雇完成一段合法代码。关键在于他是否参与需求设计、非法功能开发和后续维护。

销售者通常最容易被忽略。代理商如果只做一般的软件分发，不知道具体用途，责任可能低于定制开发者。若销售者负责招揽黄牛、培训使用、处理封号、按订单抽成，他就不再是中性渠道。

使用者也不能一概而论。少量使用自动化工具抢一张公开可购的票，和组织大量账号长期占用票源，后果、获利和主观恶性都不同。沈阳等地公开通报中的分层处理，显示办案机关已经开始区分核心团伙、技术人员、普通使用者和仅受行政处罚人员。

分层处理符合宽严相济，但必须有清晰标准。不能因为同案人员都在一个群里，就把开发、代理和普通买票人按照同一罪名、同一数额处理。

帮助信息网络犯罪活动罪常见于支付结算、推广引流、账号提供、服务器租赁和技术支持等环节。票务黑灰产里，如果行为人不直接开发或使用抢票工具，却明知对方利用网络实施犯罪，仍为其批量提供实名账号、代收款、群组推广和技术维护，就可能被评价为帮助行为。

帮信罪的风险在于“帮助”概念容易被拉得过宽。提供云服务器、支付接口和短信服务，本来都有合法用途。办案必须证明行为人对上游犯罪具有明知，且帮助行为与犯罪结果存在实质联系。只要收过一次服务费、转发过一次链接，不应自动进入刑事范围。

对帮信罪而言，异常交易数量、客户集中度、价格远高于市场、反复规避实名审核和收到风险提示后仍继续经营，才是判断明知的重要证据。

太原“黑米”案被政府网警栏目转引新华社报道为制售抢购软件入刑的典型案例。公开材料显示，研发者任某、张某各被判有期徒刑三年、缓刑四年并处罚金三万元，销售者陈某被判有期徒刑二年、缓刑三年并处罚金一万元。报道还提到，软件具有批量请求、模拟登录下单和突破网站安全保护等功能。这个案件的价值，不只在于软件罪名本身，还在于它提醒我们，技术链条必须拆开评价。

开发者掌握核心代码和功能控制，销售者掌握客户和现金流，实际使用者掌握订单和票源。三者互相配合时，可以形成共同犯罪；配合程度有限时，也应当分别认定作用大小。

武汉江岸、镇江和北京等地公开案件还呈现出一个变化。抢票软件已经从单一火车票场景扩展到演唱会、球鞋、景区预约和医疗号源。场景越多，软件越像通用抢购工具，专门性认定越需要回到代码功能和交易记录本身。

我赞成功能主义判断。软件是不是“专门用于”非法抢票，首先看它实际设计了什么，而不是开发者给它起了什么名字。一个软件即使声称能用于合法用途，只要核心功能就是绕过系统控制，就不能因为存在抽象的合法可能性而出罪。

但功能主义必须配合严格的明知证明。开发者做了通用自动化框架，客户后来擅自用于抢票，不能把客户的用途自动归责给开发者。正规企业的官方 API 调用、内部压力测试和无障碍辅助，也不应因为技术形式相似就被刑事化。

我反对两种极端。第一种是“写代码就有罪”，把技术职业本身当成风险来源。第二种是“技术中立万能”，只要在合同里写一句客户自负责任，就完全不看真实用途。刑法应该惩罚的是明知非法用途仍提供关键能力的人，而不是惩罚抽象的技术能力。

第一组是需求证据。保留客户需求、功能清单和合规用途，说明软件最初要解决什么问题。

第二组是代码证据。区分通用模块和针对特定系统的规避模块，说明哪些功能由谁提出、由谁修改。

第三组是交易证据。收款对象、宣传话术、售后记录和分成模式，能说明销售者和开发者的主观状态。

第四组是风险处置证据。收到平台投诉、客户违法使用或警方提示后，是否停止服务、封禁账号、退还费用。

这四组证据能把“我只是写代码”的口头抗辩变成可验证的事实，也能防止技术人员因为客户的单方违法行为被无差别追责。

本文对太原“黑米”案、武汉江岸案件、镇江演出票案件、沈阳案件和北京相关案件的事实，依据公开报道和办案机关通报整理。不同来源对罪名、人数、金额和刑期的表述可能存在差异，正式使用时应以生效裁判文书和鉴定材料为准。

如果你觉得这篇文章有收获，欢迎点赞、在看、转发。下一篇把火车票、演出票、医疗号源和景区预约放在一起，做最后一轮场景扫描。