软著鉴别材料代码文档模板：APP、小程序、H5 一次过审排版指南

简介：这份资源是面向软件著作权申请者的鉴别材料模板，适用于APP、小程序、H5及Vue、Web管理系统等各类软件项目的软著申报场景，帮助开发者解决材料格式不统一、代码文档整理繁琐的问题。压缩包内共1个docx文件，约103KB，以文档形式提供软著申请所需的代码与文档模板，可直接参照填写。内容预览显示模板包含智悦电子班牌管理系统V1.0的登录页源码片段，涵盖HTML结构、Vue打包资源引用、CSS动画样式等典型前端代码，可作为代码鉴别材料的组织范例。目前已有236人学习下载，适合初次申请软著、需要规范整理鉴别材料的开发者参考，能帮助快速理解材料编排逻辑，减少反复修改的成本。

1. 软著鉴别材料到底交什么：从一份被退回三次的文档说起

软件著作权申请里最容易被低估的环节，不是填表，而是那份“鉴别材料”。我见过一个做小程序商城的朋友，功能代码写了小半年，提交软著时随手把几个核心页面截图拼了个 Word 就交上去，结果连续被退回三次，理由分别是“文档与代码不对应”“页数不足”“格式不符合要求”。他后来才明白，软著鉴别材料不是走个形式，审查员是真的会翻你交的东西，看它能不能证明“这套软件确实存在、确实是你写的”。

这篇要讲的就是软著代码文档模板这件事，覆盖 APP、小程序、H5 以及各类 Web 应用。核心解决三个问题：鉴别材料到底该交哪些内容、代码文档怎么排版才不会被挑刺、不同技术栈（前端页面、后端接口、移动端）在模板里怎么组织。适合正在准备软著申请、被退回后想搞清楚原因、或者想一次性把材料做规范的开发者。下面按“先搞懂规则，再动手排版，最后避坑”的顺序讲透。

2. 鉴别材料的两种形态与选型：源代码文档和用户操作手册怎么选

软著申请时，鉴别材料通常有两种提交方式：一种是源代码文档，一种是用户操作手册（也叫设计说明书）。很多人纠结到底交哪个，其实规则里两者可以都交，也可以只交一种，但不同选择对应的准备成本差别很大。这一章先把选型逻辑讲清楚，再给出两种文档的具体排版参数。

2.1 源代码文档和操作手册的适用场景对比

源代码文档的本质是“证明代码是你写的”，它直接呈现程序逻辑；操作手册的本质是“证明软件能跑起来”，它呈现的是功能界面和操作流程。审查员看源代码文档时关注代码的连续性、页眉页脚是否规范、前后是否对应；看操作手册时关注截图是否清晰、功能描述是否完整、有没有和申请表里的软件名称对得上。

选型上有个朴素的经验：如果你的软件界面丰富、交互复杂（比如小程序、APP），操作手册更容易做，因为截图本身就是证据；如果你的软件偏后台、偏算法、界面很少（比如一个数据处理服务、一个 Web 后端），那源代码文档更合适，因为截图凑不出足够页数。常见做法是两者都准备，但以其中一种为主，另一种作为补充。

需要说明的是，页数要求各受理机构可能略有差异，提交前最好按当地最新要求核对，不要照搬旧经验。

2.2 源代码文档的排版参数：页眉、页脚、字号、行距

源代码文档最容易翻车的地方不是代码本身，而是排版。审查员拿到一份文档，第一眼看的是页眉有没有软件名称和版本号，第二眼看的是页码连不连续，第三眼才看代码内容。我一般会按下面这套参数来排：

• 页眉：左侧写软件全称 + 版本号，右侧写“源代码”字样，字号小五或五号
• 页脚：居中放页码，格式用“第 X 页 共 Y 页”
• 正文字体：宋体或 Courier New，字号五号，行距固定值 12 到 14 磅
• 代码缩进：保留原始缩进，不要为了省页数把缩进删掉
• 每页行数：控制在 40 到 50 行，太密审查员看着累，太疏页数不够

这里有个细节：源代码文档要求提交前 30 页和后 30 页，如果总代码量不足 60 页，就全部提交。所以代码量少的项目，反而要保证每一页都排得规整，不能出现大片空白。

2.3 操作手册的截图规范与功能描述写法

操作手册的核心是“图 + 文”对应。每一张截图下面要有一段文字说明，讲清楚这个界面是干什么的、用户在这里能完成什么操作。截图有几个硬要求：分辨率要够，不能糊；界面里不能出现测试数据里的敏感信息；截图顺序要和功能流程一致，不能东一张西一张。

功能描述我一般按“入口 → 操作 → 结果”三段式写。比如一个登录功能，先写“在首页点击右上角登录按钮进入登录页”，再写“输入账号密码后点击登录”，最后写“登录成功后跳转到个人中心，页面顶部显示用户昵称”。这样审查员顺着读下来，能清楚看到功能是完整的。

提示：操作手册里的软件名称、版本号必须和申请表、源代码文档里的完全一致，一个字都不能差，这是最常见的退回原因之一。

