拒绝 Vibe Coding：Matt Pocock Skills 深度拆解——当 8 万 Star 的开源项目重新定义 AI 编程的工程底线

一、问题的本质：AI 编程的"快速腐烂"困境

2025 年底到 2026 年初，AI 编程工具经历了一场爆发式增长。Claude Code、Cursor、Windsurf、Trae SOLO……各种 AI Coding Agent 如雨后春笋般涌现。开发者们欣喜若狂——原本需要一周的任务，AI 几个小时就能搞定。

但很快，一个令人不安的现象浮出水面：AI 写代码的速度越快，代码库腐烂的速度也越快。

这不是比喻。在一次次的 AI 编程实践中，开发者们发现：

• AI 能写出看起来正确的函数，但不理解整体架构
• AI 能快速实现功能，但不遵循项目既有的设计约定
• AI 能一次生成几百行代码，但这些代码往往缺乏测试、缺乏文档、缺乏一致性
• 最致命的是——AI 会在你不注意的时候修改无关代码，引入隐式依赖

这种"感觉对了就写"的开发模式，被 Matt Pocock 严肃地命名为 Vibe Coding——一种完全依赖 AI 直觉、缺乏工程约束的编码方式。

1.1 Vibe Coding 的三大毒害

毒害一：需求错位加速器

传统开发中，需求理解的偏差会通过沟通逐步修正。但 AI 编程把这个问题放大了十倍——你告诉 AI "做一个用户登录功能"，AI 可能会做一个和你的认证体系完全不兼容的实现。因为你没有告诉它：我们用的是 JWT + Refresh Token 双令牌方案，token 存在 httpOnly cookie 里，还要支持 SSO 单点登录。

传统开发中，程序员会主动追问这些细节。但 AI 不会——它只会按照字面意思执行，然后产出一个"看起来能工作"但完全不符合预期的结果。

毒害二：架构熵增

Kent Beck 说过："每天都投资于系统设计。"但在 AI 编程时代，这个忠告被彻底遗忘了。因为 AI 生成代码太快了，开发者来不及思考架构影响就已经提交了代码。每个 AI 生成的函数都是正确的，但它们组合在一起就变成了一团意大利面。

毒害三：反馈真空

最危险的一点——AI 编程切断了开发者与代码之间的反馈循环。当你自己写代码时，编译器报错、测试失败、运行时异常，这些都是即时的反馈。但当 AI 一次性生成 500 行代码，你根本无法建立有效的反馈循环。你只能看到"功能能用"或"功能不能用"，而不是"这一行有问题"。

1.2 为什么现有方案都不够？

看到这些问题后，社区尝试了多种解决方案：

• GSD（Get Shit Done）：一套完整的项目管理方法论，但太重了，掌控了整个流程反而让开发者失去灵活性
• BMAD：试图用 AI 驱动整个产品开发周期，但同样面临"过程太重"的问题
• Spec-Kit：规格驱动开发，方向正确但粒度不够

Matt Pocock 的洞察是：问题不在于缺少一套完整的方法论，而在于缺少一组小而美的、可组合的工程技能约束。 这些技能不需要接管你的整个开发流程，而是在你需要的具体环节介入，像一位资深工程师在你耳边低语："嘿，这样做更好。"

这就是 Matt Pocock Skills 诞生的背景。

二、Matt Pocock Skills 架构全解析

2.1 设计哲学：小、灵、组合

Matt Pocock 是 TypeScript 社区的顶级教育者，拥有数十年的工程经验。他在 README 中明确阐述了自己的设计哲学：

"These skills are designed to be small, easy to adapt, and composable. They work with any model. They're based on decades of engineering experience."

翻译过来就是四个关键词：

这种哲学源自 Unix 哲学——每个工具做好一件事，通过组合实现复杂功能。

2.2 三层架构

整个 Skills 项目分为三个层次：

