1. 軟著申請(qǐng)到底在申請(qǐng)什么先把這件事想明白很多人第一次接觸軟件著作權(quán)腦子里冒出來的第一個(gè)問題不是“怎么申請(qǐng)”而是“這東西到底有沒有用”。我先把結(jié)論放前面軟著在很多時(shí)候不是“有沒有用”的問題而是“你有沒有”的問題。學(xué)生加學(xué)分、評(píng)獎(jiǎng)學(xué)金、保研加分公司申請(qǐng)高新技術(shù)企業(yè)、雙軟認(rèn)證、項(xiàng)目投標(biāo)甚至一些地方的落戶積分都會(huì)用到它。它不像專利那樣審查周期長(zhǎng)、授權(quán)難度大軟著的本質(zhì)是登記制只要材料規(guī)范、代碼和文檔符合要求下證的概率非常高。但“概率高”不等于“隨便交就能過”。我見過太多人卡在幾個(gè)特別基礎(chǔ)的地方源代碼頁數(shù)不夠、文檔和代碼對(duì)不上、申請(qǐng)表里的軟件名稱和代碼里的名稱不一致、開發(fā)完成日期填得比公司成立日期還早。這些坑不涉及什么高深技術(shù)純粹是沒把規(guī)則吃透。所以這篇內(nèi)容我會(huì)把整個(gè)流程拆開講從材料準(zhǔn)備、代碼整理、文檔撰寫到提交、補(bǔ)正、拿證每一步都配上我自己踩過的坑和實(shí)操技巧。這篇文章適合幾類人看一是第一次申請(qǐng)軟著、完全不知道從哪下手的個(gè)人開發(fā)者二是需要批量給公司項(xiàng)目申請(qǐng)軟著的研發(fā)或行政人員三是手里有 Python 小工具、Tkinter 桌面程序、PyInstaller 打包的 exe想拿去申請(qǐng)軟著但不確定代碼該怎么整理的人。我會(huì)重點(diǎn)結(jié)合 Python 技術(shù)棧來講因?yàn)闊嵩~里大量出現(xiàn)了 Tkinter、PyInstaller、Python 這些關(guān)鍵詞而 Python 項(xiàng)目在軟著申請(qǐng)里有一些非常典型的坑比如依賴庫(kù)代碼算不算、打包后的 exe 能不能作為材料、代碼行數(shù)怎么湊夠等等。先給一個(gè)整體認(rèn)知軟著申請(qǐng)的核心材料就三樣——申請(qǐng)表、源代碼、軟件說明書。申請(qǐng)表在系統(tǒng)里填源代碼和說明書是你要自己整理成 PDF 上傳的。審查員看的重點(diǎn)就兩個(gè)代碼是不是真的、文檔是不是能對(duì)應(yīng)上代碼。把這兩點(diǎn)做好剩下的就是流程問題。2. 申請(qǐng)前的準(zhǔn)備工作別急著寫代碼先把規(guī)則摸清2.1 軟著材料的硬性規(guī)格先記牢這幾個(gè)數(shù)字軟著對(duì)材料的格式要求非常具體具體到頁數(shù)、行數(shù)、字體。這些數(shù)字不是建議是硬性門檻不滿足直接補(bǔ)正甚至不予受理。我整理成一張表你直接對(duì)照著準(zhǔn)備就行。材料項(xiàng)規(guī)格要求常見踩坑點(diǎn)源代碼前 30 頁 后 30 頁共 60 頁總頁數(shù)不足 60 頁要全部提交每頁行數(shù)不少于 50 行空行、注釋太多導(dǎo)致實(shí)際有效行不夠字體字號(hào)通常要求宋體、五號(hào)或小四用等寬字體導(dǎo)致每頁行數(shù)變化頁眉需標(biāo)注軟件名稱、版本號(hào)、頁碼名稱和申請(qǐng)表不一致軟件說明書一般 10-30 頁含截圖和功能說明截圖太少、功能描述和代碼對(duì)不上申請(qǐng)表系統(tǒng)在線填寫開發(fā)完成日期、首次發(fā)表日期邏輯矛盾這里重點(diǎn)說源代碼。很多人以為“前 30 頁后 30 頁”就是隨便截取其實(shí)審查員會(huì)看代碼的連續(xù)性和完整性。如果你交上去的代碼中間有明顯斷裂比如第 30 頁結(jié)尾是一個(gè)函數(shù)開頭第 31 頁也就是后 30 頁的第一頁突然跳到另一個(gè)完全無關(guān)的模塊這種是容易被質(zhì)疑的。我的做法是如果代碼總量在 3000 行以內(nèi)直接全部提交省去截取的麻煩如果超過 3000 行就老老實(shí)實(shí)按前 30 頁后 30 頁來并且保證截取位置的代碼邏輯相對(duì)完整。2.2 軟件名稱和版本號(hào)的命名講究軟件名稱這件事看起來簡(jiǎn)單實(shí)際上是最容易出問題的地方。全稱一般格式是“XXX軟件”或“XXX系統(tǒng)”比如“智能五子棋對(duì)戰(zhàn)軟件”“企業(yè)數(shù)據(jù)可視化分析系統(tǒng)”。注意幾點(diǎn)名稱里不要出現(xiàn)“最”“第一”“國(guó)家級(jí)”這類絕對(duì)化或夸大詞匯不要直接用英文縮寫除非是通用術(shù)語版本號(hào)一般寫 V1.0不要寫 V1.0.0.1 這種太細(xì)的。我踩過一次坑申請(qǐng)表里寫的是“XX數(shù)據(jù)分析軟件 V1.0”結(jié)果源代碼頁眉寫的是“XX數(shù)據(jù)分析系統(tǒng) V1.0”就這一個(gè)字之差被要求補(bǔ)正。所以從你開始整理材料的那一刻起軟件名稱和版本號(hào)在所有材料里必須完全一致包括申請(qǐng)表、源代碼頁眉、說明書封面、說明書頁眉。建議先在記事本里把標(biāo)準(zhǔn)名稱和版本號(hào)寫下來后面所有地方都從這里復(fù)制粘貼不要手打。2.3 開發(fā)完成日期和首次發(fā)布日期的邏輯關(guān)系這兩個(gè)日期在申請(qǐng)表里要填邏輯上必須自洽。開發(fā)完成日期是你代碼寫完的那天首次發(fā)表日期是軟件第一次對(duì)外發(fā)布的那天。如果你沒有正式發(fā)布過首次發(fā)表日期可以填“未發(fā)表”。但如果你填了已發(fā)表那首次發(fā)表日期必須晚于或等于開發(fā)完成日期而且不能晚于申請(qǐng)日期。我見過有人開發(fā)完成日期填 2024 年 10 月首次發(fā)表日期填 2024 年 8 月這就明顯矛盾了。還有一種情況是公司申請(qǐng)開發(fā)完成日期填得比公司營(yíng)業(yè)執(zhí)照上的成立日期還早這也會(huì)被質(zhì)疑。個(gè)人申請(qǐng)相對(duì)寬松但邏輯上也要說得通。我的建議是開發(fā)完成日期填你代碼最后一次大改完成的那天首次發(fā)表日期如果沒有就選未發(fā)表省事。3. Python 項(xiàng)目代碼整理實(shí)戰(zhàn)從 Tkinter 到 PyInstaller3.1 Python 代碼怎么整理才符合軟著要求Python 項(xiàng)目申請(qǐng)軟著有一個(gè)天然優(yōu)勢(shì)代碼可讀性好注釋清晰整理起來相對(duì)容易。但也有一個(gè)天然劣勢(shì)Python 代碼行數(shù)往往不夠。一個(gè)功能完整的 Tkinter 桌面程序可能核心邏輯就幾百行加上界面代碼也就一千多行離 60 頁按每頁 50 行算就是 3000 行差得遠(yuǎn)。這時(shí)候怎么辦我的經(jīng)驗(yàn)是不要為了湊行數(shù)去復(fù)制粘貼無意義的代碼審查員看得出來。正確的做法是把項(xiàng)目里所有自己寫的 Python 文件都納入進(jìn)來包括主程序、工具模塊、配置文件解析、數(shù)據(jù)處理腳本等。如果你用了 Tkinter 做界面界面代碼本身就是很好的素材因?yàn)?Tkinter 的布局代碼行數(shù)不少而且邏輯清晰。具體整理步驟把項(xiàng)目里所有.py文件列出來排除第三方庫(kù)和虛擬環(huán)境目錄。按邏輯順序排列入口文件放最前然后是核心功能模塊最后是工具類和配置文件。每個(gè)文件開頭加上注釋塊寫明文件名、功能簡(jiǎn)述、作者、開發(fā)完成日期。統(tǒng)一縮進(jìn)和空行風(fēng)格建議用 4 空格縮進(jìn)函數(shù)之間空兩行。導(dǎo)出為 PDF 時(shí)選擇宋體、五號(hào)字確保每頁不少于 50 行。這里有個(gè)細(xì)節(jié)如果你用了import tkinter as tk這種導(dǎo)入語句這些行也算代碼行沒問題。但如果你把整個(gè)第三方庫(kù)的源碼也貼進(jìn)去那就過分了。審查員要看的是你自己寫的代碼不是庫(kù)的代碼。3.2 Tkinter 界面代碼的整理技巧Tkinter 是 Python 自帶的 GUI 庫(kù)很多小工具、小游戲都用它做界面。熱詞里出現(xiàn)了“五子棋基礎(chǔ)設(shè)置”“tkinter 能否在沒有 mainloop 主線中打開一個(gè)非阻塞的窗口”這些說明很多人用 Tkinter 做實(shí)際項(xiàng)目。Tkinter 代碼在軟著申請(qǐng)里其實(shí)是加分項(xiàng)因?yàn)樗苤庇^地對(duì)應(yīng)軟件說明書里的界面截圖。整理 Tkinter 代碼時(shí)我建議按這個(gè)順序組織窗口初始化和基礎(chǔ)設(shè)置Tk()、title()、geometry()控件定義和布局Button、Label、Entry、Canvas等事件綁定和回調(diào)函數(shù)業(yè)務(wù)邏輯函數(shù)主循環(huán)入口mainloop()這樣整理出來的代碼審查員一看就知道這是一個(gè)完整的 GUI 程序配合說明書里的截圖說服力很強(qiáng)。如果你做的是五子棋這類游戲棋盤繪制、落子判斷、勝負(fù)判定這些邏輯代碼都是很好的素材行數(shù)也夠。關(guān)于“tkinter 能否在沒有 mainloop 主線中打開一個(gè)非阻塞的窗口”這個(gè)問題從軟著角度來說你只要把實(shí)現(xiàn)這個(gè)功能的代碼整理進(jìn)去就行。實(shí)現(xiàn)方式通常是用update()代替mainloop()或者把 Tkinter 窗口放在單獨(dú)的線程里。這些代碼本身就是你軟件的技術(shù)亮點(diǎn)寫進(jìn)說明書里還能增加技術(shù)含量。3.3 PyInstaller 打包后的項(xiàng)目怎么處理PyInstaller 是 Python 項(xiàng)目打包成 exe 的常用工具熱詞里“pyinstaller打包命令”“pyinstaller打包成單個(gè)exe”“pyinstaller打包paddleocr”都指向這個(gè)。這里有一個(gè)非常關(guān)鍵的認(rèn)知軟著申請(qǐng)?zhí)峤坏氖窃创a不是打包后的 exe。PyInstaller 打包出來的 exe 是二進(jìn)制文件審查員不看這個(gè)也沒法看。那 PyInstaller 在軟著申請(qǐng)里扮演什么角色兩個(gè)作用一是你的軟件說明書里可以寫“本軟件通過 PyInstaller 打包為單文件 exe可在 Windows 環(huán)境下直接運(yùn)行”這屬于軟件的技術(shù)特征描述二是如果你的項(xiàng)目依賴了 PaddleOCR 這類第三方庫(kù)打包配置本身也是你項(xiàng)目的一部分可以在說明書里簡(jiǎn)要說明。但源代碼部分你提交的仍然是你自己寫的.py文件。PyInstaller 生成的spec文件如果是你自己寫的也可以作為代碼的一部分提交因?yàn)樗w現(xiàn)了你的打包配置邏輯。不過spec文件通常行數(shù)不多象征性放進(jìn)去就行。我個(gè)人的做法是源代碼只提交自己寫的 Python 文件PyInstaller 相關(guān)的內(nèi)容放在說明書里作為“運(yùn)行環(huán)境”或“部署方式”來描述。這樣既符合規(guī)范又能體現(xiàn)項(xiàng)目的完整性。3.4 代碼頁眉和頁碼的批量處理60 頁的源代碼手動(dòng)加頁眉頁碼會(huì)瘋掉。我的做法是用 Python 腳本自動(dòng)處理。思路是把所有.py文件合并成一個(gè)文本文件然后按每頁 50 行分頁用reportlab或fpdf生成 PDF頁眉自動(dòng)加上軟件名稱和版本號(hào)。如果你不想寫腳本也可以用 Word 的“頁眉頁腳”功能配合“分頁符”手動(dòng)做但 60 頁手動(dòng)操作容易出錯(cuò)。我建議至少用 Python 做一次自動(dòng)化處理因?yàn)檐浿暾?qǐng)可能不止一次公司項(xiàng)目多的話這套腳本能反復(fù)用。這里給一個(gè)簡(jiǎn)單的思路示例不是完整代碼只是說明邏輯# 偽代碼思路 lines [] for py_file in py_files: lines.extend(open(py_file).readlines()) lines.append(\n) # 文件之間加空行分隔 lines_per_page 50 pages [lines[i:ilines_per_page] for i in range(0, len(lines), lines_per_page)] # 生成 PDF每頁加頁眉 for page_num, page_lines in enumerate(pages, 1): header f軟件名稱 V1.0 第 {page_num} 頁 # 寫入 PDF...實(shí)際生成 PDF 可以用reportlab中文字體需要注冊(cè)宋體。這個(gè)腳本寫一次以后所有項(xiàng)目都能用非常劃算。4. 軟件說明書怎么寫才能和代碼對(duì)得上4.1 說明書的基本結(jié)構(gòu)軟件說明書不是技術(shù)文檔不需要寫得太深但必須和代碼對(duì)應(yīng)。審查員會(huì)翻你的說明書看里面描述的功能是不是在代碼里能找到。所以說明書的寫法是功能描述 界面截圖 操作步驟三件套。標(biāo)準(zhǔn)結(jié)構(gòu)一般是封面軟件名稱、版本號(hào)、編寫日期目錄軟件概述開發(fā)目的、主要功能、運(yùn)行環(huán)境功能說明按模塊逐一描述配截圖操作說明從啟動(dòng)到退出的完整流程技術(shù)特征簡(jiǎn)要說明用了什么技術(shù)棧頁數(shù)控制在 10 到 30 頁之間比較合適。太少了顯得單薄太多了審查員也看不過來。我一般做到 15 到 20 頁每個(gè)主要功能配 1 到 2 張截圖。4.2 截圖怎么截才專業(yè)截圖是說明書里最直觀的部分。很多人隨便截幾張圖就交上去結(jié)果截圖里有桌面圖標(biāo)、有其他窗口、有個(gè)人信息顯得很不專業(yè)。我的截圖習(xí)慣是只截軟件窗口本身不要截整個(gè)桌面窗口標(biāo)題欄要完整能看清軟件名稱關(guān)鍵操作步驟分多張圖比如“點(diǎn)擊按鈕前”和“點(diǎn)擊按鈕后”截圖分辨率保持一致不要一張大一張小如果界面里有測(cè)試數(shù)據(jù)用“測(cè)試數(shù)據(jù)”“示例數(shù)據(jù)”這種中性詞不要用真實(shí)姓名或敏感信息對(duì)于 Tkinter 程序截圖很方便直接運(yùn)行起來截窗口就行。如果你做的是五子棋截一張空棋盤、一張下棋中的、一張勝負(fù)判定的三張圖就能把核心功能說清楚。4.3 功能描述和代碼的對(duì)應(yīng)關(guān)系這是說明書的核心。你不能只寫“本軟件具有數(shù)據(jù)分析功能”而要寫“本軟件的數(shù)據(jù)分析功能由data_analysis.py中的analyze_data()函數(shù)實(shí)現(xiàn)支持 CSV 文件導(dǎo)入、數(shù)據(jù)清洗、統(tǒng)計(jì)計(jì)算和圖表展示”。這樣審查員一看就知道你的代碼和文檔是對(duì)應(yīng)的。我通常會(huì)在說明書里做一個(gè)簡(jiǎn)單的對(duì)應(yīng)表功能模塊對(duì)應(yīng)代碼文件主要函數(shù)用戶登錄login.pycheck_user()數(shù)據(jù)導(dǎo)入data_import.pyload_csv()圖表展示chart_view.pydraw_chart()這個(gè)表不用放在說明書正文里但你自己心里要有數(shù)寫功能描述的時(shí)候按這個(gè)來。審查員如果較真會(huì)翻代碼找對(duì)應(yīng)你能對(duì)上就沒問題。4.4 運(yùn)行環(huán)境和技術(shù)棧的描述運(yùn)行環(huán)境這部分Python 項(xiàng)目要寫清楚 Python 版本、依賴庫(kù)、操作系統(tǒng)。比如“本軟件基于 Python 3.9 開發(fā)使用 Tkinter 作為圖形界面庫(kù)通過 PyInstaller 打包為 Windows 可執(zhí)行文件可在 Windows 10/11 環(huán)境下運(yùn)行”。技術(shù)棧描述不用太詳細(xì)但要點(diǎn)出關(guān)鍵技術(shù)。如果你用了 PaddleOCR 做文字識(shí)別可以寫“本軟件集成 PaddleOCR 實(shí)現(xiàn)圖像文字識(shí)別功能”。這屬于技術(shù)特征寫進(jìn)去能增加軟件的技術(shù)含量但不要展開講原理說明書不是論文。5. 提交申請(qǐng)與補(bǔ)正處理流程和避坑5.1 在線申請(qǐng)系統(tǒng)的填寫要點(diǎn)現(xiàn)在軟著申請(qǐng)基本都是在線上系統(tǒng)完成。填寫申請(qǐng)表時(shí)有幾個(gè)地方容易出錯(cuò)軟件分類根據(jù)你的軟件實(shí)際用途選不確定就選“應(yīng)用軟件”開發(fā)方式獨(dú)立開發(fā)、合作開發(fā)、委托開發(fā)個(gè)人申請(qǐng)一般選獨(dú)立開發(fā)權(quán)利取得方式原始取得除非你是受讓別人的軟著開發(fā)完成日期前面說過了邏輯要自洽首次發(fā)表日期沒有就選未發(fā)表申請(qǐng)表里還要填軟件的基本功能和技術(shù)特點(diǎn)這部分不用寫太長(zhǎng)200 字左右說清楚就行。我一般寫本軟件是一款基于 Python 和 Tkinter 開發(fā)的 XXX 工具主要功能包括 A、B、C解決了 XXX 問題具有界面簡(jiǎn)潔、操作便捷的特點(diǎn)。5.2 材料上傳的格式和大小源代碼和說明書一般要求 PDF 格式大小有限制通常單個(gè)文件不超過 10MB 或 20MB。60 頁源代碼 PDF 一般不會(huì)超但如果你截圖特別多說明書 PDF 可能偏大。壓縮 PDF 可以用在線工具或者 Adobe Acrobat 的“縮小文件大小”功能。上傳前一定要檢查PDF 能不能正常打開、頁眉頁碼有沒有、軟件名稱版本號(hào)是否一致。我見過有人上傳的 PDF 是加密的審查員打不開直接補(bǔ)正。這種低級(jí)錯(cuò)誤完全可以避免。5.3 補(bǔ)正通知的常見原因和應(yīng)對(duì)補(bǔ)正是軟著申請(qǐng)里很常見的一環(huán)收到補(bǔ)正通知不代表被拒只是材料有問題需要改。常見的補(bǔ)正原因我整理了一下補(bǔ)正原因具體表現(xiàn)解決方法代碼頁數(shù)不足總頁數(shù)少于 60 頁且未全部提交補(bǔ)充代碼或全部提交代碼行數(shù)不足每頁少于 50 行調(diào)整字體或補(bǔ)充代碼名稱不一致申請(qǐng)表和代碼頁眉名稱不同統(tǒng)一名稱后重新生成日期矛盾開發(fā)完成日期晚于首次發(fā)表日期修正日期邏輯說明書與代碼不符說明書功能在代碼中找不到補(bǔ)充對(duì)應(yīng)代碼或修改說明書截圖不清晰截圖模糊、有無關(guān)內(nèi)容重新截圖收到補(bǔ)正通知后一般有 30 天左右的補(bǔ)正期限在系統(tǒng)里重新上傳修改后的材料就行。補(bǔ)正一次通過的概率很高不用太緊張。5.4 加急申請(qǐng)和普通申請(qǐng)的選擇軟著申請(qǐng)分普通和加急兩種。普通申請(qǐng)下證周期一般在 30 到 60 個(gè)工作日加急可以縮短到幾個(gè)工作日但需要額外費(fèi)用。如果你是學(xué)生急著加學(xué)分或者公司急著投標(biāo)加急是值得的。如果時(shí)間充裕普通申請(qǐng)就行沒必要多花錢。我個(gè)人經(jīng)驗(yàn)是如果距離截止日期還有兩個(gè)月以上走普通如果只剩一個(gè)月走加急。加急的費(fèi)用根據(jù)加急程度不同具體在系統(tǒng)里能看到這里不展開。6. 幾個(gè)高頻問題的實(shí)操解答6.1 Python 代碼里用了第三方庫(kù)代碼怎么算這是問得最多的問題。答案很簡(jiǎn)單只提交你自己寫的代碼。你import requests或者import tkinter這些導(dǎo)入語句算你的代碼但 requests 和 tkinter 庫(kù)本身的源碼不算。審查員不會(huì)要求你提交第三方庫(kù)的代碼因?yàn)槟遣粚儆谀愕闹鳈?quán)范圍。但如果你修改了第三方庫(kù)的源碼那修改的部分可以算不過這種情況很少見。正常項(xiàng)目里你寫的業(yè)務(wù)邏輯、界面代碼、數(shù)據(jù)處理代碼這些才是軟著保護(hù)的對(duì)象。6.2 代碼行數(shù)不夠 3000 行怎么辦前面提過如果總行數(shù)不足 60 頁就全部提交不需要湊。但如果你想讓材料看起來更充實(shí)可以把項(xiàng)目相關(guān)的配置文件、腳本文件、測(cè)試代碼也納入進(jìn)來。比如requirements.txt、config.ini、build.spec這些雖然行數(shù)不多但能體現(xiàn)項(xiàng)目的完整性。另外Python 代碼可以通過合理的空行和注釋來增加可讀性但不要為了湊行數(shù)加無意義的注釋。審查員看的是代碼質(zhì)量不是行數(shù)多少。一個(gè) 2000 行的清晰項(xiàng)目比 5000 行的混亂代碼更容易通過。6.3 軟著和專利的區(qū)別什么時(shí)候選哪個(gè)軟著保護(hù)的是代碼的表達(dá)形式專利保護(hù)的是技術(shù)方案。簡(jiǎn)單說軟著是“你寫了這個(gè)代碼”專利是“你發(fā)明了這個(gè)方法”。對(duì)于大多數(shù) Python 小工具、Tkinter 桌面程序軟著就夠了申請(qǐng)快、成本低。如果你的軟件里有獨(dú)特的算法或技術(shù)方案可以考慮同時(shí)申請(qǐng)專利但專利審查周期長(zhǎng)、費(fèi)用高一般個(gè)人開發(fā)者沒必要。6.4 軟著下證后的維護(hù)和變更軟著下證后如果軟件升級(jí)了版本比如從 V1.0 升到 V2.0可以申請(qǐng)新版本軟著也可以做版本變更。如果軟件名稱改了或者著作權(quán)人變了需要做變更登記。這些操作在系統(tǒng)里都有對(duì)應(yīng)入口按提示提交材料就行。我個(gè)人建議如果只是小版本更新沒必要重新申請(qǐng)軟著等積累了幾個(gè)大版本再一起申請(qǐng)。軟著的有效期是自然人終生及死后 50 年法人是 50 年不用急著頻繁更新。7. 我踩過的坑和給你的實(shí)操建議第一個(gè)坑代碼頁眉的軟件名稱和申請(qǐng)表不一致。這個(gè)坑我踩過兩次第一次是手打名稱時(shí)打錯(cuò)了一個(gè)字第二次是版本號(hào)格式不同。后來我學(xué)乖了所有材料里的名稱和版本號(hào)都從一個(gè)文本文件里復(fù)制絕不手打。第二個(gè)坑說明書截圖里有個(gè)人信息。有一次截圖里帶了一個(gè)測(cè)試用的真實(shí)姓名雖然不是什么敏感信息但審查員還是要求補(bǔ)正說截圖不清晰。后來我截圖前都會(huì)把測(cè)試數(shù)據(jù)換成“張三”“李四”這種明顯是示例的數(shù)據(jù)。第三個(gè)坑PyInstaller 打包后的 exe 當(dāng)成代碼提交。這個(gè)錯(cuò)誤很低級(jí)但確實(shí)有人犯。記住軟著提交的是源代碼exe 是二進(jìn)制審查員不看。第四個(gè)坑開發(fā)完成日期填得太早。個(gè)人申請(qǐng)雖然沒有公司成立日期的限制但如果你的開發(fā)完成日期填得比 Python 3.0 發(fā)布還早那就明顯不合理了。填日期要符合常識(shí)。最后分享一個(gè)提高效率的技巧建立軟著申請(qǐng)模板庫(kù)。把源代碼 PDF 生成腳本、說明書 Word 模板、截圖規(guī)范文檔都整理好下次申請(qǐng)新項(xiàng)目時(shí)直接套用能省掉大量重復(fù)勞動(dòng)。我第一次申請(qǐng)花了整整一周第二次用模板只用了兩天。如果你手里正好有一個(gè) Python Tkinter 的項(xiàng)目不管是五子棋、數(shù)據(jù)分析工具還是爬蟲可視化界面現(xiàn)在就可以按上面的流程整理材料了。代碼整理和說明書撰寫是最花時(shí)間的部分但也是最可控的部分把這兩塊做好剩下的流程就是按部就班。