SoftwareCopyright-Skill 软著鉴别材料规则全解析：前后 30 页代码选材、90 列折行与 Word 自动分页实战

AI 技能文档【免费下载链接】SoftwareCopyright-Skill中国软件著作权申请材料 生成器 Skills本 Skills 通过阅读本地项目自动生成全套 .docx 软著申请材料全开源无须再付费购买任何软著申请服务项目地址https://gitcode.com/gh_mirrors/so/SoftwareCopyright-Skill点击查看免费下载本文围绕software-copyright-materials的参考资料 copyright_material_rules.md 展开系统拆解中国软件著作权登记中“程序鉴别材料”的合规规则以及开源仓库 SoftwareCopyright-Skill 如何把这些规则落地为可执行、可校验的自动化流程。读完本文你将掌握软著代码材料的前后各 30 页规则与不足 60 页时的替代方案代码正文 8pt/13pt 行距、每页约 55 物理行的选材估算逻辑90 显示列确定性折行的实现细节以及为何 Markdown 页分组不等于 DOCX 硬分页、最终页数必须交给 Word 排版引擎校准这一关键设计。一、鉴别材料规则源程序与文档的前后 30 页要求依据《计算机软件著作权登记办法》第十条软件鉴别材料分为程序鉴别材料与文档鉴别材料两类。程序鉴别材料即申请软件的源程序文档鉴别材料即说明书、用户操作手册等配套文档。该参考文档首先给出了四条基础执行规则源程序和文档一般由前、后各连续 30 页组成整个程序或文档不足 60 页时提交全部除特定情况外程序每页不少于 50 行除特定情况外文档每页不少于 30 行。这四句话是整个代码材料生成流程的“宪法”。SoftwareCopyright-Skill 的所有脚本设计都以满足这四条为最低目标extract_code_material.py中用SPLIT_THRESHOLD_PAGES 60表示 60 页阈值测试用例 test_workflow_integrity.py 也专门验证了“前 30 页/后 30 页模式下提交页数必须为 60”def test_submitted_pages_are_60_for_front_back_mode(self) - None: manifest {mode: front30_back30, total_pages: 143} self.assertEqual(submitted_code_page_count(manifest), 60)二、本 skill 的落地规则从法规到可执行参数1. 每页约 55 个物理行满足“每页不少于 50 行”代码正文使用8pt 字号、13pt 固定行距代码选材默认按每页约 55 个物理行估算。相关常量集中在 common.pyCODE_FONT_NAME Consolas CODE_FONT_SIZE 8pt CODE_LINE_SPACING 13pt CODE_LINES_PER_PAGE 55 CODE_MAX_COLUMNS 90关键理解55 行/页只是一个选材量估算值不是 DOCX 的硬分页边界。它用于决定“前 30 页/后 30 页”到底要抽取多少代码而不是在 Word 里强行塞满每页 55 行。生成完成后由 OfficeCLI/Word 重新读取真实页数并核对。分页估算在 extract_code_material.py 中实现纯按物理行数切块def paginate(lines: list[str], lines_per_page: int) - list[list[str]]: return [lines[i : i lines_per_page] for i in range(0, len(lines), lines_per_page)]2. 90 显示列确定性折行避免 Word 二次换行导致页数漂移代码中的制表符先按 4 个空格展开单行超过90 显示列时确定性折成多个物理行全角字符按 2 列计算。折行逻辑同样位于 extract_code_material.pydef display_width(text: str) - int: Return deterministic monospace display columns for Latin and CJK text. width 0 for char in text: width 2 if unicodedata.east_asian_width(char) in {W, F} else 1 return width def wrap_display_line(line: str, max_columns: int MAX_CODE_COLUMNS) - list[str]: Wrap one source line without dropping characters or relying on Word wrapping. if max_columns 8: raise ValueError(max_columns must be at least 8) expanded line.expandtabs(4) if not expanded: return [] segments: list[str] [] current: list[str] [] current_width 0 for char in expanded: char_width 2 if unicodedata.east_asian_width(char) in {W, F} else 1 if current and current_width char_width max_columns: segments.append(.join(current)) current [] current_width 0 current.append(char) current_width char_width if current: segments.append(.join(current)) return segments设计意图很明确如果长行交给 Word 自动换行Word 按自身字体度量换出的折点与 Python 按“等宽 90 列”估算的折点不一致就会造成实际页数与选材估算页数漂移。为此脚本在抽取阶段就完成确定性折行每个物理行后续在 DOCX 中对应一个段落Word 不会再因代码宽度二次换行。对应测试在 test_code_layout.py 中逐条锁定了行为def test_display_width_counts_cjk_as_two_columns(self) - None: self.assertEqual(display_width(abc中文), 7) def test_long_line_wrap_preserves_all_characters(self) - None: source const value (中 * 70) (x * 80) ; wrapped wrap_display_line(source, 100) self.assertGreater(len(wrapped), 1) self.assertEqual(.join(wrapped), source) self.assertTrue(all(display_width(line) 100 for line in wrapped)) def test_tabs_are_expanded_before_wrapping(self) - None: wrapped wrap_display_line(a\tb, 100) self.assertEqual(wrapped, [a b])3. 物理行连续写入 DOCX由 Word 排版引擎自动换页所有物理行连续写入 DOCX不插入人工分页符。Word 根据 A4 页面、页边距、字体和行距自动换页。DOCX 段落生成位于 build_docx_from_md.pydef code_paragraph_commands(pages: list[tuple[int, list[str]]]) - list[dict[str, Any]]: commands: list[dict[str, Any]] [] for _, lines in pages: for line in lines: commands.append({command: add, parent: /body, type: paragraph, props: { text: line if line else , font: CODE_FONT_NAME, font.ea: SimSun, size: CODE_FONT_SIZE, color: #000000, spaceBefore: 0pt, spaceAfter: 0pt, lineSpacing: CODE_LINE_SPACING, lineRule: exact, widowControl: false, wordWrap: false}}) return commands注意lineRule: exact13pt 固定行距、wordWrap: false段落内不换行因为行已在抽取阶段折好以及不设置pageBreakBefore。A4 页面与页边距则由 document_commands 统一写入代码材料使用1.8cm页边距21cm × 29.7cm 纵向页面。4. 60 页分档前 30 页 / 后 30 页 / 全部代码总页数分档逻辑在 extract_code_material.py总页数 60只输出前 30 页 后 30 页两份 Markdown代码-前30页.md、代码-后30页.md正式生成时对应软件全称-代码(前30页).docx与软件全称-代码(后30页).docx总页数 60只输出全部代码代码-全部.md→代码-全部.docx不为大项目输出全量代码 Word避免文件过大且不符合常规提交需求。if total_pages SPLIT_THRESHOLD_PAGES: front list(enumerate(pages[:30], start1)) back [(31 i, page) for i, page in enumerate(pages[-30:])] ... mode front30_back30 else: all_pages list(enumerate(pages, start1)) ... mode all_under_60_pages“后 30 页”的页码在草稿里从第 31 页起编号真实页码在 DOCX 中通过pageStart配置前 30 页文档从 1 编号后 30 页文档从 31 编号保证两份文档连起来是连续页码{command: set, path: /section[1], props: { pageWidth: 21cm, pageHeight: 29.7cm, orientation: portrait, ... pageStart: str(page_start)}},这里还有一个容易忽略的细节total_pages 60但候选清单里还有未选源码时抽取脚本会停止并要求用户补充选择而不是直接把不足 60 页的代码提交。见 extract_code_material.pyif total_pages SPLIT_THRESHOLD_PAGES and available_pages SPLIT_THRESHOLD_PAGES and unselected_count 0: raise SystemExit( STOP_FOR_USER\n fNEXT_ACTION: 当前已选代码只有 {total_pages} 页但候选源码足够补齐到 {SPLIT_THRESHOLD_PAGES} 页。 请在 草稿/代码文件选择.json 中继续选择补充文件重新记录 code-selection 门禁后再抽取。 )只有候选源码也用尽仍不足 60 页时才按规则生成全部代码材料。5. 代码材料必须来自项目源文件禁止 AI 编造代码材料必须来自项目源文件不能由 AI 生成。这是本 skill 区别于“模板套壳”服务的根本原则。真实性靠两层保障源码发现不依赖扩展名白名单common.py中is_source_candidate()用内容检测排除文档扩展名、二进制、超大文件、config、锁文件、minified 产物识别可读源码未知扩展名脚本同样进入候选清单common.py抽取范围完全由用户确认的选择文件决定extract_code_material.py只读取确认后的草稿/代码文件选择.json按完整文件抽取、去除纯空行不截取文件中间行段并在清单中记录每个文件的来源范围与材料行范围代码提取清单.md。抽取时还会为每个文件写入// File: 相对路径标记便于回溯extract_code_material.py。仓库 demo 中 代码-前30页.md 开头即可看到这种标记// File: frontend/src/app/layout.tsx import type { Metadata } from next; import { Providers } from ./providers; ... // File: frontend/src/app/page.tsx export default function Home() {6. 页眉必须包含软件全称和版本号页码连续清晰文件页眉或页首必须包含软件全称和版本号页码必须连续且清晰。页眉由 header_commands 写入左侧为“软件全称 版本号”SimSun 9pt右侧为“第 PAGE 字段 页”。def header_commands(software_name: str, version: str) - list[dict[str, Any]]: Create a left title and right page-number region in the default header. header_path /header[1]/p[1] return [ {command: add, parent: /, type: header, props: { type: default, text: f{software_name} {version}, align: left, font: SimSun, size: 9pt, color: #000000}}, {command: add, parent: header_path, type: ptab, props: {align: right, relativeTo: margin, leader: none}}, ... {command: add, parent: header_path, type: field, props: {fieldType: page, font: SimSun, size: 9pt, color: #000000}}, ... ]软件全称与版本号以草稿/申请表信息.md中已确认字段为准统一用于文件名、页眉、标题和正文防止“软件名称、版本号、页数不一致”这类常见的补正理由。7. 不把 Word 自动行号当登记规则行号是可选展示规则最后特别强调不把 Word 自动行号当成登记规则也不默认给源码添加逻辑行号需要行号时应作为单独的可选展示功能处理。也就是说代码正文就是源码物理行的连续排列是否显示行号不影响合规性脚本默认不开启 Word 自动行号。三、从草稿到 DOCXWord 真实页数的双重校验理解“选材估算 ≠ 最终页数”是本规则的核心要点。正式生成时build_docx_from_md.py 的docx_checks会执行完整校验链officecli validate file --jsonOpenXML 结构错误必须为 0重新读取/theme确认六个主题字体槽均为 Times New Roman / SimSun避免 WPS 因默认的 Calibri、Calibri Light、等线提示缺失字体officecli view file issues --json内容/格式提示写入生成报告Windows Word 时执行view stats --page-count --json读取自动分页后的真实页数生成全页联系表预览快速目检。其中对页数有硬性要求前 30 页/后 30 页文档经 Word 自动分页后必须分别正好 30 页否则生成失败并要求重新校准选材量而不是把不符页数的文档作为正式资料elif int(pages) ! estimated and estimated 30 and any( marker in output.name for marker in ((前30页), (后30页)) ): raise OfficeCliError( f{output.name} 经 Word 自动分页后为 {pages} 页不是要求的 30 页。 请根据生成报告重新校准代码选材量后再生成不能把页数不符的文档作为正式资料。 )仓库 demo 的 生成报告.md 展示了符合预期的校验结果- StudioAgent AI视频制片平台软件-代码(前30页).docx主题字体已统一为宋体/Times New RomanOpenXML 结构错误 0 个内容/格式提示 2271 个。 - StudioAgent AI视频制片平台软件-代码(前30页).docxWord 自动分页为 30 页与草稿选材估算一致文档未插入人工分页符。 - StudioAgent AI视频制片平台软件-代码(后30页).docxWord 自动分页为 30 页与草稿选材估算一致文档未插入人工分页符。在无 Word 的环境中生成流程仍会完成 OpenXML 校验与 OfficeCLI HTML 预览但提交前必须在 Word 或 WPS 中人工复核分页。四、运行方式与关键命令在实际项目中运行本 skill 生成代码材料时核心命令链如下。先生成代码候选清单并确认选择PYTHON SKILL_DIR/scripts/propose_code_selection.py \ --project 项目目录 \ --analysis 软件著作权申请资料/analysis/project.json \ --out-dir 软件著作权申请资料/草稿用户确认草稿/代码文件选择.json后抽取代码材料PYTHON SKILL_DIR/scripts/extract_code_material.py \ --project 项目目录 \ --analysis 软件著作权申请资料/analysis/project.json \ --selection 软件著作权申请资料/草稿/代码文件选择.json \ --software-name 软件全称 \ --version 版本号 \ --out-dir 软件著作权申请资料/草稿extract_code_material.py支持--lines-per-page参数默认55可在保持“每页不少于 50 行”前提下调整选材估算粒度。确认全部 Markdown 草稿后生成正式 DOCXPYTHON SKILL_DIR/scripts/build_docx_from_md.py \ --workdir 软件著作权申请资料 \ --software-name 软件全称 \ --version 版本号生成后可用 OfficeCLI 复核页数与结构officecli --version officecli validate 生成的docx --json officecli view 生成的docx issues --json officecli view 生成的代码docx stats --page-count --json officecli view 生成的docx screenshot --grid auto --render auto -o 预览.png五、与配套参考文档的关系copyright_material_rules.md是代码选材阶段的规则入口建议配合以下参考资料理解完整上下文code_selection_rules.md候选清单生成、selected/model_reason填写、排除项与真实性要求officecli_backend.mdDOCX 写入策略、页眉页码、主题字体归一与页数校验细节manual_structure.md文档鉴别材料操作手册的结构规则。相关实现与测试可直接在仓库中研读extract_code_material.py选材/折行/分档、common.py核心常量、build_docx_from_md.pyDOCX 构建与校验、test_code_layout.py折行与分页行为测试、test_workflow_integrity.py工作流门禁测试。仓库内还提供了完整生成样例 生成demo/软件著作权申请资料/可直接对照查看草稿、正式资料与生成报告。六、小结归纳本文核心结论便于直接引用规则落地参数校验方式源程序前后各连续 30 页 60 页时输出前 30 页 后 30 页Word 自动分页后必须各为 30 页不足 60 页提交全部 60 页且候选用尽时输出全部代码候选未用尽时先停止补充选择程序每页不少于 50 行每页按约 55 物理行估算选材量--lines-per-page可调不因代码宽度二次换行90 显示列确定性折行全角按 2 列测试锁定字符不丢失页眉/页码清晰左侧“软件全称 版本号”右侧 PAGE 字段OfficeCLI 页数 stats 复核代码必须真实只抽取确认后的完整源码文件// File:标记 代码提取清单回溯整套设计的核心哲学是Python 只负责确定性估算Word 才是最终分页的裁判。把折行、行距、页边距等影响页数漂移的因素在抽取阶段全部固定下来再用 OfficeCLI/Word 读取真实页数做最终门禁既满足《计算机软件著作权登记办法》第十条的鉴别材料规则又保证了同一份材料在重复生成时的结果稳定可复现。赞分享AI 技能文档【免费下载链接】SoftwareCopyright-Skill中国软件著作权申请材料 生成器 Skills本 Skills 通过阅读本地项目自动生成全套 .docx 软著申请材料全开源无须再付费购买任何软著申请服务项目地址https://gitcode.com/gh_mirrors/so/SoftwareCopyright-Skill点击查看免费下载相关推荐SoftwareCopyright-Skill 代码文件选择规则软著代码材料抽取的模型研判、内容检测与用户确认机制SoftwareCopyright Skill 代码文件选择规则软著代码材料抽取的模型研判、内容检测与用户确认机制 软件著作权申请材料中的代码鉴别材料必须来AI 技能文档SoftwareCopyright-Skill 使用指南用 Code Agent 从真实项目一键生成全套软著申请材料Word/TXTSoftwareCopyright Skill 使用指南用 Code Agent 从真实项目一键生成全套软著申请材料Word/TXT 中国软件著作权登记最AI 技能文档软著申请材料的业务理解规则SoftwareCopyright-Skill 如何把「理解软件业务」变成可校验的生成流程软著申请材料的业务理解规则SoftwareCopyright Skill 如何把「理解软件业务」变成可校验的生成流程 软件著作权申请材料的核心难点不在于排版AI 技能文档上一篇使用 Terraform AWS Provider 的 aws_kms_key 数据源查询 KMS 密钥详细信息下一篇tsParticles Branches 路径插件完全指南用分支运动路径打造树状粒子动画创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考