两个人、六周、从零到上线——AI 编程工具把效率顶上去的同时，也差点把项目带进坑。最开始的用法很粗放：需求往对话里一贴，AI 生成什么用什么，结果代码风格混乱、接口没有校验、迁移脚本差点把测试库清掉。后来定下”AI 写模板、人管业务”的分工，配规则文件、拆小步、强制 review，效率才真正稳住。这篇把 Cursor 和 Claude Code 的具体用法、规则约束和踩坑记录完整写下来。
一、整体策略
- 用 AI 写”重复、模板、明确”的代码；
- 用 AI 解释”陌生、复杂”的代码；
- 不让 AI 决定”业务规则、付费逻辑、关键迁移”；
- 强制 diff review 与单测。
这条策略的边界，是我们吃过亏才划出来的。项目第二周让 AI 直接写了计费模块的初版，它按自己想象的逻辑把免费额度设计得严丝合缝，实际运营规则完全对不上，返工成本比手写还高。从那以后，”业务规则”四个字不进 AI 的输入框，它只负责实现我们写清楚的东西。
二、规则文件
把项目约定写进 .cursorrules：
- 全部代码用 TypeScript，strict 模式。
- 文件命名用 kebab-case。
- 公共组件按 features 划分。
- API 必须有 Zod 校验。
- 不写 console.log。
- 不使用 any。这段文件解决的是”AI 每次生成的风格都对不上项目”的问题。没有它的时候，AI 一会儿写 default 导出、一会儿写命名导出，类型到处是 any，review 的精力全耗在风格上。规则写清楚之后，第一次生成的代码就能过八成，省下大量返工时间。
每次会话第一轮对话让 AI 重读这份规则。
三、任务拆分
把任务拆成 1–2 步的小块，喂给 AI：
- 第一步：写 Prisma schema 增量；
- 第二步：生成 zod schema；
- 第三步：写迁移脚本。
每步结束都让 AI 总结 diff，我手动 review 后再进下一步。
拆小步不是因为 AI 处理不了大任务，而是大任务的输出没法 review。有一次让 AI 一口气改完整个数据模型，出来的 diff 几百行，我根本看不过来，还埋了一个外键方向反掉的 bug。拆成三步之后，每步 diff 控制在几十行，问题当场就能发现。
四、典型场景
4.1 创建新接口
让 AI 写 Next.js Route Handler，提示词里把约束说清楚：
请用 TypeScript 写 POST /api/translation-jobs：
- 鉴权用 auth()；
- 入参用 Zod 校验：{ repositoryId, targetLang, modelKey };
- 调用 createTranslationJob；
- 错误用统一的 ApiError 抛出。这个提示词模板反复用了十几次，效果稳定。秘诀在于把”用什么函数、校验什么字段、抛什么错误”都点名，AI 不需要猜项目约定，生成结果基本一次成型。
AI 写完后我手动：
- 补单测；
- 校验错误码；
- 检查参数注入风险。
4.2 写 React 组件
组件类任务同样给足约束再让 AI 动手：
请写一个 <RepoPicker> 组件：
- props: installations, onPick;
- 列表渲染仓库，支持搜索；
- 用 shadcn/ui Command 组件；
- 选完触发 onPick(repo)。完成后我跑 Playwright 视觉回归。
4.3 解释已有代码
把老代码贴进去让 AI 生成注释与依赖图，省下读代码时间。
这一步的价值被低估了。接手一个遗留的同步脚本时，我贴进去让 AI 画调用关系，十分钟就搞清了主链路，自己读大概要一小时。用来理解代码的对话和用来写代码的对话建议分开，上下文干净，回答质量也更高。
五、Cursor 与 Claude Code 的分工
两个工具我们同时在用，一开始也纠结过选哪个。用了几周之后发现这不是二选一，而是按任务类型分流：
| 工具 | 适合 |
|---|---|
| Cursor | IDE 内多文件改写、补全 |
| Claude Code | 终端长任务、跨文件上下文 |
举例：
- 写 SQL：Cursor；
- 跑数据库迁移并修：Claude Code；
- 写单元测试：Cursor；
- 复盘整个错误链路：Claude Code。
判断标准很简单：需要我盯着编辑器逐行确认的，用 Cursor；需要它自己跑命令、追日志、跨十几个文件来回折腾的，交给 Claude Code。选错工具浪费的时间，比工具本身的差距还大。
六、与 CI 的协作
- AI 提交前必须跑过 lint、typecheck、test；
- CI 不通过时让 AI 分析日志并修复，但要核对 diff；
- 不让 AI 自动合 PR。
CI 是我们给 AI 设的安全网。最开始我们跳过 lint 直接提交，AI 生成的代码能跑但格式一团糟，后来把”提交前必须跑通本地检查”写进规则，这个坑就没了。CI 红了就让 AI 去修，它定位日志的速度确实快，但每次修完我都对照 diff 确认它没有顺手改别的文件。
七、提效的关键习惯
- 提示词开头写 “先做计划，再写代码”；
- 强制要求输出 diff 摘要；
- 写完让 AI 给自己提 3 个潜在 bug；
- 把高频 fix 写进 rules，避免重复。
“先做计划”这条最管用。让它先列实现步骤再动手，等于把思考过程暴露出来，方向不对当场就能叫停，不用等它写完一整段再返工。让 AI 自查 3 个 bug 的习惯，是从一次线上事故后养成的，那次它生成的分页查询漏了索引，慢查询打爆了数据库。
八、踩坑
- 上下文漂移：长对话后 AI 忘了早期规则，定期重发
.cursorrules； - 过度自信：AI 给出的”最优解”经常带偏见，必须看实际数据；
- 隐私：不要把生产数据库 dump 给 AI；
- 速率：AI 编辑大文件慢，提前用 sed 拆分。
四个坑里，隐私那条没有商量余地。我们内部明确：生产库数据、用户原文、私有密钥一律不进 AI 上下文，开发库脱敏之后才可以用。数据合规这件事，等出了问题再补救，代价大得多。
九、统计
- AI 生成的代码中 80% 一次通过；
- 20% 需要 1–2 轮修复；
- 不到 5% 需要推翻重写。
这个数字是六周里随手记的，不算严谨但能反映趋势：模板类和接口类代码一次通过率高，涉及既有代码改动的任务几乎总要返工。所以需要动老代码的活，我们默认预留修复轮次，不指望一次到位。
十、未来改进方向
- 把内部知识库接入 RAG；
- 让 AI 主动 review 老代码的潜在问题；
- 与 Playwright 联动，自动截图验证 UI。
优先做的是接入 RAG：现在每次会话都要人工重复项目背景，接上知识库之后，规则和架构说明可以少写一半。其次是让 AI 定期扫老代码，这块目前还是纯人工，耗时且容易漏。
十一、给同类项目的建议
- 把规则写进文件，而不是依赖人提醒；
- 大任务拆 1–2 步小块；
- AI 写的代码必须有单测；
- 不让 AI 决定业务规则与付费逻辑。
如果只记一条，我选”规则写进文件”。它是后面所有习惯的地基，没有它，提示词写得再细，下一轮会话照样回到解放前。
常见问题（FAQ）
Q1：Cursor 与 Claude Code 同时用会不会冲突？
不会。建议在 IDE 内用 Cursor，复杂任务切到 Claude Code。
Q2：AI 写的代码需要全部 review 吗？
涉及业务、权限、性能的必须 review；样板代码抽查即可。
Q3：怎么防止 AI 提交未审代码？
PR 模板要求勾选”已人工 review”才允许合并。
