AI 让写代码变便宜了，但做软件依然很贵

AI 的广泛应用确实让写代码变便宜了。
写接口、生成页面、补测试、改 CRUD，过去可能要半天，现在几分钟就能得到一个不错的结果。

既然 AI 能写代码，程序员是不是没那么重要了？写代码变便宜了，做软件是不是也变便宜了？

这个观点是把“写代码”误认为了“做软件”。
AI 降低的是代码生成成本，不是软件交付成本。真正决定软件价值的，不是代码写得多快，而是能不能把业务问题、产品流程和工程约束串起来。

软件必须有对现实世界的判断。
一个登录接口是代码，一个列表页面也是代码，但它们不等于软件。软件的最小成立条件是：能解决真实用户问题。

拿 ERP 的销售订单来说，AI 很快能生成一个 CRUD。但销售订单不是一张表。它背后连着客户、商品、价格、库存、账期、发票、出库、回款、审批、权限和审计。
订单提交后还能不能改客户？
订单取消后库存怎么回滚？
销售、财务、仓库看到的信息是否一致？
这些问题，才是真正的软件问题。
AI 可以帮你写 if，但谁来定义 if 背后的业务规则？

这也是为什么，代码越容易生成，人的判断反而越重要。
因为方向错了，AI 只会更快制造技术债、业务债和维护成本。

我最近做智能问数时，这种感受更明显。
从 Demo 看，它很简单：用户输入问题，模型生成 SQL，系统执行查询，再返回结果。比如用户问：“这个客户最近半年买过哪些型号？”AI 给出 SQL，看起来很智能。
但放到企业 ERP 里，它就不是简单的自然语言转 SQL，而是一个安全、可信、可控的业务查询系统。
更合理的方式是受控问数：先做意图识别和槽位提取，再匹配系统注册好的查询能力，经过参数校验、权限校验后，执行受控 SQL 模板，最后让模型解释结果。
代码只是实现手段，真正难的是：哪些问题必须拒答？哪些字段不能暴露？查询口径怎么定义？结果能不能追溯？模型不确定时怎么兜底？

过去程序员更强调代码生产能力，未来更强调复杂度判断能力。
不一定是比 AI 更会写代码的人，而是更会定义问题、组织上下文、控制复杂度、验证结果的人。
这并不是说代码能力不重要。相反，代码能力依然重要。因为你要看懂 AI 生成的代码，知道它有没有破坏边界，有没有留下隐患。

但只会写代码已经不够了。
还需要理解业务，知道用户真正要解决什么问题；需要具备产品判断，知道流程怎么设计、复杂度怎么收敛；需要有工程决策能力，知道哪些地方可以交给 AI，哪些地方必须受控、审计和兜底。