程序员用AI提效：我的工作流分享（附配置教程）

程序员用AI提效：我的工作流分享（附配置教程）

---

先说个扎心的数字。

上周五，我统计了一下自己一天的工作产出：用了大约4小时的AI辅助，写完了一个用户权限模块，包括接口、service层、数据库操作和单元测试。

搁以前，这个工作量我至少要干两天。

不是我变厉害了，是工具变了。

---

先交代背景，不说废话

我用的工具：Cursor + Claude（主力）或者DeepSeek（备用）。

为什么是Cursor而不是Copilot？两个原因。

第一，Copilot本质是个高级代码补全，它能猜你下一行要写什么，但它不知道你想做什么。Cursor不一样，它真的能理解你的意图，可以做代码生成、重构、解释、Review这些事情。

第二，Cursor支持多文件编辑。我之前做过一个小程序项目，需要同时修改6个文件，用Copilot只能一个文件一个文件来，Cursor可以直接帮我规划好各文件的修改方案，一次性搞定。

Copilot没有一无是处，代码补全速度确实快，现在我Copilot和Cursor混着用，各有各的场景。

---

我的一天是怎么过的

早上9点：看需求

我习惯早上到公司先看今天的需求，把要做的事情在脑子里过一遍。

不是立刻开写，是先想：这个需求的核心是什么？涉及哪些模块？有哪些边界情况要处理？

这一步以前我做得比较糙，直接开写，遇到问题再想解决方案。踩过几次坑之后学乖了，磨刀不误砍柴工。

9点半：让AI帮我拆解需求

想清楚之后，我会打开Cursor的聊天框（Cmd/Ctrl + L），把需求用大白话描述一遍：

"帮我拆解一下这个需求：用户进入个人中心，可以看到自己的订单列表。列表需要分页，每页20条。需要显示订单号、商品名称、下单时间、订单状态。用户可以点击订单查看详情。"

Claude会帮我整理成这样的结构：

1. 订单列表页
   - 调用订单列表接口（分页参数：page, pageSize）
   - 接口返回：订单号、商品名称、下单时间、状态
   - 前端分页组件

2. 订单详情页
   - 点击订单跳转详情页
   - 详情接口返回完整订单信息
   - 渲染订单详情组件

这个TODO列表就是今天的作战地图。拿到这个之后，我心里有底了，知道从哪下手，不会写着写着迷失方向。

10点-12点：开始写代码

第一个小时：搭骨架

我不会直接让Cursor帮我写代码，那样出来的代码质量不可控。

我的做法是：先自己把框架搭好，文件结构定清楚，注释写好。

举个例子，我要写一个订单Service，会先这样：

// orderService.js

/**
 * 获取订单列表
 * @param {Object} params - 查询参数
 * @param {number} params.page - 页码
 * @param {number} params.pageSize - 每页数量
 * @param {string} params.userId - 用户ID
 * @returns {Promise<{list: Array, total: number}>}
 */
async getOrderList(params) {
  // TODO: 参数校验
  // TODO: 调用订单Repository获取数据
  // TODO: 格式化返回数据
  // TODO: 返回分页结果
}

这个骨架是我的，Cursor只能帮我填空。

第二个小时：让Cursor填肉

选中这些TODO注释，按 Cmd/Ctrl + K，输入：

"帮我实现这个函数，参数校验要校验userId是否存在，调用Repository用select * from orders where user_id = ?，返回结果要格式化时间戳为YYYY-MM-DD HH:mm:ss"

Cursor会帮我生成这样的代码：

async getOrderList(params) {
  // 参数校验
  if (!params.userId) {
    throw new Error('userId不能为空');
  }
  
  const { page = 1, pageSize = 20 } = params;
  const offset = (page - 1) * pageSize;
  
  // 调用Repository
  const list = await this.orderRepository.query(
    'SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT ? OFFSET ?',
    [params.userId, pageSize, offset]
  );
  
  // 获取总数
  const [{ total }] = await this.orderRepository.query(
    'SELECT COUNT(*) as total FROM orders WHERE user_id = ?',
    [params.userId]
  );
  
  // 格式化返回
  const formattedList = list.map(order => ({
    orderId: order.order_id,
    productName: order.product_name,
    createdAt: dayjs(order.created_at).format('YYYY-MM-DD HH:mm:ss'),
    status: order.status
  }));
  
  return {
    list: formattedList,
    total,
    page,
    pageSize
  };
}

