AI时代前端工程师实战指南：全链路提效篇

发表于 分类于 阅读次数：

本章目的：从需求分析到上线运维，覆盖整个软件开发生命周期（SDLC）。但本文不是给你一堆 Prompt 模板——而是教你把每个研发环节封装成一个 Skill（SKILL.md），然后用一个 Workflow（AGENTS.md）让 AI Agent 按流水线自动执行。Agent 自行决策每一步用什么工具和 MCP，你只需要在关键 Gate 做确认。

2.1 开发生命周期全景

传统开发流程中，AI 往往只被用在”写代码”这个环节。但事实上，每个环节都可以 Skill 化。一旦被 Skill 化，Agent 就能自动识别当前处于什么阶段、该做什么事、用什么工具。

1
2
3
4
5
6
7
8
9
10
11
12
┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ 需求分析      │ → │ 技术设计      │ → │ 编码实现      │ → │  测试        │ → │ Code         │ → │ 部署运维      │
│ Skill        │    │ Skill        │    │ Skill        │    │ Skill        │    │ Review Skill │    │ Skill        │
│              │    │              │    │              │    │              │    │              │    │              │
│ requirement- │    │ tech-design  │    │ coding       │    │ test-        │    │ code-review  │    │ deploy-ops   │
│ analysis     │    │              │    │              │    │ generation   │    │              │    │              │
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘    └──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                   │                   │                   │                   │
       ▼                   ▼                   ▼                   ▼                   ▼                   ▼
  产出：功能点清单      产出：方案文档       产出：实现代码       产出：测试文件      产出：Review 结论   产出：部署完成
  验收标准             API 设计            + 测试通过          + 覆盖率报告       + MR 合并          + 监控告警
  模糊点清单           组件树

不再是你跑过去问 Agent”帮我分析这个需求”——Agent 看到 JIRA Ticket 后，自己就会加载 requirement-analysis Skill，按 Skill 里的步骤执行。

2.2 环节一：需求分析 Skill

传统痛点

  • 需求文档含糊不清，开发过程中才发现遗漏
  • 沟通成本高：产品和开发的认知偏差
  • 验收标准不明确，上线后才发现理解错误

Skill 化方案

不再给 Prompt 模板，而是把”需求分析”这个能力固化成一个 Skill。Agent 加载后，自己决定怎么读文件、查 JIRA、还是搜索知识库。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 文件名：.opencode/skills/requirement-analysis/SKILL.md

## 适用场景
收到产品需求（文字/文档/JIRA Ticket），需要拆解为可执行的功能点

## 输入
- 需求原文（从 JIRA / 文档 / 用户输入获取）
- 项目背景信息（从 CLAUDE.md / AGENTS.md 获取）

## 输出
- 功能点清单（按 P0/P1/P2 优先级排序）
- 每个功能点的验收标准（Given/When/Then 格式）
- 待确认问题列表（需求中的模糊点）
- 技术可行性评估（风险 / 依赖 / 复杂度）

## 执行步骤
1. 读取需求输入（从文件、JIRA API、或用户消息中提取）
2. 按 MVP 优先级将需求拆解为独立功能点
3. 为每个功能点编写可测试的验收标准
4. 识别需求中的模糊点和不一致之处，形成待确认问题列表
5. 评估每个功能点的技术可行性和实现复杂度
6. 输出结构化文档到 `.opencode/artifacts/requirement-analysis.md`
7. 等待人工确认后进入下一环节

## 约束
- MUST: 每个功能点必须有可测试的验收标准
- MUST: 必须区分 P0（MVP必需）/ P1（重要）/ P2（锦上添花）
- MUST: 必须列出至少 3 个待确认问题
- MUST NOT: 不要假设需求中没有提到的技术方案
- MUST NOT: 跳过模糊点标注
- MUST NOT: 直接开始编码（需求分析阶段不产生代码）

设计思路

这个 Skill 的巧妙之处在于——它不指定具体用什么工具。Agent 可以根据环境自主选择：

  • 如果项目绑定了 JIRA MCP，Agent 会直接调用 jira_getIssue 拉取 Ticket
  • 如果需求写在本地文档里，Agent 会自动 Read 对应文件
  • 如果没有外部源，Agent 会提示你粘贴需求文本

