夜雨聆风
前段时间，我接了一个项目。
不是特别大的项目，但需求挺典型：一个内部管理系统，第一期要先把客户录入、跟进、审批和基础统计跑起来。
刚开始聊的时候，对方老板说了一句让我印象特别深的话：
“你们现在不是都用 AI 开发了吗？那就先做出来，我们边看边改。”
他说得很自然。
甚至是带着一种“我这是在帮你们提效率”的语气。
我当时没有马上反驳。
说实话，有那么一瞬间，我差点被说服了。
因为从表面上看，这句话好像也没错：
AI 写代码快了 原型改动快了 页面生成快了 CRUD 接口几乎可以批量出
既然开发速度都上来了，那是不是以前那些需要反复确认的东西，现在可以先做再说？
听上去很合理。
但我后来越来越确定一件事：
AI 让开发变快之后，我反而更怕客户说“先做出来再改”了。
因为它会把一个本来就危险的项目，推向更危险的方向。
一、AI 把开发提速了，也把很多人的错觉放大了
以前客户说“先做出来再改”，大多数开发团队心里都会咯噔一下。
因为大家都知道，改东西是有成本的。
页面要改，接口要改，表结构可能也要改，测试还得重来一遍。
所以哪怕客户嘴上说“就改一点点”，开发也知道这件事不轻。
但 AI 出来之后，这种直觉被削弱了。
因为现在很多改动表面上真的变快了。
举个很直接的例子。
以前一个后台页面改字段、改表单、改校验、改接口，可能得花半天甚至一天。
现在把需求描述清楚，AI 很快就能把代码骨架改出来。
于是很多人会自然得出一个结论：
“既然改起来这么快，那就先做呗，后面边看边调。”
问题就在这里。
AI 降低的是“改代码的体感成本”，不是“改需求的真实成本”。
这两者不是一回事。
代码快改完了，不代表项目风险变小了。
很多时候只是让大家更容易低估返工的影响面。
二、AI 能很快改掉一个页面，但改不掉需求失真
很多项目真正危险的地方，不是代码写得慢。
而是需求一开始就没说清。
比如客户说：
“客户状态先随便分几类，后面我们再看怎么调。”
听上去像个很小的决定。
但如果你真的“先做出来再改”，后面可能改的根本不是几个状态值，而是一整套逻辑：
列表筛选要改 后台统计要改 权限范围要改 跟进提醒规则要改 审批流转条件要改 历史数据兼容要处理
AI 可以很快帮你把这些代码都改掉一部分。
但它解决不了一件更本质的事：
一开始对需求的理解偏了，后面所有代码都是在偏的基础上长出来的。
这时候返工不是“把旧代码换成新代码”那么简单。
它更像是：
你已经按一条错误的路修出去一段了，现在你不是只需要换个方向盘，而是要连路基一起重修。
AI 再快，也不能把错误方向变成正确方向。
三、最危险的不是改得慢，而是大家开始不怕改了
我后来发现，AI 时代最容易出现的一个错觉是：
反正改得快，那就先做再说。
这句话听上去像灵活，实际上很容易把项目带偏。
因为过去大家怕返工，至少还会逼着自己在动手前多想一点。
现在返工的“动作成本”下降了，很多人反而没那么愿意在前面把问题想清楚了。
客户这么想。
有些开发也会这么想。
甚至一些团队会把它包装成一种“AI 时代的新敏捷”：
先快速做 MVP，边看边调，需求不要卡太死。
这套话在某些场景里成立。
但前提是：
你改的是表现层，不是业务规则 你试的是低风险环节，不是核心流程 你知道哪些东西可以试，哪些东西必须先定死
如果这些边界没有分清，“先做再改”就不是敏捷。
它只是把需求没想清楚这件事，推迟到更贵的时候发生。
四、我后来是怎么把这个项目拉回来的
那个项目继续往下聊的时候，我没有直接说“不行，不能这样做”。
我换了个问法。
我先问对方：
“哪些东西你们可以边看边改，哪些东西一旦定下来，后面动一下就会影响整条链路？”
这个问题一问出来，群里安静了几秒。
然后老板、运营、财务开始慢慢往外说。
最后我们大概梳理出两类东西：
第一类：可以边做边调的
页面文案 列表展示顺序 某些字段是不是默认展示 统计页的视觉呈现
这些东西，AI 确实很适合提速。
因为它们改起来快，影响范围也可控。
第二类：不能“先做再改”的
客户状态定义 审批流转规则 权限范围 数据统计口径 操作日志保留方式
这些一旦模糊，后面就不是“调一调”。
而是整个系统都会跟着扭。
于是我们做了一个决定：
把可以快改的部分，交给 AI 提速；把不能乱改的部分，先在需求阶段问清楚。
这个项目后来没有做得特别快。
但做得很稳。
最关键的是，后面几轮联调基本没有出现那种“越做越乱”的返工。
五、AI 时代下，真正值钱的不是更快写代码
我现在越来越强烈地感觉到一件事：
AI 时代，写代码会越来越不是稀缺能力。
真正稀缺的，是下面这些东西：
判断哪些需求可以先做再调 判断哪些需求必须先问清楚 判断一个变更影响的是页面，还是整条业务链路 判断某个“先做出来看看”的建议，到底是在提效，还是在埋雷
说白了，AI 让“动手”变快了。
所以“动手之前先判断”的价值反而更高了。
以前一个团队慢一点，可能是因为开发不够快。
现在很多团队慢，反而是因为方向切得太频繁。
今天做这个。
明天改那个。
后天又推翻前天的逻辑。
代码看起来改得飞快，项目却越来越不稳。
这就是 AI 时代很容易出现的一种新型低效：
局部开发效率提升了，整体交付效率反而下降了。
六、什么时候可以“先做出来再改”，什么时候绝对不行？
这个边界，我现在看得很重。
可以先做出来再改的，通常是这些：
视觉样式 交互细节 页面文案 非核心字段展示 不影响业务链路的体验优化
这些东西改动成本相对可控，AI 很适合加速。
不能“先做出来再改”的，通常是这些：
业务规则定义 关键状态流转 权限边界 统计口径 数据归属 审批逻辑 上线后的维护责任
这些东西如果没想清楚，AI 帮你写得越快，后面返工就可能来得越快。
所以我现在遇到“先做再改”这类建议，不会直接拒绝，也不会直接接受。
我会先分层。
能试的，快速试。
不能乱试的，先问清。
这其实才是我理解里更成熟的 AI 时代工作方式。
七、写在最后
客户说“先做出来再改”，以前就危险。
到了 AI 时代，这句话反而更危险了。
因为 AI 让很多人误以为：
只要代码改得快，项目就能靠边做边调跑起来。
但项目真正容易失控的，从来不是“代码改得慢”。
而是：
需求边界没定清 规则稳定性没确认 哪些能改、哪些不能乱改，没有分层
AI 让开发更快，这没问题。
但它真正考验的，不是你会不会更快地写代码。
而是你能不能在更快写代码之前，先把问题问对。
所以现在如果客户再跟我说：
“反正你们有 AI，就先做出来，我们再慢慢改。”
我第一反应已经不是“好像也行”。
而是：
先等一下。我们先把哪些能改、哪些不能乱改，讲清楚。
这一步没做，后面越快，可能越危险。
