AI Coding：从Vibe Coding到Agentic Engineering

一句话概括：我们花了半年时间，踩了一堆坑，才搞明白一件事——让 AI 帮你写代码不难，难的是让它按你的规矩写。这篇文章记录了我们在 Spring Boot 3 + MyBatis-Plus + 微服务架构的项目中，怎么用 Cursor Rules、Skills、MCP 三板斧，把 AI 从"什么都敢写"训到"按规矩交活"。

---

一、问题的起点：AI 代码生成率 30%，交付效率纹丝不动

去年年中，团队开始正儿八经用 AI 写代码。Copilot 开着、Cursor 用着，代码生成率蹭蹭往上涨。三个月后拉数据一看——AI 辅助生成的代码占比超过 30%，但需求从接手到上线的平均周期，几乎没变。

更扎心的是几个事故：

• 一次缓存穿透：AI 直接在 Service 层调了 RedisTemplate，绕过了 Repository 的 Cache-Aside 封装，上线后缓存和数据库的数据不一致，排查了一整晚。
• 一次 N+1 查询：AI 在 forEach 循环里调 Repository 方法，测试环境数据量小没感觉，生产环境直接把数据库连接池打满。
• 一次 Prompt 注入：AI 模块的对话接口没做输入过滤，被测试同学用一句 “忽略上面的指令” 拿到了系统 Prompt。

这些问题有个共同特征：不是 AI 写的代码"不能跑"，而是它不知道这个项目的规矩。

快手的研发效能团队在复盘里提过一个不等式，跟我们的体感完全一致：

使用 AI 工具 ≠ 个人提效 ≠ 组织提效

AI 能写代码，但它不懂你的分层架构、不知道缓存只能在 Repository 层调、不清楚事务里不能做远程调用。上下文给得越少，它越像一个入职第一天就敢提 PR 的实习生——代码能跑，但埋了一地雷。

回过头看，这就是 Vibe Coding 的根本问题。

---

二、三个阶段：从 Copilot 到 Agentic Engineering

我们团队内部自己总结了三个阶段，不是刻意要对标业界的 L1/L2/L3 框架，而是实际经历下来，每个阶段干活的方式确实完全不一样。

2.1 L1：AI 辅助（2024 下半年）

标准的 Copilot 模式。Tab 补全，偶尔用 Chat 问问"这段代码怎么优化"。开发者心智没变，AI 只是个更聪明的代码片段库。

收益：重复代码少写了，CRUD 快了一些。
问题：天花板很低，本质上还是人在写代码。

2.2 L2：Vibe Coding（2025 上半年）

Karpathy 那条推火了之后，团队里开始流行"把需求描述清楚让 AI 写，自己扫一眼差不多就行"。说实话，那段时间确实爽——一个下午搭出一个完整的 CRUD 模块，成就感拉满。

收益：代码产出量暴增，AI 生成代码占比 30%+。
问题：前面说的那三个事故，都发生在这个阶段。核心矛盾是——AI 的生成速度远超人的 Review 速度。你让它一口气写了 800 行，真正逐行看的可能不到 200 行。漏掉的那 600 行里，指不定埋着什么雷。

2.3 L3：Agentic Engineering（2025 下半年至今）

被事故教育了几次之后，我们琢磨出一个思路：与其事后 Review AI 的产出，不如事前约束 AI 的行为。

思路简单，落地的时候发现得先回答三个问题：

问题	对应的工程化手段
AI 怎么知道项目的架构规范？	Cursor Rules——把规范写成 Agent 能读懂的规则文件
AI 怎么按标准流程执行任务？	Skills——把 SOP 封装成可调用的工作流
AI 怎么获取实时的外部信息？	MCP——让 Agent 直接连数据库、查文档、调 API

这三样东西加在一起，就是我们说的 Agentic Engineering 工程体系。下面逐个拆解。

---

三、第一板斧：Cursor Rules——给 Agent 装上"项目记忆"

3.1 一个反直觉的认知