你只需要写一次 Skill，以后每个需求分析 Agent 都会按这个 SOP 执行。

与直接给 Prompt 的区别

对比维度 传统 Prompt 方式 Skill 化方式
复用性 每次要 CP 粘贴 写在 SKILL.md 里自动加载
一致性 不同人/次 Prompt 不同 所有 Agent 按相同步骤执行
工具决策 你告诉 AI 用什么工具 Agent 自己选（JIRA MCP / 读文件 / …）
输出规約 每次格式不统一 固定输出格式，下一环节可直接消费
人工 Gate 靠自觉 Skill 执行步骤明确要求等待确认

2.3 环节二：技术设计 Skill

传统痛点

  • 方案选型凭经验，容易遗漏替代方案
  • 设计文档写起来痛苦，经常滞后甚至缺失
  • 架构决策的 trade-off 分析不充分

Skill 化方案

需求分析确认后，Agent 自动加载 tech-design Skill。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 文件名：.opencode/skills/tech-design/SKILL.md

## 适用场景
功能点已确定，需要进行技术方案设计、组件架构设计、API 接口定义

## 输入
- `.opencode/artifacts/requirement-analysis.md`（需求分析产出）
- 项目技术栈信息（从 CLAUDE.md 读取）

## 输出
- 技术方案对比文档（2-3 个候选方案）
- 推荐方案及理由
- 组件树 / 数据结构 / API 接口设计
- 风险点和应对策略

## 执行步骤
1. 读取需求分析阶段的产出物
2. 分析技术约束（现有技术栈、团队能力、时间限制）
3. 生成 2-3 个可行的技术方案，列出每个方案的优缺点
4. 输出推荐方案及关键技术决策的 trade-off 分析
5. 设计组件树结构、Props/Emits 接口、数据流
6. 定义 API 接口格式（请求/响应类型）
7. 如果涉及架构变更，生成 Mermaid 架构图
8. 输出设计文档到 `.opencode/artifacts/tech-design.md`
9. 等待人工确认后进入编码阶段

## 约束
- MUST: 至少对比 2 个方案
- MUST: 明确标注每个方案的 trade-off（不是只说优点）
- MUST: 定义完整的 TypeScript 类型接口
- MUST NOT: 跳过已有系统的兼容性分析
- MUST NOT: 直接输出实现代码（设计阶段不编码）

关键要点

  • 技术设计 Skill 的输入明确依赖 requirement-analysis 的产出——这是 Skill 串联的关键。每个 Skill 的输入/输出定义清晰，下一个 Skill 才知道从哪里拿数据。
  • Agent 在加载这个 Skill 后，不需要你手动粘贴需求文档。它会自动读取 requirement-analysis 阶段写入的文件。

2.4 环节三：编码实现 Skill

这是 AI 最强也最常用的环节。但问题在于，大多数人直接把编码 Skill 当”万能打字机”用——输入模糊的需求，输出不可靠的代码。

Skill 化的核心思路：编码 Skill 不直接对接原始需求，而是消费需求分析和设计阶段的结构化产出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# 文件名：.opencode/skills/coding/SKILL.md

## 适用场景
技术设计已确认，需要根据 Spec 和设计文档进行编码实现

## 输入
- `.opencode/artifacts/requirement-analysis.md`（需求分析产出：功能点+验收标准）
- `.opencode/artifacts/tech-design.md`（技术设计产出：组件树+类型定义+API 接口）
- 项目代码规范和目录结构（从 CLAUDE.md 获取）

## 输出
- 实现代码（通过对应测试）
- 代码变更摘要

## 执行步骤
1. 读取需求分析和设计文档
2. 检查是否已有测试文件（如果有，以测试通过为目标编写实现）
3. 优先增量生成：一次只实现一个功能点
4. 每完成一个功能点后立即运行 `npm run build` 和 `npm run test`
5. 如果测试失败，自主定位并修复（红 → 绿 循环）
6. 一个功能点通过后再进入下一个
7. 所有功能点完成后输出代码变更摘要
8. 等待人工确认后进入测试阶段

