大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



最近这一年，我的开发方式几乎被 AI 重塑了。

回车之后，代码一会就出来了。

这种感觉，很像你从“手工木匠”变成了“操控自动化工厂的人”。

效率提升是肉眼可见的：

• 原来半天的功能，现在可能半小时就能跑起来
• 一些重复性工作几乎可以忽略
• 连不熟的技术栈，也能快速“拼”出一个能用的版本

但奇怪的是——

我开始越来越不敢直接把这些代码上线了。

---

一开始我也没多想。

AI 写的代码，大多数时候看起来都“挺对的”：

• 结构清晰
• 命名合理
• 甚至还会加注释

有些代码，甚至比我自己写得还“规范”。

但问题在于：

它太“顺滑”了。

顺滑到你很容易失去警惕。

---

有一次，我在做一个简单的前端缓存优化。

我让 AI 帮我写一个缓存层，大致需求是：

• 相同请求短时间内复用结果
• 支持过期时间
• 出错时不缓存

它很快给了我一版实现。

我看了一下：

• 用了 Map 做缓存
• 有 TTL 控制
• 逻辑也挺清楚

我就直接用了。

上线之后，一切正常。

直到某一天，接口压力突然变大。

排查之后发现：

某些失败请求，被错误地缓存了。

导致后续请求直接命中“错误结果”。

问题的根源是：

• 它在处理 Promise 的时候，没有区分 resolve / reject 的缓存策略
• 失败的 Promise 也被缓存进去了

这个问题很隐蔽。

平时完全正常，一旦触发，就是一片连锁反应。

那一刻我意识到：

AI 写的代码，不是“错很多”，而是“偶尔错，但错得很深”。

---

后来我慢慢想明白了一件事：

AI 编程的本质，不是工具升级，而是——

你多了一个“写代码的搭档”，但你不了解它。

这个搭档有几个特点：

• 写得很快
• 知识面很广
• 但不会对自己的设计负责
• 也不会主动告诉你风险点

这和团队里的新人还不一样。

新人你可以带，可以问，可以 review 他的思路。

但 AI：

它直接给你“结果”，而不是“过程”。

这就导致一个很大的问题：

你很容易在没有完全理解的情况下，引入复杂逻辑。

---

因为它会骗过你的直觉。

在日常开发中，我们的大脑其实是有一套“快速判断机制”的：

• 代码结构 OK → 通过
• 命名合理 → 通过
• 跑起来没报错 → 通过

但 AI 写的代码，很擅长“满足这些表层条件”。

问题往往藏在：

• 边界条件
• 异常处理
• 并发场景
• 状态一致性

这些地方，你不仔细想，是看不出来的。

---

踩过几次坑之后，我开始系统性地调整自己用 AI 的方式。

不是不用，而是“加护栏”。

下面这些，是我目前在实践的一些方法。

---

我把代码分成三类：

✅ 低风险（可以高度依赖 AI）

• UI 组件
• 样板代码
• 简单工具函数

这类代码问题成本低，可以大胆用。

---

⚠️ 中风险（需要 review）

• 业务逻辑
• 数据处理
• 状态管理

AI 可以写，但必须过一遍。

---

🚨 高风险（必须自己主导）

• 并发逻辑
• 缓存策略
• 权限、安全
• 核心架构

这类我基本不会“直接用 AI 结果”。

最多是参考。

---

现在我有一个习惯：

AI 写完之后，我会在脑子里重新建一遍模型。

比如：

• 数据是怎么流动的？
• 状态在哪儿变化？
• 哪些地方可能出错？

如果我讲不清楚这段代码在干嘛，我就不会上线。

---

不用一上来就搞完整测试体系。

但至少要做：

• 正常路径测试
• 异常路径测试
• 边界测试

比如刚才那个缓存问题：

// 失败请求是否被缓存？ await requestFail() await requestAgain() // 是否还失败？ 

这种小测试，能救很多命。

---

我现在经常这样用 AI：

这段代码有什么潜在问题？ 有没有边界情况没考虑？ 如果是高并发场景会怎样？ 

有时候，它真的能指出一些问题。

相当于多了一层“自动 code review”。

---

一个很重要的经验是：

不要一次性让 AI 生成太复杂的东西。

越复杂的上下文：

• 越容易出错
• 越难 review

我现在更倾向于：

• 拆小任务
• 分步骤生成
• 每一步都验证

---

以前写前端，很多时候不太重视日志。

现在不行了。

对于关键逻辑，我会加：

• 日志（log）
• 监控（monitor）
• 错误上报

因为：

AI 写的代码，你无法完全预判，只能提高可观测性。

---

一些常用能力，比如：

• 请求封装
• 缓存策略
• 状态管理模式

我会沉淀成自己的一套实现。

之后：

AI 只能“用”，不能“改核心”。

这样可以避免反复踩坑。

以前我对“写测试”这件事，说实话是有点抗拒的。

尤其是前端：

• 页面能跑就行
• 手点一遍没问题就 OK
• 写测试？有时间再说吧

但自从开始大量用 AI 写代码之后，我的态度彻底变了。

现在不是“要不要写测试”，而是：

不写测试，我根本不敢提交代码。

---

以前我觉得：

“代码写出来能跑就行。”

现在变成：

“代码我必须解释得清楚，才敢上线。”

这个变化，其实挺大的。

---

说到底，AI 编程本身没有问题。

问题在于：

你是不是在“无意识地依赖”。

当你开始：

• 不看代码
• 不理解逻辑
• 直接复制粘贴

那风险就已经埋下了。

---

我现在依然大量使用 AI。

甚至比以前更多。

但我给自己设了一条底线：

我可以不写代码，但我不能不理解代码。

这条线，一旦守住了：

AI 是加速器。

守不住：

它就是放大器——把问题放大。

---

如果你也在用 AI 写代码，可能会有类似的感受：

速度变快了，但“确定性”变低了。

而我们要做的，不是拒绝它，而是——

重新建立对代码的掌控感。

最后问一个问题：AI 到底是在帮我们加速，还是只是把复杂度换了个地方？