很多人第一次做软件著作权申报，最容易低估的材料就是源代码。说明书还能慢慢改，申请表填错了也能撤回，但源代码一旦格式不对、内容不连续，或者前30页、后30页凑得太随意，就很容易收到补正通知。
我第一次整理软著源代码时，也以为直接从项目里复制代码、粘进Word就行。结果光是页眉就改了两遍，代码里还带着一堆测试地址、第三方库目录和空页。后来申报次数多了，才慢慢形成一套比较稳的流程。今天就顺着实际操作，把软著源代码怎么整理这件事讲透。
先确认要交多少代码，不要临提交才数页
常规申请一般提交源程序前连续30页、后连续30页，总共60页。每页通常控制在50行左右，不足60页的，就全部提交。这个要求看似明确，但实际操作里最常见的问题，是很多人从不同文件里东拼西凑，看起来页数够了，代码却不连续。
这里的“连续”，不是说60页必须来自同一个文件，而是代码材料本身要像一份完整文档：页眉统一、页码连续、内容顺序合理。前30页可以从程序入口、主要模块、核心业务逻辑开始，后30页尽量取项目后半部分的功能实现。不要前面放登录页，后面突然跳到压缩包自带的开源组件，中间又没有任何衔接。
如果代码量很大，我通常会先把项目结构过一遍，把真正属于本软件的核心源码挑出来，再决定前后顺序。不要等文档排版完了才发现前30页全是自动生成代码，后30页全是注释和空行。
源代码里哪些内容能放，哪些最好删掉
软著审查看的是申请人提交的软件源代码材料，代码要能体现软件功能，也要尽量干净。正式整理前，我一般会先处理几类内容。
第一类是第三方框架、开源库和自动生成代码。比如node_modules、vendor目录、UI框架、插件库、protobuf自动生成文件，这些不建议作为主要代码提交。不是说项目里不能出现开源依赖，而是软著材料要突出你自己开发的部分。如果60页里大半都是框架源码，说明不了你的软件原创表达。
第二类是敏感信息。数据库连接串、服务器IP、密钥、Token、内部接口地址、真实账号密码，都建议替换或删掉。代码可以保留原有结构，但不要把生产环境信息直接打印进申报材料。很多项目里测试写得很随意，提交前不搜一遍，后面会很麻烦。
第三类是大段无意义内容。空行、注释掉的废弃代码、console调试信息、自动生成的版权头、无限制重复的配置项，都可以适当清理。清理不是让你伪造代码，而是让材料更清楚、更可读。
还有一个细节，代码内容最好和软件名称、说明书功能对应上。你申请的是库存管理系统，代码里却主要是播放器组件；说明书里写了报表统计、权限管理，源代码却全是页面模板，这种不一致就容易引发疑问。
Word排版别花哨，稳定比好看重要
我现在整理源代码，基本不会用复杂格式。常用做法是新建Word文档，字体选宋体或者新宋体，字号小五号，段落行距设成固定值，保证每页接近50行。不同单位、代理机构的模板可能略有差别，但核心是每页行数稳定、打印出来不会大面积留白。
页眉通常要写软件全称、版本号，再配合页码。软件名称一定要和申请表一致，不要页眉写简称，申请表写全称，版本号也别一个带V，一个不带V。比如申请表写“某某仓储管理系统 V1.0”，源代码页眉就保持同样写法。
粘贴代码时，尽量用等宽字体并保留缩进。不要从IDE里截图塞进Word，源代码材料应当是可复制的文本。直接复制时如果出现自动换行、语法高亮、制表符错位，可以先贴到纯文本编辑器里处理一遍，再放进Word。我的习惯是把Tab转成空格，避免不同电脑打开后排版乱跑。
页码从第一页连续编到最后一页。页眉、页脚、页码这些东西看起来不起眼，却是补正高发区。尤其是代码超过60页时，不要以为只提交前后各30页，就可以分别从第1页排到第30页。最终材料本身要有一套连续页码，审查人员翻阅时才不会混乱。
前后30页怎么选，最能体现核心功能
选代码不能只按文件名字母顺序，也不能把项目压缩包解开后从头复制。比较稳妥的方式，是先按软件运行逻辑排：入口文件、路由或主窗体、核心业务模块、数据处理模块、接口服务、主要功能页面、工具类，再根据项目实际情况取舍。
前30页尽量放能说明软件身份和主流程的代码。比如系统启动、登录鉴权、主要菜单、订单处理、数据采集、设备通信等。后30页可以接项目后半段的实现，比如统计分析、导出、日志、权限控制、数据同步等。结尾不要落在一个莫名其妙的配置文件上，更不要最后一页只有两三行。
如果是小程序、App、Web系统，前后端代码都有，可以按功能逻辑组合，但别把碎片文件切得太碎。一个文件没放完就跳到另一个文件，不是绝对不行，但频繁跳转看起来会很乱。我的原则是：每个模块尽量完整呈现，文件之间的顺序能解释清楚。
有些项目代码量不足60页，这时就全部提交，不要为了凑页数硬加空行、注释或重复代码。代码行数少，只要功能、说明书和申请表能对应上，照样可以申请。反过来说，为了显得“有技术含量”，硬塞大量生成代码，风险更高。
几个我反复遇到的坑，能避就避
最常见的坑是代码和说明书两张皮。说明书里大讲人工智能算法，源代码里却只有普通增删改查；申请表里填的运行环境是Linux，代码里全是Windows桌面控件；软件名称带“平台”，实际代码和文档却像一个简单页面。这些都不是靠改页眉能解决的。
第二个坑是版本混乱。项目目录里同时放着V1.0、V1.1、backup、final、new_final多个文件夹，提交时随手选一个，最后代码版本和申请表不一致。整理前最好先固定一个申报版本，复制出来单独放，后续所有材料都从这个版本提取。
第三个坑是PDF转换后错位。Word看着没问题，转成PDF后代码被截断、页码丢失、页眉重复、灰色背景变成大黑块，这种情况我都遇到过。所以最终文件一定要自己打开PDF逐页检查，尤其看第1页、第30页、第31页和最后一页。
第四个坑是注释和命名太随意。变量名全是aa、bb、test123，注释里还写着“网上抄的”“临时先这样”，虽然不一定直接导致失败，但材料观感很差。既然是正式申报，至少让代码看起来像一个完成度较高的软件项目。
我自己的整理流程，照着做基本不会乱
现在每次申报，我都会先建一个材料文件夹，里面放申请表、说明书、源代码、营业执照或身份证明这些固定材料。源代码方面，先冻结项目版本，再删除第三方库和无关备份，只保留自研代码。接着按核心功能排列文件，把敏感信息批量替换掉，再合并成一个纯文本或Word文档。
排版时，我会先设置好页眉、字体、行距和页码，然后再粘代码。这样比全部粘完再返工省事得多。排完以后，不只看页数，还会抽查每页行数、是否有空白页、是否有大段重复代码、最后一页是否过短。确认无误后再导出PDF，并把Word版也留档，方便后面补正。
如果你们公司项目多、版本杂，或者自己第一次提交，实在不想在格式上反复试，可以试试 软著Pro。它上面有不少和软著材料整理、代码格式处理相关的实用功能，适合在提交前做规范化检查。我的建议是，工具可以提高效率，但项目代码怎么选、功能怎么对应，自己还是要过一遍，别完全无脑生成。
软著源代码不是简单凑60页纸。真正重要的是代码归属清楚、内容连续、格式统一，并且能和软件功能说明相互印证。把这些细节提前处理好，比收到补正通知后再到处找原项目、重新数页码轻松多了。
