一线生产项目，95% 代码让 AI 写——Cursor + Claude Opus 4.6，15 天 10 万行，烧了 2 万块

一、先说我是谁

我是小隐，一个9年中厂Java后端，也从小厂、大厂、中厂都待过了，工程级经验也是拉的比较满了。

23年刚入的生财，24 年初开始关注 AI，也同时在web3搞了一段时间"科学家"，自己也折腾了个 AI 相关的 Web 出海产品。在此之前日常开发一直是"AI 辅助写 + 人工全量 Code Review"的模式，工作上的代码基本80%-90%都是自己写的，AI的占比很少。

也就是最近一个月，生产级的深入体验，变成了90%代码都是AI，我自己占比10%。同时也因为网传 网易因为AI实验成功，裁了很多外包；但我司不是网传，在我们封闭第二周后（AI Coding初见成效），研发的外包确实是一次性裁完了。

二、项目背景

之前生产上，其实AI真实coding，效果过浅，主要我们代码库多、代码行数也多、逻辑也复杂，所以一直没大批量使用。AI 写的代码你不 review 不敢用，review 完又觉得还不如自己写来得快。一直也在"用了，但没完全用"的状态。

也是25年11月后，感受AI编程好像有不少突破，我开始尝试整个工程给到Gemini 3.0 Pro它去理解和梳理老逻辑，才发现效果确实显著，至少在代码理解上。

2月底，接到老大通知："加入小黑屋用AI从0实现，之前的新APP项目"。（之前的新APP项目，总估时都100人日），我内心也是超级懵逼的、拒绝的。

需求何其重：用户体系、即时通信、会话管理、内容审核、支付钱包、推送通知、活动系统、任务系统、发现页……零零散散加起来 20 多个业务模块。

说实话，项目启动那会儿，不少同事是持保留态度的。"AI 写的代码能上生产？""不 review 你敢部署？"这种声音不少。我自己也是懵的、破罐破摔的，项目组刚开始的一周都是我在公司7年最想离职的时间。

但最后的结果，其实确实超出预期！

维度

数据

开发周期

15 个工作日

工具

Cursor + Claude Opus 4.6

AI 代码占比

~95%

代码规模

10 万行+，674 个文件

Git 提交

199 次

业务模块

20+（用户/支付/会话/活动/推送/任务等）

Token 费用

~2 万元人民币

PS：cursor月度积费，刚发现重新计费了😢

三、整体工作流

我们项目组也配置齐全——产品、设计、测试、后端、客户端都有，不过本来最重的研发，只有1个后端，1个客户端，而其他的有3产品3设计3测试。

直接上对比图，左边是传统流程，右边是我们实际跑通的 AI 流程：

看起来步骤数差不多，但实际跑起来有两个关键区别。

区别一：砍了需求评审和人工设计方案，AI Leader 一小时搞定需求对齐

我们研发就 2 个人，对面 3 产品 3 设计 3 测试。需求变得比翻脸还快，传统"评审会→设计稿→定接口→排期"的串行流程根本跟不上。

所以砍掉评审会，需求来了直接进 AI Leader 模式对齐。AI 会针对异常处理、状态流转、边界情况疯狂提问——不少问题我自己都没想到。

以前开发流程中耗时的点很多，现在核心耗时的点就是 AI Leader 的需求对齐，方案对齐，开发+自测等等AI自行完全就覆盖了。

区别二：AI 用例逐条逻辑校验——大部分 bug 是它发现的

这一步是整个流程里我觉得 ROI 最高的环节。

这一步分两个阶段。

第一阶段：测试 + 产品一起人工过用例。

联调完之后，测试和产品拿着测试用例对照需求文档一条条过。这一步的核心价值不是"跑通没跑通"，而是补齐需求文档里的细节和边界。AI 实现的时候往往只关注了大体功能，很多细节——比如"这个状态在这种特殊场景下该怎么表现"——需求文档里可能一笔带过了，AI 就真的一笔带过了。测试和产品是最懂业务细节的人，这一轮他们能把遗漏的边界补上。

第二阶段：AI 用例逐条逻辑校验。

人工过完之后，我把测试同学的测试用例和研发侧的全量代码一起喂给 AI，让它逐条对照做逻辑校验。

