前阵子帮团队提交的两个软著，其中一个卡在了源代码重复率的问题上，收到补正通知那天我还在赶项目上线的需求，当时脑瓜子嗡的一声——之前听同行业务的朋友说，补正材料要是写得不对，轻则再拖一两个月审核，重则直接驳回，之前花了半个月整理的材料全打水漂。
我前前后后办过不下20次软著申报，补正也碰过三四次，说实话补正真的没有很多人说的那么难，核心就是把审查员提的问题给足回应，别打太极，也别漏项。
首先拿到补正通知书第一件事，别上来就改材料，先把审查员列的所有问题一条一条标出来，哪怕是“公章模糊”这种看起来很小的问题，也别漏，我之前有个同事就是漏了审查员提的“说明书页眉版本号和申请信息不一致”的问题，只改了源代码的问题，结果第二次被打回来，硬生生多耗了一个月时间，差点耽误了公司申报高新的时间点。
补正材料的开头不用搞什么花里胡哨的格式，第一行先写清楚软件全称、版本号、申请号、申请人信息，方便审查员对应到你的申请单，接下来就对着审查意见一条一条写回应，每一条回应分两部分，先说你是怎么改的，再附上修改后的材料就行。比如审查员提“源代码前后重复率过高，未体现核心自研内容”，你别就只把新的源代码打包传上去就完事，要在回应里写清楚“本次重新提交的源代码为软件核心功能模块的自研代码，去除了之前误提交的开源框架通用代码，前后各30页无重复内容，总行数符合要求，页眉软件名称、版本号与申请信息完全一致”，相当于直接把审查员要的答案递到他面前，不用他自己去翻材料找。
我第一次碰补正的时候也慌，不知道怎么写回应才合规，后来同行给推了软著Pro，上面有不同补正场景的参考模板，还有最新的审查规则，对着捋逻辑省了很多事，不用自己瞎猜审查员要什么。
我碰过最多的补正问题主要是三类，第一类就是源代码相关的，要么是行数不够，要么是重复率太高，要么是页眉的信息和申请的不一样，还有人直接把测试数据、注释全删了凑页数，结果审查员看代码全是连续的功能函数，一眼就看出来是凑的，这种补正的时候一定要提交真实的核心代码，别凑数，3000行的要求其实很低，稍微上点规模的软件核心代码都不止这个数。
第二类是说明书的问题，很多人做说明书的时候图省事，直接拿别的软件的说明书改，结果截图里带了别家的logo，或者功能描述和提交的源代码完全对不上，还有的操作流程缺头少尾，只有核心功能的截图，没有登录、注册这些基础流程的内容，这种补正的时候最好把你修改的地方用红色标注出来，然后在回应里列清楚你修改了哪几页的什么内容，比如“已修改说明书第3页、第7页的功能截图，去除了第三方工具的水印，补充了从用户注册到核心功能调用的完整操作流程，所有功能均对应提交的源代码内容”，审查员一看就知道你改到位了。要是你不确定说明书的规范，也可以去软著申请相关的工具站查最新的要求，别用三四年前的旧模板，现在的审查规则比之前严很多，旧模板很多都不符合要求了。
第三类就是资质材料的问题，比如公章盖得太糊，或者营业执照没盖公章，个人申请的身份证没有签字，这种最简单，直接重新提交清晰的资质文件，在回应里说清楚已经重新提交符合要求的材料就行。
很多人补正的时候容易踩的坑，首先是回应不对题，审查员问你为什么源代码重复率高，你扯我们这个软件就是用了开源框架，那肯定不行，你得说清楚之前提交的重复部分是开源框架的通用代码，本次已经替换成自研的核心功能代码，重复率已经符合要求。还有就是材料格式乱，要求提交PDF格式你传个Word，或者页码乱序，审查员每天要看上百份材料，你给人添乱，自然容易被打回来。还有最关键的，补正的期限是收到通知之后2个月，超期直接视为撤回，之前交的申请费都退不回来，千万别卡着最后一天提交，万一网络出问题或者材料传错，连补救的机会都没有。
我身边还有个朋友更有意思，补正说明写得特别硬，上来就说“我们的材料没有问题，是你们审查错了”，结果自然是被驳回，其实审查员很少会故意挑错，既然给你发补正通知，就说明你的材料确实有不符合要求的地方，老老实实对着改就行，没必要带着情绪写材料。
其实补正本身不是坏事，说明你的申请还有过的机会，只要你对着审查意见一条一条对应，把改的内容说清楚，材料符合要求，基本都能一次过，不用太焦虑。我上次那个源代码的补正，就按照这个逻辑写的说明，重新提交之后不到10天就过审了，拿证时间也没耽误多少。