夜雨聆风公司总有一些比较老的系统，可能团队的主要精力已经在开发其他产品了，但这些老系统还有客户使用，所以也需要继续维护。虽然说是维护，但原先开发这个系统的成员经过时间的洗礼，早就换了好几拨了，最后接手的同事在上一任严重失真的交接后，可能很长时间都没有动过里面的一行代码，突然有个小需求需要迭代，还是有点措手不及的。
没人愿意维护老系统的原因也很明显，系统老只是时间长而已，但代码量可不小，可能本地连测试环境都没有了，要跑起来都有点困难，还要从海量的代码里找出要迭代的地方。即使找到了功能所在的地方，也不敢确定是否只有这么一个地方，还是在其他地方也有相互关联的功能也需要一起进行变更。对于找到的代码，由于已经不懂里面的业务，代码虽然每行都认识，但就是不懂实现了什么业务，也不理解为什么当初这么写。贸然改动，也不确定是否会对别的地方造成影响，也不知道哪些地方需要进行相关联的测试，总不能迭代一个小功能，就把整个系统都测试一遍吧，而且测试也一样没人懂的。
这些都是维护老系统的难处，问题都指向不了解业务，而且是一个系统的业务，要解决这个问题就需要慢慢地把代码再逐步熟悉起来，对着客户运行的业务和代码，一点点地再把业务补充回来，这个时间是漫长的。这是以前的做法，到了现在 AI 工具兴起的时代，突然发现 AI 工具恰好是解决这个问题的一个大杀器。几万行的代码对人来说就很多了，要看完就不知道要猴年马月，但这点代码对于 AI 工具来说，可能十分钟都不需要就能够遍历一遍了。要多处代码互相印证才能够把业务恢复回来，但要从大量代码里面找到这些相关的代码就很困难，这对于 AI 工具来说则是非常的简单，可能也就几分钟就能够找全了。至于改动的影响，再花几分钟 AI 工具也能够分析清楚是否影响了其他地方。只需要把需求给 AI 工具讲清楚，很快就能够找到合适的地方，把这个需求实现出来。还可以让 AI 工具整体检查一遍，确认是否有问题，甚至把测试用例补充回来，这些都是多花点 token 的事情，处理起来突然容易了很多。
像这种谁也不了解情况的场景，而且是非常耗时耗力的场景，使用 AI 工具反而提升效率特别明显。这个时候，好像人连审核的资格都没有，因为本来对系统就一无所知，如何审核 AI 工具完成的对不对、好不好呢？只能从功能上去验收结果是否是预期的即可。从这个角度来讲，随着 AI 工具的编码能力进一步变强，很可能就会走到不需要人去审查代码的正确性了，毕竟以人的速度完全是跟不上的，AI 工具很轻易地产生按万为单位的代码，人工审核可能要好几个月都审核不过来，那还审核什么呢，只能退化到验收功能了，其他的都只能交给 AI 工具了。
