前言¶
做智能體開發的人大概都有過這個體會：功能代碼寫完了，要申報軟件著作權時才發現，真正花時間的不是寫代碼，而是整理材料。源程序文檔要求每頁 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
