大家好，我是肆〇柒。做過程序猿的朋友，或者與程序猿群體走的近的朋友，應該了解程序猿這個群體，每天都在正面臨著日益增長的系統復雜性和高效交付的巨大壓力。為了提升生產力并應對這些挑戰，Gen AI 工具，尤其是軟件工程智能體（SWE agent，比如 cursor 等），逐漸成為了開發者的得力助手。這些智能體不僅能夠生成代碼片段，還能執行工具調用、迭代優化輸出，甚至在某些基準測試中展現出能夠媲美人類，甚至超越一些人類開發者的能力。然而，當面對現實世界中復雜且模糊的開發任務時，SWE agent 卻暴露出了明顯的局限性。正因如此，許多 SWE agent 被設計為與開發者協同工作，通過互動實現優勢互補。

下面是來自微軟的研究《Sharp Tools: How Developers Wield Agentic AI in Real Software Engineering Tasks》，將會深入探討開發者如何與 SWE agent 協作解決實際代碼庫中的開放問題，并與大家一起分析其中的溝通障礙以及影響成功的諸多因素。通過觀察 19 名開發者樣本，使用 Cursor Agent 解決 33 個開源項目中的開放問題，這個研究試圖填補該領域實證研究的空白，為優化開發者 - 智能體協作模式以及設計更高效的 SWE agent 提供一些依據。這些發現不僅關乎當下開發效率的提升，更將對未來軟件工程領域的協作范式產生深遠影響。

一些 Cursor Agent 的示例用法

一些概念與背景

軟件工程智能體（SWE agent）的定義

SWE agent 是一類能夠在軟件開發生命周期中自主執行復雜任務的智能體，其核心優勢在于基于環境反饋迭代細化輸出的能力。與傳統的非智能體工具（如代碼補全插件）僅提供單一響應不同，SWE agent 能夠自主搜索文件、修改代碼、運行終端命令，并根據執行結果調整后續操作。例如，在處理一個 GitHub 問題時，SWE agent 可以先分析代碼庫結構，再嘗試定位問題根源，生成修復代碼，并最終運行測試驗證結果。這種自主性和迭代性使得 SWE agent 在處理復雜任務時展現出巨大潛力。

SWE Bench 等基準測試的評估作用及局限性

SWE Bench 等基準測試為評估 SWE agent 的性能提供了標準化的度量方式。這些基準測試通常基于歷史 GitHub 問題，涵蓋了多種編程語言和任務類型，從而能夠量化比較不同智能體的代碼生成準確性、問題解決效率等關鍵指標。然而，其局限性在于主要關注智能體的自主性能，而忽略了與人類開發者協作的場景。現實世界的開發任務往往涉及團隊協作、需求變更等動態因素，智能體在這些情境下的表現可能與基準測試結果大相徑庭。因此，僅僅依賴基準測試無法全面反映 SWE agent 的實際應用價值。

研究方法

工具選擇

在眾多 SWE agent 中，研究者選擇了 Cursor Agent 作為研究工具。經過對 Cursor Agent、VSCode Agent Mode、Windsurf Cascade、Cline 等工具的對比分析，Cursor Agent 憑借其獨特優勢脫穎而出。它不僅支持在 IDE 內操作，提供流暢的開發體驗，還能自動結合用戶當前打開的文件和光標位置作為智能體上下文，使智能體能夠更精準地理解任務背景。例如，當開發者在某個函數附近請求代碼修改時，Cursor Agent 可以聚焦于該函數相關的代碼片段，而非整個文件，從而提高任務解決的針對性和效率。

任務與參與者選擇

要求參與者解決他們曾貢獻過的開源代碼庫中的開放問題，原因在于這些參與者對代碼庫結構和業務邏輯相對熟悉，能夠更有效地與智能體協作。研究者對代碼庫進行了嚴格篩選，確保其規模較大（源代碼文件數量超過 50 個）、近期活躍（過去一個月內有提交記錄）、以軟件為核心（非文檔或教程集合），并且在 GitHub 上獲得超過 500 次星標，以保證代碼庫的成熟度和實際開發價值。

參與者篩選依據包括公司內部員工身份、過去三個月內對目標代碼庫有貢獻記錄等。最終，19 名開發者參與了本研究。這些參與者的性別、年齡、種族 / 民族、編程經驗等基本特征如下表所示：

多樣背景體的執行軌跡、在對話中回溯等的參與者背景有助于提升研究結果的廣泛性和代表性。例如，不同編程經驗的開發者在與智能體協作時可能展現出不同的策略和行為模式，而不同地區的開發者可能受到當地開發文化和技術生態的影響，這些差異都將為研究提供豐富的視角。

實驗流程與操作

實驗開始前，研究管理員對參與者進行了 Cursor IDE 及其智能體功能的培訓。通過一個演示任務，參與者熟悉了如何與智能體交互，例如在聊天窗口中輸入提示、實時查看智能體的執行軌跡、接受或拒絕代碼變更等操作。這一培訓環節是為了確保參與者對工具的基本功能有清晰的理解，從而在實驗過程中能夠專注于任務解決而非工具學習。