用例是测试写的，代码是研发写的——两份东西独立产出，各有各的理解偏差。AI 拿到两边的产物做交叉比对，比任何单方自检都有效。

举个真实的例子：

有一条用例是"用户余额不足时下单应该返回失败"。测试跑过了，绿的。但 AI 逻辑校验的时候发现：这个用例传的余额是 0，确实会走到余额不足的分支。但如果余额是正数但小于商品价格呢？代码里这个分支根本没有用例覆盖。

跑测试只能告诉你"用例过了还是没过"。AI 能告诉你**"这个用例虽然过了，但它没测到你以为它测到的那个场景"**。

实际效果：大部分逻辑问题在这一步被 AI 拦下来了。人工测试更多是验交互体验——点击流畅不流畅、页面显示对不对、用起来顺不顺手。代码层面的 bug，基本在 AI 这一轮就被清得差不多了。

这套链路能跑通，核心靠一套东西：Rules 规则文件 + Docs 方案文档，配合 Leader-Worker-Judge 角色切换。

四、Rules 体系——AI 的"员工手册"和"项目文档库"

先回答一个很多人会问的问题：95% 代码 AI 写的，不做 Code Review，你怎么敢上生产？

答案是：我把 Code Review 该关注的东西，提前写成了规则文件，让 AI 写代码的时候就遵守。不是事后检查，是事前约束。

Cursor 有个功能叫 .cursor/rules/（Claude Code 也有个 .claude/rules/），放进去的规则文件 AI 每次开新对话都会自动加载。打个比方——入职第一天 leader 发的那本《开发规范手册》，人可能翻两页就扔了，但 AI 每次都从头读一遍，而且读了就照做。

原来我们项目就只有代码，现在还会额外加上AI用，完整"知识库"长这样：

文件

类型

管什么

设计原则

Rules

代码架构如何设计：禁令红线 + 自检清单 + 传统工程原则（单一职责、开闭原则、幂等、防御性编程等）

项目架构

代码放在哪：域边界表 + 数据访问分层

编码规范

代码写成啥样：命名、注入方式、异常处理、日志规范

开发流程

什么阶段做什么：Leader-Worker-Judge 角色定义 + 测试规范

docs/plans/

文档

设计方案：Leader 阶段产出，Worker 阶段参照，AI 随时可查

4 份 Rules 加起来 近千行。写 Rules 最核心的一条经验：多写"禁止"，少写"建议"。 AI 跟新员工一样，正面引导它选择性接收，明确红线它死守。而且规则不是第一天就完善的，有些是你本项目强相关的规则，需要一步步补充，每踩一次坑加一条。规则是长出来的，不是设计出来的。

光看表格可能还比较抽象，我展开说说几份关键 Rules 里到底写了什么。

4 份 Rules 里写了什么

设计原则——红线禁令 + 传统工程原则 + 自检清单

这是整套体系里信息密度最高的一份。分成 4 条红线（违反即不通过）和 9 条重要原则。

Part 1：4 条红线——AI 最容易犯的 4 类结构性错误

红线

一句话

AI 不写这条会怎样

逻辑收口

同一职责只有一个归属，禁止相同逻辑多处各写一份

比如"发放奖励"可能很多功能模块都有，AI 最爱干的事就是在每个功能里重写一遍"发放奖励"逻辑，项目里同一个功能出现 3 份实现

复用优先

新增代码前必须搜索已有逻辑，禁止复制-粘贴-微调

不写这条，AI 100% 在新模块里复制粘贴旧代码，改两个参数就当"新实现"

禁止循环依赖

模块间依赖必须是 DAG，新增依赖时递归展开至少 3 跳验证

AI 经常写出 A→B→C→A 的环，单测 mock 了不报错，一上生产就出事

禁止魔法值

所有业务语义值用枚举/常量，禁止硬编码字符串和数字

不写这条，AI 到处写 "active" "completed" "event_reward" 这种裸字符串

循环依赖这条，不光是一句"禁止"，还给了 AI 可执行的检查算法——新增跨域依赖时，递归展开目标 Service 的全部 Service 依赖，至少查到第 3 跳或确认到叶子节点。并且明确告诉 AI：Mockito @InjectMocks 不经过 Spring 容器，单测全绿不能作为无循环依赖的证据。 这是真实踩过的坑。

