ARTICLE · 1242926
抢单软件刑事案件的指控逻辑与辩护路径
计算机犯罪辩护实务
抢单软件刑事案件的指控逻辑与辩护路径
从程序怎样运行到证据怎样闭合
一款软件被叫作抢单神器，落进刑事卷宗以后，常常只剩下几个很粗的词。
平台看到高价订单被迅速拿走。侦查机关查到软件、卡密和收款记录。技术报告里又出现了侵入、绕过、控制一类表述。几样材料摆在一起，很容易形成一种直觉。软件能抢单，开发者也收了钱，罪名似乎已经清楚了。
我把近两年的公开案例、现行刑法和司法解释重新对了一遍。这类案件最需要补上的，恰好是直觉省略掉的那一段。程序在哪台设备上运行，它越过了哪一道权限，实际拿回了什么数据，都要由证据说清楚。行为人何时参与，又知道了多少，决定责任最终落到谁身上。
同样是在手机上多出一个订单，后台走过的路可以差得很远。有的软件只在用户已经打开的页面上读图和点击。有的软件会计算签名参数，绕过平台校验，再去抓取普通账号原本看不到的订单。业务结果看着相近，刑法评价却不能把中间过程略过去。
控辩双方的交锋，往往就落在这段被省略的过程里。
01上海闵行案把版本差异摆到了桌面上
2026年4月，上海市检察院公开了一起顺风车抢单软件案件。这个案件很适合用来理解抢单软件的法律边界，因为同一名开发者先后做过两个技术原理明显不同的版本。
早期版本使用手机无障碍功能模拟人工点击。司机仍通过自己的账号进入平台，软件替他刷新页面、识别订单并点击。检察机关审查后认为，这个版本破坏了公平接单秩序，却不足以据此认定计算机犯罪。
后来的版本发生了实质变化。开发者接入破解算法，绕过平台权限验证，未经授权抓取顺风车平台的全量订单，再按司机设定的价格和行程条件筛选。软件还可以向司机发送抢单邀请。法院最终以非法获取计算机信息系统数据罪对开发者和分销者定罪，两人均被判处三年有期徒刑并适用缓刑。
案中还有一个很容易被忽略的细节。配套登录软件传输的是司机本人登录时在本机产生的令牌。办案机关没有因为它叫登录令牌，就直接推定为非法取得身份凭证。他们继续核对令牌的来源，再审查软件怎样使用它。单凭传输本人令牌这一点，不足以证明未经授权。
这起案件给辩护留下了一个很实在的提醒。审查对象要落到具体版本。早期版本做过什么，后期增加了什么功能，某个行为人又在哪个时间点加入或退出，必须逐一对应。把后期版本的越权功能倒推到早期，再把整条链上的人一并装进去，证据上会出现很大的空档。
版本不只是软件包装上的一个数字。它可能直接改变案件的法律评价。
02抢单软件先按运行路径分开看
在正常页面里替人操作
最常见的是无障碍点击、OCR识别和坐标模拟。程序读取用户已经看到的订单页面，根据价格或距离作判断，随后代替手指点击。
这类工具可能违反平台协议，也会挤压其他司机或骑手的接单机会。最高人民法院2026年公布的反不正当竞争典型案例里，一家企业销售点滑器，设备能够自动刷新并快速点击。它没有直接拦截、修改平台数据和程序，法院仍认定这种经营行为妨碍平台正常运行，判赔300万元。
这个民事案例说明，页面内自动化也可能承担很重的法律责任。它同时提醒办案人员，民事上的不正当竞争结论不能直接替代刑法构成要件。平台规则被规避，和安全保护措施被突破，仍是两件需要分别证明的事。
卷宗如果只能证明软件读图、刷新和点击，下一步应当查清账户原来能看到哪些订单。程序有没有额外访问受限数据，平台端有没有出现权限扩张，也要从日志和网络请求里找答案。
下面放几段代码，把这些差别摊开来看。代码只处理本地演示页和虚构数据，不连接任何真实平台。里面的域名、令牌、密钥和订单标识都不能使用。
它们能说明某项功能在技术上怎样实现，单靠这些代码仍无法证明程序在案发时实际运行，更无法替代服务器日志和授权范围的审查。
技术示意一 本地演示页里的自动点击
TYPESCRIPT
import { test, expect } from "@playwright/test";
test("only handle visible demo orders", async ({ page }) => {
await page.goto("http://127.0.0.1:4173/demo-orders");
const cards = page.locator("[data-demo-order]");
for (let i = 0; i < await cards.count(); i += 1) {
const card = cards.nth(i);
const fee = Number(await card.getAttribute("data-fee"));
const button = card.getByRole("button", { name: "accept" });
if (fee >= 50 && await button.isEnabled()) {
await button.click();
await expect(card).toHaveAttribute("data-status", "accepted");
break;
这段脚本只打开本机演示页，读取页面已经展示的卡片，再点击页面原有按钮。它没有主动访问后台接口，也没有扩大当前账号的可见范围。办案时若只检出这一层代码，结论应先停在页面操作被自动化，随后再查请求和服务器响应。
跳过页面直接向接口发请求
另一类程序不等页面慢慢刷新。它分析客户端与服务器之间的通信方式，直接发出获取订单或提交接单的请求。
接口直调本身只能说明交互方式变了。正常客户端也要调用接口。判断是否越权，要把正常请求和涉案请求放在一起比较。账户原本能看什么，涉案程序又拿回了什么，这两个范围如果完全相同，控方还需要说明非法性究竟出现在哪一步。
风险较高的情形通常会留下更具体的技术痕迹。程序可能伪造签名参数，或者避开身份验证。请求频率也可能远超正常客户端。服务器返回的数据一旦越过账号原有权限，案件便不再只是自动化效率问题。
上海静安区2026年办理的批量代抢火车票案又说明了另一面。涉案软件没有攻破平台底层系统，它通过多线程密集提交申请，批量获取购票系统处理、传输中的数据。被告人代抢200余张车票，违法所得2万余元，法院以非法获取计算机信息系统数据罪判处其有期徒刑一年六个月并适用缓刑。
由此可见，服务器没有被攻破，只能排除一部分技术路径。刑法第二百八十五条第二款还规定了采用其他技术手段非法获取数据的情形。辩护必须继续查授权范围和数据内容，停在有没有传统入侵上，论证还没有走完。
技术示意二 找出两条请求链的第一处差异
TYPESCRIPT
type AuditRow = readonly [stage: string, result: string];
const normalFlow: readonly AuditRow[] = [
["ui_event", "ok"],
["client_request", "sent"],
["authorization", "allow"],
["response_scope", "visible_to_account"],
];
const observedFlow: readonly AuditRow[] = [
["client_request", "sent"],
["authorization", "deny"],
];
function firstDifference(left: readonly AuditRow[],
right: readonly AuditRow[]) {
const length = Math.max(left.length, right.length);
for (let i = 0; i < length; i += 1) {
if (JSON.stringify(left[i]) !== JSON.stringify(right[i])) {
return { index: i, normal: left[i] ?? null,
observed: right[i] ?? null };
return null;
console.log(firstDifference(normalFlow, observedFlow));这段代码不生成网络请求，它只比对审计节点。正常链路从页面动作走到客户端请求，服务端完成授权后才返回账户可见的数据。观察链路在授权处得到 `deny`，能够说明这次请求没有通过。若控方主张程序曾成功越权，还应找到同一个请求编号下的放行记录和返回范围，并把受限数据落到具体字段。
在手机端改变程序运行结果
Hook、注入和虚拟定位经常出现在这类案件里。它们可以拦截本地函数，改变设备信息，或者让客户端上报另一个位置。
这里要分清手机端和平台端。用户在自己手机上修改某个函数返回值，不能直接证明他已经取得平台服务器的控制权。控方需要说明本地修改怎样影响认证。服务器若因此接受了无权请求，还要用返回数据证明受限内容已经开放。
虚拟坐标也要按这条路审查。客户端发送错误位置，可能导致订单匹配发生变化。定罪所需的技术事实仍要落实到具体罪名。若指控非法获取数据，就要查它多拿了什么。若指控非法控制，就要查行为人取得了怎样的系统支配能力。涉及破坏计算机信息系统罪时，还需要证明系统功能或数据受到法定意义上的破坏，并达到严重后果。
修改发生在本机，影响却可能到达平台服务器。完整证据应当把这条因果过程接起来。
技术示意三 本地函数变了 服务端权限没有跟着变
TYPESCRIPT
type Order = Readonly<{ id: string; distanceKm: number }>;
class DemoClient {
constructor(
private readonly readDistance =
(order: Order) => order.distanceKm,
render(order: Order) {
return `${this.readDistance(order)} km`
const order = { id: "DEMO-ORDER-001", distanceKm: 8.4 }
const changedClient = new DemoClient(() => 1.2);
const serverAcl = new Map([
["DEMO-ORDER-001", new Set(["account-A"])
function acceptOnServer(accountId: string, orderId: string)
const allowed = serverAcl.get(orderId)?.has(accountId) ?? false;
return { status: allowed ? 200 : 403
console.log(changedClient.render(order);
console.log(acceptOnServer("account-B", order.id));这里用测试替身模拟本地函数返回值被改成 `1.2`。客户端显示随之变化，服务端仍按自己的授权记录判断，演示账号得到 `403`。鉴定意见若只证明本地函数被替换，结论应当落在客户端变化。平台服务器是否受到控制，还要看发出的请求和服务器状态。
绕过认证并集中管理账号
部分抢单系统会部署在云端。运营者集中管理司机账号，按客户设定的条件筛单，再自动发出请求。云端模式说明程序部署在哪里，案件定性仍取决于认证和权限事实。
程序若复用合法登录状态，下一步要看使用范围有没有得到账号持有人的同意。程序若破解平台签名、伪造身份参数，越权事实会清楚得多。多账号集中运行还会影响涉案人次、请求规模和共同犯罪的判断，因此服务器日志、卡密后台和客户记录必须互相对应。
技术名称可以很复杂，办案问题其实很朴素。程序从哪里进入，又在哪一道校验前后改变了权限。它实际拿回了什么，应当另用请求和返回数据回答。
技术示意四 服务端验签到底检查了什么
TYPESCRIPT
import { createHash, verify } from "node:crypto";
type Envelope = Readonly<{
body: Buffer;
timestampMs: number;
nonce: string;
scopes: readonly string[];
signatureB64: string;
}>;
function verifyEnvelope(input: Envelope,
publicKey: string,
seenNonces: Set<string>) {
const fresh = Math.abs(Date.now() - input.timestampMs) < 30_000;
const unused = !seenNonces.has(input.nonce);
const authorized = input.scopes.includes("orders:visible");
const bodyDigest = createHash("sha256")
.update(input.body).digest("hex");
const message = Buffer.from(
`${input.timestampMs}\n${input.nonce}\n${bodyDigest}`,
);
const integrity = verify(
"sha256", message, publicKey,
Buffer.from(input.signatureB64, "base64"),
);
if (fresh && unused && integrity) seenNonces.add(input.nonce);
return { accepted: fresh && unused && integrity && authorized,
fresh, unused, integrity, authorized };
}这段代码只保留验证端，没有签名生成和私钥读取。时间窗口用来挡过期请求，随机数用来识别重复提交，正文摘要进入完整性校验。`scopes` 又单独处理访问范围。签名通过只能说明来源和内容校验成立，账户是否有权看到某批订单，还要继续经过访问控制。鉴定报告若笼统写成绕过风控，技术事实仍然不够具体。
03三类常见指控各自需要哪些事实
抢单软件案件通常围绕刑法第二百八十五条第二款、第三款展开。有时卷宗还会讨论第二百八十六条规定的破坏计算机信息系统罪。几个罪名保护的对象和要求不同，不能用一句影响平台正常运营全部包住。
第二百八十五条第二款还把违反国家规定写进入罪前提。刑法第九十六条对国家规定的范围有专门限定，平台用户协议和司机规则不能单独替代这个要件。它们可以帮助说明账户原有权限，也可以用来判断行为人是否明知。现行《网络安全法》第二十九条禁止非法侵入或者干扰他人网络，窃取网络数据也在禁止之列。《网络数据安全管理条例》第十八条又要求，使用自动化工具访问、收集网络数据时评估对网络服务的影响，不得非法侵入或者干扰网络服务。具体到一份起诉书，控方仍应说清行为违反了哪一项国家规定，不能把违反平台规则直接写成违反国家规定。
提供程序工具有两条指控路径
刑法第二百八十五条第三款规定了两种提供行为。
一条路径针对专门用于侵入、非法控制计算机信息系统的程序、工具。2011年两高司法解释要求关注程序是否避开或突破安全保护措施，并在未经授权或超越授权的状态下获取数据、实施控制。这里审查的是程序本身的功能设计。
另一条路径不要求程序只能用于违法活动。提供者明知他人正在实施侵入、非法控制计算机信息系统的违法犯罪行为，仍向其提供程序、工具，也可能进入刑事评价。此时，客户需求、功能改动和售后沟通会变得很重要。
最高人民法院2024年发布的丁某案给出了很清楚的判断方法。涉案爬虫软件通过特定服务计算并取得平台签名参数，避开服务器签名校验，随后获取未授权人员不能访问的数据。法院把突破安全保护措施和取得访问受限数据结合起来，认定该软件属于专门用于侵入计算机信息系统的程序。
这个案例的价值在于，它没有停在爬虫、获客神器或侵入性几个标签上。裁判理由写清了平台采用什么校验，软件怎样避开校验，受限数据又如何被取回。抢单软件案件也应当达到同样的证明精度。
非法获取数据不要求系统先瘫痪
订单数据属于计算机信息系统中处理、传输的数据，这一点通常争议不大。案件的主要争议往往集中在获取行为有没有越过授权。
司机正常登录后，平台主动展示给他的订单，与程序绕过校验后抓回的全量订单，权限基础不同。屏幕上的价格和距离已向该账户开放，后台尚未展示的订单列表则未必如此。控方需要把具体字段和访问控制策略拿出来，辩方也应围绕这个范围提出意见。
有些案件虽然没有传统意义上的漏洞利用，仍可能被认定为采用其他技术手段非法获取数据。上海静安火车票案提供了现实样本。这个样本不宜被扩大成凡是高频访问都构罪。审查仍需回到国家规定和账户权限，并查明程序实际取得的数据。情节标准是否达到，要用数额和其他证据单独说明。
自动执行请求不当然构成非法控制
非法控制的核心在于控制能力。程序替司机点击接单，服务器仍按账号原有权限和业务规则处理请求，这种情形与取得系统支配权存在距离。
如果程序绕过权限，让服务器执行正常账户无权触发的功能，评价会发生变化。有无管理员账号只能说明一部分事实。控方还需证明行为人实际支配或干预了什么系统功能，以及这种能力怎样超出授权。
四川天全一起网络抢购软件案件提供了很有意思的审查过程。公安机关先后以破坏计算机信息系统罪、非法控制计算机信息系统罪移送。检察机关经补充侦查认为，证据不能证明系统功能失效，也不足以证明平台失去对购买行为的正常管理，最后按照非法获取计算机信息系统数据罪处理。这个过程说明，抢购成功和系统受控之间仍有一段事实需要证明。
04控方通常怎样把案件做实
刑事案件不会只靠软件名称定案。平台异常通常是起点，程序检验和电子数据用来还原运行过程。案件能不能落到某个人身上，还要看参与记录与情节门槛。
平台先提供异常线索
平台可能发现接单速度远超人工操作，或者同一账号短时间发出大量请求。其他司机的投诉也可能成为线索。平台随后提交服务器日志、账户权限说明和安全措施材料，用来解释异常怎样发生。
这些材料很重要，仍需接受普通证据审查。平台既掌握后台数据，也维护自己的经营利益。单方情况说明能够说明报案缘由，不能独自完成全部技术证明。
律师拿到平台材料后，可以先看时间范围是否完整。异常请求前后发生了什么，服务器怎样响应，权限校验在哪一步通过或失败，都比截取几行异常日志更有价值。缺少正常账号的对照样本，很多异常也很难准确解释。
侦查机关固定软件和运行环境
手机安装包、电脑程序和云端后台可能分别保存一部分证据。侦查机关还会提取源代码、数据库和卡密记录，必要时开展检验或鉴定。
这里最容易出现版本问题。案发时运行的是哪个文件，送检样本来自哪里，哈希值能否对应，决定鉴定结论能够证明哪一段事实。软件持续更新时，文件名相同也可能功能不同。
动态测试同样要保留条件。报告应先写明测试账号的权限，再说明连接对象。设备环境若经过特殊设置，也要完整记录。一个在特殊测试环境里出现的结果，不能自然覆盖历史版本和其他用户。
司法解释第十条还规定，对程序、工具属性难以确定时，应当依法检验，司法机关再结合案件具体情况认定。技术人员可以说明程序怎样运行。罪名是否成立，仍要由司法机关根据全案证据判断。
电子数据的来源也要经得住回查。2016年电子数据规定要求审查收集程序与数据完整性。扣押时有没有封存，提取后是否计算校验值，动态运行过程能否重现，都会影响证据分量。检材来源说不清时，一份写得很肯定的报告也可能失去基础。
资金和通信记录把责任落到个人
程序功能查清以后，办案机关会沿卡密和收款记录追查人员关系，聊天内容则用于核对需求变化。开发者写过的代码要有版本对应。代理商和实际使用者做过什么，也不能只按群名片或职位称呼认定。
聊天记录的上下文尤其重要。客户最初可能只要求提高点击速度，后来又提出绕过验证。开发者是否参与后一次改动，会改变主观认识和客观行为。只截取一句能过风控，既可能说明明知，也可能因为缺少前后文而产生误读。
资金流水负责证明规模，但它不能替代功能证明。软件卖到五千元，不会因此自动变成专门侵入工具。程序属性已经成立以后，违法所得和提供人次才进入情节判断。
开发、销售和使用常常不在一地。网络犯罪管辖确实存在多个连接点，服务器或者被侵害系统所在地都可能与案件有关。多地有权时，相关规定仍要求结合最初受理和主要犯罪地处理。平台面向全国经营，不能由此推导出任何地方都当然有管辖权。
05辩护思维
这类案件的无罪或罪轻空间，很少来自一句技术中立。更有效的做法，是把控方结论拆回可以验证的技术动作，再逐项放进刑法要件。
软件究竟作用于哪个系统
一部手机里可能同时出现操作系统、平台客户端和抢单软件。网络另一端还有抢单服务端与平台业务服务器。它们由不同主体控制，权限来源也不一样。
鉴定报告如果只证明本地函数返回值被改，下一步应当说明这项修改怎样到达平台端。平台服务器是否因此开放了受限数据，或者执行了无权操作，要有请求、响应和日志支持。
把手机端变化直接写成控制平台服务器，中间缺了关键事实。只强调服务器没有被直接登录，也会漏掉其他技术手段非法取数的可能。辩护意见应当把两个方向都处理完。
程序越过了哪一道权限
安全保护措施要具体到可以观察。登录参数校验和请求签名处理认证问题，访问控制决定账户能够看到哪些数据。平台泛称有风控，说明不了涉案软件突破了什么。
审查时可以找一组正常样本。普通账户发出怎样的请求，服务器返回哪些字段。再看涉案程序携带的参数和返回结果，差异便会清楚许多。
上海闵行案对本人登录令牌的判断很有启发。凭证来自合法账户，只能说明进入系统的起点。后续有没有扩大用途，还得继续看。反过来，凭证保存在用户本机，也不能被自动描述成窃取而来的身份信息。
权限分析需要一步一步走，不能靠名词替代。
鉴定版本能否代表指控期间
假设一款软件第一版只做页面点击，第三版才加入签名破解。开发者在第二版发布前已经退出，后续版本却沿用同一个名称。鉴定第三版，只能说明第三版具有什么功能。早期参与者是否提供过这项功能，需要版本记录和交付证据补上。
现实中的版本变化未必写得这样整齐。更新可能发生在服务端，客户端看不出版本号。办案人员还要查后台部署时间、代码提交和客户反馈。无法复原全部代码时，聊天记录与日志可以补强，但不能把推测写成已经检验的技术事实。
鉴定意见值得重点核对六个地方。
技术示意五 给检材计算哈希并关联两端日志
PYTHON
from hashlib import sha256
from pathlib import Path
import json
def file_hash(path: Path) -> str:
digest = sha256()
with path.open("rb") as source:
for block in iter(lambda: source.read(1024 * 1024), b""):
digest.update(block)
return digest.hexdigest()
def read_jsonl(path: Path) -> list[dict]:
with path.open("r", encoding="utf-8") as source:
return [json.loads(line) for line in source if line.strip()]
client_path = Path("readonly-copy/demo-client.jsonl")
server_path = Path("readonly-copy/demo-server.jsonl")
client_rows = read_jsonl(client_path)
server_by_id = {
row["request_id"]: row for row in read_jsonl(server_path)
}
pairs = []
for row in client_rows:
peer = server_by_id.get(row.get("request_id"))
if peer and abs(row["epoch_ms"] - peer["epoch_ms"]) <= 3000:
pairs.append({
"request_id": row["request_id"],
"server_decision": peer.get("decision"),
})
print({
"client_sha256": file_hash(client_path),
"server_sha256": file_hash(server_path),
"matched_requests": pairs,
})哈希值可以检查送检副本在计算以后有没有变化，请求编号和时间差则帮助办案人员对应客户端日志与服务器日志。两项结果都有边界。同一个哈希值说明两份内容相同，补不上缺失的提取笔录。日志能够对应到同一次请求，也不能单独回答当时是谁操作了账号。设备持有人和账号使用者仍需另用证据确认。
每个人知道什么又参与了什么
程序员懂技术，只能说明他有实现功能的能力。主观明知还要从需求变化和实际参与中证明。
先看最初委托内容。普通自动化需求后来若变成破解签名，谁提出改动，谁写入代码，会留下相应记录。软件被平台封禁以后，售后人员怎样处理，也可能反映其对规避措施的认识。
开发者、分销者和代抢者可能形成共同犯罪，也可能分别实施不同犯罪。常州武进案中，外挂绕过登录参数校验并调取全部订单。五名研发、分销人员被以提供侵入、非法控制计算机信息系统程序、工具罪追诉。两名设立工作室替司机抓单的人被以非法获取计算机信息系统数据、非法控制计算机信息系统罪中的非法获取数据行为追诉。法院对七人均判处三年有期徒刑并适用缓刑。
同一条商业链没有替所有人生成同一份责任。开发者是否控制核心功能，代理商有没有参与需求设计，使用者是否亲自抓取数据，都要分别查。主犯和从犯也应根据实际作用判断，写代码或直接收服务费都只是其中一项事实。
06卡密流水和平台损失要分开算
2011年两高司法解释分别规定了提供工具和直接实施行为的情节门槛。几套数字放在一起很容易串线，分开看更稳妥。
达到上述数量或数额标准五倍以上，通常进入情节特别严重。司法解释使用的是人次，卡密张数、续费次数和账号数量都不能机械替代。现有规范也没有给出一张卡等于一人次的统一换算方式。
直接实施非法获取数据或非法控制行为，适用另一套标准。
普通订单数据没有一条多少单即入罪的数量线。订单条数可以反映规模，却不能直接换算成司法解释列明的身份认证信息组数。控方选择违法所得或损失作为情节依据时，就应当按相应口径举证。
二十张卡密可能对应二十个独立客户，也可能包含同一客户续费。代理调货还会让一张卡密在多层流水里重复出现。试用卡没有实际交付给违法使用者时，能否计入提供人次，也要看证据。
较稳妥的做法，是从每一张卡密往回查。后台记录可以先确认生成和激活时间，再与账号、设备对应。付款记录能否指向实际接受者，还要另行核对。无法完成这些对应时，数量结论的准确性就需要重新评估。
流水、销售额和违法所得也要分开。账户里可能混有其他业务收入，代理之间的转账不能层层累加。退款已经实际发生，计算时应当留下记录。具体被告人加入以前的款项，不能只因进入同一个收款账户就全部算到他头上。
平台损失另有一套证明问题。风控升级费用、人工处置成本和经营损失，是否由涉案程序直接造成，需要原始凭证和计算方法。司法解释所称经济损失，包括犯罪行为给用户直接造成的损失，也包括恢复数据、功能所支出的必要费用。平台提供一个总额，仍需说明每一部分怎样产生。
数额越大，计算过程越要经得住拆分。
07取保
抢单软件案件里，当事人没有前科、有固定住所，当然可以写进取保申请。办案机关常会追问共同犯罪调查是否结束，也会顾虑电子数据仍能被远程改变。
链条上的人员可能分散在多地。有人尚未到案，聊天记录和服务器数据也没有固定完毕。此时只写家属愿意担保，很难回应串供或毁证风险。
更有用的材料会落到具体状态。涉案设备是否已经扣押，云端数据有没有完成提取，当事人还掌不掌握后台权限。经营已经停止，服务器控制权也已经移交，可以用相应记录证明。口头承诺不会删除数据，分量通常有限。
技术和数额争议也会影响羁押必要性判断。若早期版本仅有页面自动化功能，可以提交能够复现该版本的技术说明。侦查机关按照全部销售流水初步估算规模时，辩护人应先扣除退款，再把客户续费与代理间的重复转账分开。争议写得越具体，办案人员越容易评估案件可能的刑罚风险。
刑事诉讼法第六十七条规定取保候审的适用情形，第八十一条围绕逮捕所需的社会危险性展开审查。案件存在犯罪嫌疑，不会自动排除非羁押措施。辩护意见既要处理构成要件，也要说明现实风险怎样被控制。
08检察院阶段
一份普通法律意见书很难装下这类案件。文字写得再完整，如果没有版本、请求和人员行为作支撑，办案人员仍然无法判断争议落在哪儿。
我会把材料做成几组可以互相对照的文件。
这些表格不替代法律论证。它们把法律意见中的每个判断送回证据，让办案人员能够核对。
对明显缺少犯罪构成要件的案件，应当把不起诉意见建立在具体技术事实和证据缺口上。关键事实尚未查清，可以围绕版本、权限和日志申请补充调查，必要时请有专门知识的人协助审查。
有罪证据已经较充分，辩护方向也要及时调整。不同人员的作用大小需要分开，违法所得要重新计算。退赃、认罪认罚和其他量刑情节，可以在事实基础查清以后继续推进。
有效辩护会承认卷宗已经坐实的部分，再把尚未坐实的环节讲到足以影响定性、数额或责任。全部否认通常无法增加说服力。
09抢单只是业务结果
一名司机手动点击接单，平台按规则返回结果。软件代替他点击，页面上出现的还是一张订单。若程序进一步破解签名并抓取全量数据，手机上看到的也可能只是同一张订单。
刑法需要评价的是订单出现之前的技术行为。
控方要证明程序怎样越过授权，证据怎样把运行过程还原出来。辩方要检查这个过程有没有被平台违规评价、概括性鉴定结论或一笔总流水代替。每名行为人的参与时间和认识范围，也要单独落在证据上。
抢单软件当然可能构成犯罪。公开案件已经表明，破解校验、抓取受限数据并达到情节标准，刑事风险很高。页面自动化、物理点击和本机环境修改，则需要继续审查它们怎样触及具体的计算机信息系统和法定权益。
罪责最终落在已经查明的行为上。程序运行和权限变化先要对得上证据，再把每个人的实际参与放回时间线，案件的评价才有落脚处。
10主要依据
中华人民共和国刑法 两高关于办理危害计算机信息系统安全刑事案件应用法律若干问题的解释 最高人民法院丁某提供侵入计算机信息系统程序案 上海检察机关顺风车抢单软件案 江苏检察机关常州武进网约车抢单外挂案 最高人民检察院上海静安批量代抢火车票案 最高人民法院2026年反不正当竞争典型案例 三部门关于办理刑事案件收集提取和审查判断电子数据若干问题的规定 现行中华人民共和国网络安全法 网络数据安全管理条例 关于办理信息网络犯罪案件适用刑事诉讼程序若干问题的意见
本文仅作一般法律实务交流