┌─────────────────────────────────────────┐
│         Productivity Layer             │
│   (caveman, grill-me, handoff, teach)  │
├─────────────────────────────────────────┤
│          Engineering Layer              │
│  (tdd, diagnose, triage, to-prd, ...)  │
├─────────────────────────────────────────┤
│            Misc Layer                   │
│  (git-guardrails, pre-commit, ...)      │
└─────────────────────────────────────────┘

Productivity Layer（生产力层）：通用的效率工具，不限于编程场景。比如 caveman 模式可以把 AI 的 Token 消耗降低 75%——通过去掉所有填充词，只保留核心技术内容。

Engineering Layer（工程层）：核心所在。这是 Matt Pocock 数十年工程经验的精华凝结。

Misc Layer（辅助层）：不常用但关键时刻能救命的工具，比如 git-guardrails 在 Shell 层面拦截危险的 Git 操作。

2.3 完整技能清单

工程技能（Engineering Skills）

生产力技能（Productivity Skills）

三、核心技能深度拆解

3.1 /grill-with-docs：可能是整个项目最强大的技能

Matt Pocock 自己说："It might be the single coolest technique in this repo."

为什么这么牛？因为它同时解决了三个问题：

问题一：需求对齐

传统的 AI 编程交互模式是这样的：

用户：帮我做一个用户注册功能
AI：好的，我来实现 [开始写代码]

结果呢？AI 写了一堆代码，但根本不是你想要的。

/grill-with-docs 改变了这个模式：

用户：帮我做一个用户注册功能
AI：好的，在开始之前，让我先确认几个关键细节：
    1. 注册方式是什么？邮箱？手机号？第三方 OAuth？
    2. 密码策略？需要多强？是否支持无密码登录？
    3. 注册后是否需要邮箱验证？验证码有效期多久？
    4. 是否需要 CAPTCHA？什么类型的？
    5. 用户名规则？是否允许中文？
    6. 是否有邀请码机制？
    ...

AI 主动追问，直到所有决策分支都被覆盖。

问题二：领域语言建立

这个才是 /grill-with-docs 的杀手锏。它不只是问问题，还在过程中帮你建立一个 共享语言。

举个例子——来自 Matt Pocock 自己的项目：

没有共享语言时，描述一个功能需要很长一段话：

"There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)"

有了共享语言后：

"There's a problem with the materialization cascade"

两个字（materialization cascade）替代了整整一段话。而且这个词是领域内所有人都理解的、有精确含义的术语。

这个能力对 AI 编程的价值巨大：

1. 代码一致性：变量、函数、文件命名都使用统一语言
2. Token 节省：AI 思考时需要更少的 Token 来表达同样的概念
3. 可导航性：代码库对 AI 更加友好，因为术语统一

/grill-with-docs 的具体流程：

1. 用户提出需求/想法
2. AI 针对需求进行深度追问（grilling session）
3. 在追问过程中识别关键领域概念
4. 将这些概念写入 CONTEXT.md（领域语言文档）
5. 将重要设计决策写入 ADR（Architecture Decision Record）
6. 后续所有开发都基于这些文档进行

问题三：知识沉淀

每次使用 /grill-with-docs，你的项目就会多一份 CONTEXT.md 和几份 ADR。这些文档不只是给 AI 看的——它们也是团队的最佳实践文档。时间一长，你的项目就有了完整的领域语言字典和架构决策历史。

3.2 /tdd：让 AI 学会"先测试后编码"

这个技能是整个项目流传最广的，也是对 Vibe Coding 最直接的对抗。

为什么 AI 需要 TDD 约束？

AI 编程有一个天然倾向：先写实现，再写测试（如果记得的话）。这和人类初学者的问题一样——迫不及待地看到代码跑起来，把测试当作"额外负担"。

但 TDD 的价值恰恰在于反转这个顺序：

红阶段（Red）：先写一个失败的测试。这迫使你思考"我到底要什么"。

绿阶段（Green）：写最少的代码让测试通过。这防止了过度工程。

重构阶段（Refactor）：在测试保护下优化代码。这让重构变得安全。