Part 2：9 条重要原则——传统软件工程的"显式教学"

这一块特别想说说。幂等性、防御性编程、开闭原则……这些东西你写了几年代码早融进经验了，但 AI 没有"经验"，或者说它不一定每次记得起来。你不显式告诉它，它就真的不做。

原则

写进 Rules 的要点

为什么 AI 必须被告知

幂等性

所有状态变更操作必须做幂等保护：唯一键约束 + DuplicateKeyException，或先查后写 + 状态判断

AI 默认写"裸 insert"，不加任何防重，重复调用就重复写数据

防御性编程

在模块/方法入口处做参数校验和前置条件检查，内部逻辑假设入参合法

AI 不校验入参，空值传到第 5 层才 NPE，排查半小时

副作用可预测

方法名必须体现写操作——get/find 禁止包含写操作，写操作用 add/update/create/claim

AI 喜欢在 calculateXxx() 方法里偷偷写数据库，调用方根本不知道

优雅降级

非核心外部依赖（推送、日志上报、异步任务触发）失败时 catch + 降级，不打挂主流程

AI 默认让所有异常向上传播，推送服务挂了整个下单接口 500

可测试性

用构造器注入，纯计算逻辑抽成无副作用方法，避免方法内部 new 依赖对象

AI 经常在方法里 new RestTemplate()，单测没法 mock

日志有效性

状态变更必须 log，异常路径必须 log，循环内禁止高频 log.info

AI 要么不打日志，要么循环里每条都 info，日志量爆炸

开闭原则

分支 ≥3 且有增长趋势才引入策略/工厂模式；只有 1-2 个分支不要提前抽象

AI 特别爱过度设计——只有一个实现就搞接口 + 抽象类 + 工厂，也会在该用模式时不用

模块化设计

复杂业务拆成边界清晰、可独立演进的模块，跨模块有业务逻辑的操作必须走 Service

AI 不分边界，一个类 800 行什么都干

设计模式使用

问题驱动，先有问题再匹配模式；if-else ≤2 时不硬套模式

AI 用起模式来没有"度"，需要明确的判定标准

Part 3：自检清单——每个新功能前自动过一遍

#

自检项

不通过的信号

1

这个逻辑项目里是否已有？

搜到类似方法 → 复用，不另写

2

状态变更是否幂等？

有写操作且无唯一约束 → 加防重

3

方法名是否体现真实行为？

名叫 getXxx 但内部有写数据库 → 改名

4

外部依赖挂了会怎样？

非核心依赖异常向上传播 → 加降级

5

有没有硬编码的魔法值？

字符串/数字裸写 → 提取枚举或常量

6

新增模块依赖是否会成环？

递归展开至少 3 跳验证

7

分支 ≥3 且会继续增长？

是 → 考虑策略模式；否 → 保持简单

7 条自检 = 红线 + 重要原则的浓缩版。AI 每次写新功能前过一遍，等于在"动手前先想 30 秒"。

Part 4：禁令写法——这种格式对 AI 特别有效

代码块
Plain Text
复制
❌ 禁止用 @Lazy 注解掩盖循环依赖（治标不治本，运行时仍有隐患）
❌ 禁止仅检查一跳直接依赖就声称"无循环依赖风险"
❌ 禁止 get/find 方法包含写操作（调用方不知道有副作用）
❌ 禁止在循环体内高频打 log.info（用 log.debug 或循环外汇总）
❌ 禁止猜测式扩展（"以后可能会加"但只有一种实现 → 不提前抽象）

每条禁令背后都有一个真实踩过的坑。AI 对正面"建议"选择性接收，但对明确"禁止"几乎 100% 遵守。规则越像"法条"，AI 执行力越强。

项目架构——域边界表 + 数据访问分层

这份文件管的是"代码放在哪"。核心是两样东西：

第一，域边界表。 20 多个域全列出来，每个域写清楚入口 Service 和 DAO：

