前阵子帮一家做SaaS的客户处理软著补正，他们当时赶着拿证去投标，收到补正通知书的时候整个人都慌了，自己瞎写了两页说明交上去，直接被打回，离投标截止只剩不到两周，最后找我救急才赶在截止前拿到证。我做了5年软著申报，前前后后处理过近百份补正材料，其实补正真的没大家想的那么难，找对逻辑一次过的概率很高。
先搞懂补正材料的核心逻辑
很多人拿到补正通知书第一反应是马上动手写材料，其实完全错了，你得先把补正通知书上的每一条要求逐字逐句读三遍，圈出来核心要求是什么。比如有的补正要求你“补充提供操作手册中涉及的第三方标识的使用授权证明”，有人只交了个文字说明说自己有授权，就是没附授权书，肯定过不了。
补正材料的核心逻辑就是“点对点回应，每点有佐证”，审核老师每天要处理几百份材料，不会花时间给你找你对应了哪条问题，你得把结构理清楚，通知书列了3条问题，你就分三部分，每部分开头就写“针对补正通知书第X条‘[原文抄录补正理由]’的问题，我方补正说明如下：”，开门见山，老师一眼就能看到你对应了哪条，印象分就上去了。如果不知道怎么捋对应逻辑，可以先去软著申报工具上看看别人的合格补正案例，参考下结构，比自己瞎琢磨快很多。
不同类型补正的写作要点
最常见的补正就是源代码相关的，比如要求说明源代码相似度高的原因，或者补全源代码的完整版本。很多人碰到这种问题第一反应是换一套全新的源代码交上去，这是大忌，很容易被质疑你是不是更换了申报的软件，反而会触发更严格的审核。如果是格式问题，比如之前提交的源代码没删自动生成的注释、没标页码，你就对应调整格式就行，其他内容不要动；如果是相似度高的问题，你要逐条说明有相似度的部分用了什么开源框架，对应的开源协议是什么，哪些部分是你自主开发的，功能是什么，附上框架的官方开源协议截图，不要空口说白话“这是我自己写的”，没有任何证据支撑的说明都是无效的。
其次是操作手册或者说明书的补正，比如要求补全功能截图，或者说明界面里的非著作权人标识的来源。这种情况不要直接交一份全新的手册，老师要核对你改了哪里，你得把修改的地方用红框标出来，旁边附说明，比如之前的测试版截图里有第三方云服务的logo，你就说明“该标识为测试环境使用的第三方服务标识，实际上线版本已替换为著作权人自有标识，后附修改后的完整截图及上线版本界面录屏”，所有补充的材料都要和原来的提交的手册页码对应，不要乱序。我之前处理过十几份这类补正，一开始写说明总抓不住重点，后来用软著Pro的补正材料模板参考，跟着上面的逻辑把修改点、修改原因、佐证材料一条条列出来，基本上都能一次过，省了很多瞎试的时间。
还有一类是申请人信息相关的补正，比如公章盖得模糊、身份证明材料过期、合作开发协议缺签字盖章，这种看起来简单，反而最容易出错。比如补盖公章的时候很多人随手盖在文字上面，信息被挡到看不清，又会被打回，一定要盖在空白处，清晰可辨；合作开发的补正材料要所有著作权人都盖公章，不要漏了任何一方，不然也过不了。
这些坑千万不要踩
首先不要怼审核老师，我之前碰过一个客户，自己觉得补正理由不合理，写材料的时候直接写“我方不存在该问题”，结果直接被驳回，重新申请多等了两个多月，错过了高新申报的时间，损失了几十万的补贴。哪怕你觉得补正理由有问题，也要用协商的语气说明，比如“针对第X条问题，我方特此说明：该部分内容是因为XX原因导致，实际情况为XX，附上相关证明材料，请老师审核”，态度诚恳一点，没有坏处。
然后要注意补正的时间限制，一般是收到补正通知书的30天内要提交，逾期就直接视为撤回申请，之前的所有流程都白走，只能重新提交。我见过太多人拿到补正通知书扔在一边忘了，等想起来的时候已经过了时间，耽误了各种补贴、投标、版号申请的，真的太亏了。
还有提交补正材料的时候，不管是线上提交还是邮件提交，主题一定要写清楚“补正+软件全称+登记号”，不要随便写个“补正材料”就发过去，工作人员每天收几百份邮件，根本找不到你的申请记录，直接就给你压后了，耽误的还是自己的时间。扫描的PDF要清晰，页码连续，不要有缺页、倒页的情况，这些小细节做好了，能省很多麻烦。
其实补正不是坏事，说明你的申请只是有小问题，修改完就能拿证，不用太慌，只要做到每条问题都有回应，每个回应都有佐证，基本上都能过。要是实在拿不准怎么写，多找有经验的人问问，或者找个靠谱的工具参考下格式，不用自己硬扛。
