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

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

---

上回说到

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

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

所以决定搭一套标准化的发布流程，让每次提交都自动走一遍：

。

工具组合：

。

---

为啥是 Cline + Cursor

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

两者的分工：

工具	擅长什么	在流程里的角色
Cursor	代码补全、Tab 补全、内联编辑、快速重构	日常写代码
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 的执行流程：

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

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

，有个函数返回 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 行

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

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

---

成本和效率对比

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

指标	以前手动流程	Cline 自动化
单次发布前检查耗时	15-20 分钟	5-8 分钟
遗漏的 eslint 问题	偶尔有（3-4 次/月）	基本为 0
忘记跑测试就提交	1-2 次/月	0
commit message 不规范	经常	0
月度 API 花费	-	~$8-12

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

---

实际用了一个月后的评价

好的地方

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

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

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

需要注意的地方

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

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

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

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

和其他工具的对比

工具	优势	劣势
Cline	开源免费、每步可控、终端集成强	需要自己配置流程
Cursor Agent	集成度高、Tab 补全爽	闭源收费、自动化流程弱
GitHub Actions	真正的 CI/CD、团队级	门槛高、反馈慢

结论是：

Cline 在提交前就把问题拦住了，推上去之后 Actions 再跑一遍兜底。

---

两篇文章总结

	第一篇	第二篇
场景	接手祖传老项目	日常标准化发布
核心流程	清理冗余 → 更新依赖 → 补测试	规范检查 → 跑测试 → Git 提交
关键能力	Plan/Act 模式、AST 分析	终端自动化、.clinerules、Auto-approve
耗时	~2.5 小时	每次 5-8 分钟
花费	~$2.85	月度 ~$10

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

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

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

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