材料总览
软著独创性证明材料怎么准备？真实开发记录与补正清单
CCopyright 编辑团队内容核对：非官方指南
这份指南面向已经收到真实性、独创性或研发过程相关补正意见的申请人。先看通知提出了什么问题，再选择能解释事实的已有资料，避免为了凑齐清单重复制作无关材料。
整理开发资料先分清：常规申请材料与补充证明
《计算机软件著作权登记办法》第 9—11 条分别涉及申请表、程序和文档的鉴别材料，以及相关证明文件。登记机构要求补正时，还可能需要申请人就具体问题作出说明。
本轮查阅的公开案例解读提到了文件目录、哈希、研发日志、版本记录、PR 审核和第三方测试报告。这是问题场景线索，不足以推出“2026 年所有申请新增六项必交材料”。
让材料回答具体问题
目录、历史、审核和测试资料说明的是不同事实。以同一个软件名称、版本和源码快照为主线，记录它们之间的对应关系。
| 需要说明的问题 | 可以核对的已有资料 | 需要说明的边界 |
|---|---|---|
| 提交了哪些源文件 | 源程序目录、文件清单、逐文件哈希 | 不等同于源程序鉴别材料正文 |
| 功能怎样逐步形成 | Git/SVN 历史、研发日志、需求或问题记录 | 没有记录的阶段不能靠推测补齐 |
| 改动是否经过评审 | 实际 PR/MR、评论、评审状态和合并记录 | 提交记录或 CI 成功不等于人工审核 |
| 某版本是否进行过测试 | 测试用例、运行结果、实际第三方报告 | 测试结论不直接等于原创性或权属结论 |
按四步整理，而不是重新编造开发过程
先逐项摘录自己的补正问题，保留通知原文，再建立材料索引。无需在公开网页或咨询评论中暴露申请号、手机号和完整源码。
- 固定核对版本：记录软件名称、版本号、仓库或源码包标识。
- 收集已有资料：源码、提交历史、需求记录、PR、测试结果分别保存原件。
- 建立对应关系：每项说明引用文件路径、提交号、记录链接或报告页码。
- 复核并说明缺失：区分原始历史记录与今天依据资料整理的说明稿。
收到“AIGC 检出率高”意见时如何处理
先确认通知针对文档、程序还是声明事项。核对说明书中的功能、截图与实际软件是否一致，再检查申请表和签章页的具体要求。
真实存在的 AI 使用情况应按实际说明。改写措辞、制造提交历史或添加不存在的审核人，不能解决事实不一致的问题。本专题不提供降低检测率或保证登记通过的承诺。
补正期限不要套用网上的统一天数
公开办法第 22 条载明应当在 30 日内补正，逾期未补正的，视为撤回申请。办理时应核对收到的通知、期限起算及适用的延期安排；如通知与一般介绍不同，及时向办理机构确认。
将问题、对应修改、附件名称与位置列成答复清单，先完成材料一致性检查，再按通知指定入口提交。
常见问题
软著独创性证明材料必须六项全部提交吗？
本轮核对的公开办法没有将这六项列为所有申请人的统一必交清单。应按实际通知的问题和要求选择材料，不把商业文章中的案例清单当作统一规定。
没有 Git、PR 或研发日志怎么办？
如实说明缺失情况，整理现有源码、需求文档、测试记录和交付资料，并向办理机构确认是否需要其他说明。事后整理稿应注明整理时间和资料来源，不伪装成当时形成的记录。
材料预审或整理工具能保证通过吗？
不能。工具帮助整理、核对和发现缺项，不能代替登记审查，也不能仅凭上传的数据独立鉴定真实性或权属。
依据与资料来源
- 国家版权局：《计算机软件著作权登记办法》
第 9—11 条说明申请材料；第 22 条说明补正期限。
- 公开补正案例解读（网弧软著，非官方）
仅用于说明公开讨论中的问题场景，不作为统一必交材料的依据。