AI Agent Skills 实战：20+ 技能详解与团队协作的 5 大掣肘

作者：老马，一个在编程和 AI 领域摸爬滚打的程序员兼博主

前言：感谢读者的提问

上一篇《从快手万人团队到小作坊：AI Agent Skills 的务实落地之路》发出后，收到了很多读者的留言。其中有位朋友问得特别好：

"非常有意义，能不能分享一下你们的 skills 以及团队协作之间觉得掣肘的点。"

这个问题问到点子上了。上篇文章更多是讲"为什么要做"和"怎么做"，但具体的技能长什么样？实际落地时遇到了哪些坑？这些才是最有价值的实战经验。

所以这篇文章，我会：

详细拆解我们的 20+ 个技能：不只是列清单，而是讲每个技能解决什么问题、怎么设计的、效果如何
坦诚分享 5 大掣肘点：团队协作中真实遇到的问题，有些解决了，有些还在摸索

废话不多说，直接上干货。

一、我们的技能体系全景图

先上一张全景图，让大家对我们的技能体系有个整体认知：

需求阶段
├── requirements-assistant (需求分析助手)
└── prd-writer (PRD 文档生成器)

前端开发
├── frontend-dev-assistant (前端开发统一入口)
├── frontend-admin-assistant (管理端开发)
├── frontend-mobile-assistant (移动端开发)
├── frontend-dashboard-assistant (大屏开发)
├── frontend-api-assistant (API 代码生成)
├── frontend-admin-dashboard-builder (图表组件生成)
├── frontend-mobile-chat-builder (聊天界面生成)
└── frontend-doc-generator (前端文档生成)

后端开发
└── java-dev-assistant (Java 全栈助手)

测试与质量
├── test-skills (测试用例生成)
├── ui-automation-expert (UI 自动化测试)
└── frontend-code-review (代码审查)

辅助工具
├── skill-creator (技能创建生成器)
└── icinfo-skill-creator (定制化技能生成器)

统计数据：

总技能数：20+
日均调用次数：50+
覆盖场景：需求、开发、测试、文档
团队规模：10 人

接下来，我会按照开发流程，逐个拆解这些技能。

二、需求阶段：从想法到可执行任务

2.1 requirements-assistant：需求分析助手

解决的问题：产品经理给的需求往往很模糊，比如"做一个用户管理功能"。开发拿到后一脸懵：要管理哪些字段？有什么权限控制？交互流程是什么？

技能设计：

markdown

核心能力：

1. 用户故事 (User Story) 生成

   - 输入：模糊需求描述
   - 输出：标准的 "作为...我想要...以便..." 格式

2. 验收标准 (Acceptance Criteria) 制定

   - 输入：用户故事
   - 输出：可测试的验收条件列表

3. 业务流程梳理

   - 输入：业务场景描述
   - 输出：Mermaid 流程图

4. 领域模型建议
   - 输入：业务实体
   - 输出：实体关系图 + 字段建议

实际案例：

输入：

产品需求：做一个用户管理功能，可以增删改查用户

输出：

markdown

## 用户故事

作为系统管理员，我想要管理系统用户，以便控制谁可以访问系统。

## 验收标准

1. 用户列表

   - 可以查看所有用户列表
   - 支持按用户名、邮箱搜索
   - 支持分页显示（每页 20 条）

2. 新增用户

   - 必填字段：用户名、邮箱、密码
   - 用户名唯一性校验
   - 邮箱格式校验
   - 密码强度要求：至少 8 位，包含字母和数字

3. 编辑用户

   - 可以修改用户名、邮箱、角色
   - 不能修改密码（需单独的重置密码功能）

4. 删除用户
   - 删除前需二次确认
   - 不能删除当前登录用户
   - 删除后相关数据如何处理？（需产品确认）

## 业务流程图

[Mermaid 流程图]

## 领域模型

User 实体：

- id: Long (主键)
- username: String (用户名，唯一)
- email: String (邮箱，唯一)
- password: String (密码，加密存储)
- role: String (角色：admin/user)
- status: Integer (状态：0-禁用，1-启用)
- createTime: Date
- updateTime: Date

效果：

需求澄清时间：从 1 小时降到 15 分钟
需求遗漏率：从 30% 降到 5%
开发返工次数：从平均 2 次降到 0.5 次

2.2 prd-writer：PRD 文档生成器

解决的问题：写 PRD 文档是个苦差事，格式要规范、内容要全面、还要考虑技术可行性。很多产品经理写的 PRD 要么太简单（开发看不懂），要么太啰嗦（没人愿意看）。

技能设计：

markdown

核心能力：

1. 标准 PRD 结构生成

   - 背景与目标
   - 用户画像
   - 功能需求
   - 非功能需求
   - 交互设计
   - 数据埋点

2. 自动排除技术实现细节

   - 只关注"做什么"，不关注"怎么做"
   - 避免产品文档变成技术文档