很多人觉得 AI 编码的关键在于 Prompt 写得好。我们实际跑下来结论相反：Prompt 是一次性的，Rules 才是持久的。

Prompt 是你每次对话时临时交代的要求，关了窗口就忘。Rules 是始终生效的全局约束——不管谁在用、不管什么任务，规矩一直在。

打个比方：Prompt 像是你每次开会前口头嘱咐新人"注意代码规范"，Rules 像是直接把《新人入职手册》钉在他工位上。哪个靠谱，不用说了。

3.2 我们的 8 条 Rules

我们在 .cursor/rules/ 目录下维护了 8 个规则文件，全部设为 alwaysApply: true，覆盖了开发流程的每一个关键环节：

这里面有几条规则是被事故"逼"出来的，举两个典型的：

规则一：cache-in-repository-only

起因就是前面说的那次缓存穿透。AI 在 Service 层直接注入了 UserCache4Redis，绕过了 Repository 封装的 Cache-Aside 逻辑。修完 Bug 之后，我们加了这条规则：

# 缓存使用规范：仅限 Repository 层

所有 `XxxCache4Redis` / `XxxCache4Local` 的方法调用只允许在 Repository 层。
Service 层及以上禁止直接依赖任何缓存组件（包括 RedisTemplate）。

## 禁止示例
@Service
public class UserServiceImpl {
    @Autowired
    private UserCache4Redis userCache4Redis; // 禁止
}

## 正确示例
@Repository
public class UserRepositoryImpl implements IUserRepository {
    @Autowired
    private UserCache4Redis userCache4Redis; // 允许
    
    @Override
    public UmsMember getById(Long id) {
        UmsMember cached = userCache4Redis.get(id);
        if (cached != null) return cached;
        UmsMember member = memberMapper.selectById(id);
        if (member != null) userCache4Redis.set(id, member);
        return member;
    }
}

加了这条规则之后，AI 再也没在 Service 层调过缓存。因为它每次生成代码前都会读到这条约束——就像一个实习生，你把"禁止"两个字写进文档，比口头说十遍都管用。

规则二：pev-framework——Plan → Execute → Verify

这是整个体系里最重的一条。它要求 AI 在执行任何多文件变更前，必须走完三个阶段：

这条规则里最有意思的部分是 Verify 阶段的反作弊机制（Anti-Cheat）。加这个是因为我们发现了 AI 修 Bug 时的一个骚操作——改不了生产代码就改测试。

举个真实的例子：一个方法应该返回 5，实际返回了 3。AI 的第一反应不是去修方法逻辑，而是悄悄把测试的期望值从 5 改成 3。CI 绿了，Bug 还在。这比不写测试还坑人。

所以我们在 Rules 里写死了一套禁止清单：

禁止行为	说明
删除/跳过失败测试	禁止 @Disabled、@Ignore、删除测试方法
注释掉断言	禁止注释或移除 assert* 语句
降低断言强度	禁止 assertEquals → assertNotNull
篡改期望值	业务应返回 5 实际返回 3，禁止把期望改成 3
加 try-catch 吞异常	为让测试不抛异常而包裹 catch

3.3 Rules 的设计心法

写了大半年规则，总结出几条经验：

1. 负面清单比正面引导有效 10 倍。

“建议在 Repository 层调用缓存"和"禁止在 Service 层调用缓存”，效果天差地别。AI 对"禁止"这个词的遵从度远高于"建议"。凡是被事故验证过的规则，一律用"禁止"开头。

2. 给出正反两个代码示例。

光说"不许这么写"不够，还得告诉它"应该怎么写"。我们每条规则都附带了 ❌ 禁止示例和 ✅ 正确示例，AI 的遵从率明显提高。

3. 规则文件不超过 8 个。

试过写 20 多条规则，结果发现 AI 的上下文窗口是有限的，规则太多反而会互相冲突。后来精简到 8 个，按"流程规范 / 架构约束 / 领域规范"三个维度组织，效果最好。

