关于上下文的定义

最近工作中写了不少bug（毕竟我的工作就是写bug），然后就发现了一个问题，就是很多时候写的bug是因为同一个问题——上下文不足。

所谓的上下文不足就是说有时候写代码的时候会有一系列的地方需要改动，就会涉及到很多文件，然后这些文件改的过程中需要频繁的在多个文件中切换找到自己需要改的地方，在这个频繁切换上下文的时候就容易漏掉东西，导致出现bug，或者需要改很多地方，但是没有改掉，其实在这方面来说AI和人的思维也是一样的，所以AI刚出来那会儿我感觉AI编程是不太能实现的，因为有上下文，AI是做不到读取一个项目的上下文的，然后AI就开始不断的增加可以使用的上下文，现在比较多了好像都好几兆的上下文了，这么高的上下文确实可以满足一些代码逻辑的上下文的需要了，所以现在AI是可以搞一些编程任务的，甚至很多时候搞的还挺严谨。

但是，我又要但是了，AI的上下文再大也是基于现有的代码的训练去做的，AI只是看起来理解了你的上下文，其实还是基于逻辑的判断去做的，所以AI很多时候会非常暴力的去解决问题，而不是从架构设计的角度去解决，比较小的、短期的项目可以用AI非常方便的解决，如果一个项目需要长期维护，并且业务逻辑比较复杂，那就需要从架构设计上做一些限制，当然，这并不是说这样的项目就不能用AI，而是需要谨慎的使用，小部分小部分的去做，因为一次实现的东西太多依然会导致上下文不足，然后AI输出一些似是而非的内容。拥抱AI是必须的，但是过于依赖AI也是灾难性的，因为过于依赖AI扼杀了自己的创造性和成长性，从小我们就在说任何东西都具有双面性，科技进步当然也一样，这不是固步自封，而是更好的利用，让科学技术的进步为自己服务，让AI能快速的写出代码，但是也要提升自己的能力，AI来临之后需要提升的不是某个功能是否能做出来的问题，对于API的记忆的问题，在这些方面AI肯定是吊打人类，那么人类的优势在哪里呢，那就是对项目的整体设计方面，对项目的整体把控方面，让AI在整体的架构内做合适的东西。

因为我在用AI的过程中发现如果不限制AI，他会倾向于重复早轮子，AI不会用项目里已有的工具函数和组件去做，因为使用的人没有告诉AI有这些工具和组件，所以AI选择了最省力的方式，而不是去项目里找，对于人来说调用一个组件和函数是更省力的选择，但是对于AI来说这样意味着上下文的增加，而上下文的增加意味着算力的指数上升，那还不如自己写一个类似的实现。突然感觉在这方面人和AI的逻辑是比较像的，因为人的大脑是最耗费能量的器官，所以很多时候也是会更倾向于省力的思维模型，这样可以节省脑子消耗的能量。但是这样“节省”的模式可能会产生bug，对于人来说可能就是一个错误的决策，对于代码来说可能是一个bug，但是也可能是项目的熵增，而一个项目想要长久发展就要考虑熵增的速度，要想办法减慢熵增的速度，所以我现在看到代码量的减少会比较高兴，因为从感性来讲代码的减少意味着简化（大部分情况下是这样，少数为了代码少而写的极度难懂的代码除外）。Less is more. 不外如是。

说完AI说一下人吧，具体来讲就是我自己，我感觉我很多时候写的bug其实并不是说我不知道这是个bug，而是在代码比较多的时候在太多的上下文中漏掉了一些地方导致了bug，只要有人提出来我有时候可以在不需要看代码就知道那里出了问题，然后很快的改好，但是在我自己看的时候却无法发现问题。结合上面说的就是我的大脑为了节省能量做了“偷懒”的选择，导致我无法完整的想好上下文，把一些需要关注的地方漏了，进而导致了bug。现在想来这个问题可能在我很小的时候就有了，但是我好像一直无法解决，从小的时候做作业和考试就容易老师告诉我错了，我立马就知道正确答案了，但是我自己写的时候却总是在那个错误的方向上狂奔。

那么怎么解决呢，我一时半会也没有特别好的办法，现在需要尝试的就是让自己的上下文变少，一次只处理一个问题或者方面，对其他的问题先“视而不见”，这样可能会降低效率，但是应该可以减少错误。为什么我做这样的选择呢，因为我最近写代码的时候就容易改到这个文件之后忍不住想重构一下，因为写的让我看起来有点难受，但是这样就会导致一次处理多个问题：1. 我自己本身要解决的文； 2. 重构的问题； 这样甚至导致我提交的代码的时候不知道改怎么写我的commit message，所以我会先把代码回退一部分，先提交重构的代码，然后提交我需要做的，这样看起来代码提交是正确的，但是思考问题的方式还是错的，涉及到多个问题了，那么上下文就会增加，出错的概率也会增加。

最后写一个轶事吧，我刚工作两三年那会儿，写代码bug非常多，但是如果是我自己写的，改的也非常快，尤其是当时有个项目比较紧急，我写的时候比较着急，bug就更多了，然后一个需求可能好几十个bug，但是我一天有时候能改10几个甚至20几个bug，当时有个测试就说我，改bug速度很少见。

——2025.12.26