软著申请「模板化补正」实战手册
软著申请的「模板化补正」实战手册
按版权局给出的数据来看，很多人已经得到补正的消息了吧。首先恭喜下证的著权人和代理公司们，现在下证确实不容易，你们太棒 了！
很多人觉得，软著申请就是说明书越厚越好、一次提交越多越省事、收到补正就赶紧修改。
今天分享三个很多人不知道，却非常实用的反直觉经验。
一、使用文档：质量远比页数重要
很多人的第一反应，就是把软件使用说明书写得越厚越好。
事实上，现在的审核逻辑已经发生了变化。
官方真正看重什么？
从版权中心发布的《软件说明书结构模板》可以发现，官方更加关注的是：
- 软件功能描述是否清晰
- 功能之间逻辑是否完整
- 说明书是否能够真实反映软件
- 图文是否能够对应软件实际功能
换句话说：
请站在审查员的角度去写说明书。
对于每天需要审核大量材料的审查员来说，一份格式规范、逻辑清晰、图文对应、名称一致的说明书，比几十页空洞文字，堆砌高屋建瓴技术的文档，更容易判断软件是否真实存在。
一份优秀说明书必须具备三个要素
① 功能概述
介绍软件解决什么问题、主要实现哪些功能。
避免大段空话，重点突出软件核心能力。
我们应该把为什么要开发这个软件讲清楚，注重创造性和独特性。
② 真实运行截图
截图必须：
- 来自真实软件运行界面
- 内容清晰可辨
- 能体现核心功能
- 不使用大量重复页面
截图不是越多越好，而是越有代表性越好。
③ 详细操作步骤
每个功能都应该写清楚操作流程，例如：
- 登录系统
- 创建项目
- 上传数据
- 点击开始处理
- 查看处理结果
更重要的是：
说明书中的每一个功能点，都应该能够在源代码中找到对应实现。
说明书、截图、代码三者形成闭环，审核通过的概率会更高。
页数的真相
版权中心并没有规定说明书必须多少页。
但从大量申请经验来看：
| 页数 | 建议 |
|---|---|
| 10页以下 | 内容可能偏少 |
| 10～20页 | 大多数软件较为合适 |
| 30页以上 | 如果大量重复，灌注水话，意义不大 |
真正影响审核的不是页数，而是：
有没有把软件讲清楚。
一句话总结：
言之有物，远比页数更重要。
二、模板误判：不要硬补，直接「撤回重来」
这是近几年越来越多人采用的一种处理方式。
尤其是在收到补正通知，并出现模版化程度较高时。
很多人第一反应是：
我赶紧改一下再提交。
实际上，这往往不是最佳选择。
为什么不建议硬补？
出现"模版化程度较高"的补正意味版权局不太认可你软件是真实可用的。你固然可以解释，但是补正消耗时间太长，不确定因素太多。 这时候如果改动不合审查员心意，很可能仍然无法通过审核。
补正从提交到审核大概30天起，常规要消耗50天。而新材料从提交到审核需要20天左右。
更高效的方法：主动撤回
很多有经验的申请人会选择：
- 提交撤回申请；
- 等待撤回完成；
- 全面优化材料；
- 重新提交新的申请。
这相当于给整个申请做了一次“重启”
相比在已有问题的申请上不断补正，重新整理材料并提交可以将时间成本从50天降为20天。。
三、批量申请：避开「集中提交」，拥抱「细水长流」
这是很多企业最容易忽略的一点。
尤其是拥有多个软件产品的时候。
很多公司的第一想法就是：
一次把3,4个软著全部提交。
实际上，这种方式并不一定最稳妥。从现在的通过率，和网友们真实软件也被要求补正的情况来看，有些其实是被严打误伤了，不过不用气馁，我们可以构建少量多次的策略，避免自己和自己竞争下证率。
为什么不建议集中提交？
虽然版权中心并未公开规定单次申请数量限制，但在实际申请过程中，不少申请人发现：即使是同一个写手，几份一起提交，有通过的，也有被要求补正的。
更聪明的方法
一周只提交一个。
这样既能够持续获得知识产权，也能避免因为严打必须标记为补正的风险。
总结：软著申请，拼的不是厚度，而是真实性
如今的软著审核，更像是在验证：
你的软件是否真实存在，你的材料是否真实反映了软件。
真正值得关注的，是以下三个原则：
文档
❌ 追求页数
✅ 追求逻辑清晰、图文对应、内容真实。
补正
❌ 收到建议撤回后反复硬补。
✅ 必要时主动撤回，重新整理材料，以更完善的版本重新申请。
提交
❌ 集中批量提交。
✅ 分批申请、细水长流，更有利于降低审核风险。
最后送大家一句我们在大量软著申请中总结出来的话：
站在审查员的角度写材料，而不是站在申请人的角度堆材料。
一份格式规范、逻辑清晰、功能真实、代码对应、图文一致的申请材料，往往比几十页堆砌出来的说明书，更容易获得认可。