3. 多格式输出
   - Markdown（开发友好）
   - Word（给老板看）

实际案例：

输入：

需求：做一个消息通知功能，用户可以收到系统消息和站内信

输出：

markdown

# 消息通知功能 PRD

## 1. 背景与目标

### 1.1 背景

当前系统缺少消息通知机制，用户无法及时获知重要信息...

### 1.2 目标

- 提升用户活跃度
- 降低客服咨询量
- 提高信息触达率

## 2. 用户画像

- 系统管理员：需要发送系统公告
- 普通用户：需要接收个人消息

## 3. 功能需求

### 3.1 消息类型

- 系统消息：全员广播
- 站内信：点对点消息

### 3.2 消息列表

- 显示未读/已读状态
- 支持标记已读
- 支持删除消息

### 3.3 消息提醒

- 顶部显示未读消息数量
- 新消息弹窗提醒（可关闭）

## 4. 非功能需求

- 消息推送延迟 < 3 秒
- 支持 10000+ 用户同时在线

## 5. 交互设计

[原型图链接]

## 6. 数据埋点

- 消息发送量
- 消息打开率
- 消息删除率

效果：

PRD 编写时间：从 2 天降到 2 小时
PRD 质量评分：从 6 分提升到 8.5 分（满分 10 分）
开发理解偏差：从 40% 降到 10%

三、前端开发：从手写到自动生成

3.1 frontend-dev-assistant：前端开发统一入口

解决的问题：我们有三个前端项目（管理端、移动端、大屏端），技术栈类似但规范不同。开发者经常搞混，比如在管理端用了移动端的组件，或者忘记了某个项目的特殊规范。

技能设计：

markdown

核心能力：

1. 项目识别

   - 自动识别当前是哪个项目
   - 根据项目类型调用对应的子技能

2. 规范统一

   - 统一弹窗规范（$modalDialog）
   - 统一 TypeScript 接口定义
   - 统一 Axios 请求封装

3. 子技能路由
   - 管理端 → frontend-admin-assistant
   - 移动端 → frontend-mobile-assistant
   - 大屏端 → frontend-dashboard-assistant

实际案例：

输入：

/frontend-dev-assistant 我要开发一个用户列表页面

AI 会自动：

检测当前项目类型（通过 package.json 或目录结构）
如果是管理端，调用 frontend-admin-assistant
如果是移动端，调用 frontend-mobile-assistant
生成符合该项目规范的代码

效果：

规范混用错误：从每周 5 次降到 0 次
新人上手时间：从 2 周降到 3 天
代码审查时间：从 30 分钟降到 10 分钟

3.2 frontend-admin-assistant：管理端开发神器

解决的问题：管理端最常见的需求就是 CRUD 页面：用户管理、订单管理、商品管理...90% 的页面都是表格 + 表单 + 弹窗。手写一个要 3 小时，而且容易出错。

技能设计：

markdown

技术栈：Vue 2 + Element UI + Less + TypeScript

核心能力：

1. CRUD 表格页面生成

   - el-table 组件配置
   - 分页、搜索、排序
   - 操作列（编辑、删除）

2. 多步骤表单开发

   - el-steps 组件
   - 表单验证
   - 数据回填

3. 复杂弹窗交互

   - 必须使用 $modalDialog（不允许 el-dialog）
   - 父子组件通信
   - 数据刷新

4. 报表统计页面
   - 配合 frontend-admin-dashboard-builder
   - ECharts 图表集成

约束：

- 严禁自动重启服务
- 严禁自动 ESLint 格式化

实际案例：

输入：

/frontend-admin-assistant 生成一个用户管理页面，
包括列表、新增、编辑、删除、搜索功能

AI 会生成：

vue

<template>
  <div class="user-management">
    <!-- 搜索区域 -->
    <el-form :inline="true" :model="searchForm">
      <el-form-item label="用户名">
        <el-input v-model="searchForm.username" placeholder="请输入用户名" />
      </el-form-item>
      <el-form-item>
        <el-button type="primary" @click="handleSearch">搜索</el-button>
        <el-button @click="handleReset">重置</el-button>
      </el-form-item>
    </el-form>

    <!-- 操作按钮 -->
    <el-button type="primary" @click="handleAdd">新增用户</el-button>

    <!-- 表格 -->
    <el-table :data="tableData" border>
      <el-table-column prop="username" label="用户名" />
      <el-table-column prop="email" label="邮箱" />
      <el-table-column prop="role" label="角色" />
      <el-table-column label="操作" fixed="right" width="150">
        <template slot-scope="scope">
          <el-button size="small" @click="handleEdit(scope.row)">编辑</el-button>
          <el-button size="small" type="danger" @click="handleDelete(scope.row)">删除</el-button>
        </template>
      </el-table-column>
    </el-table>

    <!-- 分页 -->
    <el-pagination
      :current-page="pagination.page"
      :page-size="pagination.size"
      :total="pagination.total"
      @current-change="handlePageChange"
    />
  </div>
