3 天备齐 60 页源码文档：一次软著材料交付记录

这是一次软著申报材料的交付复盘。项目本身不大，但源码散、文档缺、历史版本多，材料整理占用的时间远超预期。这里记录三个卡点与对应的处理方式，供准备自己动手的人参考。

问题不是「没有代码」，是「没有整齐的材料」

项目托管在三个位置：本地主力分支、一台服务器上的部署副本、一个早期压缩包。真正提交用的源码要回答的是三个问题——哪个版本是最终版、源码总量是否达到登记要求、文档与源码是否对得上。

这三个问题不解决，后面每一步都会返工。

三个卡点与处理方式

一、版本不唯一。 三份代码看起来都能跑，但功能有差异。处理方式：先确定唯一最终版（以线上运行的那份为准），其余两份标注归档，不进入材料。用软著通整理源码文档时，只对它做一次完整扫描，避免把旧版本的功能页混进文档。

二、源码页数不足。 登记对源码页数有下限要求，项目实际代码量差一截。处理方式：补齐项目历程中真实存在的功能代码与必要注释，而不是凑行数——灌水的文档在审核环节更容易被要求说明。软著通在生成源码文档时会按申报格式分页，先看页数缺口在哪，再有针对性地补内容。

三、文档与源码对不上。 说明书里写的能力，源码里找不到对应实现；源码里有的模块，说明书没提。处理方式：以源码为唯一起源反推文档，说明书写「做了什么」，不写「计划做什么」。这一步是退回风险最集中的地方。

结果

三天内材料齐备并提交：源码文档约 60 页，说明书与源码逐项对应。整个过程中最省时的部分恰好是最机械的部分——分页、格式、页码与目录，这些由软著通按申报格式自动生成，人工只需要核对内容本身。

最终登记结果以中国版权保护中心审核为准。