先划清一条线：软著审查看的是材料与软件是否对应、材料之间是否自洽，不看你是怎么把文档敲出来的。所以 AI 用来整理格式、搭文档结构、做一致性校对，没有问题；用 AI 虚构软件功能、编造不存在的模块和代码，那就是材料不实，风险很大。
审查真正在看什么
审查环节关注的是三份材料能不能互相印证：申请表里的名称版本日期、源程序里的实际代码、文档里描述的功能。如果文档写了一个系统具备智能推荐、数据分析、多端同步等一堆功能，而源代码里找不到对应实现，这就是典型的不一致，会被要求补正甚至更严重的处理。
换句话说，材料的可信度来自内部一致性，而不是文笔好坏。写得再漂亮，对不上代码一样过不了。
AI 能用的地方
- 生成说明书的目录结构和章节骨架，省掉从零列提纲的时间；
- 把散落的操作步骤整理成连贯的段落，语句更通顺；
- 批量做格式统一：页眉页码、字号行距、图表编号；
- 一致性校对：全文搜名称版本，找出前后不一致的地方；
- 把代码里的模块名、文件结构提取成功能清单，作为写文档的输入。
不能碰的地方
不能让 AI 无边无际地补功能。常见的事故是：开发只做了一个后台管理系统，文档里却写成了包含 App、小程序、数据大屏的完整解决方案。这种材料一提交就等着补正，因为源程序里根本没有对应代码。
也不能用 AI 生成代码来凑页数。审查方看到一个功能完整但不属于这个软件主体的代码块，比页数不够更麻烦。
| 场景 | 可以做 | 不要做 |
|---|---|---|
| 文档结构 | 生成章节骨架、整理语句 | 虚构不存在的功能模块 |
| 功能描述 | 按真实代码提炼模块说明 | 按行业套话写一堆没实现的功能 |
| 源代码 | 清理格式、统一页眉页码 | 生成不属于本项目的代码凑页数 |
| 一致性 | 全文检索名称版本字段 | 让工具替你决定权属和日期 |
| 截图 | 整理真实运行截图 | 用原型图或生成的示意图替代 |
一个稳妥的做法
- 先列功能清单，清单只写代码里真实存在的模块，一句话一个功能。
- 把清单作为约束交给整理工具或助手，要求文档只围绕这些功能展开，不要补充。
- 生成的文档自己通读一遍，逐条对照代码确认，删掉任何对不上的描述。判断标准是每个功能都能指出对应的文件或类。容易出错的地方是看着顺眼就放过。
- 统一名称版本和页眉页码，导出 PDF 复核。
- 保留一份材料与代码的对应记录，日后被问到时能立刻说清。
这套流程的本质是把 AI 限制在文字加工的范围内，事实由人提供。软著Pro 是按这个边界设计的：它负责把真实的功能清单转成规范文档、批量出页眉页码、做一致性自查，判断权仍在申请人手里，网址是 https://ruanzhu.pro。
常见问题
用 AI 整理材料会被发现吗
问题不在于被发现用了什么工具，而在于材料是否和软件真实情况一致。不一致才是风险来源。
文档全是 AI 写的会不会有问题
文本来源不是审查重点，内容与代码不匹配才是。功能描述必须来自真实实现。
用工具生成的说明书能直接用吗
可以作为初稿，但必须核对功能是否真实存在，截图是否来自本软件，不要原样提交。
代码能不能让工具生成一部分
不建议。提交的代码应当是软件实际运行的代码，混入生成的代码会造成功能与代码不符。
审核方会核对代码和文档吗
会做一致性比对，尤其是文档里强调的核心功能，所以两边必须对得上。
材料不实会有什么后果
轻则反复补正拉长周期，重则影响登记结果。材料真实是底线，不要在这上面省事。
审查标准以中国版权保护中心当期公布的要求为准。
