前几天看到一篇帖子，标题是《甲方开始用AI自研了，卖软件的乙方该怎么办？》。

他给出的答案意外简单，就是“有甲方思维的乙方才能走下去”。

暂且不评价这个解决之道。

先让我们看清一件事情：

软件开发最耗时间的环节，是把业务需求说清楚，逻辑整清楚。

不信你让一个有经验的开发回忆一下，他会告诉你：70%的时间在沟通需求，30%才是实现。

现在AI能写代码了，这30%被压缩了。但前面的70%，反而被放大了。

不得不面对的更多问题是：谁来把需求变成“正确的提示词”？谁来判断生成的逻辑有没有坑？谁来兜底上线后的运维和业务变化？

也正因为这样，AI并没有让软件开发变简单，反而让“理解业务的人”更稀缺。

很多乙方公司这两年都在做一件事上大模型、做AI产品、贴AI标签。

看起来很积极，但问题在于他们的出发点，还是“怎么把产品卖出去”。

于是就出现了一个奇怪的现象：云厂商在卖API，乙方在卖“AI能力”，甲方却在问一句话：能帮我解决业务问题吗？

更现实的一点是：当技术门槛下降，甲方会天然想把控制权拿回来。

这也是为什么“甲方开始自研”这个趋势，越来越明显。

但这件事，也有一个很大的误判。

短期内，大规模“AI自研软件”并不会发生。

原因很简单：代码可以生成，系统不能自动长出来。

一个ERP、MES、供应链系统，背后是几十甚至上百个业务环节的组合。这些东西是经验沉淀出来的，而非表面的代码堆砌。

更现实一点：AI生成的代码要不要审核？出了问题谁负责？系统上线后怎么维护？

这些成本，甲方不一定愿意长期承担。

所以你会看到一个很微妙的趋势。甲方在尝试自己做，但一旦复杂度上来，又会重新找“能理解业务的人”。

问题从来没变，只是门槛换了位置。

很多人还在讨论“AI会不会替代乙方”，但在制造业，有一类工具，绕开了传统开发模式。

系出金山的云表平台做了一件很直接的事：把开发软件系统这件事，拆成了业务人员也能参与的过程。

画表格、无代码、写中文业务逻辑、逐步迭代。

听起来很简单，但它改变了分工方式。

乙方不再是单纯“交付软件”，而是变成“帮甲方把系统搭起来的人”。

这背后其实是一种更现实的合作模式。比如恒逸石化，用过SAP，知道系统长什么样，用云表平台8个月做了30套系统，还打通了原有架构。

再比如中铁十六局，一个人带头，几个人的小组，把物贸业财税一体化系统搭了起来，很多人甚至没有编程背景。

所谓“甲方思维”，其实就是你站在谁的角度思考问题。

过去乙方更关注软件功能怎么做、架构怎么设计、成本怎么控制。

现在这些还重要，但优先级在下降。

真正决定价值的，是这个系统到底解决了什么问题，在业务里有没有用，能不能随着变化持续调整。

当工具越来越通用，经验、理解、判断，就变成了稀缺品。

这也是为什么，一些乙方开始转型——从卖产品，转向卖结果；从交付系统，转向陪着一起做系统。

AI不会让乙方消失。但会让“只会做产品的乙方”，变得越来越难。

未来留下来的，大概率是两类人：一类，极致技术能力，能解决复杂问题；另一类，深度理解业务，能把问题讲清楚。

中间那一层，会被挤压得最明显。

而甲方，也不会完全接管开发。他们更可能做的一件事，是把能力往内部拉一部分，再把复杂的部分交给更懂业务的外部力量。

最后，你有什么修正或者补充的地方？

文 | eamon