AI对软件公司是“赋能”,还是“降维打击”?

1997年，卡西尼号探测器发射升空，飞向土星。20年后，2017年9月15日，它受控坠入土星大气层，化作一颗流星。

这个故事一直让我难以平静。

卡西尼号最后的任务是"自杀式"的——它要一边坠落，一边把天线对准地球，把最后的数据传回来，直到信号彻底消失。而执行这个"坠毁指令"的代码，是1997年一个程序员写的。

那个程序员当时在想什么？他知不知道，自己敲下的那几行逻辑，会在20年后、在距离地球14亿公里之外，以这样悲壮的方式被执行？

这让我重新理解了"代码"这件事的重量。

而我这十年，恰好见证了这种"重量"的转移——从"人"的身上，慢慢转移到了别的地方。

01

十年前我刚入行的时候，写代码跟今天是天差地别。

我们给银行做系统。一个项目启动前得先和客户聊需求，很多情况下客户自己也说不清"他到底要什么"或者就是简单写的模糊的一句：有XX等功能。这个“等”就有很多理解了，需求不清晰后期双方也容易互相扯皮。

需求明确后就是写技术方案、画架构图、做概要设计、详细设计，层层评审。

开发阶段，前端后端数据库各司其职。

一个简单的CRUD功能，从建表到接口到页面，一个人吭哧吭哧写两天。遇到复杂的业务逻辑，比如对公客户的风险评级，几百个规则嵌套，一个函数能写到五百行。不敢拆分，因为一拆后面的同事看不懂。

测试阶段，提测之后测试同事提几十个Bug回来，改完了再测，测完了再改。交付阶段更折腾——客户的生产环境永远是另一个世界，操作系统版本不一样、数据库字符集不一样、中间件参数没调对，本地跑得好好的，一部署就报错。运维同事半夜打电话把我叫起来："生产挂了，快看看。"

一个项目从启动到上线，三个月算快的，半年是正常的。

如果是项目制的，软件公司也很有可能会亏钱，需求控制不好，开发无穷无尽。

所以大部分的软件公司更喜欢“卖人头”的模式。客户买程序员的时间，出几个人、干几个月、花多少钱。

对银行来说，这个模式虽然慢、虽然贵，但至少"可控"：人头预算可控，出了问题找得到人，不需要人了随时可以退回外包公司。

但今天，这个模式也正在被AI一点点拆掉。

AI带来的变化

两年前，我开始看到身边的同事用AI辅助写代码。一开始我不信。模型能写出什么像样的代码？

直到经历在某头部城商行的项目，让我觉得自己也必须尽快把AI用起来。

我的同事正在写一个解析复杂JSON结构的工具类，放在以前，这活儿至少半天。他把需求扔给AI，二十秒，代码出来了。跑了一下，一次过。

我站在旁边，看的一愣一愣的。

那种感觉就像你练了十年的手艺，突然发现隔壁桌的同事用一台机器就干了你一天的活儿。也许不是被超越，是规则变了。

我和公司的产品经理聊了，他也在用AI写需求、PRD、生成用户故事、整理会议纪要、甚至直接把需求文档转成验收标准。以前花在"写文档"上的时间，现在全挪到了"想清楚要什么"上。

上个月我们接了一个基金公司的需求：合规风控仪表盘，数据来自五个业务系统，实时汇总展示。在以前至少要三个人干一个月。这次怎么做的？一个开发用AI写脚本骨架、写接口代码、写图表组件，开发来改业务映射、调参数、调样式交互。

10天，上线了。

客户很满意，问我们"这次怎么这么快？"

客户不关心你怎么写的，只关心三件事：上线越快越好，运行不要出错、价格越便宜越好。

效率提高了，是件好事。

但你算过这笔账没有，一个人加AI能干原来三个人的活，那另外两个人去哪里？当"写代码"的门槛从"科班出身、三年经验"降到"会描述需求就行"，软件公司赖以生存的"人力壁垒"还有什么意义？

传统软件公司的模式是：按人天报价，赚人力差价。现在AI来了，你报50个人天的项目，AI可能10个人天就干完了。客户不傻，凭什么还按50个人天付钱？

