大厂已经不谈怎么用 AI 替代人,写代码变便宜了,但是做软件这件事情没有变便宜

这两年，AI 的广泛应用确实让写代码这件事变便宜了。

写一个接口、生成一个页面、补一组测试、改一个 CRUD，过去可能要花半天，现在可能几分钟就能得到一个还不错的代码。

很多人因此得出一个判断：既然 AI 能写代码，那程序员是不是就没那么重要了？既然写代码变便宜了，那做软件是不是也变便宜了？

我觉得这两个判断都有问题。

因为它们都把“写代码”误认为了“做软件”。

代码生产确实变快了，但软件决策没有变少。

AI 降低的是代码生成成本，不是软件交付成本。真正决定软件价值的，不是代码生成速度，而是我们能不能把业务问题、产品流程和工程约束串起来。

换句话说：

代码可以被生成，但软件必须有对现实世界的判断。

一、AI 确实让写代码变便宜了

先承认一个事实：AI 对软件开发的提效是真实存在的。

现在让 AI 写一个列表页、表单页、接口封装、单元测试、脚手架代码，这些确定性的内容 AI  能很快给出结果。

对于大量标准化、模板化、重复性的开发工作，AI 的确大幅降低了生产成本。

以前很多开发时间花在“把代码写出来”这件事上。

比如：

写一个新增接口，要定义参数、写校验、写 service、写 DAO、补文档、补测试。

写一个前端页面，要搭布局、调组件、处理表单状态、对接接口、补交互细节。

写一个普通 CRUD，要把类似的代码一遍遍复制、修改、调试。

这些事情现在 AI 都能帮我们更快完成。

所以我并不反对 AI 提效。相反，程序员应该主动使用 AI，把它放进自己的工作流里。

但问题在于：写代码变快，不等于做软件变简单。

因为代码只是软件生产链路里的一环，而且很多时候，它不是最贵的那一环。

过去我们以为软件贵，是因为代码难写。

所以我们做产品设计的时候会更谨慎，调动研发资源的时候会去做更多的前期工作来保证研发资源被用在刀刃上。

现在 AI 把代码生产变便宜之后，我们反而更清楚地看到：软件真正贵的地方，往往不在代码本身，而在代码之前和代码之后。

代码之前，是问题定义、需求判断、流程设计、规则抽象。

代码之后，是验收、上线、维护、演进、风险兜底。

这些事情没有因为 AI 能写代码就自动消失。

二、代码不是软件，能解决真实问题才是软件

一个快排函数是代码，但它不是软件。

一个登录接口是代码，它只是软件里面的一个功能，有它不代表是一个可交付的软件

一个看起来完整的前端页面，也可能只是页面，而不是一个真正能被用户稳定使用的功能。

那什么才是软件？

软件的最小成立条件是：能解决真实用户问题。

只有当代码被放进真实业务流程里，能承载业务规则，能处理异常情况，能被不同角色稳定使用，并且能在后续业务变化中继续演进，它才开始接近软件。

软件不是一堆文件，也不是几个接口和页面的组合。软件是一套被系统化表达出来的业务能力。

拿 ERP 来说，“销售订单”不是一张表，也不是一个新增页面。

它背后连着客户、商品、价格、库存、账期、发票、出库、回款、审批、权限和审计。

AI 可以很快生成一个销售订单 CRUD。

但它不一定知道：

订单提交后还能不能改客户？

未收款是否允许出库？

大客户是否允许特批？

订单取消后库存怎么回滚？

销售、财务、仓库看到的信息是否应该一样？

历史单据是否需要兼容？

这些问题，才是真正的软件问题。

代码可以生成，但业务规则不会自己长出来。页面可以生成，但用户为什么要点这个按钮、什么时候点、点错了怎么办，这些都需要人来判断。

所以，代码和软件之间，隔着真实业务。

没有业务问题，代码只是一堆文件。

没有产品流程，代码不知道该如何组织。

没有工程约束，代码很快就会变成系统债。

三、真正没变便宜的，是软件决策

