AI多大程度上可以替代傳統(tǒng)開發(fā)工作？
應如何系統(tǒng)性引入與運營AI編程工具？
關鍵系統(tǒng)中采用AI輔助編程，有哪些風險？
未來軟件工程師的核心競爭力應如何重塑？
廣發(fā)證券專家繼今年5月分享《AI重構證券行業(yè)——范式突破與生態(tài)進化》一文后，本次為我們帶來AI應用探索系列的又一力作，并已發(fā)表于第12期《投資管理》/ China JOIM（2025年10月刊）。
作者 ：辛治運b,*、王蓁a,*
a第一作者，b通訊作者，*廣發(fā)證券
引言
自2021年GitHub Copilot將生成式模型嵌入主流IDE以來，基礎模型能力的攀升逐漸解鎖此類AI輔助編程工具工程設計的想象空間。Cursor、Devin、Claude Code等工具的快速迭代，從語句補全、到自動生成函數(shù)級代碼、乃至端到端開發(fā)的能力逐漸被人們關注和看好，AI輔助編程已從開發(fā)者玩具演變?yōu)槠髽I(yè)級生產(chǎn)力平臺。
金融行業(yè)眾多的合規(guī)要求、龐大復雜的遺留系統(tǒng)(Legacy Code)、與對實時可靠性的極高需求，成為檢驗AI編程價值的試金石。Deloitte預測到2028年，生成式AI可為銀行業(yè)節(jié)省20–40%的軟件投資成本，當前已有高盛為12,000名開發(fā)者大規(guī)模配發(fā)生成式助手，花旗亦將AI輔助編程工具擴展至30,000名工程師的現(xiàn)代化重構計劃中。
然而當前企業(yè)大多聚焦于“AI采納率提升了多少、缺陷率降低多少、能替代多少人力”，卻很少關注到一些更長遠的問題：
1) 當AI輔助編程與業(yè)務場景深度交織，未來的編程將會是什么形態(tài)；
2) 程序員的核心競爭力將如何隨之遷移；
3) 組織和企業(yè)如何在技術與文化的雙重演進中構建可持續(xù)的競爭優(yōu)勢。
本文將以工具生態(tài)、實踐經(jīng)驗、用戶分析與未來趨勢四個維度，探討AI輔助編程在證券行業(yè)的現(xiàn)實價值與遠景藍圖，一方面希望為金融行業(yè)領域智能研發(fā)體系提供可借鑒復制和落地的實踐路徑，一方面更希望通過對未來發(fā)展的預判，給各位讀者更多的思考。
01
AI輔助編程的現(xiàn)狀與工具生態(tài)分析
1. AI輔助編程的三代演進
我們將當前主流的AI輔助編程工具按照技術特征與應用能力的演進，大致劃分為三代：
第一代代碼補全
回溯到AI編程的早期階段，工具多聚焦于代碼補全與語法建議。在這個階段，產(chǎn)品大多以插件形式存在于IDE中，例如GitHub Copilot等。它們提示預測下一行代碼或函數(shù)，是最先普及、最容易上手的輔助編程應用范式。但受限于響應速度要求與極高的調用頻率，代碼補全場景下所使用的模型通常是被限制在10B以內(nèi)的“小”模型，難以發(fā)揮最強大模型的全部能力。這類工具提升了輸入效率，卻并不具備跨任務規(guī)劃或環(huán)境洞察的能力。
第二代嵌入式編程智能體
更長的上下文窗口與使用工具的能力推動輔助編程進入第二代，工具逐漸具備“agent”特征。這類編程輔助工具不再局限于補全文本和回答特定問題，而是擴展了項目理解、工具使用、上下文持續(xù)分析、批量代碼生成等多方面能力。Cursor是此類場景下最典型的產(chǎn)品案例，原生的智能IDE設計為大模型獲取更多的上下文提供了便利，讓模型能在IDE內(nèi)思考，識別項目結構、調用外部工具、提供更連貫的開發(fā)建議，完成項目級的代碼文件生成，仿佛是隨時待命的實習工程師。
在這一代工具中，用戶的使用方式發(fā)生了巨大的改變，從單點調用轉向任務委托，開發(fā)者開始習慣用自然語言描述任務意圖并審閱AI所提供的代碼與指令，因此，第二代工具不僅提高了開發(fā)效率，更重塑了人機協(xié)作的模式，開發(fā)者的角色正在從“代碼執(zhí)行者”轉變?yōu)椤靶枨笤O計者與審閱者”，而代碼的落地實現(xiàn)，正越來越多地交由AI在幕后完成。
第三代 SDLC一體化軟件工程智能體
而現(xiàn)在，第三代輔助編程工具正利用更先進的模型，它們能夠在端到端測試中自動瀏覽網(wǎng)站、理解CI/CD工具，并協(xié)調多個專業(yè)化代理協(xié)同工作，成為真正具備SDLC(軟件開發(fā)生命周期)整合能力的工具。以Devin為例，這款由Cognition AI推出的產(chǎn)品號稱世界上第一個AI軟件工程師，能夠在全程無人干預的情況下，從GitHub issue中讀取需求，自動規(guī)劃開發(fā)任務，編寫并提交代碼，運行測試，修復缺陷，并最終將功能部署上線。Anthropic的Claude Code以CLI為形態(tài)，既能在本地編碼，也通過GitHub Actions將安全審查接入CI/CD，自動在PR上留評與修復。
2. AI輔助編程產(chǎn)品形態(tài)對比
各個AI輔助編程工具的功能點都在向著最前沿的方向趨同進化與補齊，但產(chǎn)品形態(tài)與交互特性依然保持差異，我們針對市面上主流的一些輔助工具根據(jù)產(chǎn)品形態(tài)進行了劃分：
表1 國內(nèi)外主要流程AI編程工具及主要特點
3. 演進涉及的主要技術能力
為彌合大語言模型在代碼生成中的概率性與軟件工程的確定性之間的鴻溝，業(yè)界探索出四類主流的工程增強技術路徑，其共同目標是確保模型生成的代碼不僅“語法正確”，更能通過編譯、通過測試，并最終成功合入代碼倉庫。
倉庫級上下文理解：為實現(xiàn)跨文件的代碼補全、檢索與流水線一體化，模型必須具備理解整個代碼倉庫的能力。RepoBench等評測基準的出現(xiàn)，正推動著該技術方向的發(fā)展，使模型能夠基于項目全局信息生成更精準、更符合上下文的代碼。
基于靜態(tài)分析與類型系統(tǒng)的解碼約束：為提升代碼的可編譯率與正確性，可在模型解碼階段引入硬性約束。例如，監(jiān)控引導解碼(Monitor-Guided Decoding)技術能夠在生成過程中動態(tài)過濾掉與類型定義不符的候選詞，而基于上下文無關文法(CFG)或類型系統(tǒng)的約束則能提供更強的確定性保障。
推理與行動一體化：為使模型能夠執(zhí)行復雜的、需要與外部環(huán)境交互的任務，研究者提出了將“思考”與“行動”相結合的框架。ReAct框架通過交錯執(zhí)行推理(思考下一步做什么)與行動(調用工具、運行測試)，使模型能夠動態(tài)規(guī)劃并調整其行為。自我精煉(Self-Refine)機制則通過“編寫-評估-修改”的內(nèi)部循環(huán)，持續(xù)迭代優(yōu)化生成的代碼。
基于執(zhí)行反饋的學習：此路徑將代碼的實際執(zhí)行結果作為關鍵信號，納入模型的訓練或推理流程中。通過“生成—運行—讀取測試結果—再生成”的閉環(huán)，模型能夠從成功或失敗的執(zhí)行經(jīng)驗中學習?；趫?zhí)行反饋的強化學習(RLEF)與GenX等方法是該方向的代表，它們使模型的能力從“寫得像”真正轉變?yōu)椤澳芙鉀Q問題”。
4. 評測基準趨向衡量真實研發(fā)流程下的表現(xiàn)
與技術路徑相對應，AI輔助編程的評測基準(Benchmark)也經(jīng)歷了深刻的演進，其核心趨勢是從“算法級、靜態(tài)問題”轉向“工程級、動態(tài)任務”，以更真實地衡量模型在實際軟件開發(fā)流程中的應用價值。
早期的評測基準，如HumanEval和MBPP，主要測試模型根據(jù)函數(shù)描述生成獨立函數(shù)的能力，并通過少量單元測試進行判定。盡管這些基準開創(chuàng)了代碼生成評測的先河，但后續(xù)研究(如EvalPlus通過擴充測試用例)發(fā)現(xiàn)，它們可能因測試覆蓋度不足而高估模型的真實性能。
為了更貼近真實開發(fā)場景，新一代評測基準應運而生。SWE-bench將評測任務升級為“在真實的開源代碼倉庫中修復一個已知的Issue，并確保代碼能通過項目的持續(xù)集成(CI)測試”，這極大地提升了評測的復雜性和真實性。LiveCodeBench則強調了對數(shù)據(jù)污染的控制和評測集的持續(xù)更新，以反映真實世界中軟件的動態(tài)演化。而RepoBench與ExecRepoBench等則專注于評測模型在倉庫級的代碼檢索、補全以及可執(zhí)行代碼補全方面的能力。
總體而言，評測基準的演進方向明確地表明：行業(yè)共識正在從評估模型“編寫代碼片段”的能力，轉向評估其“解決實際工程問題”的綜合能力。評測基準越貼近真實的軟件開發(fā)流程，就越能有效地區(qū)分不同AI編程工具的真實水平。
02
廣發(fā)證券智能編程運營體系的方法論與實踐
1. 研究背景與整體設計
在證券公司引入并推廣智能編程工具，挑戰(zhàn)遠不止部署上線這么簡單。一方面工具的成功落地不僅是技術問題，更深度交織著開發(fā)者的使用習慣、團隊協(xié)作模式與組織文化等非技術性因素。另一方面，市場上各工具性能參差不齊，宣傳的效能指標與真實業(yè)務場景下的表現(xiàn)往往存在顯著差異。
我們的故事始于一次以提升內(nèi)部效能為目標的運營實踐，這次實踐在取得初步成效后遇到了瓶頸，從而催生了旨在探尋真相的深度評測；而評測所帶來的顛覆性發(fā)現(xiàn)，反過來又為我們的運營體系注入了全新的戰(zhàn)略洞察，最終引領我們?nèi)〉昧藢嵸|性的效能突破。
為了系統(tǒng)性地探究AI輔助編程在證券行業(yè)的真實效能與最佳實踐路徑，我們設計并實施了一項為期近一年的綜合性實踐研究。我們構建了一套集“用戶驅動的運營體系”與“多維效能評價體系”于一體的綜合推進方案。整體設計包含兩大并行且互為支撐的核心實踐模塊：
圖 1 廣發(fā)證券智能編程運營體系的方法論：“運營-評測-運營”閉環(huán)模型圖
1）基于用戶驅動的閉環(huán)運營體系：工具的運營旨在解決“從可用到會用、愛用”的關鍵問題。我們認為，工具的價值最終取決于人的使用。因此，在評測的基礎上，我們構建了一套以用戶為中心的閉環(huán)運營體系。該體系通過“數(shù)據(jù)分析、深度訪談、線下推廣、持續(xù)跟進與產(chǎn)品迭代”的五步法，精準定位用戶在采納工具過程中的認知、習慣與環(huán)境障礙，并采取針對性舉措予以解決，從而持續(xù)提升工具的活躍度與使用深度。
2）智能編程工具的多維效能評測體系：此模塊的核心目標在于建立一套客觀、公正且貼近證券業(yè)務真實場景的度量衡。我們摒棄了廠商自帶的、可能存在“指標膨脹”的看板數(shù)據(jù)，通過統(tǒng)一的基準口徑，對市場上多款主流AI編程工具進行為期數(shù)月的深度實測。該評測不僅關注代碼補全采納率等量化指標，更將產(chǎn)品功能完善度與開發(fā)者的主觀體驗評分納入評估體系，旨在全面、多維地甄別出最適合各公司研發(fā)環(huán)境的工具。
綜上所述，這兩項實踐并非簡單的線性關系，而是構成了一個動態(tài)的、相互催化的探索閉環(huán)。效能評測為運營提供了方向與依據(jù)，而用戶運營則確保了評測選出的優(yōu)質工具能夠真正落地并發(fā)揮價值。兩者共同構成了一個動態(tài)、循環(huán)的優(yōu)化閉環(huán)，為在證券行業(yè)規(guī)?；茝VAI輔助編程工具，并切實提升研發(fā)效能提供了可復制、可擴展的實踐框架。
2. 基于用戶驅動的閉環(huán)運營體系
2.1 “五步法”運營模型
在實踐初期，我們面臨的核心挑戰(zhàn)是工具采納率不足10%，與業(yè)界宣傳的動輒百分之五六十的采納率水平存在巨大鴻溝。為定位并解決此問題，我們構建了一套以用戶為中心的閉環(huán)運營體系。該體系旨在了解一線用戶對工具使用的真實體驗、精準識別并解決用戶在工具使用過程中的各類障礙，通過精細化、人本化的運營手段，持續(xù)提升工具的活躍度與使用深度，從而將AI輔助編程的潛力真正轉化為團隊的生產(chǎn)力。
我們將在實踐中探索出的運營方法論，沉淀并提煉為一套可復制、可迭代的“五步法”閉環(huán)運營模型。該模型以“數(shù)據(jù)分析、用戶訪談、線下地推、用戶跟進、產(chǎn)品迭代”五步法構成一個持續(xù)優(yōu)化的動態(tài)循環(huán)，確保運營工作能夠精準、高效地解決用戶真實痛點。
1) 數(shù)據(jù)分析：用戶行為數(shù)據(jù)的分析是運營的起點。通過對后臺數(shù)據(jù)的多維度分析(如采納率、調用量、語言類型、時段差異等)，結合用戶崗位信息，量化地識別出使用行為異常的用戶或群組，為后續(xù)的(線下)運營提供精準的目標畫像。
2) 用戶訪談：真實的用戶反饋是深入洞察的窗口。針對數(shù)據(jù)分析篩選出的重點用戶，盡最大努力在非正式工作環(huán)境下進行一對一的深度訪談，了解用戶真實體驗，挖掘定量數(shù)據(jù)無法揭示的使用心理和行為細節(jié)，探尋數(shù)據(jù)背后的根本原因。
3) 線下地推：解決問題的關鍵行動。針對訪談中發(fā)現(xiàn)的共性問題，尤其是面對插件版本兼容、安裝流程復雜等技術性障礙，我們采用了“一對一上門安裝”的地推方式。運營團隊攜帶最新版插件安裝包和正版激活賬號，直接進入研發(fā)組現(xiàn)場為用戶配置環(huán)境，確保用戶能夠立刻投入使用。在推廣過程中，我們還篩選了核心種子用戶針對最前沿產(chǎn)品進行使用與交流分享，率先形成使用氛圍，再向其他團隊擴散。
4) 用戶跟進：形成反饋的閉環(huán)。將用戶分群，對核心種子用戶和已干預用戶進行持續(xù)的、定期的溝通與跟進，觀察其使用行為的變化，收集長期的使用反饋，鞏固運營成效。
5) 產(chǎn)品迭代：價值提升的落點。將收集到的用戶反饋進行系統(tǒng)性整理，轉化為明確的產(chǎn)品需求或缺陷修復任務，推動智能編程工具本身的迭代與優(yōu)化，從而提升用戶體驗，形成正向循環(huán)。
2.2 運營過程、關鍵舉措與成效分析
我們于2024年5月啟動了以提升工具采納率為目標的第一輪專項運營計劃。這一過程始于對內(nèi)部問題的深度診斷，并通過一系列精準的干預措施，最終取得了階段性的成效。
2.2.1 數(shù)據(jù)分析：數(shù)據(jù)驅動下的多維度問題診斷
運營的起點是對現(xiàn)狀的精準診斷。面對不足10%的初始采納率，我們首先對過去3個月內(nèi)，全量414名用戶行為數(shù)據(jù)進行了深度挖掘，并檢驗我們提出的多個影響采納率指標的假設，為后續(xù)的線下運營提供更精準的目標用戶群和待解決問題：
1) 初期用戶低采納率是普遍現(xiàn)象：如圖2數(shù)據(jù)顯示，用戶采納率呈現(xiàn)明顯的右偏分布，絕大多數(shù)用戶的采納率集中在0-15%的低位區(qū)間，且剔除掉部分極低采納次數(shù)的用戶后，依然無明顯變化，表明低采納率是一個普遍現(xiàn)象，而非少數(shù)用戶的極端行為所致。
圖2A 用戶采納率分布直方圖：該圖展示了項目初期全體用戶的代碼補全采納率分布情況，用戶采納率呈現(xiàn)明顯的右偏分布，絕大多數(shù)用戶的采納率集中在0%至15%的低區(qū)間，整體平均采納率為7.48% 。
圖2B 采納數(shù)>20的用戶采納率分布直方圖：該圖展示了項目初期采納數(shù)>20用戶群體的代碼補全采納率分布情況，以消除小部分極端行為用戶影響，整體平均采納率為7.69%。
2) AI對不同程序語言的效率提升存在顯著差異，但不能解釋初期總體采納率偏低的事實：我們曾假設程序語言使用分布的差異是主要原因。然而，通過將公司內(nèi)各程序語言的采納率按廠商所提供的語言調用分布進行加權測算后，預估采納率并無顯著提升。該結論有力地排除了此核心假設，讓我們得以聚焦于更本質的問題。
表2. 測試效果與外部基準相比的各語言調用率和采納率
*按外部基準調用率加權后的測試預估采納率僅為8.64%，仍顯著低于市場宣傳值。
3) 代碼場景復雜度顯著影響AI輔助編程的效能：我們把用戶按照實際工作的代碼場景分群，并對不同的場景按照程序開發(fā)復雜度排序。分析結果顯示，業(yè)務邏輯相關性較低的群組采納率顯著高于業(yè)務邏輯復雜的群組。
4) 用戶偏好較短的AI代碼補全，而更不信任/不接受較長的代碼生成結果：圖3顯示，用戶對短代碼補全(6-10個Token)的采納意愿最高，采納率隨建議長度增加而下降(相關系數(shù)-0.48)。
圖3 不同長度代碼補全采納率與上屏率分析:該圖以代碼補全建議的長度(Token數(shù))為橫軸，通過組合圖的形式展示了不同長度建議下的調用量、上屏量、采納量(左軸，柱狀圖)以及對應的上屏率和采納率(右軸，折線圖)。
2.2.2 用戶訪談和線下地推：從數(shù)據(jù)洞察到精準干預
數(shù)據(jù)分析揭示了“當前的情況是什么”，而用戶訪談則告訴我們“為什么會是這個情況”。根據(jù)上述數(shù)據(jù)洞察圈定的重點用戶群，我們在四個月內(nèi)進行了數(shù)百人次的一對一深度線下訪談(單次>15分鐘)，并把用戶的反饋分類，對其中較快即可解決的問題，通過線下地推進行了精準的干預措施。通過深度訪談，我們識別出以下幾類典型的用戶畫像與障礙：
1) 認知偏差型：部分用戶采納率為零，其根本原因竟是“不知道可以按TAB鍵采納”，僅將工具當作代碼翻譯或注釋生成的輔助手段。
2) 使用習慣型：有經(jīng)驗的開發(fā)者對工具的價值高度認可，但因長期的編碼習慣，仍傾向于“照著AI的提示手動敲一遍代碼”，而非直接采納。
3) 環(huán)境障礙型：部分研發(fā)團隊因使用特定版本的IDE，其版本較舊，無法與最新的AI編程插件兼容，導致無法安裝或使用。
4) 心理顧慮型：部分合作方員工擔心插件的使用數(shù)據(jù)會被作為個人績效考核的負面指標，因而主動選擇不安裝或禁用插件，對數(shù)據(jù)上報存在顧慮。
針對認知偏差問題，我們迅速組織了多場用戶培訓，并對零采納和低采納用戶線下逐一溝通，確保其掌握基本用法。針對環(huán)境障礙，運營團隊攜帶正版插件安裝包與賬號，深入研發(fā)團隊進行“地推式”上門安裝，手把手解決兼容性問題?？傊瑢τ脩粼L談中得到的最真實的反饋，運營團隊從聆聽、化解顧慮、通過外部資源協(xié)助解決等各種方式盡最大努力的解決。
2.2.3 用戶跟進與產(chǎn)品迭代：形成閉環(huán)與價值固化
“五步法”的最后兩個環(huán)節(jié)——用戶跟進與產(chǎn)品迭代，是運營工作的價值閉環(huán)所在。我們相信，好的產(chǎn)品永遠是迭代出來的，這樣的運營機制確保了一線的用戶反饋能夠被系統(tǒng)性地吸收，并轉化為產(chǎn)品能力的持續(xù)提升，從而將運營帶來的短期效果固化為長期的產(chǎn)品價值。
從一線反饋到產(chǎn)品迭代的轉化機制
我們建立了從用戶跟進到產(chǎn)品迭代的常態(tài)化轉化機制。在運營訪談中收集到的每一條具體反饋，無論是功能缺陷還是體驗優(yōu)化建議，都會被記錄并轉化為明確的開發(fā)任務：
1) 缺陷修復：有用戶在訪談中反饋，代碼補全時“經(jīng)常出現(xiàn)重復的括號補全，導致結構錯誤”。此類具體問題被定為高優(yōu)先級缺陷，并迅速在后續(xù)的產(chǎn)品迭代中得到修復。
2) 體驗優(yōu)化：另有用戶指出，插件在版本更新時需要重新卸載安裝，若忽略更新可能會有接口對接報錯，嚴重影響使用。這類體驗層面的問題，則推動我們完成插件熱更新的能力，以提升工具的持續(xù)性使用。
持續(xù)的、可量化的產(chǎn)品迭代
這種由用戶反饋驅動的迭代是持續(xù)進行的。數(shù)據(jù)顯示，早在2024年1月，我們就已根據(jù)初期用戶反饋解決了27個問題。在6-9月的集中運營期后，我們于9月再次推動了一次集中優(yōu)化，修復了超過40個收集到的缺陷。
從功能優(yōu)化到戰(zhàn)略升級的演進
產(chǎn)品迭代的內(nèi)涵遠不止于缺陷修復，更包含了基于用戶需求和行業(yè)趨勢的戰(zhàn)略性產(chǎn)品升級。
1) 關鍵版本更新與成效：運營期間積累的大量反饋，最終催生了2024年第四季度的一次產(chǎn)品大版本更新。這次更新不僅包含了大量細節(jié)優(yōu)化，也對核心模型與策略進行了升級。更新上線后，工具的整體采納率由9%進一步提升并穩(wěn)定在了10%~13%的區(qū)間，有力地證明了“運營驅動產(chǎn)品，產(chǎn)品提升數(shù)據(jù)”的良性循環(huán)。
2) 能力邊界拓展：基于對研發(fā)全流程提效的構想，我們的產(chǎn)品迭代并未止步于代碼補全。自2024年10月起，我們開始推動大模型賦能軟件開發(fā)全流程的應用研發(fā)，成功落地了接口測試用例自動生成等新功能，并開發(fā)了智能CodeReview與智能日志分析的應用Demo。
3) 面向未來的技術跟進：為始終保持技術領先，我們持續(xù)跟進業(yè)界前沿模型。在2025年2月，我們再次對產(chǎn)品進行了升級，實現(xiàn)了對DeepSeek等前沿大模型的快速集成與切換，確保一線開發(fā)者能隨時受益于最新的技術進展。并在之后引入了Coding Agent的能力，將公司AI輔助編程工具能力推進到了下一個時代。
2.2.4 階段性總結：從內(nèi)部優(yōu)化到外部求索
綜上所述，第一輪以“五步法”為核心的運營實踐取得了顯著的階段性成效。通過數(shù)據(jù)驅動的診斷和精細化的人本運營，我們在解決用戶真實痛點、激活用戶生態(tài)方面收獲頗豐，工具的日活躍用戶峰值在不施加強制管理手段的情況下，由155人自然增長至380人，整體采納率也由6%穩(wěn)步提升至11.2%。
好產(chǎn)品是迭代出來的。AI時代，天馬行空的創(chuàng)意或許可以獨領風騷一時，但線下科學的、成體系的、堅持不懈的“笨功夫”和“苦活”更是競爭力可持續(xù)的護城河。
然而，盡管取得了顯著進展，百分之十幾的采納率與業(yè)界宣傳的動輒百分之五六十水平之間仍存在巨大鴻溝。這讓我們不得不重新審視問題的根源：這一差距究竟是源于我們自身尚未解決的深層問題，還是行業(yè)本身的標準值得商榷？
僅靠內(nèi)部運營已無法回答這一問題。為此，我們設計并啟動了一套全面的多維效能評測體系，旨在將公司工具與行業(yè)主流產(chǎn)品置于同一標準下進行客觀對比，以探尋差距背后的真相。
3 智能編程工具的多維效能評測體系
3.1 評測方法論與評估模型
為系統(tǒng)性地解答第一輪運營后產(chǎn)生的核心困惑——即公司與行業(yè)標桿的采納率差距的根本原因，我們設計并啟動了一套多維度、多廠商的智能編程工具效能評測體系。
同時，在大模型技術高速迭代的背景下，市場上新產(chǎn)品、新功能層出不窮，性能迭代周期往往以月甚至周為單位計算，對外部產(chǎn)品的持續(xù)調研不僅是信息收集，更是保持技術競爭力的前提。將行業(yè)橫向對標納入調研范圍，定期與同業(yè)交流智能編程工具的推進情況與成效指標，能幫助企業(yè)判斷當前行業(yè)的真實應用深度與普遍痛點，另一方面也為產(chǎn)品迭代提供了可參照的基準線。
3.1.1 評測原則與方案設計
為保證評測結果的有效性與普適性，我們在方案設計中遵循了以下核心原則：
用戶代表性(Representativeness)：為避免因用戶樣本偏差導致評測結果失真，我們嚴格篩選了50名測試用戶。這些用戶覆蓋了信息技術部20個不同的研發(fā)群組，其日常使用的編程語言涵蓋Java、JS/TS、Vue、Python、GO等，確保了樣本的崗位、語言分布與公司整體研發(fā)人員的實際情況保持一致。
場景真實性(Authenticity)：所有測試均在用戶的實際生產(chǎn)任務中進行，而非模擬場景。這確保了評測數(shù)據(jù)能夠真實反映工具在處理復雜業(yè)務邏輯與多樣化開發(fā)需求時的真實表現(xiàn)。
測試周期充分性(Adequacy)：我們?yōu)槊考覅⑴c測試的工具都提供了3至4周的實測時間。充足的周期確保了用戶能夠充分熟悉工具并形成穩(wěn)定的使用習慣，從而使得采集到的數(shù)據(jù)更具統(tǒng)計意義和可靠性。
3.1.2 多維度綜合評估模型
我們構建了一個包含數(shù)據(jù)指標、產(chǎn)品功能與用戶體驗三大維度的綜合評估模型，旨在從客觀數(shù)據(jù)、產(chǎn)品能力和主觀感受三個層面進行全方位評估。
數(shù)據(jù)指標(Data Metrics)：此維度聚焦于客觀、量化的效能數(shù)據(jù)，以代碼補全采納率作為業(yè)界通用的核心評價指標。我們通過對后臺數(shù)據(jù)的深度挖掘，驗證了是否存在數(shù)據(jù)美化或“指標膨脹”的情況，并建立了統(tǒng)一口徑以保證跨產(chǎn)品對比的公平性。
產(chǎn)品功能(Product Functionality)：此維度用于評估工具在功能層面的完善度與支撐能力。評估內(nèi)容包括其核心功能點的實現(xiàn)情況、產(chǎn)品迭代速度、產(chǎn)品未來規(guī)劃等，以及廠商交付與支持團隊的配合度等。
用戶體驗(User Experience)：此維度關注開發(fā)者在實際使用過程中的主觀感受。我們通過問卷和深度訪談的方式，收集了用戶對各產(chǎn)品在代碼補全質量、智能問答效果以及交互設計等方面的綜合評分與反饋，以此衡量工具的易用性和實際感知效率。
3.2 引入更多國際輔助編程工具進行聯(lián)合測評
為了建立一個更全面的參照系，客觀評估公司現(xiàn)有工具在全球技術坐標系中的位置，并深入洞察前沿產(chǎn)品的演進趨勢與設計哲學，我們決定將視野拓寬至全球范圍，引入國際主流AI編程工具進行聯(lián)合評測。此舉的目標不僅是進行一次簡單的功能“跑分”，更是希望通過對標分析，理解不同技術路線的優(yōu)劣，為公司自有產(chǎn)品的戰(zhàn)略迭代和未來技術選型提供具備前瞻性的依據(jù)。
3.2.1 測試工具選擇
在眾多國際工具中，我們選擇Cursor作為本輪評測的核心對象。做出這一選擇并非偶然，而是基于其在AI輔助編程演進路徑上的獨特性和代表性：
1）形態(tài)差異：與我們之前測試的、以內(nèi)置插件形式存在的國內(nèi)工具不同，Cursor代表了“智能IDE”的典型形態(tài)。它并非在傳統(tǒng)IDE上“附加”AI能力，而是一個AI原生(AI-Native)的集成開發(fā)環(huán)境。這種從底層架構開始就為AI設計的理念，使其能夠更深度地理解和操作整個項目代碼庫。
2）能力的躍遷：Cursor的核心能力超越了單點的代碼補全。它支持跨文件上下文的代碼庫問答、智能重構和端到端的小任務執(zhí)行。這正是公司希望探索的下一個能力階段，即AI如何從“輔助敲代碼”轉變?yōu)椤拜o助軟件工程”。我們希望通過對Cursor的評測，預判這種能力躍遷對開發(fā)者工作流的真實影響。
3）趨勢引領：Cursor的產(chǎn)品哲學和功能迭代速度，使其成為觀察全球AI編程工具發(fā)展趨勢的重要窗口。通過深入使用和評測，我們可以更直觀地把握未來AI編程工具可能的設計方向和用戶交互模式。
3.2.2 測試方法
在測試方案設計環(huán)節(jié)，我們意識到此類國際產(chǎn)品雖然可參考國內(nèi)產(chǎn)品的整體測試方法論，但卻無法完全復刻并在同一口徑下進行測評。
一是Cursor獨特的產(chǎn)品形態(tài)對于用戶本身來講是一個挑戰(zhàn)，它要求開發(fā)者從熟悉的IDE切換到一個全新開發(fā)環(huán)境，并且學習掌握Coding Agent下的開發(fā)范式。因此，我們設計測試的重點不僅在于評估其功能表現(xiàn)，更在于觀察和理解開發(fā)者在適應全新人機協(xié)作范式過程中的行為與反饋。
我們關注的問題包括：開發(fā)者是否愿意為了更強的AI能力而改變自己長期形成的工具習慣？新的交互模式(如對話式重構、代碼庫問答)在真實開發(fā)場景中的使用頻率和有效性如何？
二是，由于Cursor是云端服務，使用過程中不可避免地涉及代碼數(shù)據(jù)的傳輸。為嚴格遵守金融行業(yè)的監(jiān)管規(guī)定和公司的數(shù)據(jù)安全紅線，本次測試無法像國內(nèi)工具一樣，在實際生產(chǎn)環(huán)境中進行私有化部署和測試。為此，我們設計了專門的兼顧安全與可信的測試方案：
1）測試人群選擇：我們并未進行大規(guī)模推廣，而是精心篩選了一批“種子用戶”參與測試。這些用戶需同時滿足兩個條件：第一，其當前從事的開發(fā)任務不涉及公司核心業(yè)務或敏感數(shù)據(jù)，例如負責內(nèi)部創(chuàng)新項目、技術預研或開源工具的二次開發(fā)；第二，結合過往行為數(shù)據(jù)，他們本身是AI編程工具的活躍使用者和積極探索者，具備較高的學習意愿和反饋能力。
2）營造學習與交流氛圍：為了讓參與者能充分發(fā)掘Cursor這類AI原生IDE的潛力，我們并未將此次測試定位為一次簡單的“任務”。在測試期間，我們組織了多次線下分享會和專題交流會，鼓勵用戶分享使用技巧、探討高級用法。這不僅提升了測試的深度，也為團隊培養(yǎng)了一批能夠駕馭下一代AI編程工具的種子用戶。
3.3 國內(nèi)和國際工具評測結果與核心發(fā)現(xiàn)
3.3.1 發(fā)現(xiàn)一：“采納率”指標的口徑差異
在對多款智能編程工具進行評測后，我們發(fā)現(xiàn)一項核心問題：各產(chǎn)品對于關鍵效能指標“采納率”的計算口徑存在顯著差異。通過深度測試與分析，我們識別出部分編程輔助工具在計算采納率時，會通過調整計算公式中的分母(即代碼建議的總展示次數(shù))來改變最終的指標數(shù)值。這種調整主要通過引入特定的數(shù)據(jù)過濾規(guī)則來實現(xiàn)。
為了建立客觀的評估基準，我們首先定義了嚴格定義下的“基準口徑”，其不包含任何數(shù)據(jù)過濾：
基準口徑：將所有在屏幕上有效展示給用戶的代碼建議次數(shù)(E )均納入分母：
與基準口徑相比，各個工具的后臺管理面板中的采納率計算，都采用了了“膨脹口徑”，在計算分母時引入了過濾條件使得采納率膨脹：
膨脹口徑：這類口徑通?；诖a建議在屏幕上的停留時長來篩選數(shù)據(jù)。例如，將停留時間過短或過長的建議從分母中剔除。除此之外，還可能對內(nèi)容相似的重復建議在分母中進行去重計算，而分子(采納次數(shù))則保留原始計數(shù)。其通用公式可表示為：
這種調整從實際意義上似乎更具有業(yè)務合理性，因為它試圖排除用戶無感知的瞬時建議或重復的無效建議，聚焦于衡量更有價值的交互行為。但實際上更科學的做法是對分子A同樣進行的過濾，忽視掉那些被采納前在屏幕上停留時間屬于分母過濾條件區(qū)間的記錄，我們稱其為對稱膨脹口徑：
由于在參與測試的大部分工具數(shù)據(jù)埋點設計中，被采納后的代碼補全記錄數(shù)據(jù)不再記錄對應的上屏時間，我們僅提供其中一款產(chǎn)品的數(shù)據(jù)進行參考：
表3 各測試產(chǎn)品在不同口徑下的采納率詳情
*大部分產(chǎn)品對采納記錄的上屏持續(xù)時間埋點缺失，導致無法計算在其他膨脹口徑及對稱膨脹口徑下的采納率。
可以看出，對稱口徑下采納率相比于基準口徑并沒有大幅度的提升，遠遠低于膨脹口徑數(shù)值。由此可見，產(chǎn)品的膨脹口徑過濾條件可能是比實際情況更加苛刻的，從而大量過濾掉了用戶可能會產(chǎn)生采納行為的上屏記錄。
除此之外，由于各產(chǎn)品對于有效交互的定義和篩選標準完全不統(tǒng)一，這使得膨脹口徑下的采納率指標喪失了跨產(chǎn)品橫向對比的客觀性和公平性。所以在進行技術選型和效能評估時，不能僅依賴提供方的數(shù)據(jù)，而必須深入理解其指標的計算邏輯。建立一套統(tǒng)一、透明、嚴謹?shù)亩攘亢怏w系，是客觀評價智能編程工具真實效能、避免價值誤判的關鍵前提。
3.3.2 發(fā)現(xiàn)二：國際工具效能度量的演進與現(xiàn)實挑戰(zhàn)
在揭示了“采納率”指標的局限性后，我們進一步對Cursor做了深度評測，對于代表未來的“第二代”AI編程工具，我們發(fā)現(xiàn)不僅需要全新的效能度量衡，更看到其在技術、生態(tài)和用戶習慣方面面臨的現(xiàn)實挑戰(zhàn)。
1）Agent模式正漸漸成熟為具有生產(chǎn)力的工具
相比起“第1.5代”結合代碼補全與簡單問答的AI代碼輔助插件，Cursor更具特點的功能是其Coding Agent能力。所以我們需要關注的數(shù)據(jù)不僅是代碼補全場景的調用、上屏、采納等，還需要額外收集Agent模式下提供的代碼增刪建議行數(shù)以及代碼增刪采納行數(shù)。
我們對80名種子用戶進行了為期兩個月的深度測試，并選取后一個月(行為數(shù)據(jù)穩(wěn)定后)的數(shù)據(jù)進行分析，可以發(fā)現(xiàn)：
表4 Cursor測試用戶行為數(shù)據(jù)詳情
* 數(shù)據(jù)來源與Cursor管理后臺聚合結果，其中代碼補全官方僅提供次數(shù)數(shù)據(jù)；Agent模式的建議和采納中包括了刪除和新增。
一是Agent模式下的用戶采納意愿與傳統(tǒng)代碼補全模式存在代際差異。如表中所示，Agent模式無論是按行數(shù)(76.9%)還是按次數(shù)(73.1%)計算，其采納率都達到了一個極高的水平。這與傳統(tǒng)代碼補全10~20%的采納率形成了鮮明對比。
這一數(shù)據(jù)有力地證明，當AI從一個被動的“建議者”轉變?yōu)橐粋€主動的“執(zhí)行者”時，其產(chǎn)出與開發(fā)者意圖的契合度得到了根本性的提升。在Agent模式下，用戶通過自然語言下達明確指令，AI基于對任務的理解進行代碼生成與修改，這種高意圖的交互模式，是其高采納率的核心原因。
第二，開發(fā)者正利用Agent模式處理大規(guī)模的工程任務。在一個月內(nèi)，僅80名用戶就通過Agent模式生成了近180萬行代碼建議，并最終采納了超過138萬行。這表明用戶并非用其進行小修小補，而是將其作為核心生產(chǎn)力工具，處理包括模塊構建、代碼重構、復雜邏輯生成等大規(guī)模任務。平均到每一次交互，Agent單次建議的代碼量約為124行，這進一步印證了其作為工程智能體而非補全工具的核心價值。
2）傳統(tǒng)IDE的生態(tài)基礎是AI原生IDE進行替代的主要壁壘
盡管AI原生IDE在能力上展現(xiàn)了未來趨勢，但我們的測試明確地揭示了“智能IDE并不適用于全部場景”這一現(xiàn)實。最大的阻力來自于現(xiàn)有IDE強大的生態(tài)壁壘。以Java開發(fā)者為例，他們對IntelliJ IDEA存在極強的依賴。這種依賴遠不止于編碼習慣，而是深度根植于IDEA為Java提供的短期難以替代的生態(tài)能力：從無縫集成的Maven/Gradle構建工具，到業(yè)界頂尖的調試、重構和靜態(tài)分析能力。短期內(nèi)，任何新興的智能IDE都難以復制這一深厚的生態(tài)護城河。
我們的種子用戶反饋非常一致：即便掌握了一些在Cursor和IDEA之間聯(lián)動的技巧，他們依然更傾向于在自己熟悉的IDEA中使用“具備類Cursor能力的插件”，而不是為了更強的AI能力而徹底放棄原有的、高效的開發(fā)環(huán)境。這說明，對于有深厚生態(tài)依賴的開發(fā)者而言，他們追求的是能力的平移，而非平臺的遷移。
3）國內(nèi)外工具差異對比分析
結合前述的定量指標與定性訪談，我們得以清晰地勾勒出以國內(nèi)插件為代表的“第1.5代”工具與以Cursor為代表的“第2代”工具之間的核心差異：
表5 國內(nèi)外工具差異對比
4）基礎模型能力和大量場景化微調模型決定了顯著更優(yōu)的效能表現(xiàn)
在深入對比后，我們發(fā)現(xiàn)Cursor之所以強大，除了其Coding Agent的工程設計以外，更本質的是它支持對接當前全球范圍內(nèi)最強大的大語言模型，這些強力模型提供了高質量的推理和代碼生成能力。Agent模式特有的多文件編輯、終端信息獲取等工具調用及項目代碼理解，都對基礎大模型有極高的要求：指令遵循、代碼生成質量、上下文窗口長度等性能要求缺一不可。
所以國內(nèi)產(chǎn)品迭代速度似乎落后于國際化的產(chǎn)品，可能根源并不是工程能力的不足或是產(chǎn)品本身的設計壁壘，更多的可能是受限于基礎模型。
這種模型對效果的影響是全方位的，我們觀察到，即便是用于實時代碼補全的“小模型”，Cursor也遠勝于參與測試的國內(nèi)插件。其高效的“Next Edit Prediction”(下一次編輯預測)能力，使其建議更貼近開發(fā)者的真實意圖，超出了簡單的下一段代碼補全范疇。
這表明，無論是實現(xiàn)簡單的代碼補全，還是驅動復雜的Coding Agent，工具最終能達到的天花板，幾乎完全由其所能調用的模型能力和針對各場景微調的細分模型決定。對于企業(yè)而言，這意味著在技術選型或自研投入時，對模型能力的評估權重需要被更進一步放大，并且為了設計出服務于未來的產(chǎn)品，企業(yè)可能需要對后續(xù)模型能力的邊界有更清晰的預判。
03
AI輔助編程的工程風險
金融行業(yè)作為對系統(tǒng)合規(guī)性、安全性要求嚴苛且容錯率極低的關鍵領域，金融系統(tǒng)的故障不僅可能導致經(jīng)濟損失，更可能引發(fā)數(shù)據(jù)泄露、監(jiān)管處罰乃至市場信任危機，其業(yè)務特性與技術場景對AI輔助編程提出了當前階段需重點關注的挑戰(zhàn)與風險。
1. 單系統(tǒng)架構缺陷和多系統(tǒng)復雜架構考慮不足
證券、銀行等金融領域的業(yè)務數(shù)據(jù)與任務具有時序性、高波動性特征，且需嚴格遵循合規(guī)標準與安全規(guī)范。經(jīng)過數(shù)十年發(fā)展，主流金融機構普遍形成包含數(shù)百至數(shù)千個關聯(lián)模塊的復雜系統(tǒng)集群，系統(tǒng)間交互與依賴關系錯綜復雜。
但當前金融機構應用AI輔助編程時，多采用“局部代碼庫/代碼片段調用”模式，AI僅基于有限上下文生成功能代碼，用于輔助開發(fā)與測試。這種模式下，AI生成代碼在小規(guī)模測試或低負載場景中表現(xiàn)正常，但在真實業(yè)務尤其是極端壓力場景下，容易暴露架構缺陷。
典型案例包括：未優(yōu)化的數(shù)據(jù)庫查詢語句在交易峰值時拖垮數(shù)據(jù)庫服務；權限校驗邏輯因AI對整體權限體系理解不足出現(xiàn)漏洞，導致敏感數(shù)據(jù)泄露。且AI生成代碼“量大、碎片化”，人工審核難以全覆蓋，問題排查與修復成本遠超開發(fā)時間。
架構缺陷的根源在于，AI缺乏對單系統(tǒng)整體性的認知，更無法理解多系統(tǒng)交互邏輯，代碼生成僅依賴局部需求與上下文，無法預判全系統(tǒng)交互影響。例如，轉賬系統(tǒng)中，AI生成的日志代碼未考慮與清算系統(tǒng)的異步通信，月末批量清算時數(shù)據(jù)積壓導致流程中斷；未優(yōu)化查詢代碼在數(shù)據(jù)量達百萬級時觸發(fā)全表掃描，引發(fā)服務器崩潰。此類問題多在業(yè)務峰值(如股市開盤、節(jié)假日轉賬高峰)暴露，不僅造成業(yè)務損失，還可能觸發(fā)監(jiān)管風險。
架構問題與普通功能缺陷本質不同：普通缺陷可局部修復，架構缺陷可能導致系統(tǒng)邏輯與業(yè)務需求不匹配，企業(yè)或面臨“推翻重構”的高昂成本。因此，對AI生成的核心模塊(如交易引擎)與重要業(yè)務鏈路(如資金清算)代碼，由資深架構師開展架構評審，結合峰值場景設計壓力測試，評估并發(fā)性能、數(shù)據(jù)一致性等非業(yè)務功能，更能保障系統(tǒng)的高可用要求。
2. 金融業(yè)務復雜性下邊界情況考慮不足
受限于對金融業(yè)務邏輯的深度理解，AI生成的邏輯代碼存在“假性正確”：常見場景下運行正常，邊界條件、特殊輸入或極端規(guī)則觸發(fā)時易產(chǎn)生致命錯誤。金融業(yè)務邏輯包含大量細分規(guī)則、例外條款與交叉約束，如利息計算需兼顧基準利率、客戶分級分群等多變量，定價估值需適配不同產(chǎn)品風險模型和參數(shù)配置，這些邊界場景容易成為AI的“盲區(qū)”。這些漏洞觸發(fā)概率低、但風險高，常規(guī)人工測試通常也難以覆蓋，而AI生成的測試用例更傾向常見場景(概率性)，進一步增加此類風險。
防范此類風險需建立“異常組合測試”機制：依托金融專家經(jīng)驗梳理歷史邊界場景，構建專項測試庫；引入模糊測試、符號執(zhí)行技術，主動挖掘潛在漏洞。同時明確，AI測試用例僅作常規(guī)場景補充，核心業(yè)務模塊的邊界測試需以專家主導的方案為核心，覆蓋全量特殊規(guī)則。
3. 可維護性和可擴展性不足
當前AI生成的代碼普遍缺乏可讀性和最合理的結構，典型現(xiàn)象如“中間件配置分散在多個文件”、“核心邏輯缺乏分層設計”，導致可維護性與可擴展性不足，且維護成本隨系統(tǒng)復雜度呈指數(shù)級增長。當問題發(fā)生時，診斷和追溯邏輯關聯(lián)耗費的時間和精力可能遠超過重構；當業(yè)務小幅調整時，需大量交互才能讓AI正確修改代碼，出現(xiàn)“生成Demo五分鐘，修改配色兩小時”的低效情況。
常見問題體現(xiàn)在三方面：一是代碼規(guī)范性不足，不符合金融機構數(shù)據(jù)與研發(fā)規(guī)范，缺乏必要注釋，維護人員難理解設計意圖；二是邏輯分散且耦合度高，修改一處可能引發(fā)連鎖反應；三是設計決策缺失，AI不記錄選型理由，還可能生成冗余代碼，維護人員需大量時間逆向推導邏輯。
人工維護和迭代的“規(guī)范規(guī)則”和“代碼信任分級”入手：一方面制定AI生成代碼專項規(guī)范，明確格式、注釋、模塊劃分標準，開發(fā)自動化校驗工具；另一方面采用“漸進式信任”策略，初期僅允許AI生成非核心模塊代碼，而核心邏輯與關鍵文檔由人工開發(fā)維護，以“人工主導、AI輔助”平衡效率與可維護性。
4. 小結
在大模型技術研究領域，多項研究已明確當前技術架構下的固有局限性。
一方面，研究者通過理論推導與實驗驗證，證實幻覺現(xiàn)象在現(xiàn)有大模型體系中具備不可避免性：
Kalai與Vempala的研究指出，“經(jīng)過校準的語言模型必然會產(chǎn)生幻覺”，從理論層面揭示了幻覺與模型校準間的內(nèi)在關聯(lián)(Kalai A T, et al, 2024)；同期Xu、Jain與Kankanhalli進一步論證，幻覺并非技術優(yōu)化可完全消除的缺陷，而是大語言模型(LLM)在信息生成機制上的“固有局限性”，為幻覺的不可避免性提供了更全面的證據(jù)支撐(Xu Z, et al, 2024)。
直觀理解，OpenAI團隊的2025年9月的研究認為，當前大模型的標準訓練和評估程序傾向于獎勵模型的猜測行為，而不是獎勵模型承認其結果有不確定性(Kalai A T, et al, 2025)。
另一方面，大模型的可解釋性問題也隨著研究深入暴露出更復雜的挑戰(zhàn)。2025年4月，Bengio團隊的研究打破了行業(yè)對“思維鏈(Chain of Thought, CoT)等同于可解釋性”的認知誤區(qū)——該研究發(fā)現(xiàn)，當前學界與產(chǎn)業(yè)界普遍視作LLM可解釋性關鍵載體的CoT，并非模型真實的推理過程；
更值得警惕的是，AI甚至可能主動隱藏其底層的(思考)推理邏輯，而模型實際依賴的“潛在推理空間(Latent-space Reasoning)”因技術限制無法被人類觀測與解析(Bengio Y, et al, 2025)。這一發(fā)現(xiàn)直接挑戰(zhàn)將思維鏈作為可解釋性的解決方案，CoT的“偽解釋性”可能掩蓋模型決策的潛在風險，加劇AI應用中的不確定性(Korbak T, et al, 2025)。
基于上述技術局限性，我們必須重新審視對LLM生成內(nèi)容的信任邊界：既不能過度依賴LLM展示的“思維鏈CoT”作為其推理合理性的證明，也不能輕信模型對自身行為的描述——因為在概率性文本生成機制下，模型可能并未執(zhí)行其所宣稱的推理過程，僅是基于訓練數(shù)據(jù)的統(tǒng)計規(guī)律生成了符合人類預期的文本，其內(nèi)容與真實推理邏輯可能存在顯著偏差。
這一認知在生產(chǎn)級軟件研發(fā)場景中更具現(xiàn)實意義。生產(chǎn)級軟件研發(fā)需要嚴謹?shù)慕Y構化工程思維，“代碼可運行”僅滿足最基礎的功能要求，遠不等于“可交付”的質量標準，更無法等同于“可靠”的工業(yè)級應用規(guī)范；同理，LLM生成代碼的能力也不能與完整的軟件工程劃等號。
代碼只是軟件工程師眾多交付物中的一環(huán)，真正的軟件工程是貫穿研發(fā)全流程的系統(tǒng)性決策過程：從需求階段對業(yè)務合理性與優(yōu)先級的判斷，到設計階段對業(yè)務架構、復雜系統(tǒng)架構的規(guī)劃，再到開發(fā)與運維階段對研發(fā)效率與技術標準的權衡，每一步?jīng)Q策都直接決定軟件系統(tǒng)的質量、可維護性與長期價值。由此可見，軟件工程的核心價值在于工程師的系統(tǒng)架構能力與決策判斷力，而非單純的代碼生成速度。
因此，在AI編程技術快速發(fā)展的背景下，我們應明確AI的定位：若以規(guī)范研發(fā)流程、升級工程實踐為目標，AI并非要替代軟件工程師，而是需要與具備系統(tǒng)思維和風險意識的專家協(xié)同。未來的發(fā)展方向，應是通過技術優(yōu)化強化工程紀律，將AI轉化為可控的生產(chǎn)力工具，最終在提升研發(fā)效率與保障軟件系統(tǒng)可靠性之間找到動態(tài)平衡。
相比于“AI威脅替代論”，營造積極向上的氛圍更能激發(fā)軟件工程師們的創(chuàng)造力和工作效率，畢竟，AI輔助編程的英語是“氛圍編程”(Vibe Coding)，初衷是激發(fā)大家激情(vibe)的。
04
下一個AI編程時代的程序員與金融機構
1. 為什么這次軟件工程師似乎是擁抱智能研發(fā)最慢的一批人？
在科技迭代的浪潮中，從版本控制工具(如Git)的普及，到云原生技術的全面落地，再到DevOps理念的廣泛實踐，軟件工程師群體向來以敏銳的技術嗅覺和積極的接納態(tài)度，沖在每一次研發(fā)工具更新的最前沿，主動將新技術融入工作流程，推動研發(fā)效率的持續(xù)提升。
然而，在當前智能研發(fā)技術快速發(fā)展的背景下，這一群體卻呈現(xiàn)出明顯的“謹慎性滯后”——相較于其他行業(yè)對AI工具的積極擁抱，許多軟件工程師對AI輔助編程工具的接受度不高，甚至存在抵觸情緒。他們常給出的評價是“現(xiàn)在AI做不了我在做的事情”，這種反差現(xiàn)象值得深入探討。
從技術邏輯來看，AI輔助編程工具要實現(xiàn)高效賦能，需要滿足一系列前提條件。首先，需要全面的知識傳承和記錄，包括項目架構設計思路、業(yè)務邏輯梳理、歷史問題解決方案等，這些信息是AI理解項目背景的基礎；其次，清晰的需求定義和明確的功能邊界至關重要，只有需求清晰，AI才能準確生成符合預期的代碼；再者，完備且統(tǒng)一規(guī)范的文檔和注釋是關鍵支撐，規(guī)范的文檔能幫助AI快速理解代碼邏輯，減少生成錯誤代碼的概率；此外，還需要可復現(xiàn)的開發(fā)環(huán)境和良好的編碼規(guī)范來確保AI生成的代碼順利運行，以及提升代碼的可讀性和可維護性。
這些前提條件恰好是理想研發(fā)場景中程序員需要達成的工作標準，但在實際研發(fā)過程中，各類現(xiàn)實問題導致理想場景難以實現(xiàn)。
一方面，“一句話業(yè)務需求”成為常態(tài)，業(yè)務需求方往往僅通過簡短描述提出需求，缺乏詳細的邏輯梳理和邊界定義，使得AI難以準確捕捉需求核心和準確的邏輯；另一方面，歷史遺留問題和龐大系統(tǒng)集群的“技術債”不斷累積，許多老舊系統(tǒng)缺乏規(guī)范文檔，代碼邏輯混亂，AI無法快速理解系統(tǒng)架構，生成的代碼難以融入現(xiàn)有系統(tǒng)；
同時，緊急需求的應急修復常常打破編碼規(guī)范，為了快速上線功能，程序員往往忽略代碼質量和文檔編寫，進一步加劇了系統(tǒng)的不規(guī)范性；此外，在需求密集的項目中，研發(fā)人員常因時間緊張而無暇撰寫詳細文檔和注釋，導致項目知識傳承出現(xiàn)斷層。
這些現(xiàn)實問題的疊加，使得AI輔助編程工具在復雜業(yè)務系統(tǒng)開發(fā)中難以發(fā)揮有效作用，進而導致軟件工程師對智能研發(fā)工具的信任度不足，成為其擁抱智能研發(fā)較慢的重要原因。
2. 初級程序員和軟件專家對AI編程工具的定位
JetBrains2025年針對3380名開發(fā)者的調研顯示，編碼經(jīng)驗不決定AI工具的使用與否，但影響開發(fā)者對AI輔助工具的角色定位：資深開發(fā)者多將AI視為“初級同事(Junior Colleague)”、“內(nèi)容生成器(Content Generator)”、甚至“無明確角色”；初級開發(fā)者則更傾向視其為“導師(Teacher)”。
初級開發(fā)者在使用AI編程工具時，往往表現(xiàn)出選擇性注意的行為模式。心理學家Chabris和Simons在1999年通過著名的“隱形大猩猩”實驗向我們展示了這一現(xiàn)象：當志愿者專注于數(shù)傳球次數(shù)時，即使一位穿著大猩猩服的人從鏡頭中走過，也極易被忽視。
對于初級開發(fā)者而言，AI給出的代碼能跑便是那個引人聚焦的目標，他們因而容易忽略關鍵細節(jié)：包括邏輯完整性、邊界條件、代碼整潔性、錯誤容忍性、性能瓶頸和長期可維護性。這些本該引起警覺的因素，就像實驗中那只被忽略的“大猩猩”。
資深開發(fā)者在AI輔助編程中，常將“認知卸載”作為核心策略，即將部分思考任務交由外部工具或系統(tǒng)承擔，從而騰出精力專注于更高層次的決策與設計。例如，他們會利用AI自動檢測代碼中的缺陷、低效實現(xiàn)或反模式，讓工具先完成基礎掃描，再將自身注意力集中在架構優(yōu)化與整體設計完善上。
不同于完全依賴AI的做法，資深開發(fā)者的習慣是讓AI服務于既有的工程規(guī)范與審查方法，而非用新的“全AI化”習慣替代原有的專業(yè)流程。與此同時，資深開發(fā)者在評估AI生成的修改建議時，他們不僅關注方案是否可行，還追求明確理解為什么可行。
當AI提出大量重構、模式或優(yōu)化建議時，他們會自覺過濾：這是在解決核心問題，還是僅僅讓提示詞中描述的錯誤不出現(xiàn)？這樣的實現(xiàn)六個月后是否依然易于理解？它是否真正降低了潛在的故障風險？這種追求簡潔與本質的態(tài)度，使得資深開發(fā)者在AI時代依然保持對代碼質量與工程可持續(xù)性的掌控。
3. 對未來AI輔助編程范式的暢想
未來AI輔助編程的形態(tài)，既不會完全復刻當前“逐行編寫代碼”的底層模式，也無法通過“幾句話描述”實現(xiàn)自動化程序開發(fā)(因為大量細節(jié)難以通過簡單描述精準傳遞)。前者類似細致的生產(chǎn)操作手冊，后者更像簡化宣傳的廣告，而未來的軟件工程可能會是二者的混合形態(tài)，類似“產(chǎn)品說明書”的中間層呈現(xiàn)，需圖文結合傳遞完整需求。
這一變化將深刻影響開發(fā)工具形態(tài)：未來集成開發(fā)環(huán)境(IDE)或許會徹底變革，AI編程不再是IDE的插件，將軟件工程模塊融入業(yè)務工作臺，“編碼即業(yè)務操作”(Coding as You Trade)作為未來發(fā)展的一個可能模式確實令人憧憬和激動。
3.1 功能與能力
大模型及其應用生態(tài)的飛速演進，確實很難說未來AI輔助編程到底“能做什么”，那不如審視還有哪些是AI短期內(nèi)難以企及的領域。當我們以發(fā)展的眼光來看，模型的推理能力越來越強，代碼邏輯越來越健全，甚至上下文窗口足以吞得下整個項目甚至相關項目的每一行代碼，那還有什么是無法做到的？
可能最大的局限在于對復雜、隱性的業(yè)務場景理解與系統(tǒng)架構設計能力。企業(yè)級的軟件需求遠比“一句話生成應用”的理想場景復雜，它深度關聯(lián)歷史需求、現(xiàn)有系統(tǒng)與基礎設施。開發(fā)者無法將所有的背景信息、技術債務和未來規(guī)劃都作為上下文輸入給AI，這導致AI難以獨立完成高質量的需求分析。
同理，在系統(tǒng)架構設計上，如何最大化復用現(xiàn)有IT設施、如何為未來的業(yè)務演進提供擴展性與通用支持，這些決策背后融合了對技術、業(yè)務與組織的綜合考量，是當前AI尚無法企及的戰(zhàn)略性思考。
3.2 用戶體驗與協(xié)作模式
兩大趨勢正逐漸顯現(xiàn)。
一是去IDE化。未來的開發(fā)環(huán)境可能不再是傳統(tǒng)的集成開發(fā)環(huán)境(IDE)，而是類似Devin所展示的AI原生工作臺。在這種范式下，開發(fā)者的核心輸入不再是代碼，而是自然語言、文檔、圖表乃至語音視頻，交互變得更加直觀與高效。
二是人機協(xié)作流程的自動化與重塑。開發(fā)者將從具體的開發(fā)流程中逐漸剝離，轉變?yōu)楸O(jiān)督者與決策者。例如，當代碼倉庫收到一個新的Issue，AI編程智能體將自動拉取需求，嘗試獨立規(guī)劃、編碼、測試并提交代碼。開發(fā)者僅需在最終環(huán)節(jié)，借助AI的輔助分析，進行審核與合并確認即可。
3.3 效能提升的邊界
影響AI提效的核心因素將不再是編程語言或技術棧，而是項目的安全性與可靠性要求。對于創(chuàng)新性的、容錯率高的項目，開發(fā)者可以像使用高級語言一樣，不必完全探究AI生成代碼的底層邏輯，實現(xiàn)“能跑就行”的快速交付。然而，對于金融交易系統(tǒng)這類高風險、高可靠性的關鍵項目，開發(fā)者必須逐行校驗AI生成的代碼，確保其邏輯的嚴謹性與安全性。在這種場景下，“讀懂AI”所耗費的認知成本，可能不亞于親手編寫代碼，這將成為AI輔助編程在關鍵領域提效的天然瓶頸。
3.4 敏捷開發(fā)模式的可持續(xù)性存疑
基于AI輔助編程對上下文的強依賴，傳統(tǒng)“小步快跑”的敏捷模式需要被重新審視。敏捷開發(fā)的核心價值在于通過高頻小幅迭代快速響應需求變化，降低單次變更的風險與成本。
但AI輔助編程場景下，每一次小幅變動看似僅涉及局部功能，卻需向AI輸入全量上下文——包括該功能關聯(lián)的歷史代碼邏輯、跨模塊交互規(guī)則、業(yè)務約束條件、系統(tǒng)架構設計規(guī)范、乃至整個代碼庫，否則AI生成的代碼易與現(xiàn)有系統(tǒng)脫節(jié)，引發(fā)兼容性或邏輯沖突。這種“全量上下文輸入—校驗”的重復流程，會顯著增加單次迭代的時間與人力成本，一個簡單的改動可能會產(chǎn)生上萬乃至更大量級的token消耗。
我們不禁產(chǎn)生疑問：當上下文處理成本持續(xù)累積，是否會超出敏捷模式原本追求的效率優(yōu)勢，導致“小步快跑”反而陷入“低效迭代”的困境？并且在現(xiàn)實中的能耗是否真的可以支持大范圍的應用普及？
4. 對軟件從業(yè)者的沖擊
未來軟件從業(yè)者的競爭力分化，本質是AI技術打破編程領域“隱性馬爾薩斯陷阱”后，價值分配重構的結果，我們可以類比第一次工業(yè)革命前后的勞動力結構變革結果來得到一些啟發(fā)。
4.1 編程領域的“隱性馬爾薩斯陷阱”：分化前的平衡態(tài)
在AI大規(guī)模介入前，編程領域的“隱性馬爾薩斯陷阱”，是基于馬爾薩斯原陷阱“資源增速滯后于勞動力增速”核心邏輯的行業(yè)映射。在AI大規(guī)模介入前，該陷阱的核心矛盾集中于“基礎開發(fā)需求”與“開發(fā)者供給”的增速失衡：前者對應原陷阱中的“食物”，受傳統(tǒng)業(yè)務模式穩(wěn)定、新增常規(guī)需求依賴企業(yè)擴張節(jié)奏影響，呈線性增長；后者對應“人口”，因編程培訓普及、基礎入行門檻降低，大量新人涌入基礎開發(fā)賽道，增長速度遠超需求，接近幾何級。
這種失衡并未引發(fā)顯性危機，而是通過“內(nèi)卷化調節(jié)”維持表面穩(wěn)態(tài)——如同馬爾薩斯的“強制抑制”，行業(yè)靠延長工時、壓低項目報價、比拼重復性開發(fā)效率等方式消化過剩供給。最終，普通開發(fā)者的人均價值(薪資、項目話語權)長期停滯，只能困在“多勞多得”的線性勞動框架中，難以通過技術突破或價值創(chuàng)造實現(xiàn)非線性躍遷，形成人均價值被增速失衡鎖定的低水平穩(wěn)態(tài)，即編程領域的“隱性馬爾薩斯陷阱”。
4.2 AI的破壞性沖擊
大模型的快速迭代為編程領域注入了“超量供給代碼”的技術因素，直接打破上述平衡。AI如工業(yè)革命創(chuàng)造新產(chǎn)業(yè)需求般，推動編程需求從“常規(guī)實現(xiàn)”向“高附加值創(chuàng)新”升級。這種失衡直接引發(fā)價值分化：“寫可運行代碼”的核心競爭力從較為稀缺能力淪為基礎技能，常規(guī)項目人力需求大幅縮減，普通開發(fā)者面臨“競爭加劇—薪資停滯—技能貶值”的困境。
而另外少數(shù)的兩類人則會變得更加稀缺且高價值，一類是喬布斯式的“設計創(chuàng)新者”，這類人才的核心價值是“跨維度的需求洞察與創(chuàng)造性整合”，而非“代碼實現(xiàn)”。AI為其提供快速原型能力，讓他們的構想從草圖到成品的周期大幅縮短；同時降低實現(xiàn)門檻，使得優(yōu)秀設計更快得到驗證與落地。換句話說，AI并沒有取代他們的創(chuàng)造力，反而成為其生產(chǎn)力的放大器；
另一類人才是核心系統(tǒng)的“架構戰(zhàn)略者”，具有AI難以跨越“隱性知識壁壘”。他們的核心價值或在前沿算法與工程領域實現(xiàn)關鍵性突破，或是“基于業(yè)務全生命周期的戰(zhàn)略性決策”，涵蓋歷史技術債務梳理、現(xiàn)有IT設施復用、未來業(yè)務擴展性預留等，這些信息中大部分是“隱性知識”(如歷史項目的坑點、未文檔化的約束經(jīng)驗)，無法通過“prompt”完整輸入AI。且隨著系統(tǒng)復雜度提升，這類人才的“不可替代性溢價”會持續(xù)上升。
4.3 分化的本質是“編程行業(yè)的產(chǎn)業(yè)升級”
從馬爾薩斯陷阱邏輯延伸可知，此次從業(yè)者沖擊并非“AI取代程序員”，而是編程行業(yè)從勞動密集型(依賴人力堆代碼)向知識密集型、創(chuàng)造密集型(依賴創(chuàng)新與戰(zhàn)略)轉型的必然階段。工業(yè)革命使得手工紡織工人因蒸汽機被替代，但“機器設計者”、“工廠管理者”成為稀缺人才。如今編程領域的分化是同一邏輯的復刻：技術替代淘汰“重復性勞動”，但催生“技術駕馭者”和“價值創(chuàng)造者”。未來，軟件從業(yè)者若無法向“創(chuàng)新者”或“架構者”轉型，其競爭力將持續(xù)弱化；而兩類高價值人才的稀缺性，會推動行業(yè)薪資差距進一步擴大，形成“高端人才價值倍增，普通人才價值被稀釋”的格局。
這一判斷的核心邏輯在于：AI的技術邊界決定了其僅能替代“可標準化、可數(shù)據(jù)化”的工作，而人類的核心價值始終錨定于“創(chuàng)造性、戰(zhàn)略性、隱性知識驅動”的工作，這既是打破馬爾薩斯陷阱的關鍵，也是未來從業(yè)者競爭力的核心錨點。
4.4 軟件工程師如何重塑自身核心競爭力？
軟件工程師核心競爭力的重塑需聚焦“觀察—判斷—決策”三維能力：對需求、市場與客戶的精準觀察，對動態(tài)趨勢的理性判斷，對解決方案與架構的科學決策。最顯著的趨勢便是，程序員的核心競爭力已從“執(zhí)行者”轉向“指揮者”，他們需要學會如何將業(yè)務目標轉化為精確的意圖表達，通過Prompt Engineering、過程監(jiān)督與結果校驗來引導AI完成高質量產(chǎn)出。
同時，復雜系統(tǒng)架構設計能力的重要性日益凸顯，金融企業(yè)的核心系統(tǒng)往往需要在高并發(fā)交易、嚴格風控、合規(guī)監(jiān)管、跨系統(tǒng)調用與容災備份等多重約束下保持穩(wěn)定，既要兼顧實時性和安全性，又要保證后續(xù)擴展性與可維護性。這類頂層架構涉及跨業(yè)務線的流程梳理、接口規(guī)范、數(shù)據(jù)治理和安全邊界劃定，本質上是對業(yè)務理解與技術洞察的結合，遠超出當前AI的生成能力。
4.5 長期看，AI是否可能徹底替代軟件工程師？
從AI發(fā)展的抽象邏輯出發(fā)，丹尼特(Daniel C. Dennett)的“多重草稿模型”(Multiple Drafts Model)為解析意識與AI心智關系提供了一個參考理論框架。該模型認為，意識不是單一的中心控制過程，而是大腦內(nèi)多個并行的信息處理“草稿”持續(xù)競爭、篩選、整合的動態(tài)過程。神經(jīng)活動不斷生成碎片化的感知與認知草稿，在互動中優(yōu)勝劣汰，最終形成連貫的主觀意識體驗。
基于此模型，丹尼特進一步衍生出四種層級化心智模型：從基礎的“達爾文式心智”(依賴先天本能反應)，到“斯金納式心智”(通過后天強化學習調整行為)，再到“波普爾式心智”(能在內(nèi)部模擬未來場景以規(guī)避風險)，最終到“格列高利式心智”(借助語言、工具等文化符號拓展認知邊界)。四層心智根據(jù)“虛擬機層層疊加”機制層層遞進：底層提供基礎運算與反應能力，上層則在其基礎上整合更復雜的信息、融入文化符號，每一層心智都以底層心智為支撐，如同虛擬機嵌套，最終涌現(xiàn)人類復雜心智。
筆者認為，意識的本質，正是在這一疊加過程中，“生物神經(jīng)機制”與“文化符號體系”形成的“二維競合”：生物本能為意識提供物質基礎，文化則規(guī)范認知方向，二者既相互制約(如文化倫理約束本能沖動)，又相互促進(如語言符號強化邏輯思維)，共同推動意識復雜度升級。
若認可這一邏輯，便會發(fā)現(xiàn)其與AI領域的Scaling Law(規(guī)模定律)高度契合。Scaling Law的核心是AI通過擴大X軸(模型參數(shù)和數(shù)據(jù)量，如2022年ChatGPT 3.5)或者延伸Y軸(推理時間Inference-time，如2025年DeepSeek-R1)，實現(xiàn)能力層級的階梯式躍升——基礎模型(如Transformer架構)如同“達爾文式心智”提供底層運算能力，當前和未來的各種新技術則像“斯金納式”到“格列高利式”心智的嵌套，不斷疊加形成更復雜的智能。
這種“層層疊加”正是AI演進的核心優(yōu)勢：如果我們認可主流的“多重草稿模型”，那么這種層層疊加的機制正對照AI領域的Scaling Law，也是AI演進的強項，AI在未來不但有可能徹底替代軟件工程師，而且最終也會涌現(xiàn)復雜心智。
5. 金融機構擁抱AI的思考
歐美社會中一個值得關注的現(xiàn)象是：按小時計費的律師群體，同樣面臨AI提效帶來的職業(yè)焦慮。未來社會對軟件的需求規(guī)模，或許足夠容納當前所有程序員借助AI工具開展工作；但與軟件需求不同，法律案件的數(shù)量未必能支撐AI提效后所有律師的計費時長。這一對比揭示了不同行業(yè)在AI變革中的需求差異。
若企業(yè)將AI編程工具的推廣視為自上而下的強制任務，并以僵化的數(shù)據(jù)指標作為考核標準，可能會帶來一些負面效果。持續(xù)的強硬管理手段在短期內(nèi)通常會迅速提升覆蓋率使用率等數(shù)據(jù)，但長期來看，這種做法可能會帶來一些隱性地負面效果：
一是為了便于用戶數(shù)據(jù)管理，官方提供的工具必然被限定在一個小的范圍內(nèi)，甚至鎖定某一單一產(chǎn)品。然而當前技術迭代迅速，新的工具層出不窮，強制的要求只會抑制工程師的好奇心與自發(fā)探索的熱情，從而錯失發(fā)現(xiàn)更優(yōu)解決方案的機會；
二是員工可能會為了達成數(shù)據(jù)目標而進行無效的工具調用，有人會為了“采納行數(shù)”而隨意提問無效采納。用來評判工具本身性能的指標直接與考核掛鉤很容易把人推向“指標內(nèi)卷”，而不是對問題實質的思考，當AI輔助編程的評價標準異化為內(nèi)部的績效競爭，它便失去了提升生產(chǎn)力的初衷。
因此，金融機構更長遠的競爭力，在于培育一種鼓勵探索與分享的創(chuàng)新文化。管理者需要傳遞更加積極正面的信息：AI輔助編程工具是為了將開發(fā)者從重復勞動中解放出來，讓他們能將精力投入到更具創(chuàng)造性的工作中。企業(yè)應建立分享機制，鼓勵員工交流不同工具的使用心得，包容各類探索。AI輔助編程的理想狀態(tài)，是激發(fā)開發(fā)者的靈感與熱情，而不是施加新的限制。
在這個充滿不確定性的時代，把握“擁抱變化、持續(xù)學習、流程重構”的組織能力，才是長期競爭力的核心。最終，能夠在行業(yè)變革中取得長期優(yōu)勢的，將是那些不僅成功應用AI技術，更是根據(jù)人機協(xié)作新模式重構了的組織文化與流程的企業(yè)。
附錄文獻
(1) Kalai A T, Vempala S S. Calibrated language models must hallucinate[C]//Association for Computing Machinery (ACM). The 56th Annual ACM Symposium on Theory of Computing (STOC 2024), New York, NY, USA, 2024. New York, NY, USA: ACM, 2024: 160-171. DOI: 10.1145/3651084.3654253
(2) Xu Z, Jain S, Kankanhalli M. Hallucination is inevitable: An innate limitation of large language models[EB/OL]. (2024-01-22). https://arxiv.org/abs/2401.11817..
(3) Kalai A T, Nachum O, Vempala S S, Zhang E. Why Language Models Hallucinate[R]. San Francisco, CA, USA: OpenAI, 2025. https://cdn.openai.com/pdf/d04913be-3f6f-4d2b-b283-ff432ef4aaa5/why-language-models-hallucinate.pdf.
(4) Bengio Y, Bordes A, Larochelle H. Chain-of-Thought: A Mirage of Interpretability in Large Language Models[EB/OL]. (2025-04-15). https://arxiv.org/abs/2504.08123.
(5) Korbak T, Balesny M. Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety[EB/OL]. (2025-07-10). https://arxiv.org/abs/2507.10345.