AI时代，程序员依然下不了岗

我最开始接触AI Coding的时候就在想：既然代码都可以自动生成了，那程序员是不是迟早会被替代？当我在尝试 GitHub Copilot 和 Cursor的时候这种感觉越来越强烈，因为AI可以在很短时间内帮我生成大量代码，甚至看起来已经接近“可交付”的状态。我让AI从0写一个后台管理系统，从登录、权限到数据管理全部交给它来完成，结果也很“符合预期”：功能能跑，页面也有，但只要我稍微深入去改，就会发现问题密集出现——权限模型是平的、缺乏边界控制，数据结构无法扩展，异常处理几乎不存在，一旦需求变动就要整体推翻。也是在那个阶段，我第一次明确意识到，AI可以极大提高“写代码的速度”，但它并没有能力替我承担一个项目的“工程质量”。

后来我开始刻意调整自己的使用方式，不再让AI直接承担“从0到1”的开发，而是把它拆进我原本的开发流程里。我现在的习惯是，我先自己把业务结构和关键约束想清楚，然后再让AI参与进来做补全和实现，比如我会先定义接口、约束输入输出，再让AI生成代码；或者我先把需求拆成几个模块，再让AI帮我补充边界情况和异常流程；甚至在调试的时候，我也会把报错和上下文直接丢给AI，让它给我一组可能原因，再由我逐个验证。这一轮实践下来，我最大的感受不是“我写代码变少了”，而是“代码不再是我一行一行生产出来的”，而是变成了一个不断生成、筛选、修改的过程，而我自己更像是在控制这个过程的人。

也正是在这个过程中，我开始意识到一个更关键的问题：AI改变的并不是“谁来写代码”，而是“代码是怎么被生产出来的”。以前开发是一个很线性的过程，人负责从需求一路推进到实现，而现在更像是一个循环系统——生成、判断、调整反复进行。在这个循环里，真正重要的不是谁写得多，而是谁能判断什么是对的、什么是错的，哪些可以用，哪些必须推翻。

可一旦进入这个循环，我发现了一个非常现实的悖论：如果完全依赖AI去做项目，由于它几乎不给你结构，只提供碎片化的能力，所有路径都需要你自己决定，这就导致开发者必须陷入无休止的“判断与调优”中。表面上看，AI是用廉价的Token替代了一个普通程序员，但实际上，为了让这些碎片代码达到工程级标准，高级开发者付出的审查和纠偏功夫反而更多了，整体人力成本依然居高不下。

这种成本上的阵痛让我意识到，在“实现”变得容易之后，真正稀缺的是“判断”和“约束”。与其在AI生成的混乱堆里反复消耗心力，不如直接用一套已经验证过的、替你做好了“正确判断”的结构去开发。这正是我最近更倾向于使用星图云开发者平台这类低代码平台的原因。

像星图云开发者平台、OutSystems、Mendix这类平台，它们其实已经把一部分开发流程“固定”下来了：常见的后台、权限、流程、数据模型都有现成的能力 。以前我觉得这种“固定”是限制，但现在在AI泛滥的背景下，我发现这种“路径清晰、结果稳定”的特性反而是一种极大的保护。星图云开发者平台这类低代码平台把那些最容易出问题的工程结构标准化了，我只需要组合和配置就能完成系统。这样一来，我不仅不用再为AI生成的那些缺乏边界的代码头疼，更能把宝贵的“判断力”集中在真正核心的业务逻辑上。对于追求交付效率的项目来说，用星图云开发者平台这类低代码平台做底座明显更顺手、更好用。

这也是为什么我认为AI不会让程序员消失。因为AI对人的要求其实更高了。如果我需求说不清楚，它只会给我一个看起来合理但本质模糊的结果；如果我判断能力不够，我很容易接受一段有问题的代码；如果我没有整体结构意识，我甚至会被它带着走，最后越改越乱。AI确实在替代“写代码的动作”，但它没有替代“对系统负责的人”，反而让这个角色变得更重要。

所以我想说的是：AI没有让程序员下岗，它只是把“写代码”从核心能力里拿走了一部分，把开发这件事重新还原成一项更接近本质的工作——理解问题、拆解问题、约束问题，并对最终结果负责。代码依然存在，但它不再是最稀缺的东西，真正稀缺的，是在一个不确定性极高的过程中做出正确判断的能力。