项目已经开发完成，准备登记材料时，却要重新面对一件很细的工作：哪些文件纳入、按什么顺序排列、注释怎样处理、页眉中的软件名称与版本是否一致。手工复制到文字处理软件里，改一个选项就可能影响后面的分页。
CodeSucker 把文件筛选、清洗、分页预览和导出放在本地桌面流程中。它能减少重复排版，但材料内容与权利归属仍需要申报人核实。下面按 2026 年 9 月 23 日项目说明与国家版权局公开文件整理使用思路，不把工具的校验结果写成登记通过保证。项目仓库
“60 页”有适用条件
《计算机软件著作权登记办法》第十条规定了程序与文档鉴别材料的范围：一般取前、后各连续三十页，整体不足六十页时提交全部；除特定情况外，程序与文档分别有每页行数要求。程序和文档并不是同一种材料，不能把源码的行数设置直接套给说明文档。国家版权局公布的登记办法
因此，工具介绍中的“生成 60 页”不能理解成任何项目都要人为凑到六十页。项目本来较短，就应按实际材料和适用要求处理；通过重复代码、扩大无关内容或改字号凑数，都不会让材料更能说明软件本身。
具体提交方式与特殊情况还应核对登记机构当前指引。涉及保密或例外交存时，也不要只靠工具中一个遮盖或脱敏选项作判断。先明确需要提交哪类材料，再选择相应整理方式。
从一个固定版本的副本开始
准备材料时，先确定软件全称、版本和对应代码状态。若项目还在持续开发，可以保存一个独立副本或明确提交版本，记录整理日期。这样导出过程中即使主仓库继续变化，也不会悄悄混入另一版本的文件。
目录中常有依赖包、构建产物、生成代码、测试数据、历史备份和业务源码。不能把目录下所有文本都直接视为自己的源程序。先浏览文件树，确认每类文件的用途，再逐项决定是否纳入。
现有截图展示文件与排序的操作思路，具体界面以所用版本为准。排序时应保持可解释的组织方式，例如围绕项目入口与主要模块排列，而不是仅按哪个文件更容易凑满页面来移动。
可以另外保存一份清单，记录纳入的相对路径、顺序和排除原因。以后补正或重新生成时，能够复现当时的选择。只有最终 Word 文件而没有这份信息，后续很难判断某段代码来自哪里。
第三方代码提示需要人核对
当前项目说明提供第三方代码线索分析，会结合依赖清单、目录和声明等信息给出提示，并明确不自动作权利归属结论。它适合帮助你发现需要进一步核对的内容，不能把“没有提示”解释为全部代码来源都已确认。
例如项目中包含复制进来的工具函数、外包交付模块或修改过的开源组件，依赖文件未必能完整反映来源。整理时应保留相关开发与授权记录，不能因为准备申报材料就删除原来的版权或许可证说明。
反过来，一个文件存在第三方名称，也不代表可以直接把它排除。可能是接口兼容说明、调用示例或合法依赖记录。先看提示指向的具体行与项目背景，再决定如何整理。
这一步如果出现争议，应先核实材料来源或咨询负责登记事务的人员。排版工具解决不了合作开发、受让或修改许可等问题，不宜用自动结果替代相关证明。
清洗先看差异，再看行数
删除空行、转换 Tab、去除注释会改变文档的视觉结构。CodeSucker 说明采用状态机区分注释与字符串，能避免一类简单正则误删问题，例如把字符串中的 https:// 当作注释。但支持常见语法，不等于所有项目中的特殊写法都已经验证。
先挑几份有代表性的文件检查：包含 URL 的字符串、正则表达式、多行文本、模板字符串，以及注释中带有重要说明的段落。逐项比较清洗前后内容，确认没有误删有效代码，也没有把两段原本分开的语句连在一起。
超长行处理也需要留意。文档中的硬换行有助于排版，但它与源文件原始行号可能不再一一对应。保留原文件与导出文本，发现异常时才能回查。不要用经过排版的文档反向覆盖源码仓库。
对注释的处理可以按内容决定。只是为了方便开发的临时说明，与版权声明、必要来源说明，不应一律采用同样删除规则。若一条清洗规则导致内容难以理解，宁可先关闭它，弄清问题后再处理。
敏感信息检查不能只依赖自动替换
开发目录可能含访问令牌、测试账号、内部地址或样本个人信息。先从项目副本中确认哪些文件本就不应参与材料整理，例如真实环境配置、密钥文件和数据库导出。
工具可以提示或替换部分敏感模式，但自定义字段、分散拼接的值和特殊格式未必都能识别。导出前再搜索项目使用过的配置键名与敏感字段，检查实际内容。已经失效的测试密钥也不必为了“源码完整”继续保留在公开流转材料中。
与此同时，自动脱敏与登记要求中的保密处理不是同一个概念。需要按特定交存方式处理时，先核对适用要求。不能把源码大段替换成占位符之后，仅因软件没有报错就认定材料已经合适。
分页预览与最终文件各检查一次
预览阶段先检查纳入范围与首尾内容，再查看页数、每页行数和页眉。若中间改变了文件顺序、重新扫描了项目或修改了清洗设置，应重新生成并校验，不沿用上一次结果。
项目说明中有多项内置检查，例如署名冲突、页眉一致性和首末页边界。它们可以作为整理提示，但每一项“通过”所覆盖的范围都有限。内容真实性、材料之间是否一致，以及适用的登记要求仍应分别核对。
导出以后，用实际用于提交的办公软件打开文档。字体替换、自动域更新和不同渲染方式都可能影响分页。检查第一页、前后段连接处、最后一页，再抽查有长行或特殊字符的页面。只确认文件存在，无法发现页码与换行问题。
如果需要打印或转换为 PDF，再检查转换后的版本。记录最终使用的文件名与生成日期，避免提交时误选早先草稿。源文件、整理配置与最终导出文件可以分别归档，便于后续复核。
检查记录可以写得很具体：软件名称与申请表是否一致、版本是否对应保存的代码副本、第一页与最后一页来自哪个文件、长行是否超出页面，以及最终页码是否连续。由另一位熟悉项目的人抽查几处，比同一个人只反复检查总页数更容易发现选错版本的问题。
如果导出后还在办公软件中手工修改，应记录改了什么，并保存修改前文件。否则下一次从工具重新生成时，那些改动会消失，看起来像程序随机改变了结果。能通过整理配置完成的修改，尽量回到配置中处理；必须手工调整的部分，留一份可以重复执行的说明。
本地处理也需要核对下载来源
项目声明核心源码处理在本机完成，更新检测会请求公开版本元数据。这是开发者对产品流程的说明，本文没有做完整网络审计。对保密项目，可以在自己的测试环境中进一步检查实际运行行为，再按组织要求决定是否使用。
下载应通过项目发布页，选择对应系统与架构，核对发布说明和提供的校验信息。不要因为某个转发链接写着“免安装”就把完整商业源码交给它。版本更新后，也先用测试副本重新验证清洗与分页，确认行为符合预期。
CodeSucker 最适合承担重复的整理工作：把已确认的源码范围稳定地生成文档，并提前暴露格式问题。保存好版本、文件清单和最终检查记录，下一次修改材料时就能从明确的状态继续，而不必重新拼接整个项目。