前两年刚接手公司软著申报工作的时候，我踩过最大的坑就是重复率。第一次报3个软著，2个因为重复率超标被打回，当时离高新资质申报的截止日只剩12天，我熬了三个通宵改材料，最后才勉强赶上。后来摸清楚门道之后，近两年报的20多件软著，没有一件因为重复率被驳回，今天就把这些实操出来的经验全说透。
先搞懂：软著重复率到底查的是哪部分
很多刚接触软著申报的人都以为，重复率只查提交的源代码，其实根本不是。现在版权局的审核是源代码和说明书双查，只要其中一项的重复率超过阈值，就会直接被驳回。官方没有公开过具体的合格线，我自己实测下来，最好把两项的重复率都控制在20%以内，基本不会出问题，要是卡在25%到30%这个区间，就很容易被打回来补材料。
很多人第一次申报图省事，直接找网上的模板改个产品名就交，还有的直接扒同行业已下证软著的公开材料，这种百分之百过不了，现在的查重系统已经很成熟了，大段的通用表述一查一个准。要是实在不知道怎么避开别人已经用过的表述，可以先去软著查询平台搜下同品类已经下证的软著摘要，大概摸一下哪些内容是大家都在写的通用表述，自己写的时候尽量避开就行。
说明书降重：多写独有细节比啥都强
我见过很多人写的软著说明书，全是套话，比如做餐饮收银系统的，通篇都是“支持扫码点餐、收银结账、库存管理”这种烂大街的表述，你能这么写，别人也能，重复率怎么可能低？其实要降重特别简单，多写你自己家产品独有的功能细节就行。比如同样是库存管理，你别写“支持库存预警”，改成“门店食材库存低于设定阈值时，系统会自动给采购负责人发企业微信提醒，同时同步锁定对应菜品的点单权限，前台点单时自动展示沽清标识”，这种只有你家产品有的逻辑，根本不可能和别人重复。
还有一个很多人不知道的小技巧，说明书里尽量多放自己做的截图和流程图。我之前有个软著，文字部分的重复率刚好卡到31%，我本来打算大改文字，后来抱着试试的心态，加了3张自己画的功能逻辑流程图和2张后台操作的实拍截图，再提交居然直接过了。后来问了负责审核的朋友才知道，现在查重是图文结合判定的，独有的图片内容会拉高整体的原创占比，不用改太多文字就能把重复率拉下来。
还要注意，别大段抄行业通用的技术原理，比如做大模型相关应用的，别上来就抄半页Transformer的架构原理，你哪怕把这些原理结合自己的产品改一改都行，比如改成“本系统处理用户的文案生成需求时，会先对输入的关键词做3层行业标签匹配，优先调用对应品类的微调语料库生成内容，比通用大模型的输出内容匹配度高40%以上”，这么一改，不仅重复率下来了，审核员也能直观看到你这个软件的独创性，反而更容易过审。
源代码降重：别总想着抄开源凑数
源代码是重复率重灾区，很多人为了凑够要求的前后30页共60页代码，直接把开源框架的底层代码、GitHub上扒的现成代码粘进去，不被打回才怪。首先你要记住，提交的代码优先选你自己写的业务逻辑部分，那些引入的依赖包、开源框架的代码完全不用放，比如你用Java写系统，没必要把Spring的源码粘进去凑数，就挑你自己写的订单生成、用户权限校验、独有功能的实现代码，凑够60页就行。
要是自己写的代码实在不够凑60页，也别直接抄别人的，改一改变量名和注释就行。比如原来的变量名叫order_id，你可以改成biz_vip_order_create_id，注释别写通用的“生成订单”，改成“生成付费会员专属权益订单，自动关联用户绑定的未过期优惠券”，这些小改动看起来麻烦，但是效果特别好，查重系统是逐行匹配的，你变量名和注释改了，整行的匹配度直接就下来了。要是自己凑代码太麻烦，也可以用软著代码生成工具，按照你的业务场景生成独有的代码，根本不用担心重复的问题。
说个我之前踩过的大坑，之前有个同事为了凑行数，把同一段业务代码复制粘贴了三遍塞进去，结果不仅被打回，我们公司还被列入了异常申报名单，后面半年提交的所有软著都要走人工审核，比正常审核慢了整整半个月，真的得不偿失。还有别想着把代码打乱顺序降重，现在的查重系统是按语义匹配的，你就算把代码顺序全打乱，内容还是一样的，照样能查出来，纯纯浪费时间。
最后给大家推个我最近常用的工具，上次公司要凑高新的数量，一次性要报12个软著，我自己整不过来，同行给我推了软著Pro，他们可以提前帮你做材料预审，先查一遍重复率，要是超了会给你标出来具体哪部分要改，怎么改，我那次提交的12个，只有1个需要改几行注释，剩下的全一次过，省了我至少半个月的时间，要是你赶时间或者怕自己整不好，可以试试，反正预审也不贵，比被打回来浪费十天半个月强多了。
对了，还有个小提醒，要是你之前有过被驳回的记录，第二次提交的时候尽量改的多一点，别就改两三个字就交上去，二次审核会比第一次严很多，尽量把重复率压到15%以内再提交，基本就稳了。