AI 让代码生产变快了，但软件决策没有变少。

软件工程过程中，最贵的不是“把代码写出来”，而是持续做判断：

要不要做？

做到什么程度？

为谁优先？

规则怎么定？

异常怎么处理？

风险谁承担？

未来如何扩展？

这些问题不是 AI 自动替我们完成的。

尤其在企业软件里，很多复杂度不是单纯的技术复杂度，而是业务复杂度。

工程复杂度有很多成熟方法可以处理。比如分层架构、设计模式、DDD、状态机、事件驱动、幂等、缓存、消息队列、事务补偿。

这些方法很重要，也很有价值。

但业务复杂度没有固定答案。

因为业务里有客户特例、历史流程、组织边界、权限博弈、财务风险和长期维护成本。

比如一个“是否允许发货”的判断，看起来只是一个 if。

但背后可能是客户账期、应收余额、信用等级、历史逾期、大客户特批、库存占用、审批权限和财务风控。

AI 可以帮你写这个 if。

但谁来定义这个 if 背后的业务规则？

这才是软件工程里更贵的部分。

再比如一个字段要不要做成配置化。

从代码上看，写死最简单。AI 也能很快生成。

但从软件角度看，你要判断：

这个规则是不是经常变化？

未来是不是不同客户会有不同配置？

配置开放给谁？

配置错了谁负责？

配置变更要不要审计？

历史数据怎么兼容？

这些判断不是代码生成问题，而是软件决策问题。

代码越容易生成，人的判断反而越重要。

因为 AI 可以很快产出一堆代码，如果方向错了，它只会更快制造技术债、业务债和维护成本。

四、一个智能问数的例子：代码容易，软件难

智能问数是我最近做的一个需求。

这个功能的代码并不复杂。

用户输入一个问题，系统请求大语言模型，让模型理解问题，再生成对应的查询逻辑，最后把结果返回给用户。

从 Demo 角度看，这个链路很容易做出效果。

用户问：

“这个客户最近半年买过哪些型号？”

AI 返回一段 SQL，系统执行后展示结果。

看起来很智能，也很有冲击力。

但如果要把它做成企业 ERP 里真正可用的功能，问题就完全不一样了。

因为它不是一个简单的“自然语言转 SQL”功能，而是一个需要安全、可信、可控的业务查询系统。

用户问“最近半年”，应该按什么时间算？

是下单时间、出库时间、开票时间，还是回款时间？

用户问“买过哪些型号”，是看订单明细，还是看实际出库记录？

如果订单取消了，要不要算？

如果出库后又退货，要不要排除？

如果同一个客户有多个主体，要不要合并统计？

这些都是业务口径问题。

再往下看，还有权限问题。

销售能不能查所有客户？

只能查自己名下客户，还是能查部门客户？

财务数据能不能给销售看？

毛利、成本、应收、逾期这些字段是否需要按角色控制？

老板看到的是全量数据，销售看到的是部分数据，普通员工看到的是脱敏数据，这些都要被明确设计。

如果只是让大模型自由生成 SQL，风险非常高。

它可能查到用户无权访问的数据。

可能生成高成本查询，拖慢数据库。

可能误解字段含义，返回一个看似正确但实际口径错误的结果。

甚至可能在提示词被攻击时暴露系统结构或敏感信息。

所以，真正落地的智能问数，不能让 AI 随便生成 SQL。

更合理的方式是受控问数。

它应该是这样一个流程：

用户自然语言提问。

系统先做意图识别，判断用户到底想问什么。

然后做槽位提取，比如客户、时间范围、型号、金额口径、订单状态。

再去匹配系统已经注册好的查询能力。

比如：

查询客户近半年购买型号。

查询客户应收逾期情况。

查询当前型号可用库存。

查询出库未开票订单。

查询已开票未回款金额。

接着进行参数校验和权限校验。

确认这个用户能不能查这个客户，能不能看这些字段，查询范围是否合理。

然后再执行受控 SQL 模板，而不是让模型自由发挥。

