全局 Skill + 项目 Skill + 自定义 Skill + MCP：用 Cursor 把开发做成流水线
实践项目：laby-boot（Ruoyi-Pro / CRM + BPM）
工具链：Cursor Agent + Superpowers + MCP
2026-05-31
写在前面
很多人用 AI 写代码，体验像开盲盒：同一句「帮我加个审批」，有时产出结构清晰、有时直接改飞、有时 SQL 中文变 ???、有时没跑测试就说「已完成」。
问题不在模型笨，而在 缺少一套稳定的工程约束。
我们在 Cursor 里搭了一套组合：全局 Skill 定规矩、项目 Skill 贴地图、自定义 Skill 补细节、MCP 接工具。Agent 不再「想到哪改到哪」，而是按流水线干活——设计先行、测试先行、验证有证据、规范可复用。
这篇文章讲清楚：四层分别是什么、怎么配合、一条需求如何走完全程、以及「全自动化」真实边界在哪。
一、先建立一个直觉：Agent 需要「操作系统」
可以把 Cursor Agent 想成新来的高级工程师：
- 技术不差，但 不了解你们组的流程
- 写代码快，但 容易跳过设计、跳过测试
- 能调终端，但 不知道 Windows 下 SQL 会乱码
只给一句 Prompt，等于只说一句「帮我做 CRM」。
给 Skill + Rules + MCP，等于再给他：员工手册、项目 Wiki、工牌权限、测试账号、浏览器和数据库钥匙。
所以我们不做「更长的 Prompt」，而是做 分层能力栈：
1你（决策） 2 ↓3Superpowers 流程（怎么开发）4 ↓5Ruoyi-Pro 规范（怎么写代码）6 ↓7项目 Rules（本仓库必须遵守）8 ↓9MCP / Shell（怎么验证）10 ↓11可交付产物（spec / plan / 代码 / E2E 报告）二、四层能力栈，各管什么
1. 全局 Skill —— 跨项目的「宪法」
位置：~/.cursor/skills/
特点：换仓库也生效，不写具体业务模块名。
我们目前配了 3 个：
| Skill | 管什么 |
|---|---|
superpowers-driven-development | 流程：先设计、先 TDD、先验证，禁止裸写代码 |
ruoyi-pro-coding-standards | 代码：分层、字典四件套、P3C、ErrorCode |
sql-encoding-safe | 数据：utf8mb4、UNHEX 兜底、HEX 验中文 |
全局 Skill 回答的是：不管做 CRM 还是 ERP，开发方式和代码底线是什么。
2. 项目 Skill + Cursor Rules —— 本仓库的「地图 + 门禁」
位置：
- 项目 Skill：
.cursor/skills/ - 自动规则：
.cursor/rules/*.mdc
区别：
- Skill 给 Agent 读的长说明（流程、示例、指针）
- Rules 每次对话自动注入的短约束（硬门禁）
本仓库 Rules 已开 3 条（alwaysApply: true）：
superpowers-driven-development.mdc— 必须走 Superpowers 流程ruoyi-pro-coding-standards.mdc— 必须遵守 Ruoyi-Pro 规范sql-encoding-safe.mdc— 含中文 SQL 必须防乱码
项目 Skill 还存 Superpowers 14 条的本地镜像，以及本仓库速查（包名 com.laby.boot.module.*、SQL 在 sql/、E2E 在 scripts/ 等）。
一句话：全局 Skill 是通用法；项目层告诉 Agent「在这个 repo 里，文件在哪、惯例是什么」。
3. 自定义 Skill —— 团队的「补丁包」
仍在 .cursor/skills/，但性质是 团队自己写的，不是 Superpowers 官方、也不是跨项目通用规范。
例如 laby-boot 里：
java-layered-architecture-standards.md— 极细的 Java 分层与 import 清理流程document-formatting-styles.md— 文档排版风格
用法原则：
- 全局 Skill 要少而稳（3～5 个足够）
- 自定义 Skill 解决具体痛点（架构、Review 标准、模块专有流程）
- 三层不重复粘贴同一段话 — 项目层只写「本仓库差异」
4. MCP —— Agent 的「手」和「眼」
Skill 告诉 Agent 该不该验证、该怎么思考；MCP 和 Shell 告诉它 怎么动手。
| 能力 | 用途 |
|---|---|
| Shell / Docker | 跑 mvn、执行 E2E、MySQL HEX() 验中文、Redis FLUSHALL |
| cursor-ide-browser | 打开管理后台、走审批页、截图留证 |
| cursor-app-control | 打开 spec/plan、切终端、开 worktree |
| Postman MCP | API 集合回归（可选） |
没有 MCP，Agent 只能「猜」服务起没起、页面对不对。
有了 MCP，verification-before-completion 才真正落地——说「完成」之前，得拿日志和截图。
三、Superpowers：14 个 Skill 串成一条流水线
Superpowers 是 Cursor 插件（obra/superpowers），提供 14 个流程 Skill。
我们再用全局 superpowers-driven-development 强制每次开发都走这套流程。
不必背 14 个名字，记住 一条故事线 即可：
11. brainstorming → 先聊清楚、出设计，你点头之前不写代码22. writing-plans → 设计拆成任务清单（plan）33. test-driven-development → 先写失败测试，再写实现44. subagent-driven-development → 大计划拆给子 Agent 做（可选）55. systematic-debugging → 出 Bug 先查根因，别乱改66. verification-before-completion → 跑通 E2E/编译，有输出才能说「完」77. finishing-a-development-branch → 合并 / PR / 清理分支其余 7 个是辅助：using-superpowers（总控）、using-git-worktrees（隔离开发）、requesting/receiving-code-review（审查）、dispatching-parallel-agents（并行）、writing-skills（写 skill 本身）、executing-plans（无子 Agent 时手动执行 plan）。
Rigid 技能（TDD、调试、验证）不能打折；用户明确说「这次跳过 TDD」才可以例外。
四、走一遍真实需求：CRM 审批闭环
下面不是虚构流程，就是 laby-boot 里 CRM BPM 闭环的走法。
你只说目标
商机、立项、台账阶段都要 BPM；财务要进审批链；要能 E2E 验证。
Agent 的第一件事不是改代码
brainstorming 产出 spec：
docs/superpowers/specs/2026-05-31-crm-bpm-closed-loop-design.md
里面定死：统一 audit_status、Listener 回调、门禁规则、BPMN 设计器类型、财务角色权限。
你评审通过，才进入实施。
第二件事：拆 plan
writing-plans 产出：
docs/superpowers/plans/2026-05-31-crm-bpm-parallel-spaces.md
按 Space 拆：SQL 基础设施、商机阶段、合同立项、台账完成、前端、E2E——可并行、可验收。
第三件事：TDD + 规范叠加实现
每个 Space：
- 先动 E2E 或测试断言（例如
auditStatus=20） - 再写 Java / SQL / BPMN
- 同时遵守 ruoyi-pro-coding-standards（分层、字典、ErrorCode）
- 中文 SQL 走 sql-encoding-safe（UNHEX +
--default-character-set=utf8mb4）
第四件事：MCP + Shell 拿证据
1docker exec qian-redis redis-cli FLUSHALL2python scripts/e2e_crm_bpm_test.py3python scripts/e2e_crm_bpm_full_loop.py改角色菜单后必须刷 Redis，否则 @PreAuthorize 仍 403——这是项目踩过的坑，适合写进项目 Skill，而不是每次靠人提醒。
第五件事：才允许说「完成」
verification-before-completion：
e2e_crm_bpm_test.py → 16 PASS；e2e_crm_bpm_full_loop.py → 18 PASS，0 FAIL。
有数字，才算闭环。
第六件事：你决定怎么合入
finishing-a-development-branch：合并、开 PR 或继续迭代——commit 由你下令，Agent 不擅自 push。
五、目录怎么摆（Cursor 标准布局）
1~/.cursor/skills/ # 全局：跨项目2├── superpowers-driven-development/3├── ruoyi-pro-coding-standards/4└── sql-encoding-safe/56laby-boot/7├── .cursor/8│ ├── rules/ # 自动注入（门禁）9│ │ ├── superpowers-driven-development.mdc10│ │ ├── ruoyi-pro-coding-standards.mdc11│ │ └── sql-encoding-safe.mdc12│ └── skills/ # 项目：镜像 + 速查 + 自定义13│ ├── README.md14│ ├── brainstorming.md # Superpowers 14 条镜像15│ ├── ruoyi-pro-coding-standards.md16│ └── java-layered-architecture-standards.md17├── docs/superpowers/18│ ├── specs/ # 设计19│ └── plans/ # 计划20├── sql/ # 可重复执行脚本21└── scripts/e2e_*.py # 全链路验证插件原版 Superpowers 还在：
~/.cursor/plugins/cache/cursor-public/superpowers/*/skills/*/SKILL.md
项目 .cursor/skills/ 里的镜像，是为了 离线可读、检索方便；以插件版为准。
六、「全自动化」到底自动化了什么
诚实讲：这是 高度自动化的人机协作，不是无人值守。
| Agent + Skill + MCP 负责 | 仍然需要你 |
|---|---|
| 出 spec / plan、写代码/SQL、跑 E2E | 定优先级、拍板业务规则 |
| 强制 TDD、强制验证 | 批准设计、决定例外 |
| 规范检查、乱码修复套路 | 生产发布、密钥与账号 |
| 浏览器/终端验证 | 产品细节与 UX 审美 |
自动化的目标：
- 重复劳动机器做（规范、回归、乱码、权限缓存）
- 人只做决策（做不做、何时合、是否跳过流程）
- 每次交付可审计（spec + plan + 测试输出）
七、新需求怎么接（复制即用）
1## 需求2- 目标：3- 验收标准：4- 是否涉及：SQL / BPM / 权限 / 前端56## Agent 应自动执行71. brainstorming → spec（等我批准）82. writing-plans → plan93. TDD 实现 + ruoyi-pro-coding-standards104. 含中文 SQL → sql-encoding-safe115. verification → E2E / 编译 / HEX()126. finishing → 等我指令再 commit/PR把这段贴进 Issue 或对话开头，Agent 就知道该走哪条流水线。
八、常见误区
误区 1：Skill 越多越好
Skill 太多会互相打架。全局 3 个 + 项目若干指针 + 团队补丁，足够。
误区 2：有 Rules 就不用 Skill
Rules 短、适合门禁；Skill 长、适合流程和示例。两者配合。
误区 3：Agent 说「应该没问题」就算完
没有命令输出、没有 E2E PASS，就是没完成——这正是 verification-before-completion 存在的原因。
误区 4：只配 Prompt，不配 MCP
不调终端、不跑脚本，自动化停在纸面上。
误区 5：项目 Skill 写满规范全文
规范放全局；项目只写 路径、账号、踩坑（例如 Redis FLUSHALL）。
结语
Cursor 里的「开发全自动化」，本质不是让 AI 替人写代码，而是：
用全局 Skill 统一方法论，用项目 Skill/Rules 钉住仓库惯例，用自定义 Skill 补团队细节，用 MCP 把验证做实。
Superpowers 保证 先设计、先测试、先证据；Ruoyi-Pro 规范保证 代码能维护；SQL 防乱码保证 数据能读；E2E 保证 链路真通。
当你下次只说一句「做个审批闭环」，Agent 应自动展开成：spec → plan → TDD → 规范实现 → E2E 报告 → 等你合入——这才叫 工程化的 AI 开发，而不是聊天式改代码。
延伸阅读：本仓库 CRM BPM 设计 docs/superpowers/specs/2026-05-31-crm-bpm-closed-loop-design.md；项目 Skill 索引 .cursor/skills/README.md。
评论区 / Comments