開場白：歷史事件與現今的比喻
還記得在生物（或歷史）課本上提及到的一件事嗎？
那是當時（19世紀）人們因為太依賴單一一種馬鈴薯的種類，造成當時的馬鈴薯缺乏基因多樣性；結果馬鈴薯晚疫病來襲時，人們面對大量枯死的馬鈴薯卻束手無策，並最終造成饑荒的一場悲劇。雖然也有其他成因，但是「缺乏遺傳變異」的禍根，在 21 世紀的今天、人們逐漸依賴 AI 寫程式的當下，正悄悄地在一個場域發生重演。
2022年底，ChatGPT 的出現，正以革命性的速度，讓人們逐漸不再透過網路上的一問一答、相互切磋，來解決程式編寫上的問題，而改以將程式碼「整段複製貼上」給AI的模式在寫程式。在這之前的曾經，Stack Overflow 是人們面對不會講話的程式碼出問題時的沙漠綠洲；武漢肺炎的出現，更是讓該論壇的問答數量達到高峰。
然而在 2025 年初，約莫在 ChatGPT 推出後兩年，Theodore R. Smith – 一位在該論壇上貢獻了無數心力的軟體工程師 – 貼出了在 Stack Overflow 上問題被提出的數量。
當筆者看到 2026 年的現在，人們依賴彼此改進、糾正錯誤、讓彼此的程式碼「演化」的頻率，竟降低到與十數年前的頻率相同，不免感到心寒。雖然使用 AI 來寫程式的確能增進效率，但是 AI 與其他大型語言模型一樣，都是利用過往我們寫出的原始碼在不斷重複利用；這跟幾百年前，人們用同樣品種馬鈴薯來增進人口成長的往事，竟也有幾分相像。
當我們的程式碼也因為AI表面上帶來的優勢而停止演化，歷史上的教訓，也會在不同的場域再現；現在看到這篇文章的你，或許好奇「演化」的重要性，抑或是困惑一件事。
為何 AI 這麼好用，卻有人在警示我們不要過度依賴它來寫程式？
今天，且容筆者娓娓道來這道理的脈絡，以及在程式碼都開始「無性繁殖」的時代，身為生物資訊工程師的我們該如何面對。
依賴人工智慧寫程式：我的經驗與工程師觀點的兩相呼應
筆者在過去那一個年頭，曾經也是對程式碼撰寫不求甚解、短視近利的菜鳥編寫者，並本著這樣的「精神」去接觸自動化流程工具 Snakemake 、容器化工具 Docker 、以及許多生物資訊工具；本以為用這樣的方式彎道超車，就能讓自己省事、讓教授省心，但是卻在結果產出的幻想之前，吃了不少的苦頭；而教授在此時放手讓筆者自己體悟的作法，也讓筆者切實地發現從地基開始建高樓的重要性。
當時在 AI 的介紹下，我接觸到了 Snakemake 這款基於 Python 語法的自動流程工具；在看不懂的 help message 之前，我直接請 AI 教我最基本的使用方式、並將我對於這套工具的需求、疑問，一五一十地交付給了 AI 。在 AI 的指導下，我逐漸將本來需要五套不同腳本的大流程，整合成了只需要一列指令，就可以完成從最初輸入、一條龍直到最終輸出的 Snakemake 腳本。
在終端機面前按下 Enter 鍵的當下，我真的傻傻地以為這樣等六個小時過後，就可以寫實驗記錄了；沒想到卻在我沒看到的背景執行中，最後一步驟的腳本發生了未知的錯誤，導致全部的分析必須從頭重做、前面那五個多小時的等待也全都付諸流水。
我那時候簡直慌到六神無主，卻沒有選擇回頭去看看那工具的 Documentation ，依然選擇繼續請 AI 推薦解決方案。先後從五個階段分批次重跑、腳本執行環境的徹底檢查，卻都沒有發現問題。一、兩個星期過去了，而我依然像19世紀，人們面對枯死的馬鈴薯一般地束手無策。
某天，當瀕臨絕望的我準備要跟教授報告這件事的前一刻，事情因為一件意外而有了轉機。從 VS Code 視窗裡瞥見的隱藏資料夾給了我答案：要跟同行解釋 Bug 常常會需要 log 檔案；也就是當下才發現 Snakemake 一直都有內建的 log 檔案輸出功能。
把分階段產出 log 檔案的邏輯寫入後，才發現原來是因為終端執行指令的疏忽，導致原本指定的 Conda 環境根本沒被使用，最後一步的 R 語言腳本也因為找不到該環境中才有的工具，而直接中斷。
# This line was originally used without conda
snakemake --cores 16 -p
（說明：上面的指令是原本使用的，未使用 Conda）
# This line was later used with conda envs included
snakemake --cores 16 -p --sdm conda
（說明：這裡的指令是後來使用的，有使用 Conda）
後續的分析當然因為找到這個錯誤、修正後而順利完成了，而我也塵封了這段回憶；直到2026 年的寒假，因緣際會之下看見了知名生物資訊學家 Yasset Perez-Riverol 對於 AI 生成程式碼的觀點。看完了這位大師對於 AI 在生物資訊分析的現況後，我不禁感到心有戚戚焉：
GitClear analyzed 211 million lines of code. Since AI adoption spiked: 8x more code duplication. Refactoring down 60%. We are building faster but sloppier.
大量的程式碼重複率、探底的程式碼重構；這就是程式碼正「停止演化」並「無性繁殖」的進行式。而他在底下這段話所言的「資深開發者」的對照，正是當初只依賴 AI 寫程式、不懂「人工策展」的筆者本人！
And here is what seniority matters again. Someone needs to spot the mess, refactor the duplication, and enforce clean architecture. AI would not do that. The dev who has seen ten codebases rot from the inside will.
這段話精準打擊到過去那位不會重構程式碼片段的我：完全複製貼上、不會懷疑或思考；不過卻也反過來激勵我成為他鍵盤下那位「資深開發者」。
他的文字中提到過度依賴 AI 來寫程式可能會讓程式碼倉庫「從內部開始腐爛」就像十九世紀的馬鈴薯一樣；那麼從 2022 年開始有沒有類似的案例呢？
有，而且非常多；這說明類似 19 世紀的大規模馬鈴薯腐爛已經開始進行中。但是，基於篇幅上的一些限制，我在這裡只列舉兩項比較值得討論的例子。
當馬鈴薯正在腐爛：過度依賴 AI 寫程式的後果
首先來看看一個不那麼嚴重的：某新創公司的創辦人在媒體前宣稱：公司內部的程式碼都是使用 Cursor AI 撰寫，「完全沒有半點人工程式碼」。
然而，光鮮亮麗的外表，僅僅數天之內即被拆穿：程式碼中竟有許多初學者級別的安全漏洞；不僅讓使用者可以「繞過」付費功能（因為程式碼中根本沒有驗證機制）還能在資料庫裡修改別人的資料（資料庫也沒有輸入驗證機制）。
最後，該創辦人因為「無法修復這些錯誤」而被迫關閉專案。過度依賴 AI 的後果，是一間新創公司枉費了無數的投資，最終倒閉的結局。
那麼，如果這項由 AI 產出的程式碼，是有關於其他人的個人資訊呢？
在2025年7月，Tea App（社交軟體）爆發了被「駭入」的災情；超過五萬張從對話記錄的照片跟訊息被從資料庫中挖了出來，形成資料洩漏。後續的另一波災情更導致有位置紀錄的相片被洩漏出去。
後來，資訊安全專家很快就發現：這些跡象全部來自 AI 的推薦設定：預設的零安全性配置（Configurations）、沒有加密、驗證機制等限制；而開發這軟體的人竟然只有六個月的程式編寫經驗。這導致任何人只要會寫 Python 程式碼，很快就可以透過一條網址查到該軟體背後的資料；過度依賴 AI 的後果，是無數用戶的個人資料，在不知情的狀況下外洩的浩劫。
還有很多案例可以在延伸閱讀區看看，像是專案資料被 AI 給的指令全部刪除掉、AI 直接在指令列中使用 Pull request 的標題，導致駭客趁機植入惡意程式碼，造成加密貨幣損失之類。
結語：學習與AI共存，不要讓AI代勞
有發現嗎？
上述的兩個案例，弱點竟然那麼相似：
忽略安全性、驗證機制、存取限制的考量。
看到這裡的讀者，或許還會好奇一件事情：
那麼，AI這麼危險，我們不要去使用，可以嗎？
圖片由 ChatGPT 繪製
在非工程師都可以利用AI學編寫程式的現代，抗拒使用 AI 變得愈發不切實際；但是，筆者從我自己的案例，以及上述的後果當中，看出了一件關鍵：
學習與 AI 共存，不要讓 AI 代勞
使用AI來讓自己學習程式碼背後的原理，當然可以；只是：
當我們試圖利用 AI 去跨越我們本來該承受的試錯成本、本來該走的彎路，我們很可能會因此喪失在那些彎路上碰到不同的人，彼此相互切磋、學習、成長的機會；當一大群人都選擇使用 AI 而不去思考它產出內容的意義時，很可能一次晚疫病，就會讓這群生物全軍覆沒。
筆者本人現在對於 AI 的想法，就如同我們現在如何種植馬鈴薯：結合無性繁殖（ AI 撰寫程式碼）與有性繁殖（與其他開發者互動、交流，或是自己重構程式碼）各自的優點，在兼顧效率的同時，又能讓自己產出的程式碼與其他程式碼一起「共同演化」來避免過於單一、重複的弱點。
只要新手們願意花時間去自我學習寫程式、跟不同專案的開發者交流、知道一個負責任的專案該考量到哪些決策，就能將 AI 最不擅長的地方（理解程式碼背後的意圖）給補全。希望我們寫程式的人，都能找回與彼此互動的習慣，讓未來不至於因為程式碼重複導致的相同弱點，而再次出現類似馬鈴薯晚疫病的重災；共勉之！
延伸閱讀
文章引用的貼文：請點我
文章的靈感來源：請點我
其他格友的故事：請點我
其他類似的案例：請點我
Tea App 的報導：請點我