代码块
Plain Text
复制
| 域 | 核心 Service | 数据层 | 备注 |
|-----------|---------------------|------------------------------|-------------------|
| 用户 | UserService | UserDao, UserProfileDao | |
| 认证 | AuthService | — | 登录注册、验证码 |
| 订单 | OrderService | OrderDao, OrderItemDao | |
| 支付 | PaymentService | PaymentRecordDao, WalletDao | 扣款走统一 Service |
| 商品 | ProductService | ProductDao, SkuDao | |
| 消息 | MessageService | SessionDao, MessageDao | DAO 可被外部域直接读 |
| 活动 | ActivityService | ActivityProgressDao, ... | 策略模式 |
| 通知 | NotifyService | NotifyRecordDao | 推送通知 |
| ... | ... | ... | |

没这张表，AI 经常做出这种事：在活动模块里直接操作用户数据库、把推送逻辑写到订单 Service 里。有了这张表，AI 写代码前先查——"这个功能归谁管？数据找谁要？"，还有重要的也是让AI快速检索和了解项目功能构成和对应入口，这样更有利于AI渐进式披露的获取相关的上下文。

第二，数据访问分层。 这其实就是 Spring MVC 经典分层架构的延伸——做 Java 后端的同学都熟悉 Controller → Service → DAO 三层，但光知道三层是不够的，你得告诉 AI 每一层的"规矩"。人写了几年代码，知道 Controller 不该写业务逻辑、Service 之间该怎么调用——这些"默认常识"AI 不具备，必须显式写出来。

代码块
Plain Text
复制

这里面有两个关键设计：

一是 Repository 作为叶子节点。传统三层架构里 Service 互相调用容易成环（A 调 B，B 又调 A）。我加了一个约束：Repository 只能调 DAO，不能调任何 Service——这样任何 Service 都可以安全依赖 Repository 而不会成环。传统 DDD 里就有这个思路，只是很多团队嫌麻烦不落地，但对 AI 来说，规则越明确它越好执行。

二是"编排 Service vs 领域 Service"的区分。AI 最容易犯的错误之一就是在一个 Service 里把跨域逻辑和本域逻辑混在一起，越写越膨胀。告诉它"编排只做组装调用，领域只管本域逻辑"，代码立刻变清爽。

这里想多说一句：很多人觉得"AI 编程时代传统架构经验没用了"。我的体会恰好相反——传统软件工程的分层思想、设计原则，在 AI 开发时代反而更重要了。 因为人可以凭直觉把代码放对地方，AI 不行。你的架构经验越扎实，写出来的 Rules 就越精准，AI 产出的代码质量就越高。经验不是被替代了，是换了一种方式发挥价值——从"自己写好代码"变成"教 AI 写好代码"。

编码规范——统一风格，让 5 个 AI 写出一个人的代码

这份文件管的是"代码写成啥样"。在多个 AI 对话并行写代码的场景下，这份规范是风格一致性的保障。核心内容：

• • 依赖注入——用构造器注入（@RequiredArgsConstructor），禁止 @Autowired 字段注入。这不只是风格问题，构造器注入让依赖关系显式化，单测可以直接 new，不需要启动 Spring 容器。
• • 异常处理——业务异常统一抛自定义异常（配合错误码枚举），全局异常处理器兜底。Controller 里禁止 try-catch 包装返回值——这条不写的话，AI 特别喜欢在每个 Controller 方法里写 try-catch。
• • 返回值——Controller 统一返回包装对象 Result<T>，不返回裸对象。
• • 日志——@Slf4j 注解统一日志框架，禁止 e.printStackTrace()。状态变更用 info，异常路径用 error（必须带异常对象），循环内只许 debug。
• • 安全——SQL 参数化查询，MyBatis 用 #{} 不用 ${}；日志中禁止输出密码、token、完整手机号。

看着都是基础的东西对吧？但如果不写进 Rules，5 个并行的 AI 对话会产出 5 种风格的异常处理、3 种日志写法、2 种注入方式。规范越基础，越需要写死。

开发流程——角色切换 + 测试规范 + BugFix 闭环

这份文件定义了 AI 在不同阶段该做什么、不该做什么，这个算是重中之重的了：

代码块
Plain Text
复制
# 开发工作流（简要）

这份文件还定义了测试分层规范——什么改动写什么测试：

改了什么

