Cline + Cursor 组合拳：从代码清理到 Git 提交，标准化发布流程
这是「Cline 实战」系列第二篇。上一篇我们介绍了如何借助 Cline 接手祖传老项目，仅用半天便完成冗余清理、依赖更新与测试补齐。本篇继续深入，探讨项目跑通后，如何搭建一套可持续运转的标准化发布流程，让每次代码提交都自动执行规范检查、测试与 Git 提交。
上回回顾
在第一篇文章中，我们利用 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 | 代码补全、Tab 补全、内联编辑、快速重构 | 日常编码 |
| Cline | 多步骤任务规划、终端命令执行、文件批量操作、自动化流程 | 标准化流程执行 |
简单来说：Cursor 负责写代码，Cline 负责检查和执行。
为什么不直接用 Cursor 的 Agent 模式？因为 Cline 具备两大优势：
- Plan/Act 模式——先制定计划再执行，每一步都可控
- 终端集成——能直接运行
npm test、git commit，无需手动切换到终端
环境配置
在 Cursor 中安装 Cline
- 打开 Cursor，按
Ctrl+Shift+X进入扩展市场 - 搜索 "Cline"，点击安装
- 左侧栏出现 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 的处理过程：
- 读取失败的测试，发现断言的是
response.data.length - 检查源代码，确认新的返回结构中
data字段仍在，类型未变 - 分析后发现是 mock 数据的问题——测试 mock 返回的是旧格式
- 更新了 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 |
每月花十来美元，换来的是每次提交都有保障。这比线上出事故后再修复划算得多。
实际使用一个月后的评价
优点
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 | 开源免费、每步可控、终端集成强 | 需要自己配置流程 |
| Cursor Agent | 集成度高、Tab 补全流畅 | 闭源收费、自动化流程较弱 |
| GitHub Actions | 真正的 CI/CD、团队级 | 门槛高、反馈较慢 |
结论是：Cline 做本地发布前检查，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，而是把那些重复、机械的活交给它，自己专注于业务逻辑和架构设计。工具再好也只是工具，但好的工具能帮你少加班。