AI 把软件开发的很多环节都提速了。
页面能更快搭出来，CRUD 更快写出来，原型和表单结构也更容易快速试出来。
这件事当然是好事。
但我最近越来越强烈地感觉到一个问题：
AI 让开发变快之后，很多团队反而更容易低估返工的真实成本。
最典型的一句话就是：
“反正现在有 AI，先做出来，我们边看边改。”
这句话在今天比以前更危险。
因为 AI 的确让“改代码”这件事看起来轻了很多，于是团队、客户、产品，甚至开发自己，都会更容易放松对前置判断的要求。
但问题是：
AI 降低的是局部实现成本，不是需求失真的系统性成本。
一、AI 降低了改代码的体感成本
先承认一件事：很多改动今天就是比以前快。
例如一个典型后台场景：
- 表单字段变了
- 列表展示项变了
- 校验逻辑变了
- 接口出入参变了
以前这类改动，开发往往要自己逐层查：
- 前端表单
- 状态管理
- 接口层
- DTO
- 校验
- 表结构
现在如果上下文清楚，AI 可以很快把代码骨架改出来。
所以很多人会自然得出一个结论：
既然改起来这么快，那就先做呗，后面再慢慢调。
这个结论的问题，不在“快”，而在“错把实现速度，当成了项目风险的下降”。
二、AI 改得掉代码，改不掉错误的需求方向
项目真正容易出问题的地方，很多时候不是代码写得慢，而是需求理解一开始就偏了。
比如客户说：
“客户状态先随便分几类，后面再调整。”
听起来像个小决定。
但如果系统已经按这个定义长出来，后面改的可能不是几个状态值，而是一整条链路：
- 列表筛选逻辑
- 统计报表口径
- 跟进提醒规则
- 权限范围
- 审批条件
- 历史数据兼容
AI 可以很快帮你把其中一部分代码改掉。
但它解决不了更本质的问题：
你是沿着错误或模糊的边界，长出了一套正确执行的代码。
这时候返工不是“重写几段代码”，而是要重新定义：
- 业务规则是什么
- 状态边界在哪里
- 哪些数据要兼容历史
- 哪些逻辑要迁移
所以 AI 再快，也不能把错误方向自动修成正确方向。
三、AI 时代最危险的，不是返工慢，而是大家开始不怕返工
以前团队怕返工，反而会被逼着在前面多想一点。
今天返工的动作成本下降了，很多团队的前置思考反而松了。
这就是 AI 时代特别容易出现的一种错觉：
反正改起来很快，那就先做。
这句话在某些场景里成立，但前提非常苛刻。
只有在下面这些情况下，它才相对安全：
- 改的是表现层，不是业务规则
- 改的是低风险模块，不是核心链路
- 团队已经清楚哪些能试、哪些不能试
如果这些边界没有先分清，“先做再改”并不是敏捷。
它只是把“需求没想清楚”的代价，推迟到更贵的时候发生。
四、可以先做再调，和不能先做再改，是两回事
这是我现在特别在意的一条边界。
可以先做再调的，通常是这些
- 页面文案
- 展示顺序
- 某些字段默认显隐
- 非核心交互细节
- 不影响业务链路的视觉调整
这些地方 AI 非常适合提速。
因为它们改动快，影响面也相对可控。
不能先做再改的，通常是这些
- 业务规则定义
- 状态流转
- 权限边界
- 统计口径
- 数据归属
- 审批逻辑
- 上线后的维护责任
这些如果前面没问清楚，AI 帮你写得越快，后面返工的频率反而可能越高。
所以问题从来不是“能不能边做边调”，而是：
你有没有先分清哪些地方允许试，哪些地方必须先定。
五、我后来怎么处理“先做出来再改”这种要求
我现在遇到这类说法，一般不会直接说不行，也不会直接答应。
我会先把问题改写成：
哪些内容可以先做再调，哪些内容一旦定下来，后面动一下就会影响整条链路？
这个问题一问出来，讨论的质量通常会立刻提高。
因为大家不得不开始区分：
- 页面和规则
- 体验和逻辑
- 局部调整和系统性变更
很多项目在这一步，才第一次真正开始做需求分层。
我越来越觉得，AI 时代里一个很重要的交付能力，不是“把代码写得更快”，而是“把变更按风险分层”。
如果团队没有这个能力，就很容易出现一种表面高效、实际失控的状态：
- 代码一直在快速变
- 页面一直在快速迭代
- 但核心规则没有稳定下来
- 最后局部效率提高了，整体交付效率反而下降了
六、AI 时代真正稀缺的，是前置判断力
今天写代码这件事，正在越来越不稀缺。
真正稀缺的反而是：
- 判断哪些需求可以试
- 判断哪些需求必须定清
- 判断一个改动影响的是页面，还是整条业务链路
- 判断某个“先做出来看看”的建议，到底是在提效，还是在埋雷
也就是说，AI 把“动手”这段路压缩了。
所以“动手之前先判断”的价值就更高了。
以前一个项目慢，可能是因为开发不够快。
现在很多项目慢，反而是因为需求方向切得太频繁，业务边界一直没收住。
这就是我现在越来越警惕“先做出来再改”这句话的原因。
AI 不是让我们可以少想一点。
恰恰相反。
AI 越能帮我们更快动手，团队就越需要在动手之前把问题问对。
写在最后
AI 时代下，真正值钱的不是更快写代码，而是更早识别哪些地方不能乱改。
可以快速试错的部分，当然应该大胆利用 AI 提速。
但只要涉及业务规则、权限边界、状态流转、统计口径这些核心结构，就不能把“AI 很快”误当成“返工没关系”。
如果说以前的项目管理是在防“开发太慢”，那今天很多团队更该防的是另一种风险：
局部实现越来越快，整体方向却越来越乱。
所以我现在不是更愿意听到“先做出来再改”。
而是比以前更在意：
这件事，到底是可以先做再调，还是必须先问清楚再开工。