## 约束
- MUST: 读取需求分析和设计文档作为输入（不直接对接原始需求）
- MUST: 优先检查是否有测试文件，有则 TDD 模式
- MUST: 增量生成，每次不超过一个功能点
- MUST: 每步完成后立即运行构建和测试验证
- MUST: AI 生成的代码必须人工 Review
- MUST NOT: 一口气生成超过 200 行的代码块
- MUST NOT: 修改已有的测试文件
- MUST NOT: 跳过验证步骤直接进入下一个功能点

设计思路

这个 Skill 有几个设计细节值得注意：

第一，输入上游化。 编码 Skill 的输入不是”你粘贴一段需求”，而是自动读取两个上游文档。这意味着需求分析和设计阶段做得越扎实，编码质量越高。

第二，增量原则。 Skill 明确要求”一次只实现一个功能点”——这不是保守，而是为了让 Agent 在可控范围内工作。如果一口气生成 500 行代码，出问题你根本不知道从哪开始 Debug。

第三，TDD 自动触发。 如果检测到已有测试文件，Agent 会自动进入”让测试通过”模式。这就是为什么下一环节（测试生成）要在编码 Skill 之前或并行执行。

2.5 环节四：测试 Skill

写测试是大多数开发者的痛点，但 AI 非常擅长。测试 Skill 可以独立运行，也可以在编码之前提前生成测试文件（TDD 模式）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 文件名：.opencode/skills/test-generation/SKILL.md

## 适用场景
需求分析和技术设计已完成，需要为功能点生成测试文件

## 输入
- `.opencode/artifacts/requirement-analysis.md`（功能点清单 + 验收标准）
- `.opencode/artifacts/tech-design.md`（组件结构 + 类型定义 + API 接口）
- 项目测试框架配置（从 CLAUDE.md 获取）

## 输出
- 完整的测试文件（`.test.ts` / `.spec.ts`）
- 覆盖率简报

## 执行步骤
1. 读取需求分析的验收标准和设计文档的类型定义
2. 分析每个功能点的正常路径、边界值、异常路径
3. 为每个功能点生成对应的测试用例（一个 describe 对应一个功能点）
4. 确保测试文件可以独立运行（mock 外部依赖但不 over-mock）
5. 运行测试验证语法正确（预期全红，因为还没有实现代码）
6. 输出测试覆盖率目标（最低 80% 行覆盖率）
7. 将测试文件写入对应源文件目录

## 约束
- MUST: 一个 describe 对应一个功能点，一个 it 只测一个行为
- MUST: 覆盖正常路径 + 边界值 + 异常路径
- MUST: 测试可独立运行，不依赖其他测试
- MUST: 只生成测试，不生成实现代码
- MUST NOT: mock 不需要的外部依赖
- MUST NOT: 测试实现细节（如内部状态、私有方法）
- MUST NOT: 修改源文件

关键要点

测试 Skill 可以独立运行，但在 TDD 流程中它通常在编码之前执行。Agent 的自主决策体现得非常明显：

  • 如果项目用 Vitest，Agent 会生成 vitest 格式的测试
  • 如果项目用 Jest，Agent 会适配 jest 格式
  • 如果是组件测试，Agent 自己决定用 Testing Library 还是 Playwright Component Test
  • Agent 从项目配置文件中检测这些信息，不需要你手动告诉它

这就是 Skill 化与传统模板的区别——Skill 只规定”做什么”和”约束”，不规定”用什么工具”。

2.6 环节五：Code Review Skill

Code Review 通常被认为是”人的工作”。但 AI 做 Pre-review 的效率极高，它擅长发现一致性问题和边界遗漏。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 文件名：.opencode/skills/code-review/SKILL.md

## 适用场景
代码变更已完成并经过自测，需要进行 Code Review

## 输入
- 代码变更（通过 git diff 获取，或通过 LSP 读取文件）
- 项目代码规范（从 CLAUDE.md 获取）
- `.opencode/artifacts/requirement-analysis.md`（用于对照需求判断逻辑正确性）