单元测试

API 集成测试

流程串联测试

Service 内部逻辑分支

✅ 必须

—

新增或修改 API 接口

多 API 交互流程

各 Service 单测

各接口测试

仅改工具类/枚举

Leader-Worker-Judge 实战——Rules 怎么配合工作

有了这些 Rules，具体怎么用？跟着三个角色走一遍就清楚了。

Leader 阶段——读规则、对齐需求、输出"施工图"

我说"分析需求"，AI 进入 Leader 模式。

开发流程 Rules 约束它：只许提问和确认，不许写一行代码。但 Leader 不只是读开发流程——它会同时加载设计原则（知道哪些是红线）、项目架构（知道现有的域和模块划分）、编码规范（知道技术栈约束）。带着这些"背景知识"来对齐需求，问出来的问题质量完全不一样。

AI 会针对异常处理、状态流转、边界情况疯狂提问。比如做支付模块时：

"充值和赠送的消费优先级是什么？"

"iOS 和 Android 的支付验证走统一逻辑还是分开？"

"退款的时候如果赠送已经花了怎么处理？"

有几个问题我自己都没想过。

讨论完，AI 输出一份详细的设计方案文档，存到 docs/plans/ 里。这份文档不是概要描述，而是一份真正的"施工图"，精确到可以直接照着写代码的程度：

方案文档包含什么

举个例子

核心决策表

"扩展模式用策略模式、进度检测用事件驱动、按日循环靠唯一索引自然实现"——把关键决策和理由写清楚

数据模型

每张表的字段名、类型、说明、索引定义——精确到哪几个字段组合做唯一索引，AI 照着建表不会出错

枚举定义

新增哪些枚举、放在哪个包下、每个枚举值的含义——禁止魔法值的前提是先把值定好

Service 架构

新增哪些类、每个类的职责、依赖关系图、接口方法签名——Worker 照着这张图搭骨架

API 定义

Controller 方法签名 + 请求/响应 DTO 字段定义，确认后锁定不改——这就是前后端协议

API 交互流程

"第一步调 xx 接口拿列表→第二步调 yy 接口提交"——前后端串联步骤写清楚

测试场景清单

正常流程 + 关键异常路径——AI基于此写API集成测试

这份文档不只是给人看的。后面 Worker 阶段、甚至新开一个会话，AI 都可以随时 read 这个文件回忆方案。 对话会忘，文件不会。

Worker 阶段——照施工图写代码 + 三层测试

我说"开始开发"，AI 切到 Worker 模式。开发流程 Rules 定义了严格的执行步骤：

第一步：搭骨架。 按方案文档的 API 定义，先创建 Controller → Service → DAO 的空壳。API 签名已在 Leader 阶段锁定，这一步不允许改接口。

第二步：逐个填充。 按方案文档逐个实现 Service 内部逻辑。每次只做一个功能点，做完就编译检查。

这时候前面展开说的那几份 Rules 全部生效：

• • 设计原则——每写一个新功能前，AI 自动过一遍前面那份自检清单（7 条），确认没有重复逻辑、幂等保护到位、没有魔法值
• • 项目架构——AI 查域边界表确认代码放哪个包，查数据访问分层确认该走 Service 还是直接用 DAO
• • 编码规范——命名风格、注入方式、异常处理全统一。5 个并行的 AI 对话产出的代码风格是一致的

第三步：写三层测试。 这一步也在 Worker 阶段完成，不是等后面才补：

层级

测什么

怎么跑

单个 Service 的业务分支

mvn test

单个接口的全链路（Controller→Service→真实数据库）

mvn test -Papi

多个接口按业务流程串联调用

同上

人开发的时候自测经常偷懒，但 AI 写测试成本低。我让它拉满，项目结束时测试代码比业务代码还多。

Cursor 支持同时开多个 Worker 对话，我单日最高 43 个对话、将近 5000 条消息，5 条线同时推不同模块。因为共享同一份 Rules，5 个 AI 产出的代码风格是一致的。

Judge 阶段——质量工具 + 测试验收

我说"review"，AI 切到 Judge 模式。按前面开发流程 Rules 里定义的检查清单逐项过——代码规范、安全检查、三层测试、接口一致性、静态检查、编译、数据库脚本同步，一个都不能少。