这个代码基本上能直接用，可能有几个小地方要调整，比如我用的ORM语法可能不太对，或者字段名需要改成项目里的命名规范。调整一下就好了，整体比我手写的快多了。

午休前：让AI做Code Review

写完代码，我会把刚写的文件扔进聊天框，让Claude帮我Review一下：

"帮我Review这段代码，重点看看有没有bug、命名是否规范、有没有安全问题"

Claude通常会给我一些具体的建议：

1. 存在SQL注入风险：userId应该用参数化查询（你已经做了，这个没问题）
2. 建议加上分页上限：pageSize最大100，防止一次查询数据量过大
3. status字段可能需要枚举值校验
4. 考虑加上请求超时处理

有些是我没想到的，有些是我"知道但懒得做"的。Review完之后，我会把这些优化点补上。

下午：写测试用例

这是AI提效最明显的部分。

我直接跟Cursor说："帮我为getOrderList函数写测试用例，覆盖正常情况、分页情况、userId为空的情况"

Cursor会生成这样的测试代码：

describe('getOrderList', () => {
  it('正常返回订单列表', async () => {
    const mockData = [
      { order_id: '001', product_name: '商品A', created_at: '2026-01-01', status: 1 }
    ];
    mockRepository.query.mockResolvedValue([mockData, [{ total: 1 }]]);
    
    const result = await service.getOrderList({ userId: '123', page: 1, pageSize: 20 });
    
    expect(result.list).toHaveLength(1);
    expect(result.total).toBe(1);
  });
  
  it('userId为空抛出异常', async () => {
    await expect(service.getOrderList({})).rejects.toThrow('userId不能为空');
  });
});

生成的测试用例覆盖了基本场景，我再补几个边界情况的用例就好了。

以前写测试用例我觉得是负担，现在变成流水线作业，反而没那么抵触了。

---

几个进阶技巧

上面说的是基础用法，下面说几个我后来发现的进阶技巧。

技巧1：用AI帮你写正则表达式

我最烦写正则，脑子不够用。以前遇到需要校验手机号、邮箱、身份证的需求，都是先Google再改。

现在直接问Cursor：

"帮我写一个中国手机号的正则，要求：1开头，第二位是3-9，共11位"

Cursor秒回，还能给你解释这个正则的每一部分是什么意思。

技巧2：让AI帮你写SQL

有些复杂的查询语句我写起来很费劲，尤其是多表联查、子查询这些。

直接用大白话描述需求：

"帮我写一个SQL：查询订单表和用户表，关联条件是user_id，返回用户名、手机号、订单数、消费总额，按消费总额降序排列，只看2026年的订单"

Cursor会给你完整的SQL，你再根据实际表结构调整一下字段名就行。

技巧3：遇到报错，让AI先分析

遇到Bug的时候，我以前习惯先Google，看看有没有人遇到过同样的问题。

现在我会先问Cursor：

"这个报错是什么意思：TypeError: Cannot read property 'map' of undefined"

Cursor会告诉你报错原因、可能的情况、怎么排查。比Google强的是，它可以根据你给的上下文（比如报错的代码片段）给出更精准的分析。

技巧4：用AI帮你理解别人的代码

有时候接手的项目代码写得烂，读起来费劲。

我会把一段看不懂的代码扔给Cursor：

"帮我解释一下这段代码在做什么，它的输入输出是什么，有没有什么潜在问题"

Claude会给你一个清晰的解读，比自己啃半天效率高多了。

---

配置细节

说了这么多，你可能想问：具体怎么配置？

第一步：下载安装

去 cursor.com 下载，安装过程跟普通软件一样（魔法上网，懂得都懂）。

第二步：连接AI模型

Cursor默认带的是Cursor模型，对国内用户不太友好，速度慢。

推荐换成Claude（魔法、也容易封号）或DeepSeek：

1. 按 Cmd/Ctrl + Shift + I 打开设置
2. 左侧选择 Models
3. 添加模型提供方，选择 Claude 或 DeepSeek
4. 填入你的API Key

API Key怎么来：

• Claude：去 anthropic.com 注册（需要海外手机号验证）
• DeepSeek：去 platform.deepseek.com 注册，国内可直接访问，有免费额度

第三步：记住这几个快捷键

快捷键	作用
Cmd/Ctrl + K	选中代码后，按这个键，让AI按你的要求修改
Cmd/Ctrl + L	打开聊天框，问AI问题或让它写代码
Tab	接受AI的自动补全建议
Esc	拒绝当前建议
Cmd/Ctrl + Enter	应用聊天框里的完整代码
Cmd/Ctrl + Shift + L	把当前文件内容引用到聊天框