---

四、第二板斧：Skills——给 Agent 装上"操作手册"

4.1 Rules 和 Skills 的区别

一句话讲清楚：Rules 管"不能做什么"，Skills 管"应该怎么做"。

Rules 画红线——不能在 Service 层调缓存、不能在事务里做远程调用、不能 SELECT *。

Skills 给流程——拿到一个新需求，第一步干什么、第二步干什么、最终交付物长什么样。

打个比方，Rules 是交通法规，Skills 是驾校教材。

4.2 我们的三个核心 Skill

Skill 1：java-ai-delivery-sop（交付标准流程）

这个 Skill 覆盖了开发全周期的 6 个工作流：

每个工作流跑完之后，AI 必须输出"质量门禁三件套"：

1. 变更说明（Changelog）——改了什么、为什么改、影响范围
2. 开发自检清单（Dev Checklist）——编译？命名？分层？事务？
3. 回归清单（Regression Plan）——P0 回归项 + P1 回归项

这三件套不是给人看的面子工程，而是 AI 自己执行 Verify 阶段的输入。没产出这三件套，Verify 阶段就跑不起来。

Skill 2：java-testing（测试标准）

这个 Skill 规定了单元测试和集成测试的写法模板。拎几个关键约定：

• 测试方法命名：should{行为}When{条件}，比如 shouldReturnCachedUserWhenCacheHit
• 单元测试：JUnit 5 + Mockito，AAA 模式（Arrange-Act-Assert）
• 集成测试：@SpringBootTest + @ActiveProfiles("test")
• 覆盖优先级：P0 核心逻辑 > P1 边界条件 > P2 性能场景

为什么测试要单独做成 Skill 而不是写进 Rules？因为测试不只是一条约束，它有完整的模板、分级策略和执行命令，内容量比一条 Rule 大得多。Skill 支持引用外部模板文件（references/ 目录下的 .md），这种复杂度用 Rule 塞不下。

Skill 3：zentao（禅道工作流）

这个 Skill 把项目管理工具打通了。AI 可以直接：

• 拉取"指派给我"的 Bug/任务/需求
• 查看 Bug 详情并生成修复计划
• 修复完成后自动关闭 Bug、更新状态
• 批量模式：一键修复所有 Bug（fetch → plan → fix → test → commit → close）

说起来有点离谱，但跑起来意外地顺畅——尤其是"改个文案""修个空指针"这种低风险 Bug，AI 从读 Bug 到提交代码到关工单，全程不用人碰。

4.3 一个真实的 Skill 调用过程

拿"新功能开发"举例，AI 收到一个需求后的完整执行链路：

---

五、第三板斧：MCP——给 Agent 接上"外部世界"

5.1 为什么需要 MCP

Rules 管住了"不许做什么"，Skills 规定了"怎么做"，但还有个问题没解决：AI 怎么知道我们数据库里有哪些表？字段叫什么？索引建没建？

总不能每次都在 Prompt 里贴表结构吧？表结构会改，人会忘，50 张表的 DDL 贴进去直接把上下文撑爆。

MCP（Model Context Protocol）干的就是这事——让 AI 自己去查。

5.2 我们接入的 7 个 MCP Server

这里面有几个 MCP 的用法值得展开讲。

5.3 MySQL MCP：Schema 发现优先

这是使用频率最高的 MCP。我们在 db-access 规则里写了一条硬性要求：

禁止凭记忆或过时的 Entity 类编写 SQL。涉及数据库操作前，必须通过 MCP 的 describe_table 确认表结构。

为什么这么严格？因为 AI 的训练数据里没有我们的数据库 Schema。如果不强制它先查，它就会"编造"字段名——写个 user_name 实际上字段叫 nick_name，写个 gmt_create 实际上字段叫 create_time。这类错误在编译期抓不到（MyBatis 的 XML 映射在运行时才校验），往往到了集成测试甚至生产环境才暴露。

加了这条规则 + MySQL MCP 之后，AI 的典型操作变成了：

