原文標題：關於放慢速度的想法
原文作者：Mario Zechner
翻譯：Peggy，BlockBeats

編者按：隨著生成式人工智慧加速進入軟體工程領域，行業情緒正從「能力驚歎」轉向「效率焦慮」。寫得不夠快、用得不夠多、自動化不夠徹底，似乎都會讓人產生被淘汰的壓力。但當編碼 Agent 真正進入生產環境時，一些更現實的問題開始浮現：錯誤被放大、複雜度失控、系統漸漸變得難以理解，效率的提升並沒有等比例轉化為質量的提升。

本文基於一線實踐，對這輪「agentic coding」熱潮進行了冷靜反思。作者指出，Agent 並不會像人類一樣在錯誤中學習，在缺乏瓶頸與反饋機制的情況下，小問題會被快速放大；而在複雜代碼庫中，其局部視角與有限召回能力，又進一步加劇了系統結構的混亂。這些問題的本質，並不在於技術本身，而在於人類在焦慮驅動下，將判斷與控制過早交出。

因此，與其陷入「是否必須全面擁抱 AI」的焦慮，不如重新校準人與工具的關係：讓 Agent 承擔局部、可控的任務，而將系統設計、質量把關與關鍵決策牢牢掌握在自己手中。在這個過程中，「慢下來」反而成為一種能力，它意味著你仍然理解系統、能夠做出取捨，也仍然保有對工作的掌控感。

在工具不斷進化的時代，真正稀缺的，或許不是更快的生成能力，而是對複雜性的判斷力，以及在效率與質量之間做出選擇的定力。

以下為原文：

烏龜的那張臉，就是我看這個行業時的表情

大約一年前，真正能夠幫你「從頭到尾做完整專案」的編碼 Agent 開始出現。更早之前也有像 Aider、早期 Cursor 這樣的工具，但它們更像助手，而不是「代理」。新一代工具極具吸引力，很多人也花了大量業餘時間，把那些一直想做卻沒時間做的專案全做了一遍。

我覺得這本身沒問題。用業餘時間做東西本來就很快樂，而且大多數時候你也不太需要在意代碼質量和可維護性。這也給了你一個學習新技術棧的路徑。

聖誕假期期間，Anthropic 和 OpenAI 還發了一些「免費額度」，像老虎機一樣把人吸進去。對很多人來說，這是第一次真正體驗到「Agent 寫代碼」的魔法。參與的人越來越多了。

如今，編碼 Agent 也開始進入生產代碼庫。12 個月過去，我們開始看到這場「進步」的後果了。下面是我目前的看法。

一切都壞掉了

雖然這些大多只是經驗之談，但現在的軟件確實給人一種「隨時會碎」的感覺。98% 的可用性，正在從例外變成常態，哪怕是大型服務也不例外。用戶界面裡充滿了各種離譜的 bug，本該是 QA 團隊一眼就能抓到的那種。

我承認，這種情況在 Agent 出現之前就已經存在。但現在，問題明顯在加速。

我們看不到公司內部的真實情況，但偶爾會有一些信息洩露出來，比如那次傳聞中「AI 導致的 AWS 崩潰」。Amazon Web Services 隨後第一時間「更正」了說法，但緊接著又在內部啟動了一個 90 天的重整計劃。

Satya Nadella（Microsoft CEO）最近也一直在強調，公司裡有越來越多的代碼是由 AI 寫的。雖然沒有直接證據，但確實有一種感覺：Windows 的質量在下滑。甚至從微軟自己發布的一些部落格來看，他們似乎也默認了這一點。

那些聲稱「產品 100% 代碼由 AI 生成」的公司，幾乎總是在輸出你能想象到的最糟糕的產品。不是針對誰，但動輒以 GB 計的內存洩漏、UI 混亂、功能殘缺、頻繁崩潰……這些都絕不是他們以為的「質量背書」，更不是「讓 Agent 替你幹一切」的正面示範。

私下裡，你會越來越多地聽到，無論是大公司還是小團隊，都在說一件事：他們已經被「Agent 寫代碼」逼進了死胡同。沒有代碼審查，把設計決策交給 Agent，再堆上一堆沒人需要的功能——結局自然不會好。

我們為什麼不該這樣使用 Agent

我們幾乎已經放棄了所有工程紀律和主觀判斷，轉而陷入一種「上癮式」的工作方式：目標只有一個——在最短時間內生成最多代碼，至於後果如何，完全不在考慮之內。

你在搭一個編排層，去指揮一支自動化 Agent 軍隊。你裝了 Beads，卻完全不知道它本質上幾乎就是個卸不掉的「惡意軟體」。只是因為網上說「大家都這麼做」。不這麼幹你就「要完蛋」（ngmi）。

你在不斷「套娃式循環」裡自我消耗。