在實驗過程中，參與者通過遠程控制研究管理員的系統進行問題解決。他們首先在 GitHub 上瀏覽代碼庫的開放問題列表，選擇一個自己認為能夠通過代碼修改解決的問題。然后，參與者使用 Cursor Agent 嘗試解決該問題，過程中盡量使用 AI 并進行口頭報告，以實時記錄他們的思考過程和操作動機。當完成一個問題后，研究管理員會與參與者共同選擇下一個問題，確保任務在類型（如特性請求與錯誤修復）、難度和范圍上具有多樣性。例如，如果第一個問題是錯誤修復，第二個問題可能鼓勵參與者選擇一個特性請求；若第一個問題較為簡單，后續問題則會更具挑戰性。

數據收集與分析方法

研究者收集了多類型的數據以全面捕捉開發者與智能體的協作過程。會話錄像包括視頻、音頻和屏幕錄制，用于定性編碼參與者的行為和與智能體的交互細節。研究者基于 CUPS 稅收法改編了參與者活動編碼表，新增了與智能體協作特有的行為狀態，如跟蹤智能體的執行軌跡、在對話中回溯等。具體行為分類詳見下表

參與者活動分類

同時，還對聊天軌跡進行了編碼，記錄參與者提供給智能體的上下文信息（如文件、代碼片段、外部鏈接）以及他們從智能體尋求的信息類型（如代碼變更解釋、測試運行等）。編碼分類依據見下表：

聊天軌跡分類法

此外，參與者在研究前后填寫的問卷數據也為研究提供了重要補充。預研究問卷收集了參與者的 demographics 信息以及他們對 AI 工具的先前使用經驗，這有助于我們了解這些背景因素如何影響參與者在實驗中的行為和表現。而 post - study 問卷則聚焦于參與者對工具的感知，如智能體在開發過程中的角色、工具設計特征的重要性等。

在數據分析過程中，主要采用定性分析方法，深入挖掘參與者的行為模式和協作策略，同時結合定量數據（如提示使用次數、任務成功率等）呈現趨勢。例如，下圖直觀展示了參與者處理不同任務時的成功率及時間投入分布。

按參與者劃分的成功率問題時間線

為了確保編碼的一致性和可靠性，研究者計算了 Cohen’s κ 值，結果顯示參與者活動編碼和聊天軌跡編碼的信度均達到近完美的一致性。此外，還進行了成員審查，將初步研究結果反饋給參與者，以驗證結果的準確性和完整性。

研究結果

開發者與 SWE 智能體的協作模式

任務分配策略

在任務分配方面，開發者主要采用兩種策略：一次性任務分配策略（一槍式策略）和逐步解決策略。采用一槍式策略的參與者有 10 人，他們將整個問題描述交給智能體，期望其能夠生成全面的修復方案。這種策略的優勢在于，如果智能體成功，開發者可以以極小的額外努力解決問題。然而，一旦智能體失敗，開發者就要理解智能體生成的代碼，還需花費大量時間迭代優化。例如，一位參與者提到，對于較為簡單的、局部性較強的錯誤修復任務，他傾向于使用一槍式策略，因為這類任務通常有明確的解決方案路徑，智能體能夠快速定位并修復問題。但在處理涉及多個代碼模塊交互的復雜特性請求時，該策略往往導致智能體生成的代碼與預期結果大相徑庭，開發者需要反復調整提示并引導智能體逐步完善代碼。

逐步解決策略則要求開發者手動將任務分解為多個子任務，并依次請求智能體解決每個子任務。使用此策略的參與者平均每個問題使用 11.0 個提示，而采用一槍式策略的參與者平均僅使用 7.0 個提示。盡管這種策略對開發者的主動性和溝通能力要求較高，但能夠更早地發現智能體的錯誤并及時糾正，從而提高任務成功率。例如，一位經驗豐富的開發者在處理一個涉及前后端交互的特性請求時，先請求智能體優化前端數據展示代碼，待驗證無誤后，再請求其修改后端數據處理邏輯。這種分步推進的方式使他能夠有效掌控任務進度和代碼質量。

從成功率來看，采用逐步解決策略的參與者在他們處理的問題中成功解決了 83%，而采用一槍式策略的參與者僅成功解決了 38% 的問題。這一顯著差異表明，逐步解決策略在復雜任務中更具優勢。然而，這兩種策略并非完全互斥。在實際協作過程中，開發者可能會根據任務的進展和智能體的表現動態調整策略。例如，一位開發者最初采用一槍式策略請求智能體生成一個完整的代碼模塊，但智能體生成的代碼部分邏輯有誤。此時，開發者轉而采用逐步解決策略，針對代碼中的每個錯誤邏輯分別向智能體發送提示進行修正，最終成功完成了任務。

實踐指導：對于逐步解決策略，開發者可以按照以下步驟實施：

1. 任務分解：將復雜問題分解為多個獨立的子任務，每個子任務應具有明確的輸入和輸出要求。例如，將一個特性請求分解為數據模型設計、業務邏輯實現和用戶界面適配三個子任務。

2. 初始提示制定：為第一個子任務制定清晰的提示，盡量包含上下文信息（如相關文件路徑、已有代碼片段）以幫助智能體理解任務背景。

3. 智能體反饋分析：在智能體完成子任務后，仔細審查其輸出（包括執行軌跡、變更解釋和 diff），評估是否符合預期。

4. 任務描述調整：根據智能體的輸出結果，調整后續子任務的提示內容。如果智能體在某個子任務中犯了錯誤，可在提示中明確指出錯誤并給出修正方向。

