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.