软著补正通知书怎么处理？常见原因与修改示范

周二晚上十一点多，我在旧笔记本上刚合上代码，邮箱弹出一封版权局通知——软件著作权补正通知书。点开一看，意见只有两行：源代码文档里软件版本号和用户说明书不一致，限期 30 个工作日补正。当时心里就一个念头，这周发布计划要往后挪了。

先说结论：收到软著补正通知书，不代表申请作废。大多数情况下按通知书指出的问题修改并重新提交，就能继续走流程。怕的不是补正，怕的是没看懂意见就乱改，或者同一份材料原样再交一次。对独立开发者和小团队来说，补正最耗不起的不是打印费，是来回快递和等待周期，一次补正通常多花 10 到 20 天，发布窗口可能就错过了。

下面先列要点：

• 补正有截止日期，通常 30 个工作日左右，以通知书上写的为准；
• 常见原因集中在名称版本号不统一、源代码文档格式错、说明书截图对应不上；
• 修改时不要只改被指出的一处，全套材料里相同的错要一起改；
• 重新提交前，把文件命名、页码、页眉页脚再核对一遍。

补正通知书里常见的问题

我收到的那条算轻的，只让统一版本号。后来帮朋友看补正意见，发现大部分问题可以分成几类，其中名称版本号不统一最常见。申请表上写“某仓储管理系统 V1.2”，说明书页眉只写“某仓储管理系统”，少了 V1.2，就可能被要求补正。版本号不要写成“V1.0.0 build 20240101”这种长串，写 V1.0 或 V1.0.0 没问题，但整套材料必须一致。通知书有时会写“源代码文档第 1-30 页页眉标注版本号为 V1.0，用户说明书封面标注为 V1.1，请核实后提交一致版本”，这已经点得很具体了。

源代码文档出问题也很多。版权局对源代码有明确要求：多数情况提交前、后各连续 30 页，共 60 页；不足 60 页全部提交。每页不少于 50 行，页眉要有软件名称和版本号，页码要清晰。补正意见里常出现“源代码文档不足 60 页”“每页行数不足 50 行”“源代码与说明书功能不符”。还有些人把自动生成的模板代码整页贴上去，被要求说明原创性。

说明书和界面截图对不上，是另一个高频问题。说明书要写清楚运行环境、安装步骤、主要功能操作流程。截图里的按钮文字、界面标题，必须和说明书描述、源代码里的字符串一致。截图如果是低分辨率导出，或者用手机拍屏幕导致反光，补正意见会出现“截图不清晰，无法识别界面内容”。

拿到补正意见后的修改顺序

我的习惯是不直接上手改，先花 10 分钟把通知书里的每条意见拆开，对应到具体文件。比如通知书写“源代码文档与用户说明书版本号不一致”，就打开两个文档搜版本号，把所有出现位置列出来。别只改首页，页眉、页脚、封面、正文里的版本号都要统一。改完用 Ctrl+F 全局搜一遍，确认没有漏网。

如果被指出源代码页数或行数不足，先别急着扩写代码。源代码文档的页边距可以适当调小，行距设成固定值 12 到 14 磅，让每页稳定在 50 行以上。前 30 页和后 30 页要连续，不能跳页。页眉写“软件名称 V1.0”这种格式，页码用阿拉伯数字。导出 PDF 后逐页翻一遍，确认没有空白页和乱码。

说明书和截图的问题，多半出在流程不对应。截图要能看清按钮文字，Windows 下用系统截图工具保存 PNG，尺寸至少 1024×768，大多数情况下够用。说明书里每张图下面加一行说明，例如“图 3：库存查询界面”，并让图注和正文描述一致。改完让同事按说明书操作一遍，凡是截图和文字对不上的，都会成为下一次补正点。

重新提交时，把补正通知书扫描件或电子版放在压缩包首层，文件命名用“补正材料-软件名称-申请人”这种格式。补正说明里逐条引用原意见，写清楚改了哪个文件哪个位置，不要只回一句“已修改”，那样容易被再次退回。

如果平时不想每次手工逐页核对，用成套生成工具能少一些版本号不一致的问题。不过通知书已经在手里，先按上面的顺序改完最实际。

常见问题

软著补正通知书一般给多少天补正？

大多数情况下补正通知书会写明截止日期，通常给 30 个工作日左右。不是从收到快递算，是从通知书上的发文日期或收到日期起算，以通知书为准，千万别压到最后几天。

软著补正可以自己改吗，还是要找代理？

可以自己改。只要按通知书里的意见逐条修改，重新提交即可。如果涉及源代码原创性说明、名称冲突等复杂问题，拿不准再考虑咨询代理或版权局。

补正材料提交后多久能下证？

补正提交后，版权局会重新进入审查流程，通常还需等待一段时间，大多数情况比首次申请快，但具体时间以官方通知为准。