从快手万人团队到小作坊：AI Agent Skills 的务实落地之路

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

前言：大厂的光鲜与小厂的现实

最近看到快手发布了一篇 1.6 万字的长文，讲他们 10000+ 研发团队如何用 3 年时间完成 AI 研发范式升级。说实话，第一反应是：卧槽，真有钱。第二反应是：这跟我有啥关系？

但仔细读完后，我发现快手踩过的坑，我们也在踩；快手的困惑，我们也有。唯一的区别是：他们有钱试错，我们只能精准打击。

所以这篇文章不是要复述快手的成功经验（那玩意儿复制不了），而是想聊聊：一个普通团队，如何用最小的成本，借鉴大厂的思路，走出自己的 AI 提效之路。

一、快手的三年之痛：用 AI 工具 ≠ 个人提效 ≠ 组织提效

快手用一年时间把 AI 代码生成率从 1% 提升到 30%+，结果发现：组织的需求交付效率基本不变。

这个结论太扎心了。就像你花了一年时间练出八块腹肌，结果发现还是找不到对象。

快手总结出一个不等式：

用 AI 开发工具 ≠ 个人提效 ≠ 组织提效

为什么会这样？因为：

个人提效没传导到组织：工程师编码快了，但需求还是那么多，交付周期没变短
工具割裂：传统 DevOps 平台和新的 AI 编程工具各玩各的，无法协同
方法论缺失：大部分人只会"AI 辅助编码"，停留在 Copilot 阶段

这个问题，我们也遇到了。

二、我们的困境：没钱、没人、没时间

我们团队规模不大，但业务线不少：管理端、移动端、大屏端、后端服务。技术栈也挺杂：Vue2、Spring Boot、MyBatis、PostgreSQL、达梦数据库...

一开始，我们也想学快手，搞个 AI 编程工具推广，结果发现：

没钱自研：快手自研了 Kwaipilot，我们只能用 Claude Code、Cursor 这些现成的
没人推广：快手有效能 BP 专家，我们只有一个兼职的"AI 布道师"（就是我）
没时间试错：快手可以花一年时间发现"个人提效 ≠ 组织提效"，我们必须三个月见效

但我们有一个优势：小团队，决策快，试错成本低。

所以我们换了个思路：不追求大而全的 AI 研发平台，而是聚焦高频场景，用 Agent Skills 快速解决具体问题。

三、我们的解法：Agent Skills 体系

3.1 什么是 Agent Skills？

简单说，就是把开发过程中的高频任务，封装成可复用的"技能包"，让 AI 助手（Claude、Cursor 等）能够按照我们的规范和最佳实践来工作。

举个例子：

传统方式：

开发：Claude，帮我写个 Vue 表格页面
Claude：好的（然后给你写了一堆不符合项目规范的代码）
开发：不对，我们用的是 Element UI，而且有统一的弹窗规范
Claude：好的（改了半天，还是不对）

用 Agent Skills：

开发：/frontend-admin-assistant 帮我写个用户管理的 CRUD 页面
Claude：好的（自动读取项目规范、组件库、路由配置，生成符合规范的代码）
开发：完美，直接用

3.2 我们的技能体系

我们参考快手的"L1 → L2 → L3"升级路线，但做了简化：

级别	快手的定义	我们的实践
L1 AI 辅助	人主导，AI 辅助编码	用 Copilot，但加上项目规范约束
L2 AI 协同	人机深度协同，AI 完成更多任务	用 Agent Skills，AI 按规范生成代码
L3 AI 自主	人做 PM，AI 自主完成需求	暂时不追求（太理想化）

我们的目标很务实：先把 L1 做扎实，再逐步推进 L2。

目前我们已经开发了 20+ 个技能，覆盖了开发全流程：

需求阶段

requirements-assistant：需求分析助手，生成用户故事、验收标准、业务流程图

前端开发

frontend-dev-assistant：前端开发统一入口
frontend-admin-assistant：管理端开发（Vue2 + Element UI）
frontend-mobile-assistant：移动端开发（Vue2 + Vant）
frontend-dashboard-assistant：大屏开发（数据可视化）
frontend-api-assistant：前端 API 代码自动生成

后端开发

java-dev-assistant：Java 开发助手（Spring Boot 3.x + MyBatis）

测试

test-skills：从需求文档生成测试用例
ui-automation-expert：UI 自动化测试（Playwright）
code-review：代码审查

