葛如鈞 AI代碼爭議：從翻車現場看 AI 代碼乾淨度與 3 個致命提交破綻
從施政島 Prompt 外洩與 GitHub 時間軸事件，看現代工程師必備的代碼衛生標準與 PR 審查避坑指南
2026 年 10 月底台北市長選戰掀起軟體圈熱議，焦點聚焦在葛如鈞 AI代碼爭議。蔣萬安競選團隊推出 3D 施政島網頁並宣稱原創領先，卻在公開代碼中被抓包給 AI 的提示詞指名參考對手沈伯洋網站，隨後更被 GitHub 提交時間軸與強制推送紀錄打臉。這起事件暴露出團隊在 AI 協作開發時，常見的代碼乾淨度破綻與版本控制失誤。
AI 輔助代碼交付的工程邊界速覽
- 提示詞留痕風險：直接把包含競品網址的原始 AI 對話打包發布，會造成開發動機外洩與公關信譽受損。
- 版本時序物理鐵證：Git 提交紀錄具備不可逆的時間戳記，發布順序無法靠事後口頭宣稱翻轉。
- 生產代碼衛生規範：進入生產環境前必須清除所有原型階段的非必要註解，落實自動化脫敏過濾。
本文將讓你學到
- 2026年10月「臺北施政島」爭議始末：一條留在原始碼裡的 Prompt 如何戳破技術先鋒宣稱
- 代碼鑑識下的 3 個致命破綻：Git Commit 時間差、強制推送與 Prompt 污染
- 原型驗證不等於生產交付：AI 協作代碼的「乾淨度邊界」三層檢驗標準
- 避免職場 AI 協作翻車的工程自保清單：自動化 Git Hooks 與審查規範
- 職場常見問題：AI 生成代碼參考競品架構算不算抄襲與侵權？
2026年10月「臺北施政島」爭議始末：一條留在原始碼裡的 Prompt 如何戳破技術先鋒宣稱
2026 年 10 月 28 日，台北市長蔣萬安競選團隊召開發布會，正式公開「台北安可大舞台」數位平台。其中第 2034 台名為《臺北施政島》，採用 WebGL 與 Three.js 技術，將過去四年的市政成果設計成可自由縮放、切換時段的 3D 浮動島嶼。
▲ 圖解：了解葛如鈞 AI代碼爭議中的三個致命破綻，並學習如何避免類似問題發生。
活動發表後，外界質疑該網頁的視覺語彙與互動模式，高度雷同於民進黨參選人沈伯洋在 10 月 22 日晚間推出的「HEART 政策島」。
面對質疑，競選團隊主管葛如鈞公開回應，宣稱自己早在 10 月初就用 AI 工具做出 3D 虛擬體驗，反指對手團隊跟進採用相同技術，更公開批評對方營造個人崇拜。
這段宣稱在數小時內被多位軟體工程師以公開原始碼推翻。開發者檢視網站公開資訊時，發現指令欄赫然保留了最初下達給 AI 輔助編程工具的第一行 Prompt。
該提示詞寫明：「幫我做一個3D互動網站，用島嶼地圖方式呈現市政成果與政見，互動手感參考 puma.taipei/heart-island」。
這條指令成為無可辯駁的直接證據，證明專案在啟動生成時，就以對手的現成線上作品為參考樣本。面對原始碼鐵證，葛如鈞隨後修正說法，改稱感謝開源社群相互啟發，並將成果定調為網友與 AI 的共同創作，事件迅速在技術社群引發對 AI 輔助開發誠信與專業交付的熱烈討論。
代碼鑑識下的 3 個致命破綻：Git Commit 時間差、強制推送與 Prompt 污染
從軟體版本控制與工程實務角度觀察，這場爭議並非單純的發言失誤，而是團隊在發布流程中忽略了三項基本技術防線，導致無法自圓其說的客觀紀錄全面曝光。
第一項破綻是提示詞未脫敏的「Prompt 污染」。
現代開發者常使用 Claude Code、Cursor 或 GitHub Copilot 等工具加速撰寫功能，但在原型測試階段輸入的粗糙指令與競品參考網址，若未在正式發布前建立過濾機制，就會跟隨打包工具的 Source Map 或註解直接暴露於前端生產環境。
第二項破綻是 GitHub Commit 紀錄的不可逆物理時間戳記。版本控制系統的提交紀錄由 SHA 雜湊值與精確時間座標構成。
沈伯洋團隊的「政策島」公開代碼首筆紀錄於 10 月 22 日建立並部署；蔣陣營施政島專案的首筆 Initial Commit 則出現在 10 月 23 日凌晨。客觀的時間先後順序，無法藉由口頭宣告顛倒因果。
第三項破綻是企圖使用 Git Force Push 覆蓋歷史痕跡。在社群指出時間差後，專案紀錄出現了強制覆蓋提交（Force Push）的軌跡。
在分散式版本控制系統中，任何推送動作一旦同步至公開遠端節點，分散各處的開發者本地端便已保留快照。事後強行重寫 Commit 歷史，反而成為修改紀錄的明確旁證。
原型驗證不等於生產交付：AI 協作代碼的「乾淨度邊界」三層檢驗標準
生成式 AI 讓非工程背景人員也能在數小時內搭建出酷炫的 3D 網頁原型，但原型測試與正式商業交付之間存在著嚴格的「代碼乾淨度邊界」。如果團隊缺乏上線檢驗規範，快速生成的便利性就會轉變成公關與法律風險。
為了建立健康的發布標準，軟體工程團隊在不同階段需要落實明確的代碼衛生區隔：
| 檢驗維度 | 草稿測試階段（Prototype） | 正式生產環境（Production） |
|---|---|---|
| 提示詞與註解 | 允許包含任意參考網址、對話提示與未驗證邏輯 | 全數移除草稿註解，禁止遺留任何生成式提示詞 |
| 版本控制歷程 | 允許頻繁試錯、零碎提交與隨意命名 | 執行分支整理（Squash Commit），產出清晰語義化歷史 |
| 外部依賴與授權 | 直接引用第三方 CDN、開源套件或競品前端資產 | 嚴格審查開源授權（License），移除未授權競品資源與字型 |
| 原始碼地圖管理 | 開啟 Source Map 便於本機即時排查問題 | 生產環境關閉公開 Source Map，防止內部架構直接外露 |
許多人在使用 AI 協作時，只注重功能是否跑得通，卻忽略了程式碼本身的乾淨度。未經清理的代碼就像把草稿紙上的雜亂筆記直接印在商品外包裝上，隨時會被懂行的檢視者看出破綻。
避免職場 AI 協作翻車的工程自保清單：自動化 Git Hooks 與審查規範
要防止類似的 Prompt 外洩與提交爭議在自己的團隊上演，不能單靠個人的記憶力與細心程度，必須建立機械化的自動檢查關卡。現代開發工作流可以透過三道具體措施建立發布防線：
第一步是部署本地 Pre-commit Hook。在專案的 Git 設定中加入自動化腳本，在開發者執行提交動作的瞬間，自動掃描代碼是否包含常見的 AI 提示詞標籤、API 金鑰、個人身分資訊或競品網址。一旦偵測到敏感字串，系統立即中止提交。
第二步是在 CI/CD 管線中加入脫敏掃描與語法檢查。將程式碼推送到遠端伺服器時，自動化建置工具需執行靜態檢查（Linter），強制阻擋包含特定關鍵字的註解與未過濾的 Source Map 檔案，確保生產環境只打包純粹的執行邏輯。
第三步是落實 Pull Request（PR）雙人同儕審查。由資深同仁檢視程式碼變更內容，確認 AI 生成的功能邏輯具備良好的結構可讀性，並確認沒有將測試階段的實驗程式碼或爭議參考資料遺留在正式分支中。
職場常見問題：AI 生成代碼參考競品架構算不算抄襲與侵權？
許多職場工作者在日常業務中會向 AI 下達「參考某家知名網站的排版或互動」指令，這種做法是否構成法律或道德上的侵權疑慮？判斷核心在於成果是僅參考概念，還是實質複製了受保護的表達形式。
在著作權法規中，單純的互動概念或 3D 浮島呈現政見屬於抽象思想，思想本身不受著作權法保護。然而，如果給予 AI 的指令導致其直接抓取對手網站的特定前端架構、專有樣式表、客製化 3D 模型檔案或專有文本，便可能構成對著作權中「重製權」的侵權疑慮。
此外，在公關與商業信譽層面，若團隊在宣傳上標榜全台首創或自主研發，私下卻以競品網址作為生成骨架，一旦原始碼曝光，即便未達到法律侵權門檻，也會直接摧毀企業或個人的專業公信力。