当互联网用AI卷效率时，这家公司先问了一连串“能不能”
点击查看原文>
在金融行业，引入一项新技术从来不是一场“军备竞赛”，而是一场严苛的“压力测试”。当 AI 编程工具以惊人的提效速度席卷整个软件行业，许多互联网公司和小型团队迅速将“代码行数”和“Token 消耗”挂上绩效考核，甚至直接与裁员挂钩时，神州信息这家深耕银行核心软件系统的金融科技企业，却选择了一条截然不同的路。
它没有盲目跟风，而是先回到了一个根本问题：我们到底该不该用 AI？ 从 2025 年初开始，神州信息展开了一场长达数月的系统性验证。他们不满足于“代码生成快不快”，而是用真实的金融项目需求做对比测试，从代码质量、任务拆解能力、存量工程匹配度，到开发规范与文档体系的兼容性，每一个维度都经过反复校验，直到确认 AI 生成的代码在缺陷密度和扫描覆盖度上与人工开发“基本持平”，才谨慎地迈出推广的第一步。
更关键的是，当外界将“提效”与“裁员”划等号时，神州信息给出了完全不同的答案。面对金融系统固有的复杂性——账务一致性、7×24 小时高可用、严格的合规与问责——他们深知，AI 现阶段只能作为经验工程师的“副驾驶”，而非替代者。省下来的人效，被用来承接更多项目、覆盖更多场景，而非减少一个岗位。他们甚至警惕“能力断层”的风险，坚持保留初级工程师的培养路径。
正是这种基于严谨验证、拒绝激进裁员、重视人机协同的实践，让神州信息在喧嚣的“AI 取代人类”叙事中，提供了一个稀缺而理性的样本。下面这篇对神州信息软件工艺创新部的独家专访，将带你深入一家金融科技企业如何科学地落地 AI，了解它的逻辑、它的指标，以及它对未来开发者能力的冷静预判。
在金融场景里用 AI：不是先上工具，而是先反复验证
InfoQ：能不能先介绍一下您所在的部门，以及您现在主要负责的工作？
吴娟： 我在 25 年初就开始做一些和 AI 落地应用推广相关的工作了。去年 11 月，神州信息专门成立了 AI 创新中心，下面设了两个部门，一个是软件工艺创新部，一个是业务场景创新部，我现在就在软件工艺创新部。
神州信息一方面是一家软件公司，另一方面又长期为银行提供金融软件服务，所以我们在软件工艺上本身就有比较深的积累，包括开发规范、技术栈、技术架构等。去年 AI 开始大规模落地之后，公司也希望把 AI 真正融入现有的软件工艺过程中，切实去推动降本增效。我们这个部门，主要就是在这个方向上做应用落地和智能化改造。
从去年到今年，我们整体的定位一直比较明确，就是基于 AI 来推动软件工艺的智能化升级。前期会先从编码、测试等具体研发环节入手，把 AI 逐步用起来；后续再往整个软件工艺全流程的智能化方向推进。
同时，公司管理层对 AI 的价值一直非常认可。从去年开始，组织层面就在持续推动“AI for process”这件事。无论是内部提效，还是面向外部业务和交付，公司都希望尽可能去尝试、去挖掘 AI 能真正带来的价值。
InfoQ：AI 这三年从补全到 Agent 的演进，对你们带来的最大变化是什么？你们内部有没有做相应的调整？
吴娟： 从时间上看确实是三年的演进，但对我们来说，真正带来质变的时间点，其实是在 2025 年 2 月之后。
我们其实一直在尝试，AI 到底能不能在研发环节里真正帮我们提效。前期比较早做的一件事，就是想用大模型来辅助完善设计文档。因为在实际开发里，代码和文档经常会不一致，团队在“文码一致”这件事上会消耗很多精力。所以我们当时最先切入的一个场景，就是希望借助 AI 的能力，根据代码去同步更新文档，减少这类维护成本。但从实际效果来看，当时生成的文档质量整体是不可用的，这是我们当时一个比较直接的判断。
转折点出现在 2025 年初。一方面是模型能力明显提升，比如 DeepSeek 等模型出来之后，效果有了一个明显跃迁；另一方面，编程助手工具开始快速丰富起来，像 Cursor、通义灵码这一类工具逐渐成熟。我们也在这个阶段开始引入工具做系统性的验证，整体感受是：对 AI 的认知需要重新评估了。
当时我们专门选了一款编程助手工具做深入验证，核心不只是看这类工具能不能生成代码，更重要的是看它能不能适配我们现有的研发模式，尤其能不能用于金融行业这类业务复杂、系统复杂的软件开发场景。验证之后，我们的判断是，它整体上能够达到预期。
我们当时看的其实不只是它能不能帮我们节省时间，而是从几个维度一起评估，包括代码生成质量、任务拆解情况、功能实现情况，还有一个最关键的点，就是它到底能不能适配我们现有的开发模式。
代码生成质量这部分，相对还是比较基础的，主要看准确性、健壮性和可读性。真正要求更高的，其实是任务拆解能力。因为这不只是写代码的问题，而是它能不能理解我们现有的需求和设计文档，能不能把功能描述覆盖全。
还有一点对我们特别重要，就是定位能力。因为我们的系统不是从零开始搭的，而是在现有产品和解决方案上不断做增量开发，所以我们会特别看它能不能在已有工程里找对位置，修改代码时能不能准确找到对应逻辑。同时也会看它生成出来的逻辑是不是合理，是否符合业务逻辑和执行顺序。
功能实现这一块，我们更关注的是完整性。也就是说，它不只是把主流程做出来，还要把异常情况和边界场景一并覆盖到。
在与现有开发模式的匹配度上，我们主要看了几个方面。
第一是开发规范的匹配。也就是说，它能不能符合我们现有的一些基础要求，比如数据标准、数据字典，以及日常开发中的命名规范等。
第二是内部工程的匹配度。我们会重点看它能不能识别我们现有的工程体系，包括已有的架构设计和长期形成的标准体系，并在这个基础上按照既有的架构结构去生成代码。
第三是内部文档的匹配度。因为我们在初期使用时也发现，很多 AI 工具更适合处理 Markdown 这类格式，但我们现有的大量存量文档，无论是项目、产品研发还是交付过程中的文档，很多仍然是以 doc 或者 excel 这类传统格式来管理的。所以我们也会评估，它的引入会不会额外增加文档维护、格式转换等成本。
当然，验证下来也不是没有问题。我们当时觉得，它在一些基础错误上还需要继续改进，比如类型转换这类问题；另外像依赖包解析、现有开发规范的加载，也还不够稳定。再加上上下文长度受限，token 一旦过长，有时就会出现任务中断这类异常情况。这些都是我们当时重点关注、也认为后续需要优化的地方。
基于这一轮验证，我们在 2025 年 5 月之后，开始在内部项目中逐步推广编程助手的使用，优先在一些关键的交付项目中落地。同时我们也会重点考虑金融行业的一些要求，比如数据安全、私有化部署等，确保工具能够真正用在安全的环境中，没有后顾之忧。
InfoQ：也有人认为，AI 现在的提效主要还是集中在写代码这一段，对整个软件工程链路的影响其实还比较有限，您怎么看？
吴娟： 这个说法其实是成立的，但只说对了一半。编码确实是最容易被 AI 改造的环节，但它在整个软件工艺流程里的占比本身就不算太高，所以如果只停在这里，整体提效是有限的。所以我们一开始也是从编码切入，但很快就往测试、需求、设计这些环节去扩展，比如用 AI 生成测试用例、测试脚本，或者在需求和设计阶段用智能体去辅助相关角色。
AI 提效，不是为了裁人，而是为了解决人手不够
InfoQ：在引入 AI 之后，研发提效应该怎么衡量？像 DORA、SPACE 这些体系还适用吗，还是需要新增一些指标？
吴娟： 从我们的实践来看，像 DORA 这类传统指标，在金融行业其实不会因为 AI 的引入而失效，反而依然是最核心的衡量标准。
比如部署频率、变更前置时间、变更失败率、服务恢复时间，这些对银行核心系统来说都是非常关键的健康指标。因为银行系统上线本身就有非常严格的流程，要提前报备、审批、对外公告，而且不能随意停机，所以生产稳定性始终是第一优先级。在这样的前提下，这些指标本身不会因为 AI 出现而改变。
另外，SPACE 这类框架本身就是从人的视角出发的，所以到了 AI 时代，我觉得它反而更有洞察力。像满意度、绩效、沟通协作这些维度都不会变。AI 更多是作为一个新的成员，或者辅助成员，参与到这些维度里面。
在质量指标上，我们依然非常看重，比如代码扫描覆盖度、缺陷密度等，而且在 AI 介入之后，要求甚至会更高。
我们在做验证时，是拿真实项目需求来对比的：一边是项目组按传统方式开发，另一边是用 AI 编程助手生成代码再由人工审核。然后用同一套标准去评估两边的结果。一方面用代码扫描工具去看问题数量和分布，另一方面让测试人员对两个版本做同样的功能验证，统计缺陷密度，比如千行代码的缺陷数量。
从结果来看，在代码扫描覆盖度和缺陷密度这两个维度上，AI 生成的代码和人工开发基本是持平的。也正是基于这一点，我们才认为它在质量上是可接受的，具备推广的前提。所以从这个角度来说，传统的质量指标在 AI 时代依然是必须坚持的。
至于一些效率类指标，比如人均代码行数、人均提交次数，我们其实在 AI 之前就已经淡化了。因为在我们的业务场景里，不同角色的工作性质差异很大，比如架构师可能每天产出的代码不多，但价值很高，而一些基础开发的提交量可能会更大，用这种指标去衡量并不合理。
即便在 AI 介入之后，这类指标可能更容易“做高”，但从软件质量和业务价值的角度来看，它们并不能反映真实的工程效果，尤其是在金融行业，这类指标的参考意义其实是比较有限的。
InfoQ：很多人觉得，AI 带来的提效更多还是停留在个人层面，还没有真正反映到组织绩效上，您怎么看？您这边的情况是怎样的？
吴娟： 这种情况确实存在。AI 在初期更多体现为个人提效，比如原来两天做完的事，现在一天就能做完。但从项目整体来看，人员投入和交付周期未必马上会变，所以这部分效率提升，短期内不一定能直接反映到组织绩效上。
不过从我们的实践看，一些具体环节已经开始出现比较明显的组织级提效。
比如在测试用例编写这个环节，原来可能计划 5 个人一个月来完成，现在借助 AI 生成测试用例，只需要 1 个人做审核即可，而且在异常场景的覆盖上，AI 有时甚至比人工考虑得更全面。在这个环节，我们是可以明确统计出人力节省的。
再比如文档维护，特别是“文码一致性”这类工作。以前在项目交付后期，如果代码和设计文档严重不匹配，往往需要投入大约 15 个左右的人月来做文档补齐和修订。现在通过 AI 根据代码反向生成设计文档，这部分工作可以缩减到 3 到 5 个人月，节省效果也比较直观。
所以从我们的实际情况来看，AI 带来的提效，确实是可以逐步体现在组织层面的，只是它不是一开始就以“整体效率提升”的形式出现，而是先从局部环节突破，再慢慢累积出来。
InfoQ：现在有不少声音在说，AI 提效最终会走向裁员，您怎么看？
吴娟： 从我们公司的情况来看，短期内还不会出现这种情况。
不过，如果企业一开始就把“用 AI 提效”的目标直接等同于裁员，其实反而会影响推广效果。员工的使用意愿会明显下降，甚至会出现抵触。
我们去年就看到过两种比较典型的反应：一种是觉得 AI 生成的代码质量不行，不愿意用；另一种则是觉得 AI 已经能写得很好了，反而担心被替代，也会产生抗拒心理。
所以我们在推广的过程中，一直给大家传导的思想是 AI 不会淘汰人，但是会淘法不会使用 AI 的人，鼓励大家用好 AI。AI 其实是检验人的水平的试金石，是辅助个人放大自身优势和能力的工具。
所以从组织推进的角度来看，AI 的落地不仅是技术问题，也是人的问题。如果一开始就把它和裁员绑定在一起，这件事本身就很难真正推开。
另外一个原因在于，我们面对的是金融这类复杂业务系统，整体工程复杂度比较高，所以 AI 在代码生成这一环节的效果，目前还存在一定边界。
这里面一方面是代码生成之后的可用度问题，另一方面也和具体场景有关。并不是所有场景都适合交给 AI。比如一些复杂的账务处理、事务一致性保障，以及银行 7×24 小时运行机制相关的代码实现，这些都高度依赖长期积累下来的工程经验，只有对业务和系统都非常熟悉的人，才能写出足够稳健的代码。
AI 目前在一些相对简单、标准化程度更高的场景里，效果还是比较明显的，比如查询、交易处理，或者增删改查这类业务逻辑。在金融这类复杂业务系统的开发过程中，它现阶段更适合承担辅助角色，帮助研发人员完成其中一部分工作。
当然，随着模型能力持续演进，再加上我们自己也在做智能体和知识库建设，这种能力还会继续提升。
但至少在当前阶段，我们认为它还不足以替代现有开发人员，尤其还替代不了那些经验比较丰富的开发人员。
从另一个角度来看，如果只保留经验丰富的开发人员，而忽略初级工程师的培养，反而可能带来能力断层。在金融系统开发中，这种断层的代价是很高的。当中间层级出现断档时，知识传递会受影响，进而影响系统稳定性。所以 AI 并不能简单地用来替代某一类人群，尤其不能通过削减初级工程师来换取所谓的效率提升。
从我们服务的客户来看，银行本身就受到严格监管，对合规、安全、稳定性都有很高要求。在新技术应用上，我们也会更关注这些方面。所以现阶段，AI 生成的代码仍然需要结合人工审核和把关，才能更好地应用到金融场景中。从这个角度来看，AI 目前更多还是起到辅助作用，还不足以支撑人员的直接缩减。
尤其是在金融合规这方面，AI 可以生成代码，但像合规判断、数据安全边界的控制，以及在出现问题时的责任承担，这些都必须由人来完成，而且依赖的是长期积累下来的经验。如果把 AI 带来的提效，直接用来压缩这部分人力，我们认为是一个风险很高的误判。
所以从我们的实际情况来看，目前的思路并不是“用 AI 减少人”。一方面，我们本身项目就比较多，经常会出现人员紧张、资源不够用的情况；另一方面，我们更希望把 AI 节省出来的人效，用来承接更多项目、覆盖更多场景，是把事情做得更多，而不是把做事的人变少。
现在看质量，未来看闭环：生产力考核的变化方向
InfoQ：现在很多大模型厂商会强调“AI 生成代码直接进入生产”的比例，你们会把这个作为过程指标去关注吗？
吴娟： 我们内部其实更强调的是人机协同，而不是单纯去看“AI 生成代码占比”这样的指标。
即便引入了 AI，我们仍然有一套比较严格的流程规范。比如 AI 生成的代码，首先需要对应的工程师进行审核；工程师提交之后，开发组长还需要再做一轮代码 review。整个过程里，责任主体始终是开发人员，最终的提交和责任归属也都是以人为主。
所以我们并不会特别去强调“有多少 AI 代码直接进入生产”。从金融客户的角度来看，这类指标本身也不是他们最关心的。和一些互联网公司的开发模式相比，我们的流程会更加严格。所有代码都需要经过完整的开发、审核、测试流程，包括多轮测试和回归验证之后，才会进入不同环境，比如测试环境、行方的 FAT、UAT，最终再到生产环境。而在生产环节，流程会更加严格。所以在整个过程中，一定是有人参与、有多环节把控的，而不是简单地把 AI 生成的代码直接部署到生产环境。
InfoQ：现在有些公司会给开发者单独的 AI 预算，比如每月几千美元，用来调用模型。也有人说“如果不花掉与自己工资相当的 Token，就不算用好 AI”。从公司的角度看，这种投入怎么判断是否合理？
吴娟： 我们的情况和很多互联网公司不太一样。很多互联网公司是基于公有云环境，直接调用像 Claude、Gemini、GPT 或国内的这类模型，所以成本主要体现在 token 消耗上。但在我们这里，天然就有私有化部署的要求。尤其是银行客户，关键系统大多还是要求在私有环境中运行。所以我们整体的投入，不是在 token 上，而是在 GPU 资源上。
目前我们是自采 GPU 资源，在内部部署模型，比如 DeepSeek、智谱 GLM 等。这种模式下，对开发者个人来说，并不存在“token 用多少”的成本问题，主要是公司层面的资源投入。
另外，我们也不会完全局限在现有的私有化模型上。像最新的一些模型能力，比如 Claude 等，我们也会做对比评估，看看在代码生成等场景下的差异，以及它们具体好在哪里。因为我们这个部门本身就是做软件工艺创新的，所以会承担一部分“先行探索”的角色。比如对一些新模型、新工具，我们会在小范围内做试点验证。但这种尝试是可控的，不会直接用真实的全部工程代码去做。
整体来看，这部分外部资源的消耗其实是比较小的，公司也可以支持。对我们来说，更核心的投入，还是在 GPU 资源这一块。
InfoQ：那在使用层面，你们会不会去评估个人的 ROI，比如有的人资源用得多，但产出相对少？
吴娟： 我们目前更多还是正向鼓励大家去使用，而不是去做这种“用得多、产出少”的评价。因为不同角色之间其实是很难直接用同一套标准去衡量的。比如像架构师，在做一份架构设计方案时，可能会基于 AI 做多轮调研、反复推敲，过程中调用次数会比较多，但最终产出可能就是一份设计文档，或者几个架构原型。而开发人员在做一些相对标准化的功能开发时，调用次数可能也很多，但对应的代码产出也会比较多。这两类工作本身就不具备直接对比的基础。
所以我们不会简单用调用次数、资源消耗，或者产出多少，去判断一个人的使用效果，更不会据此做评价。在当前阶段，我们更看重的是把 AI 用起来、用好。只要它能够在实际工作中发挥作用，对我们来说就是有价值的。
InfoQ：从个人评价的角度来看，现在有些开发者会大量使用 agent，甚至通过并行方式来完成工作；而有些人仍然停留在辅助型用法。不同使用方式带来的生产力差异非常明显。如果从个人考评的维度来看，这种差异你们会纳入考量吗？
吴娟： 不同用法带来的效率差异确实很明显。像辅助式用法，更多是持续交互；而 agent，尤其是多 agent，在一些批量处理场景里效率会更高。
比如代码扫描问题分析、单元测试生成、设计文档补充这类工作，更适合批量执行，可以让 AI 先跑完，再由人集中审核。但像架构设计、功能开发这类工作，往往还是需要持续交互，去确认代码匹配度、功能完整性和业务逻辑是否正确。
所以我们更看重的是场景是否合适，而不是简单判断哪种方式更好。现阶段，我们也不会因为一个人用了 agent 或多 agent，就直接把这类差异纳入个人考评。
InfoQ： 最后一个问题，现在 Agent 整体还处在比较早期的阶段，但从今年开始，它展现出来的能力已经有了很大的变化。如果再往未来看 3 到 5 年，变化可能会更大。您觉得到了那个时候，开发者生产力考核里最需要调整的，会是什么？
吴娟： 我觉得变化一定会非常大。现在开发者使用 AI 工具，已经不只是最早那种问一句答一句的辅助方式了，而是在往“直接把任务做完”这个方向走。以前很多事情还需要反复交互，但随着多智能体协作越来越成熟，现在有些任务其实已经能由智能体自己闭环完成了。比如生成一份完整的 PPT，并直接放到指定路径下，这种能力已经开始应用了。
第一点，是考核从“代码产出”转向“任务闭环”。从编码这个角度来看，像提交次数、bug 修复数量这些指标，肯定不会再是首要关注的了。未来更重要的是看任务有没有形成闭环：开发者和编程助手（智能体）是怎么协同，把一个任务完整地做完，比如能不能把任务拆解清楚，让智能体自主完成模块开发，包括完成单测、功能验证，甚至自动部署到测试环境，走完内部“送测”的流程。
第二点，是从“个人产出”转向“可复用能力和知识沉淀”。不再只关注代码写得好不好，而是要看这个人的表达能力和逻辑完整性。换句话说，他是否能够“教会 AI 做事”，是否能够构建可复用的 Agent。这里有两个关键点：一是 Agent 本身可以复用，二是过程中沉淀的知识库、知识模板（例如提示词、规则、模板）可以积累下来。
因为我们在推广 AI 编码的过程中也发现，对于一些能力表现相对更好的人员来说，他们真正拉开差距的一个点，就在于能不能把自己使用 AI 的经验沉淀下来。比如在编码过程中，他们会把提示词，或者我们内部说的 rule 规则，也可以说是 skills，沉淀得非常好。这种沉淀一方面会直接提升他自己当前的代码生成质量，另一方面，这些积累下来的内容也可以拿到项目组里给其他人使用，甚至可以跨项目组复用。因为很多问题本身就是共性的。
所以在这种情况下，后面可能就要更多去看，一个人在知识沉淀上的贡献，或者说在智能体训练上的贡献。换句话说，就是他能不能成为一个“教会智能体做事”的人。通过这些能力，其实是为了提升 Agent 的复用能力，从代码层面来看，就是提升代码的可用度，以及在不同项目之间的复用占比。
第三点，是“可审计、可追溯”成为基础能力。不只是看事情有没有做完，还要看整个过程是不是可追溯的。因为金融软件对安全性和稳定性的要求非常高，银行系统的稳定性通常要做到多个“9”的级别，比如核心系统要 99.999%。一旦某个环节出现问题，我们必须能够追根溯源，找到问题是在哪个环节产生的，而不是只解决表面这一个问题，而是能够定位并解决这一类问题。
尽管很多工作可以交给智能体，但人依然需要具备能力去理解它做了什么。要能够跟踪 Agent 的行为轨迹，知道每一步的推理和调用关系。同时，开发者最终还是要对结果负责，这样在出现问题之后，才能保证整个过程是可追溯、可回放的。
第四点，是从“单一能力”转向“跨域能力”。过去我们的角色划分比较严格，需求、设计、开发、测试，各个环节的边界都比较清楚。后面用了 AI 之后，因为 AI 在各个环节里都可能做得比较好，这其实会改变我们对开发者的考核方式。
以前有些开发人员开发能力很强，但业务理解能力不够，或者需求沟通能力不够，未来这类单一能力可能就不够了。后面可能会更看重广度，而不只是深度，或者说，更看重这种跨域连接的能力。也就是他能不能把业务、数据和 AI 能力打通，成为中间的连接者；能不能让智能体理解公司整个开发流程，并在这个基础上去完成任务、优化过程；同时还要具备需求验证的能力，以及从整体上闭环去看任务验收的能力。
因为以前开发人员有一个比较明显的特点，就是把代码写出来、跑通、不报错，一个简单功能实现了，好像就完成了。他未必真正关注这个功能到底实现了什么、原始需求是什么，所以版本一旦交给测试人员，往往还会暴露出很多问题。但现在如果用了 AI，它不仅能帮你写代码，还能进一步生成各种业务场景下的测试用例，那开发人员就需要有能力去判断，这些业务场景是不是都覆盖到了。
所以对开发人员来说，未来需要具备的，是一种从前到后、能够把整个任务看完整的能力。
延伸阅读：
本文来源：InfoQ