辅助工具

skill-creator：技能创建生成器（用 AI 生成 AI 技能，很 meta）

3.3 一个真实案例：前端 CRUD 页面生成

以前写一个用户管理的 CRUD 页面，需要：

创建 Vue 组件（30 分钟）
写表格、表单、弹窗（1 小时）
对接 API（30 分钟）
调样式、改 bug（1 小时）

总耗时：3 小时

现在用 frontend-admin-assistant：

bash

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

AI 会自动：

读取项目的组件库规范
读取路由配置规范
读取弹窗使用规范
生成符合规范的代码

总耗时：10 分钟（包括微调）

效率提升了 18 倍。

四、我们踩过的坑

4.1 坑一：技能粒度太细

一开始，我们想学快手，搞得很细：button-generator、form-validator、table-sorter...

结果发现：技能太多，开发者记不住，也懒得用。

后来我们调整策略：按场景聚合，而不是按功能拆分。

比如把 button-generator、form-validator、table-sorter 合并成 frontend-admin-assistant，一个技能解决一类问题。

4.2 坑二：规范文档写得太抽象

一开始，我们的技能文档是这样的：

markdown

## frontend-admin-assistant

帮助开发者快速生成管理端页面

结果 AI 根本不知道该怎么做。

后来我们学乖了，把规范写得超级具体：

markdown

## frontend-admin-assistant

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

核心能力：

1. CRUD 表格页面生成

   - 使用 el-table 组件
   - 分页使用 el-pagination
   - 操作列固定在右侧

2. 弹窗规范

   - 必须使用 $modalDialog 方法
   - 不允许使用 el-dialog 组件
   - 示例代码：[链接]

3. 路由配置
   - 路由文件位置：src/router/modules/
   - 必须配置 meta.title 和 meta.icon

教训：AI 不会读心术，你得把规范写得像给实习生看的一样详细。

4.3 坑三：没有度量，不知道效果

快手有"琅琊阁"效能度量平台，我们没有。

但我们也不能瞎搞，所以用了最简单的度量方式：

技能使用次数：每周统计各技能的调用次数
代码生成率：AI 生成的代码占比（手动统计，不精确但够用）
开发者反馈：每月收集一次使用体验

数据不精确，但至少知道哪些技能有用，哪些是摆设。

五、我们的收获：小步快跑，持续迭代

5.1 量化收获

经过 3 个月的实践，我们的数据：

前端 CRUD 页面开发时间：从 3 小时降到 15 分钟（效率提升 12 倍）
后端 API 开发时间：从 2 小时降到 30 分钟（效率提升 4 倍）
测试用例生成时间：从 1 天降到 1 小时（效率提升 8 倍）
代码规范符合率：从 60% 提升到 95%

这些数字比不上快手的 30% AI 代码生成率，但对我们来说已经很满意了。

5.2 质变收获

更重要的是，我们发现了一些"质变"：

新人上手更快：以前新人要 2 周才能写出符合规范的代码，现在 3 天就行
代码质量更稳定：AI 生成的代码虽然不完美，但至少不会犯低级错误
团队协作更顺畅：大家都用同一套规范，代码风格统一了

最让我惊喜的是：开发者开始主动贡献技能了。

以前我一个人维护技能库，累得要死。现在大家发现"写技能比写代码爽"，纷纷贡献自己的最佳实践。

5.3 意外收获：技能即文档

我们发现，Agent Skills 其实是一种"活文档"。

传统的开发文档有两个问题：

写的时候很认真，但没人看
过时了也没人更新

但 Agent Skills 不一样：

开发者必须用：因为用技能比手写代码快
过时了会立刻发现：因为 AI 生成的代码跑不通

所以我们的技能库，反而成了最准确、最及时的开发文档。

六、快手的经验 vs 我们的实践：对比与反思

维度	快手（万人团队）	我们（小团队）
投入	自研 AI 编程工具（Kwaipilot）	使用现成工具（Claude Code、Cursor）
推广	效能 BP 专家 + 全员培训	一个兼职"布道师" + 自发传播
度量	琅琊阁效能平台 + 精细化指标	手动统计 + 简单指标
目标	组织级提效（L1 → L2 → L3）	场景级提效（聚焦高频场景）
周期	3 年（试错成本高）	3 个月（快速迭代）
结果	AI 代码生成率 30%+	特定场景效率提升 10+ 倍