最后由模型负责解释结果，而不是直接决定查询逻辑。

这个过程中，代码只是实现手段。

真正的难点是：

第一版支持哪些问题？

哪些问题必须拒答？

哪些字段不能暴露？

不同角色看到的结果是否一致？

查询口径怎么定义？

结果能不能追溯？

模型不确定时怎么兜底？

用户问得模糊时，是猜测，还是追问？

这些才决定了智能问数是不是一个真正的软件功能。

如果只是把大模型接进系统，它只是一个 Demo。

如果它能在权限可控、口径明确、安全可信的前提下，帮助用户更快做业务判断，它才是软件。

智能问数的核心价值，不是“让用户能问”。

而是“让用户问出来的结果，能安全、可信、可追溯地辅助业务决策”。

五、AI 时代，软件从业者的价值会迁移

AI 时代真正的问题不是“程序员会不会被替代”。

这个问题太粗了。

更准确的问题是：

当代码生产越来越便宜，程序员的价值会迁移到哪里？

我认为会从代码生产能力，迁移到复杂度判断能力。

更有价值的程序员，不一定是比 AI 更会写代码的人，而是更会定义问题、组织上下文、控制复杂度、验证结果的人。

也就是说，人的角色会发生变化。

从实现者，变成 AI 协作系统的设计者。

从写代码的人，变成定义问题和验证结果的人。

这并不是说代码能力不重要。

相反，代码能力依然重要。因为你需要看懂 AI 生成的代码，知道它有没有绕远路，有没有破坏边界，有没有留下隐患。

但只会写代码已经不够了。

还需要补三类能力。

第一，业务理解能力。

要知道用户真实问题是什么，而不是只接一句需求。

用户说想要一个报表，真实需求可能不是报表，而是想知道哪些客户有回款风险。

用户说想要智能问数，真实需求可能不是聊天框，而是想降低查询数据的门槛，让销售、财务、老板都能更快拿到可信信息。

第二，产品判断能力。

要知道功能流程应该怎么设计。

哪些信息应该前置？

哪些操作应该收敛？

哪些复杂度不应该暴露给用户？

用户需要的是自由提问，还是几个高频问题的快捷入口？

当系统不能回答时，是直接失败，还是引导用户换一种问法？

这些都不是代码问题，而是产品问题。

第三，工程决策能力。

要知道系统边界怎么切。

哪些地方可以让 AI 参与？

哪些地方必须受控？

哪些查询能力要注册？

哪些字段要脱敏？

哪些操作要审计？

哪些结果要可追溯？

哪些实现现在省事，但半年后会变成维护成本？

这些能力，决定了 AI 生成的代码最后是软件资产，还是系统负债。

而这一切的起点，是验收标准。

如果产品都不知道自己想要什么，代码更不可能知道该如何实现。

如果我们不能定义清楚什么叫“做对了”，AI 只会把模糊需求更快变成一堆看起来合理、但长期不可维护的代码。

所以，程序员不能把自己降级成 AI 的操作员。

只会对 AI 说“帮我写一个页面”“帮我生成一个接口”，价值会越来越低。

更重要的是，你要能告诉 AI：

我们要解决什么问题。

这个功能服务于谁。

哪些规则不能破。

哪些边界不能越。

哪些结果必须验证。

哪些异常必须兜住。

哪些代码未来还要维护。

这才是 AI 时代更稀缺的能力。

写在最后

代码会越来越便宜，但软件不会自动变便宜。

因为软件的成本，正在从“写代码”迁移到“做判断”。

AI 降低了编码成本，但没有替我们完成业务理解、产品取舍、工程决策和风险承担。

它可以帮我们更快生成代码，但不能替我们判断什么代码值得写，应该怎么写，写到什么程度，以及上线后出了问题谁负责。

AI 时代真正有价值的软件从业者，不是比 AI 更会写代码的人，而是更会定义问题、组织上下文、控制复杂度、验证结果的人。

写代码变便宜了。

但做软件这件事，依然很贵。