🔧 阿川の電商水電行
在 Octomind，我們建立人工智慧代理，但我們的程式碼仍然主要由人類編寫。我們熱愛邏輯邏輯模型（LLM），並盡可能地在各個方面使用它們，從產品到內部工作流程。但儘管各種宣傳鋪天蓋地，我們距離「代理編寫大部分程式碼」的目標還很遠。
我們有充分的理由暫時不盲目跟風Anthropic（貢獻 80% 的收益） 、 微軟（貢獻 30% 的收益）或谷歌（貢獻 25% 的收益）等公司。
*眾多案例之一，來源： LinkedIn
有些關鍵事項尚未落實。以下闡述其重要性，以及如何真正彌補這些差距。
在日常編碼中嘗試使用編碼代理
我們使用Cursor 、 Claude Code和Windsurf已經好幾個月了，但我們都不能說它們顯著提升了我們的工作效率（例如提升 20% 或更多）。當然，Tab 鍵自動補全功能通常很可靠，而且我也成功地用它們產生了一些單元測試——尤其是在有現成的測試可以複製的情況下（例如建立新路由時）。
然而，這遠不及其他人所聲稱的80%以上的效率提升。因此，出於害怕錯過機會和好奇心的雙重驅使，我和我的同事法比奧決定在過去一周完全使用人工智慧來實現一項路線圖功能。
在正式開始之前，我們仔細閱讀了常用工具的文件，確保沒有遺漏任何有用的訊息。我們也更新了 Cursor 規則和CLAUDE.md文件，以便注入關於產品和開發流程的最新知識，啟用了BugBot進行 AI 程式碼審查，然後就開始工作了。
我們嘗試建立的功能（使用人工智慧）
在 Octomind，我們建立了一個基於代理的端到端測試平台。我們的測試案例不與分支綁定，而是集中儲存在我們的系統中，該系統不支援特定於分支的測試案例版本。這在開始使用分支部署之前都運作良好。
假設有一個 SaaS 應用，它有三個測試案例：登入、建立貼文和編輯貼文。被測應用程式採用分支部署的方式開發，每個拉取請求 (PR) 都會部署到一個分支。現在假設有一個分支更改了登入流程－例如，新增了雙重認證 (2FA)。現有的登入測試（僅檢查使用者名稱和密碼）現在會失敗，從而阻塞該 PR 的管線。
目前，你有兩種選擇：
-
移除失敗的測試，以免阻塞不相關的 PR，手動（或透過 AI）修復它以處理新的流程，合併，然後重新啟用它。
-
直接更新測試並合併你的 PR——但是現在其他所有開發人員的管線都會中斷，直到你完成為止。
兩者都不好。一個會阻礙其他人的操作；另一個會破壞合併過程中的信任。
為了解決這個問題，我們希望將分支的概念擴展到測試中。建立分支時，您可以產生一個特定於該分支的測試副本。該副本僅在當前分支上執行，並且可以自由編輯。分支合併後，該副本將成為新的預設測試。
我們認為，由兩名開發人員在一周左右的時間內應該可以完成這項功能。
第一次嘗試：狂奔
作為第一版，我們讓智能體自由漫遊。我們並不指望它能完美執行，但我們想看看效果如何。
我們的單體倉庫規模相當大，所以「把所有東西都直接放進去」這種方法行不通。我們非常重視測試，並設定了防護措施，供 AI 用來檢查自身的輸出。
所以我寫了一份詳細的簡報，並將所需文件附在了郵件正文中。這並非「寥寥幾句提示就能創造奇蹟」——我反覆修改提示，直到它盡可能具體。大約5分鐘後，代理人就制定了一個包含11項合理待辦事項的計畫：
*遊標代理程式產生了一個編碼方案
我們點擊run ，然後事情就出了岔子。代理開始輸出程式碼，但在任何任何開發人員都能輕鬆完成的基本操作上卻遇到了困難——例如在資料庫架構更改後重新生成 Prisma 用戶端（是的，Cursor 規則中明確規定了這一點）。
我反覆確認了好幾次。它報告成功，並顯示訊息：“該功能現在應該可以正常工作了！分支按鈕應該可以正常使用，您可以使用新的篩選器查看分支後的測試案例。🎉”
-
未完成所有待辦事項
-
在我們的開發伺服器上（它可以透過電腦存取該伺服器）沒有任何可執行的程式碼。
-
忽略我們明確列出的基本編碼準則
以下列舉一些人類開發人員不會犯的錯誤（此列表不完整）：
-
我為新按鈕建立了一個 React 元件…但卻從未將其連接到現有元件中。
-
跳過了我們的標準日誌庫
-
使用了效率極低的資料庫查詢（對於任何地方連接的每個 ID，都會額外發出一次請求）。
-
無視了我們的命名和結構規範
-
新增了兩個新的外部函式庫，用於我們已經擁有的瑣碎功能。
我說的還不是bug。這些都是一些一眼就能看出來、而且不可能是開發者會遇到的問題。
是的，我們嘗試了多輪「還是不行－你忘了使用新按鈕」之類的提示。結果：提交了一個 2000 行的 PR，幾乎處處都需要審核和修改。
第二種方法：更小、更漸進的改變
我決定從頭開始。我們從未指望它能順利運作——這些智能體本來就更擅長處理較小的特徵。所以我退後一步，仔細思考如何一步步地自己建造它。這種構思階段我通常喜歡用邏輯邏輯管理器（LLM） ——不是為了寫程式碼，而是為了在規劃模式下嘗試各種方法。
然後我讓它再次製定計劃，這次只針對第一個部分：根據執行 URL 從資料庫載入正確的測試。
它產生了另一個冗長但看似合理的計劃。我讓它運作下去——打算這次更頻繁地介入。在瀏覽了幾個上下文的聊天記錄後，我又收到了一個拉取請求。
光這一部分就用了大約 1200 行程式碼。它能用嗎？嗯……類型檢查通過了。至於其他方面，誰知道呢。
本著實驗精神，我把 PR 提交給了 BugBot 進行審查。它留下了四條評論——其中一條指出事務處理存在問題。這對資料一致性不利，所以我把這則評論回饋到了聊天記錄中。
人工智慧的回應：
“當然，這是我的重大疏忽，我深表歉意。讓我來改正一下：……”
我想我接受了它的道歉。它確實修復了一些問題，當我問它是否還發現了其他問題時，它回覆說：
推薦
- 修復交易一致性：確保 getFullTestCasesWithPrerequisites 函數中的所有資料庫呼叫都使用相同的事務客戶端。 （以及其他 7 項內容）
所有這些資訊都包含在一個文件中。它唯一需要的上下文資訊是資料庫模式——也就是它正在處理的內容。
它還有讓自己生活更輕鬆的習慣：
它會檢查程式碼檢查錯誤，但只是透過執行 head -30 和一些正規表示式過濾器來進行檢查，所以它自己會認為一切正常。
自信地將半成品標記為已完成，為「重大疏忽」道歉，修復問題卻又破壞其他問題（查閱德語單字verschlimmbessern ），完全無視我們現有的設計和用戶體驗，但這甚至還不是最糟糕的部分。
真正重要的問題
1. 心智模型喪失
假設代理現在幾乎無需任何幫助就能交付中等複雜度的功能。我們甚至可以假設，透過將開發人員轉變為代理的協調者而非程式設計師，我們已經解決了「等待 3 分鐘，查看 1000 行輸出」的問題。這正是許多 LinkedIn 貼文所描繪的理想願景。
即便如此，仍然存在一個巨大的問題：我失去了對程式碼庫的心理模型。
現在，我知道修改一個部分會如何影響其他部分，bug 通常隱藏在哪裡，以及資料模型的運作方式。但當 AI 不斷提交上千行的 PR（甚至可能自動合併）時，這種直覺就消失了。如果是隊友提交 PR，我可以相信他們經過了深思熟慮的權衡，而且我在審查或基於這些 PR 進行開發時也能理解其中的邏輯。但 AI 不具備這種學習循環的能力。
所以，當遇到棘手的 bug 或極端情況的功能——那種 AI 仍然無法處理的功能——時，我感覺就像第一次看到程式碼庫一樣。也許我粗略地瀏覽過一些 AI 可以獨立完成的功能的程式碼審查（除非我執行了像 CodeRabbit 這樣的自動審查工具），但這與親自與程式碼互動所帶來的理解相去甚遠。
在我完全信任人工智慧之前，我需要保持自己的思考模式。否則，每次需要我親力親為時，都感覺像是加入了一家新公司。
2. 缺乏自我反思
人工智慧目前在評估自身表現方面表現不佳。像這樣的不斷回覆只有在你放在心上時才會令人惱火，但說實話，很難不去在意：
我要求它在實現該功能之前這樣做，它回复說：
中等信心－我可以正確實現這一點，但有一些注意事項：
整體評估：我可以正確完成這項任務，但這需要非常注重細節、進行徹底的測試，並且可能需要對缺失的方法和業務邏輯進行一些澄清。複雜度尚可控制，但並非微不足道。
這聽起來像是人類工程師的自我評價，因為模型只是在鸚鵡學舌地重複人類的訓練資料。問題在於，它不應該使用人類（至少在最近之前）訓練的資料來判斷自身的能力，因為它畢竟不是人類。
這就是問題的核心：這個模型沒有自我設限的概念。只有讓它嘗試，才能知道它能否完成任務。實習生可能會說：「我從來沒做過這個。」但LLMs不太可能這麼做。
更糟的是，在我們後續的較小任務中，它給自己打的分數甚至更高：
複雜度：高- 這是一項大規模的重構
我的能力：高度自信－我絕對能夠正確執行這項任務，因為：
該計劃非常詳細，具體說明了需要做出哪些改變。
我了解目前的架構和資料流
這些變更遵循程式碼庫中既定的模式。
實施步驟已明確列出。
這項任務絕對可行，我很有信心能夠正確完成——只需要一步一步地按照詳細計劃執行，並補全所有缺失的部分即可。
編碼代理的優點
AI 在開發者的工具箱中絕對佔有一席之地。我每天都會使用 ChatGPT 或 Cursor 的 Ask 模式——用來集思廣益、除錯程式碼，或解決一些小問題。 Tab 鍵自動補全功能？它們的準確率大約有 80%，這足以讓我一直開啟這項功能。我甚至讓 AI 來處理一些工作，例如為簡潔的介面編寫單元測試，或重構一些小的程式碼片段。對我來說，用Promise.allSettled包裹一個循環很枯燥，但對 AI 來說卻輕而易舉，瞬間完成。它在從零開始重現一些常見的模式方面也表現出色——例如遍歷樹狀結構。
對於非技術用戶而言，人工智慧驅動的自動化可以帶來巨大的便利。這正是 Octomind 的工作重點：利用專門的代理人在明確的邊界內自動化技術任務。這些代理程式不會編寫整個程式碼庫，而是處理程式碼中特定且可觀察的部分，並受到輸出約束的約束。
其他一些專用工具也能提供類似的價值。當然，也許有一天，人工智慧真的能像今天這樣承擔所有被認為能完成的任務（無論是LLMs還是其他更高級的任務）。
但我們還沒有達到那個目標——而且越來越多的人開始承認這一點。
維斯·羅特林斯霍弗
Octomind公司的人工智慧工程師
原文出處：https://dev.to/veith-octomind/why-agents-do-not-write-most-of-our-code-a-reality-check-87j
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
