Cline + Cursor 组合拳：从代码清理到 Git 提交，我的标准化发布流程

这是「Cline 实战」系列第二篇。[上一篇]我讲了怎么用 Cline 接手祖传老项目，半天搞定清理冗余、更新依赖、补齐测试。这篇接上，讲怎么把项目跑起来之后，搭建一套能长期运转的标准化发布流程。

上回说到

上一篇里，我用 Cline 把一个停更一年多的 React 老项目盘活了——清理了 132 处未使用 import、修了 4 个高危漏洞、把测试覆盖率从 0 干到了 73%。

但项目能跑只是第一步。团队里其他人也要往里提交代码，总不能每次都靠我手动检查吧？万一有人提交了一段带 console.log 的代码、或者忘记跑测试就 push 了，之前的工作就白做了。

所以我决定搭一套标准化的发布流程，让每次提交都自动走一遍：代码规范检查 → 自动修复 → 单元测试 → 构建 → Git 提交。

工具组合：Cline + Cursor。

为啥是 Cline + Cursor

先说下这两个的关系。Cursor 是一个基于 VS Code 内核的 AI 编辑器，Cline 是一个 VS Code 插件。因为 Cursor 兼容 VS Code 插件生态，所以 Cline 可以直接装在 Cursor 里用。

两者的分工：

简单说：Cursor 负责写，Cline 负责查和跑。

为啥不直接用 Cursor 的 Agent 模式？因为 Cline 有两个优势：

1. Plan/Act 模式——先出计划再执行，每步可控
2. 终端集成——能直接跑 npm test、git commit，不用切到终端手动敲

环境配置

在 Cursor 里装 Cline

1. 打开 Cursor，Ctrl+Shift+X 打开扩展市场
2. 搜 "Cline"，安装
3. 左侧栏出现 Cline 图标，点开配置 API

配置 .clinerules

上一篇文章里我建了一个 .clinerules 文件。这次我在里面加了发布流程相关的规范：

# 项目规范

## 编码约定
- TypeScript strict mode，禁止 any
- 组件用函数式 + hooks
- 删除所有 console.log
- 提交信息用 conventional commits 格式

## 发布流程规范
- 提交前必须通过 eslint，0 error 0 warning
- 提交前必须通过 vitest，所有测试用例通过
- 提交前必须通过 tsc 类型检查
- commit message 格式：type(scope): description
- type 可选：feat | fix | refactor | test | docs | chore | style | perf
- scope 用模块名，如 auth | ui | api
- description 用中文，不超过 50 字

## 禁止事项
- 不要直接 push 到 main 分支
- 不要跳过测试提交
- 不要提交 node_modules
- 不要在代码里留 console.log

配置 Auto-approve

在 Cline 设置里找到 Auto-approve，我选了中等级别：

• 自动批准：读文件、eslint、vitest、tsc、git status、git diff
• 手动确认：写文件、git add、git commit、git push

这样安全命令自动跑，涉及代码修改和 Git 操作的还需要我确认。

第一步：代码规范检查 + 自动修复

每次写完代码，我会让 Cline 跑一遍规范检查：

检查当前工作区的代码规范：
1. 跑 eslint，报告所有 error 和 warning
2. 跑 tsc --noEmit，检查类型错误
3. 扫描是否有 console.log
4. 检查 import 是否都使用了
5. 能自动修复的先修了，不能修的列出来

Cline 的执行流程：

实操中遇到的情况举几个例子：

eslint 报了个 react-hooks/exhaustive-deps 的 warning，Cline 定位到是 useEffect 的依赖数组少了个变量。它先分析这个变量加进依赖后会不会触发无限重渲染，确认安全后修了。

tsc 报了个类型不匹配，有个函数返回 string | undefined，但调用方直接当 string 用了。Cline 加了可选链 ?. 和空值处理。

整个检查+修复过程，大概 3-5 分钟，基本不用我插手。

第二步：跑单元测试

规范检查过了，下一步跑测试：

运行 vitest，报告结果。
如果有失败的用例，分析原因并修复。

Cline 直接在终端里跑 npx vitest run，拿到输出后分析：

有一次比较典型的场景：我改了个 API 响应的数据结构，从 { data: T } 变成了 { data: T, meta: PaginationMeta }，结果 3 个测试用例挂了。

Cline 的处理过程：

1. 读失败的测试，发现断言的是 response.data.length
2. 检查源代码，确认新的返回结构里 data 字段还在，类型没变
3. 分析后发现是 mock 数据的问题——测试 mock 返回的是旧的格式
4. 更新了 3 个 mock，重跑测试，全绿

这种事以前得自己一个文件一个文件翻，现在 Cline 沿着调用链一路追踪，几分钟定位。

第三步：Git 提交自动化

代码干净了，测试也过了，最后一步是 Git 提交。

帮我提交当前改动：
1. 先看 git status 和 git diff，确认改动范围
2. 根据 .clinerules 里的规范生成 commit message
3. 执行 git add 和 git commit
4. 不要 push，等我确认

Cline 执行的流程：

举几个实际生成的 commit message：

feat(auth): 新增记住密码功能，用 localStorage 缓存用户名

fix(ui): 修复表格在空数据时高度塌陷的问题

refactor(api): 提取公共请求拦截器，统一错误处理逻辑

test(hooks): 补充 useAuth hook 的边界测试用例