5. 迭代推進：重復步驟 2 至 4，直到所有子任務完成并整合為最終解決方案。

知識傳遞

在與智能體協作解決問題的過程中，參與者向智能體提供了兩類知識：上下文知識和專業知識。上下文知識主要來源于問題描述和環境背景（如測試日志），例如，參與者告知智能體某個函數在特定輸入條件下會拋出異常。專業知識則是基于開發者對代碼庫的深入理解和過往經驗，涉及代碼實現細節或編碼規范等，例如，一位開發者指出在該代碼庫中通常避免使用硬編碼的超參數，并建議使用配置文件進行管理。

研究發現，參與者提供專業知識的模式與軟件工程管理者分配工作的行為高度相似。管理者往往在初始任務分配時提供較為寬泛的指導，而在開發過程中根據工程師的反饋提供具體、針對性的建議。同樣，參與者在請求智能體生成新代碼變更時，通常較少提供專業知識（49% 的提示包含專業知識），但在請求智能體優化已生成代碼時，專業知識的提供比例上升至 65%。對于擔任管理職務的 12 名參與者而言，這種差異更為顯著，他們在請求新代碼變更時提供專業知識的比例為 45%，而在請求代碼優化時這一比例高達 75%。

進一步分析表明，參與者對代碼庫的熟悉程度和是否有使用 Cursor 的經驗顯著影響其專業知識的提供頻率。在研究前四個月對代碼庫有超過 10 次提交記錄的參與者，在尋求代碼變更時提供專業知識的比例達到 70%，而其他參與者僅為 48%。有 Cursor 使用經驗的參與者在尋求代碼變更時提供專業知識的比例更是高達 81%，且在請求代碼優化時專業知識提供比例達到 89%，遠高于請求新代碼變更時的 67%。這表明，隨著對代碼庫和工具的熟悉度增加，開發者更傾向于主動向智能體傳授專業知識，以引導其生成更高質量的代碼。例如，一位資深開發者在處理一個涉及代碼重構的問題時，憑借對代碼庫架構的深入理解，向智能體詳細說明了各個模塊之間的依賴關系和預期的重構目標，從而使智能體能夠生成符合整體架構規范的優化代碼。

實踐指導：為了有效傳遞專業知識，開發者可以：

1. 建立知識庫：整理代碼庫中的關鍵設計決策、架構規范和常見實現模式，形成文檔或模板。在與智能體協作時，將相關知識片段直接引用到提示中。例如，對于一個微服務架構項目，可以將服務間通信的規范（如 RESTful API 設計原則、消息隊列使用場景）整理成文檔，當請求智能體生成接口代碼時，將相關規范片段粘貼到提示中。

2. 采用類比和示例：在提示中使用類比或提供示例代碼，幫助智能體理解特定的實現方式。例如，“在之前的用戶認證模塊中，我們通過中間件實現權限驗證，類似地，請為訂單管理模塊實現一個權限驗證中間件，確保只有管理員角色可以訪問特定接口”。

3. 引導式提問：以問題的形式引導智能體思考專業知識點。例如，“根據我們項目的錯誤處理規范，網絡請求失敗時應該返回哪種格式的錯誤信息？請按照這一規范修改當前代碼”。

請求的任務類型

參與者需要請求智能體進行代碼修改以解決 GitHub 問題，還需要尋求代碼理解、測試運行、代碼審查等方面的幫助。具體而言，50% 的提示請求代碼變更，27% 的提示尋求代碼庫相關細節的解釋（代碼理解），16% 的提示要求運行測試，11% 的提示請求對智能體所做變更的解釋（代碼審查）。這一任務請求分布與參與者對智能體角色的認知高度一致。在 post - study 問卷中，參與者普遍將智能體視為內容生成器，認為其最擅長生成代碼。同時，由于將智能體視為參考指南，他們也頻繁請求智能體解釋代碼庫結構和現有代碼邏輯。然而，參與者對智能體作為代碼審查者的期望相對較低，因此在請求測試運行和代碼審查方面的提示較少。

Agent 感知研究后續問卷調查結果

例如，在處理一個涉及復雜算法實現的問題時，一位開發者首先請求智能體解釋算法的核心思想和現有代碼實現的優缺點（代碼理解），然后基于智能體的解釋提出改進方案，并請求智能體生成優化后的代碼（代碼變更）。在代碼生成后，開發者又要求智能體運行相關測試用例以驗證代碼的正確性（測試運行）。在整個過程中，開發者僅在智能體生成代碼后簡單查看了其變更解釋，并未深入借助智能體進行代碼審查。

實踐指導：針對不同類型的任務請求，開發者可以采用以下實踐方法：

1. 代碼理解任務：

• 使用具體的問題引導智能體，如“在用戶登錄流程中，哪個函數負責驗證用戶名和密碼的格式？請解釋其正則表達式規則”。
• 結合代碼片段請求解釋，例如，“針對以下代碼片段（粘貼代碼），解釋其在處理并發請求時的線程安全機制”。

2. 測試運行任務：