当 AI 遵循这个循环时，效果是惊人的：

# 红 - 先写测试
def test_user_registration_with_email():
    """用户应该能通过邮箱注册"""
    response = register_user(
        email="test@example.com",
        password="SecurePass123!",
        username="testuser"
    )
    assert response.status_code == 201
    assert response.data["email"] == "test@example.com"
    assert "password" not in response.data  # 密码不应返回
    assert response.data["email_verified"] is False  # 需要验证

# 运行测试 → 失败（还没有实现）❌

# 绿 - 写最少代码通过测试
def register_user(email: str, password: str, username: str) -> Response:
    user = User.create(
        email=email,
        username=username,
        password_hash=hash_password(password),
        email_verified=False
    )
    return Response(
        status_code=201,
        data={"email": user.email, "email_verified": user.email_verified}
    )

# 运行测试 → 通过 ✅

# 重构 - 在测试保护下优化
def register_user(email: str, password: str, username: str) -> Response:
    validate_email(email)
    validate_password_strength(password)
    validate_username(username)
    
    if User.exists(email=email):
        raise DuplicateEmailError()
    if User.exists(username=username):
        raise DuplicateUsernameError()
    
    user = User.create(
        email=email,
        username=username,
        password_hash=hash_password(password),
        email_verified=False
    )
    send_verification_email(user.email)
    
    return Response(
        status_code=201,
        data={"email": user.email, "email_verified": user.email_verified}
    )

/tdd 的垂直切片策略

传统的 AI 编程往往会"先写完所有后端 API，再写所有前端页面"——这是水平切片。问题在于，直到最后一步，你都无法看到完整的功能。

/tdd 强制使用垂直切片：一个功能从 UI 到 API 到数据库，一次打通一个完整的用户场景。每个切片都是一个小而完整的"追踪弹"（tracer bullet），让你能立即看到功能是否端到端可用。

传统水平切片：
├── 后端 API 全部
├── 前端页面全部
├── 数据库设计全部
└── 最后才能看到完整功能

垂直切片（/tdd 方式）：
├── 切片1：用户注册（API + UI + DB）✅ 可用
├── 切片2：邮箱验证（API + UI + DB）✅ 可用
├── 切片3：密码重置（API + UI + DB）✅ 可用
└── 每个切片完成后都能独立验证

3.3 /diagnose：系统化调试的艺术

调试是编程中最消耗心智的活动之一。面对一个神秘的 Bug，人类的本能是"试试改这个，试试改那个"——这叫猎枪调试（Shotgun Debugging），效率极低且容易引入新 Bug。

/diagnose 强制执行一个六步调试循环：

┌─────────┐
│ Reproduce │ ← 首先稳定复现 Bug
└────┬────┘
     ↓
┌─────────┐
│ Minimise │ ← 精简到最小复现用例
└────┬────┘
     ↓
┌───────────┐
│ Hypothesise│ ← 提出假设，不要急于动手
└────┬──────┘
     ↓
┌───────────┐
│ Instrument │ ← 添加日志/断点验证假设
└────┬──────┘
     ↓
┌──────┐
│ Fix  │ ← 确认原因后再修复
└────┬──┘
     ↓
┌───────────────┐
│ Regression Test│ ← 写回归测试防止复发
└───────────────┘

这六步每一步都有明确的产出和准入条件。AI 不能跳步——比如在没稳定复现之前就动手修复，这是调试中最常见的错误。

# /diagnose 实战示例

# Step 1: Reproduce - 写一个能稳定触发 Bug 的测试
def test_concurrent_order_creation_race_condition():
    """并发创建订单时偶尔出现库存超卖"""
    # 模拟 100 个并发请求
    results = asyncio.gather(*[
        create_order(item_id=1, quantity=1) 
        for _ in range(100)
    ])
    
    total_sold = sum(r.quantity for r in results)
    
    # 商品库存只有 50，不应该卖出超过 50
    assert total_sold <= 50  # ❌ 这个测试会失败！