银行采购人力外包，核心逻辑一直是"以人定费"——初级、中级、高级分别什么单价，乘以人天，就是合同金额。当AI把人效提升到3倍甚至更多，这个计价模型的根基就松动了。银行科技部的同事迟早会问出那个问题：你们都用AI写了，人力价格不也要下来的？

最难的不是大中型的软件公司，而是小公司。大公司有余力投入AI研发，产品经理和开发都在学习和使用AI工具，我们公司也是举全力往AI方向倾斜资源。我是使用者，也是受益者。但小公司呢？他们没有这个余力。开发还是传统模式，人力成本一分没降，竞争对手的报价却越来越低。想研究AI？研发费用太高，承受不住。想转型？客户不会等你。想去跟大公司竞争？价格拼不过、效率拼不过、产品也拼不过。

所以AI不是在淘汰"写代码的人"，是在淘汰"来不及用AI的人"和"用不起AI的公司"。

还有个更深层的问题。银行、证券、保险这些TOB客户，最看重的是合规、安全、稳定。AI生成的代码，你敢不敢直接给银行用，AI写得文档传到这些云和服务器上泄露怎么办？出了问题谁负责？

AI吗？不，还是你。

所以你会发现一个尴尬的局面：AI让生成代码变得很容易，但让"对代码负责"这件事变得比以前更复杂了。

我也在思考这个问题：在行业的十年，我积累的到底是什么？如果"写代码"这件事正在贬值，还有什么是AI拿不走的？

我想了三样东西。

第一，行业认知。AI能写代码，但需求谁来定义？你面对的是一个基金公司的风控总监，他说的"风险敞口"是什么意思？他说"实时监控"到底容忍几秒延迟？他说"高可用"是99.9%还是99.99%？这些AI不知道、问不出来、判断不了。

你在金融行业积累的十年，知道银行的监管报送些什么、知道证券的集中交易系统为什么这么设计、知道保险的核心系统什么时候该上分布式。这些不是代码，是经验，是踩坑踩出来的体感。

第二，需求翻译能力。业务方说"我要一个报表"，你听懂的是"他需要实时掌握五个维度的风险敞口，并且能下钻到每笔交易"。业务方说"系统太慢了"，你听懂的是"并发上来了，缓存策略和数据库索引都需要重构"。这种从"表面需求"到"真实问题"的翻译能力，是十年跟客户吵架、熬夜、背锅换来的。AI听不懂弦外之音。

第三，信任关系。银行的核心系统、风控系统、报送系统，每一个都关乎资金安全、监管合规、业务连续。客户信任你，是因为你陪他熬过夜、扛过上线、救过生产。AI能写完美的代码，但AI不能在凌晨两点接起电话说"别急，我现在过来"。

信任是这个世界上延迟最高、但带宽最大的连接——一旦建立，很难被替代。

简单说就是：AI负责"怎么写"，你负责"写什么"和"为什么写"。前者是技能执行，后者是经验判断。

如果你也在这个行业，三条建议供参考。

第一，从"等需求"变成"挖需求"。别再等着需求文档砸过来。主动去问业务方：你到底要解决什么？最痛的是什么？试过什么？为什么不行？问出那个"真问题"，比写十万行代码更值钱。金融行业尤其如此。监管政策一变，银行的需求一夜之间全变了。谁能第一时间读懂政策、理解业务、定义需求，谁就抢占了先机。

第二，让AI当实习生，你当把关的人。实习生能干的统统交给AI。你要干的是实习生干不了的：做决策、担责任、权衡利弊。在银行项目里，你还要担合规责任、担数据安全责任、担业务连续责任。代码写错了可以改，但交易数据错了、风控规则漏了、报送超时了，这些责任AI担不起。

第三，别只盯着屏幕，多盯着人。我们这行有个毛病：总觉得"代码即正义"。但十年了，我慢慢明白一个道理——软件是给人用的，生意是和人做的，价值是在人和人之间流动的。金融系统尤其如此。你写的每一行代码，背后可能是几百万笔交易、几万个客户账户、几十亿的资金流动。在项目上做好自己做的事，在此之外和甲方处好关系非常重要。