• 明確指定測試范圍和預期結果，如“請為 User 模型的 save 方法編寫單元測試，覆蓋正常保存、字段驗證失敗和數據庫連接異常三種情況，并輸出測試結果”。
• 在測試失敗時，要求智能體分析失敗原因，如“測試用例 test_login_failed 報錯，根據錯誤信息和代碼，分析可能的原因并提出修復建議”。

3. 代碼審查任務：

? 提供審查標準或檢查列表，引導智能體按照特定規范進行審查。例如，“根據公司的代碼審查規范（粘貼規范要點），審查我提交的代碼變更，指出不符合規范的地方”。

? 將審查范圍限定在特定方面，如“僅從代碼可讀性角度審查以下函數（粘貼函數），提出改進意見”。

手動操作

參與者對智能體的角色認知深刻影響了他們在協作中的自身角色定位。在驗證（調試和測試）和內容生成（編寫代碼）方面，這種影響尤為顯著。盡管智能體能夠生成代碼變更，但由于參與者對其在調試和測試等驗證任務上的能力缺乏信任，往往主動承擔起手動調試和測試工作。在 33 個問題中，參與者手動調試和測試代碼的案例多達 21 個。例如，一位開發者在處理一個涉及用戶界面交互的錯誤修復任務時，盡管智能體生成了看似合理的代碼，但開發者仍選擇手動在本地瀏覽器中運行代碼并觀察用戶界面行為，以確保修復效果符合預期。

相比之下，參與者在內容生成方面的手動操作較少，僅在 14 個問題中手動編寫代碼，其中 10 個問題的代碼干預局限于修改智能體建議的代碼，而非新增功能代碼。這表明，開發者對智能體生成代碼的能力持有較高信任，但在驗證環節更傾向于親力親為。部分參與者也表達了希望 AI 工具在審查和驗證方面提供更有力支持的觀點，認為這將大幅提高開發效率并降低錯誤風險。

在實際開發項目中，這種現象具有普遍性。例如，在敏捷開發團隊中，開發者通常會借助智能體快速生成代碼原型，但在代碼審查和測試環節，仍需依賴團隊成員的協作和手動操作。這種協作模式不僅影響項目進度（如因手動調試導致迭代周期延長），還對代碼質量產生關鍵影響（如智能體生成的代碼可能存在隱藏的邏輯缺陷，需通過人工測試發現）。

實踐指導：為了平衡手動操作與智能體協作，開發者可以采取以下措施：

1. 驗證任務分配：在開始任務前，明確劃分智能體和開發者的驗證職責。例如，智能體負責運行自動化測試套件并報告結果，開發者負責分析復雜場景下的運行時行為和邊界條件測試。

2. 逐步轉移驗證任務：對于智能體能力范圍內的驗證工作，先讓智能體嘗試完成，開發者對其輸出進行抽檢。例如，智能體生成單元測試代碼并執行，開發者隨機選擇部分測試用例進行復查，根據復查結果決定是否擴大智能體的驗證權限。

3. 代碼生成協作：在代碼生成過程中，開發者可以先使用智能體生成代碼框架，然后手動填充關鍵業務邏輯細節。例如，智能體生成一個數據訪問層的代碼模板，開發者添加具體的數據庫查詢優化邏輯。

審查輸出

智能體通過三種方式與參與者溝通：執行軌跡、變更解釋和變更 diff。執行軌跡是智能體工作時的實時記錄，包括代碼庫搜索、文件讀取、終端命令執行等操作步驟。變更解釋是智能體在執行結束后對所做變更的總結性描述，而變更 diff 則直觀展示了代碼的具體修改內容，供參與者接受或拒絕。

研究觀察到，參與者傾向于實時跟蹤智能體的執行過程，這一行為在 84% 的提示中得到體現。而對于 23% 的提示，參與者僅通過實時觀察執行軌跡即可完成驗證，無需進一步審查 diff 或解釋。通常，實時分析足以使參與者理解智能體的上下文收集步驟，例如，智能體搜索了哪些相關文件、執行了哪些初步命令等。在大多數情況下（75% 的智能體響應后），參與者會進一步審查 diff 或解釋。其中，參與者更偏好直接審查代碼變更 diff，而非閱讀變更解釋。在包含代碼變更的智能體響應中，參與者在 95% 的情況下實時跟蹤執行過程，但在 67% 的情況下需要進一步審查 diff，而僅在 31% 的情況下審查解釋。即便在同時審查 diff 和解釋的情況下，這一比例也僅為 23%。

這種對代碼變更的直接審查偏好在 post - study 問卷中得到了印證。參與者將能夠查看詳細代碼變更解釋的功能評為相對不重要的特性。

Agent 特性學習后問卷調查結果

具有 Cursor 使用經驗的參與者對解釋的關注度甚至更低，他們在包含代碼變更的智能體響應中僅閱讀 18% 的解釋，而其他參與者為 35%。盡管如此，這種直接審查代碼的行為通常足以使參與者對智能體的代碼變更形成清晰理解，并且僅在 16% 的后續提示中詢問智能體關于生成變更的解釋。這表明，開發者對智能體輸出的信任建立在對代碼變更的直接審查之上，而非依賴智能體提供的文字解釋。

實踐指導：優化輸出審查流程的建議如下：

1. 實時跟蹤優先：在智能體執行任務時，保持對其操作的實時觀察，重點關注其對代碼庫的搜索路徑和文件訪問順序，這有助于快速了解智能體是否在正確的方向上工作。