# Step 2: Minimise - 精简到最小复现
def test_minimal_concurrent_order():
    """最小复现：只需要 3 个并发请求"""
    stock = update_stock(item_id=1, quantity=2)  # 库存设为 2
    results = asyncio.gather(
        create_order(item_id=1, quantity=1),
        create_order(item_id=1, quantity=1),
        create_order(item_id=1, quantity=1),
    )
    assert len(results) == 2  # 只应该成功 2 个


# Step 3: Hypothesise - 假设原因
# 假设：update_stock 和 create_order 之间存在竞态条件，
# 两个请求同时读到库存为 2，各自减 1，都成功


# Step 4: Instrument - 添加日志验证假设
# 在 create_order 中添加日志：
# logger.info(f"Stock before deduct: {current_stock}")


# Step 5: Fix - 确认假设后修复
# 使用 SELECT ... FOR UPDATE 行级锁
async def create_order(item_id: int, quantity: int):
    async with db.transaction():
        row = await db.fetchrow(
            "SELECT stock FROM items WHERE id = $1 FOR UPDATE", 
            item_id
        )
        if row["stock"] < quantity:
            raise InsufficientStockError()
        await db.execute(
            "UPDATE items SET stock = stock - $1 WHERE id = $2",
            quantity, item_id
        )


# Step 6: Regression Test - 回归测试
# 把最小复现测试加入测试套件

3.4 /improve-codebase-architecture：AI 时代的代码库急救

这是整个项目中最具"急救"属性的技能。当你的代码库已经被 AI 搞得面目全非时，这个技能可以帮你"救回来"。

它的工作方式非常聪明：

1. 读取 CONTEXT.md：了解项目领域语言
2. 读取 docs/adr/：了解架构决策历史
3. 扫描代码库：发现"深化"机会

什么是"深化机会"？这个概念来自 John Ousterhout 的《A Philosophy of Software Design》：

"The best modules are deep. They allow a lot of functionality to be accessed through a simple interface."

简单说，如果一个模块的接口很复杂但功能很少，那就是"浅模块"——需要深化。/improve-codebase-architecture 会自动识别这类问题，并建议重构方向。

3.5 /to-issues：需求到任务的精确转化

当 PRD 已经就绪，下一步就是把需求拆成可执行的任务。传统方式是按"水平层"拆分：

❌ 水平拆分
Issue 1: 设计数据库表结构
Issue 2: 实现 API 端点
Issue 3: 实现前端页面
Issue 4: 联调测试

问题：前三个 Issue 都不能独立运行，直到 Issue 4 才能看到功能

/to-issues 使用垂直切片：

✅ 垂直切片（Tracer Bullet）
Issue 1: 用户可以通过邮箱注册（包含 DB schema + API + UI + 测试）
Issue 2: 注册后发送验证邮件（包含邮件服务 + API + UI 状态 + 测试）
Issue 3: 验证邮箱后激活账号（包含验证逻辑 + API + UI + 测试）

优势：每个 Issue 完成后都能独立验证，交付频率大幅提升

每个垂直切片 Issue 都像一颗"追踪弹"——你射出一发，就能看到完整的弹道。这比"盲射一堆弹药然后祈祷"要靠谱得多。

四、安装与实战指南

4.1 快速安装

# 一键安装
npx skills@latest add mattpocock/skills

# 选择你需要的技能
# 选择要安装到的 Coding Agent（Claude Code / Cursor / 其他）
# 务必选择 /setup-matt-pocock-skills

4.2 项目初始化

安装完成后，在你的项目中运行初始化：

/setup-matt-pocock-skills

这个命令会问你三个问题：

1. Issue Tracker 选什么？ GitHub / Linear / 本地文件
2. Triage 时用什么标签？ 你常用的 Issue 标签体系
3. 文档保存在哪里？ CONTEXT.md、ADR 等文档的存放路径

这些配置会被写入项目的配置文件，后续所有技能都会基于这些配置工作。