我们的启示：

不要盲目追求大而全：快手的 L3（AI 自主）很美好，但我们连 L1 都没做好，先把基础打牢
聚焦高频场景：不要试图覆盖所有场景，先解决 80% 的问题
用现成工具：自研成本太高，Claude Code、Cursor 已经够用
小步快跑：3 个月见效，比 3 年规划更实际

七、给小团队的建议：如何开始你的 AI 提效之路

7.1 第一步：找到你的"痛点场景"

不要一上来就想"全面 AI 化"，先问自己：

哪些工作最重复、最无聊？（比如 CRUD 页面）
哪些规范最容易被违反？（比如代码风格）
哪些文档最容易过时？（比如 API 文档）

从这些场景入手，做一个技能，立刻见效。

7.2 第二步：写一个"最小可用技能"

不要追求完美，先写一个能用的：

markdown

---
name: my-first-skill
description: 帮我生成一个标准的 Vue 组件
---

# 我的第一个技能

## 技术栈

Vue 2 + Element UI

## 核心能力

生成一个包含 template、script、style 的标准组件

## 示例代码

[粘贴一个你们项目的标准组件]

## 注意事项

- 必须使用 TypeScript
- 样式必须使用 scoped

就这么简单，先跑起来再说。

7.3 第三步：让团队用起来

技能写好了，怎么推广？

找一个"种子用户"：通常是团队里最愿意尝试新东西的人
解决一个真实问题：让他用技能完成一个实际任务
展示效果：在团队会议上演示"10 分钟完成 3 小时的工作"
自然传播：其他人看到效果，自然会来问

不要强推，效果会说话。

7.4 第四步：持续迭代

技能不是一次性的，要根据反馈持续优化：

每周收集反馈：哪里不好用？哪里可以改进？
每月更新一次：修复 bug，增加新功能
每季度复盘一次：哪些技能有用？哪些该淘汰？

我们的 frontend-admin-assistant 已经迭代了 8 个版本，越来越好用。

八、未来展望：从 L1 到 L2 的进化

快手提出的"L1 → L2 → L3"升级路线，我们目前在 L1.5 的位置：

L1 AI 辅助：✅ 已完成，AI 按规范生成代码
L2 AI 协同：🚧 正在探索，让 AI 理解业务逻辑
L3 AI 自主：❌ 暂不考虑，太理想化

我们正在尝试的 L2 场景：

8.1 场景一：需求到代码的自动化

现状（L1）：

产品给需求文档
开发手动拆解任务
用技能生成代码

目标（L2）：

产品给需求文档
AI 自动拆解任务 + 生成代码
开发只需审核

我们已经有了 requirements-assistant（需求分析）和各种开发技能，现在要做的是把它们串起来。

8.2 场景二：代码审查的智能化

现状（L1）：

AI 检查代码规范
人工审查业务逻辑

目标（L2）：

AI 理解业务逻辑
AI 发现潜在 bug
AI 提出优化建议

这需要 AI 能读懂项目的业务代码，我们正在尝试用 RAG（检索增强生成）技术来实现。

九、写在最后：AI 是放大器，不是魔法棒

快手在文章最后说：AI 是"透视镜"与"放大器"。

这句话太对了。

AI 不会自动解决你的组织问题，它只会把你的问题放大：

如果你的规范混乱，AI 会生成更混乱的代码
如果你的流程低效，AI 只会让低效流程跑得更快
如果你的团队不协作，AI 也帮不了你

所以，AI 提效的前提是：你得先把基础打好。

快手花了 2 年时间做"平台化、数字化、精益化"，才开始做"智能化"。我们虽然没有快手的资源，但也要先把规范、流程、协作做好，再谈 AI。

我们的三个心得

不要追求完美，先追求可用
- 快手的 AI 代码生成率 30%+ 很牛，但我们 10% 也够用
- 重要的是解决实际问题，而不是追求数字
不要盲目模仿大厂，要找到自己的路
- 快手有钱自研，我们用现成工具
- 快手追求组织提效，我们先做场景提效
- 条条大路通罗马，适合自己的才是最好的
不要等待完美时机，现在就开始
- 不需要等规范完善
- 不需要等工具成熟
- 不需要等团队准备好
- 写一个技能，解决一个问题，就是开始

十、结语：2026，AI 时代的分水岭

