我前两年帮公司申报软著，第一次3个申请里2个收到了补正通知书，当时盯着那几条审查意见傻了眼，怕改不好直接被驳回，白瞎了前期花的半个月准备时间。后来摸了几年的门路，现在不管是自己申报还是帮朋友救急补正，基本提交一次就能过，甚至还碰到过不用改材料、直接说明情况就通过的情况。
首先拿到补正通知书的时候，先别着急改材料，把审查员提的每条意见逐字读三遍，先搞清楚人家到底要你改什么。我见过太多人上来就瞎改，审查员说你说明书里功能描述和代码对应不上，他转头去改了源代码的格式，提交过去直接又被打回来，白白浪费十几天的审核时间。如果实在拿不准某条意见对应的要提交什么材料，可以先去软著补正相关的工具站查下对应问题的常规解决方案，比自己瞎猜要高效得多。
写补正材料的第一个核心，就是要和审查意见一一对应，提了几条就回应几条，一条都不能漏。开头先把申请号、软件全称、申请人信息准确填好，我同事之前就犯过傻，申请号少写了一位，提交过去根本匹配不到对应的申请单，直接被退回，本来能赶上的项目补贴都错过了。每条回应的开头先明确标注是对应第几条补正意见，然后先说你做了什么调整，再附上调整后的证明材料，别就干巴巴说一句“已经修改”，审查员没功夫自己去翻你提交的材料找改了哪。比如审查员说你提交的源代码里有其他公司的版权声明，你就先说明这段代码是引入的遵循MIT开源协议的公共组件，附上开源协议的官方截图，再说明自主编写的核心代码占比超过80%，最后附上调整后标注了开源组件位置的源代码就行，逻辑顺了人家一眼就能看明白。
不同的补正场景写法也不一样，最常见的是说明书补正，比如审查员说你说明书里有太多和软件功能无关的公司宣传内容，或者界面截图没遮挡敏感信息，你改完之后要明确说明“已删除说明书第3页到第5页的公司业务介绍内容，所有界面截图中的用户手机号、后台地址等敏感信息已做打码处理”，后面附上新的说明书就行。如果是源代码的补正，要注意提交的前后各30页代码不能有太多空行，每页至少要有50行有效代码，开头要对应软件的初始化模块，结尾要对应核心功能的实现模块，别随便从项目中间截一段就交上去。我之前每次整理源代码都要花两三个小时删空行、调格式，后来朋友推荐用软著Pro，上传整个代码包就能自动生成符合要求的前后30页代码，格式完全符合审查要求，省了超多事，后来补正的时候用它生成的代码基本没再被提过格式问题。
还有很多人容易忽略签章和提交时间的问题，个人申请的话补正回函要签自己的本名，公司申请的话要盖鲜章，不能用电子章，盖章的时候尽量盖在申请人名称旁边，别把字全挡住了，我之前有个朋友就是章盖歪了，挡住了公司全称，又被要求重新提交。补正通知书下发之后要在30个工作日之内提交材料，超期的话申请会直接被视为撤回，之前交的申请费也不会退，这种低级错误真的没必要犯。
要是你觉得审查员的意见有误解，也不用硬着头皮改自己本来没问题的材料，只要拿得出证据就行。我之前有个软著申报的单子，审查员说我们的软件名称和已有软著重名，但其实我们做的是工业领域的设备管理系统，已经过审的那个是社交类的APP，完全不搭边，我就整理了两个软件的功能差异说明，附上我们的软件使用场景证明，提交上去之后没改名称直接就过审了。
其实补正真的没大家想的那么可怕，审查员也不是故意卡你，只要你针对每条意见给出清晰的回应，该附的材料都附全，基本都能顺利过审，不用太焦虑。