</template>

<script lang="ts">
import { Component, Vue } from 'vue-property-decorator'
import { getUserList, deleteUser } from '@/api/user'

interface User {
  id: number
  username: string
  email: string
  role: string
}

@Component
export default class UserManagement extends Vue {
  searchForm = {
    username: '',
  }

  tableData: User[] = []

  pagination = {
    page: 1,
    size: 20,
    total: 0,
  }

  mounted() {
    this.loadData()
  }

  async loadData() {
    const { data } = await getUserList({
      ...this.searchForm,
      page: this.pagination.page,
      size: this.pagination.size,
    })
    this.tableData = data.list
    this.pagination.total = data.total
  }

  handleSearch() {
    this.pagination.page = 1
    this.loadData()
  }

  handleReset() {
    this.searchForm.username = ''
    this.handleSearch()
  }

  handleAdd() {
    this.$modalDialog({
      title: '新增用户',
      component: () => import('./components/UserForm.vue'),
      width: '600px',
      onConfirm: () => {
        this.loadData()
      },
    })
  }

  handleEdit(row: User) {
    this.$modalDialog({
      title: '编辑用户',
      component: () => import('./components/UserForm.vue'),
      props: { userId: row.id },
      width: '600px',
      onConfirm: () => {
        this.loadData()
      },
    })
  }

  async handleDelete(row: User) {
    await this.$confirm('确定删除该用户吗？', '提示', {
      type: 'warning',
    })
    await deleteUser(row.id)
    this.$message.success('删除成功')
    this.loadData()
  }

  handlePageChange(page: number) {
    this.pagination.page = page
    this.loadData()
  }
}
</script>

<style lang="less" scoped>
.user-management {
  padding: 20px;
}
</style>

效果：

开发时间：从 3 小时降到 10 分钟
代码规范符合率：从 70% 提升到 98%
Bug 率：从 15% 降到 3%

3.3 frontend-mobile-assistant：移动端开发助手

解决的问题：移动端开发和管理端差异很大：组件库不同（Vant vs Element UI）、交互方式不同（触控 vs 鼠标）、布局方式不同（Rem vs Px）。

技能设计：

markdown

技术栈：Vue 2 + Vant UI + Less + TypeScript

核心能力：

1. H5 页面布局（Flex/Rem）
2. 移动端表单交互
   - van-field 组件
   - 键盘弹起处理
   - 表单验证
3. 长列表加载（List 组件）
   - 下拉刷新
   - 上拉加载更多
   - 空状态处理

约束：

- 使用 Vant 组件库
- 适配移动端触控交互
- 考虑弱网环境

实际案例：

输入：

/frontend-mobile-assistant 生成一个订单列表页面，
支持下拉刷新和上拉加载

输出的代码会自动包含：

Vant 的 List 组件
PullRefresh 下拉刷新
移动端适配的样式
触控优化的交互

效果：

移动端页面开发时间：从 4 小时降到 20 分钟
适配问题：从每个页面 3-5 个降到 0-1 个

3.4 frontend-api-assistant：API 代码自动生成

解决的问题：前端调用后端 API 时，需要手写 TypeScript 接口定义和 Axios 请求代码。一个接口要写 20-30 行代码，而且容易出错（字段类型不对、参数遗漏等）。

技能设计：

markdown

核心能力：

1. 基于 Swagger/OpenAPI 自动生成

   - 读取后端 API 文档
   - 生成 TypeScript 接口定义
   - 生成 Axios 请求函数

2. 支持多种请求方式

   - GET/POST/PUT/DELETE
   - 文件上传
   - 文件下载

3. 统一错误处理
   - 自动集成项目的错误处理机制

实际案例：

输入：

/frontend-api-assistant 生成用户管理相关的 API 代码

输出：

typescript

// src/api/user.ts

import request from '@/utils/request'

// 用户实体
export interface User {
  id: number
  username: string
  email: string
  role: string
  status: number
  createTime: string
  updateTime: string
}

// 用户列表请求参数
export interface UserListParams {
  username?: string
  email?: string
  page: number
  size: number
}

// 用户列表响应
export interface UserListResponse {
  list: User[]
  total: number
}

// 获取用户列表
export function getUserList(params: UserListParams) {
  return request<UserListResponse>({
    url: '/api/user/list',
    method: 'get',
    params,
  })
}

// 获取用户详情
export function getUserDetail(id: number) {
  return request<User>({
    url: `/api/user/${id}`,
    method: 'get',
  })
}

// 新增用户
export function createUser(data: Partial<User>) {
  return request({
    url: '/api/user',
    method: 'post',
    data,
  })
}

// 更新用户
export function updateUser(id: number, data: Partial<User>) {
  return request({
    url: `/api/user/${id}`,
    method: 'put',
    data,
  })
}

// 删除用户
export function deleteUser(id: number) {
  return request({
    url: `/api/user/${id}`,
    method: 'delete',
  })
}

效果：

