11 posts
AI 寫程式遵循一條驗證梯度。後端在毫秒內完成驗證。網頁端需要幾分鐘。行動端需要幾小時。回饋循環的速度與確定性直接決定了 AI 寫程式在各技術層的實際效果與可靠程度。驗證速度沿著光譜遞減，決定了 AI 編碼在哪裡能自主迭代、在哪裡必須仰賴人類的判斷。
AI 模型自己寫程式這件事本身並不有趣。有趣的是它生成程式碼之後發生的事：模型能以多快的速度知道程式碼是否正確？生成與驗證之間的回饋循環有多緊密？ 這個循環決定了一切。它決定了模型能否迭代自己的輸出，決定了人類能否在不手動檢查的情況下信任輸出，也決定了 AI 寫程式究竟在哪些領域行得通。…
AI 程式設計對能從任何混亂中恢復的精英團隊有效。其他人得到的只有恐懼、失敗的 CI，以及被放棄的實驗。差距不在於模型。
觀察兩個團隊使用同一個 AI 模型，你會看到兩種完全不同的結果。 第一個團隊向模型下達提示，要求構建一個畫面。輸出接近正確，但不完全對。樣式偏離了 Figma 檔案。狀態管理碰到了不該碰的檔案。建置在本機通過，但在 CI…
大多數團隊嘗試 AI 輔助寫碼，交付的程式碼未能通過 QA，然後放棄。問題不在模型，而在於缺乏讓 AI 輸出值得信賴的防護機制。
大多數嘗試 AI 輔助寫碼的團隊，走的是同一條軌跡。 他們一開始充滿熱情。模型在幾分鐘內生成一項功能，他們交付出去。QA 捕捉到一個錯誤，於是他們交付一個修復。QA 又捕捉到另一個錯誤，這次是在一個本該毫無關聯的 module 裡。那個修復牽涉了十四個檔案，然後 QA 又發現了另外三個問題。…
你有型別檢查、語法檢查和架構規則。但你的確定性堆疊對複雜度、重複和命名災難視而不見。這裡有個零成本的解決方案。
讓我們誠實面對：大多數 AI 程式碼流水線目前的真實面貌是什麼。 你用 Cursor 或 Claude Code 產生程式碼。你執行 ，因為 TypeScript strict mode 能抓出型別不匹配。你執行 ESLint，因為沒人想在拉取請求裡為了分號爭吵。或許你會執行…
AI 程式開發工具擅長生成第一版。真正的工程挑戰從第四版開始——當團隊需要在不破壞其他一切的情況下修改某些東西。
每個 AI 程式開發的展示都遵循相同的弧線。有人對模型下達提示。一個能運作的應用程式就這樣出現了。觀眾印象深刻。 他們確實該如此。速度是真的。能力是真的。有 AI 參與時，第一版確實交付得更快。 問題是，第一版從來都不是困難的部分。 軟體工程的成本不集中在初始創建。它集中在第四、第五、第六次迭代：…
衡量 AI 生成程式碼品質的真正標準，不在於第一天是否能運作，而在於第三十天你能否替換它，而不需要 rewrite 其他所有東西。
大多數關於 AI 生成程式碼品質的討論，都聚焦在生成當下的正確性。輸出能編譯嗎？能通過測試嗎？符合規格嗎？ 這些只是基本門檻。它們無法告訴你真正的成本。 真正的衡量標準是可替換性：當需求改變時，你能以多低的成本刪除這個 module 並在相同的 contract 背後重新實作？ 如果答案是「輕而易舉」，AI…
人工審查不一致。AI 審查更糟。AI 生成 codebase 唯一可擴展的防禦是確定性 enforcement：讓建置失敗的規則，而非被忽略的建議。
對 AI 生成程式碼的標準建議是「仔細審查它」。 這建議正確但在規模化時毫無用處。 開發者在警覺、熟悉領域且沒有時間壓力時，審查 AI 輸出能發現問題。在其他所有情況下——也就是大多數情況——問題會溜過去。 用 AI 審查者抓 AI 生成的問題更不可靠。你在要求一個機率系統驗證另一個機率系統的輸出。失敗模式是相關的。…
當 AI 能從規格產生實作、測試與 contracts，槓桿最高的人類工作就會往上游移動。最需要被仔細審視的東西，其實是規格本身。
如果你已經用 AI 出貨超過幾個星期，你大概很熟悉這種感覺。 你打開一個 PR。程式碼夠乾淨。命名還不錯。測試也有。看起來沒有任何明顯壞掉的地方。但你就是覺得哪裡怪怪的。 也許邊界有點模糊。也許 contract 只是被暗示，卻沒有被明確寫出來。也許 happy path…
如果你想讓 AI-generated code 能在正式環境站得住，光靠 code review 不夠。你需要一套從 type constraints 到 mutation testing 與 runtime containment 的分層安全棧。
AI-generated code 最大的危險，不是它總是錯的。 真正危險的是，它經常「看起來已經對得足夠可以 merge」。 這正是風險所在。明顯有問題的 code 往往會被擋住。真正會進正式環境的是那種看起來合理、能過幾個 happy-path tests、卻悄悄削弱關鍵 boundary 的實作。…
這篇對 Stanford CS146S 的評論認為，它準確看見了 AI coding 的轉向，但真正決定長期品質的仍是 AI architecture：系統是否可替換、可約束、可持續演進。
Stanford 的課程代碼是 ，課名是 The Modern Software Developer，由 Mihail Eric 授課，是一門在 2025 年秋季首次開設的課程。想看課程的官方概覽和 syllabus 細節，可以直接到官方課程網站…
Design by contract、property-based testing、mutation testing、model checking 從來不是壞想法。真正的問題是它們長期需要太多專業判斷才能維持，而 AI 正在改變這筆帳。
軟體工程裡有很多方法，你一讀就會覺得「這本來就該這樣做」。 當然應該用 contracts 明確 function 能接收什麼、必須回傳什麼。當然 tests 不該只寫幾個人工挑選的例子，而應該驗證 properties。當然團隊不該把 coverage 當成品質代理，而應該真的去判斷 tests 能不能抓到…