看——Anthropic 用一群 Agent 做了個 C 編譯器，雖然現在還有問題，但下一代模型肯定能修好，對吧？

再看——Cursor 用一大群 Agent 做了個瀏覽器，雖然現在基本不可用，還需要人時不時手動干預，但下一代模型肯定能搞定，對吧？

「分佈式」「分而治之」「自治系統」「黑燈工廠」「六個月解決軟體問題」「SaaS 已死，我奶奶剛用 Claw 搭了個 Shopify」……

這些敘事聽起來很爽。

當然，這種方式對於你那種幾乎沒人用（包括你自己）的 side project，可能確實「還能跑」。也許，確實存在某個天才，能用這種方式做出一個不垃圾、真正被人使用的軟體產品。如果你就是那個人，那我真心佩服。

但至少在我身邊的開發者圈子裡，我還沒見過這種方法真的有效的案例。當然，也許只是我們都太菜了。

錯誤在無學習、無瓶頸、延遲爆發中不斷疊加

Agent 的問題在於：它們會犯錯。這本身沒什麼，人類也會犯錯。可能只是一些正確性錯誤，容易識別、也容易修復，再補一個回歸測試就更穩了。也可能是一些 linter 抓不住的程式碼味道：這裡一個沒用的方法、那裡一個不合理的類型、還有重複程式碼之類。這些單獨來看都無傷大雅，人類開發者同樣會犯這種小錯誤。

但「機器」不是人。人類重複犯幾次同樣的錯誤後，通常會學會不再犯——要麼是被人罵醒了，要麼是在真正的學習過程中改掉了。

而 Agent 沒有這種學習能力，至少默認是沒有的。它會一遍又一遍重複同樣的錯誤，甚至還可能基於訓練數據「創造」出不同錯誤的奇妙組合。

你當然可以嘗試「訓練」它：在 AGENTS.md 裡寫規則，讓它別再犯這種錯誤；設計一套複雜的記憶系統，讓它查詢歷史錯誤和最佳實踐。這在某些特定類型的問題上確實有效。但前提是——你必須先觀察到它犯了這個錯誤。

更關鍵的差異在於：人類是瓶頸，而 Agent 不是。

人類不可能在幾個小時內吐出兩萬行程式碼。即使犯錯頻率不低，一天也只能引入有限數量的錯誤，這些錯誤的累積是緩慢的。通常，當「錯誤帶來的痛苦」累積到一定程度，人類（出於本能厭惡痛苦）會停下來修一修。或者人被替換掉，由別人來修。總之，問題會被處理。

但當你用一整套編排好的 Agent「軍隊」時，就沒有瓶頸，也沒有「痛感」。這些原本微不足道的小錯誤，會以不可持續的速度疊加。你已經被移出了循環，甚至不知道這些看似無害的小問題，已經長成了一個龐然大物。等你真正感受到痛苦時，往往已經太晚了。

直到某一天，你想增加一個新功能，卻發現當前的系統架構（本質上已經是錯誤的堆積）根本無法支持修改；或者使用者開始瘋狂投訴，因為最新一次發佈出了問題，甚至丟了數據。

這時你才意識到：你已經無法信任這套程式碼了。

更糟的是，你讓 Agent 生成的成千上萬的單元測試、快照測試、端到端測試，同樣不再可信。唯一還能判斷「系統是否正常運作」的方式，只剩下手動測試。

恭喜，你把自己（以及公司）坑慘了。

複雜性的販賣者

你已經完全不知道系統在發生什麼了，因為你把控制權交給了 Agent。而 Agent，本質上是在「販賣複雜性」。它們在訓練數據中見過大量糟糕的架構決策，在強化學習過程中也不斷強化這些模式。你讓它來設計系統，結果可想而知。

你最終得到的是：一整套極其複雜的系統，混雜著各種「行業最佳實踐」的拙劣模仿，而你在問題失控之前，並沒有加以約束。

但問題還不止於此。你的 Agent 彼此之間並不共享執行過程，也看不到完整的程式庫，更不了解你或其他 Agent 之前做出的決策。因此，它們的決策始終是「局部的」。

這就直接導致了前面提到的那些問題：大量重複程式碼、為抽象而抽象的結構、各種不一致。這些問題不斷疊加，最終形成一個不可挽回的複雜系統。

這其實和人類寫的企業級程式庫很像。只是那種複雜性通常是多年累積的結果：痛苦被分散在大量人身上，每個人都沒到「必須修」的臨界點，組織本身的容忍度又很高，於是複雜性與組織一起「共生演化」。

但在人類 + Agent 的組合下，這個過程會被極大加速。兩個人，加上一堆 Agent，幾周就能達到這種複雜度。

Agentic 搜索的召回率很低

