哈喽，我是老刘
老刘用Flutter开发客户端也有六七年了，这两年在工作中使用AI的地方有很多。
有的地方很爽，有的地方很难受，但是总体感觉还是利大于弊的。
不过前两天看到这篇文章，也确实道出了AI编程中那些我们不得不面对的问题。
比如老刘聊过的一家 8 人的初创团队，使用 AI 编码，一周的PR 数量翻了三倍。
结果线上事故也翻了三倍。
原来两周一次迭代，最近三天一次合并，半天一次回滚。
项目管理工具一片绿，线上监控一片红。
这不是"AI 要让程序员失业"。
这是"AI 正在让团队失控"。
为什么会这样？
很简单：AI 写得快，但不会替你做工程治理。
它能自动补全，却不会自动复盘。
它能一秒生成代码，却不能替你建立边界、规范和兜底机制。
所以 CTO 们喊停，不是倒车。
是先把安全带系上，把车灯调亮，把路标竖好。
先把"能不能跑"换成"稳不稳跑，能不能收"。
接下来我们聊聊，AI开发在真正的企业开发中到底扮演了什么角色，以及如何有效的利用AI。
AI 编程的真相，提效是事实，翻车也是真事
先说好的一面。
AI 编程确实有三大利好，老刘亲测有效：
第一，提升效率。
标准化、重复性强的代码，AI "嗖嗖"就来。
写个 CRUD 接口，以前半小时，现在 5 分钟。
写个数据模型类，以前敲键盘敲到手酸，现在描述一下需求就行。
老刘团队统计过，纯编码环节效率提升了 60% 都不止。
第二，降低门槛。
新人上手更快，能看懂结构、补齐语法。
以前新人写个复杂的动画效果，需要查手册，自己调试，折腾很久。
现在 AI 直接给出标准写法，还带注释。
第三，重构利器。
对遗留系统做现代化改造有奇效。
比如老刘的项目时原生 + Flutter混合开发。
当一个需求对老页面或者老模块的修改高于50%的时候，我们就会用Flutter重写。
这种情况下AI将老页面转换为Flutter页面的效率奇高。
但是，硬币总有另一面。
AI 编程有三大致命坑，每个都能让你怀疑人生：
第一坑：架构缺位。
AI 不懂你的全局业务与约束，容易"就地拼贴"。
它只看到你当前的代码片段，不知道你的系统边界在哪里。
结果就是，单个模块看起来很完美，整体架构一团糟。
老刘见过一个场景，新增一个促销用的大模块，AI 生成的代码每个函数都很优雅。
但是这些代码拼在一起，就好像是找了一堆实习生写的代码，拼接到一起，就成了一个大的系统。
第二坑：隐形技术债。
Demo 看着顺眼，长线维护是"堆屎山"。
AI 为了快速实现功能，经常选择最直接的路径。
不考虑扩展性，不考虑维护性，不考虑性能优化。
3 个月后你再看这些代码，想改一个小功能，牵一发动全身。
第三坑：维护地狱。
"调试像考古"，上下文与意图缺失。
AI 生成的代码往往缺少关键的业务逻辑注释。
你知道它做了什么，但不知道为什么这么做。
出了 bug，你得像考古学家一样，一层层挖掘代码的真实意图。
更要命的是生产环境的三座大山：
**性能问题：**小样本 OK，大流量崩。
AI 写的代码在测试环境跑得飞起，一上生产就趴窝。
**安全漏洞：**权限边界出血，数据泄露风险。
AI 不懂你的安全策略，有可能在权限控制上留后门，这里并不是说它是故意的，而是很多情况可能会考虑不到。
**可扩展性：**没考虑未来增长，架构僵化。
当用户量从 1000 涨到 10 万，系统很有可能会撑不住。
一句话总结：
AI 是"强力螺丝刀"，不是"自动盖房机"。
它能帮你拧螺丝，但房子的设计图，还得你来画。
（1、至少现阶段是这样）
（2、Claude Code在这方面表现会好一点）
那么我们应该怎么办呢？是彻底抛弃AI回到原来？还是有切实可行的手段降服AI？
别跟风，给 AI 上"缰绳"的 5 步工作法
答案当然不是抛弃，而是给AI套上"缰绳"。
老刘结合这两年的实战经验，总结了一套"防失控"的 5 步工作法：
第一步：边界清单先行
别什么都交给 AI，先画清楚红线。
适合交给 AI 的：
- 样板代码：比如 CRUD 接口、数据模型类
- 单元测试：特别是边界值测试和异常处理测试
- 文档生成：API 文档、代码注释自动补全
- 重构建议：代码优化和性能提升建议
不适合交给 AI 的：
- 核心业务逻辑：支付流程、用户权限控制
- 安全关键代码：加密解密、身份验证
- 复杂算法：推荐算法、计费逻辑
这个边界不是一成不变的，根据团队、项目和AI工具的不同而变化，但在团队内必须明确且统一的。
也就是说团队里每个人都要知道，哪些能碰，哪些不能碰。
第二步：设计先、落码后
这是最关键的一步。
不要上来就让 AI 写代码，先由人画清架构图、数据流、接口边界。
把整个系统的"骨架"搭好，再让 AI 按"空位"补代码。
就像装修房子，先把水电布局、承重墙确定好，再让 AI 帮你贴瓷砖刷油漆。
老刘的做法是：每个功能模块开发前，先用 30 分钟画个简单的架构图。
标清楚输入输出、依赖关系、边界约束。
然后把这个架构图贴给团队，大家 Review 通过了，再开始用 AI 写具体代码。
第三步：双层防线
Code Review 和自动化测试，一个都不能少。
Code Review 重点看什么？
- 业务逻辑是否正确
- 权限控制是否到位
- 异常处理是否完善
- 性能是否有问题
别只看代码风格和语法错误，那些 AI 比人做得好。
要看 AI 看不到的东西：业务上下文、安全边界、性能瓶颈。
自动化测试要覆盖核心链路。
特别是用户注册、登录、支付这些关键流程，测试用例必须跟上。（当然，如果能结合TDD其实更好）
第四步：可观测与压测
别拿"小样本正常"当真相。
AI 生成的代码在开发环境跑得好，不代表生产环境也 OK。
必须要有：
- 性能基准数据
- 压力测试验证
- 完善的监控报警
老刘团队的做法是：每各版本都要跑压测。
模拟真实用户量，看看系统会不会崩。
监控指标也要跟上：响应时间、错误率、资源使用率。
第五步：迭代与回滚
小步快跑，灰度发布，预设回滚预案。
别搞"豪赌式上线"，一次性把所有 AI 代码都推到生产。
先推 10% 流量，观察 24 小时。
没问题再推 50%，最后推 100%。
每个阶段都要有明确的回滚触发条件：
- 客户端可以看崩溃率，用户投诉等指标。
- 服务端要看响应时间，内存占用等指标。
还有三条红线，踩到任何一条都是找死：
- 不懂就上：对 AI 生成的代码不理解，就直接用
- 不审就上：跳过 Code Review，直接合并
- 无人负责：没有明确的责任人，出了问题找不到人
这些坑老刘都见过团队踩，甚至有些我们团队自己都踩过，每一个都是血的教训。
总结：与其追风，不如驭风
说到底，AI 是工具而非替代。
架构设计、业务判断、技术责任，还是要由人类技术负责人扛。
AI 可以让你的手速更快，但不能替你做决策。
它可以帮你生成代码，但不能替你承担后果。
记住这句话：别指望 AI 写出你的战略，它只会加速你的选择。
方向错得越早，坑就挖得越快。
所以，与其盲目追风，不如学会驭风。
让 AI 成为你手中的利器，而不是脱缰的野马。
最后问个问题：你的团队把哪些环节交给了 AI？又有哪些"生死线"你绝不交？
欢迎在评论区分享你的经验和踩坑故事。
如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。 可以作为Flutter学习的知识地图。 ------ laoliu_dev