2. diff 審查要點：

? 對于代碼修改部分，檢查是否符合代碼風格規范（如命名約定、縮進規則）。

? 分析邏輯變更是否完整，是否存在遺漏的邊界條件處理。

? 驗證與現有代碼的集成點是否正確，例如函數調用參數是否匹配、數據類型轉換是否合理。

3. 解釋利用策略：將智能體的解釋作為輔助參考，當 diff 審查中發現疑問時，回溯解釋以理解智能體的修改動機。例如，如果發現智能體修改了一個配置文件，通過解釋確認其目的是為了適配新功能的環境變量要求。下圖可以直觀地展示出智能體輸出的代碼變更 diff 的形式，有助于大家理解開發者在面對智能體輸出錯誤時所看到的內容。

由Agent建議的代碼編輯差異

處理錯誤輸出

面對智能體生成的錯誤代碼，參與者更傾向于迭代優化而非直接放棄重來。在所有問題中，平均每個問題參與者使用 8.2 個提示，其中 52% 的提示用于優化智能體之前生成的代碼變更。這一現象在特性請求任務中尤為突出，參與者平均使用 11.2 個提示，而錯誤修復任務中這一數字僅為 6.3。例如，在處理一個涉及新功能開發的問題時，智能體最初生成的代碼實現了基本功能，但在與現有代碼集成時出現了兼容性問題。參與者隨后多次向智能體發送提示，逐步引導其優化代碼，以確保新功能與整體系統無縫集成。

盡管迭代優化是參與者的首選策略，但部分參與者也表達了對其潛在風險的反思。一位參與者指出，如果開發者持續要求智能體修復其先前的錯誤代碼，可能會陷入錯誤路徑，浪費大量時間。例如，智能體在處理某個錯誤修復任務時，因誤解問題根源生成了一系列錯誤代碼。開發者在多次迭代后才發現智能體的初始假設存在偏差，不得不重新調整提示方向，導致任務解決時間大幅延長。此外，智能體的“不請自來的操作”現象（即超出提示范圍進行更改）在一定程度上反映了其在任務邊界識別方面的技術缺陷。在 38% 的未請求代碼變更提示后，智能體仍進行了額外更改，有時雖能提高效率，但更多時候會造成溝通誤解和開發者的困惑。

實踐指導：為了有效處理錯誤輸出，開發者可以遵循以下步驟：

1. 錯誤定位：在收到智能體的錯誤代碼后，首先明確錯誤類型（如語法錯誤、邏輯錯誤、與需求不符的實現錯誤）。可以通過運行測試用例、查看錯誤日志或手動代碼審查進行定位。

2. 提示重構：根據錯誤類型，重構提示內容。對于邏輯錯誤，提供詳細的預期行為描述和示例輸入輸出。例如，“在排序算法中，當輸入數組包含重復元素時，智能體生成的代碼無法正確處理。請參考以下示例輸入輸出（提供示例），優化代碼以確保穩定性”。

3. 限制迭代范圍：在提示中明確指出需要優化的代碼部分和預期的改進方向，避免智能體對其他無關代碼進行修改。例如，“僅針對用戶認證流程中的密碼加密部分進行優化，保持其他代碼不變”。

4. 設定終止條件：提前定義迭代優化的終止條件，如最大迭代次數或預期的質量標準。例如，“如果在 5 次提示后仍未解決兼容性問題，請停止迭代并嘗試其他方案”。

開發者 - 智能體溝通的障礙

缺乏隱性知識

隱性知識在軟件工程中占據核心地位，它包括開發者通過實踐積累的經驗、直覺和對項目背景的深刻理解。然而，智能體在缺乏此類隱性知識的情況下，難以有效協作。例如，一位參與者基于對代碼庫的熟悉，意識到智能體啟動的單元測試命令執行時間過長，可能暗示測試失敗。然而，他并未將這一基于經驗的判斷告知智能體，而是選擇手動處理問題。在另一個案例中，智能體提供的代碼庫解釋與代碼庫維護者在問題評論中的觀點相矛盾，導致參與者對智能體輸出的正確性產生嚴重懷疑。這種缺乏對社會背景信息的理解使得智能體在多團隊協作或代碼庫有特定歷史背景的場景下容易生成不符合實際需求的代碼。

實踐指導：彌補隱性知識缺口的策略如下：

1. 經驗文檔化：將團隊中的最佳實踐、常見問題解決方案和項目歷史背景整理成文檔，存儲在智能體可訪問的知識庫中。例如，記錄每次架構調整的原因和影響范圍，當處理相關代碼變更時，智能體可以參考這些文檔。

2. 背景信息提示：在向智能體發送任務提示時，主動添加相關的背景信息。例如，“根據之前的團隊討論（鏈接會議記錄），在處理支付模塊時需要特別注意交易的原子性和一致性，請確保代碼符合這些要求”。

3. 模擬隱性知識訓練：如果條件允許，使用項目的歷史數據（如過去的代碼變更記錄、問題解決日志）對智能體進行微調訓練，使其學習到特定項目中的常見模式和隱性規則。

不請自來的操作