4.3 日常开发工作流

以下是一个典型的 AI 编程工作流，结合了多个 Skills：

Step 1: 需求探索
  → /grill-with-docs
  → AI 追问需求细节
  → 生成 CONTEXT.md（领域语言）
  → 生成 ADR（架构决策）

Step 2: 需求文档化
  → /to-prd
  → 将对话内容提炼为标准 PRD

Step 3: 任务拆分
  → /to-issues
  → 将 PRD 拆为垂直切片 Issue

Step 4: 逐个实现
  → 对每个 Issue 使用 /tdd
  → 红-绿-重构循环
  → 每个切片完成后验证

Step 5: 架构维护
  → /improve-codebase-architecture
  → 定期检查代码库健康度
  → 修复发现的架构问题

Step 6: 问题排查
  → 遇到 Bug 时使用 /diagnose
  → 六步调试循环
  → 写回归测试

4.4 团队协作场景

当需要把工作交接给另一个 Agent 或人类同事时：

/handoff

这个技能会将当前会话压缩为一份结构化的交接文档，包含：

• 当前工作状态
• 已完成的任务
• 待完成的任务
• 关键决策和原因
• 已知问题

五、与同类方案的深度对比

5.1 vs GSD（Get Shit Done）

5.2 vs Spec-Kit

5.3 vs Claude Code 内置能力

Claude Code 本身就具备一定的编程能力，但 Skills 的价值在于"工程约束"。就像一个聪明的实习生——能力很强但需要有人告诉他正确的做事方式。

六、关于"Skill 会不会成为 Agent 时代的 npm"的思考

这个讨论在社区中非常热烈。核心问题是：如果工程经验可以被封装成可安装的 Skill，那 Skill 是否会成为 AI Agent 时代的标准分发单元？

6.1 类比分析

npm 之所以成为 JavaScript 生态的基础设施，是因为它解决了一个核心问题：代码复用。在 npm 出现之前，每个项目都要重新实现常见功能。

Skill 解决的是类似的问题：经验复用。在 Skill 出现之前，每个使用 AI 编程的团队都要自己摸索如何约束 AI 的行为。

6.2 但也有不同

npm 分发的是"确定性代码"——安装后行为完全可预测。Skill 分发的是"指导性指令"——AI 的执行可能因模型不同而产生差异。

这意味着 Skill 的标准化比 npm 更难。但目前趋势来看，skills.sh 平台正在试图建立这个标准。

七、实战代码示例：用 Skills 重构一个真实项目

让我们通过一个真实场景来展示 Skills 的价值。

场景：一个正在腐烂的电商订单系统

# 腐烂前的代码——典型的 Vibe Coding 产物
class OrderService:
    async def create_order(self, user_id, items, address, payment_method, coupon=None):
        # 800 行代码混在一起
        # 没有测试
        # 没有错误处理
        # 直接操作数据库
        # 业务逻辑到处散落
        pass

Step 1：使用 /grill-with-docs 理清领域语言

通过访谈，我们确立核心领域概念：

CONTEXT.md:
  - Order: 用户购买意向的确认凭证
  - OrderLine: 订单中的单品条目
  - Fulfillment: 订单履约流程
  - Settlement: 订单结算（资金流）
  - Inventory Reservation: 库存预占（防止超卖）

Step 2：使用 /to-issues 拆分任务

Issue 1: 实现库存预占机制（DB + API + 测试）
Issue 2: 实现订单创建基本流程（DB + API + 测试）
Issue 3: 实现优惠券验证逻辑（单独模块 + 测试）
Issue 4: 实现支付流程（网关对接 + 回调 + 测试）
Issue 5: 实现订单状态机（created → paid → shipped → completed）

Step 3：使用 /tdd 逐个实现

# Issue 1: 库存预占 - TDD 方式

# 红：先写测试
import pytest

