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

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

一些 Cursor Agent 的示例用法

一些概念與背景

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

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

SWE Bench 等基準(zhǔn)測試的評估作用及局限性

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

研究方法

工具選擇

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

任務(wù)與參與者選擇

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

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

多樣背景體的執(zhí)行軌跡、在對話中回溯等的參與者背景有助于提升研究結(jié)果的廣泛性和代表性。例如，不同編程經(jīng)驗的開發(fā)者在與智能體協(xié)作時可能展現(xiàn)出不同的策略和行為模式，而不同地區(qū)的開發(fā)者可能受到當(dāng)?shù)亻_發(fā)文化和技術(shù)生態(tài)的影響，這些差異都將為研究提供豐富的視角。

實驗流程與操作

實驗開始前，研究管理員對參與者進(jìn)行了 Cursor IDE 及其智能體功能的培訓(xùn)。通過一個演示任務(wù)，參與者熟悉了如何與智能體交互，例如在聊天窗口中輸入提示、實時查看智能體的執(zhí)行軌跡、接受或拒絕代碼變更等操作。這一培訓(xùn)環(huán)節(jié)是為了確保參與者對工具的基本功能有清晰的理解，從而在實驗過程中能夠?qū)Ｗ⒂谌蝿?wù)解決而非工具學(xué)習(xí)。

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

數(shù)據(jù)收集與分析方法

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

參與者活動分類

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

聊天軌跡分類法

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

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

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

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

研究結(jié)果

開發(fā)者與 SWE 智能體的協(xié)作模式

任務(wù)分配策略

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

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

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

實踐指導(dǎo)：對于逐步解決策略，開發(fā)者可以按照以下步驟實施：

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

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

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

4. 任務(wù)描述調(diào)整：根據(jù)智能體的輸出結(jié)果，調(diào)整后續(xù)子任務(wù)的提示內(nèi)容。如果智能體在某個子任務(wù)中犯了錯誤，可在提示中明確指出錯誤并給出修正方向。

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

知識傳遞

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

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

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

實踐指導(dǎo)：為了有效傳遞專業(yè)知識，開發(fā)者可以：

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

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

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

請求的任務(wù)類型

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

Agent 感知研究后續(xù)問卷調(diào)查結(jié)果

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

實踐指導(dǎo)：針對不同類型的任務(wù)請求，開發(fā)者可以采用以下實踐方法：

1. 代碼理解任務(wù)：

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

2. 測試運行任務(wù)：

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

3. 代碼審查任務(wù)：

? 提供審查標(biāo)準(zhǔn)或檢查列表，引導(dǎo)智能體按照特定規(guī)范進(jìn)行審查。例如，“根據(jù)公司的代碼審查規(guī)范（粘貼規(guī)范要點），審查我提交的代碼變更，指出不符合規(guī)范的地方”。

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

手動操作

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

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

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

實踐指導(dǎo)：為了平衡手動操作與智能體協(xié)作，開發(fā)者可以采取以下措施：

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

2. 逐步轉(zhuǎn)移驗證任務(wù)：對于智能體能力范圍內(nèi)的驗證工作，先讓智能體嘗試完成，開發(fā)者對其輸出進(jìn)行抽檢。例如，智能體生成單元測試代碼并執(zhí)行，開發(fā)者隨機選擇部分測試用例進(jìn)行復(fù)查，根據(jù)復(fù)查結(jié)果決定是否擴大智能體的驗證權(quán)限。

3. 代碼生成協(xié)作：在代碼生成過程中，開發(fā)者可以先使用智能體生成代碼框架，然后手動填充關(guān)鍵業(yè)務(wù)邏輯細(xì)節(jié)。例如，智能體生成一個數(shù)據(jù)訪問層的代碼模板，開發(fā)者添加具體的數(shù)據(jù)庫查詢優(yōu)化邏輯。

審查輸出

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

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

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

Agent 特性學(xué)習(xí)后問卷調(diào)查結(jié)果

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

實踐指導(dǎo)：優(yōu)化輸出審查流程的建議如下：

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

2. diff 審查要點：

? 對于代碼修改部分，檢查是否符合代碼風(fēng)格規(guī)范（如命名約定、縮進(jìn)規(guī)則）。

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

? 驗證與現(xiàn)有代碼的集成點是否正確，例如函數(shù)調(diào)用參數(shù)是否匹配、數(shù)據(jù)類型轉(zhuǎn)換是否合理。

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

由Agent建議的代碼編輯差異

處理錯誤輸出

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

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

實踐指導(dǎo)：為了有效處理錯誤輸出，開發(fā)者可以遵循以下步驟：

1. 錯誤定位：在收到智能體的錯誤代碼后，首先明確錯誤類型（如語法錯誤、邏輯錯誤、與需求不符的實現(xiàn)錯誤）?？梢酝ㄟ^運行測試用例、查看錯誤日志或手動代碼審查進(jìn)行定位。

2. 提示重構(gòu)：根據(jù)錯誤類型，重構(gòu)提示內(nèi)容。對于邏輯錯誤，提供詳細(xì)的預(yù)期行為描述和示例輸入輸出。例如，“在排序算法中，當(dāng)輸入數(shù)組包含重復(fù)元素時，智能體生成的代碼無法正確處理。請參考以下示例輸入輸出（提供示例），優(yōu)化代碼以確保穩(wěn)定性”。

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

