我利用 AI 完成的那些事

背景

這篇文章源於一位擁有七年專業經驗的工程師分享他如何從最初對 AI 的排斥，轉變為全面擁抱 LLM 工具（如 Cursor 與 Claude Code）的心路歷程。作者強調，雖然他熱愛編程與軟體架構，但現在更傾向於將 AI 視為解決問題的槓桿，甚至在近幾個月內幾乎不再親手撰寫程式碼，轉而扮演提示詞編寫者與審查者的角色。

社群觀點

Hacker News 的討論呈現出極端兩極化的反應。支持者與實踐者分享了大量透過 AI 實現的具體專案，從語音筆記本、自動化稅務處理到複雜的 3D CAD 建模工具。這些用戶認為 AI 徹底改變了開發門檻，讓「拋棄式軟體」成為可能：開發者不再需要依賴現成的商業軟體，而是可以針對極其小眾或個人化的需求，快速生成並在完成任務後隨即丟棄。這種「解決問題優先於維護程式碼」的觀點，被視為一種開發範式的轉移，讓工程師能從繁瑣的語法細節中解放，專注於更高層次的系統設計與價值創造。

然而，批評者的聲音同樣強烈且具備深度。許多資深開發者質疑，目前 AI 生成的專案大多屬於「無用之物」或是為了推廣 AI 而存在的工具，缺乏真正的商業價值或技術深度。反對者指出，過度依賴 AI 可能導致技能萎縮，並將編程簡化為一種「追求廉價多巴胺」的行為，產生大量無人維護的「廢棄軟體」。更深層的技術爭論在於系統設計的本質：有人引用 Linus Torvalds 的觀點，強調編程的核心在於資料結構與系統間的隱含關係（Edges），而非單純的程式碼片段（Nodes）。AI 雖然擅長生成片段，卻難以理解複雜系統中的假設與反饋循環。如果開發者只追求「程式碼能跑就好」而忽視維護性，最終將在面對複雜需求變更時陷入困境。

此外，關於「職業替代」的焦慮也滲透在討論中。部分留言者諷刺地表示，開發者正在支付費用來訓練自己的替代品，並擔心當所有人都能透過 AI 產出大量程式碼時，工程師的專業價值將被稀釋。但也有觀點反駁，認為 AI 只是另一種形式的槓桿，真正的核心競爭力在於對問題領域的深刻理解與客戶需求的洞察，而非單純的打字速度。關於 AI 幻覺的討論也提醒了使用者，在處理如稅務或醫療數據等高風險任務時，AI 的錯誤可能帶來嚴重後果，目前的最佳實踐仍是讓 AI 撰寫檢驗腳本，而非直接信任其輸出的數值。

延伸閱讀

在討論串中，開發者們分享了多個實際運行的 AI 協作專案與工具。Stavros 介紹了包括語音筆記、AI 個人助理、以及一個極具創意的「不規則跳秒時鐘」等專案。在開發流程工具方面，有使用者討論了 Dagger 與 Earthly 在 CI/CD 流程中的優劣，並提到 Dagger 在處理複雜邊際案例時的穩定性。此外，也有人分享了利用 WebAssembly 版的 Open CASCADE 庫結合 AI 進行 3D 建模的嘗試，以及透過 Claude Code 結合 beancount 進行自動化帳務校對的流程。