最近这一年，我的开发方式几乎被 AI 重塑了。
写页面、封装 hooks、补接口层、甚至写 Node 服务------
很多时候，我不是在"写代码"，而是在"描述需求"。
回车之后，代码一会就出来了。
这种感觉，很像你从"手工木匠"变成了"操控自动化工厂的人"。
效率提升是肉眼可见的：
- 原来半天的功能，现在可能半小时就能跑起来
- 一些重复性工作几乎可以忽略
- 连不熟的技术栈，也能快速"拼"出一个能用的版本
但奇怪的是------
我开始越来越不敢直接把这些代码上线了。
那种不安，是慢慢长出来的
一开始我也没多想。
AI 写的代码，大多数时候看起来都"挺对的"：
- 结构清晰
- 命名合理
- 甚至还会加注释
有些代码，甚至比我自己写得还"规范"。
但问题在于：
它太"顺滑"了。
顺滑到你很容易失去警惕。
一个很真实的坑
有一次，我在做一个简单的前端缓存优化。
我让 AI 帮我写一个缓存层，大致需求是：
- 相同请求短时间内复用结果
- 支持过期时间
- 出错时不缓存
它很快给了我一版实现。
我看了一下：
- 用了 Map 做缓存
- 有 TTL 控制
- 逻辑也挺清楚
我就直接用了。
上线之后，一切正常。
直到某一天，接口压力突然变大。
排查之后发现：
某些失败请求，被错误地缓存了。
导致后续请求直接命中"错误结果"。
问题的根源是：
- 它在处理 Promise 的时候，没有区分 resolve / reject 的缓存策略
- 失败的 Promise 也被缓存进去了
这个问题很隐蔽。
平时完全正常，一旦触发，就是一片连锁反应。
那一刻我意识到：
AI 写的代码，不是"错很多"，而是"偶尔错，但错得很深"。
本质问题：你在使用一个"不可解释的合作者"
后来我慢慢想明白了一件事：
AI 编程的本质，不是工具升级，而是------
你多了一个"写代码的搭档"，但你不了解它。
这个搭档有几个特点：
- 写得很快
- 知识面很广
- 但不会对自己的设计负责
- 也不会主动告诉你风险点
这和团队里的新人还不一样。
新人你可以带，可以问，可以 review 他的思路。
但 AI：
它直接给你"结果"，而不是"过程"。
这就导致一个很大的问题：
你很容易在没有完全理解的情况下，引入复杂逻辑。
为什么"看起来没问题"的代码最危险？
因为它会骗过你的直觉。
在日常开发中，我们的大脑其实是有一套"快速判断机制"的：
- 代码结构 OK → 通过
- 命名合理 → 通过
- 跑起来没报错 → 通过
但 AI 写的代码，很擅长"满足这些表层条件"。
问题往往藏在：
- 边界条件
- 异常处理
- 并发场景
- 状态一致性
这些地方，你不仔细想，是看不出来的。
我现在的解决办法（以及一些实用方案）
踩过几次坑之后，我开始系统性地调整自己用 AI 的方式。
不是不用，而是"加护栏"。
下面这些，是我目前在实践的一些方法。
1. 分层信任：不是所有代码都一样对待
我把代码分成三类：
✅ 低风险（可以高度依赖 AI）
- UI 组件
- 样板代码
- 简单工具函数
这类代码问题成本低，可以大胆用。
⚠️ 中风险（需要 review）
- 业务逻辑
- 数据处理
- 状态管理
AI 可以写，但必须过一遍。
🚨 高风险（必须自己主导）
- 并发逻辑
- 缓存策略
- 权限、安全
- 核心架构
这类我基本不会"直接用 AI 结果"。
最多是参考。
2. 强制自己做"二次建模"
现在我有一个习惯：
AI 写完之后，我会在脑子里重新建一遍模型。
比如：
- 数据是怎么流动的？
- 状态在哪儿变化？
- 哪些地方可能出错？
如果我讲不清楚这段代码在干嘛，我就不会上线。
3. 引入"最小验证测试"
不用一上来就搞完整测试体系。
但至少要做：
- 正常路径测试
- 异常路径测试
- 边界测试
比如刚才那个缓存问题：
js
// 失败请求是否被缓存？
await requestFail()
await requestAgain() // 是否还失败？这种小测试，能救很多命。
4. 让 AI 参与"审查"，而不是只写代码
我现在经常这样用 AI：
这段代码有什么潜在问题？
有没有边界情况没考虑？
如果是高并发场景会怎样？有时候，它真的能指出一些问题。
相当于多了一层"自动 code review"。
5. 控制"上下文复杂度"
一个很重要的经验是：
不要一次性让 AI 生成太复杂的东西。
越复杂的上下文：
- 越容易出错
- 越难 review
我现在更倾向于：
- 拆小任务
- 分步骤生成
- 每一步都验证
6. 给关键代码加"可观测性"
以前写前端，很多时候不太重视日志。
现在不行了。
对于关键逻辑，我会加：
- 日志（log）
- 监控（monitor）
- 错误上报
因为：
AI 写的代码，你无法完全预判，只能提高可观测性。
7. 建立自己的"可信代码库"
一些常用能力，比如：
- 请求封装
- 缓存策略
- 状态管理模式
我会沉淀成自己的一套实现。
之后：
AI 只能"用"，不能"改核心"。
这样可以避免反复踩坑。
8. 乖乖地加各种测试用例
以前我对"写测试"这件事，说实话是有点抗拒的。
尤其是前端：
- 页面能跑就行
- 手点一遍没问题就 OK
- 写测试？有时间再说吧
但自从开始大量用 AI 写代码之后，我的态度彻底变了。
现在不是"要不要写测试"，而是：
不写测试，我根本不敢提交代码。
一个很真实的变化
以前我觉得：
"代码写出来能跑就行。"
现在变成：
"代码我必须解释得清楚，才敢上线。"
这个变化，其实挺大的。
AI 不是问题，失控才是
说到底，AI 编程本身没有问题。
问题在于：
你是不是在"无意识地依赖"。
当你开始：
- 不看代码
- 不理解逻辑
- 直接复制粘贴
那风险就已经埋下了。
最后
我现在依然大量使用 AI。
甚至比以前更多。
但我给自己设了一条底线：
我可以不写代码，但我不能不理解代码。
这条线，一旦守住了：
AI 是加速器。
守不住：
它就是放大器------把问题放大。
如果你也在用 AI 写代码，可能会有类似的感受：
速度变快了，但"确定性"变低了。
而我们要做的，不是拒绝它，而是------
重新建立对代码的掌控感。
最后问一个问题：AI 到底是在帮我们加速，还是只是把复杂度换了个地方？