## 输出
- P0（必须修复）：逻辑错误、安全问题、类型问题、性能隐患
- P1（建议修复）：代码质量、错误处理、测试覆盖
- P2（风格建议）：命名一致性、注释准确性
- 最终结论（是否可以合并）

## 执行步骤
1. 通过 git diff（或 LSP 文件对比）获取代码变更
2. 对照需求分析文档判断变更是否满足验收标准
3. 按 P0 → P1 → P2 分级 Review：
   - P0：逻辑错误、XSS/CSRF/注入、类型不安全、性能泄漏
   - P1：可读性、错误处理、测试覆盖、重复代码
   - P2：命名一致性、代码风格、注释质量
4. 生成 Review Report 到 `.opencode/artifacts/code-review.md`
5. 如果存在 P0 问题，要求 Agent 自主修复并重新 Review
6. 如果全部通过（或仅 P2 问题），进入合并或下一步

## 约束
- MUST: 使用 git diff 获取变更（不依赖人工粘贴代码）
- MUST: 按 P0/P1/P2 三级分类问题
- MUST: 每个问题必须给出具体的代码位置和建议修复方案
- MUST: P0 问题必须修复后再合并
- MUST NOT: 仅做风格检查（需要涉及业务逻辑判断）
- MUST NOT: 完全依赖 AI 判断（最终决策由人工完成）

设计思路

这个 Skill 不依赖粘贴代码——Agent 会自动执行 git diff 获取变更内容。如果需要上下文，Agent 可以用 LSP 读取相关文件。Review 时还会对照需求分析的产出，判断代码是否偏离了原始需求。

  需要注意的一点：AI 擅长发现遗漏的边界处理和一致性问题，但不太擅长判断业务逻辑对错。所以 Skill 输出规定了”人做最终决策”，但 P0 问题 Agent 可以自主修复。

2.7 环节六：部署运维 Skill

部署运维与其他 Skill 最大的区别在于：它更依赖 MCP 工具。测试和 Review 主要操作文件系统，但部署需要调用 CI/CD 平台、云服务商 API、监控系统。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 文件名：.opencode/skills/deploy-ops/SKILL.md

## 适用场景
代码已合并到主分支，需要进行构建、部署、配置变更、或排查线上问题

## 输入
- 代码变更摘要（合并到主分支的 commit）
- 项目部署配置（从 CLAUDE.md 或 CI 配置文件读取）

## 输出
- 部署完成确认（或部署失败报告）
- 部署后验证结果
- 监控告警配置确认

## 执行步骤
1. 读取项目 CI/CD 配置文件（`.github/workflows/` 或 `.gitlab-ci.yml`）
2. 触发构建流水线（通过 GitHub MCP / GitLab MCP）
3. 监控构建状态，如果失败则分析日志并修复
4. 构建通过后，触发部署到目标环境
5. 部署完成后执行健康检查（HTTP 状态码 / 页面加载 / API 响应）
6. 检查监控告警是否正常配置
7. 输出部署报告到 `.opencode/artifacts/deploy-report.md`

## 约束
- MUST: 通过 MCP 工具触发 CI/CD，不手动执行命令
- MUST: 部署后执行健康检查验证
- MUST: 如果部署失败，自动回滚到上一个稳定版本
- MUST NOT: 直接修改生产环境配置（通过 IaC 工具或 CI 配置变更）
- MUST NOT: 跳过部署验证步骤

与其他 Skill 的区别

Skill 主要工具 MCP 依赖度
requirement-analysis Read / JIRA MCP 可选
tech-design Read / Write / LSP 低
coding Read / Write / LSP / Bash 低
test-generation Read / Write / Bash (npm test) 低
code-review git diff / LSP / Read 低
deploy-ops GitHub MCP / Cloud MCP / HTTP 高

  部署 Skill 是唯一一个默认就重度依赖 MCP 的环节。如果 Agent 环境没有配置 GitHub MCP 或云服务 MCP，这个 Skill 的效果会大打折扣。所以部署 Skill 的 SKILL.md 中应该额外注明前置依赖的 MCP 工具列表。

