前言¶
做智能体开发的人大概都有过这个体会：功能代码写完了，要申报软件著作权时才发现，真正花时间的不是写代码，而是整理材料。源程序文档要求每页 50 行、连续 60 页、页眉带软件名和版本号；说明书要有固定的六章结构；申请表还要填开发完成日期、代码行数、编程语言占比这些字段。手工凑这些文档，往往比写代码还累，而且格式稍有不符就会被打回。
下面介绍的这个 DSH 插件，就是针对这个痛点的：给它一个代码仓库和软件名，它在本机生成源程序 docx、说明书 docx、界面截图和申请表字段草稿。维护者是 feely0208，包名 @deepwhale-cn/dsh-copyright-kit，版本 0.1.0，MIT 许可证。它的定位是「辅助起草 + 排版 + 核对」，不是代办，也不构成法律意见。
这是什么¶
一句话定位：把「代码仓库 + 软件名」变成软件著作权登记要用的材料草稿，全部在本机生成。
它解决三件事：
- 源程序文档的排版：每页固定 50 行、显式分页、页眉和页码域，都由脚本生成，不靠手工调。
- 说明书的骨架：按登记习惯的六章结构排版，用户没给的信息写
【待补充】，不编造。 - 申请表字段的推导：软件名、版本号、代码行数、语言占比这些字段给出草稿值，并逐项标注推导依据和置信度。
核心功能¶
源程序文档¶
递归收集仓库里的源码，按跳过规则过滤后写入 docx：
- 跳过
node_modules、.venv、dist等依赖和构建目录，跳过锁文件、二进制、媒体文件、隐藏文件和符号链接，跳过package.json这类工程清单，超过 1MB 或疑似压缩生成的文件也不收。 - 每页固定 50 行，不足补空行；页与页之间是显式分页符，不是靠内容自然溢出。
- 源码超过 60 页时，取前 30 页 + 后 30 页，中间页不收录，计划里会写明。
- 页眉左侧是「软件名 版本号」，右侧是
PAGE域页码。 - 版式为 A4，上下边距 2.0cm、左右 2.5cm，正文 Consolas/宋体 9pt，固定行距 13.6pt。
生成之后插件会自动读回 docx，核对页数、每页行数、页眉和页码域，把结果一起返回，不用自己一页页翻。
说明书骨架¶
按六章结构排版：概述、主要功能、运行环境、操作说明、技术特点、版本说明。用户提供了 functions 和 overview 就填进去，没给的信息写 【待补充：…】。首次发表日期无法从代码推导，一律留空。
界面截图¶
调用本机 Chrome 或 Chromium 的无头模式，截 http(s) 地址或本地 HTML 文件，默认 1440×900。截图只是本机渲染，插件自身不发起网络请求，目标地址是否联网由使用者决定。
申请表字段草稿¶
产出 申请表字段草稿.json 和 .md，包含软件名、版本号、开发完成日期、首次发表日期、代码行数、编程语言占比。代码行数是按文件行数累加的统计口径，不等于登记系统的「有效代码行」口径，插件会标注这一点。不确定的字段留空，并给出推导依据和置信度。
计划先行，再落盘¶
侧栏「软著工坊」面板把流程分成两步。第一步「生成计划」列出会收哪些文件、跳过多少、总行数、原始页数与实际采用页数、语言占比，以及每项材料的前置条件（python-docx、Chrome 是否可用）。计划确认后才真正写盘，生成结果展示每个产物的路径与核对结果。输入变化会让旧计划失效，避免用旧计划跑新参数。
安装与启用¶
安装命令如下，来自插件 README：
dsh plugin --profile web add @deepwhale-cn/dsh-copyright-kit
装好后侧栏会多一个「软著工坊」图标。命令本身使用的是包名而不是 GitHub 地址，不要凭名称拼 dsh plugin add github:owner/repo。
除必需的 @deepseek-ai/dsh-tools 之外，插件声明的运行时要求是 dsh >=0.1.0-rc.6 <0.3.0，Node.js 不小于 18。
前置依赖¶
两项依赖缺了会明确报错，不会静默失败。
1、python3 + python-docx，用于生成 docx：
python3 -m pip install python-docx
解释器可以用环境变量 DSH_COPYRIGHT_PYTHON 指定。
2、Google Chrome 或 Chromium，只在需要截图时用到。默认会在常见路径查找，例如 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome，也可以用 DSH_COPYRIGHT_CHROME=/path/to/chrome 指定。
另有两个可选的环境变量：
| 变量 | 作用 | 默认值 |
|---|---|---|
DSH_COPYRIGHT_OUT |
输出根目录 | ~/软著材料 |
DSH_COPYRIGHT_REPOS_DIR |
面板候选仓库的扫描根 | ~/dsh-guard |
典型用法¶
方式一，在面板里走两步流程：先看「生成计划」，检查收录文件范围和前置条件，确认后再点「开始生成」。
方式二，在对话里直接说：「用软著工坊把这个仓库生成源程序和申请表」。
方式三是调服务端工具，四个工具的参数如下：
| 工具 | 主要参数 | 说明 |
|---|---|---|
copyright_source_doc |
repo、software_name、version、output |
生成源程序 docx 并读回核对 |
copyright_manual |
software_name、version、functions[]、overview、environment、output |
生成说明书骨架，缺的信息留占位 |
copyright_screenshots |
targets[]、output_dir、width、height |
本机 Chrome 无头截图 |
copyright_form |
repo、software_name、version、output |
推导申请表字段草稿 |
输出结构如下，以默认输出根目录为例：
~/软著材料/<软件名>-<版本>/
├── 源程序.docx
├── 说明书.docx
├── 截图/
│ ├── 01-首页.png
│ └── ...
├── 申请表字段草稿.json
└── 申请表字段草稿.md
自检¶
仓库自带三个命令，本地跑一遍就能确认插件可用：
node --check lib/index.js
node scripts/preflight-client.mjs .
node scripts/selftest.mjs
selftest 只写系统临时目录、不联网，覆盖 80 页裁剪、每页 50 行、页眉和 PAGE 域、物理容量、说明书占位、申请表留空字段、本地 HTML 截图以及 HTTP 面板接口。
适用场景与注意¶
适合需要申报软件著作权、手上有代码仓库、不想手工排版源程序和说明书的开发者与团队。
几点需要注意：
- 这是辅助起草工具，不构成法律意见。材料格式和内容仍需申请人或代理机构按登记要求核对，是否构成作品、权属归谁，由申请人负责。
- 插件以当前 dsh 进程的权限运行，安装前应检查源码和许可证，再决定是否用于内部代码。本插件是 MIT 许可，仓库里也带
LICENSE文件。 - 插件自身不联网，只读源码，除输出目录外不写任何文件。
- 申请表字段只是草稿，最终以版权保护中心系统里的表单为准。
- 说明书不会编造信息，缺失部分一律以
【待补充】占位。
结尾¶
这个插件的价值在于把登记材料里最机械的部分交给脚本：分页、页眉、截图、字段推导和读回核对。它不保证登记通过，也不替代人工核对，但能把人从一页页调格式里解放出来。
插件目录页：https://www.skillhub.cn/plugins/feely0208/dsh-copyright-kit
GitHub：https://github.com/feely0208/dsh-copyright-kit