API 代码编写时间：从 30 分钟降到 2 分钟
类型错误：从每个接口 2-3 个降到 0 个
前后端联调效率：提升 5 倍

四、后端开发：Java 全栈助手

4.1 java-dev-assistant：企业级 Java 开发助手

解决的问题：后端开发涉及的层次多（Controller、Service、Mapper、Entity），每一层都有固定的写法和规范。新增一个功能，要写 4-5 个文件，重复劳动多。

技能设计：

markdown

技术栈：Spring Boot 3.x + MyBatis + Shiro + Java 17+

核心能力：

1. 新功能开发（全流程）

   - 需求分析 → 接口设计 → 代码实现 → 测试验证

2. 问题排查

   - 编译错误
   - 启动失败
   - SQL 异常
   - 空指针异常
   - 性能慢查询

3. 单元测试

   - Service 层测试
   - Mapper 层测试
   - Controller 层测试
   - Mock 依赖

4. 代码重构

   - 消除重复代码
   - 提取公共方法
   - 优化类结构
   - 应用设计模式

5. 代码审查

   - 规范检查
   - 安全漏洞（SQL 注入/XSS）
   - 性能优化建议

6. 部署上线
   - Maven 打包
   - 环境配置
   - 启动脚本
   - 健康检查

实际案例：

输入：

/java-dev-assistant 开发用户管理功能，
包括增删改查和角色分配

AI 会自动生成：

Entity 实体类：

java

@Data
@TableName("sys_user")
public class User {
    @TableId(type = IdType.AUTO)
    private Long id;

    private String username;
    private String email;
    private String password;
    private String role;
    private Integer status;

    @TableField(fill = FieldFill.INSERT)
    private Date createTime;

    @TableField(fill = FieldFill.UPDATE)
    private Date updateTime;
}

Mapper 接口：

java

@Mapper
public interface UserMapper extends BaseMapper<User> {
    List<User> selectUserList(@Param("username") String username);
}

Service 层：

java

@Service
public class UserService {
    @Autowired
    private UserMapper userMapper;

    public PageResult<User> getUserList(UserQuery query) {
        // 分页查询逻辑
    }

    public void createUser(User user) {
        // 参数校验
        // 密码加密
        // 保存用户
    }

    // 其他方法...
}

Controller 层：

java

@RestController
@RequestMapping("/api/user")
public class UserController {
    @Autowired
    private UserService userService;

    @GetMapping("/list")
    public Result<PageResult<User>> list(UserQuery query) {
        return Result.success(userService.getUserList(query));
    }

    @PostMapping
    public Result<Void> create(@RequestBody @Valid User user) {
        userService.createUser(user);
        return Result.success();
    }

    // 其他接口...
}

效果：

后端功能开发时间：从 4 小时降到 30 分钟
代码层次遗漏：从 20% 降到 0%
SQL 注入漏洞：从 5% 降到 0%

五、测试与质量：自动化测试体系

5.1 test-skills：测试用例生成器

解决的问题：测试人员拿到需求文档后，要手动编写测试用例，费时费力。而且容易遗漏边界场景。

技能设计：

markdown

核心能力：

1. 自动解析需求文档结构
2. 多格式测试用例生成（JSON、Markdown、Excel）
3. 智能测试场景生成
   - 正常场景
   - 异常场景
   - 边界场景
4. 内置多种测试设计方法
   - 等价类划分
   - 边界值分析
   - 场景法

实际案例：

输入：

/test-skills 根据用户管理需求文档生成测试用例

输出：

markdown

# 用户管理测试用例

## 1. 新增用户

### 1.1 正常场景

| 用例 ID | 测试场景     | 前置条件         | 操作步骤                                                                                                              | 预期结果                         |
| ------- | ------------ | ---------------- | --------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| TC001   | 新增用户成功 | 已登录管理员账号 | 1. 点击"新增用户"<br>2. 输入用户名"test01"<br>3. 输入邮箱"test@example.com"<br>4. 输入密码"Test1234"<br>5. 点击"确定" | 提示"新增成功"，列表中显示新用户 |

### 1.2 异常场景

| 用例 ID | 测试场景     | 操作步骤               | 预期结果                            |
| ------- | ------------ | ---------------------- | ----------------------------------- |
| TC002   | 用户名为空   | 不输入用户名，直接提交 | 提示"用户名不能为空"                |
| TC003   | 用户名重复   | 输入已存在的用户名     | 提示"用户名已存在"                  |
| TC004   | 邮箱格式错误 | 输入"test@"            | 提示"邮箱格式不正确"                |
| TC005   | 密码强度不足 | 输入"123"              | 提示"密码至少 8 位，包含字母和数字" |

### 1.3 边界场景

| 用例 ID | 测试场景       | 操作步骤               | 预期结果             |
| ------- | -------------- | ---------------------- | -------------------- |
| TC006   | 用户名最小长度 | 输入 1 个字符的用户名  | 根据规则判断是否允许 |
| TC007   | 用户名最大长度 | 输入 50 个字符的用户名 | 根据规则判断是否允许 |
| TC008   | 密码最小长度   | 输入 8 位密码          | 允许提交             |