3. 从零做一份源代码文档：抽取、排版、导出的完整流程

选好了交源代码文档，接下来就是动手做。这一章给一套可复现的流程，从代码抽取到最终导出 PDF，每一步都落到具体操作。中间会涉及一个用 Python 做代码合并与分页的小脚本，适合代码文件分散在多个目录的情况。

3.1 代码抽取策略：抽哪些文件、按什么顺序排

不是所有代码都值得放进鉴别材料。我的原则是：抽核心业务逻辑，不抽第三方库、不抽自动生成的代码、不抽配置文件里的密钥。具体来说，优先抽这几类文件：

• 入口文件（如 main 函数、路由注册文件）
• 核心业务处理文件（如订单、支付、用户模块）
• 关键算法或工具类文件
• 数据模型定义文件

排序上按“入口 → 路由 → 业务 → 工具”的逻辑走，让审查员能顺着读出一个完整的调用链。如果项目是前后端分离的，可以先放后端接口定义，再放前端调用逻辑，这样对应关系更清楚。

3.2 用脚本合并代码并自动分页

代码文件多的时候，手动复制粘贴到 Word 里再调格式，效率极低还容易出错。我一般写个小脚本先把代码合并成一个带分页标记的文本，再导入 Word。下面这个脚本做三件事：遍历指定目录下的代码文件、按扩展名过滤、合并输出并每 45 行插入一个分页标记。

import os # 要抽取的代码文件扩展名 CODE_EXTS = ('.py', '.js', '.java', '.vue', '.ts') # 每页行数，和 Word 排版参数保持一致 LINES_PER_PAGE = 45 # 代码根目录 SRC_DIR = './src' # 输出文件 OUT_FILE = './merged_code.txt' def collect_files(root): """按目录顺序收集代码文件，保证排序稳定""" result = [] for dirpath, dirnames, filenames in os.walk(root): # 跳过依赖目录和构建产物 dirnames[:] = [d for d in dirnames if d not in ('node_modules', 'dist', 'build', '__pycache__')] for name in sorted(filenames): if name.endswith(CODE_EXTS): result.append(os.path.join(dirpath, name)) return result def merge(files): line_count = 0 with open(OUT_FILE, 'w', encoding='utf-8') as out: for path in files: out.write(f'// ===== File: {path} =====\n') line_count += 1 with open(path, 'r', encoding='utf-8', errors='ignore') as f: for line in f: out.write(line) line_count += 1 # 达到每页行数就插入分页标记 if line_count % LINES_PER_PAGE == 0: out.write('\n<<<PAGE_BREAK>>>\n') print(f'合并完成，共 {line_count} 行') if __name__ == '__main__': files = collect_files(SRC_DIR) merge(files)

逻辑说明：collect_files用os.walk遍历目录，通过dirnames[:]原地过滤掉依赖目录，避免把第三方库代码混进来；sorted(filenames)保证同一目录下文件顺序稳定，不会因为文件系统顺序不同导致每次合并结果不一样。merge函数在写入每个文件前加一行文件路径注释，方便审查员对照；每累计 45 行插入一个分页标记，导入 Word 后可以用查找替换把标记换成真正的分页符。

参数说明：CODE_EXTS按你的技术栈改，小程序可以加.wxml、.wxss，H5 可以加.html、.css；LINES_PER_PAGE要和 Word 里的行距设置匹配，如果你在 Word 里设的是每页 50 行，这里就改成 50；SRC_DIR指向你的源码根目录，注意不要指向包含node_modules的目录，虽然脚本会过滤，但遍历本身会变慢。

3.3 导入 Word 后的排版收尾与导出 PDF

脚本输出的文本导入 Word 后，还有几步收尾要做。先把<<<PAGE_BREAK>>>替换成分页符，然后统一设置字体和行距，再插入页眉页脚。页眉里写软件名称和版本号，页脚里插页码。做完这些，用 Word 的“导出为 PDF”功能生成最终文件，不要直接交 docx，因为不同电脑打开 docx 可能排版错位。

导出前建议通读一遍，重点看三处：分页符位置有没有把一行代码从中间截断、页眉页脚有没有从第一页就开始显示、代码里有没有出现真实的密钥或密码。这三点是审查员最容易挑出来的问题。

4. 小程序、APP、H5 三类项目的模板差异与适配

不同技术栈的项目，鉴别材料的组织方式差别不小。这一章分别讲小程序、APP、H5/Web 三类项目在模板上的适配要点，每类给出具体的文件清单和排版建议。

4.1 小程序项目：页面文件与逻辑文件的配对呈现

小程序的特点是页面由多个文件组成（.wxml、.wxss、.js、.json），如果按文件类型分开排，审查员读起来会很割裂。我的做法是按页面配对呈现：一个页面的四个文件连续放，先放结构文件，再放样式，再放逻辑，最后放配置。这样审查员能看到一个页面从结构到逻辑的完整实现。

