AI Coding 工作流

Cursor、Claude Code 和 Kiro 三个工具不是替代关系，而是覆盖不同任务粒度。混用之前先把"什么时候用哪个"搞清楚，才能避免来回切换却没有提效。

本章假设你已经装过其中至少一个。如果还没动手，先去 Vibe Coding · 安装 Cursor 和 Claude Code 完整指南 跑通基础流程，再回来看团队协同部分。

三种工具的真实定位

实际工作里这三个不冲突。Cursor 适合写代码时手感最快；Claude Code 适合"帮我把这个 bug 在三个 service 里都改掉"；Kiro 适合接一个新 feature ticket 时先把 spec 钉死再让 AI 实现。

选哪个看任务粒度

• 改 1 行 / 1 个函数 → Cursor inline edit (Cmd+K)，比开会话快
• 改 1 个文件内逻辑 → Cursor chat panel，引用同文件即可
• 跨 5+ 文件 / 跑 test 验证 → Claude Code，写一个 prompt 让它自己跑 bun test 验证
• 新 feature 从 0 到 1 → Kiro 写 spec → 让 Claude Code 按 spec 实现 → Cursor 收尾微调
• debug 生产事故 → Claude Code，因为它能直接执行 kubectl logs / psql 这类命令链路

把它们组合起来：典型一天

# 早上：Kiro 把今天的 ticket 拆成 spec
kiro spec create "add rate limit to /api/upload"
# → 产出 spec.md + tasks.md

# 上午：Claude Code 按 spec 跑实现
claude
> implement tasks.md step by step, run tests after each step

# 下午：Cursor 微调 UI 细节
# Cmd+K "把这个 toast 改成 styled-components"

# 晚上：Claude Code 写 PR description + changelog
> generate PR title and body from git diff main...HEAD

关键点：不要在一个任务中途切工具。每切一次都要重新喂 context，纯浪费 token。

量化提效（不是"AI 真快"）

老板/team lead 不关心你"用了 AI 感觉很爽"，他们看数字。建立这 4 个指标：

1. PR 周期时间 - 从 ticket open 到 merge 的 hours，对比引入 AI 前后 30 天平均
2. 首次 review 通过率 - 一次过 vs 需要修改的 PR 比例
3. Bug 引入率 - 每周 PR 数 / 每周新 bug 数
4. token 成本 - Cursor Pro $20/月、Claude Code 按 API 计费、Kiro 免费/付费 tier，记录每月 per-engineer 成本

JR Academy 内部数据：引入 Claude Code 后 PR 周期从 2.3 天降到 1.1 天，但 review 通过率第一个月反而降了（因为 AI 写得多但 reviewer 没跟上），第二个月才恢复。这个滞后是真实的，团队推广要预留磨合期。

团队推广常见的坑

• 没有共享 CLAUDE.md - 每个工程师的 AI 写出的代码风格各异，CR 成本激增。把项目级 CLAUDE.md commit 进 repo
• AI 写完没人读 - PR 巨大、reviewer 直接 approve，三个月后没人看得懂这块代码。强制 PR 上限（比如 +400/-200 行）
• token 成本失控 - Claude Code 默认开 Sonnet 4.5，长 session 一天烧 $30+。设置 budget alert，复杂任务才用 Opus
• 不写 test 的 AI 代码 - 让 AI 写实现的同时必须写 test，否则下次让 AI 改这段代码就开始破坏行为
• Skills/Commands 不共享 - 个人工作流提效 ≠ 团队提效。把高频 skill 提到 repo 级 .claude/skills/

下一步

• Vibe Coding 实战 — 自然语言驱动开发的 quality gate 设计
• AI Rules 配置实战 — .cursorrules / CLAUDE.md / Skills 三种格式的分工
• Claude Code Context Management — 长任务里控制 token 成本