2.8 ⭐ 核心：Skill Workflow 编排

单个 Skill 解决了”这个环节怎么做”，但最强大的部分是把它们串成自动流水线。这正是 AGENTS.md 的作用。

完整 AGENTS.md 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# 文件名：AGENTS.md

# 研发效能 Workflow

## 流程说明
本项目将软件开发生命周期封装为一系列可编排的 Skill，Agent 按顺序自动执行。
每个 Skill 的输入/输出通过 `.opencode/artifacts/` 目录传递。

## Workflow 顺序

### Phase 1: 需求分析
- Skill: `.opencode/skills/requirement-analysis`
- 输入: JIRA Ticket / 需求文档
- 输出: `artifacts/requirement-analysis.md`
- Gate: ✅ 人工确认

### Phase 2: 技术设计
- Skill: `.opencode/skills/tech-design`
- 输入: `artifacts/requirement-analysis.md`
- 输出: `artifacts/tech-design.md`
- Gate: ✅ 人工确认

### Phase 3: 测试生成（TDD 前置）
- Skill: `.opencode/skills/test-generation`
- 输入: `artifacts/requirement-analysis.md` + `artifacts/tech-design.md`
- 输出: 测试文件（写入 src 目录）
- Gate: ⏭️ 无（自动进入编码）

### Phase 4: 编码实现
- Skill: `.opencode/skills/coding`
- 输入: `artifacts/requirement-analysis.md` + `artifacts/tech-design.md`
- 输出: 实现代码 + 测试通过
- Gate: ✅ 人工确认

### Phase 5: Code Review
- Skill: `.opencode/skills/code-review`
- 输入: git diff + `artifacts/requirement-analysis.md`
- 输出: `artifacts/code-review.md`
- Gate: ✅ 人工确认 + P0 问题修复

### Phase 6: 部署运维
- Skill: `.opencode/skills/deploy-ops`
- 输入: 合并后的主分支代码
- 输出: 部署确认 + 健康检查结果
- Gate: ✅ 最终确认

Skill 串联关系图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
┌──────────────────────────────────────────────┐
│              Agent 自动调度                     │
│  按 AGENTS.md 声明的 Workflow 顺序加载 Skill   │
└──────────────────────────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────┐
│  requirement-analysis                 │
│  读取 JIRA / 文档 → 输出功能点清单     │
└──────────────┬───────────────────────┘
               │
               ▼
        ╔════════════╗
        ║ 人工确认 Gate ║ ← 需求模糊？返回修改
        ╚════════════╝
               │
               ▼
┌──────────────────────────────────────┐
│  tech-design                          │
│  消费需求分析产出 → 输出方案对比+设计   │
└──────────────┬───────────────────────┘
               │
               ▼
        ╔════════════╗
        ║ 人工确认 Gate ║ ← 方案不满意？调整设计
        ╚════════════╝
               │
               ├─────────────────────────┐
               │                         │
               ▼                         ▼
┌──────────────────────┐    ┌──────────────────────┐
│  test-generation      │    │  coding              │
│  先生成测试(可选前置)   │    │  消费需求+设计 → 实现  │
└──────────┬───────────┘    └──────────┬───────────┘
           │                          │
           └──────────┬───────────────┘
                      ▼
               ╔════════════╗
               ║ 人工确认 Gate ║ ← 代码或测试有问题的
               ╚════════════╝
                      │
                      ▼
┌──────────────────────────────────────┐
│  code-review                          │
│  git diff + LSP → 分级 Review Report  │
└──────────────┬───────────────────────┘
               │
               ▼
        ╔════════════╗
        ║ 人工确认 Gate ║ ← P0 问题修复后合并
        ╚════════════╝
               │
               ▼
┌──────────────────────────────────────┐
│  deploy-ops                           │
│  MCP 触发 CI/CD + 健康检查             │
└──────────────────────────────────────┘

Agent 的自主决策