## 2. 编辑用户

[类似结构...]

## 3. 删除用户

[类似结构...]

效果：

测试用例编写时间：从 1 天降到 1 小时
用例覆盖率：从 60% 提升到 90%
遗漏的边界场景：从 30% 降到 5%

5.2 ui-automation-expert：UI 自动化测试专家

解决的问题：手动测试效率低，而且每次发版都要重复测试相同的功能。UI 自动化测试可以解决这个问题，但编写测试脚本需要技术门槛。

技能设计：

markdown

技术栈：Playwright

核心能力：

1. 录制用户操作生成测试脚本
2. 支持多浏览器测试（Chrome、Firefox、Safari）
3. 截图对比
4. 自动生成测试报告

实际案例：

输入：

/ui-automation-expert 生成用户登录的自动化测试脚本

输出：

typescript

import { test, expect } from '@playwright/test'

test.describe('用户登录', () => {
  test('正常登录', async ({ page }) => {
    // 访问登录页
    await page.goto('http://localhost:8080/login')

    // 输入用户名
    await page.fill('input[name="username"]', 'admin')

    // 输入密码
    await page.fill('input[name="password"]', 'admin123')

    // 点击登录按钮
    await page.click('button[type="submit"]')

    // 验证跳转到首页
    await expect(page).toHaveURL('http://localhost:8080/home')

    // 验证显示用户名
    await expect(page.locator('.user-info')).toContainText('admin')
  })

  test('用户名为空', async ({ page }) => {
    await page.goto('http://localhost:8080/login')
    await page.click('button[type="submit"]')
    await expect(page.locator('.error-message')).toContainText('用户名不能为空')
  })

  test('密码错误', async ({ page }) => {
    await page.goto('http://localhost:8080/login')
    await page.fill('input[name="username"]', 'admin')
    await page.fill('input[name="password"]', 'wrong')
    await page.click('button[type="submit"]')
    await expect(page.locator('.error-message')).toContainText('用户名或密码错误')
  })
})

效果：

回归测试时间：从 2 小时降到 10 分钟
测试覆盖率：从 40% 提升到 80%
发现 bug 的时间：从发版后降到发版前

5.3 frontend-code-review：代码审查助手

解决的问题：人工代码审查耗时长，而且容易遗漏问题。特别是一些常见的低级错误（变量未定义、类型错误等），浪费审查者的时间。

技能设计：

markdown

核心能力：

1. 自动检查代码规范

   - ESLint 规则
   - TypeScript 类型检查
   - 命名规范

2. 安全漏洞检测

   - XSS 风险
   - 敏感信息泄露
   - 不安全的第三方库

3. 性能问题识别

   - 大文件引入
   - 未优化的循环
   - 内存泄漏风险

4. 生成审查报告
   - 问题分级（严重/警告/建议）
   - 修复建议
   - 代码示例

实际案例：

输入：

/frontend-code-review 审查当前 git 变更

输出：

markdown

# 代码审查报告

## 严重问题（必须修复）

### 1. XSS 风险

