很多人第一次申请软件著作权，材料交上去之后最担心的不是流程慢，而是被通知源代码材料重复率偏高，需要补正。说实话，我第一次整理软著材料时也卡在这里：明明项目是自己做的，业务逻辑也不复杂，但提交的60页代码里，大量都是自动生成的实体类、通用工具类、前端框架代码和配置文件，查重结果自然不好看。后来接连帮几个项目做过软著申报，才慢慢搞明白，软著重复率怎么降低，关键不只是“改几个变量名”，而是要先选对材料，再做有边界的整理。
先弄清楚重复率到底高在哪里
软署审查时看的源代码材料，通常要求提交源程序前后各连续30页，每页不少于50行。很多项目实际代码量并不少，但真正有辨识度的业务代码可能只占一部分。剩下的大量内容，是脚手架、第三方依赖、开源框架模板、MyBatis或Swagger自动生成的代码，还有统一返回对象、异常处理、日志封装这类常见结构。
这些代码有个共同特点：大家写得都差不多。比如Result、Response、BaseController、User实体类、分页查询对象，字段无非id、createTime、updateTime、pageNum、pageSize，注释也常常是生成器自动带出来的。你把这些页面原封不动放进去，重复率当然容易升高。
还有一种情况更冤：项目里确实有自研逻辑，但申请人为了凑够页数，前面30页全放目录结构、接口定义、get/set方法，后面30页又放了大量Lombok生成后的展开代码。看上去代码很厚，实际上有效表达很少。审查老师看不到系统的独特流程，查重工具反而更容易匹配到相似片段。
第一步不是改代码，而是重新选代码段
我现在整理材料，一般不会直接把整个工程导出就交。先做一遍筛选，把最能体现软件核心功能的模块挑出来。比如一个订单管理系统，优先选订单生成、库存扣减、支付状态回写、售后审批、报表统计这些模块；如果是设备监测平台，就选数据采集、协议解析、告警规则判断、阈值计算、消息推送这些部分。
选择代码时有个原则：尽量避开纯模板、纯配置、纯自动生成内容。像package信息、import列表、空构造方法、简单getter/setter、Swagger注解、数据库映射XML里的通用SQL，都可以少放或不放。不要心疼这些页数，软著材料看的是源代码表现，不是比谁堆的行数多。
如果项目本身代码量足够，我会直接截取业务实现类、算法处理类、规则引擎类、状态流转类和自定义工具类。前后30页尽量保持连续，但这个“连续”是围绕选定模块来的，不代表必须从工程第一行开始。可以从某个核心业务类的包声明开始，到该模块完整逻辑结束，再衔接同一业务链路里的下一个类。
要是项目代码量偏少，凑60页比较吃力，就更不能拿开源文件硬凑。那种把vue、element、jquery或者某个SDK源码粘进去的做法，风险很大。开源库本身在网上到处都是，一查一个准。更稳妥的方式是补充自研功能模块，或者把系统中的关键流程、接口适配、数据清洗、权限控制等部分整理完整。
改写时别只做表面替换
说到降重，很多人第一反应是改变量名。比如把userName改成username、result改成res、list改成dataList。这种改法不能说完全没用，但只靠它，通常不够。代码的结构、判断顺序、注释句式、异常处理逻辑如果都没变，重复片段照样会被识别出来。
我一般会从几个层面一起处理。
先调整代码结构。能拆方法的拆方法，能合并的小段逻辑重新归类。例如一个很长的saveOrder方法，可以拆成参数校验、价格计算、库存判断、订单持久化、消息通知几个私有方法。拆分后业务含义没有变化，但代码呈现方式会自然很多。注意不要为了降重故意写出看不懂的嵌套，更不能把正常逻辑改坏。软著材料虽然不要求代码可运行提交，但可读性、逻辑性要经得起看。
再处理命名和注释。变量名、方法名可以结合具体业务命名，而不是沿用通用模板。比如不要所有地方都叫handleData，可以改成calculateMonthlySettlementAmount、buildEquipmentAlertContent这种更贴近业务的名字。注释也别照搬网上教程的句式，用自己的话说明输入、处理规则、异常分支和返回结果。那些自动生成的“get the value of id”“set the value of id”之类注释，能删就删。
最后调整表达方式。同样的if-else判断，可以用提前return、策略类、枚举映射、Optional处理或者状态机方法来写；循环里的统计逻辑，可以按业务步骤重新分层；日志输出内容也可以结合系统场景重写。这里的重点是让代码体现你的系统设计，而不是简单同义替换。
不过有一条边界要守住：不要把第三方开源代码伪装成自己的原创代码。软著申请材料应当反映申请人自主开发的软件内容。通用库可以存在于项目里，但不适合作为源代码材料的主体。降重是为了让自研表达更清楚，不是为了掩盖权属问题。
文档部分也会影响整体观感
很多人只盯着代码，却忽略说明书或操作手册。软著材料是一套组合，源代码、软件名称、功能说明、界面截图之间要对得上。如果源代码里全是用户增删改查，文档却写自己实现了智能调度、复杂算法和大数据分析，审查时就容易显得材料不一致，严重时还会要求补正。
写说明书时，我习惯按真实业务流程走：从登录、角色权限、数据录入，到核心功能处理，再到查询统计和系统设置，每个模块配实际界面截图和操作说明。截图里的软件名称、版本号、公司或个人名称要统一。别从别的项目直接复制一份说明书，只替换标题。这种文档和代码一起交上去，就算源代码重复率勉强过了，也可能因为内容不对应被打回。
如果你不确定自己选出来的代码是不是太通用，或者想先做一次重复率检测，可以试试 软著Pro 这类工具。我通常会在正式提交前把候选代码页放进去跑一遍，重点看哪些类、哪些注释、哪些通用片段命中得比较多，再回头调整代码选择。它不能替你完成原创设计，但能帮你快速定位问题，比闭着眼睛改一通效率高。
这些坑我基本都见过或者踩过
一个最常见的坑，是大量保留自动生成代码。尤其是用代码生成器做后台管理系统的项目，Controller、Service、Mapper、Entity一套下来，结构和命名高度雷同。我的做法是保留少量入口类，让审查者能看懂调用关系，主体尽量放自定义业务实现。比如Controller里有个性化校验、流程编排，就可以保留；如果只是一行调用service.save()，那没必要放太多。
第二个坑，是注释比代码还重复。不少团队喜欢在每个方法上放同一套模板注释：@author、@date、@param、@return，再配一句“新增数据”“修改数据”“删除数据”。这些注释本身没有问题，但密集出现会让材料显得很模板化。可以保留必要的JavaDoc，同时把核心方法的注释改成业务说明，比如优惠金额如何计算、工单状态为什么不能直接从待审核跳到已完成。
第三个坑，是为了凑页数加入大段SQL、JSON配置或静态资源。SQL可以选有代表性的复杂查询、统计语句，但不要把几百行字段映射都贴上去；JSON配置、路由表、国际化文案这类内容对体现软件逻辑帮助有限。前端项目则建议提交Vue/React组件中的核心业务代码，而不是压缩后的JS、UI框架源码或CSS重置文件。
第四个坑，是页码和格式处理粗糙。提交前要检查页眉软件名称、版本号是否一致，代码是否清晰，有没有大量黑块、空行或半个单词换行。每页行数尽量稳定，不要为了规避查重把字号调得过小，或者故意删括号、加乱码。这种动作很容易被看出来，反而得不偿失。
真正稳妥的降重思路
如果让我把经验浓缩成一句话，就是：先保证材料展示的是自研核心业务，再通过结构、命名、注释和代码选段降低重复，不要靠抄袭改写或硬凑模板。
实际操作时，我一般按这个顺序来：先通读项目，确定软件最有特点的三到五个功能；再从这些功能对应的模块里挑选连续代码，尽量避开框架和生成器内容；然后对重复度高的通用类做删减，对业务方法做合理拆分和注释补充；最后把代码、说明书、截图和申请表里的软件名称、版本、功能范围统一核对一遍。有需要的话，再通过 软著重复率检测 先看命中情况，针对性修改，而不是全篇乱改。
软著申报不是论文答辩，不要求代码多么高深，但材料要能让人看出这是一个具体软件，而不是从网上拼出来的通用工程。把自己真正写过的业务流程、规则判断和系统交互清楚呈现出来，重复率问题大多能解决，补正概率也会低很多。