chore(deps): 升级 react-router 到 6.26.0，修复安全漏洞

说实话，commit message 写得比我手动敲规范多了。以前我经常就写个 "fix bug" 或 "update code"，被同事吐槽过好几次。

把流程串起来：一键执行

三个步骤单独跑还行，但每次手动输入三段指令也烦。Cline 支持把一串指令写成一个 prompt，跑一次搞定。

我在项目根目录建了个 .cline/prompts/release.md：

# 发布前检查

请按顺序执行以下步骤，每一步通过后再执行下一步：

## 1. 代码规范检查
- 跑 `npx eslint src/ --max-warnings 0`
- 跑 `npx tsc --noEmit`
- 扫描并删除所有 console.log
- 清理未使用的 import
- 有问题就修，修不了停下来报告

## 2. 运行单元测试
- 跑 `npx vitest run`
- 失败的用例分析原因并修复
- 全部通过后继续

## 3. Git 提交
- 跑 `git status` 和 `git diff --stat` 查看改动
- 根据 .clinerules 规范生成 commit message
- 执行 `git add -A` 和 `git commit`
- 不要 push

## 输出
最后给我一个汇总：
- eslint 检查结果
- 测试用例数和通过率
- commit message
- 改动文件数

这样每次写完代码，直接在 Cline 里 @ 引用这个文件，一句话触发整个流程：

@release.md 执行发布前检查

完整的流程长这样：

实际跑下来，从触发到完成提交，大概 5-8 分钟。改动小的话 3 分钟就搞定。

汇总报告长这样

Cline 跑完会给你一个汇总：

========== 发布前检查报告 ==========

【规范检查】
- eslint: ✅ 0 error, 0 warning
- tsc: ✅ 类型检查通过
- console.log: ✅ 已清理 0 处
- 未使用 import: ✅ 已清理 2 处

【单元测试】
- 测试文件: 24 个
- 测试用例: 87 个
- 通过: 87 / 87
- 覆盖率: 74.2%

【Git 提交】
- commit: feat(auth): 新增记住密码功能，用 localStorage 缓存用户名
- 改动文件: 6 个
- 新增: 92 行
- 删除: 15 行

====================================
✅ 全部通过，可以推送了

看到这个报告心里就踏实了——代码规范没问题，测试全绿，提交信息也符合规范。

成本和效率对比

用了一个月，统计了一下：

一个月花十来刀，换来的是每次提交都有保障。比出线上事故后修锅便宜多了。

实际用了一个月后的评价

好的地方

1. 流程真的标准化了

以前靠自觉——"记得跑 lint"、"记得跑测试"。现在是 Cline 帮你跑，跑不过去就不让你提交。.clinerules 随 Git 走，团队所有人拉代码后 Cline 自动遵守同样规范。

2. 省了大量重复劳动

eslint 自动修复、测试失败自动分析、commit message 自动生成，这三件事以前每天得花半小时手动处理。现在 Cline 一键搞定，我只需要在最后确认一下。

3. Plan 模式特别适合复杂改动

有次要重构整个 API 层，涉及 20 多个文件。Plan 模式先出了完整的改动方案，我审查后确认没问题才切 Act 模式执行。要是直接让 AI 改，大概率得改出一堆 bug。

需要注意的地方

1. Auto-approve 别开太猛

一开始我开了激进模式（读写文件 + 所有命令自动批准），结果有次 Cline 改错了文件没注意到。后来调成中等级别——安全命令自动跑，改文件和 Git 操作手动确认。建议新人先用保守模式。

2. 大任务要拆

一口气让 Cline 改 30 个文件，上下文窗口容易爆，后面就开始犯傻。建议每个任务控制在 5-8 个文件以内，完事就 /newtask 开新对话。

3. 模型别省错了

一开始我省钱，全程用 DeepSeek。跑 eslint 修复没问题，但分析测试失败原因时明显不如 Claude Sonnet——经常找不到根因，改了表面问题过一阵又冒出来。后来把模型分级：简单任务 DeepSeek，复杂任务 Claude Sonnet，成本没涨多少，质量好很多。

4. .clinerules 要持续维护

项目演进过程中，规范会变。比如我们后来从 Redux 迁移到了 Zustand，.clinerules 里就得更新。建议把 .clinerules 当成活文档，跟代码一起维护。

和其他工具的对比

我的结论是：Cline 做本地发布前检查，GitHub Actions 做远端 CI/CD，两者配合。 Cline 在提交前就把问题拦住了，推上去之后 Actions 再跑一遍兜底。

两篇文章总结

两篇文章串起来，就是一个完整的 Cline 使用路径：

第一步（第一篇）：用 Cline 把老项目盘活——清理、修依赖、补测试
第二步（第二篇）：用 Cline + Cursor 搭建标准化发布流程，长期运转

Cline 这工具，说实话，刚上手的时候觉得"不就是个聊天插件嘛"。但真正用熟了之后，Plan/Act 模式、终端自动化、.clinerules 这三板斧配合起来，确实是能改变工作习惯的东西。

不是说要完全依赖 AI，而是把那些重复的、机械的活儿交给它，自己专注在业务逻辑和架构设计上。工具再好也只是工具，但好的工具能让你少加班。

如果觉得有用，点个在看转发给同事。有问题评论区聊，我会回复。