AI 编程工作流、Rules、Skills 完整解析（附示例）

一句话导读：很多人把 Cursor 提示词当「万能咒语」，却忽略了 2026 年 AI 编程真正拉开差距的三件套——Workflow 怎么拆任务、Rules 怎么锁边界、Skills 怎么沉淀专长。 下文按「概念 → 架构 → 示例 → 落地」展开，附可直接复制的 Rules / Skills 片段与团队协作清单；若你已在用 Cursor 或 Claude Code，读完即可在仓库里搭起第一层骨架。

三层架构：Workflow、Rules、Skills 各管什么？

2026 年的 AI 编程工具（Cursor、Claude Code、GitHub Copilot App、Windsurf 等）表面都是「聊天改代码」，但稳定产出的团队会把能力拆成三层：

可以类比：

• Workflow = 乐谱上的节拍（先规划再写码，还是先写测试）
• Rules = 家规（不许改 backend/、提交前跑 lint）
• Skills = 专科医生（只会做安全审查、只会写博客、只会配 MCP）

三层不互斥，而是叠加：Workflow 决定「这一轮对话怎么走」，Rules 始终压在上下文底层，Skills 在匹配到任务描述时被拉起。

Workflow：可重复的协作节奏

Workflow 不是某个配置文件，而是你与 Agent 约定好的步骤。在 Cursor 2026 里，常见拆法：

1. Plan 模式（先想清楚）

适合：跨文件重构、新功能、不熟悉模块。

请先只读代码库，列出：
1) 需要改动的文件清单
2) 风险点（API 兼容、迁移、测试缺口）
3) 分步实施计划（每步可独立验证）
不要写代码，等我确认后再进入 Agent 模式。

2. Agent 模式（小步落地）

适合：计划已确认、改动边界清晰。

按上一步计划执行第 1 步。范围仅限 src/auth/。
改完后列出已改文件，不要提交。

3. Review 模式（人工 + Agent）

适合：合并前、发版前。

对比 main 分支 diff，检查：
- 是否违反 .cursor/rules 里的后端禁令
- 是否有遗漏测试
- 是否有硬编码密钥
输出 checklist，标红高风险项。

推荐节奏（个人 / 小团队）

flowchart LR
  A[需求/ Issue] --> B[Plan 只读]
  B --> C{人确认?}
  C -->|是| D[Agent 分步改]
  C -->|否| B
  D --> E[本地测试]
  E --> F[Review / PR]

关键原则：一次 Agent 会话只解决一个可验证子目标；不要把「写博客 + 改后端 + 部署」塞进同一条提示词——那是 Workflow 失控，不是模型不够聪明。

Rules：持久化约束与项目记忆

Rules 解决的是：不用每次重复「我们是 TypeScript strict」「禁止 force push」。

存放位置

.mdc 文件结构