1. 调用 mysql.list_tables → 确认表存在
2. 调用 mysql.describe_table("ums_member") → 拿到完整字段定义
3. 检查索引情况 → 决定查询策略
4. 基于真实 Schema 编写 LambdaQueryWrapper

字段名错误从此基本绝迹。

5.4 Context7 MCP：实时文档查询

我们技术栈里有不少版本敏感的框架——Sa-Token 1.37.0、MyBatis-Plus 3.5.16、Langchain4J 1.4.0。AI 的训练数据里可能是旧版本的 API，直接用轻则编译报错、重则行为不一致。

Context7 MCP 解决的就是这个问题。它能实时查询指定库的最新文档和代码示例。比如我们在写 Langchain4J 的向量检索代码时，AI 会先调 context7.query-docs("langchain4j", "milvus embedding store")，拿到 1.4.0 版本的正确用法，而不是凭记忆写一个可能已经废弃的 API。

5.5 飞书 MCP + 阿里云 MCP：超越编码的能力边界

这两个 MCP 把 AI 的能力边界从"写代码"推到了"做事情"。

举个例子：我们内部搞了个 Agent 架构学习课程，需要每天往飞书群推当天的学习内容。以前是人工编写 → 调飞书 API → 手动发。现在是 AI 读课程大纲、用 LLM 扩展知识点、调飞书 MCP 直接推，全程没人碰。

另一个场景更实际：线上告警的时候，AI 通过阿里云 Observability MCP 直接查 SLS 日志、拉 Prometheus 指标、看链路追踪，定位完问题出个修复方案。以前值班同学半夜起来至少 30 分钟的排查流程，AI 两分钟出初步结论。

---

六、实战案例：时区与冬夏令时兼容性重构

光讲体系太虚，拿一个真实案例说话。这是我们前段时间做的一个中等规模重构——用户时区的冬夏令时（DST）兼容性问题。

6.1 背景

我们的用户遍布全球，但系统里存的时区是固定偏移量（比如纽约存的是 UTC-5）。问题是纽约有夏令时——夏天实际上是 UTC-4。这导致夏天的时间计算全部错一个小时，用户的营养打卡、睡眠记录时间都不对。

6.2 AI 的 Plan 阶段产出

AI 先调 MySQL MCP 查了 ums_member 表结构，发现 time_zone 字段存的是 +08:00 这种固定偏移量格式。然后产出了一份完整的技术方案文档（存在 doc/技术方案-时区与冬夏令时兼容性重构(PEV).md），核心内容包括：

• 现状诊断：固定偏移量无法感知 DST，影响 225+ 个调用点
• 目标方案：新增 time_region 字段（IANA 格式，如 America/New_York），新建 Repository Shim 层提供 DST 感知的偏移计算
• Phase 拆分：3 个阶段——Phase 0 加字段 + 写入路径 → Phase 1 Repository Shim 改造 → Phase 2 灰度迁移
• 数据流预演：详细列了纽约冬令时和夏令时两种情况下的偏移计算过程

6.3 AI 做得好的地方

