从刚开始的 copilot 到现在的 claude code，尝试用了这些 AI 辅助开发工具。
博主写代码并不是奔着挣大钱去的，更多是好玩，能被许多人使用，能让自己安心而已。
而刚好写代码能养活自己，如果不是，也还是会另找工作然后业余时间继续写我认为还算有用的代码。
讨厌 AI 到不是代码，更多是感到了全方位的冲击，简单来说，人的价值被稀释了。
不过今天不讨论这个话题，来说说 LLM 在替代人写代码的一些问题。
经常写代码的都明白，维护代码库的一个核心点就是分层设计。
将复杂度一层层隐藏并对上层提供干净的接口。
随着代码量的逐渐递增，大多数时候维护的是从下到上多层嵌套的接口。
这只是应用侧的，还有编译器，标准库，内核侧，硬件侧的架构分层及复杂度隐藏。
在单独的某一层，可以完全不管下层的实现，只关心当前这层的逻辑，比如在挺多上层的托管语言下已经默认拿不到系统的接口了，只需要在当前环境下的接口上去搭建就行了。
在某些情况下，可能需要到下层去重新构建，比如为了达到性能极限而去面向硬件编程。
其实和上下文限制很像，人面对复杂系统是需要通过拆分把"上下文"压缩，对应到具体的情况，就是把实现细节隐藏到清晰的接口里，来降低复杂度，也就是压缩"上下文"。
我们先定一个前提，AI 无法一次生成现在的 Linux 系统及其编译链工具链。
先不提准确度，这里想说明，它的上下文是有限的。
再定一个前提，AI 不具备自主性。
即它不会自己提出问题去自我迭代。
人类的思考不总是被需要的，
思考的过程可以被忽略，LLM 其实只需要结果。
对于代码架构设计，在大量迭代后，人们会收敛到一个接近完美的最佳设计，而这个设计可以被嵌入 LLM 里。
对于迭代代码，人们能总结出一些常见的思路链条，而这些链条可以被嵌入 LLM。
对于需求的拆解，人们能结合以往的经验给出一个大概的结果，而这些经验能以文本的形式嵌入 LLM。
最后加上大量的开源代码，铸就了现在 AI 能生成部分"高质量"代码的基础。
回到替代人的话题上，我们提出需求，而 AI 去执行。
对应到开发上，则是去让 AI 生成代码来满足需求。
通过非常有限的语言描述，去生成几倍几十倍甚至上千倍的代码量，这是不对等的。
也就是说当你的需求越细，AI 能发挥的空间更少，需要收敛得更精确。
但要达到这种精确度时，你得站到一个当前层次的顶部去俯视，去提出大致实现你需求的路径和设计。
当然如果不要代码的精确度，只关心 AI 生成的代码运行之后能有预期的效果，但其实这里的效果现在看来，并不是 AI 生成保证的，而是下层的架子足够的好，能让现有的 AI 通过有限的上下文和提示词，去生成还能用的代码。
尝试一段时间的 AI 代码生成，很容易发现，生成的代码依赖现有的基础设施，由人来维护的代码基础设施。
直接不依靠现有设施，去生成看来常见的应用功能，背后的代码量是非常恐怖的，同时代码内部是有关联的，如果分层分得不太好，一点小的修改就可能导致严重且难以调试的问题。这对应我们的第一个前提，也就是 AI 还无法直接生成从底层到上层的一整套代码。
而当我们想要让 AI 去直接面对一个无额外代码依赖的大型代码库时，这就会把复杂度重新抛到提需求的人那里，迫使使用 AI 的人去处理分层设计和部分实现细节。这里还只考虑代码层面的依赖，还没有涉及到编译器和操作系统。
当然就长期来看，分层和复杂度问题随着上下文的扩大和更多的经验被嵌入 LLM 而有所缓解。但是就第二个假设来说，即 AI 不具备自主性，无法自我迭代。
那么还是需要人去处理复杂度的问题。
可能在未来，经验的积累达到某个奇点，或者其他因素的引入，LLM 突然就具有自主性了，能自我迭代了。
那人还有价值吗，就大脑来说。
往后延伸的一点点，
AI 注定会导致写代码的价值被稀释，我个人来说，还是会对维护开源组件的人一些尊重和宽容。如果你正在用在 AI 生成的代码去赚钱，还请不要谴责和贬低开源组件及其维护人，如果有问题可以正常提 issue 和 pr。