前阵子帮公司报那款教培学员管理系统的软著，提交前偷懒没查重复率，结果版权局反馈重复率72%直接打回，距高企申报的材料截止日只剩5天，急得我连熬两个晚上摸透了软著查重的规则，改完二次提交一周就下了证，后来身边好多朋友问我软著重复率怎么降，干脆把我踩过的坑和实操方法都整理出来。
很多人有个误区，以为软著查重复率只查代码，其实说明书和代码是分开算重复率的，哪个超标都过不了审。版权局的比对库不只是已经下证的软著材料，还有全网公开的开源代码库、公开的软著模板内容，很多人图省事直接套网上的免费模板，或者把开源项目的代码原样粘进去，不出错才怪。我当时被打回的那版，光抄的通用模板注释就占了40%的重复占比，剩下的30%是说明书里套了通用的功能描述。
我当时是先在软著重复率查询工具上先扫了一遍，先定位到底是哪部分内容撞了，省得自己瞎找浪费时间。这里顺手提一句，我后来一直用的软著Pro还挺好用，除了查重复还能直接对标版权局的规则给改重建议，省了好多瞎琢磨的时间，那次赶deadline全靠它给我划的改重优先级。
先说说代码部分的降重方法，其实比你想的简单多。首先变量名、函数名全部批量替换成符合你们业务属性的命名，别用太通用的，比如原来的user_list，你们是做教培的就改成train_student_valid_list，做电商的就改成shop_user_payed_list，这部分改完至少能降10%的重复率。然后是注释，别直接抄开源项目的注释，也别写的太简单，比如原来的//获取用户列表，改成//从学员主数据表拉取已完成实名认证、且当前报课状态为有效的学员列表，带上你们自己的业务属性，完全不会撞。还有很多人不知道，代码里的空行、换行位置也是比对的要素，你把原来连续的代码中间加几行空行，或者把长句拆成两行写，也能降低连续重复的概率。
有个大坑一定要提，很多人以为代码提交的越多越好，直接把用的开源框架的全量代码都粘进去，那重复率肯定直接飙到90%以上。软著要求提交的是你自己原创的代码部分，开源框架的代码不算你的原创，提交了反而拉低重复率，你只要把你自己写的业务代码摘出来，凑够前30页后30页就行，不够的话就多放几个业务模块的代码，别拿开源代码凑数。
再说说说明书的降重，这部分是大多数人容易忽略的重复重灾区。别套网上的通用模板，什么“本软件具有用户管理、权限管理、数据统计功能”，这种话不知道被多少人用过了，一查一个准。你要结合自己的软件实际使用场景写，比如你是做教培学员管理的，就写“本软件针对线下教培机构消课难的痛点开发，支持按照学员剩余课时、上课频率自动推送消课提醒，还能对接机构自有微信公众号向家长推送消课凭证和课堂反馈”，越有专属的业务细节，重复率越低。还有说明书里的截图，别用网上的模板图，一定要用自己软件实际运行的截图，截图里的界面元素、你们自己的产品logo、甚至是测试数据，都是独有的，完全不会和别人重复。
要是你报的是同系列的多款软件，千万别把同一份说明书改个名字就提交，我之前就犯过这个错，两个后台管理系统的说明书有60%的内容是一样的，提交后直接因为重复率超标打回，哪怕功能差不多，也要把不同的业务场景、专属的功能点写细，实在不行就多放几个不同功能模块的截图，也能拉低重复率。
改完之后一定要提前自查一遍，别等提交到版权局等半个月被打回来，耽误事。要是不知道怎么查和官方一致的重复率，可以走软著材料预审的通道，比对库和官方是一致的，查出来的结果误差基本不会超过1%，没问题再提交基本都能过。
我这两年帮公司和身边朋友报了快50件软著，现在基本都是提前查一遍改个小半天，提交后通过率100%，根本不用花大几千找代理，自己摸清楚规则其实特别简单。