過去兩年，AI 程式設計助手從「玩具」變成了許多團隊的標配。自動補全、生成函式、甚至整段模組，都能在幾秒內完成。但在程式碼生成越來越廉價的今天，一位資深工程師的自白式文章，給出了不同的觀察：他仍然堅持手寫核心程式碼，並且找到一種方式讓 AI 幫忙，而不是代勞。
AI 的「最短路徑」偏好
作者從大量「vibecoding」專案中總結出一個規律：AI 幾乎總是更願意新增程式碼，而不是重構現有程式碼。這種方式雖然能避免「AI 把我的程式碼庫清空」這類極端事故，卻帶來另一個隱患——它把架構問題悄悄推遲到了未來。
比如，工程師讓 AI 實現一個功能，忘記交代某個細節，AI 會自行補上。它可能拼接一段重複邏輯，或者堆上多層 if-else，但幾乎不會主動說：「這個需求不改介面根本沒法乾淨地做。」有經驗的工程師通常在動手實現時就能察覺這一點，意識到小範圍重構能讓方案清晰得多。這種判斷，恰恰是當前 AI 最欠缺的。
更棘手的是，AI 生成的程式碼往往格式規範、註釋完整，看起來賞心悅目，但它真正存在的問題——架構錯位、冗餘程式碼、邊界情況沒處理——都藏在表層之下。在程式碼評審中，這些缺陷是最容易被忽略的。
guideme：把「怎麼寫」變成「改哪裡」
為了對衝 AI 的「短視」，作者給自己設計了一個叫 guideme 的 SKILL.md。它的工作方式與 Claude 的 Learning Mode 有些類似，但目標使用者是高階工程師，而不是新人。
這個技能不生成可直接貼上的程式碼塊，而是像交接入職任務一樣，告訴工程師：改動涉及哪些檔案、應該改什麼、為什麼這樣改，並附上相關模組的架構概覽。實現部分則完全交給工程師自己。
- 明確改動範圍，提供上下文
- 解釋設計動機，避免說教式的基礎講解
- 要求手工實現，讓架構問題暴露出來
作者強調，親手實現指南，正是發現審查漏掉的架構捷徑的關鍵時刻。機器生成的程式碼不會「卡住」，也不會告訴你這裡有個設計矛盾，但人會。
AI 程式設計工具的下一步
這個案例對 AI 程式設計工具的演進很有參考價值。它說明，AI 的價值不限於補全程式碼，也可以是幫助你更深刻地理解程式碼。與其讓 AI 當「自動補全器」，不如讓它當一個「帶路嚮導」。
對團隊而言，這也提醒我們：審查 AI 生成的程式碼時，別被表面的整潔迷惑，要額外關注結構是否合理、是否走了不必要的繞路。也許未來，更成熟的工具會在生成之前主動評估「是否應該重構」這個選項。
文章結尾的觀點很務實：AI 能幫你寫很多程式碼，但「怎麼寫更好看」這件事，至少目前，還是得靠人。
評論
暫無評論
成為第一個評論的人