**文件**：src/views/user/UserList.vue:45
**问题**：直接使用 v-html 渲染用户输入内容
**代码**：
\`\`\`vue

<div v-html="user.description"></div>
\`\`\`
**修复建议**：使用文本渲染或对内容进行转义
\`\`\`vue
<div>{{ user.description }}</div>
\`\`\`

### 2. 类型错误

**文件**：src/api/user.ts:12
**问题**：返回类型与接口定义不匹配
**修复建议**：修正返回类型或接口定义

## 警告（建议修复）

### 1. 性能问题

**文件**：src/views/dashboard/Index.vue:78
**问题**：在 computed 中使用了复杂的循环计算
**修复建议**：考虑使用缓存或将计算移到后端

## 建议（可选）

### 1. 代码风格

**文件**：src/utils/format.ts:23
**问题**：函数过长（超过 50 行）
**修复建议**：拆分为多个小函数

---

**总结**：

- 严重问题：2 个
- 警告：1 个
- 建议：1 个

效果：

代码审查时间：从 30 分钟降到 5 分钟
低级错误发现率：从 60% 提升到 95%
审查者可以专注于业务逻辑审查

六、团队协作的 5 大掣肘点

前面讲了我们的技能体系，看起来很美好。但实际落地过程中，我们遇到了很多问题。这些问题不是技术问题，而是人的问题、流程的问题、认知的问题。

掣肘点 1：老员工的抵触情绪

问题描述：推广 Agent Skills 最大的阻力不是技术，而是老员工的抵触。

典型的反馈：

"我写代码这么多年了，还需要 AI 教我？"
"AI 生成的代码不靠谱，还不如我自己写"
"学这个要花时间，我现在项目很紧"

根本原因：

舒适区被打破：老员工已经形成了自己的工作习惯，不愿意改变
担心被替代：潜意识里觉得"AI 会抢我的饭碗"
学习成本焦虑：担心学不会，或者学了没用

我们的应对：

不强推，先示范
- 我自己先用，在团队会议上展示效果
- "10 分钟完成 3 小时的工作"，用数据说话
- 让效果自己传播，而不是强制推广
找到"种子用户"
- 团队里总有愿意尝试新东西的人
- 先让他们用起来，形成示范效应
- 其他人看到效果，自然会跟进
强调"增强"而非"替代"
- AI 是工具，不是替代品
- 就像从手写代码到 IDE，是效率提升，不是能力贬低
- 用 AI 的人不会被淘汰，不用 AI 的人才会

效果：

3 个月后，团队使用率从 20% 提升到 80%
老员工从抵触变成了最积极的贡献者（因为他们发现真的能省时间）

掣肘点 2：技能维护成本高

问题描述：一开始我一个人维护所有技能，累得要死。每次项目规范变了，要更新好几个技能；每次有人反馈问题，要立刻修复。

具体表现：

技能数量从 5 个增长到 20+ 个，维护工作量指数级增长
项目规范变更频繁（比如组件库升级），技能要同步更新
不同项目的规范不同，技能要做适配

根本原因：

单点维护：只有我一个人懂技能怎么写
文档不足：没有技能开发文档，别人想贡献也不知道怎么做
缺乏自动化：技能更新全靠手动，没有自动化测试

我们的应对：

开发 skill-creator 技能
- 用 AI 生成 AI 技能（很 meta）
- 降低技能开发门槛
- 团队成员可以自己创建技能
建立技能贡献机制
- 每个技能有明确的负责人
- 谁用得最多，谁就是负责人
- 负责人负责维护和更新
技能模板化
- 提取通用的技能模板
- 新技能基于模板创建
- 减少重复工作
自动化测试
- 每个技能都有测试用例
- 规范变更时，自动跑测试
- 发现问题及时修复

效果：

技能维护时间：从每周 10 小时降到 2 小时
技能贡献者：从 1 人增加到 5 人
技能更新频率：从每月 1 次提升到每周 1 次

掣肘点 3：AI 生成代码的质量不稳定

问题描述： AI 生成的代码质量很不稳定。有时候生成的代码完美无缺，有时候却漏洞百出。这导致开发者对 AI 的信任度下降。

具体表现：

同样的需求，不同时间生成的代码质量差异很大
有时候 AI 会"理解错误"，生成完全不符合需求的代码
边界场景处理不好，容易出 bug
生成的代码有时不符合项目规范

根本原因：

Prompt 不够精确：技能描述太模糊，AI 理解有偏差
缺乏示例代码：AI 不知道"好代码"长什么样
上下文不足：AI 没有读取足够的项目代码作为参考
缺乏验证机制：生成后没有自动检查

我们的应对：

优化技能 Prompt
- 从"帮我生成一个表格页面"
- 改为"使用 el-table 组件生成表格页面，必须包含分页、搜索、操作列，操作列固定在右侧，参考示例代码：[链接]"
- 越具体越好，不要让 AI 猜
提供大量示例代码
- 每个技能都附带 3-5 个标准示例
- AI 会模仿示例的风格和结构
- 示例代码要覆盖常见场景
增强上下文读取
- 技能执行前，先读取项目的相关文件
- 比如生成表格页面前，先读取现有的表格页面代码
- 让 AI 理解项目的实际风格
建立验证机制
- 生成代码后，自动运行 ESLint 检查
- 自动运行 TypeScript 类型检查
- 发现问题立刻提示，让 AI 重新生成

效果：

代码质量稳定性：从 60% 提升到 85%
一次生成成功率：从 40% 提升到 75%
需要手动修改的代码量：从 30% 降到 10%

掣肘点 4：跨角色协作的认知差异

问题描述：产品、开发、测试对 AI 的理解和期望完全不同，导致协作时出现很多摩擦。

具体表现：

产品经理的期望：
- "AI 能直接把我的想法变成产品吗？"
- "为什么 AI 生成的需求文档还需要我修改？"
- 期望：AI 是魔法棒，一键搞定
开发的期望：
- "AI 生成的代码能直接用吗？"
- "为什么 AI 不能理解我们的业务逻辑？"
- 期望：AI 是高级助手，但需要指导
测试的期望：
- "AI 生成的测试用例覆盖率够吗？"
- "AI 能替代手动测试吗？"
- 期望：AI 是辅助工具，不能完全依赖

根本原因：

认知不统一：每个角色对 AI 的理解不同
缺乏培训：没有系统的 AI 使用培训
期望过高：把 AI 当成万能工具

我们的应对：

统一认知培训
- 每月一次 AI 使用分享会
- 讲清楚 AI 能做什么、不能做什么
- 设定合理的期望
角色定制化技能
- 产品用 requirements-assistant 和 prd-writer
- 开发用 frontend-dev-assistant 和 java-dev-assistant
- 测试用 test-skills 和 ui-automation-expert
- 每个角色只需要关注自己的技能
建立协作规范
- 产品：提供结构化的需求文档（不是想法）
- 开发：基于需求文档生成代码，但要审查
- 测试：基于需求文档生成测试用例，但要补充
案例库建设
- 收集成功案例和失败案例
- 让大家知道什么场景适合用 AI
- 什么场景不适合

效果：

跨角色协作效率：提升 40%
因认知差异导致的返工：从 30% 降到 5%
团队对 AI 的满意度：从 6 分提升到 8.5 分

掣肘点 5：度量体系缺失，无法证明价值

问题描述：推广 AI 最难的不是技术，而是证明价值。老板问："AI 到底给我们带来了多少收益？"我答不上来。

具体表现：

没有数据支撑，只能靠"感觉"
无法量化 AI 带来的效率提升
无法对比使用 AI 前后的差异
无法说服管理层继续投入

根本原因：

缺乏度量工具：快手有"琅琊阁"平台，我们没有
缺乏度量指标：不知道该统计什么数据
缺乏对比基准：没有使用 AI 前的数据作为对比

我们的应对：

建立简单的度量指标
- 技能使用次数（每周统计）
- 代码生成率（手动统计，不精确但够用）
- 开发时间对比（使用 AI 前后）
- 代码质量指标（bug 率、规范符合率）
使用现有工具
- Git 统计代码提交量
- Jira 统计任务完成时间
- 代码审查工具统计问题数量
建立对比案例
- 选择典型任务（如 CRUD 页面开发）
- 记录使用 AI 前的时间
- 记录使用 AI 后的时间
- 计算效率提升比例
定期汇报
- 每月向管理层汇报数据
- 展示具体案例和效果
- 收集团队反馈

我们的数据（3 个月后）：

前端 CRUD 页面开发：效率提升 12 倍
后端 API 开发：效率提升 4 倍
测试用例生成：效率提升 8 倍
代码规范符合率：从 60% 提升到 95%
团队整体交付效率：提升 35%

效果：

管理层认可度：从怀疑到支持
预算支持：获得了 AI 工具的预算
团队信心：看到数据后，更愿意使用 AI

七、5 大掣肘点的共性与应对策略

回顾这 5 个掣肘点，我发现它们有一些共性：

共性 1：人的问题 > 技术问题

所有掣肘点都不是技术问题，而是人的问题：

老员工的抵触 → 心理问题
维护成本高 → 组织问题
代码质量不稳定 → 方法问题
认知差异 → 沟通问题
度量缺失 → 管理问题

启示：推广 AI 不是技术项目，而是变革管理项目。

共性 2：期望管理很重要

很多问题源于期望不匹配：

期望 AI 是魔法棒 → 失望
期望 AI 完美无缺 → 失望
期望一次性解决所有问题 → 失望

启示：要设定合理的期望，AI 是放大器，不是魔法棒。

共性 3：小步快跑比大而全更有效

我们的成功经验：

不追求完美，先追求可用
不追求覆盖所有场景，先解决高频场景
不追求一次性成功，而是持续迭代

启示：3 个月见效，比 3 年规划更实际。

八、给读者的实践建议

如果你也想在团队推广 AI Agent Skills，这里是我的建议：

8.1 第一周：找到你的第一个技能

不要一上来就想做 20 个技能，先做 1 个：

找到最痛的点：团队最重复、最无聊的工作是什么？
写一个最小可用技能：不追求完美，能用就行
找一个种子用户：让他试用，收集反馈
快速迭代：根据反馈改进

目标：1 周内让 1 个人用起来。

8.2 第一个月：扩展到 3-5 个技能

第一个技能成功后，快速复制：

识别高频场景：哪些工作最常做？
复用技能模板：不要从零开始
让团队参与：鼓励大家贡献技能
建立使用习惯：在团队会议上展示效果

目标：1 个月内让 50% 的人用起来。

8.3 第三个月：建立完整体系

技能多了之后，要系统化：

分类管理：按场景分类（需求、开发、测试）
建立规范：技能命名、文档格式统一
度量效果：收集数据，证明价值
持续优化：根据使用情况淘汰和改进

目标：3 个月内让 80% 的人用起来，效率提升 30%+。

8.4 避免的 3 个坑

不要追求大而全
- 快手做了 3 年，我们只有 3 个月
- 聚焦高频场景，不要贪多
不要强制推广
- 效果会说话，不要强推
- 让愿意尝试的人先用起来
不要忽视度量
- 没有数据，就无法证明价值
- 简单的度量也比没有强

九、写在最后：AI 时代的团队协作

这篇文章写了 20+ 个技能的详细拆解，也坦诚分享了 5 个掣肘点。

如果让我总结最重要的经验，那就是：

AI 提效的本质，不是技术问题，而是人的问题。

技术很简单：

用 Claude Code 或 Cursor
写几个 Agent Skills
让 AI 按规范生成代码

但人很复杂：

老员工会抵触
维护成本会很高
质量会不稳定
认知会有差异
价值难以证明

所以，推广 AI 不是技术项目，而是变革管理项目。

你需要：

管理期望（AI 是放大器，不是魔法棒）
管理情绪（让抵触变成支持）
管理质量（让不稳定变成稳定）
管理认知（让差异变成共识）
管理价值（让感觉变成数据）

我们的三个心得

从小处着手，从痛点切入
- 不要想着一次性解决所有问题
- 找到最痛的点，做一个技能，立刻见效
- 效果会带来信心，信心会带来更多尝试
让团队参与，而不是单打独斗
- 一个人维护 20 个技能会累死
- 让团队成员成为技能的贡献者
- 用 AI 生成 AI 技能，降低门槛
用数据说话，而不是靠感觉
- 没有数据，就无法证明价值
- 简单的度量也比没有强
- 数据会说服管理层，也会说服团队

最后的话

感谢那位读者的提问，让我有机会系统地梳理我们的实践经验。

这篇文章分享了：

20+ 个技能的详细设计和效果
5 个真实的掣肘点和应对策略
可落地的实践建议

希望对你有帮助。

如果你也在推广 AI，欢迎留言交流。如果你遇到了其他问题，也欢迎提问。

2026 年，让我们一起用 AI 改变开发方式。

AI Agent Skills 实战：20+ 技能详解与团队协作的 5 大掣肘 ​

前言：感谢读者的提问 ​

一、我们的技能体系全景图 ​

二、需求阶段：从想法到可执行任务 ​

2.1 requirements-assistant：需求分析助手 ​

2.2 prd-writer：PRD 文档生成器 ​

三、前端开发：从手写到自动生成 ​

3.1 frontend-dev-assistant：前端开发统一入口 ​

3.2 frontend-admin-assistant：管理端开发神器 ​

3.3 frontend-mobile-assistant：移动端开发助手 ​

3.4 frontend-api-assistant：API 代码自动生成 ​

四、后端开发：Java 全栈助手 ​

4.1 java-dev-assistant：企业级 Java 开发助手 ​

五、测试与质量：自动化测试体系 ​

5.1 test-skills：测试用例生成器 ​

5.2 ui-automation-expert：UI 自动化测试专家 ​

5.3 frontend-code-review：代码审查助手 ​

六、团队协作的 5 大掣肘点 ​

掣肘点 1：老员工的抵触情绪 ​

掣肘点 2：技能维护成本高 ​

掣肘点 3：AI 生成代码的质量不稳定 ​

掣肘点 4：跨角色协作的认知差异 ​

掣肘点 5：度量体系缺失，无法证明价值 ​

七、5 大掣肘点的共性与应对策略 ​

共性 1：人的问题 > 技术问题 ​

共性 2：期望管理很重要 ​

共性 3：小步快跑比大而全更有效 ​

八、给读者的实践建议 ​

8.1 第一周：找到你的第一个技能 ​

8.2 第一个月：扩展到 3-5 个技能 ​

8.3 第三个月：建立完整体系 ​

8.4 避免的 3 个坑 ​

九、写在最后：AI 时代的团队协作 ​

我们的三个心得 ​

最后的话 ​

AI Agent Skills 实战：20+ 技能详解与团队协作的 5 大掣肘

前言：感谢读者的提问

一、我们的技能体系全景图

二、需求阶段：从想法到可执行任务

2.1 requirements-assistant：需求分析助手

2.2 prd-writer：PRD 文档生成器

三、前端开发：从手写到自动生成

3.1 frontend-dev-assistant：前端开发统一入口

3.2 frontend-admin-assistant：管理端开发神器

3.3 frontend-mobile-assistant：移动端开发助手

3.4 frontend-api-assistant：API 代码自动生成

四、后端开发：Java 全栈助手

4.1 java-dev-assistant：企业级 Java 开发助手

五、测试与质量：自动化测试体系

5.1 test-skills：测试用例生成器

5.2 ui-automation-expert：UI 自动化测试专家

5.3 frontend-code-review：代码审查助手

六、团队协作的 5 大掣肘点

掣肘点 1：老员工的抵触情绪

掣肘点 2：技能维护成本高

掣肘点 3：AI 生成代码的质量不稳定

掣肘点 4：跨角色协作的认知差异

掣肘点 5：度量体系缺失，无法证明价值

七、5 大掣肘点的共性与应对策略

共性 1：人的问题 > 技术问题

共性 2：期望管理很重要

共性 3：小步快跑比大而全更有效

八、给读者的实践建议

8.1 第一周：找到你的第一个技能

8.2 第一个月：扩展到 3-5 个技能

8.3 第三个月：建立完整体系

8.4 避免的 3 个坑

九、写在最后：AI 时代的团队协作

我们的三个心得

最后的话