软著代码文档这破活,终于有人做成本地工具了

申请软著这事，老鬼最烦的从来不是填表。

是那 60 页代码。

前 30 页、后 30 页，每页至少 50 行，页眉还得塞软件名和版本号，第一页要从程序开头起，最后一页还得收在程序结尾。你代码写得再漂亮，材料少一行、分页跑了、署名没处理干净，照样可能回来补。

纯体力活。

最近翻到个国产开源项目 CodeSucker，我一开始还以为就是把代码拼成 Word，结果看到它的截取逻辑才停了一下：超过 3000 行，直接拿前 1500 行 + 后 1500 行，每 50 行插一个显式分页符，不靠字体、行距在那里硬凑 60 页。

这就很现实。

老鬼以前折腾 Demo、小工具，最怕这种“看着简单”的文档活。真正耗时间的不是第一次生成，而是改个文件之后重新排、重新查，最后发现第 47 页少了一行。

CodeSucker 干脆把这套脏活全塞进本地流水线里。文件夹拖进去，选代码，清掉注释和空行，排版，然后直接出 docx 和 txt。

我比较敏感的是另外一个点：源码不上传。

扫描、清洗、分页、导出都在本机跑，没有源码网络请求；联网只用于查询 GitHub 的公开 Release 版本信息。对于公司项目，这往往比“一键生成”重要得多——谁敢为了申个软著，把整仓库代码传给一个不知道后端在哪儿的网站。

它甚至还顺手做了脱敏，API Key、密码、内网 IP、手机号会被替换掉。注释清理也不是简单拿正则狠狠干，像字符串里的 https://，其中的 // 不会被误删。

啧，这种细节才像真踩过坑。

导出前还有一轮校验：每页够不够 50 行、末页有没有达到要求、页眉对不对，以及代码里的 @author、Copyright 跟申报主体有没有冲突。有问题还能定位回源文件。

不过先别急着吹成“提交神器”。

官方自己也说了，生成的 docx 更适合作为申报材料准备稿，最终还是得按登记机构最新要求核一遍。另外 macOS 安装包目前还没做 Apple Developer ID 签名和公证，第一次启动可能得手动放行。

项目目前正式版已经到 v0.4.4，7 月底这一版还在修 Windows 字体缩放、macOS 原生窗口行为和 Word 文档一致性校验。不是扔个 MVP 就跑路的节奏。

如果你一年就申一次软著，也能省点命。

要是公司里一批一批报，而且源码压根不允许出内网，这玩意儿就更对路了。