文件清单上，优先抽首页、核心功能页、个人中心页这几个页面，再加上app.js和app.json。工具类文件如果不多，可以放在最后。需要注意的是，小程序代码里经常有wx.开头的 API 调用，这些是正常业务代码，不用删，但要把测试用的console.log清理掉，保持代码整洁。

4.2 APP 项目：按模块划分代码章节

APP 项目代码量大，如果按文件顺序平铺，前 30 页可能还在工具类里打转。更合理的做法是按模块划分章节，每个模块下放该模块的界面代码、逻辑代码和数据模型。比如一个电商 APP，可以分成“首页模块”“商品模块”“订单模块”“个人中心模块”，每个模块内部再按文件类型排。

模块划分的好处是审查员能快速看到软件的功能覆盖面。如果某个模块代码特别多，可以只抽核心文件，在文档里用注释说明“此处省略部分重复代码”，但省略不能太多，否则会被认为代码不完整。

4.3 H5 与 Web 项目：前后端代码的章节切分

H5 和 Web 项目通常前后端分离，鉴别材料里如果只放前端或只放后端，都会显得单薄。我一般把文档分成两大部分：前端部分放页面组件、路由配置、状态管理；后端部分放接口定义、业务逻辑、数据模型。两部分之间用明显的章节标题隔开，比如“第一部分 前端代码”“第二部分 后端代码”。

如果后端代码量远大于前端，可以前端全放，后端只抽核心接口。反过来也一样。关键是让审查员看到这是一个完整的、能跑通的系统，而不是半截代码。

5. 避坑与排查：鉴别材料被退回的五个高频原因

这一章是我自己和身边人踩过的坑，按“现象 → 原因 → 解决”整理成五条。每一条都对应一个具体的退回理由，照着排查能省下不少来回修改的时间。

5.1 现象：审查员说“文档与代码不对应”

原因通常是申请表里填的软件名称、版本号，和文档页眉、代码注释里的不一致。比如申请表写的是“XX 商城系统 V1.0”，文档页眉写的是“XX 商城 V1.0.0”，多了个小数点版本号，就可能被挑出来。

解决：提交前把所有出现软件名称和版本号的地方列一个清单，逐一核对。包括申请表、源代码文档页眉、操作手册封面、截图里的标题栏。统一成一个写法，不要有的地方带“系统”有的地方不带。

5.2 现象：页数不够被要求补交

原因有两种：一种是代码量本身少，另一种是排版太稀疏，一页没放几行。代码量少的情况，可以把操作手册也交上，用截图补足页数；排版稀疏的情况，调整行距和字号，把每页行数提到 45 到 50 行。

解决：先算一下总代码行数，除以每页行数，看能不能凑够 60 页。如果差得不多，调排版；如果差得多，补操作手册。不要为了凑页数把无关代码塞进去，审查员看得出来。

5.3 现象：截图模糊或包含敏感信息

原因通常是截图时用了缩放，或者截图里带了测试账号、真实手机号、服务器地址。这些信息一旦交上去，轻则退回，重则涉及信息泄露。

解决：截图用原始分辨率，不要缩放；截图前把测试数据换成假数据，手机号用 13800000000 这种明显是占位的号码，服务器地址用 localhost 或示例域名。截完图放大检查一遍，确认没有敏感信息再插入文档。

5.4 现象：代码里出现第三方库或自动生成代码

原因是抽取时没过滤node_modules、dist、vendor这类目录，把第三方库代码也放进去了。审查员看到大段不是申请人写的代码，会质疑材料的真实性。

解决：抽取前先确认目录结构，把依赖目录和构建产物排除掉。如果不确定某个文件是不是自动生成的，看文件头有没有“此文件由 XX 工具生成”之类的注释，有就排除。

5.5 现象：分页符把一行代码从中间截断

原因是脚本按固定行数插入分页标记，没有考虑代码行的完整性。一行代码被分成两页，审查员读起来会认为排版不认真。

解决：导入 Word 后，把光标移到分页符前，看下一行是不是完整的代码行。如果是被截断的，手动把分页符往前或往后挪一行。这个工作有点繁琐，但比被退回重做要快。

注意：不同受理机构对鉴别材料的具体要求可能有细微差异，提交前务必按最新要求核对，本文参数作为通用参考。

6. 让材料一次过审的几个实操习惯

做软著鉴别材料这件事，技术含量不高，但细节密度大。我做了几份之后，养成了一个习惯：在动手排版之前，先把申请表填好，把软件名称、版本号、功能描述定下来，然后再开始做文档。这样文档里的所有信息都有唯一来源，不会出现前后不一致。

另一个习惯是留一份“对照表”。用一张表格记录每个章节对应哪些代码文件、每个截图对应哪个功能点。提交前拿着这张表逐项核对，比通读一遍文档更高效。这个习惯帮我省下了至少两次退回重做的时间。

最后一个习惯是导出 PDF 后，用手机打开看一遍。手机屏幕小，排版问题会被放大，页眉页脚错位、代码换行异常、截图模糊这些问题在手机上特别明显。电脑上看着没问题，手机上可能就露馅了。这个土办法虽然简单，但确实管用。

希望帮到你。

本文还有配套的精品资源，点击获取