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