手把手打造一套高效的 AI 编程工作流你有没有这种感觉——装了 Copilot、试了 Cursor、玩了 Claude

手把手打造一套高效的 AI 编程工作流

你有没有这种感觉——装了 Copilot、试了 Cursor、玩了 Claude Code，AI 编程工具一个没落下，但写代码的效率好像也就那样？该查的文档还在查，该踩的坑一个没少。问题出在哪？不是工具不行，是你没有把工具编排成工作流。

单个 AI 工具就像一把好刀，但做菜不能只靠刀。你得知道什么时候用刀切、什么时候用锅炒、什么时候该上手揉。我带团队做了半年 AI 辅助开发，最大的体会是：工具选型只占 20%，工作流设计占 80%。这篇文章把我们团队沉淀下来的一套完整工作流拆给你看，从项目初始化到 Code Review，每个环节怎么让 AI 介入、介入到什么程度、哪些地方必须人工兜底。

核心步骤二：用分层 Prompt 管理复杂任务

上下文文件解决的是"AI 知道项目长什么样"的问题。下一个问题是：怎么把一个复杂需求拆给 AI 做？直接甩一句"帮我做一个带搜索、分页、排序的用户管理页面"，AI 大概率给你吐一个 300 行的巨型组件，搜索逻辑、分页逻辑、表格渲染全糊在一起。能跑，但没法维护。

我们团队摸索出一个"三层 Prompt"的模式：

第一层：架构层（用 Claude Code）

先让 AI 只做架构设计，不写实现代码。Prompt 大概是这样的：

我要做一个用户管理模块，功能包括：
1. 用户列表（支持搜索、分页、按状态筛选）
2. 新增/编辑用户（弹窗表单）
3. 批量启用/禁用

请帮我拆分文件结构和组件职责，不要写具体实现，只输出：
- 需要哪些文件
- 每个组件/composable 的职责边界
- 组件之间的数据流向

Claude Code 会输出一个清晰的文件树和职责说明。你快速 Review 一下，觉得拆分合理再进入下一步。这一步花 2 分钟，能省后面 30 分钟的返工。第二层：实现层（用 Cursor 或 Claude Code）

架构确认后，按文件逐个让 AI 实现。关键是每次只让它写一个文件，并且把相关的上下文喂给它。在 Cursor 里你可以用 @file 引用相关文件：

请实现 src/composables/useUserList.ts
参考 @src/api/user.ts 的接口定义
参考 @src/composables/useTablePagination.ts 的分页封装

这比一次性让 AI 写整个模块要靠谱得多。每个文件生成后你当场 Review，有问题当场改，不会出现最后发现整个模块的数据流设计有问题、全部推翻重来的情况。第三层：打磨层（用 Copilot）

骨架和核心逻辑写完，剩下的胶水代码——类型定义补全、错误边界处理、loading 状态管理——直接用 Copilot 的 Tab 补全搞定。这类代码模式化程度高，Copilot 的补全准确率非常不错。

效果验证：怎么知道 AI 没有在坑你

AI 生成的代码最大的风险不是"写错了"——写错了编译器和 TypeScript 会帮你兜着。最大的风险是"看起来对，但有隐藏的逻辑问题"。举个真实案例。让 AI 写一个防抖搜索的 composable：

// AI 生成的版本
export function useDebounceSearch(fetchFn: Function, delay = 300) {
  const keyword = ref('')
  let timer: number | null = null

  const doSearch = () => {
    if (timer) clearTimeout(timer)
    timer = setTimeout(() => {
      fetchFn(keyword.value)
    }, delay) as unknown as number
  }

  watch(keyword, doSearch)
  return { keyword }
}

乍一看没问题，跑起来也正常。但仔细看有两个坑：第一，fetchFn 用的是 Function 类型，等于放弃了类型检查；第二，组件卸载的时候 timer 没清理，如果用户快速切换页面会导致请求打到已卸载的组件上。

正确的做法是在 Review AI 代码时重点检查这几个方向：

// 修正后的版本
export function useDebounceSearch(
  fetchFn: (keyword: string) => Promise<void>,
  delay = 300
) {
  const keyword = ref('')
  const { start, stop } = useTimeoutFn(
    () => fetchFn(keyword.value),
    delay,
    { immediate: false }
  )

  watch(keyword, () => {
    stop()
    start()
  })

  onUnmounted(stop)
  return { keyword }
}

修正版做了三件事：fetchFn 有了明确的类型签名；用 @vueuse/core 的 useTimeoutFn 替代手动管理 timer；加了 onUnmounted 清理。这些都是 AI 容易忽略的"工程化细节"。

我们团队的 AI 代码 Review 有一个 checklist：

类型安全：有没有 any、Function、Object 这类逃逸类型
生命周期：定时器、事件监听、订阅有没有清理
边界条件：空数组、undefined、并发请求的竞态
依赖版本：AI 用的 API 是不是当前依赖版本支持的（AI 经常用已废弃的 API）
安全性：有没有 XSS 风险，用户输入有没有做转义

