软著补正提示“文档鉴别材料AIGC检出率高”怎么办？独创性证明材料及处理方法及华代建议。
近期，部分软件著作权普通申请在提交后，收到了一类新的补正意见：
“提交的文档鉴别材料AIGC检出率高，如果此申请未遵守申请确认签章页中的声明及承诺，建议回此申请。如非此类情况，请修改文档鉴别材料的同时，在其他相关证明文件处提交独创性真实开发的证明文件，如源程序文件目录结构，每个文件附哈希值，项目研发日志，代码版本管理记录，PR审核记录，第三方测试报告等，或来电沟通作出合理解释说明。”
与过去比较常见的“文档雷同”“鉴别材料重复”相比，这一轮补正出现了一个比较明显的新变化。
审核重点已经不仅是源代码和说明书本身，还开始要求申请人进一步证明软件存在真实、连续、可验证的研发过程。
如果您还没有准备软件著作权申请材料，可以使用：网弧软著项目生成平台，在线生成软件项目及对应的软著申请材料。
对于通过网弧平台生成的项目，如果后续收到“AIGC检出率高”“要求提供独创性真实开发证明”等补正，平台可根据该项目实际生成内容提供对应的补正和证明材料支持。
如果软件项目并非由网弧平台生成，我们不提供该项目的独创性真实开发证明材料。因为目录结构、文件哈希、研发日志、版本管理记录等证明必须建立在能够核验的实际项目基础上，不能脱离真实项目情况制作。
1. “文档鉴别材料AIGC检出率高”是什么意思？
这里所说的文档鉴别材料，通常涉及软件著作权申请过程中提交的软件说明书、操作手册以及其他用于说明软件功能、界面和业务流程的材料。
首先需要明确一点：
收到“AIGC检出率高”的补正，并不能简单等同于材料质量差，也不能直接说明这个软件不是真实开发。
目前的软件开发环境已经发生了很大变化，代码补全、智能IDE、AI辅助排错、文档润色等工具已经非常普遍。而且不同类型的软件本身也会存在大量相似的软件工程表达，例如用户管理、权限管理、数据列表、统计分析等。
因此，“AIGC检出率高”更适合理解为：当前提交的鉴别材料触发了进一步真实性审查，需要申请人提供更多资料解释软件是如何开发出来的。
从此次补正文字来看，真正需要解决的是两个问题：
申请材料是否与实际软件相符。说明书中的页面、功能、数据流程能否和实际软件及源代码对应。
是否能够证明软件存在真实研发过程。例如源程序目录、文件哈希、Git记录、研发日志、PR记录、测试资料等。
所以，这种补正并不是简单进行一次所谓的“AI降重”就一定能够解决。
2. 我们的一个观察：出现该补正不一定代表材料质量不行
结合近期我们接触到的申请情况，有一个现象值得申请人注意。
近期普通软件著作权申请出现AIGC、独创性证明、真实性核验等补正的频率有所提高。
根据近期实际案例，我们有一个非官方的判断和推测：
当前审核可能正在通过提高普通申请的审核强度、增加补正和真实性核验等方式，对普通申请的整体下证节奏和下证率进行一定控制。
这里必须强调：这是我们根据近期实际申请情况作出的经验性推测，并非版权登记机构公开发布的政策，也不代表官方结论。
因此，如果以前使用类似质量的材料能够正常下证，而近期突然收到“AIGC检出率高”“需要提供独创性证明”等补正，并不能直接说明此次材料质量一定有问题。
更可能的情况是，当前普通申请的整体审核尺度、真实性核验要求和下证节奏发生了变化。
3. 对下证时间有要求，可以考虑华代
如果只是正常申请，对下证时间没有特别严格的要求，可以继续按照普通申请流程，根据补正意见准备真实的软件研发证明材料。
但是，如果软件著作权用于：
项目招投标；
高新企业申报；
项目验收；
学校或科研项目结题；
企业资质申报；
其他具有明确时间节点的业务。
那么就不建议单纯以“继续等待普通申请审核”作为唯一方案。
根据我们近期实际办理情况，华代目前整体下证表现相对更加稳定，下证率也相对较高。
如果对下证时间有明确要求，可以优先考虑华代。
华代申请详情：https://www.webarcx.com/detailsPage/587
需要说明的是，无论普通申请还是华代，都不能理解为“绝对保证下证”。最终仍然取决于软件本身、申请材料及实际审核结果。
4. 为什么这次补正开始要求“独创性真实开发证明”？
过去准备软件著作权申请材料，申请人通常重点关注两类文件：
源程序鉴别材料；
软件说明书或操作手册。
但从此次补正内容来看，审核思路正在出现明显变化。
补正通知已经直接列举了：
源程序文件目录结构；
每个文件的哈希值；
项目研发日志；
代码版本管理记录；
PR审核记录；
第三方测试报告。
也就是说，审核人员现在关注的不只是“提交了什么代码”，还开始关注“这些代码是怎样一步一步开发出来的”。
相比一份静态的源程序材料，能够反映项目实际研发过程的完整证据链，可能具有更高的解释价值。
5. 哪些材料可以用于证明软件是真实开发的？
5.1 源程序文件目录结构
可以根据实际源码整理完整或部分项目目录结构，例如：
project/ ├── src/ │ ├── controller/ │ ├── service/ │ ├── model/ │ ├── repository/ │ └── utils/ ├── config/ ├── tests/ ├── package.json └── README.md
目录结构可以辅助说明软件具有真实的软件工程组织形式，而不是只有少量零散代码文件。
目录应当根据真实源码生成，不建议为了补正临时增加或者虚构不存在的文件和模块。
5.2 每个源程序文件附哈希值
此次补正意见中特别明确地提出了“每个文件附哈希值”。
例如可以针对实际项目源文件生成SHA-256：
src/service/UserService.java SHA-256: 8c78xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
文件哈希的主要作用，是固定某个时间点文件的具体状态。
如果源代码目录、文件哈希、Git提交记录和研发日志能够互相对应，其证明力显然比只提交一份源代码截图或者打印材料更完整。
当然，哈希值本身并不能单独证明软件一定属于原创。
5.3 项目研发日志
研发日志可以记录软件实际研发过程，例如：
项目启动；
需求分析；
数据库设计；
核心模块开发；
接口联调；
BUG修复；
测试；
版本发布。
真正有价值的研发日志不是篇幅越长越好，而是时间、功能、代码和版本之间能够相互对应。
5.4 Git、SVN等代码版本管理记录
如果实际开发过程中使用了Git、GitLab、GitHub、Gitee、SVN或者企业内部代码管理系统，可以提供真实的版本管理记录。
相比静态代码，版本管理历史能够显示软件从无到有、持续迭代的过程。
不建议为了补正而伪造Git历史。所有证明材料都应该建立在实际项目基础上。
5.5 PR、Merge Request和Code Review记录
如果属于多人协作开发项目，并且真实存在PR、Merge Request或者代码审核记录，也可以作为辅助证明。
可以包括：
PR提交时间；
代码提交人；
审核人员；
修改模块；
审核意见；
最终合并时间。
5.6 测试报告及测试记录
如果软件实际进行过功能测试、安全测试、兼容性测试或者第三方软件测试，也可以提交相应真实资料。
测试材料主要能够辅助证明，在某一个时间点，这个软件已经实际形成，并进入了可运行、可测试的状态。
但测试报告不能单独等同于“原创证明”，仍然建议配合源码和版本管理材料使用。
6. 收到AIGC检出率高补正后，应该怎么处理？
我们建议不要只是把说明书重新改几个句子就再次提交。
可以分三个步骤处理。
第一步：检查当前说明书和软件是否对应
重点检查：
说明书功能是否真实存在；
页面截图和功能介绍是否对应；
功能模块和源程序是否对应；
软件名称是否全文统一；
是否存在大量模板化、空泛描述。
第二步：重新整理鉴别材料
说明书应该尽量按照软件真实使用过程描述，而不是单纯追求所谓的“降低AI率”。
例如不要整篇都是：
“本模块旨在为用户提供高效、便捷、智能化的操作体验……”
更建议直接描述：
用户在哪个页面操作；
填写哪些字段；
点击什么按钮；
系统进行什么处理；
最后产生什么业务结果。
真实的软件细节越多，材料通常也越具有项目自身特征。
第三步：补充真实开发证明
如果已经明确要求提供独创性真实开发证明，可以围绕：
目录结构 → 文件哈希 → Git版本记录 → 研发日志 → PR记录 → 测试材料
建立一套相互对应的研发证据链。
如果项目是自己开发或由其他开发团队完成，应当由实际开发方根据真实项目情况整理上述材料。
7. 网弧生成的项目，可以一键自助补正并申请证明材料
如果您的软件项目本身就是通过：
网弧软著项目生成平台：https://www.webarcx.com/
生成的，那么在项目后续申请过程中遇到“AIGC检出率高”“需要提供独创性真实开发证明”等补正时，可以直接在平台针对原项目进行一键自助补正，并申请对应的项目证明材料。
针对网弧生成的实际项目，可以根据项目已有数据和源码整理包括：
源程序目录结构；
源程序文件哈希清单；
项目研发日志；
代码版本管理记录；
PR或代码审核类证明材料；
项目开发过程说明；
补正后的软件说明书及鉴别材料。
以上证明材料仅针对网弧平台实际生成的项目提供。
如果软件并非通过网弧平台生成，我们无法核验该项目真实的源码形成过程、文件历史、研发时间和版本记录，因此不提供第三方项目的独创性真实开发证明材料。
这样做的目的也是为了保证证明材料能够与实际项目对应，而不是为了补正临时制作一套无法核验的研发记录。
8. 如果补正意见已经“建议撤回”，怎么办？
如果收到的补正意见已经明确包含“建议撤回此申请”，首先应当判断当前项目是否还适合继续补正。
对于使用网弧项目生成服务的用户，如果遇到符合条件的“建议撤回”情况，目前平台也提供相应的售后补偿政策。
可以将补正通知提供给客服，由客服根据对应订单和实际情况确认处理方案。
如果已经出现建议撤回，建议先联系网弧客服核实是否符合补偿政策，不要直接重复购买或反复提交相同材料。
后续可以根据实际情况决定：
继续补正；
重新生成或整理材料；
撤回后重新申请；
改用华代申请。
9. 要不要拨打补正通知中的010电话？
此次补正通知还提供了联系电话，并允许申请人通过电话进行合理解释。
但是，我们并不建议所有收到补正的人都立即拨打电话。
如果可以非常明确地确认软件属于真实自主开发，代码和申请材料的形成过程也能够完整解释，并且申请内容符合申请确认签章页中的声明及承诺，那么电话沟通可以作为了解具体审核要求的一种方式。
但如果软件开发或者申请材料制作过程中确实使用过AI工具，或者自己无法确认实际情况是否完全符合签章页中的声明及承诺，不建议在没有核实清楚之前贸然拨打电话进行解释。
因为工作人员可能会进一步询问：
软件是什么时候开始开发的；
由谁开发；
代码如何形成；
说明书由谁制作；
为什么出现较高AIGC检测结果；
是否存在AI生成或者辅助开发；
有哪些资料能够证明实际研发过程。
如果这些情况自己都没有核实清楚，电话解释反而可能增加处理难度。
更重要的是，不应为了通过申请而作出与真实情况不一致的说明。
10. 软件开发过程中使用过AI怎么办？
这一问题现在越来越常见。
如今软件开发人员实际工作中可能会使用：
AI代码补全；
智能IDE；
AI辅助排查BUG；
AI生成部分基础代码；
AI辅助撰写文档。
因此，“使用过AI工具”和“完全由AI生成一个软件”显然不是完全相同的概念。
但是对于具体申请而言，最重要的还是申请确认签章页中的声明及承诺。
如果实际项目情况与申请人已经作出的声明存在冲突，就不应该单纯通过改写材料、降低AIGC率或者补做证明文件来掩盖真实情况。
这种情况下，应当首先评估当前申请是否适合继续。
11. 这类补正最容易踩的几个坑
第一，只盯着所谓的“AIGC率”。
这次审核已经明显延伸到了研发真实性，仅仅做文字改写可能并不能解决问题。
第二，认为收到补正就一定是材料质量差。
目前普通申请整体审核尺度可能正在提高，同一质量水平的材料，在不同时期可能面临不同的审核要求。
第三，临时伪造Git记录、研发日志。
一旦多份资料之间出现明显时间冲突，反而可能进一步影响材料可信度
