這次我們不聊具體模型不聊部署腳本先聊一個在 LLM 應用開發里越來越繞不開的問題AI 寫的代碼功勞算誰的最近技術社區里有一個說法叫Dont credit the LLM翻譯過來就是“不要把功勞歸給大語言模型”。它不是在否認 LLM 的生產力而是在提醒一件事當 AI 輔助開發成為常態代碼的版權歸屬、提交記錄、學術署名、團隊績效不能用一句“這是 GPT 寫的”就含糊過去。這個理念直接關系到你的項目能不能進開源倉庫、論文能不能過審、公司代碼能不能合規商用。這篇文章把這個問題拆開講清楚。我會先解釋 Dont credit the LLM 的背景和核心邏輯再落到工程實踐提交記錄怎么寫、文檔怎么署名、開源合規怎么做、團隊協作怎么設計流程。面向的是已經在用 LLM 寫代碼、寫文檔、做分析的技術人員以及需要在團隊里制定 AI 使用規范的負責人。1. 核心觀點速覽維度說明核心理念LLM 是輔助工具代碼與內容的最終責任和功勞應歸于人類作者適用對象使用 LLM 輔助編程的開發者、技術團隊、學術作者、開源維護者主要場景Git 提交、代碼評審、學術論文、開源許可、團隊績效、內容發布爭議焦點LLM 生成內容的版權歸屬、許可合規、學術誠信、署名規范常見誤區把 LLM 當共同作者、用 LLM 生成代碼后不做審查、忽視開源許可證推薦做法保留人工審查與修改記錄、明確標注 AI 輔助范圍、建立團隊使用規范這個表把核心信息列出來了下面逐個展開。2. 為什么會有 Dont credit the LLM 的討論這個問題不是憑空出現的。它來自幾個真實的技術和法律交叉場景。2.1 學術論文與署名規范2023 年起多個學術期刊和會議組織陸續更新政策明確大型語言模型不能被列為論文作者。原因很直接作者要對內容的準確性、原創性和倫理責任負責而 LLM 無法承擔責任。如果你在一篇論文里寫了“本文由 ChatGPT 和作者共同完成”這不符合學術規范。正確的做法是在方法或致謝部分說明使用了哪些 AI 工具、用在哪一步、如何驗證了輸出。署名仍然是人。2.2 開源許可證與版權歸屬這是工程上最實際的坑。LLM 訓練數據里包含大量開源代碼這些代碼有不同的許可證MIT、Apache 2.0、GPL、AGPL 等。LLM 生成的新代碼可能無意中復現了某個 GPL 項目的關鍵邏輯一旦你把它放進自己的商業項目就面臨許可證污染風險。所以“這是 AI 生成的我沒有抄襲”并不構成法律上的免責理由。代碼的最終責任在你不在模型。2.3 團隊績效與工程管理如果團隊里所有開發者都在用 Copilot 或 ChatGPT 輔助寫代碼那績效怎么算代碼提交記錄里全是 Generated by Copilot 顯然不合理。工程管理的核心是AI 工具降低的是打字成本不降低設計、決策、責任成本。2.4 語義上的誤導Dont credit the LLM 還有一層意思是不要讓 LLM 成為你不思考的借口。一個常見現象是開發者把需求直接丟給 LLM然后把輸出原樣提交。代碼能跑但沒人理解它為什么這樣寫。這種“AI 驅動開發”在項目規模小的時候還行一旦進入復雜系統就變成災難。3. LLM 輔助開發中的角色邊界要落地 Dont credit the LLM先要清楚 LLM 在開發流程里到底扮演什么角色。3.1 LLM 是“增強器”而非“作者”我把 LLM 在開發中的角色分為四級級別角色人類參與度責任歸屬L1代碼補全高逐行審查人類開發者L2函數/模塊生成中高需要理解并修改人類開發者L3架構方案建議中需要驗證和取舍人類開發者L4全流程自動生成低需要全面評審人類開發者但風險最高不管是哪一級最終的責任人都是人。LLM 不參與需求評審不背線上故障的鍋也不對用戶數據安全負責。3.2 人類負責什么需求拆解把業務問題轉化為 LLM 能理解的提示詞和驗收標準。方案選型判斷 LLM 給出的技術方案是否適合當前系統架構。代碼審查逐行檢查生成代碼的邊界條件、錯誤處理、安全性。測試驗證補充單元測試、集成測試、回歸測試。合規審查確認引入的依賴、算法和訓練數據不違反許可證。3.3 LLM 負責什么初稿生成把思路快速變成可運行的代碼雛形。模式匹配從訓練數據中找到常見問題的解決方案。文本改寫優化注釋、文檔、錯誤信息的表達。代碼翻譯在不同語言和框架之間做轉換。知識檢索在對話中提供 API 用法、算法說明等參考信息。這個邊界劃分可以幫你判斷哪些環節可以放心交給 LLM哪些環節省不了。4. 代碼歸屬與提交記錄的工程實踐落實到日常開發Dont credit the LLM 最直接的表現是Git 提交記錄怎么寫。4.1 不要在提交信息里把 LLM 寫成作者錯誤示范git commit -m Add user login module # 作者是 AI這個提交記錄沒有意義 git commit --authorChatGPT chatgptopenai.com -m Add user login module正確做法是提交者始終是實際負責的人類開發者可以在提交信息里標注 AI 輔助范圍。git commit -m Add user login module - Implement JWT authentication - Add password hashing with bcrypt - Write unit tests for login service AI-assisted: ChatGPT was used to draft the initial JWT middleware. Reviewed and modified by 你的名字.這樣既保留了 AI 使用痕跡又明確人類進行了審查和修改。4.2 使用 Conventional Commits 規范如果你的團隊使用 Conventional Commits建議加一個可選的ai-assisted標記。feat(login): add JWT authentication middleware AI-assisted: true Reviewed-by: your-name這個標記可以用于后續的數據分析統計哪個模塊 AI 輔助比例高、哪個模塊需要更多人工審查。4.3 配置 Git Template 統一提交格式團隊層面可以用 Git 提交模板強制要求填寫 AI 輔助信息。創建.gitmessage文件# 提交類型: feat / fix / docs / style / refactor / test / chore type(scope): subject # 正文描述 # AI 輔助情況必填: none / draft / review AI-Assisted: draft # 審核人必填 Reviewed-by:然后配置到 Gitgit config commit.template .gitmessage這樣每次提交都會提醒開發者填寫 AI 使用情況和審核人。4.4 代碼評審中檢查什么使用 LLM 輔助開發的代碼評審重點應該增加以下內容是否有未理解的魔法值LLM 生成的代碼里常有硬編碼數字。邊界條件是否覆蓋輸入為空、并發沖突、網絡超時這些場景。安全漏洞提示詞注入、SQL 注入、路徑遍歷。許可證沖突引入的第三方庫和復制來的代碼塊是否符合項目許可證。是否有冗余邏輯LLM 有時會生成重復的 check 和 fallback。5. 文檔、論文與博客的署名規范代碼之外文檔和內容的署名同樣適用 Dont credit the LLM。5.1 技術文檔的 AI 輔助標注團隊內部技術文檔建議統一格式。頁頭可以加一個元信息塊--- title: 支付服務架構設計 author: 張三 ai_tool: ChatGPT / Claude ai_usage: 用于生成初稿框架人工完成架構選型和細節修訂 updated: 2025-01-15 ---這樣既不掩蓋 AI 輔助的事實也不把功勞歸于工具。5.2 對外發布內容的規范對外發布的博客、白皮書、產品說明建議在文末加一段聲明本文采用 AI 輔助寫作。AI 工具用于資料整理和初稿生成所有內容的準確性、技術判斷和最終表述由作者負責。這個聲明不降低你的專業度反而體現對讀者負責。5.3 學術論文的處理方式按主流學術規范執行不要將 LLM 列為作者。在 Methods 或 Acknowledgements 中說明使用的 AI 工具和技術細節。如果使用了 LLM 生成圖表、代碼或分析結果要明確標注。提交前務必核對目標期刊或會議的具體政策。一個常見模板是Acknowledgement: During the preparation of this work, the authors used [Tool Name] to assist with literature summarization and code implementation. After using this tool, the authors reviewed and edited the content and take full responsibility for the final publication.6. 開源項目中的 LLM 生成代碼合規這是最容易踩雷的部分。LLM 生成的代碼不是憑空出現的它基于訓練數據而訓練數據里包含大量受許可證保護的開源代碼。6.1 許可證分層風險評估場景風險等級說明完全手寫的代碼低不涉及 LLM 生成邏輯LLM 生成通用代碼片段循環、排序、IO低屬于常見的、不受版權保護的表達LLM 生成有特定業務邏輯的代碼中可能復現了某個開源項目的實現LLM 完整生成一個模塊高需要重點審查從 LLM 對話中復制了大段開源項目代碼極高需要確認原項目的許可證6.2 實操合規流程第一步啟用代碼掃描工具?？梢杂?grep 或更專業的工具搜索可疑代碼段# 搜索是否有可疑的版權聲明殘留 grep -rniE copyright|license|all rights reserved src/ | head -50第二步記錄所有 LLM 輔助生成的代碼范圍建立審計追蹤。第三步對高風險代碼段進行重寫。LLM 生成的代碼如果可能來自 GPL 項目最穩妥的做法是重新實現只保留思路不保留具體實現。第四步發布前檢查項目依賴樹# 查看所有依賴及其許可證 pip-licenses --formatjson | jq .[] | {Package, License}6.3 公司內部合規建議如果你在公司里維護內部項目建議和法務團隊確認三點公司是否有統一的 AI 使用政策。員工使用外部 LLM 服務時是否允許上傳內部代碼。生成代碼的版權歸公司還是個人合同中是否有約定。這些不能想當然。7. 團隊協作中的工作流設計單獨一個人實踐 Dont credit the LLM 不難難的是在團隊里推行。下面是一套可以參考的工作流。7.1 建立 AI 使用規范文檔一個團隊 AI 使用規范應該包含這些內容# 團隊 AI 輔助開發規范 ## 允許使用的工具 - GitHub Copilot經公司批準 - ChatGPT / Claude不得上傳內部敏感代碼 ## 必須人工完成的事項 - 需求分析與驗收標準制定 - 架構設計評審 - 安全相關代碼的最終確認 - 合規審核 ## 必須標注 AI 輔助的任務 - Git 提交信息中標注 - PR 描述中說明 AI 使用范圍 - 文檔中記錄 AI 工具類型 ## 禁止事項 - 將 AI 工具列為代碼作者 - 未經審查直接合入 LLM 生成的代碼 - 向外部 LLM 服務提交客戶的個人信息7.2 PR 模板加入 AI 信息字段在 GitHub 或 GitLab 的 Pull Request 模板里增加兩行## AI 輔助說明 - [ ] 本 PR 未使用 AI 輔助 - [ ] 本 PR 使用了 AI 輔助在下方說明范圍和工具 AI 工具: AI 使用范圍: 人工審查情況:這個字段的價值在于它讓評審者知道哪些代碼需要更仔細地看尤其是安全相關代碼。7.3 代碼評審中的 AI 專項檢查建議在評審清單里增加一個專門的 AI 檢查區- [ ] 代碼中是否存在不理解的邏輯要求作者解釋。 - [ ] 是否使用了正確的錯誤處理LLM 生成的代碼經常吞掉異常。 - [ ] 是否有合理的測試覆蓋LLM 生成的測試代碼常常只覆蓋 happy path。 - [ ] 是否引入不必要的依賴LLM 傾向于用額外庫解決簡單問題。7.4 用自動化工具輔助審計如果你想統計團隊中 AI 輔助代碼的比例可以寫一個簡單的腳本分析提交信息import subprocess import re from collections import Counter def analyze_ai_usage(): log subprocess.run( [git, log, --format%s%n%b%n---, -100], capture_outputTrue, textTrue ) commits log.stdout.split(---) ai_commits [] for c in commits: if re.search(rAI[- ]?[Aa]ssisted, c): ai_commits.append(re.search(r^.$, c.strip(), re.M).group(0)) print(fTotal commits: {len([x for x in commits if x.strip()])}) print(fAI-assisted commits: {len(ai_commits)}) if __name__ __main__: analyze_ai_usage()7.5 能力建設把 LLM 當“結對編程搭檔”我建議團隊把 LLM 的使用定位成“同事”而不是“自動代碼生成器”。具體來說讓開發者先寫注釋和偽代碼再讓 LLM 生成實現。要求開發者在提交前能解釋每一段新代碼的作用。在代碼評審中不是只看“對不對”而是問“為什么這樣寫”。這樣可以防止出現“代碼生成率挺高但沒人懂系統”的情況。8. 常見誤區與排查建議這塊是我觀察到的常見問題整理成一張排查表。問題現象可能原因排查方式解決方案PR 里出現大段未修改的 LLM 生成代碼開發者直接復制粘貼查看提交歷史確認是否有逐行審查記錄要求開發者重構并寫清修改邏輯提交作者是 Copilot 或 ChatGPTGit 配置錯誤git log --format%an檢查重置 author 配置提交者必須是實際作者開源項目收到許可證質詢生成的代碼與 GPL 項目相似使用代碼比對工具檢查重寫相關代碼段記錄追溯過程論文投稿被要求補充 AI 使用聲明未按期刊政策披露查看投稿規范在 Methods 和 Acknowledgements 補充說明團隊提交信息混亂無法統計 AI 使用情況缺少統一規范檢查 git log 和 commit 模板引入 Conventional Commits AI 標注開發者對自己提交的代碼無法解釋完全信任 LLM 輸出代碼評審中追問實現細節先寫設計文檔再生成代碼商業項目引入 GPL 依賴LLM 推薦了被污染的庫pip-licenses或license-checker檢查移除或替換為兼容許可證的庫8.1 關于“無法解釋代碼”的排查這個現象最容易在小團隊里出現。解決方法是建立“代碼答辯”制度每次評審讓提交者在評審會上口頭解釋至少三個關鍵函數的設計意圖。如果解釋不清楚就說明他還沒有真正掌握這段代碼不能合入。8.2 關于“許可證污染”的排查如果你發現項目里混入了可疑代碼第一步定位來源。git log --follow -p path/to/suspicious_file第二步搜索版權聲明。grep -rn copyright path/to/suspicious_file第三步評估風險。如果是個人項目問題不大如果是商業項目需要法務介入。第四步重寫或移除。重寫時不要簡單改變量名要重新設計實現方案。9. 最佳實踐總結把前面內容壓縮成一組可以直接執行的最佳實踐。9.1 個人開發者每個提交都明確自己承擔代碼責任。在提交信息中記錄 AI 輔助程度none / draft / review。對生成代碼做兩輪審查一輪看邏輯一輪看安全。不在技術簡歷上寫“X% 代碼由 AI 生成”沒有意義。對外發布內容時注明 AI 輔助范圍。9.2 團隊負責人制定 AI 使用規范文檔明確允許和禁止的事項。在 PR 模板中增加 AI 輔助說明字段。評審重點從“代碼質量”擴展到“代碼與作者理解度”。定期抽查提交記錄確保信息一致。與法務確認外部 LLM 服務的合規邊界。9.3 開源維護者明確項目的 AI 生成代碼接受政策。在 CONTRIBUTING 文檔中說明使用 AI 輔助生成代碼時貢獻者必須負責審查和合入。不強制要求貢獻者披露 AI 使用情況但如果代碼被質詢貢獻者要能解釋來源。對許可證高風險提交設置額外的人工審查環節。9.4 內容創作者論文遵循目標期刊的 AI 披露政策。博客和公眾號文章在末尾添加 AI 輔助聲明。包含代碼示例時確認代碼的許可證可接受。不把“AI 生成”作為內容質量不佳的借口。10. 下一步可以做的事Dont credit the LLM 不是一個口號它應該在具體的地方落地。我建議你按這個順序推進檢查最近的 Git 提交看看是否有作者信息混亂的提交。為自己的項目建立一份AI_USE.md文檔記錄 AI 使用原則。如果你的團隊還沒有規范先起草一頁紙的規則不用太長能執行就行。給 PR 模板加上 AI 輔助說明字段。在評審清單里增加一條開發者必須能解釋自己提交的核心代碼。如果你在推進過程中發現LLM 生成的代碼我改了還要不要標注這類邊界問題我的建議是標注成本很低信任成本很高。在你無法明確區分哪些代碼確實完全脫離 LLM 影響時寧可多標注一點也不要隱瞞。最后說一句LLM 是你工具箱里一個非常順手的工具但項目記錄里、論文署名處、開源許可證清單上始終應該是你的名字。這不是保守是一種更健康的工程文化工具負責提速人負責負責。 Don‘t credit the LLM：AI輔助開發的代碼歸屬與合規實踐指南
這次我們不聊具體模型不聊部署腳本先聊一個在 LLM 應用開發里越來越繞不開的問題AI 寫的代碼功勞算誰的最近技術社區里有一個說法叫Dont credit the LLM翻譯過來就是“不要把功勞歸給大語言模型”。它不是在否認 LLM 的生產力而是在提醒一件事當 AI 輔助開發成為常態代碼的版權歸屬、提交記錄、學術署名、團隊績效不能用一句“這是 GPT 寫的”就含糊過去。這個理念直接關系到你的項目能不能進開源倉庫、論文能不能過審、公司代碼能不能合規商用。這篇文章把這個問題拆開講清楚。我會先解釋 Dont credit the LLM 的背景和核心邏輯再落到工程實踐提交記錄怎么寫、文檔怎么署名、開源合規怎么做、團隊協作怎么設計流程。面向的是已經在用 LLM 寫代碼、寫文檔、做分析的技術人員以及需要在團隊里制定 AI 使用規范的負責人。1. 核心觀點速覽維度說明核心理念LLM 是輔助工具代碼與內容的最終責任和功勞應歸于人類作者適用對象使用 LLM 輔助編程的開發者、技術團隊、學術作者、開源維護者主要場景Git 提交、代碼評審、學術論文、開源許可、團隊績效、內容發布爭議焦點LLM 生成內容的版權歸屬、許可合規、學術誠信、署名規范常見誤區把 LLM 當共同作者、用 LLM 生成代碼后不做審查、忽視開源許可證推薦做法保留人工審查與修改記錄、明確標注 AI 輔助范圍、建立團隊使用規范這個表把核心信息列出來了下面逐個展開。2. 為什么會有 Dont credit the LLM 的討論這個問題不是憑空出現的。它來自幾個真實的技術和法律交叉場景。2.1 學術論文與署名規范2023 年起多個學術期刊和會議組織陸續更新政策明確大型語言模型不能被列為論文作者。原因很直接作者要對內容的準確性、原創性和倫理責任負責而 LLM 無法承擔責任。如果你在一篇論文里寫了“本文由 ChatGPT 和作者共同完成”這不符合學術規范。正確的做法是在方法或致謝部分說明使用了哪些 AI 工具、用在哪一步、如何驗證了輸出。署名仍然是人。2.2 開源許可證與版權歸屬這是工程上最實際的坑。LLM 訓練數據里包含大量開源代碼這些代碼有不同的許可證MIT、Apache 2.0、GPL、AGPL 等。LLM 生成的新代碼可能無意中復現了某個 GPL 項目的關鍵邏輯一旦你把它放進自己的商業項目就面臨許可證污染風險。所以“這是 AI 生成的我沒有抄襲”并不構成法律上的免責理由。代碼的最終責任在你不在模型。2.3 團隊績效與工程管理如果團隊里所有開發者都在用 Copilot 或 ChatGPT 輔助寫代碼那績效怎么算代碼提交記錄里全是 Generated by Copilot 顯然不合理。工程管理的核心是AI 工具降低的是打字成本不降低設計、決策、責任成本。2.4 語義上的誤導Dont credit the LLM 還有一層意思是不要讓 LLM 成為你不思考的借口。一個常見現象是開發者把需求直接丟給 LLM然后把輸出原樣提交。代碼能跑但沒人理解它為什么這樣寫。這種“AI 驅動開發”在項目規模小的時候還行一旦進入復雜系統就變成災難。3. LLM 輔助開發中的角色邊界要落地 Dont credit the LLM先要清楚 LLM 在開發流程里到底扮演什么角色。3.1 LLM 是“增強器”而非“作者”我把 LLM 在開發中的角色分為四級級別角色人類參與度責任歸屬L1代碼補全高逐行審查人類開發者L2函數/模塊生成中高需要理解并修改人類開發者L3架構方案建議中需要驗證和取舍人類開發者L4全流程自動生成低需要全面評審人類開發者但風險最高不管是哪一級最終的責任人都是人。LLM 不參與需求評審不背線上故障的鍋也不對用戶數據安全負責。3.2 人類負責什么需求拆解把業務問題轉化為 LLM 能理解的提示詞和驗收標準。方案選型判斷 LLM 給出的技術方案是否適合當前系統架構。代碼審查逐行檢查生成代碼的邊界條件、錯誤處理、安全性。測試驗證補充單元測試、集成測試、回歸測試。合規審查確認引入的依賴、算法和訓練數據不違反許可證。3.3 LLM 負責什么初稿生成把思路快速變成可運行的代碼雛形。模式匹配從訓練數據中找到常見問題的解決方案。文本改寫優化注釋、文檔、錯誤信息的表達。代碼翻譯在不同語言和框架之間做轉換。知識檢索在對話中提供 API 用法、算法說明等參考信息。這個邊界劃分可以幫你判斷哪些環節可以放心交給 LLM哪些環節省不了。4. 代碼歸屬與提交記錄的工程實踐落實到日常開發Dont credit the LLM 最直接的表現是Git 提交記錄怎么寫。4.1 不要在提交信息里把 LLM 寫成作者錯誤示范git commit -m Add user login module # 作者是 AI這個提交記錄沒有意義 git commit --authorChatGPT chatgptopenai.com -m Add user login module正確做法是提交者始終是實際負責的人類開發者可以在提交信息里標注 AI 輔助范圍。git commit -m Add user login module - Implement JWT authentication - Add password hashing with bcrypt - Write unit tests for login service AI-assisted: ChatGPT was used to draft the initial JWT middleware. Reviewed and modified by 你的名字.這樣既保留了 AI 使用痕跡又明確人類進行了審查和修改。4.2 使用 Conventional Commits 規范如果你的團隊使用 Conventional Commits建議加一個可選的ai-assisted標記。feat(login): add JWT authentication middleware AI-assisted: true Reviewed-by: your-name這個標記可以用于后續的數據分析統計哪個模塊 AI 輔助比例高、哪個模塊需要更多人工審查。4.3 配置 Git Template 統一提交格式團隊層面可以用 Git 提交模板強制要求填寫 AI 輔助信息。創建.gitmessage文件# 提交類型: feat / fix / docs / style / refactor / test / chore type(scope): subject # 正文描述 # AI 輔助情況必填: none / draft / review AI-Assisted: draft # 審核人必填 Reviewed-by:然后配置到 Gitgit config commit.template .gitmessage這樣每次提交都會提醒開發者填寫 AI 使用情況和審核人。4.4 代碼評審中檢查什么使用 LLM 輔助開發的代碼評審重點應該增加以下內容是否有未理解的魔法值LLM 生成的代碼里常有硬編碼數字。邊界條件是否覆蓋輸入為空、并發沖突、網絡超時這些場景。安全漏洞提示詞注入、SQL 注入、路徑遍歷。許可證沖突引入的第三方庫和復制來的代碼塊是否符合項目許可證。是否有冗余邏輯LLM 有時會生成重復的 check 和 fallback。5. 文檔、論文與博客的署名規范代碼之外文檔和內容的署名同樣適用 Dont credit the LLM。5.1 技術文檔的 AI 輔助標注團隊內部技術文檔建議統一格式。頁頭可以加一個元信息塊--- title: 支付服務架構設計 author: 張三 ai_tool: ChatGPT / Claude ai_usage: 用于生成初稿框架人工完成架構選型和細節修訂 updated: 2025-01-15 ---這樣既不掩蓋 AI 輔助的事實也不把功勞歸于工具。5.2 對外發布內容的規范對外發布的博客、白皮書、產品說明建議在文末加一段聲明本文采用 AI 輔助寫作。AI 工具用于資料整理和初稿生成所有內容的準確性、技術判斷和最終表述由作者負責。這個聲明不降低你的專業度反而體現對讀者負責。5.3 學術論文的處理方式按主流學術規范執行不要將 LLM 列為作者。在 Methods 或 Acknowledgements 中說明使用的 AI 工具和技術細節。如果使用了 LLM 生成圖表、代碼或分析結果要明確標注。提交前務必核對目標期刊或會議的具體政策。一個常見模板是Acknowledgement: During the preparation of this work, the authors used [Tool Name] to assist with literature summarization and code implementation. After using this tool, the authors reviewed and edited the content and take full responsibility for the final publication.6. 開源項目中的 LLM 生成代碼合規這是最容易踩雷的部分。LLM 生成的代碼不是憑空出現的它基于訓練數據而訓練數據里包含大量受許可證保護的開源代碼。6.1 許可證分層風險評估場景風險等級說明完全手寫的代碼低不涉及 LLM 生成邏輯LLM 生成通用代碼片段循環、排序、IO低屬于常見的、不受版權保護的表達LLM 生成有特定業務邏輯的代碼中可能復現了某個開源項目的實現LLM 完整生成一個模塊高需要重點審查從 LLM 對話中復制了大段開源項目代碼極高需要確認原項目的許可證6.2 實操合規流程第一步啟用代碼掃描工具?？梢杂?grep 或更專業的工具搜索可疑代碼段# 搜索是否有可疑的版權聲明殘留 grep -rniE copyright|license|all rights reserved src/ | head -50第二步記錄所有 LLM 輔助生成的代碼范圍建立審計追蹤。第三步對高風險代碼段進行重寫。LLM 生成的代碼如果可能來自 GPL 項目最穩妥的做法是重新實現只保留思路不保留具體實現。第四步發布前檢查項目依賴樹# 查看所有依賴及其許可證 pip-licenses --formatjson | jq .[] | {Package, License}6.3 公司內部合規建議如果你在公司里維護內部項目建議和法務團隊確認三點公司是否有統一的 AI 使用政策。員工使用外部 LLM 服務時是否允許上傳內部代碼。生成代碼的版權歸公司還是個人合同中是否有約定。這些不能想當然。7. 團隊協作中的工作流設計單獨一個人實踐 Dont credit the LLM 不難難的是在團隊里推行。下面是一套可以參考的工作流。7.1 建立 AI 使用規范文檔一個團隊 AI 使用規范應該包含這些內容# 團隊 AI 輔助開發規范 ## 允許使用的工具 - GitHub Copilot經公司批準 - ChatGPT / Claude不得上傳內部敏感代碼 ## 必須人工完成的事項 - 需求分析與驗收標準制定 - 架構設計評審 - 安全相關代碼的最終確認 - 合規審核 ## 必須標注 AI 輔助的任務 - Git 提交信息中標注 - PR 描述中說明 AI 使用范圍 - 文檔中記錄 AI 工具類型 ## 禁止事項 - 將 AI 工具列為代碼作者 - 未經審查直接合入 LLM 生成的代碼 - 向外部 LLM 服務提交客戶的個人信息7.2 PR 模板加入 AI 信息字段在 GitHub 或 GitLab 的 Pull Request 模板里增加兩行## AI 輔助說明 - [ ] 本 PR 未使用 AI 輔助 - [ ] 本 PR 使用了 AI 輔助在下方說明范圍和工具 AI 工具: AI 使用范圍: 人工審查情況:這個字段的價值在于它讓評審者知道哪些代碼需要更仔細地看尤其是安全相關代碼。7.3 代碼評審中的 AI 專項檢查建議在評審清單里增加一個專門的 AI 檢查區- [ ] 代碼中是否存在不理解的邏輯要求作者解釋。 - [ ] 是否使用了正確的錯誤處理LLM 生成的代碼經常吞掉異常。 - [ ] 是否有合理的測試覆蓋LLM 生成的測試代碼常常只覆蓋 happy path。 - [ ] 是否引入不必要的依賴LLM 傾向于用額外庫解決簡單問題。7.4 用自動化工具輔助審計如果你想統計團隊中 AI 輔助代碼的比例可以寫一個簡單的腳本分析提交信息import subprocess import re from collections import Counter def analyze_ai_usage(): log subprocess.run( [git, log, --format%s%n%b%n---, -100], capture_outputTrue, textTrue ) commits log.stdout.split(---) ai_commits [] for c in commits: if re.search(rAI[- ]?[Aa]ssisted, c): ai_commits.append(re.search(r^.$, c.strip(), re.M).group(0)) print(fTotal commits: {len([x for x in commits if x.strip()])}) print(fAI-assisted commits: {len(ai_commits)}) if __name__ __main__: analyze_ai_usage()7.5 能力建設把 LLM 當“結對編程搭檔”我建議團隊把 LLM 的使用定位成“同事”而不是“自動代碼生成器”。具體來說讓開發者先寫注釋和偽代碼再讓 LLM 生成實現。要求開發者在提交前能解釋每一段新代碼的作用。在代碼評審中不是只看“對不對”而是問“為什么這樣寫”。這樣可以防止出現“代碼生成率挺高但沒人懂系統”的情況。8. 常見誤區與排查建議這塊是我觀察到的常見問題整理成一張排查表。問題現象可能原因排查方式解決方案PR 里出現大段未修改的 LLM 生成代碼開發者直接復制粘貼查看提交歷史確認是否有逐行審查記錄要求開發者重構并寫清修改邏輯提交作者是 Copilot 或 ChatGPTGit 配置錯誤git log --format%an檢查重置 author 配置提交者必須是實際作者開源項目收到許可證質詢生成的代碼與 GPL 項目相似使用代碼比對工具檢查重寫相關代碼段記錄追溯過程論文投稿被要求補充 AI 使用聲明未按期刊政策披露查看投稿規范在 Methods 和 Acknowledgements 補充說明團隊提交信息混亂無法統計 AI 使用情況缺少統一規范檢查 git log 和 commit 模板引入 Conventional Commits AI 標注開發者對自己提交的代碼無法解釋完全信任 LLM 輸出代碼評審中追問實現細節先寫設計文檔再生成代碼商業項目引入 GPL 依賴LLM 推薦了被污染的庫pip-licenses或license-checker檢查移除或替換為兼容許可證的庫8.1 關于“無法解釋代碼”的排查這個現象最容易在小團隊里出現。解決方法是建立“代碼答辯”制度每次評審讓提交者在評審會上口頭解釋至少三個關鍵函數的設計意圖。如果解釋不清楚就說明他還沒有真正掌握這段代碼不能合入。8.2 關于“許可證污染”的排查如果你發現項目里混入了可疑代碼第一步定位來源。git log --follow -p path/to/suspicious_file第二步搜索版權聲明。grep -rn copyright path/to/suspicious_file第三步評估風險。如果是個人項目問題不大如果是商業項目需要法務介入。第四步重寫或移除。重寫時不要簡單改變量名要重新設計實現方案。9. 最佳實踐總結把前面內容壓縮成一組可以直接執行的最佳實踐。9.1 個人開發者每個提交都明確自己承擔代碼責任。在提交信息中記錄 AI 輔助程度none / draft / review。對生成代碼做兩輪審查一輪看邏輯一輪看安全。不在技術簡歷上寫“X% 代碼由 AI 生成”沒有意義。對外發布內容時注明 AI 輔助范圍。9.2 團隊負責人制定 AI 使用規范文檔明確允許和禁止的事項。在 PR 模板中增加 AI 輔助說明字段。評審重點從“代碼質量”擴展到“代碼與作者理解度”。定期抽查提交記錄確保信息一致。與法務確認外部 LLM 服務的合規邊界。9.3 開源維護者明確項目的 AI 生成代碼接受政策。在 CONTRIBUTING 文檔中說明使用 AI 輔助生成代碼時貢獻者必須負責審查和合入。不強制要求貢獻者披露 AI 使用情況但如果代碼被質詢貢獻者要能解釋來源。對許可證高風險提交設置額外的人工審查環節。9.4 內容創作者論文遵循目標期刊的 AI 披露政策。博客和公眾號文章在末尾添加 AI 輔助聲明。包含代碼示例時確認代碼的許可證可接受。不把“AI 生成”作為內容質量不佳的借口。10. 下一步可以做的事Dont credit the LLM 不是一個口號它應該在具體的地方落地。我建議你按這個順序推進檢查最近的 Git 提交看看是否有作者信息混亂的提交。為自己的項目建立一份AI_USE.md文檔記錄 AI 使用原則。如果你的團隊還沒有規范先起草一頁紙的規則不用太長能執行就行。給 PR 模板加上 AI 輔助說明字段。在評審清單里增加一條開發者必須能解釋自己提交的核心代碼。如果你在推進過程中發現LLM 生成的代碼我改了還要不要標注這類邊界問題我的建議是標注成本很低信任成本很高。在你無法明確區分哪些代碼確實完全脫離 LLM 影響時寧可多標注一點也不要隱瞞。最后說一句LLM 是你工具箱里一個非常順手的工具但項目記錄里、論文署名處、開源許可證清單上始終應該是你的名字。這不是保守是一種更健康的工程文化工具負責提速人負責負責。