---
description: 博客文章 HTML 规范
globs: frontend/**/blog/articles/**
alwaysApply: false
---

# 博客文章规范
- 从 0-article-template 整目录复制
- 开篇用「一句话导读」，放在 TOC 前
- 更新对应语言 blog/index.html

• globs：只有编辑匹配文件时才注入，省 token
• alwaysApply: true：全局生效（如「禁止改 backend」）

好 Rule 的写法

1. 可执行：写「禁止修改 backend/」而非「注意后端安全」
2. 可验证：写「提交前运行 npm test」而非「保证质量」
3. 短小：单文件 200–800 字；过长拆成多个按 glob 挂载
4. 跟仓库走 Git：新人 clone 即生效

反例

❌ 你是一个资深工程师，请写出优雅的代码……
（空话，对 Agent 无约束力）

✅ 本仓库 API 层只用 zod 校验；新增 endpoint 必须同步更新 openapi.yaml
（具体、可检查）

Skills：按需加载的专项能力

Skills 是 Cursor 2026 引入的结构化技能包，通常是一个目录 + SKILL.md。与 Rules 的区别：

SKILL.md 基本结构

# Deploy Skill

## 何时使用
用户要求部署、发布、上线 frontend 时启用。

## 步骤
1. 确认不修改 backend/
2. 更新 seo-file 若为新博客
3. 运行 ./deploy.sh
4. git status 验证

## 禁止
- 不要 force push main
- 不要跳过 pre-commit hook

Skills 可放在：

• 项目内：.cursor/skills/deploy/SKILL.md（团队共享）
• 用户目录：~/.cursor/skills-cursor/（个人技能库，Cursor 内置 create-skill 等）

官方内置 Skills（如 create-rule、review-security）可作为模板阅读——重点是 「何时使用」+「步骤」+「禁止」 三段式。

三层如何叠加？

优先级经验：用户当前消息 > Skill 步骤 > Rules 约束 > 模型预训练习惯。若 Skill 与 Rule 冲突，应改文案明确「本 Skill 仅覆盖部署流程，仍遵守 no-backend 规则」。

示例 1：博客写作 Rule

.cursor/rules/blog-article.mdc（节选）：

---
description: 博客文章 HTML 规范
globs: frontend/**/blog/articles/**
alwaysApply: false
---

完整文档：frontend/zh/blog/ARTICLE-SPEC.md

## 新建文章
1. 从 frontend/zh/blog/articles/0-article-template/ 整目录复制
2. 开篇第一段为「一句话导读」，放在 arx-toc 之前
3. 更新对应语言 blog/index.html
4. Hero 图放 resources/images/

配合 Workflow：用户说「写一篇关于 MCP 的博客」→ Agent 自动挂上此 Rule（glob 匹配）→ 再按需加载 blog-writer Skill。

示例 2：部署 Skill

.cursor/skills/deploy/SKILL.md：

# Deploy

## 何时使用
用户提到部署、上线、deploy.sh、发布到生产。

## 前置检查
- [ ] 仅 frontend / seo-file 变更，未改 backend/
- [ ] sitemap / indexnow 已更新（若是新博客）

## 执行
./deploy.sh

## 验证
部署后检查目标 URL 可访问。

这样即使 Rule 里没写 deploy 细节，Agent 在听到「部署」时会拉起 Skill，减少漏步骤。

示例 3：一次完整迭代 Workflow

任务：为站点新增一篇中文博客并翻译、收录、部署（与本文生产流程类似）。

全程 Rules 保证：不动 backend/、遵循 ARTICLE-SPEC.md；Skills 在「部署」「sitemap」环节注入命令清单。

团队落地清单

• [ ] 仓库根添加 AGENTS.md：技术栈、目录说明、禁止区域
• [ ] .cursor/rules/ 至少 2 条：全局约束 + 按目录细分
• [ ] 高频任务（部署、博客、CR）各 1 个 Skill
• [ ] CONTRIBUTING.md 写明：Plan 先行、单次 PR 范围、Review 检查项
• [ ] Rules/Skills 变更走 PR，像改 CI 一样 review
• [ ] 远程开发机（如 Cloud Mac）同步 clone，Rules/Skills 随 Git 一致

常见误区

1. 把所有提示词塞进一条 Rule → 上下文膨胀，Agent 反而忽略重点。应拆分 + glob。
2. 没有 Workflow，上来就 Agent 全自动 → 大范围误改。先 Plan，再小步。
3. Skills 与 Rules 重复 → 维护两份真相。约束放 Rules，流程放 Skills。
4. Rules 写人格「你是专家」 → 浪费 token。写可验证规则。
5. 忽略性能 → 多 Agent + 本地构建吃内存；重负载可放 32GB+ Cloud Mac 节点，Workflow 不变。

常见问题

（结构化 FAQ 见页脚折叠区与 JSON-LD；此处为正文补充。）

Q：要先写 Rules 还是先写 Skills？
先写 1 条全局 Rule（技术栈 + 禁止区），再为最高频的 2–3 个任务写 Skills。Workflow 在日常使用中自然沉淀即可。

Q：Claude Code 怎么对应？
CLAUDE.md ≈ Rules；自定义 command / 子 agent 文档 ≈ Skills；终端里先 claude plan 再执行 ≈ Workflow。

更多 MCP 与工具链配置，可参考 Claude Code MCP 配置教程。