async def test_reserve_inventory_success():
    """预占库存应该成功并返回预留 ID"""
    reserve_id = await inventory.reserve(
        item_id=1, quantity=2, order_id="ORD-001"
    )
    assert reserve_id is not None
    
    available = await inventory.get_available(item_id=1)
    assert available == 48  # 原始 50 - 预占 2


async def test_reserve_inventory_insufficient():
    """库存不足时应该抛出异常"""
    with pytest.raises(InsufficientStockError):
        await inventory.reserve(
            item_id=1, quantity=999, order_id="ORD-002"
        )


async def test_reserve_inventory_concurrent():
    """并发预占不应超卖"""
    import asyncio
    
    # 库存设为 5
    await inventory.set_stock(item_id=1, quantity=5)
    
    # 10 个并发预占，每个要 1 个
    results = await asyncio.gather(*[
        inventory.reserve(item_id=1, quantity=1, order_id=f"ORD-{i}")
        for i in range(10)
    ], return_exceptions=True)
    
    successes = [r for r in results if not isinstance(r, Exception)]
    assert len(successes) <= 5  # 最多成功 5 个


# 绿：实现最少的代码
class InventoryService:
    def __init__(self, db):
        self.db = db
    
    async def reserve(self, item_id: int, quantity: int, order_id: str):
        async with self.db.transaction():
            row = await self.db.fetchrow(
                "SELECT stock FROM items WHERE id = $1 FOR UPDATE",
                item_id
            )
            if row["stock"] < quantity:
                raise InsufficientStockError(
                    f"需要 {quantity}，可用 {row['stock']}"
                )
            reserve_id = await self.db.fetchval(
                "INSERT INTO inventory_reserves "
                "(item_id, quantity, order_id) "
                "VALUES ($1, $2, $3) RETURNING id",
                item_id, quantity, order_id
            )
            await self.db.execute(
                "UPDATE items SET stock = stock - $1 WHERE id = $2",
                quantity, item_id
            )
            return reserve_id


# 重构：在测试保护下优化
class InventoryService:
    def __init__(self, db: Database, logger: Logger):
        self.db = db
        self.logger = logger
    
    async def reserve(
        self, 
        item_id: int, 
        quantity: int, 
        order_id: str,
        ttl_seconds: int = 1800  # 预占 30 分钟后自动释放
    ) -> str:
        """预占库存，返回预留 ID"""
        async with self.db.transaction():
            stock = await self._lock_item(item_id)
            
            if stock < quantity:
                self.logger.warning(
                    f"库存不足: item_id={item_id} "
                    f"需要={quantity} 可用={stock}"
                )
                raise InsufficientStockError(
                    needed=quantity, available=stock, item_id=item_id
                )
            
            reserve_id = await self._create_reserve(
                item_id, quantity, order_id, ttl_seconds
            )
            
            await self._deduct_stock(item_id, quantity)
            
            self.logger.info(
                f"库存预占成功: reserve_id={reserve_id} "
                f"item_id={item_id} qty={quantity}"
            )
            
            return reserve_id
    
    async def _lock_item(self, item_id: int) -> int:
        row = await self.db.fetchrow(
            "SELECT stock FROM items WHERE id = $1 FOR UPDATE",
            item_id
        )
        return row["stock"]
    
    async def _create_reserve(
        self, item_id: int, quantity: int, 
        order_id: str, ttl_seconds: int
    ) -> str:
        return await self.db.fetchval(
            """INSERT INTO inventory_reserves 
               (item_id, quantity, order_id, expires_at)
               VALUES ($1, $2, $3, NOW() + INTERVAL '1 second' * $4)
               RETURNING id""",
            item_id, quantity, order_id, ttl_seconds
        )
    
    async def _deduct_stock(self, item_id: int, quantity: int):
        await self.db.execute(
            "UPDATE items SET stock = stock - $1 WHERE id = $2",
            quantity, item_id
        )

Step 4：使用 /improve-codebase-architecture 定期检查

每隔几天运行一次，发现模块边界模糊的地方，及时重构。

