昨日回顧與今日目標

在 Day 27，我們深入探討了人機協作的過程，學會了如何批判性地看待 AI 的建議，並認識到人類開發者在架構設計、業務理解和最終決策上的核心價值。我們已經從一個 AI 的副駕駛，成長為一個懂得如何飆車的正駕駛。

但是，當我們在專業的、商業的環境中使用這些工具時，一些更嚴肅的問題浮出水面。我們不能只享受 AI 帶來的便利，而忽略其背後潛在的風險與責任。

今天的目標：跳出程式碼，從一個行業參與者的角度，探討在專業開發中使用 AI 時，我們必須面對的幾個關鍵議題。

版權與歸屬： AI 生成的程式碼，到底屬於誰？

• j資料隱私與安全： 我可以把公司的機密程式碼貼到 Prompt 裡嗎？
• 對未來的影響： AI 會讓初級開發者更難成長嗎？我們現在應該學習什麼？

議題一：程式碼的版權歸屬 (The Copyright Conundrum)

• 問題： GitHub Copilot 是用海量的開源程式碼訓練的，當它生成一段程式碼時，這段程式碼是否可能「複製」了某個受特定開源許可證（如 GPL）保護的程式碼片段？如果我將這段程式碼用在我的商業閉源專案中，是否存在法律風險？

現狀與觀點

• AI 公司的立場： 像 GitHub/Microsoft 和 Google 這樣的公司通常聲稱，AI 模型學習程式碼的過程，類似於人類開發者閱讀和學習大量開源專案，最終產生的程式碼是「衍生的」、「原創的」，因此使用者擁有其產出物的所有權。
• 法律界的爭議： 這個領域的法律仍在快速發展中，尚未有明確的判例。一些開源開發者認為，如果 AI 的輸出與其訓練資料中的受保護程式碼「高度相似」，就可能構成侵權。
• GitHub Copilot 的內建防禦： Copilot 有一個內建的篩選器，它會盡力避免生成與其訓練集中公開程式碼完全匹配的程式碼片段，如果它檢測到這種情況，它會在其建議中標註出來源，提醒使用者注意相關的許可證。

作為開發者的務實策略

• 不要盲目複製貼上： 始終將 AI 生成的程式碼視為「草稿」或「啟發」，對其進行理解、重構、並用你自己的風格重寫，這不僅能增加程式碼的原創性，也是一個很好的學習過程。
• 把它當作 Stack Overflow： 對待 AI 的建議，就像對待從 Stack Overflow 複製的程式碼一樣，你需要理解它、測試它，並確保它符合你專案的許可證要求。
• 關注大型、結構化的程式碼塊： AI 生成一個簡單的 for 迴圈或標準的 http.HandlerFunc 幾乎沒有版權風險，但需要警惕的是當它生成一個複雜、獨特的演算法或一個完整的、非通用的類別時，這時最好去查證一下是否有相似的開源實現。

議題二：資料隱私與安全 (The Confidentiality Concern)

• 問題： 我們在 Day 23 演練了如何讓 AI 為遺留程式碼生成特性測試，如果那段遺留程式碼是包含了公司核心業務邏輯或商業機密的閉源程式碼，我將它作為 Prompt 的上下文發送給 Copilot，這是否意味著我把公司的機密洩露給了 AI 的提供商呢? 這是目前企業應用 AI 最關心的問題之一。

不同產品的策略

• GitHub Copilot for Individuals (個人版): 根據 GitHub 的隱私政策，他們可能會使用你提交的程式碼片段（Prompts 和建議）來改進他們的模型。雖然是匿名的，但這對於有嚴格保密要求的公司來說，是不可接受的。
• GitHub Copilot for Business / Enterprise (企業版): 這是專門為了解決這個問題而生的。GitHub 明確承諾，企業版使用者的程式碼片段絕對不會被用於訓練其公開的 AI 模型。所有的資料傳輸和處理都是短暫的，僅用於即時生成建議，並且有嚴格的資料保留和存取策略。

作為開發者的務實策略：

• 遵守公司的政策： 在使用任何 AI 工具處理公司程式碼之前，務必與你的主管或 IT/法務部門確認公司的政策。
• 使用企業級解決方案： 如果公司要全面導入 AI 協作，建議使用 GitHub Copilot for Business 或其他提供類似隱私保護承諾的企業級 AI 開發工具。
• 脫敏處理： 如果你只是想就某個「演算法」或「模式」請教 AI，而不是整個業務邏輯，可以嘗試將程式碼中的敏感變數名（如 customer_secret_key）和業務術語替換為通用的名稱（如 apiKey）再進行提問。

議題三：對開發者未來的影響 (The Future of Developers)

• 問題： 當 AI 能完成越來越多的初級編碼任務時，初級開發者的成長路徑是否會被堵死？我們現在應該專注於學習什麼技能？

這是一個充滿焦慮但也充滿機遇的問題。答案對我來說是否定的，但我們的技能重心確實需要轉移。

技能的轉移：從「實現者」到「設計者」和「驗證者」

• Prompt Engineering 就是新的通靈技能: 過去，我們透過精準的 Google 搜尋來找到解決方案，但在未來，我們可以透過精準的 Prompt Engineering 來引導 AI 生成解決方案。提出好問題的能力，變得前所未有的重要。
• TDD/ATDD 技能價值飆升： AI 可以生成程式碼，但它無法對程式碼的正確性負責。驗證 AI 產出的能力，即編寫高質量測試的能力，變得至關重要。TDD/ATDD 不僅是保證品質的方法，更是駕馭 AI 的方向盤。
• 架構與系統設計能力: AI 能寫好一個函式，但它無法設計一個由數十個微服務構成的複雜系統。理解高可用、高併發、可擴充的系統設計原則，是人類開發者不可替代的價值。
• 軟實力與業務理解： 如 Day 27 所述，與人溝通、理解業務、將複雜問題拆解為技術任務的能力，其重要性已經超越了單純的寫code能力。

對於初級開發者而言，AI 不應被視為偷懶的工具，而應被視為一個加速學習的管道。當你不懂一段程式碼時，可以讓 AI 為你逐行解釋；當你想學習一種新模式時，可以讓 AI 為你生成範例。利用 AI 來更快地跨越初級階段，將精力投入到更高層次的設計和思考中，才是正確的成長路徑。

今日總結

今天，我們探討了關於責任與未來的嚴肅討論。

• 我們了解了 AI 生成程式碼的版權問題，並學會了以務實的態度規避風險。
• 我們釐清了個人版和企業版 AI 工具在資料隱私上的巨大差異，並強調了遵守公司政策的重要性。
• 我們展望了 AI 對開發者技能的未來影響，認識到提問能力、測試能力、架構能力和軟技能將是我們未來的核心競爭力。

擁抱 AI，不僅要擁抱它的能力，更要理解它的限制，並承擔起作為專業人士的責任。

預告：Day 29 - 案例研究 - AI+ATDD/TDD 在真實專案中的應用
理論和實踐都已探討完畢。明天，我們將把這 28 天所學的一切，濃縮到一個連貫的、故事性的案例研究中。我們將模擬一位開發者在真實工作中的一天，看看他是如何利用 AI+ATDD/TDD 的完整流程，來應對一個來自產品經理的真實需求。