Skill Workflow 中最关键的概念是：Agent 自主决定每一步用什么工具。AGENTS.md 只规定”做什么”和”顺序”，不规定”用什么工具来做”。

举个例子，在 coding 阶段，Agent 会自问：

“我需要实现这个功能点。项目是 React 18 + TypeScript + Tailwind CSS。测试文件已经生成好了。我应该用什么方式写代码？”

然后 Agent 根据环境自主选择：

  • 如果当前环境是 Cursor，它会用 Composer 来生成代码（因为 Cursor Composer 支持多文件编辑）
  • 如果当前环境是 OpenCode，它可能会直接使用 Write 工具写文件
  • 如果有 LSP，它会在写完后用 LSP 检查语法

同样，在 review 阶段，Agent 会自己决定：

  • 用 git diff 获取变更 → 如果变更太多就分批 Review
  • 用 LSP 检查类型错误 → 看 tsconfig 是否严格模式
  • 用 Bash 运行 lint → 检查代码风格
  • 用 GitHub MCP 创建 Review Comment → 如果配置了 GitHub 集成

在部署阶段，Agent 的决策更加多样化：

  • 如果有 GitHub MCP → 触发 GitHub Actions Workflow Dispatch
  • 如果有 Vercel MCP → 调用 Vercel Deploy
  • 如果有阿里云 MCP → 同步到 OSS 并刷新 CDN

这就是 Skill 化与传统 Prompt 模板最根本的区别：Skill 告诉 Agent “做什么”和”不能做什么”，但”怎么做”由 Agent 根据环境自主决策。

2.9 Skill Workflow 的设计原则

把研发流程转化为 Skill Workflow 不是随手写几个 Skill 就行。以下是我在实践中总结的五条原则：

原则一：松耦合

每个 Skill 应该独立可运行，不依赖其他 Skill 的内部状态。Skill 之间的通信通过结构化文件（.opencode/artifacts/）完成，而不是通过内存变量或环境变量。

1
2
✅ 正确：coding → 读取 artifacts/requirement-analysis.md
❌ 错误：coding → 调用 requirement-analysis Skill 的内部函数

这样设计的好处是：你可以单独替换某个 Skill 而不影响其他环节。比如想换一种 Code Review 策略，只改 code-review Skill 就行。

原则二：明确 Gate

Gate（人工确认点）是 Skill Workflow 的刹车。每个 Gate 都是一次质量检查，也是人类的决策权所在。

推荐在以下位置设置 Gate：

位置 目的 跳过条件
需求分析后 确认功能点理解正确 需求极其明确
技术设计后 确认方案方向正确 改动极小，方案明显
编码完成后 确认代码质量和功能完整 —
Code Review 后 最终合并前检查 —
部署前 确认部署窗口和环境 紧急修复（Hotfix）

原则三：渐进式执行

Agent 不需要一次加载所有 Skill。AGENTS.md 定义了完整的 Workflow，但 Agent 只加载当前步骤对应的 Skill。这带来了三个好处：

  1. 上下文窗口不浪费 — 一个 Skill 的 SKILL.md 通常只有 50-80 行，远低于一整套 Prompt 模板
  2. 执行速度快 — Agent 不需要在需求分析阶段就加载部署 Skill 的规则
  3. 按需追加 — 如果某个环节需要补充规则，只修改对应的 SKILL.md

原则四：可跳过

不是所有开发任务都需要走完整流程。紧急 Bug 修复就应该绕过需求分析和设计阶段。

实现方式：在 AGENTS.md 中标注每个 Phase 的 skipable 属性，或通过指令参数控制：

1
2
3
4
> 修复用户登录页的 500 错误
→ Agent 检测到这是紧急 Bug 修复
→ 自动跳过 requirement-analysis 和 tech-design
→ 直接加载 coding + test-generation + code-review

原则五：输入输出契约

这是最容易被忽视但最重要的原则。每个 Skill 的输入/输出必须显式声明并且格式一致。如果 requirement-analysis 输出的功能点格式是：

1
2
3
## FP-001: 用户登录
- 优先级: P0
- 验收标准: Given... When... Then...