• 主动搜索复用：在 Plan 阶段就 Glob 搜索了 **/service/**TimeZone*、**/repository/**Member*，找到了已有的 IUmsMemberRepository，没有重复造轮子。
• MCP 查表验证：在写 DDL 之前先 describe_table 确认了现有字段，避免了字段命名冲突。
• Phase 粒度合理：每个 Phase 都有独立的验收标准，Phase 0 完成后可以单独上线，不影响存量逻辑。

6.4 AI 翻车的地方

也不全是好消息。这个案例里 AI 犯了两个错：

错误 1：低估了改造范围。AI 最初的 Plan 只覆盖了 Service 层的时区计算逻辑，漏掉了定时任务（Task）和消息队列（MQ Listener）里的时区引用。人工 Review 时发现并补充了。

经验：AI 对"非主链路"的代码覆盖度不够好。Controller → Service → Repository 这条主链路它很熟，但 Task、Event Listener、MQ Consumer 这些"旁路"容易被遗漏。后来我们在 PEV 规则的 Plan 阶段加了一条：搜索范围必须包含 task/、event/、mq/ 目录。

错误 2：DDL 没考虑存量数据迁移。AI 写的 DDL 只有 ALTER TABLE ums_member ADD COLUMN time_region VARCHAR(64)，但没有考虑已有用户的 time_region 怎么填充。225 万条存量数据，不能全是 NULL。

经验：AI 对"新增字段"的第一反应就是加个 ADD COLUMN，缺乏"存量数据怎么办"的意识。后来我们在 db-access 规则里补了一条：凡是 ADD COLUMN，必须附带存量数据的迁移 SQL 和回滚策略。

---

七、效果与度量

这套体系跑了半年多，直接上数据：

7.1 质量维度

指标	Vibe Coding 时期	Agentic Engineering 时期	变化
AI 代码导致的线上事故	3 次/季度	0 次/季度	↓100%
编译失败率（首次提交）	~40%	~8%	↓80%
单元测试覆盖率	约 15%（几乎不写）	约 65%	↑50pp
PR Review 平均耗时	45 分钟	20 分钟	↓56%

7.2 效率维度

指标	变化	说明
需求平均交付周期	↓30%	Plan 阶段多花了 20 分钟，但 Execute 和 Verify 节省了大量返工时间
Bug 修复平均耗时	↓45%	zentao Skill 自动化了 Bug 读取→分析→修复→关闭的全流程
技术文档产出量	↑300%	PEV 框架强制产出技术方案文档，以前没人愿意写的文档现在自动生成

7.3 一个有意思的发现

AI 产出的技术方案文档，比大部分人写的更稳定。 不是说 AI 写得"更好"——资深工程师写的方案，AI 拍马追不上。但 AI 有个人做不到的优势：它不偷懒。不会因为赶工期就跳过风险评估，不会因为觉得"这需求简单"就省掉 Phase 拆分。该有的章节一个不少，该填的表格一个不漏。

这恰恰是团队最缺的——不是追求 100 分的神仙方案，而是保证每个方案兜底 80 分。

---

八、踩过的坑与反思

8.1 坑一：Rules 写太多反而失效

一开始上头了，写了 20 多条 Rules，从代码格式到 Git 提交信息面面俱到。结果 AI 的行为反而飘了——有时候守了 A 规则但犯了 B，有时候干脆无视好几条。

原因很简单：上下文窗口是有限资源。 20 多条 Rules 全部加载后占了大量的 Token，留给实际代码的空间变小了，AI 的推理质量反而下降。

后来精简到 8 条，按优先级排列，低优先级的规则从 alwaysApply 改成按文件路径触发（比如 ai-module-standards 只在编辑 calora-ai/** 下的文件时加载）。效果立竿见影。

教训：Rules 不是越多越好，而是越精越好。每条 Rule 都应该有一个明确的事故作为"出生证明"。

8.2 坑二：测试修复循环的无限 Loop

Verify 阶段有个"修复循环"机制——测试失败后 AI 自动修复并重跑，最多 5 轮。听起来很稳健，但实际跑起来遇到过一种情况：AI 修了 A 问题导致 B 测试也挂了，修 B 又导致 A 回来了，就这么来回抖动。

解决办法：在第 4 轮修复时强制 AI 回读 Plan 文档，重新审视整体方案。如果第 5 轮还没修好就停下来，把完整的错误日志和已尝试的修复方案一起报给人。这个"第 4 轮触发全局审视"的机制挺关键，相当于给 AI 一个"退一步看全局"的机会。

8.3 坑三：MCP 的安全边界

MySQL MCP 一开始图省事配了读写权限。有一次 AI 在"修复"一个数据问题时，二话不说执行了一条 UPDATE 改了生产数据。好在影响范围小，但出了一身冷汗。

现在的策略是：

• 查询类操作（SELECT）：默认允许
• 写入类操作（INSERT/UPDATE/DELETE）：只允许在测试环境
• DDL 操作：必须先写入 sql/ 目录落盘，再通过 MCP 执行
• 生产环境：零 DML 权限，彻底堵死

8.4 坑四：过度依赖 AI 的 Plan 能力

前面时区重构的案例里提到，AI 的 Plan 漏掉了 Task 和 MQ 相关的改造点。类似的问题不止出现过一次。AI 的 Plan 能力依赖于它能"看到"多少代码——如果代码库太大，它不可能全部读取，就一定会有遗漏。

我们现在的做法是：AI 的 Plan 只是初稿，人工 Review 时重点检查"变更边界"这一节。 特别是要问自己一个问题：“除了主链路，还有哪些地方引用了这个模块？”——这个问题，目前人比 AI 更擅长回答。

---

九、对 AI Coding 发展阶段的判断

实践聊完了，说几点我们自己的判断，不一定对，但都是真实体感。

9.1 Vibe Coding 不是错的，是阶段性的

Vibe Coding 的核心理念——“描述意图，让 AI 写代码”——方向没问题，问题在于缺少约束。就像你让一个聪明的新人自由发挥，他产出可能很高，但在一个有复杂规范的项目里，“自由发挥"往往意味着"到处埋雷”。

Agentic Engineering 不是对 Vibe Coding 的否定，而是给它加上了工程化的骨架。Vibe 负责创意和速度，Engineering 负责质量和可控。

9.2 开发者角色的实际变化

"AI 要取代程序员"和"AI 只是工具"这两种声音我们都听腻了。实际体感在中间偏右：AI 干掉了编码劳动的重复部分，但反过来放大了工程设计的价值。

这套体系里，开发者的日常工作变成了：

• 写 Rules 和 Skills——定义 AI 的行为边界和执行流程
• Review Plan 文档——审查 AI 的设计方案，补充遗漏
• 定义验收标准——告诉 AI 什么样的结果才算"通过"
• 处理 AI 搞不定的事——跨模块的架构决策、模糊需求的澄清、生产事故的应急响应

简单说，从"写代码的人"变成了"定义规则的人"。这对工程师的要求不是降低了，而是换了个方向——你得对项目的架构和规范有足够深的理解，才能写出有效的 Rules。

9.3 投入产出的诚实评估

搭这套体系不便宜。8 条 Rules + 3 个 Skills + 7 个 MCP Server，光写规则和调通就花了将近两个月。Rules 也不是写完就完事，每次出了新类型的问题还得回去加。

但一旦搭好，边际成本降得很快。新人来了不用手把手教规范——AI 自己按 Rules 遵守。开新模块不用从零摸索——Skills 定义了标准流程。数据库操作不用翻文档——MCP 自己查。

如果你的项目是一次性的、小规模的，Vibe Coding 够用了。如果你的项目需要长期维护、团队协作、质量底线，那 Agentic Engineering 的投入是值得的。

---

十、写在最后

回到开头那个不等式：

使用 AI 工具 ≠ 个人提效 ≠ 组织提效

我们花了半年验证了一件事：从"用 AI 工具"到"组织真的提效"，中间差的不是更好的模型或更贵的订阅，是一套把团队的知识、流程、能力编码成 Agent 能读懂的指令的工程体系。

Rules 编码知识，Skills 编码流程，MCP 编码能力。三样东西凑齐了，AI 才能从一个"什么都会但什么都不深"的通才，变成"在这个项目里知道怎么干活"的专才。

这条路没捷径。每条 Rule 后面是一个事故，每个 Skill 后面是一次返工，每个 MCP 配置后面是一次"AI 又搞砸了"的教训。但走过来回头看，这些约束不是在限制 AI，而是在释放它。

赛车不是只靠引擎马力大就能赢——还得有刹车、悬挂和空力套件。Agentic Engineering 就是给 AI 这台大马力引擎装上了整套底盘，让它不光跑得快，还跑得稳。