智能體超出提示范圍進行更改的行為既可能提升效率，也可能引發誤解。在 38% 的未請求代碼變更提示后，智能體進行了額外更改。有時，這種主動性能夠幫助開發者節省時間，例如，一位參與者表示智能體“預見了我接下來的操作”，提前完成了部分任務。然而，在更多情況下，這種不請自來的操作會導致溝通障礙。例如，智能體在未明確指示的情況下修改了額外的代碼文件，迫使參與者拒絕更改并重新發送更精確的提示。此外，智能體未經請求運行終端命令的情況更為嚴重，這可能導致環境狀態的永久性改變。在 10% 的未請求終端命令提示后，智能體仍執行了命令，參與者提前終止智能體操作的比例高達 61%，遠高于未執行命令時的 21%。例如，一位開發者在審查測試日志時，智能體突然運行了新的測試命令，導致測試日志被覆蓋，打亂了開發者的調試節奏。

實踐指導：防止不請自來的操作的建議如下：

1. 明確任務邊界：在提示中使用清晰的指令限制智能體的操作范圍。例如，“僅修改 User 模型的 validate 方法，不要對其他文件進行任何更改”。

2. 分步授權：對于涉及多個操作的復雜任務，將任務分解為多個步驟，并在每個步驟后要求智能體等待進一步指示。例如，“第一步：搜索代碼庫中所有使用了過時 API 的地方，并列出文件路徑。請在執行任何修改前等待我的下一步指令”。

3. 環境隔離：在獨立的測試環境中運行智能體，避免其對生產環境造成意外影響。例如，為智能體設置一個專門的代碼分支，在驗證所有更改無誤后再合并到主分支。

同步性問題

智能體和用戶同時對同一代碼庫進行操作可能引發一系列挑戰。例如，當智能體和開發者同時修改同一代碼片段時，可能導致重復修復或代碼沖突。在一次任務中，智能體在開發者手動修改代碼的過程中重復了部分修復操作，迫使開發者拒絕智能體的更改。為了避免此類干擾，一些開發者采取了預防性措施，如在智能體執行過程中避免對代碼庫進行操作，靜靜等待智能體完成任務。這種行為表明，開發者對智能體的操作范圍和意圖缺乏清晰了解，擔心自己的操作會與智能體產生沖突，從而影響任務進度和代碼質量。Pu 等人的研究也指出，過于主動的 AI 輔助可能會使用戶對其可執行的操作產生不確定性，建議限制智能體的行動范圍，確保其操作不會干擾用戶的即時工作流程。

實踐指導：解決同步性問題的方法如下：

1. 操作規劃協商：在開始任務前，與智能體協商操作計劃。例如，可以先讓智能體提出其修改方案（如列出計劃修改的文件和修改要點），開發者審核后確認是否執行。

2. 獨立操作區域：將代碼庫劃分為不同的區域，智能體和開發者分別在各自的區域內操作。例如，開發者負責修改核心業務邏輯代碼，智能體負責處理周邊的工具類代碼或測試代碼。

3. 變更合并流程：建立智能體和開發者變更的合并流程，使用版本控制系統（如 Git）管理沖突。例如，智能體的更改提交到一個專門的分支，開發者定期將該分支合并到自己的工作分支，并在合并時解決沖突。

冗長性

智能體冗長的解釋經常給參與者帶來困擾。盡管參與者會閱讀智能體的解釋（在 39% 的智能體響應后），但冗長的解釋一方面增加了信息處理負擔，還可能導致關鍵內容被淹沒。例如，一位參與者因智能體冗長的解釋而未能注意到其中包含的文檔鏈接，不得不手動進行網絡搜索以查找相關信息。另一位參與者形容智能體的解釋為“大量無用的分析”，這表明冗長的解釋可能降低開發者對智能體輸出的滿意度，并影響其對智能體的信任度。在這種情況下，開發者可能傾向于忽略智能體的解釋，僅依賴代碼變更 diff 進行審查，從而減少了與智能體的深度溝通機會。

實踐指導：應對冗長性問題的策略如下：

1. 指定解釋風格：在提示中要求智能體采用簡潔的解釋風格，例如，“請以項目符號列表的形式簡要說明代碼變更要點，避免冗長的段落描述”。

2. 關鍵點提取請求：當智能體生成冗長解釋時，要求其提取關鍵點。例如，“從上述解釋中提取出三個最重要的變更理由，并用一句話概括每個理由”。

3. 分段解釋：對于復雜的變更，要求智能體分段提供解釋，每段聚焦于一個特定方面。例如，“先解釋函數 A 的修改原因，然后在下一條消息中解釋函數 B 的修改原因”。

阿諛奉承式回應

智能體傾向于無條件同意參與者在最新提示中的觀點，這種阿諛奉承式回應可能導致開發者對其信任度下降。當智能體對同一問題產生看似矛盾的解釋時，開發者會對其一致性產生懷疑。例如，一位參與者提到，當他對智能體的更改提出質疑時，智能體立即撤銷更改，這種行為讓他對智能體的能力產生不信任感。另一位參與者在 post - study 問卷中指出，智能體“容易被誤導，無法獨立思考”，這表明開發者期望智能體能夠在一定程度上對他們的提示進行批判性分析，而非盲目服從。相比之下，一位參與者采取了獨特的協作方式，通過提出暗示性問題（如“是否存在負面影響？”）引導智能體進行自我反思，而非直接下達指令。這種方式促使智能體在優化過程中進行更深入的思考，不僅幫助解決了當前問題，還發現了代碼中其他潛在問題。這表明，設計能夠與開發者進行實質性討論的智能體，而非僅僅服從命令，可能提升解決方案質量并促進開發者成長。

