---
title: "給 AI 寫程式後，有什麼消失了？"
date: 2026-10-07T00:00:00+08:00
publishDate: 2026-10-07T00:00:00+08:00
lastmod: 2026-10-05T21:28:32+08:00
tags: ["LLM","AI","經驗","心得"]
toc: true
permalink: "https://blog.aotoki.me/posts/2026/10/07/what-disappeared-when-ai-writes-code/"
language: "zh-tw"
---


週末在評估 [Tsuzuri](https://blog.aotoki.me/posts/2026/09/30/tsuzuri-reinventing-subtitle-editor/) 的前端框架該從 Stimulus 換到哪一套時，為了維持整體的輕量，評估過程中我打開了 [Svelte](https://svelte.dev/) 的教學文件，沒想到全程禁止複製貼上，倒是久違的手寫了一遍程式。

花一小時左右手寫後，我對於 Svelte 用很精簡的語法實作許多功能感到讚嘆，也開始思考讓 AI 實作時，還能找到這樣的驚喜嗎？

<!--more-->

## 打磨{#polish}

上一次打開程式碼思考「如果這樣做，是不是就更好」的時機點是什麼時候？我不確定大家是否還會這樣做，因為它似乎跟 Code Review（程式碼審查）是同樣的事情，既然 AI 實作大多不會出錯，我們真的還需要這樣做嗎？

雖然我也不太會逐行讀，但過程中仍會看一下產生的程式碼調整方向，有時候也還是會在 GitHub 上觀察專案的實作狀況。

實際上，由 AI 生成的程式碼很多時候還是有問題，但那種問題不是「不會動」這樣的問題，更像是沒注意到，或者理解不夠深入。

所以打磨還是必要的，但現在這種能夠快速開發的環境，很難回答該怎麼做。

## 盲點{#blind-point}

當我能快速推進時，我總是會在某個時機點發現「變慢了？」但這種變慢實際上不明顯，畢竟原本就是放著讓 AI 跑一兩個小時，通常要開發一陣子，慢到連給個回饋都要等，才會注意到問題。

以我正在開發的 [Godot 擴充](https://github.com/elct9620/godot-mruby)來當案例，當我把 mruby 處理到接近可用時，我提出跑 CI 特別慢，我們該去補強，這實際上也很正常，大部分專案發展到一個規模後本來就會發生這樣的狀況。

但實際慢的點是什麼，基本上都是手寫時代不會犯的錯。像是在最初設計 CI 檢查時，為了比對有沒有錯，所以把整個測試跑了兩遍，砍掉就馬上快一倍，又或者是 Godot 編輯器啟動時要索引檔案，但是 AI 完全沒有設計快取，所以每一次載入檔案需要重新掃描，時間複雜度變成 `O(M * N)` 而不是掃描一次檔案的 `O(N)` 這樣的錯誤。

但是功能有錯嗎？完全沒有任何錯，而且肯定可以運作得很好。

這都還算是幸運的案例，朋友也碰過實際部署的服務，但是 AI 並沒有看清楚 Cloudflare Workers 上 D1（資料庫）的計費方式，設計了大量寫入的設計，資料確實是即時更新，但是寫入的費用也讓帳單差點倍數成長。

而且這一切都沒有錯，測試也都有檢查，但是我們正默默地付出某種代價，而且可能比我們認知的更高。

## 解法？{#solution}

實際上我到目前為止也沒有好的解決方案，唯一能確定的是對於電腦科學的理解、對你正在使用的語言是否熟悉，都會大大影響我們能不能處理好這些問題，至少我先不管「設計是否優雅」這樣在手寫時代也很少人在意的問題。

使用有型別、跑得更快的語言會有幫助嗎？像是 DHH 在 [Rails World 2026](https://www.youtube.com/watch?v=vDjW_dRyKXY) 的演講那樣，當你不用閱讀原始程式碼，使用 Rust 也許是個選項，但這真的有幫助嗎？

前面我提到 Godot 擴充的案例就是使用 Rust 開發的，我們扣掉測試跑兩遍、編輯器反覆掃描那個看起來很蠢的問題，我還遇到了比原生的 GDScript 慢了快 10 倍的問題，這比我預估的 2 倍多還差非常大一截。

原因是什麼，雖然 Rust 很好地保證型別、記憶體上的安全，但是並不保證整個路徑都是最佳的，我在 mruby 的 Rust Binding 套件 [beni](https://github.com/elct9620/beni) 上找到了新的問題，原因是使用 Rust 包裝後確實獲得原本 C API 沒有的保護，但同時也做了「多餘」的檢查，原本 C API 就已經會確認，但是 AI 在包裝時「假設不安全」又再次檢查，最後這種幾微秒（microseconds）累積起來的，在遊戲情境中就是巨大的拖累。

我在今年 COSCUP 的 [讓 AI 接管你的應用](https://talks.aotoki.me/2026-08-09-coscup/)也花不少時間在解釋怎麼逐步地把「速度」推到極限，現在回過頭來看，這可能是某種新症狀的跡象，當我們可以快速地前進時，原本「後期」遇到的問題，是不是更快地浮現出來？

現在我總覺得在這個過程中少了什麼，即使我會很認真的思考結構、命名慣例這些問題，但是快速前進時，總像是少做了些什麼，至少網路上很常被討論的我都有試過，但似乎有某種更本質的問題，大家還沒找到一樣。