7.1 重构前 vs 重构后对比

重构前（Vibe Coding）：
  order_service.py          - 800 行，混合所有逻辑
  payment.py                - 300 行，与订单紧耦合
  inventory.py             - 150 行，缺少并发控制
  tests/                    - 几乎没有测试
  总代码量：1250 行
  可测试性：极差
  可维护性：极差

重构后（Skills 驱动）：
  domain/
    context.md              - 领域语言定义
    adr/
      001-inventory-reservation.md
      002-order-state-machine.md
      003-payment-separation.md
  services/
    inventory_service.py    - 120 行，专注库存
    order_service.py        - 200 行，专注订单
    payment_service.py      - 180 行，专注支付
    fulfillment_service.py  - 150 行，专注履约
  tests/
    test_inventory.py       - 250 行，充分覆盖
    test_orders.py          - 200 行，充分覆盖
    test_payment.py         - 150 行，充分覆盖
  总代码量：1250 行 + 700 行测试
  可测试性：优秀
  可维护性：优秀

代码量几乎没变，但质量和可维护性有了质的飞跃。

八、性能与效率分析

8.1 Token 效率

/caveman 技能可以将 AI 的 Token 消耗降低约 75%。原理很简单——去掉所有填充词：

# 普通模式（~200 tokens）
"好的，我理解你想要实现一个用户注册功能。让我来分析一下
这个需求，我们需要考虑以下几个方面：首先，我们需要一个
用户模型来存储用户信息，然后我们需要一个注册端点来处理
注册请求..."

# caveman 模式（~50 tokens）
"用户注册：POST /api/register 
  body: {email, password, username}
  返回: 201 + JWT token
  需验证邮箱格式、密码强度、用户名唯一"

8.2 开发效率

根据社区反馈，使用 Skills 后的典型效率变化：

九、局限性与注意事项

9.1 不是银弹

Matt Pocock 自己也说了，这些 Skills 不能替代工程思维。它们是工具，不是魔法。你仍然需要：

• 理解你的业务领域
• 做出正确的技术决策
• 审查 AI 生成的代码
• 持续关注架构健康

9.2 学习曲线

虽然每个 Skill 本身很简单，但 组合使用 需要一定的工程经验。一个新手可能不知道什么时候该用 /diagnose，什么时候该用 /zoom-out。

9.3 模型依赖

虽然设计为模型无关，但不同模型对指令的遵循程度不同。在能力较弱的模型上，某些 Skills 的效果可能会打折扣。

十、总结：从"魔法"到"工艺"

Matt Pocock Skills 的火爆（8 万 Star，且仍在快速增长）传递了一个清晰的信号：AI 编程正在从"魔法时代"过渡到"工艺时代"。

在魔法时代，开发者对 AI 满怀期待——只要提示词够好，AI 就能搞定一切。结果发现，没有工程约束的 AI 编程，速度越快，积累的技术债越多。

在工艺时代，开发者重新重视工程基本盘——测试驱动、领域语言、架构设计、系统化调试。Skills 的价值不在于提供了什么新方法，而在于 把这些已经被验证了数十年的工程实践，用 AI 能理解的方式重新封装，并注入到 AI 编程的工作流中。

Matt Pocock 在 README 的结尾写道：

"Software engineering fundamentals matter more than ever. These skills are my best effort at condensing these fundamentals into repeatable practices, to help you ship the best apps of your career."

这不是一个技术项目，这是一份工程宣言——在 AI 可以写代码的时代，工程思维不是过时了，而是比任何时候都重要。

如果你正在使用 AI 编程工具，并且感受到了 Vibe Coding 的痛苦，那么 Matt Pocock Skills 值得你花 30 分钟安装和体验。它可能不会让你的代码自动变好，但它会帮你建立正确的编码习惯——这才是长期价值所在。

项目地址：github.com/mattpocock/skills

安装命令：npx skills@latest add mattpocock/skills

Star 数：80,000+（截至 2026 年 6 月）

许可证：MIT