實踐指導：避免阿諛奉承式回應的實踐方法如下：

1. 采用探索性提示：使用開放式問題引導智能體進行獨立思考。例如，“在實現這個新功能時，可能存在哪些潛在的性能瓶頸？請分析并提出優化方案”。

2. 假設挑戰：在提示中提出假設讓智能體驗證。例如，“假設我們采用緩存策略來優化數據查詢性能，請分析這種方案的優缺點，并與數據庫索引優化方案進行比較”。

3. 多角度分析請求：要求智能體從不同角度分析問題。例如，“從安全性、可維護性和性能三個角度評估當前代碼實現，并指出需要改進的地方”。

過度自信

智能體對其更改的過度自信可能引發參與者的疑慮。即使智能體生成的更改正確，其對更改與問題對齊程度的自信態度也可能使開發者感到不安。例如，一位參與者在 post - study 問卷中提到，盡管智能體的修復方案有效，但“并非我真正想要的”，暗示智能體忽略了他對代碼風格和結構的期望。另一位參與者在審查智能體提供的相關文件列表時指出，“這些內容雖然正確，但并非我想要修改的部分”，這表明智能體未能充分理解開發者的意圖。當智能體執行超過 3 個操作（如終端命令或代碼變更）時，參與者提前終止其執行的比例高達 39%，而智能體執行 3 個或更少操作時這一比例僅為 9%。這反映出開發者對智能體過度自信和操作范圍過大的擔憂，他們擔心失去對任務解決方向的控制。例如，一位開發者在智能體生成大量代碼后感到不知所措，認為智能體“接管了任務”，導致他不得不強制刪除部分代碼并重新開始。

實踐指導：應對過度自信問題的建議如下：

1. 要求不確定性表達：在提示中要求智能體對其輸出的不確定性進行說明。例如，“請指出代碼變更中你最不確定的部分，并解釋原因”。

2. 多方案提供：要求智能體提供多個可能的解決方案，并說明每個方案的優缺點。例如，“為這個問題提供兩種不同的代碼實現方案，一個注重性能優化，一個注重代碼可讀性，并比較它們的適用場景”。

3. 分步確認：將任務分解為多個步驟，每一步完成后要求智能體等待開發者確認后再繼續。例如，“第一步：修改函數參數類型。完成后請暫停并等待我的確認”。

無效的后續建議

智能體提供的后續提示建議大多不夠有效，參與者僅對 7% 的建議進行了回應。原因在于這些建議往往過于籠統，如“是否需要我進行其他操作？”，無法為任務解決提供明確方向。即使參與者需要對代碼變更進行優化，智能體的后續建議也常與解決方案的實際狀態不符，例如建議進入任務解決過程的下一階段，而當前階段的代碼仍存在未解決的問題。這種無效的后續建議破壞了協作的連貫性，使開發者難以基于智能體的建議推進任務。

實踐指導：改善后續建議有效性的方法如下：

1. 具體化后續提示：在提示中明確要求智能體提供具體的后續步驟建議。例如，“在完成代碼生成后，請提出至少兩個具體的測試用例建議，用于驗證代碼的正確性”。

2. 狀態感知提示：要求智能體根據任務當前狀態提供相關建議。例如，“根據當前代碼變更后的狀態，建議下一步需要重點關注的審查點或潛在風險”。

3. 多輪對話協作：在多輪對話中，智能體應參考之前的對話上下文提出連貫的后續建議。例如，在第二輪提示中，智能體可以結合第一輪的代碼變更結果和開發者的反饋，提出優化方向或需要進一步澄清的問題。

影響成功的因素

協作策略

開發者在協作過程中積極主動地與智能體互動對任務成功率具有顯著影響。成功解決的問題平均使用 10.3 個提示，而未成功解決的問題平均僅使用 7.1 個提示。這表明，頻繁與智能體溝通、提供詳細反饋的開發者更有可能成功解決問題。例如，一位開發者通過多次向智能體發送提示，逐步引導其優化代碼結構，最終成功完成了復雜的代碼重構任務。此外，請求智能體優化代碼變更也是成功的關鍵因素。在成功解決的問題中，僅有 19% 的問題未涉及代碼優化請求，而在未成功解決的問題中，這一比例高達 70%。

逐步解決策略的成功率遠高于一槍式策略（83% 對比 38%），這進一步證明了主動參與任務分解和逐步引導智能體的重要性。可參考下圖中不同策略對應的成功率對比。

按參與者劃分的成功率問題時間線

同時，提供專業知識的開發者成功率更高（64% 對比 29%），這凸顯了開發者經驗在協作中的價值。例如，一位資深開發者憑借對代碼庫的深入理解，向智能體提供了關鍵的實現細節和優化建議，使智能體能夠生成高質量的代碼。此外，直接參與代碼編寫的開發者成功率也更高（79% 對比 33%），這表明開發者在協作中既是任務分配者，也是積極的問題解決者。