这6个快捷键覆盖了90%的使用场景，其他的等你熟悉了再慢慢发现。

---

踩过的坑，你们别再踩了

坑1：让AI从零写整个项目

这是新手最容易犯的错误。

我第一次用Cursor，兴奋地输入："帮我写一个博客系统，包含用户管理、文章发布、评论功能"。

Cursor真的给我写了一大堆代码，看起来结构清晰、有模有样。

然后我一跑，全是问题：

• 模块之间的依赖关系是乱的
• 错误处理基本是空的
• 数据库表结构没设计
• 边界情况没考虑

后来我才明白：AI擅长填空，不擅长设计。你让它从零设计一个系统，它给你的是"看起来像系统但跑不通"的代码。

正确姿势：自己先设计好架构，把数据库表结构、定好模块边界、接口设计好，再让AI帮你实现各个模块的具体功能。

坑2：需求描述太模糊

一开始我跟AI说话特别随意：

"帮我优化一下这个函数"

AI改完之后，有时候跟我的预期完全不一样。我想让它优化性能，它给我改了命名；我想让它加注释，它给我重构了代码。

正确姿势：描述要具体。

不要说"优化这个函数"，要说：

• "把这段代码的性能提升10倍"
• "给这个函数加上异常处理"
• "把这段if-else改成switch"
• "给这个API加上请求参数校验，参数校验失败的返回400"

坑3：完全相信AI的代码

AI写的代码不是100%可信。

有一次Cursor帮我写了一个删除接口的SQL：

DELETE FROM orders WHERE id = ?

看起来没问题，但我跑的时候发现：它把所有订单都删了。

原因是我忘了传参数，id是undefined，SQL变成了 DELETE FROM orders WHERE id = undefined。

在MySQL里，undefined 会被当成 NULL，而 id = NULL 永远不成立，所以理论上不会删除任何数据。

但Cursor生成的代码里，可能有些其他逻辑的问题，导致它执行了错误的SQL。

最后我是怎么发现的？是Cursor自己跟我说的——在后续的Review中，它指出这个问题，说应该在SQL执行前加上id校验。

从那以后，AI写的所有SQL，我都会先检查条件部分有没有校验。

正确姿势：AI的代码一定要审核。不理解的不用，不确定的不用。先跑通测试用例，再上线。

坑4：太依赖AI，懒得自己想

这是我自己最近意识到的。

有时候遇到问题，我第一反应是问Cursor，而不是自己先想一下。长此以往，遇到简单问题还好，遇到复杂问题的时候，我发现自己独立思考的能力在退化。

比如以前我记API记得很熟，现在直接问Cursor，时间长了脑子真的变钝了。

我的做法：遇到问题先自己想办法，实在想不出来再问AI。这一分钟思考是必要的，不能省。

---

效果怎么样

说点实际的。

用了这套工作流三个月，我的感受：

真的快了。以前一个中等复杂度的功能模块（包含接口、Service、Repository加测试），大概需要1.5-2天。现在同样的功能，早上开工，下午测完。

质量确实提高了。以前写完代码，能通过测试用例就算完事。现在有AI Review，会多一层检查，有时候能发现自己没注意到的边界问题。

但也有代价。AI让写代码变快了，但写代码本身变得没那么有成就感了。以前解决一个复杂逻辑会兴奋半天，现在变成跟AI对话的一部分，少了点意思。

不知道这算好事还是坏事。

---

什么场景适合用AI，什么场景不适合

AI擅长的：

• 有固定套路的：CRUD、参数校验、错误处理
• 有明确规则的：格式化代码、写测试用例、写正则、写SQL
• 机械性的：代码重构、批量修改变量名、加注释

AI不擅长的：

• 架构设计：选什么框架、分层怎么划、模块怎么拆
• 业务理解：这个功能为什么要这样设计，它在整个系统里起什么作用
• 创新性的：你要做一个没人做过的功能，AI给不了你答案

知道什么交给AI，什么必须自己做，很重要。

---

总结

1. 需求先想清楚，让AI帮你拆解成TODO
2. 框架自己搭，AI填肉
3. 写完让AI Review，补上你没想到的问题
4. 测试用例交给AI，补边界情况
5. AI的代码要审核，不理解的不用
6. 先自己想再问AI，保持独立思考能力

工具只是工具，别让它替代你思考。

---

有什么问题评论区问，看到会回。如果觉得有用，点个赞。