技术类刑案辩护策略（二）：从技术行为到主观认知（上）明知的标准与推定

本文作者：武俊吉律师

今天这篇文章来源于曾经的两个当事人，两个 CTO，两个案子，同一个罪名：侵犯著作权罪。

第一个在一家小公司团队三十来人，他每天审代码、定架构细节。公司开发了一款软件，里面用了一段别人享有著作权的代码模块，被立案侦查。第二个是大公司 CTO，手下几百号人。他的工作是定技术方向、管预算、跟投资人开会，公司的一款软件里同样用了侵权代码模块，也被立案侦查。

案子后来到了检察院。从第一印象来看第二个当事人更危险，因为他公司大、软件销售额高、他工资也高得多，按常理想应该刑责应该更重，但结果反过来了。最终第一个 CTO 被检察院提起公诉且量刑不低，第二个经过两次退回补充侦查后作存疑不起诉处理。最后其实差别不在公司大小和工资高低，差别只在简单的一点：第一个 CTO 审过那段代码，第二个压根没见过那段代码。

同一个罪名，同一个头衔。一个上了被告席，一个没有。决定最终走向的，不是别人怎么定义他的岗位，而是他到底碰没碰过那段代码，也就是他的主观认识。

主观明知在技术类刑案里，不是一道法律推定题，是一道事实还原题。

一、为什么主观明知是第一道闸门

技术类刑事案件的门槛，和普通刑事案件有个根本区别。普通刑事案件例如故意杀人、抢劫、盗窃，争议焦点不在知与不知，在是不是他干的。技术类案件不一样，做开发、架服务器、做运维，这些行为本身是社会运转的日常动作。一个程序员早上起来写了两百行代码，和另一个程序员早上起来也写了两百行代码，动作完全一样，差别只在前者知道这段代码会被用来诈骗，后者不知道。

知道了，是犯罪。不知道，是工作。

所以主观明知是技术刑案的第一道闸门，也是控辩双方最先交火的地方。闸门拉起来，后续的客观行为、证据链条、数额计算才有意义。闸门没拉起来，后面的一切都不需要谈了。

以常见的几个罪名举例：

帮信罪，法条原文将明知两个字写在最前面。两高一部2025 年 7 月联合发布的《关于办理帮助信息网络犯罪活动等刑事案件有关问题的意见》，用大量篇幅细化明知的认定规则——实务中争议最大的不是技术支持这个客观行为，而是被告到底知不知道。

侵犯著作权罪，要求以营利为目的、未经许可复制发行。未经许可四个字本身就嵌入了明知，即你得知道你无权复制。比如开头的那个案件，小公司的 CTO 每天审代码，知道哪些模块是买来的、哪些是自研的、哪些是开源的，大公司的 CTO 只管方向不管代码，他可能真不知道某个模块的来路。同样的客观行为，明知的认定决定了一个起诉一个不起诉。

侵犯商业秘密罪，非法获取、披露、使用三类行为都要求行为人知道自己获取、披露、使用的是别人的商业秘密。误以为自己有权使用的，不构成本罪。

非法获取计算机信息系统数据罪，要求侵入计算机信息系统获取数据。侵入这个词本身就包含了明知，你得知道你在进入一个你不该进入的系统。技术人员用公司分配的测试账号访问了数据库，算不算侵入？取决于他知不知道测试账号的权限边界在哪里。

这一组罪名有个共同规律：客观行为和技术动作挂钩，入罪的关键在主观认知上。检察官要把明知证上去，辩护律师要把明知拆下来。双方围绕的战役，打的不该是法律概念，应该是技术事实。

二、法律标准：三层递进与一条底线

法律上的明知，不是一道是非题，是一道证明程度题。

刑事实务里，明知的证明有三个层次。第一个层次，确实知道——聊天记录里写了这款软件用于什么渠道，被告人回复收到。这就没什么可争的。第二个层次，应当知道——法律不以你嘴上说不知道为准，某些情形下推定你知道。第三个层次，可能知道——不确定、隐隐约约、有点感觉，但说不清楚。

前两个层次在实务里用得多，区分相对明确。最容易出事的是第三层。可能知道四个字，伸缩空间太大了。一个运维工程师发现自己维护的服务器访问量在某天夜里暴增，他看了一眼没深究——这算可能知道吗？一个算法工程师被告知他写的人脸识别 SDK 卖给了一家互联网金融公司——他只听到互联网金融四个字，算可能知道吗？

以帮信罪为例：2023 年，北京理工大学法学院秦雪娜副教授在最高人民检察院发表了一篇文章，把这个问题讲透了。她的核心论断是：帮信罪的行为本身具有中立色彩提供技术支持是日常商业行为，不像杀人放火一看就是犯罪。行为越中立，对主观明知的证明要求就应该越高。仅仅认识到他人可能实施犯罪是不够的，必须达到盖然性认识，认识到他人实施犯罪具有高度可能性。在无法充分证明盖然性认识、无法排除行为人只有较低程度可能性认识的情况下，就不能认定明知。这就是存疑有利被告人的程序法底线。

这个底线不是学者的一家之言。2025 年 7 月，两高一部联合发布《关于办理帮助信息网络犯罪活动等刑事案件有关问题的意见》（法发〔2025〕12 号），全文调整和整合了此前的多部规范性文件，专门用大量篇幅细化明知认定规则。意见明确要求全面准确把握行为人是否明知，防止仅凭行为符合情节严重即一概认定，说白了就是别搞客观归罪。

刚才说了三层递进，确实知道、应当知道、可能知道，再加上一层不能逾越的底线可能知道不等于明知，只有盖然性才是门槛。看似法律标准的框架不复杂，但当它落到一个具体的技术行为上，一切就变难了。

一个技术人员到底知不知道自己在帮人犯罪？这个问题不能靠法学概念回答，得从技术行为倒查。

三、公诉人的推定逻辑

主观明知在被告人脑子里，公诉人拿不到，只能用外部行为推定。这在法律上没问题，推定是主观事实证明的常规手段。但技术类案子的推定有个毛病：技术行为的日常性和犯罪行为的隐蔽性搅在一起，同一段代码、同一组日志、同一条聊天记录，控方说是明知，辩方说就是正常上班。

而实务里最常见的公诉人在主观明知上的推定链条有四条：

1.岗位推定：你是 CTO，你怎么可能不知道？

这条链在法庭上的推演通常是三步：技术岗位高→对系统有全局掌控→必然知道产品的违法用途。三步推导看起来严丝合缝，但有一个致命跳跃——它把组织架构图上的汇报关系当成了信息通路。

辩护的要点不是去说服法庭 CTO 可以不知道，而是还原技术组织里的实际信息流向：这个 CTO 有代码审查的制度义务吗？日常工作包含代码审计吗？他手下的技术 leader 有没有向他汇报过这段代码的来源？问清楚了，头衔和主观认知之间的那条线自然就断了。

2.技术难度推定：这么复杂的技术你都能做，你说你不知道它用来干什么？

这条链把技术能力和违法认知画了等号。背后的假设是：一个人既然有能力驾驭一项技术，就必然理解这项技术被用在了什么业务场景里。这个假设在现代软件开发里经常不成立。

现代软件系统是高度分层的。做基础架构的人写的是底层库，不知道上层业务在跑什么。做中间件的人写的是 API 网关、消息队列，不关心调用方是谁。做业务逻辑的人可能只负责一个模块，对系统整体功能只有碎片化的理解。越往底层走，技术人员看到的世界越抽象——一段加密代码、一组流量转发规则、一个数据库连接池，本身并不携带自己将被用于犯罪的任何信息。

一个做加密算法的工程师，技术能力世界顶尖。但他的工作是把一段加密逻辑实现出来、打包成 SDK、交给上层调用。这个 SDK 被集成到了一个诈骗 App 里——他知道吗？他没有打开那个 App 看过的义务，也没有这个工作流程。他只有一个普通程序员的信息视野。

辩护要做的是还原被告人的技术视野边界：他负责的是哪个技术层？日常工作里能看到什么、看不到什么？他对这块技术被集成后的最终用途，有没有任何渠道可以获知？把分层讲清楚，技术与知道之间的跳跃自然就不再成立。

3.异常特征推定：聊天记录里有注意合规、别让外面知道，或者服务器半夜流量暴增，公诉人说正常业务不会这样，你肯定知道有问题。

这条链在四条里最需要认真对待，因为它不依赖岗位头衔，也不依赖能力推断，而是指向了行为人本身的言行和环境特征。一个人自己说了注意合规，就意味着他意识到可能存在不合规。但关键是怎么理解这些词在具体语境里的含义。

注意合规这短短几个字，可以指向完全不同的可能性。它出现在公司刚被监管处罚完的那一周，技术负责人发在全组群里的例行提醒——这是正常的合规管理行为，不指向具体的违法认知。它出现在只有两个人的一对一私聊、上下文在讨论某个特定功能上线前要不要绕过法务审查——那就完全是另一回事了。服务器半夜流量暴增可能是 DDoS 攻击的征兆，也可能只是市场部投了一笔广告费、用户量正常上涨。

辩护要做的不是否认聊天记录和日志的存在，而是还原它们的上下文：这句话是谁对谁说的、在什么场景下说的、前后聊了什么、有没有同时期的业务背景可以解释。拆开看，很多看起来威力巨大的异常特征，放到完整的上下文里就失去了指控方向。

4.报酬推定：拿了这么多钱，明显超出正常工资。

这条链的逻辑是：报酬数额和方式存在异常，现金、私人转账、分成比例高得不合理，明显是有问题的，你应该能认识到。

但报酬类型和认知范围之间，并不是线性对应的。固定工资对应的是岗位职责的履行，不要求对每一项具体工作的合法性做判断。项目奖金对应的是特定模块的完成，认知范围局限在这个模块以内。分红或干股对应的是对公司整体业务的参与和了解，这一层的认知范围才更接近全貌。

虽然不同类型报酬对应不同的认知范围，这个逻辑法庭是听得懂的。但具体怎么展开，我们后面的文章再具体阐述。

以上四条推定的共同特点是在逻辑上都有跳跃。岗位推定跳过了信息通路，技术难度推定跳过了技术分工，异常特征推定跳过了上下文，报酬推定跳过了报酬类型差异。公诉人把推定做成填空题，辩护律师要把它拆成证明题——每一刀拆开，看有没有逻辑空当，有没有替代解释。真拆开了，很多案子的明知基础就不是铁板一块。

四、结语

写到这里，这一篇只做了一件事——把主观明知的问题拽回技术事实里来。

法条上、司法解释里、学术文章里，明知的认定规则可以写得很密，但落到一个活生生的技术人身上，核心就回到那四个问题：他在什么岗位上、做了什么样的技术动作、信息是从什么通道到他手里的、他拿的是什么类型的报酬。四条推定链条的漏洞，每一个都藏在技术细节里，不回到行为本身，辩无可辩。

公诉人的推定不是不能打的，岗位推定跨了一堆论证环节、技术难度推定把专业能力和法律认知混了、异常特征推定要看出处和上下文、报酬推定要区分来源。但光知道推定有问题还不够，你得能用技术事实把问题说清楚。

这就是下篇文章要讲清楚的事~下期见。

作者简介

武俊吉律师

北京市京师律师事务所团委书记，合伙人，专利代理师，京师律所（全国）知产委副主任，京师律师（全国）青工委副秘书长，北京知识产权法研究会委员，北京市朝阳律协青工委副秘书长，毕业于中国政法大学法律硕士学院（知识产权法方向），同时具有理工科学历背景（计算机科学与技术）。