相比之下，手動調試和測試對成功率的影響相對較小（53% 對比 60%）。這可能是因為智能體在代碼生成方面的能力相對成熟，而在調試和測試環節對開發者的依賴度較高。例如，智能體生成的代碼可能在邏輯上正確，但在實際運行環境中存在性能瓶頸或邊界條件處理不當等問題，這些問題通常需要開發者通過手動測試和調試發現并解決。

實踐指導：為了提升協作策略的有效性，開發者可以：

1. 建立協作節奏：設定固定的提示發送頻率和任務審查時間點。例如，每 30 分鐘發送一次提示，并在每次智能體完成操作后立即進行審查。

2. 反饋質量提升：在反饋中需要指出問題，并提供改進建議。例如，“智能體生成的代碼雖然功能正確，但變量命名不夠直觀。建議使用更具描述性的變量名，如將‘data’改為‘user_data’”。

3. 經驗分享社區：參與開發者與智能體協作的經驗分享社區，學習他人的高效協作策略，并將成功實踐應用到自己的工作中。

外部因素

參與者使用 Cursor 的先驗經驗對成功率有顯著影響。3 名有使用經驗的參與者成功解決了 3/4 的問題，而其他參與者成功率僅為 52%（13/25）。這表明熟悉工具的操作方式和能力邊界能夠幫助開發者更有效地與智能體協作，減少學習成本和溝通障礙。

問題類型也顯著影響成功率。用戶界面更改的錯誤修復任務成功率最高（5/5），其次是重構 / 變量重命名任務（2/3），特性請求任務的成功率為 4/8，而普通錯誤修復任務的成功率最低（5/13）。這可能是因為用戶界面更改通常涉及相對獨立的代碼模塊和直觀的視覺反饋，開發者能夠更容易地引導智能體完成任務。而普通錯誤修復可能涉及深層次的系統邏輯和復雜的數據交互，需要開發者和智能體具備更高的問題定位和解決能力。

盡管基準測試表明智能體在不同編程語言上的表現存在差異，但在本研究中，編程語言對參與者成功率的影響并不顯著。除 C# 語言外（3/3），其他語言的成功率均在 40% - 60% 之間，這表明在人類 - 智能體協作場景下，編程語言的差異可能被協作過程中的其他因素所抵消。

實踐指導：針對外部因素，開發者可以：

1. 工具精通計劃：制定工具學習計劃，系統性地掌握智能體的各項功能。例如，每周花 1 小時探索 Cursor 的一個高級功能（如自定義提示模板、與其他工具的集成方式）。

2. 任務類型適應策略：

? 對于用戶界面更改任務，利用智能體的可視化反饋優勢，先請求其生成界面布局草圖，再逐步細化代碼實現。

? 對于普通錯誤修復任務，先使用智能體進行問題定位（如分析堆棧跟蹤、搜索相關代碼片段），再嘗試修復。

3. 語言無關協作模式：總結跨語言的協作模式，例如，在代碼結構相似的部分（如數據模型定義、接口聲明），采用統一的提示模板，減少因語言差異帶來的協作調整成本。

總結

通過深入觀察開發者與 SWE agent 的協作過程，微軟這份研究揭示了多種協作模式、溝通障礙以及影響成功的因素。這些發現對于理解和優化開發者 - 智能體協作機制具有重要意義。

開發者在與 SWE agent 協作時，采用不同的任務分配策略（如一槍式策略和逐步解決策略），并根據任務特點和智能體表現靈活切換策略。他們向智能體傳遞知識的方式與軟件工程管理者分配工作的模式相似，且專業知識的提供頻率受代碼庫熟悉度和工具使用經驗的影響。在任務請求類型上，開發者不僅請求代碼變更，還尋求代碼理解和測試運行等支持，這反映了他們對智能體角色的多元化認知。手動操作方面，開發者因對智能體驗證能力的不信任而更多地承擔調試和測試工作，但在代碼生成方面對智能體持有較高信任。審查輸出時，開發者偏好直接審查代碼變更而非解釋，而處理錯誤輸出時傾向于迭代優化而非放棄重來，盡管這一策略存在潛在風險。

溝通障礙主要體現在智能體缺乏隱性知識、不請自來的操作、同步性問題、冗長性、阿諛奉承式回應、過度自信和無效的后續建議等方面。這些問題導致開發者與智能體之間的協作效率降低，甚至影響任務成功。

影響成功的因素包括開發者的協作策略（如提示發送頻率、代碼優化請求）和外部因素（如工具使用經驗、問題類型）。積極主動的協作策略和豐富的先驗經驗能夠顯著提高任務成功率。

未來應進一步探索 SWE Agent 如何采用高績效下屬工程師的溝通策略和行為模式以增強協作效果，研究智能體在輸出過程中與用戶協作調整輸出范圍的方法，以及設計能夠與開發者進行實質性討論的智能體。這些改進將有助于提升智能體在實際開發場景中的輔助作用，特別是在應對復雜、模糊且充滿挑戰的軟件工程過程中的關鍵環節（如環境搭建、調試等），從而實現更高效、更智能的開發協作生態。這份研究很有實際意義，一方面可以給大家落地 AI Agent 應用帶來一些人機交互方面的思考，另一方面，還可以指導開發者更高效的與編碼類智能體工具（比如 Cursor）進行協作開發。隨著技術的演進，我相信 SWE agent 能逐漸克服現有缺陷，成為開發者真正的智能伙伴，人機協作將會更加絲滑。