那么 coding Skill 和 test-generation Skill 都必须能消费这个格式。建议在项目级别定义一份Artifact 规范（放在 .opencode/artifacts/README.md），约定所有 Skill 产出的文件结构和 Markdown 格式。

2.10 真实场景：从 JIRA 到 MR 的全自动 Skill 流水线

理论讲了这么多，来看看在实际项目中Agent 如何自动跑完整条流水线。

场景设定

你是一名前端工程师，收到一个 JIRA Ticket：

Ticket: FRONT-2345
标题: 在用户个人中心增加实名认证功能
描述: 用户在个人中心可以看到实名认证入口，提交姓名和身份证号进行认证。认证通过后展示已认证状态和脱敏后的身份信息。需要对接第三方实名认证服务。

第一步：Agent 收到 Ticket

你在聊天窗口说：

“处理 FRONT-2345”

Agent 解析这个消息，判断这是新功能开发，需要走完整 Workflow。它读取 AGENTS.md 找到第一个 Phase，然后加载 requirement-analysis Skill。

第二步：加载需求分析 Skill

Agent 读取 requirement-analysis/SKILL.md，看到执行步骤：

  1. 读取需求输入 → Agent 调用 JIRA MCP 的 jira_getIssue("FRONT-2345") 拉取 Ticket 详情
  2. 拆解功能点 → Agent 分析需求文本，识别出 5 个 P0 功能点
  3. 编写验收标准 → 为每个功能点写 Given/When/Then
  4. 识别模糊点 → 发现 4 个待确认问题：
1
2
3
4
5
## 待确认问题
1. 身份证号脱敏展示几位？通常前6+后4，需确认
2. 认证失败的错误信息是否展示给用户？
3. 第三方认证服务是否有沙箱环境？
4. 实名认证是否需要与已有用户信息打通？
  1. 技术可行性评估 → 判断身份证校验、第三方 API 对接的复杂度
  2. 输出文档 → 写入 .opencode/artifacts/requirement-analysis.md
  3. 等待确认 → Agent 输出总结并问你：”以上功能点拆解和模糊点确认，是否有需要调整的地方？”

你确认后，Agent 进入下一环节。

第三步：加载技术设计 Skill

Agent 读取 tech-design/SKILL.md，开始设计：

  1. 读取需求分析产出 → 从 artifacts/requirement-analysis.md 获取功能点
  2. 分析技术约束 → 从 CLAUDE.md 读取技术栈（React 18 + Ant Design + TypeScript）
  3. 生成方案对比 → Agent 输出 2-3 个方案并推荐最合适的

这时 Agent 可能会问自己：”这个项目用了 Ant Design，我应该用什么方案来做表单校验？” 然后它决定用 Ant Design Form + 自定义校验规则，并在设计文档中说明理由。

  1. 输出设计文档 → 写入 .opencode/artifacts/tech-design.md
  2. 等待确认 → “方案已输出，请确认设计方向”

第四步：加载测试生成 Skill

你确认设计后，Agent 自动加载 test-generation Skill：

  1. 读取验收标准 → 从需求分析产出中获取每个功能点的验收标准
  2. 分析测试场景 → 识别正常路径、边界值、异常路径
  3. 生成测试文件 → 写入 src/components/CertifyForm.test.tsx

Agent 自己决定用 Vitest + Testing Library（因为它检测到项目中配置了这些工具）。它还会检查已有的测试风格，保持一致。

第五步：加载编码 Skill

测试文件已就位。Agent 加载 coding Skill：

  1. 读取输入 → 自动读取需求分析和技术设计文档
  2. 检查测试是否存在 → 发现 CertifyForm.test.tsx 存在，进入 TDD 模式
  3. 实现第一个功能点 → 编写认证入口按钮组件
  4. 运行测试验证 → npm run test，通过
  5. 下一个功能点 → 认证表单组件
  6. 重复 → 直到所有功能点实现完成

Agent 的决策过程在这里非常明显：

  • 是否需要新文件？ → Agent 检查是否应该新建组件还是修改现有文件
  • 代码风格统一？ → Agent 读取已有组件的写法，保持一致性
  • 依赖管理？ → 如果需要新依赖，Agent 会用 npm install 添加

