起步飛馳審查蝸行：AI編程的雙面賬本

周三上午十點，一名全棧工程師打開編輯器，開始處理一個新需求。他做的第一件事不是翻看內部文檔，也不是在 Slack 里翻聊天記錄，而是把 Jira 任務描述、接口規范和幾條相關的代碼片段一起扔給 AI 助手，并附上一句：“幫我總結一下上下文，然后給出一個初始實現方案?！?/p>

這是當下不少開發者的日常。AI 已經深度嵌入了他們的工作流——不是作為一次性代碼生成器，而是充當一個隨叫隨到的上下文整合器。在 Webflow 的工程團隊里，類似的變化正在被反復討論：AI 在工程工作流中的角色到底是什么？他們給出的定位很清晰：不是一個幫你繞過判斷的捷徑，而是一套幫你在真實產品工作中減少摩擦、增強上下文感知的輔助系統。

但這個故事還有一個不太舒服的下半句。AI 沒有讓工程變得魔法般簡單。那些煩人的、瑣碎的、耗費心力的工作沒有消失，它們只是換了一副面孔，帶著更體面的簡歷重新回來了。對這位工程師來說，最大的變化在于：AI 讓“啟動和執行”變得快得驚人，但接下來的一切——審查輸出、理解隱含假設、保持拉取請求小而精、按正確順序合并代碼，以及確保兩周后還能向同事解釋清楚自己寫的代碼——反而變得更慢了。

這就形成了一組清晰的對抗性事實。正方會告訴你：AI 徹底消除了“上下文狩獵”的痛苦，讓工作的起步速度提升了不止一個量級。在 AI 深度介入每日工作之前，一名工程師處理任務的典型路徑是從 Slack 和 Jira 里找對齊信息，翻 Confluence 和內外部文檔，查框架手冊，如果運氣不好，還得在 Google、Stack Overflow、Reddit、GitHub Issues 之間反復橫跳，最后才去敲一位可能見過同樣問題的同事。這一套流程有時會演變成結對編程，有時變成調試馬拉松，有時則是兩小時的試錯之后將過程描述為“調研”——這在技術上沒有撒謊，但在情感上是一種寬容的修辭。尤其對于從純前端領域往后端、數據庫、全棧拓展的工程師而言，這種上下文搜尋的摩擦要更加顯著?？蚣茉谧儯ぞ哝溤谧儯B NPM 包失敗的理由都像在針對你。大量的時間不是花在寫代碼上，而是花在獲取足夠信息來寫正確的代碼上。

AI 把這一階段的時間壓縮到了極致。現在，借助像模型上下文協議這樣的工具，開發者可以直接讓 AI 跨系統抓取并綜合相關信息，而不必在不同窗口之間手動切換。原本可能要花上半小時甚至更久的“開工前準備”，現在可能被縮短到幾分鐘。這種提速效應不僅體現在尋找信息，更體現在降低對陌生技術棧的恐懼感上。曾經需要數周才能建立初步直覺的領域，如今通過與 AI 的反復對話，入門曲線被明顯削平。從這里看，AI 帶來的價值幾乎無可爭議。

但反方馬上會拋出一組截然不同的觀察。代碼寫得更快，并不意味著整體交付變得更快。當生成速度遠遠超過了審查、集成和理解的速度時，瓶頸就從編碼環節轉移到了認知環節。AI 給出的輸出往往帶著許多看不見的假設和對特定上下文的依賴，如果你沒有逐行消化這些隱含前提，合并后的代碼就會成為技術債的結晶。更棘手的是，為了保持拉取請求足夠小而易于審查，開發者不得不額外花費精力去拆分 AI 一次生成的大段代碼，按照正確的邏輯順序提交，并在多個分支間管理合并關系。曾經可以自然伴隨編碼過程而產生的解釋性記憶，現在需要刻意付出額外努力才能建立。兩周后當你回過頭去維護這段代碼時，那種“這真的是我寫的嗎”的陌生感會變得更加強烈。

這種感覺意味著，上下文狩獵的痛苦并沒有被根除，只是被后置了。過去是在寫代碼之前花時間找信息，現在則是在寫完代碼之后花時間驗證和消化信息。而后者對注意力和認知儲備的消耗，可能比前者更大，因為它發生在一個已經完成了“交付”的心理狀態之后。從體驗上講，這就像把一筆技術債務從前置利息變成了后置高利貸。

那么，站在正反雙方的中間，應該如何理解這種 trade-off？一個務實的判斷是：AI 重新分配了工程工作中的“認知摩擦”，而不是消除了它。過去摩擦集中在起點——搞清楚該做什么、該怎么做；現在摩擦則集中在終點——確認做出來的東西是否真的是對的、是否是我能維護的。這個轉移是否劃算，取決于你從事的是哪一類工程工作。對于探索性項目、原型開發或一次性腳本而言，這種分配極其有利，因為審查和維護的終極需求很低。對于需要長期迭代的、多人協作的生產級系統，后置的摩擦可能會被放大，因此需要更嚴格的流程來約束 AI，包括將上下文鎖定在準確的系統約束內，要求生成內容帶有可追溯的來源引用，以及主動保持小批量、高頻率的審查節奏。

原文沒有給出一個非黑即白的結論，而是把這種體驗描述為一把雙刃劍。AI 使得工程的啟動和執行階段大幅提速，這是事實；但同樣真實的是，它也重新定義了那些“煩人事”的形態，讓它們在復盤、審查和長期維護的環節里重新冒頭。關鍵不在于判定 AI 是好是壞，而在于識別出自己當前所處的工程場景，更值得把摩擦放在左邊還是右邊。對于那些擁抱 AI 的團隊來說，或許真正的功課不是追求“更快地寫代碼”，而是建立一套能讓“寫完之后”同樣順滑的工程文化。