这里面有两个点特别想强调：

第一，静态检查工具的价值被严重低估了。 Checkstyle（代码风格）、PMD（编码规范）、CPD（重复代码检测）、SpotBugs（潜在 Bug）——一条命令扫全项目，比让 AI 逐文件审查快十倍还不花 token。而且扫出来的问题甩给 AI 改特别合适——格式调整、变量重命名、资源泄漏修复，人改起来烦得要死，AI 改起来简单。专业工具做基础扫描，AI 做精准修复，各干各擅长的。

第二，测试分层在 Judge 阶段体现价值。 单元测试跑得快能抓逻辑分支错误，但只有 API 集成测试（跑真实数据库容器，不 mock）才能抓到"数据库里真的写进去了吗"、"查出来的格式对不对"这种问题。前面测试分层规范里定义了"什么改动必须写什么测试"，Judge 阶段就是按那张表逐项验收。

铁律：证据先于结论。 必须跑测试看到绿色输出，不接受任何口头承诺"应该没问题"。

小结：Rules 是 AI 的"员工手册"——每次对话自动加载，永远不忘；docs/plans/ 是 AI 的"施工图"——Leader 产出、Worker 参照、Judge 对照验收。这套体系的核心不是某一份文件，是它们之间的配合。

这套规则你能直接抄多少

写到这儿你可能想问：你这套 Rules 我能直接用吗？

能用一部分。我按"换个项目要改多少"分成三层：

包含什么

换项目怎么办

通用层

Leader-Worker-Judge 流程、禁令清单、自检清单

直接复制，5 分钟，任何语言框架都适用

技术栈层

编码规范、工程原则、质量工具+测试分层

改改代码示例和工具配置，半小时

项目层

域边界表、配置项清单、业务枚举

必须根据自己项目写，没法复制

实操路径：

• • Day 1：通用层 + 技术栈层复制进 .cursor/rules/，5 分钟搞定。AI 的行为马上就会不一样。
• • 第一周：补项目层——先写 3-5 个核心域的边界表，不用一步到位。
• • 持续：每踩一次坑就加一条禁令。这是最有复利的事。

五、踩坑雷区

以下是我实际踩过的坑，每一个都是真金白银换来的教训。

坑 1：别第一天就搞微服务

Day 1 我搭了一套 Spring Cloud——5 个独立服务 + API 网关 + 注册中心。还挺自豪，这架构多"正规"。

当天晚上全推翻了，改成了单体多模块。

原因有两个。第一，项目初期单体架构完全够用，搞微服务纯属给自己找事。第二——这个更关键——AI coding 有个硬性前提：所有代码在一个项目里，本地能跑起来。

AI 需要看到完整的代码上下文才能写出靠谱的代码。拆成 5 个微服务之后，它写订单模块的时候看不到用户模块的代码，跨服务调用全靠猜。而且本地要同时跑 5 个服务 + 注册中心 + 网关，调试成本极高。

单体多模块就没这些问题——代码在一个项目里，AI 能看到全貌；本地一键启动，改了就能跑。架构上"够用"就好，但"所有代码在一起、本地能跑"是 AI 开发的刚需。

坑 2：一个窗口聊到底，不如勤开新窗口

最长一次对话 1800 条消息，到后面 AI 明显开始忘事——前面约定的命名不遵守了，方案细节也记不住了。这不是 bug，是上下文窗口的物理限制。

后来摸索出一个原则：新模块、新功能、Judge 审查、BugFix——全部开新窗口。

原因很简单：每个窗口的上下文是独立的，开新窗口 = 给 AI 一个干净的工作区，不会被之前 500 条消息的"残留上下文"干扰。而且新窗口会重新加载 Rules 文件，AI 一上来就带着完整的规范开工。

具体操作：

• • Leader 讨论完方案 → 方案存 docs/plans/，开新窗口进 Worker
• • Worker 全部写完 → 开新窗口 Judge review
• • 发现 Bug → 开新窗口 BugFix，四步闭环

唯一的例外是规范本身的迭代——如果你在连续调整 Rules 文件的措辞和内容，保持在一个窗口里比较好，上下文连贯。