快手的文章最后说：2026 年将成为一批先行者集中展示阶段性成果的窗口期。

我深以为然。

但我想补充一句：2026 年也将是小团队弯道超车的机会。

为什么？因为：

AI 工具已经成熟：Claude、Cursor、GitHub Copilot 都很好用，不需要自研
方法论已经清晰：快手、Google、微软都在分享经验，不需要从零摸索
成本已经降低：以前要百万级投入，现在几千块就能开始

大厂有资源优势，但小团队有灵活优势。我们可以：

更快决策：不需要层层审批
更快试错：失败了也不会影响 KPI
更快迭代：3 个月一个版本，而不是 3 年一个规划

所以，不要羡慕快手的万人团队，也不要妄自菲薄。

AI 时代，拼的不是资源，而是认知和行动力。

作者：老马

一个在编程和 AI 领域摸爬滚打的程序员
一个相信"小团队也能做大事"的理想主义者
一个愿意分享经验、不藏私的博主

如果这篇文章对你有帮助，欢迎点赞、转发、收藏。

如果你有更好的想法，欢迎留言交流。

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

参考资料

快手技术团队：《快手万人组织 AI 研发范式跃迁之路：从平台化、数字化、精益化到智能化》
DORA：《2025 年人工智能辅助软件开发现状调查报告》
icinfo-agent-skills 项目文档

从快手万人团队到小作坊：AI Agent Skills 的务实落地之路 ​

前言：大厂的光鲜与小厂的现实 ​

一、快手的三年之痛：用 AI 工具 ≠ 个人提效 ≠ 组织提效 ​

二、我们的困境：没钱、没人、没时间 ​

三、我们的解法：Agent Skills 体系 ​

3.1 什么是 Agent Skills？ ​

3.2 我们的技能体系 ​

需求阶段 ​

前端开发 ​

后端开发 ​

测试 ​

辅助工具 ​

3.3 一个真实案例：前端 CRUD 页面生成 ​

四、我们踩过的坑 ​

4.1 坑一：技能粒度太细 ​

4.2 坑二：规范文档写得太抽象 ​

4.3 坑三：没有度量，不知道效果 ​

五、我们的收获：小步快跑，持续迭代 ​

5.1 量化收获 ​

5.2 质变收获 ​

5.3 意外收获：技能即文档 ​

六、快手的经验 vs 我们的实践：对比与反思 ​

七、给小团队的建议：如何开始你的 AI 提效之路 ​

7.1 第一步：找到你的"痛点场景" ​

7.2 第二步：写一个"最小可用技能" ​

7.3 第三步：让团队用起来 ​

7.4 第四步：持续迭代 ​

八、未来展望：从 L1 到 L2 的进化 ​

8.1 场景一：需求到代码的自动化 ​

8.2 场景二：代码审查的智能化 ​

九、写在最后：AI 是放大器，不是魔法棒 ​

我们的三个心得 ​

十、结语：2026，AI 时代的分水岭 ​

参考资料 ​

从快手万人团队到小作坊：AI Agent Skills 的务实落地之路

前言：大厂的光鲜与小厂的现实

一、快手的三年之痛：用 AI 工具 ≠ 个人提效 ≠ 组织提效

二、我们的困境：没钱、没人、没时间

三、我们的解法：Agent Skills 体系

3.1 什么是 Agent Skills？

3.2 我们的技能体系

需求阶段

前端开发

后端开发

测试

辅助工具

3.3 一个真实案例：前端 CRUD 页面生成

四、我们踩过的坑

4.1 坑一：技能粒度太细

4.2 坑二：规范文档写得太抽象

4.3 坑三：没有度量，不知道效果

五、我们的收获：小步快跑，持续迭代

5.1 量化收获

5.2 质变收获

5.3 意外收获：技能即文档

六、快手的经验 vs 我们的实践：对比与反思

七、给小团队的建议：如何开始你的 AI 提效之路

7.1 第一步：找到你的"痛点场景"

7.2 第二步：写一个"最小可用技能"

7.3 第三步：让团队用起来

7.4 第四步：持续迭代

八、未来展望：从 L1 到 L2 的进化

8.1 场景一：需求到代码的自动化

8.2 场景二：代码审查的智能化

九、写在最后：AI 是放大器，不是魔法棒

我们的三个心得

十、结语：2026，AI 时代的分水岭

参考资料