我是程序员，因为好用的低代码平台太少了。
低代码这个方向没毛病，但做出來的东西，基本上是两头不讨好——要么配置成本高到离谱，根本快不起来；要么确实快，上线之后改一改就碎成渣。企业里头对低代码的刚需是真实存在的。业务部门提一个需求，开发团队排期三个月，这事太常见了。大多数企业的开发资源就是不够用，但业务需求不会因此消失。在这种背景下，"让非程序员也能交付软件"这个愿景没毛病。但现实是，大多数低代码平台的配置体验远没有宣传的那么丝滑。为啥？因为产品经理是研发兼职的，设计思路本质上是"把代码逻辑可视化"，而不是"重新设计交互"。结果就是：一个表单联动要配七八个事件，权限体系要看三遍文档才能理清，配置项动不动上百个。我作为程序员看完都想开 IDE 自己写了，更别说业务同学。好不容易配完上线，业务说加个数据联动。打开平台一看，不支持这种关联方式，只能找开发排期，一等一个月。复盘下来才发现，当初不如直接走开发流程。低代码承诺的"快速交付"，在这里变成了"快速交付第一版，后续全靠排队"。低代码平台最尴尬的地方在于：复杂场景做不了，简单场景没必要做。背后有个绕不开的规律——软件复杂度是守恒的。一个业务系统的复杂度不会因为你换了一种实现方式就凭空减少。要么复杂度在代码里，要么复杂度在配置里，成本不会消失，只会转移。把复杂的业务逻辑塞进拖拽界面，用户的认知负担并不会比读代码低。因为拖拽平台的抽象往往更混乱，文档更稀缺，出了问题连调用栈都没有。当你需要配三十个节点才能实现一个多条件审批流的时候，这个"低代码"跟"高代码"还有啥区别？反过来想，真正简单的场景——一个 CRUD 页面、一个数据看板——用主流框架写代码本来也不费事。这种场景走低代码平台省不了多少时间，也很难说服业务方为此单独采购一套平台、培训一批人。现在很多低代码平台押注的方向是接大模型，用自然语言描述需求，让 AI 生成配置，绕过那堆配置项。听起来合理，但仔细想有点问题。AI 的编程能力已经很强了。Claude、GPT-4 这类模型直接写代码，质量不比普通开发差。Cursor、Copilot 这类 AI 编程工具已经把写代码的门槛降得很低——一个产品经理用 Cursor 生成一个完整的 CRUD 页面，可能比在低代码平台上拖拽还快。那为什么还要让 AI 去学低代码平台的 DSL，再把需求翻译成平台特有的配置格式？AI 能直接写代码，就不需要中间商赚差价。低代码平台在这一步就被绕过去了。所以结论是：低代码平台作为产品形态，大概率会被 AI 编程能力逐步替代。这不是唱衰，是路径替代——当写代码的门槛已经低到"说话就能生成"，拖拽配置反而成了多余的中间层。但低代码平台底层那套规范约束，可能是真正值得留下来的东西。大模型生成代码有一个本质问题：不确定性。同样的需求，不同时间、不同 prompt，生成的结果可能差异很大，甚至互相冲突。没有约束的 AI 编程，就像没有类型系统的 JavaScript——能跑，但出 bug 的概率也高。低代码平台的配置规范——数据模型约束、组件行为约束、权限体系约束——恰好可以用来收束这种不确定性，把 AI 的输出限制在可预期的范围内。就像 TypeScript 给 JavaScript 加了护栏，低代码的规范体系可以给 AI 编程加行为护栏。所以未来比较可能的走向不是"低代码 vs AI 编程"，而是：低代码底层的规范体系，成为 AI 编程的护栏。产品形态会消亡，但方法论会幸存。