每次让 AI 生成完代码，对着这个 checklist 过一遍。听起来麻烦，但比你自己从零写再自己查 bug 快多了。

几个容易翻车的坑

跑了半年 AI 工作流，有几个坑我必须提一嘴，都是真金白银的教训。

坑一：过度依赖 AI 写测试

一开始我们让 AI 写单元测试，觉得这活儿最适合 AI 干——模式化、重复度高。结果发现一个严重问题：AI 写的测试倾向于"验证实现"而不是"验证行为"。比如一个计算购物车总价的函数，AI 写的测试是这样的：

it('should calculate total', () => {
  const cart = [{ price: 10, count: 2 }, { price: 20, count: 1 }]
  expect(calcTotal(cart)).toBe(40)
})

只有一个 case，而且只覆盖了 happy path。空购物车呢？price 是负数呢？count 是小数呢？AI 不会主动去想边界条件，因为它是根据你的函数实现来"推测"应该测什么的，不是根据业务需求来设计测试的。

我们现在的做法是：人写测试用例（描述行为和边界条件），AI 写测试代码（实现这些用例）。人的脑力花在"该测什么"上，AI 的能力用在"怎么写测试代码"上。

坑二：AI 生成的代码里藏着过时的依赖用法

这个坑踩的人特别多。AI 模型的训练数据有滞后性，它可能用 Vue 3.2 时代的写法来写你 3.4 版本的代码。我们遇到过好几次 AI 用 defineComponent + setup() 的写法，而项目早就统一用 <script setup> 了。

更隐蔽的是第三方库的 API 变化。我们有一次让 AI 写 Element Plus 的表单校验，它用了 this.$refs.form.validate()——这是 Vue 2 + Element UI 的写法，在 Vue 3 + Element Plus 里根本不存在。编辑器不报红（因为 ref 类型推导不出来），运行时才炸。

解决方案回到前面说的 CLAUDE.md，把当前使用的依赖版本和关键 API 变化写进去：

## 依赖版本与 API 注意事项
- Element Plus 2.5：表单校验用 formRef.value.validate()，不是 this.$refs
- Vue Router 4.x：路由守卫用 Composition API 写法，不要用 beforeRouteEnter
- pinia 2.1：defineStore 支持 Setup Store 语法，项目统一用 Setup Store

坑三：让 AI 处理涉及敏感数据的逻辑

有一次团队新人让 AI 帮写一个数据脱敏的工具函数，Prompt 里直接贴了几条真实的用户手机号作为示例。这些数据会被发送到 AI 服务的 API，存在数据泄露风险。

我们后来定了一条铁律：任何包含真实用户数据、密钥、内部接口地址的内容，不允许出现在 AI 工具的输入里。需要举例就用明显的假数据：13800138000、test@example.com、sk-fake-key-for-demo。

这条规则写进了团队的 CLAUDE.md 和 onboarding 文档，新人入职第一天就会被告知。

我们团队的 AI 编程工作流全景图

把上面所有环节串起来，我们当前的工作流长这样：需求拆解阶段：用 Claude Code 做架构设计和文件拆分，人工 Review 确认拆分合理性。这个阶段 AI 的角色是"技术方案讨论搭子"，你跟它对话把方案敲定，比自己对着空白文档想要快。

编码实现阶段：核心业务逻辑在 Cursor 里写，@file 引用相关上下文，每写完一个模块就 Review。工具函数、类型定义、API 层这类模式化代码交给 Copilot 补全。

调试排错阶段：按"五要素"模板组织信息再问 AI，不要零散地贴报错截图。测试阶段：人定义测试用例和边界条件，AI 实现测试代码。

Code Review 阶段：AI 先过一遍做机械检查，资深开发者再做架构和业务逻辑层面的 Review。

知识沉淀阶段：每次 AI 犯的重复错误，补进 CLAUDE.md / .cursorrules。这是一个不断迭代的过程，你的上下文文件越丰富，AI 的输出质量越高。

跑通这套工作流之后，我们团队的几个关键数据变化：

指标	引入 AI 工作流前	引入 AI 工作流后（稳定 3 个月）
新功能模块平均交付周期	5.2 天	3.1 天
线上 bug 数（月均）	11.4 个	7.8 个
代码 Review 通过率（首轮）	38%	62%
开发者每日有效编码时长	约 4.5 小时	约 5.8 小时

有效编码时长的提升主要来自调试和查文档时间的减少。以前遇到一个不熟悉的 API，得去翻文档、找 StackOverflow、看 GitHub Issues，现在直接问 AI，30 秒拿到一个靠谱的答案（前提是你的 Prompt 质量过关）。

AI 编程工具的正确定位是放大器——它放大你的能力，但前提是你本身有能力。你对架构的判断力、对边界条件的敏感度、对代码质量的审美，这些决定了 AI 在你手里能发挥几成功力。