网上关于 AI 提升开发效率的文章很多，但大多数是「AI 帮我一键生成了一个完整应用」这种偏演示性质的内容。

我想说的是更日常的东西：在真实项目里，AI 是怎么嵌进我的工作流的，哪些地方有实质帮助，哪些地方反而浪费时间。

真正节省时间的地方

写模板代码

前端有大量重复性高的代码——Redux action、API 请求函数、TypeScript 接口定义、测试文件骨架……这些代码结构固定，自己写无聊还费时。

现在我的做法是让 AI 先生成骨架，我来填业务逻辑。比如新建一个 API 模块：

1
2
3
4
5
帮我生成一个 userApi.ts，基于 axios，包含以下接口：
- getUser(id: string)
- updateUser(id: string, data: Partial<User>)
- deleteUser(id: string)
需要统一的错误处理，返回类型用 Promise<ApiResponse<T>> 包装

生成的代码改一下接口路径和字段名就能用。这种任务以前要 10 分钟，现在 2 分钟。

理解不熟悉的代码

接手老项目，或者用了一个不太熟的库，AI 帮我快速理解代码结构。我会直接把一大段代码丢进去问「这在做什么」，比自己硬读快很多。

调试思路卡壳的时候

有时候一个 bug 想了半天没思路，把相关代码和现象描述给 AI，它给的方向不一定对，但能打破思维定势。有时候它提的一个方向我自己没想到，顺着查下去就找到了。

不是 AI 帮我解决了问题，而是它帮我换了个角度。

写正则、写 SQL、写配置

这些东西我用的不频繁，每次都要查文档。现在直接说需求让 AI 生成，准确率很高。「写一个匹配 yyyy-mm-dd 格式日期的正则」、「写一个 nginx 配置，把 /api 反向代理到 localhost:8080」，这类任务 AI 很擅长。

被高估的地方

复杂业务逻辑

AI 不了解你的业务。让它实现一个「根据用户权限动态渲染菜单」的功能，它只能给你一个通用的例子，你还得根据实际业务大改。

我花了一次不小的代价——让 AI 实现了一个比较复杂的数据处理逻辑，看了一下觉得没问题，就直接上线了。结果边界情况没处理好，出了 bug。从那之后我的原则是：涉及业务逻辑的代码，不管 AI 写的多好看，必须自己过一遍。

替代学习

有人把 AI 当搜索引擎用，遇到不懂的概念就问 AI，得到答案就结束了，不深究原理。

这种方式用久了会有问题——你会用，但不知道为什么能用，也不知道什么时候会失效。AI 的答案有时候会把不同版本的 API 混用，或者在某些边界条件下给出错误的解法，如果你没有基础判断能力，就很难发现。

AI 是加速器，不是替代品。

生成完整项目

「用 AI 一分钟搭建一个完整项目」这种演示看起来很酷，但在真实工作里不实用。生成的代码往往用了陌生的架构、缺少错误处理、没有考虑你的团队规范，改起来比自己写还费事。

我现在的日常使用方式

整理一下我用 AI 工具的频率和方式：

每天必用：

  • Cursor 的 Tab 补全（几乎无感知地嵌入编码过程）
  • 遇到报错先问 AI（比搜索快，但重要的错误还是要真正理解）

经常用：

  • 生成模板代码：表单、API 封装、类型定义
  • 写正则、shell 命令、nginx 配置这类不常写的东西
  • 让 AI 给代码 review

偶尔用：

  • 设计层面的讨论：「这个场景用 Context 还是 Zustand 更合适」
  • 写文档注释

不用 AI 的场景：

  • 核心业务逻辑（必须自己写并理解）
  • 对代码质量有高要求的关键模块
  • 有明确的团队规范且 AI 理解不了规范的时候

一个心态上的调整

我觉得用好 AI 工具，有一个心态转变很重要：从「AI 帮我完成任务」到「AI 是我的协作工具」。

前者容易变成 AI 依赖，不思考，照单全收。后者是你主导，AI 协助，你对结果负责。

用 AI 之后我的技术能力并没有下降，反而因为节省了大量重复工作的时间，有更多精力去思考架构、处理复杂问题、学新东西。

这才是 AI 工具真正的价值所在。