# AI编程有感

从22年至今，AI走进我们普通程序员的工作已经有4年了，现如今已经彻底改变了我们的工作方式。从工作效率，到代码规范，甚至是架构设计，都翻了个地朝天。一些我们以前认为是很蠢的方法，现在突然变得特别适用。 最简单的一个例子，多语言本地化，以前我们都会找各种插件，甚至是调用a

从22年至今，AI走进我们普通程序员的工作已经有4年了，现如今已经彻底改变了我们的工作方式。从工作效率，到代码规范，甚至是架构设计，都翻了个地朝天。一些我们以前认为是很蠢的方法，现在突然变得特别适用。

最简单的一个例子，多语言本地化，以前我们都会找各种插件，甚至是调用api自动翻译等。现在直接ai生成翻译文本，直接一种语言一个文本，就这么简单粗暴，任何插件都不需要。放以前人工去维护翻译文本几乎是不可能的，现在有ai这都不叫事。

游戏战斗系统的实现，以前我们都会嫌弃用脚本的方式来，每一个技能写一个脚本好难维护，费时费力不说，还容易出bug。我当时使用行为树这种方案(类似蓝图)来实现战斗内的一切逻辑，技能，子弹，buff这些，还专门写了一个行为树编辑器。实践下来，效果还是比较理想的。现在复盘一下，让我再重新写战斗系统，我绝不会再考虑用行为树或蓝图，直接让ai撸脚本。

我在做的是SLG游戏，最近策划给我们提了一近乎变态的需求：我们已经有了一个slg大地图功能(业务代码非常复杂)，策划提出的需求是，再做一个小型的slg地图玩法，需要复用slg大地图的行军，交战等基础逻辑，但是玩法上又有很大的不同。在架构设计上，我面临这几种选择：
1.在直接复用现有这套代码，业务层做兼容处理。
2.对现有的代码做抽象，把公共的逻辑抽象出来，给新玩法用。
3.把现有的代码复制粘贴一份出来，在这个基础上改。
如果放在以前，论优雅，那就是2大于1远远大于3。3就是架构设计的大忌，复制粘贴代码就是屎山中的屎山，策划以后每出一种新玩法就复制一份代码，根本无法维护。但现在我会毫不犹豫的选择3，我只需要维护其中主要的玩法那一份代码，其它的衍生玩法的代码全部让ai照着主代码依葫芦画瓢改就行。

总结就是，很多以前我自我感觉很牛逼的奇技淫巧，在ai面前都变得班门弄斧，不值一提。