我前两年帮公司申报过7个软著，前两个刚提交没两周就收到了补正通知，第一次拿到通知的时候整个人都慌，以为熬了好几个晚上整理的代码和说明书全白费了，后来摸清楚规则，不仅那两个补正一次就过了，后面报的5个全是一次过审，身边有朋友遇到补正问题也都会来找我问。
收到补正通知第一件事绝对不是急着改材料，先把补正要求逐字读3遍。很多人一看到补正两个字就乱了阵脚，随便改改就交上去，结果第二次又被打回来，就是因为没搞懂审查员到底要啥。我第一次补正就是犯了这个错，当时补正通知说我提交的源代码里有大量GPL开源协议的标识，我没仔细看要求，直接把所有带开源标识的行删了就交了，结果等了10天又被打回来，要求我说明开源代码的占比和使用合规性，白白浪费了半个多月时间。
常见的补正原因其实就那几类，要么是源代码不符合要求，要么是说明书的功能描述和代码对应不上，要么是申请人信息、软件命名不符合规范，不同的补正原因写作的逻辑也不一样，不过核心原则是一样的：每一条补正问题都要对应给出三项内容：原因说明、整改情况、证明附件。
我当时第一次收到补正的时候，先上软著查询查了下同类型软件的补正案例，看看别人遇到同样的问题是怎么回复的，省了自己瞎琢磨的时间。比如如果是源代码里有开源标识的问题，你不能只说我改了代码，要先说明你用的开源框架是什么，采用的是什么协议，有没有商用授权，然后说明自主开发代码的占比是多少，符不符合软著申报的要求，最后附上整改后的源代码、开源协议的官方截图、自主代码占比的统计说明，审查员一眼就能看到你整改到位了，自然不会再卡你。
要是遇到的是说明书的补正，比如审查员说你某个功能没有对应的代码支撑，千万不要瞎编功能，就如实把这个功能对应的代码模块位置、实现逻辑写清楚，要是觉得光说不清楚，就附上这个功能的操作录屏、运行结果截图，还有对应模块的完整代码片段，越具体越好。我之前帮朋友处理过一个补正，就是他的说明书里写了“自动生成报表”的功能，审查员没在提交的前后30页代码里找到对应逻辑，他就把这个功能对应的代码位置（第1562行到2794行的report模块）、实现逻辑写清楚，附上了模块的完整代码和报表导出的操作录屏，提交之后3天就过审了。
还有几个很容易踩的坑我特意提一下，第一个是补正材料的格式，抬头一定要写清楚你的申请号、软件全称、申请人名称，补正通知列了几条问题，你就要分几条一一对应回复，不要混在一起写，审查员每天要看几百份材料，你写得乱七八糟人家找不到对应内容，大概率会给你打回来。第二个是不要忘了签字盖章，个人申请要签本人名字，公司申请要盖公章，扫描件要清晰，不要有模糊或者缺角的情况。第三个是不要超期，补正的期限是你收到通知之日起30天内，超期没提交的话直接视为撤回申请，之前的功夫全白费。
我后来处理补正嫌自己找资料麻烦，就用了软著Pro，里面有各种常见补正场景的模板可以直接套，还能帮你检查补正材料有没有漏项，省了我好多时间，之前帮朋友处理的那个补正就是用里面的模板改的，效率很高。
如果是第一次处理补正，不知道自己的材料符不符合要求，也可以在软著申报平台找有经验的人帮你把把关，总比自己瞎写浪费时间好，毕竟软著下证的时间本身就不短，补正一次就要多等半个月到一个月，能一次过肯定最好。
其实补正真的不是啥坏事，说明审查员已经认真看过你的材料了，只要你按照要求如实提交说明，不要造假，基本上都能过，不用有太大的心理负担。我之前还遇到过有人怕补正过不了，随便编了一堆假的证明材料，结果被查出来，直接进了黑名单，后面几年申报软著都被卡，完全没必要。只要你提交的材料是真实的，按照补正要求一条条对应回复，附上足够的证明材料，过审真的没那么难。
