TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
軟著源碼收集器實測：把五千行原始碼收成編好頁碼的 Word
軟著源碼收集器是開源的中國大陸軟著申請文件整理工具：實測把五千行原始碼幾秒鐘收成編好連續行號與頁碼的 Word。但上限六十頁的自動裁切其實不會動作，超量刪減要自己來；另附申請表填空產出，下載時要注意鏡像站假包風險。
用 AI 摘要這篇文章：
把一個五千零八十四行的程式碼資料夾丟給它，頁數上限設六十，匯出完成後拆開檔案檢查：五千零八十四行一行不少，全部都在。這是我實測 SoftwareCopyrightSourceCodeCollector（軟著源碼收集器）時最反直覺的一個結果。這個工具對外說的故事，是幫你把軟著申請文件整理到合規；實際跑起來，收集、編號與排版做得又快又穩，但超量刪減這一段，完全沒有發生。
這件事對要送件的開發者影響很大：如果你以為按一個按鍵就會得到前三十頁加後三十頁的成品，收到的其實是整包完整文件，中段要自己刪。兩次實際匯出、一份申請表產出，加上原始碼對照，它的能力邊界已經可以畫清楚。
送軟著為什麼是個整理苦工
軟著是中國大陸的電腦軟體著作權登記，由中國版權保護中心受理，App 上架部分商店、投標、申請高新技術企業認定或報稅優惠時，常被要求附上登記證書。台灣的開發者或工作室遇到它的情境很具體：產品要進中國大陸市場、接了當地的客戶、或對方指名要這張證明。它與我們介紹過的 數智學術導航站、12306 查票工具同屬「目標使用者在中國大陸體系內」的工具，介面與文件全以簡體中文為主。
登記要附一份源程序鑑別材料，就是你的原始碼節選。工具內建的說明頁整理了常見的送件基準：總行數三千行以內全部提交；超過三千行，提交前三十頁與後三十頁，合計六十頁；每頁至少五十行，純空白行不計；第一頁要是程式入口；頁首標軟體名稱與版本，頁尾標頁碼。這套數字是當地登記實務流傳多年的整理慣例，不同代辦的說法細節略有出入，最終以受理機關的認定為準。
手工做這件事的痛苦指數很高。挑出要交的檔案、貼進 Word、手動加連續行號、調字型行距、加頁碼、超過六十頁再從中間砍掉，一個中型專案就要耗掉半天，還容易貼錯行。這個工具要解的就是這段。
專案現況與兩種執行形態
它是 GitHub 上的開源專案，jindongjie 個人維護，MIT 授權，2025 年 2 月開始，用 C# 與 .NET 8 寫成，圖形介面走 Avalonia。正式版 V1.22-f 在 2026 年 3 月發布，儲存庫最後一次推送停在 2026 年 5 月，內容是建置流程調整；到 2026 年 9 月初有一百二十一顆星、十八個 fork，歷來七個議題與合併請求全數關閉，下載量不大，最新版 Windows 圖形版下載一百七十幾次，是典型的小眾實用工具。我把原始碼 clone 下來，在本機（macOS、ARM64、.NET 8.0）建置命令列版，編譯五秒通過，接著跑了三次產出：一份一千二百七十一行的樣本（拿它自己的介面原始碼當輸入，九個檔案）、一份五千零八十四行的放大樣本（三十六個檔案），外加一份申請資訊文字檔。圖形介面我沒有親自跑，這點後面限制段會展開。
兩種使用形態讀者可以先分清楚：圖形版是三個分頁的桌面應用，掃描、預覽、匯出、申請表填寫都在視窗裡；命令列版是互動式選單，照提示輸入資料夾、副檔名、軟體資訊就能出文件，適合伺服器或沒有桌面環境的機器。Release 頁兩種都有，Windows、Linux、macOS 各自打包，單檔約三十三到三十六 MB，建置腳本掛了自帶執行環境的參數，機器上不用先裝 .NET。
掃描器的行為有兩個小地方值得先知道。圖形版開出來的副檔名預設值是 txt;docx，對照它的用途其實是個怪預設，原始碼專案要自己改成 cs;ts;java 這類，第一次用別直接按查詢。另外檔案清單會逐檔列出程式碼行數並加總，匯出前就能核對總量，還有一份文件與實際介面的出入：README 寫的分頁名稱與現在圖形版的三個分頁對不上，以實際介面為準。
命令列版的實際流程長這樣：選單挑匯出文件，接著依序作答資料夾路徑、副檔名、排除規則、軟體名稱、著作權人、版本，然後是那個沒有作用的頁數上限，最後給輸出檔名。它掃完會先印出找到的檔案數與總行數，再花幾秒鐘寫出 docx。全程不需要網路，所有動作都在本機完成，這點從原始碼也核對過：匯出邏輯裡沒有任何對外請求。
攤開產出的 Word：該有的骨架都在
先講做到的部分，這些我逐項拆開輸出檔驗過。文件開頭有三行資訊：軟體名稱接著固定的簡體字尾組成標題（藍色粗體；即使你填繁體名稱，字尾仍是簡體）、Copyright 加著作權人加年份、版本號。接著每個檔案以粗體檔名開頭，檔案內容逐行列出，行號從第一個檔案一路連續編到最後一個，不因換檔重算。程式碼行掛 Times New Roman、緊湊行距，頁尾有真正的頁碼欄位，Word 排版時頁碼會自己跳。
帳目對得起來。一千二百七十一行的樣本，輸出的 docx 內部共一千二百八十三個段落，等於三行開頭資訊、九行檔名標題、一千二百七十一行程式碼，一行不多一行不少，與掃描時回報的九個檔案、一千二百七十一行完全一致。副檔名篩選用分號分隔（例如 cs;ts;java），另支援 glob 樣式的排除規則，可以把 node_modules 或建置產物排除在外；這是 2026 年 3 月應使用者要求加上的功能，從提出到完成隔了六天，提問者的場景正是前端專案被 node_modules 塞爆。二進位檔會被自動略過並列在警告清單，讀取失敗的檔案也一樣跳過不中斷，不會弄壞整份輸出。
樣本怎麼挑的也影響觀察。我把工具自己的原始碼餵給它，九個 C# 檔案，等於讓它整理自己的家務事。輸出的第一個檔案不是 App.axaml.cs 這類主程式，而是 ViewModelBase.cs，印證了檔案順序照資料夾列舉、不排序也不判斷重要性的設計；想要入口程式碼排在第一頁，順序要自己動手調。
這一段的自動化是真的。同樣的內容手工貼進 Word 加行號，以每分鐘貼一百行估算，五千行要將近一小時，還不含調格式與出錯重貼；它跑完只要幾秒鐘。對照我們介紹過的 Markdown 轉 Word 工具，產物同樣是 docx，這裡多出的價值在行號連續性與送件格式的預設值。
最反常的地方：上限六十頁，五千行卻全進來了
第二次匯出是專門為了驗證超量處理設計的。五千零八十四行的樣本，頁數上限用預設的六十，照介面的故事線，輸出應該只剩前三十頁加後三十頁。實際結果：輸出檔內部五千零八十四行程式碼全部都在，最高行號五千零八十四，整份文件找不到任何一個分頁符號。換句話說，頁數上限這個參數，在現行版本不會改變輸出內容。
這個結果反常的地方在於，工具明明留了上限欄位，說明頁也寫了超過三千行要交前後各三十頁，兩者對不起來。送件的人如果直接把這份五千行的文件印出去，頁數會遠超規定，等於白忙一場。實測的結論很直白：收集與編號交給它，刪減這一步，現在要自己來。
自己刪的具體動作不難，但有個後果要先知道。在 Word 裡跳到第三十頁、選取到倒數第三十頁、刪掉中段，前後就接上了；可是文件裡的行號是工具預先寫死的文字，中段刪除後，行號會從前段的最後一行直接跳到後段的第一行，留下一個明顯的斷點。送件規則本來就只收前後各半，這個斷點是預期內的形態，但若你想讓它看不出來，得連行號一起重排，等於又回到手工活。這也是我把「整理」與「合規」分開講的原因：前者它做完了，後者永遠要人收尾。
裁切為什麼不動作：頁數是數出來的，不是排出來的
翻原始碼可以找到原因。它的頁數計算方式，是統計文件裡「明確寫入的分頁符號」數量再加一；而匯出流程從頭到尾沒有插入任何分頁符號，行與行交給 Word 自然流動排列。一分頁符號都沒有，頁數恆等於一，永遠不會超過六十，裁切邏輯因此從未被觸發。裁切的設計本身看得出意圖：保留前半三十頁與後半三十頁，把中間整段拿掉，正是送件規則的形狀。對照版本歷史，插入分頁符號的那行程式碼至少從 2025 年 6 月的 V1.1 起就被註解掉，之後一路維持原狀，圖形版連頁數輸入框都在介面上註解掉了，只剩命令列版還會問你這個其實沒有作用的數字。
更有意思的是，作者自己對此是坦白的。圖形版說明頁寫著：超過約三千五百行時建議手動刪減，因為自動刪除的效果他不滿意。也就是說，這不是行銷話術與實作的落差，是開發者明確知道、也明說了的取捨：與其自動砍出一份頁數對但斷點難看的文件，不如把刪減權留給使用者。理解這一點，對它的期待就會準確：它是整理器，不是合規保證機。送件前那份文件過不過關，最終仍以受理機關的認定為準。
另一半功能：把申請表變成填空題
這個工具還有容易忽略的一半：申請資訊產出。圖形版第三個分頁是完整的申請表單，欄位涵蓋官方申請表的主要欄位，從軟體全稱、簡稱、版本、權利取得方式、開發方式、發表狀態，到硬體環境、作業系統、開發工具、程式語言、源程序量、開發目的、主要功能、技術特點。填完匯出成一份七十二行的文字檔，照著欄位逐項抄進官方系統就行，檔尾還附了登記系統的官方連結。命令列版對應的是選單第二個選項，一路照提示作答，同樣產出這份文字檔；差別只在命令列不檢查字數下限，圖形版會擋。
圖形版對幾個容易退件的欄位做了輸入檢查：開發目的至少八個字、面向行業至少四個字、主要功能至少一百個字。另有十六種軟體類型標籤（App、遊戲、教育、金融、醫療、雲端運算、人工智慧、物聯網等）可以勾選附在檔尾。實測產出的文字檔欄位完整，格式清楚。要提醒的是欄位名全是簡體中文，對照官方系統填寫時要自己做轉換，而且這份文字檔供逐項抄寫對照，還不能直接上傳。
集中限制：裁切不動作，還有字級與假包風險
平台相容性是第一道關。README 明說只在 Windows 11 與 Linux 圖形環境測過，macOS 歡迎使用者回報，但 Release 頁照樣提供 macOS 包；我在 macOS 上只建置與執行了命令列版，圖形版能不能正常開，屬於未驗證狀態，拿 Mac 的讀者建議先抓命令列版試。輸出檔也有要留意的點：它是極簡包裝的 docx，只有五個內部部件，缺少樣式表等常規部件，macOS 內建的文字轉換器拒絕開啟這種結構；我用 Word 自動化實開驗證沒有成功，建議下載後自己用 Word 打開確認一次，這一步只要幾秒鐘。
排版細節與它自家說明頁的建議有落差。程式碼行的字級寫入值換算後只有五磅，說明頁建議的卻是十到十點五磅，實際開檔會偏小，送件前要自己調整；頁首標題與版本只放在文件前三行，每頁並不會重複出現；頁尾只有單純頁碼，沒有說明頁建議的「第幾頁、共幾頁」樣式。程式入口的排序只在圖形版做得到，把某個檔案標成入口，等同把它移到清單第一位；命令列版沒有這一步，檔案順序照資料夾列舉順序，送件要求第一頁是入口程式碼的話，命令列使用者要自己安排檔名與資料夾結構。每頁實際排出幾行由 Word 決定，五十行的門檻要不要微調行距，開檔查一遍最保險。
下載安全有一條要特別注意。2025 年 12 月有使用者通報，抓來的程式會自動下載一堆東西、多出一個 KMS 啟用工具；作者答覆時懷疑對方用了第三方鏡像站。README 現在明寫不要用第三方鏡像下載，最新版的每個下載檔也都附上 sha256 校驗檔，抓完對一次雜湊值再執行，是這類小眾開源工具的基本動作。另外它的程式未簽署，Windows SmartScreen 第一次執行時可能跳警告，這與上面的假包事件是兩回事。
判斷：有送件需求才值得裝
回答開頭的問題：這個工具值不值得裝，取決於你有沒有那份送件需求。要送中國大陸軟著登記、專案在三千行上下、能接受簡體介面的人，它把半天的複製貼上壓縮成幾分鐘，裝了就有效益。判斷有沒有成功的標準很具體：匯出後打開 docx，行號連續、頁碼正常、統計行數與你專案對得上，接下來只要處理中段刪減、字級與入口排序。
反過來說，完全不碰中國大陸登記流程的開發者，用不到它；習慣把材料整包交給代辦、自己只出原始碼的團隊，代辦費裡本來就含這段工，也不必自己動手。嫌手動刪減麻煩的，現階段它幫不上忙。對照 ScriptCat 那種每週都有提交與發版的節奏，這裡的裁切功能什麼時候補上，只能盯著 Release 頁等新版。它是單人維護的免費工具，回報管道就是 GitHub 議題，從過往紀錄看作者答覆與實作都算勤快；源碼公開、MIT 授權、無帳號無遙測，整理器本身做的都是本機檔案處理。這些條件放在一起，對需要的人是個低風險的生產力工具。