4. 設(shè)定終止條件：提前定義迭代優(yōu)化的終止條件，如最大迭代次數(shù)或預(yù)期的質(zhì)量標(biāo)準(zhǔn)。例如，“如果在 5 次提示后仍未解決兼容性問題，請停止迭代并嘗試其他方案”。

開發(fā)者 - 智能體溝通的障礙

缺乏隱性知識

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

實踐指導(dǎo)：彌補隱性知識缺口的策略如下：

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

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

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

不請自來的操作

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

實踐指導(dǎo)：防止不請自來的操作的建議如下：

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

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

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

同步性問題

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

實踐指導(dǎo)：解決同步性問題的方法如下：

1. 操作規(guī)劃協(xié)商：在開始任務(wù)前，與智能體協(xié)商操作計劃。例如，可以先讓智能體提出其修改方案（如列出計劃修改的文件和修改要點），開發(fā)者審核后確認(rèn)是否執(zhí)行。

2. 獨立操作區(qū)域：將代碼庫劃分為不同的區(qū)域，智能體和開發(fā)者分別在各自的區(qū)域內(nèi)操作。例如，開發(fā)者負(fù)責(zé)修改核心業(yè)務(wù)邏輯代碼，智能體負(fù)責(zé)處理周邊的工具類代碼或測試代碼。

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

冗長性

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

實踐指導(dǎo)：應(yīng)對冗長性問題的策略如下：

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

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

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

阿諛奉承式回應(yīng)

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

實踐指導(dǎo)：避免阿諛奉承式回應(yīng)的實踐方法如下：

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

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

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

過度自信

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

實踐指導(dǎo)：應(yīng)對過度自信問題的建議如下：

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

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

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

無效的后續(xù)建議

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

實踐指導(dǎo)：改善后續(xù)建議有效性的方法如下：

1. 具體化后續(xù)提示：在提示中明確要求智能體提供具體的后續(xù)步驟建議。例如，“在完成代碼生成后，請?zhí)岢鲋辽賰蓚€具體的測試用例建議，用于驗證代碼的正確性”。

2. 狀態(tài)感知提示：要求智能體根據(jù)任務(wù)當(dāng)前狀態(tài)提供相關(guān)建議。例如，“根據(jù)當(dāng)前代碼變更后的狀態(tài)，建議下一步需要重點關(guān)注的審查點或潛在風(fēng)險”。

3. 多輪對話協(xié)作：在多輪對話中，智能體應(yīng)參考之前的對話上下文提出連貫的后續(xù)建議。例如，在第二輪提示中，智能體可以結(jié)合第一輪的代碼變更結(jié)果和開發(fā)者的反饋，提出優(yōu)化方向或需要進(jìn)一步澄清的問題。

影響成功的因素

協(xié)作策略

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

逐步解決策略的成功率遠(yuǎn)高于一槍式策略（83% 對比 38%），這進(jìn)一步證明了主動參與任務(wù)分解和逐步引導(dǎo)智能體的重要性?？蓞⒖枷聢D中不同策略對應(yīng)的成功率對比。

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

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

相比之下，手動調(diào)試和測試對成功率的影響相對較?。?3% 對比 60%）。這可能是因為智能體在代碼生成方面的能力相對成熟，而在調(diào)試和測試環(huán)節(jié)對開發(fā)者的依賴度較高。例如，智能體生成的代碼可能在邏輯上正確，但在實際運行環(huán)境中存在性能瓶頸或邊界條件處理不當(dāng)?shù)葐栴}，這些問題通常需要開發(fā)者通過手動測試和調(diào)試發(fā)現(xiàn)并解決。

實踐指導(dǎo)：為了提升協(xié)作策略的有效性，開發(fā)者可以：

1. 建立協(xié)作節(jié)奏：設(shè)定固定的提示發(fā)送頻率和任務(wù)審查時間點。例如，每 30 分鐘發(fā)送一次提示，并在每次智能體完成操作后立即進(jìn)行審查。

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

3. 經(jīng)驗分享社區(qū)：參與開發(fā)者與智能體協(xié)作的經(jīng)驗分享社區(qū)，學(xué)習(xí)他人的高效協(xié)作策略，并將成功實踐應(yīng)用到自己的工作中。

外部因素

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

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

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

實踐指導(dǎo)：針對外部因素，開發(fā)者可以：

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

2. 任務(wù)類型適應(yīng)策略：

? 對于用戶界面更改任務(wù)，利用智能體的可視化反饋優(yōu)勢，先請求其生成界面布局草圖，再逐步細(xì)化代碼實現(xiàn)。

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

3. 語言無關(guān)協(xié)作模式：總結(jié)跨語言的協(xié)作模式，例如，在代碼結(jié)構(gòu)相似的部分（如數(shù)據(jù)模型定義、接口聲明），采用統(tǒng)一的提示模板，減少因語言差異帶來的協(xié)作調(diào)整成本。

總結(jié)

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

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

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

影響成功的因素包括開發(fā)者的協(xié)作策略（如提示發(fā)送頻率、代碼優(yōu)化請求）和外部因素（如工具使用經(jīng)驗、問題類型）。積極主動的協(xié)作策略和豐富的先驗經(jīng)驗?zāi)軌蝻@著提高任務(wù)成功率。

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