这个习惯养成之后，AI 产出质量明显提升。本质上就是把"长对话记忆衰减"的问题，转化成了"短对话 + 文件持久化"的模式。

坑 3：修 Bug 别让 AI "顺手优化"

让 AI 修一个空指针。它修完了？修完了。但它顺手把整个方法重构了——变量名全改、代码结构调整、甚至加了个设计模式。

空指针好了，新来俩 Bug。而且 review 的时候根本分不清哪些改动是修 Bug，哪些是它"顺手优化"。

现在 BugFix 模式写死四步：定位根因 → 最小改动 → 补测试 → 跑通。想重构？开个新窗口。修 Bug 和重构，永远不要混在一起。

坑 4：手动改了一半代码，AI 给你改回去

这个坑特别隐蔽。

有时候我会手动改几行代码——比如调个参数、改个判断条件。但改得不彻底，只改了主代码，单测、plan啥的忘了同步。

下一次让 AI 改这个模块的时候，它读到了没改的地方，判断"原来逻辑应该是这样的"，直接把我手动改的那一处也改回去了。更坑的是它不会告诉你它改回去了——在一大堆代码变更里，这种"回滚"几乎不可能注意到。

教训：尽量都让让 AI 改（它会全局搜索关联位置一起改），我的项目ReadMe第一行就明确说明，本项目不建议手动修改，建议在cursor打开由AI改动。

坑 5：AI 看不见"全局"

AI 单文件能力很强，但全项目维度的代码质量——跨文件重复、命名不一致、潜在性能问题——它基本看不见。

特别特别是“死代码”，因为需求变更、方案修改等等可能产生很多死代码，AI是不会清除干净的，我让AI全量跑过几次，最后还是清除不干净，还巨烧Token。

解法就是 Judge 阶段的静态检查：把全局工程质量交给 Checkstyle、PMD、SpotBugs 这些原生专业工具。一条命令扫全项目，有违规甩给 AI 改。AI 负责写，工具负责查，人负责判断。专业的事交给专业的工具，别指望 AI 全能。

坑 6：跟 AI 对话，名称得稳定

这个坑很隐蔽，但在复杂工程里特别致命。

你跟 AI 讨论一个功能，第一次叫它"积分发放"，第二次叫"奖励逻辑"，第三次叫"活动结算"——AI 会以为这是三个不同的东西，然后给你写三份代码。

在复杂工程里迭代代码，你得给 AI 一个稳定的 key。

这个 key 可以是方法名（比如 issueReward），可以是文档里的功能名称（比如方案文档里写的"奖励发放模块"），但不能老换。AI 的上下文窗口有限，它靠关键词做关联。你换了名字，它就断了关联，之前讨论的上下文全废了。

我的做法：方案文档里每个功能点有唯一的名称，对话里严格用这个名称，不用同义词、不用缩写。听着简单，但你不刻意注意就会犯。

六、最后说两句

做完这个项目，我悟到一件事：

AI 编程的瓶颈不在 AI，在你。

同样是 Cursor + Claude Opus，不给它立规矩就是"第一天爽，第三天乱，第五天想重写"。给它一套完善的 Rules 就能稳定输出。

这跟带团队一个道理——招来的人再厉害，没有规范、没有流程、没有测试要求，项目一样烂。AI 也是。

2 万块 Token，15 天，10 万行生产级代码。传统方式 2-3 个人干 2-3 个月。但这个效率不是白来的——你得花时间把"规矩"立好。

如果你现在还没开始用 AI 写代码，我的建议是：今天就开始。

不用等到什么都准备好。先把通用层的 Rules 复制进项目，跑一次就能感受到区别。然后边用边踩坑，边踩坑边加规则。

这套系统会越用越值钱。

开源

我把文章里提到的 Rules 模板整理成了可直接使用的版本：

• • 通用层：Leader-Worker-Judge 开发流程 + 设计原则自检清单 + 禁止行为模板（前端/后端/客户端通用）
• • 技术栈层：编码规范 + 测试分层 + 数据访问分层
• • 项目层：域边界表空白模板（填你自己的项目结构）

开源地址：https://github.com/sheng3233836/vibe-coding-standards

拿去用。有问题评论区聊。