所有功能点通过测试后，Agent 输出变更摘要并等待确认。

第六步：加载 Code Review Skill

你确认代码后（或 Agent 自动触发下一环节），Agent 加载 code-review Skill：

  1. 获取变更 → git diff 查看所有改动
  2. 对照需求 → 检查实现是否覆盖了需求分析中的全部验收标准
  3. 分级 Review →

Agent 自己决定 Review 策略：

  • 用 LSP 检查类型错误 → 扫描所有新增 TypeScript 文件
  • 用 Bash 运行 npm run lint → 检查代码风格
  • 用 git diff 分析逻辑变更 → 判断是否有潜在问题
  1. 输出 Review Report → P0/P1/P2 分级问题
  2. 如果存在 P0 问题 → Agent 自主修复并重新 Review
  3. 等待最终确认

第七步：加载部署运维 Skill

Review 通过后，Agent 加载 deploy-ops Skill：

  1. 触发 CI/CD → 通过 GitHub MCP 调用 GitHub Actions
  2. 监控构建状态 → 轮询 Action 运行状态
  3. 健康检查 → 部署后请求目标 URL 确认服务正常
  4. 输出部署报告

这个阶段 Agent 的自主决策能力最突出：

  • 如果用 GitHub MCP → github_actions_triggerWorkflow
  • 如果用 GitLab CI → 调用对应的 Pipeline API
  • 如果用自建 Jenkins → 通过 Jenkins API 触发

Agent 根据项目 CI 配置自动选择调用方式。

完整流程时间线

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
09:00  →  你: "处理 FRONT-2345"
09:01  →  Agent 加载 requirement-analysis Skill
09:03  →  Agent 输出功能点清单 + 模糊点
          你确认 ✅
09:05  →  Agent 加载 tech-design Skill
09:08  →  Agent 输出方案对比 + 设计文档
          你确认 ✅
09:10  →  Agent 加载 test-generation Skill
09:12  →  测试文件写入完成
09:12  →  Agent 加载 coding Skill（自动开始编码）
09:25  →  全部功能点实现完成，测试通过 ✅
09:25  →  Agent 加载 code-review Skill
09:28  →  Review 完成，无 P0 问题
          你确认 ✅
09:30  →  Agent 合并 MR + 加载 deploy-ops Skill
09:32  →  CI/CD 触发，部署完成
09:33  →  健康检查通过 ✅

总耗时：33 分钟
你实际参与：3 次确认，约 2 分钟

对比传统流程

维度 传统 Prompt 方式 Skill 化 Workflow
启动方式 你在每个环节写 Prompt 你说一句”处理这个 Ticket”
流程切换 你手动复制粘贴上下文 Agent 自动读取 artifacts
工具选择 你告诉 AI 用什么 Agent 自主选择
一致性 每次 Prompt 质量看状态 固化在 SKILL.md 中，稳定输出
人工参与 每个环节你都在操作 只在 Gate 做决策确认
上下文 每个环节重新描述上下文 Agent 按需加载 Skill

小结

这篇文章的核心思想很简单：不要教 AI 怎么做事——把你做事的方法写成 Skill，让 AI 自己去执行。

把研发流程 Skill 化后，你得到的是一个可编排、可复用、可跳过、渐进式执行的自动化流水线。每个 Skill 封装了一个环节的最佳实践，AGENTS.md 将它们串联成端到端的工作流，Agent 自主选择工具完成每个步骤。

这种模式不仅适用于本文章覆盖的六个环节（需求分析 → 技术设计 → 编码 → 测试 → Code Review → 部署），你也可以为项目规范检查、性能优化、Changelog 生成、依赖升级等任何重复性流程编写 Skill。

下一节将深入讲解 Cursor 的具体使用技巧，包括三种模式（Chat / Composer / Agent）的实际应用场景和最佳实践。不过，在掌握 Cursor 之前，先把项目的 Skill 体系搭建好——这才是 AI 时代前端工程师真正需要掌握的”提效思维”。