你可能會寄希望於 Agent 來「收拾殘局」，幫你重構、優化、讓系統變得乾淨。但問題是：它們已經做不到了。

因為程式庫太大、複雜度太高，而它們始終只能看到局部。這不僅僅是上下文視窗不夠大，或者長上下文機制在百萬行程式碼面前失效這麼簡單。問題更隱蔽。

在 Agent 嘗試修復系統之前，它必須先找到所有需要修改的程式碼，以及可以複用的已有實現。這一步，我們稱為 agentic search（Agent 搜索）。

Agent 如何做這件事，取決於你給它的工具：可以是 Bash + ripgrep，可以是可查詢的程式碼索引、LSP 服務、向量數據庫……

但無論用什麼工具，本質都一樣：程式庫越大，召回率越低。而召回率低意味著：Agent 無法找到所有相關程式碼，自然也無法做出正確修改。

這也是為什麼一開始那些「程式碼味道」的小錯誤會出現，它沒找到已有實現，於是重複造輪子，引入不一致。最終，這些問題會不斷擴散、疊加，開出一朵極其複雜的「爛花」。

那我們該如何避免這一切？

我們應該如何與 Agent 協作（至少目前）

編碼 Agent 就像海妖，用極快的程式碼生成速度和那種「斷斷續續但又時不時驚艳」的智能把你吸引進去。它們往往能以驚人的速度、高質量地完成一些簡單任務。真正開始出問題，是你產生這樣一種想法的時候——「這玩意太強了，電腦，替我幹活吧！」

把任務交給 Agent 本身當然沒問題。好的 Agent 任務通常具備幾個特徵：範圍可以被很好地限定，不需要理解整個系統；任務是閉環的，也就是說 Agent 可以自行評估結果；輸出不是關鍵路徑，只是一些臨時工具或內部使用的軟體，不會影響真實用戶或收入；又或者你只是需要一個「橡皮鴨」來輔助思考——本質上是把你的想法拿去和互聯網的壓縮知識以及合成資料做一輪碰撞。

如果滿足這些條件，那麼這就是適合交給 Agent 的任務，前提是，你作為人類，仍然是最終的品質把關者。

比如，用 Andrej Karpathy 提出的 auto-research 方法來優化應用啟動時間？很好。但前提是你清楚，它吐出來的程式碼絕對不具備生產可用性。auto-research 之所以有效，是因為你給了它一個評估函數，讓它可以圍繞某個指標（比如啟動時間或 loss）進行優化。但這個評估函數只覆蓋了一個非常狹隘的維度。Agent 會理直氣壯地忽略所有不在評估函數裡的指標，比如程式碼質量、系統複雜度，甚至在某些情況下連正確性都可以忽略——如果你的評估函數本身就有問題的話。

核心思路其實很簡單：讓 Agent 去做那些無聊的、不會讓你學到新東西的事情，或者那些你本來沒時間嘗試的探索性工作。然後由你來評估結果，挑出真正合理、正確的部分，再完成最終實現。當然，最後這一步你也可以借助 Agent 完成。

但我更想強調的是：真的，該慢下來一點了。

給自己時間去思考，你到底在做什麼、為什麼要做。給自己一個說「不」的機會，「不，這個我們不需要。」給 Agent 設定一個明確的上限：每天允許它生成多少程式碼，這個量應該與你實際能夠審查的能力相匹配。所有決定系統「整體形態」的部分，比如架構、API 等都應該親自寫。你可以用自動補全找點「手寫程式碼的感覺」，也可以和 Agent 結對編程，但關鍵是：你必須在程式碼裡。

因為，親自寫程式碼，或者看著它一步一步被構建出來，這種過程本身會帶來一種「摩擦感」。正是這種摩擦，讓你更清楚自己到底想做什麼、系統是怎麼運作的、整體「手感」如何。這正是經驗與「品味」發揮作用的地方，而這恰恰是當前最先進的模型還無法替代的。慢下來，承受一點摩擦，恰恰是你學習和成長的方式。

最終，你得到的會是一個依然可維護的系統——至少不會比 Agent 出現之前更糟。是的，過去的系統也不完美。但你的用戶會感謝你，因為你的產品是「好用的」，而不是一堆糊出來的垃圾。

你做的功能會更少，但更正確。學會說「不」，本身就是一種能力。你也可以安心睡覺，因為你至少還知道系統在發生什麼，你仍然掌握主動權。正是這種理解，讓你能夠彌補 agentic search 的召回問題，讓 Agent 的輸出更可靠、需要更少修補。

當系統出問題時，你可以親自下場修復；當設計一開始就不合理時，你也能理解問題所在，並把它重構成更好的形態。至於有沒有 Agent，其實沒那麼重要。

這一切，都需要紀律。這一切，都離不開人。

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia