上个月帮一个做企业服务的朋友整理软著申报材料，前两次提交都卡在代码重复率上，官方直接打回要求修改，急得他团团转，毕竟再过三周项目投标就要用软著证书，晚一天都可能错过几百万的订单。我帮他改了不到一天，第三次提交直接过审，其实很多人卡重复率，根本不是你做的东西没有独创性，而是材料整理的时候踩了没必要的坑。
先搞懂：你的重复率到底是哪部分超的很多人拿到重复率过高的驳回通知，第一反应就是瞎改代码，改了半天再提交还是不过。现在版权局的比对库早就不是只比对公开开源代码了，历年申报过的软著材料、网上公开的软著模板都会纳入比对范围，重复率一般是源代码和说明书两部分共同算的，你得先搞清楚是哪部分拖了后腿。要是你还没提交，不知道自己的重复率情况，也可以用软著重复率检测先扫一遍，提前知道问题在哪，比等官方打回再改省至少半个月时间。
源代码降重的核心实操技巧源代码占重复率的权重最高，也是大部分人出问题的地方。首先你得先把凑行数的垃圾代码全删掉，很多人为了凑够要求的3000行，把依赖库的代码、IDE自动生成的配置代码、甚至第三方框架的源码直接粘进去，这些内容不知道被多少人用过，怎么可能不重复？我一般整理代码的时候，只会留团队自己写的核心业务逻辑代码，比如你做个门店管理系统，就留会员管理、库存盘点、营销活动这些你自己写的功能代码，底层的框架代码、公共组件代码全剔掉，根本不需要凑数，真实的业务代码够3000行就放前30页，不够就放全部就行，官方根本不会卡你行数，反而凑的垃圾代码容易导致重复率超标。
剔完无关代码之后，就针对性改重复的片段。别搞什么把代码打乱顺序的小聪明，现在的比对是语义级的，你换个行的顺序照样能查出来。最有效的方法就是改变量名、函数名，加业务场景相关的注释。比如原来的通用函数名叫getUserInfo，你可以加上你们产品的标识，改成getMxShopUserInfo，注释不要随便写// 获取用户信息，要写成// 获取连锁门店端店员的账号信息，包含所属门店权限、当月绩效指标关联数据，这样一改，哪怕你核心逻辑和别人差不多，重复率也会降下来。我现在帮客户做材料之前，都会先扔去软著Pro测一遍重复率，出的报告里会标清楚重复的代码片段对应的对比源，不用自己瞎找，改完再测一遍，确定重复率低于10%再提交，基本上不会在重复率这关出问题。
说明书降重别忽略这些细节很多人觉得说明书不重要，随便找个模板改个产品名就提交，这部分其实很容易导致重复率超标。别写那种“本系统采用Java开发，使用MySQL数据库，实现了用户的增删改查”的套话，这些话一万份说明书里有八千份都在用，不重复才怪。你要把自己产品的具体场景加进去，比如把刚才的套话改成“本系统针对社区生鲜门店的库存管理痛点开发，采用Java SpringBoot框架搭建，使用MySQL存储门店的商品损耗、临期预警、到店核销等数据，用户管理模块支持店长、店员、配送员三级权限分配，不同账号只能操作对应权限范围内的功能”，你把自己的业务细节加得越细，重复的概率就越低。
还有说明书里的配图，别直接用网上找的通用架构图、流程图，自己用绘图工具画一个，把模块名、流程节点改成你自己产品的，比如通用的电商系统流程图里的“订单模块”，你改成“生鲜配送订单模块”，加个临期商品优先分配的节点，图片的特征值变了，就不会被判定重复。要是你不确定自己的说明书有没有重复的内容，也可以走软著申报预审通道提前检查，有问题提前改，省得提交之后被打回耽误时间。
这些坑我替你踩过了别再碰之前遇到过一个客户，为了降重乱改代码，把正常的业务逻辑改得乱七八糟，比如本来是先校验用户权限再查询数据，他为了降重把顺序反过来，审查员一看逻辑都不通，直接判定材料造假，半年内都不让再提交同一款产品的软著。改代码的时候一定要保证逻辑通顺，不能为了降重瞎改，哪怕你多加点和业务相关的注释，都比乱改逻辑强。
还有很多同公司的产品，底层用的是同一套框架，申报多个软著的时候，就别把底层框架的代码反复提交了，每个软著只放对应产品独有的业务代码，不然很容易出现自己和自己之前申报的软著重复的情况，这种驳回真的是亏得慌。
其实软著降重根本没大家想的那么复杂，核心就是别偷懒抄模板，把你自己真实做的东西如实呈现出来，提前检查提前调整，基本上都能一次过审，没必要花大几千找代做，自己动动手就能搞定。