以后“会写代码”还重要吗？

最近做AI项目的时候，我一直在想一个问题：

以后“会写代码”这件事，到底还重要吗。

一开始我觉得这个问题挺简单的，但真正做进去之后，发现它其实没有那么直接。

以前对“会写代码”的理解很单一，就是能写代码就能做东西。写一个工具、做一个功能、搭一个流程，本质都是一步一步把逻辑写出来。那时候能力的边界很清晰，会就是会，不会就是不会。

但现在做AI相关项目之后，这个边界开始变得模糊。

很多事情已经不再是“从零写代码”了。比如一些数据处理流程，以前可能要写一整套脚本，现在可以直接用AI生成初稿，然后稍微调整一下就能跑起来。再比如一些简单的接口调用、数据整理、甚至小工具，现在很多时候是把几个现成能力拼在一起，而不是从头实现。

甚至有些不太会写代码的人，只是会一点逻辑或者会用工具，也能做出一些能用的小东西，比如简单的自动回复流程、内容整理工具、或者一些轻量级的自动化脚本。它们不复杂，但确实已经“可以用”。

但有意思的是，会写代码的人并没有因此变轻松，反而会开始面对一些新的问题。

比如一个功能以前只要实现，现在要考虑的是结构是不是长期可维护。一个接口以前只要能跑，现在要考虑异常情况、边界输入、不同场景的兼容性。一个流程以前只要完成任务，现在要考虑后面是否能扩展，是否会因为一点变化就全部重构。

很多时候会出现一种反差：功能本身好像更容易做出来了，但要“做对”和“做稳”反而更难。

以前做系统的时候，判断标准很简单，能跑就行，结果出来就算完成。但现在慢慢变成，即使能跑，也不一定算真的完成。因为可能只是“刚好跑通”，换个输入或者换个场景就不稳定了。

也因为这样，我开始看到一个比较明显的分化。

一边是不会写代码的人，他们更容易快速拼出一个可用的东西，关注的是“有没有结果”。另一边是会写代码的人，更多时间是在处理结构、稳定性和长期维护的问题，关注的是“这个东西能不能一直用”。

一个更偏向做出来，一个更偏向维持住。

这时候再回头看“会写代码”这件事，就会变得有点尴尬。

如果说它不重要，好像不对，因为很多底层逻辑、结构设计、问题拆解还是离不开它。但如果说它依然是核心能力，又会感觉它正在被拆解成更基础的一部分。

甚至有时候会有一种感觉，它不再决定“能不能做出东西”，而更像是在决定“能不能把东西做得长期稳定”。

但问题也来了。

如果以后做东西这件事本身变得越来越容易，那真正的差异到底在哪里。

是思路的差异，还是对问题拆解的能力，还是对系统整体的理解方式？

还是说，会写代码这件事只是换了一种存在方式，从“门槛”变成了“底层能力”？

这个问题我现在也没有答案。

只是最近越来越频繁地会想到这一点。

你们有没有这种感觉：现在AI出来之后，做东西确实比以前容易了，但“会写代码”这件事，好像已经不再是决定结果的关键因素了。还是说，这只是某种阶段性的错觉。