拆解 17 万星 GitHub 项目：撕开 AI 编程滤镜，回归真实的软件工程。- 大数跨境

首页

拆解 17 万星 GitHub 项目：撕开 AI 编程滤镜，回归真实的软件工程。

AI大模型应用实践

2026-07-19

导读：真实的软件工程，代码速度并不是唯一指标，甚至不是最重要的指标。

点击上方

蓝字

关注我们

Vibe Coding 的确很迷人，提出想法、AI 生成代码、对话修改，很快一个功能就完成了 — 是的，“文科生也能写软件”。但我们一直在强调：

真实的软件工程，速度并不是唯一指标，甚至不是最重要的指标。

那些要求“生产就绪“的软件系统，最重要的是可控 — 需求问清楚了吗？架构是否遵循了最佳模式？测试覆盖如何？

之前介绍的 SDD（规范驱动的开发）— 把需求与验收标准写成清晰规范，让人和 AI 紧密围绕这些规范协作开发，就是一种控制之道。

不过本文来拆解另一种轻量级的约束工具包 — 把成熟的软件工程方法，整理成可灵活组合的 Agent Skills。

它来自 TypeScript 界天花板级大师 — Matt Pocock 的开源项目：mattpocock/skills，当前已获得 17万+ stars。

Matt 同学的私藏 Skills

Matt Pocock 这个项目的标题非常直白：“给真正工程师的 Skills，直接来自我的 .claude 目录。”

所以这不是一套宏大方法论，而是 Matt 把自己每天与各种 Coding Agent 协作时，为自己量身定做的私人工具箱拿了出来，并鼓励大家一起来用并改造它，变成你自己的方法。

项目灵感来自 Matt 在真实 AI Coding 中反复遇到的几类工程问题，比如：

理解偏差：你以为 AI 听懂了，结果它做出另一个东西。
领域盲区：Agent 不懂项目里的领域知识，但假装很懂。
反馈缺失：没有测试、浏览器等反馈回路，AI 一直“盲飞”。
架构失控：代码生成越快，复杂度和技术债也积累得越快。

相信凡是深度使用 AI Coding 的开发者都深有体会（写个小游戏、小网站的不算）。Matt 的这套 Skills 就是要把这些问题的解决方法变成了可重复调用的工具：对齐与拆解需求；测试驱动开发；架构优化等等。

Matt 的这套 Skills 的最大特点是：

它不会强制接管整个开发流程，很多时候你可以忽略它。Matt 刻意把它们做得轻量、可组合、可改造，也不绑定某个模型和工具。你可以用其中的几个 Skill串联从需求澄清到拆解设计、实现、评审的完整链路；也可以只取一个 TDD 来用 — 你拥有绝对的控制权。

快速看懂核心的 Skills

截止目前仓库共正式发布 22+ 个Skills。这些 Skills 并非一成不变，可能在你看到的时候，有的已经被废弃，也有可能出现了新的 Skill。

大致可以把这些 Skills 按照四个维度的能力划分：

我们对这些技能做一个整体认识。

对齐与规划：把“做什么”彻底说清楚

这一类 Skills 负责减少需求理解的偏差：从访谈、研究、原型出发，逐步需求意图清晰化，沉淀为规格书与功能纵向切片。

纵向切片：把一个需求拆成多个独立的完整“功能分片”，每一片都贯穿数据、后端、前端，而不是按技术层次划分，便于独立实现与验收。

实现与反馈：让代码在真实的反馈信号里迭代

这一类 Skills 把实现控制在反馈“闭环”里：测试驱动的闭环开发；基于异常复现与验证的 Bug 诊断闭环等。

架构与质量：防止速度变成技术债

这一类 Skills 关注代码长期的可维护性与质量：领域语言（上下文）是否一致、模块与接口设计是否合理、实现是否符合团队标准与规格。

项目协作：让流程跨任务、跨会话延续

还有一类 Skills 不直接产出代码，主要是一些工程辅助、以及团队协作的工具。这部分技能必须是显式调用，模型不会自动触发。

该项目的 Skills 分成用户显式调用和模型可触发两类。凡是设定了 disable-model-invocation=true 的技能不会由 Agent 自动触发，必须自己主动唤起（通常是一些流程启动入口，比如 /implement）。

如果我们把这些 Skills 按照软件开发生命周期的阶段来落位，大致如下（某些 Skill 可以跨越多个阶段，比如 diagosing-bugs）：

接下来我们就按这个开发流程，拆解探索其中最核心的若干 Skill。

安装，并让 Skills 认识你的项目

对 Claude Code、Codex 和其他兼容 Skills 的 Coding Agent 工具，通用安装入口仍然是 skills.sh 安装器：

npx skills@latest add mattpocock/skills

安装时会提示选择需要的 Skills 和目标智能体。注意选择 setup-matt-pocock-skills 技能，然后在你的代码仓库里调用它：

/setup-matt-pocock-skills

这是一个初始化的设置技能，它启动一个交互式的配置流程：

读取当前代码仓库的现状（比如是否有 Git 远程等）
确认后续的 Issues 追踪管理器（是用 Git Issues 还是本地文档）
确认本地的领域文档、架构决策、Specs 的存放位置
最后，将上面的配置确认后写入 docs/agents/*.md 中

后续所有 Skills 将共享这套项目设定。比如笔者的 Issues 跟踪设定如下：

这代表在后续使用其他 Skills 的过程中，比如生成新开发任务、Bug 修复任务等，就会自动提交到 GitHub Issues 并追踪。

准备好这个基本工作后，就可以开启你更可控的 AI Coding 过程。

使用 Skills ，开启你的软件工程闭环

Mattpocock/skills 不会强制接管你的开发流程，但如果只把每个 Skill 当作一条新命令，项目就只能是一个“提示词收藏夹”。使用它更好的方式，是使用适当的 Skills 把一次功能开发串成有前后依赖的工程闭环。

下面是这个闭环中你最可能需要的典型 Skill，我们逐个来拆解。

/ask-matt：技能导航器

在你不知道应该调用哪个技能时，这个技能用来给你“指路”。比如：

ask-matt 是一个技能“导航器” — 告诉你什么条件下用哪个 Skill。

/grill 系列：把模糊需求拷问清楚

/grill 的系列技能（包括/grilling,/grill-with-docs）用来在实现具体功能之前，通过持续对话的形式来引导并“拷问”你，对某个模糊想法或需求的多方面进行探讨，并达成共同理解。比如

/grill-with-docs 我希望对系统首页驾驶舱做优化，提供外部舆情态势的概览和系统监控状态

随后，AI 会遵循访谈纪律：一次只问一个问题，并给出它的建议和理由，但会将最终取舍的决定权交给你。

/to-spec：把共识落地成开发规格

在访谈结束后，/to-spec 综合当前对话与代码库现状，形成规格书（Specs），包括问题陈述、解决方案、用户故事、实现决定、测试决定和范围边界等。

其中有一个很工程化的要求，是先确认测试的 seam（接缝），即可以通过哪个公开接口观察行为。优先使用已有接缝，数量越少越好。因为一旦测试位置选错，后面写得再多，也可能只是在验证内部实现。

接缝（seam）可以理解为：模块与外部连接的位置，也是调用者使用功能、测试观察行为的位置。

就像墙上的插座：你不需要知道墙内电线如何铺设和重构，只需知道插座的规格，就可以测试它。典型的软件“接缝”处可以是：HTTP Restful 接口、公共函数、消息入口、CLI命令等。

/to-issues & /to-tickets：将大需求拆成小任务

这两个技能很相似，其作用都是把大需求拆成可独立实施、验证和跟踪的纵向任务切片，但 to-tickets 的依赖管理与重构支持更强。

to-issues：把需求拆成可独立领取、端到端验收的 Issue。例如把“优惠券功能”拆成领券、下单核销、退款返还三个完整功能。
to-tickets：把需求拆成带前置依赖的 Ticket。例如先增加新版券状态，再分批迁移订单，最后删除旧状态。

以开发一个“优惠券下单”的功能需求为例，to-issues 会尝试生成多个端到端的切片，共 3个 Issue：

用户领取优惠券：数据库、接口、页面、测试全部完成。
下单使用优惠券：完整打通核销流程。
退款返还优惠券：完整打通退款流程。

每个 Issue 还会进行标记：

AFK：代理可以独立完成。
HITL：需要人工参与，例如确认优惠券叠加规则。
覆盖了哪些用户故事。

它不会把工作横向拆成“先建表、再写 API、最后做前端页面” 这样的 Issue，因为单独完成其中任何一个都无法测试。

to-tickets 也采用端到端切片，但会更严格地表达依赖关系；另外它要求每一个ticket 都尽量控制在一次全新的 Agent 上下文能够完成的规模，即可以被一个新的编程 Agent 领取，而不是必须由同一个长期对话来传递隐含知识。

当然，不是所有的迭代都能被垂直切片。

比如我需要修改某个数据表结构或增加枚举值。这种情况，两个技能仍然会尽量确保每一个 issue 或 ticket 可以被独立验证，或者采用“扩展->迁移->收缩“的方式，不会逐个修改每个模块（不便于验证），而是：

这两个技能的选择原则大致是：

普通的产品需求、PRD、场景实现用 to-issues
涉及人工任务（比如确认配置）用 to-issues
多任务并行、任务依赖关系复杂用 to-tickets
大范围重构、字段/接口迁移用 to-tickets

这是两个非常重要、也很常用的技能。用来帮助我们合理拆分需求、设计测试闭环、建立依赖关系，以弥补普通 Vibe Coding 所缺乏的工程思想。

/implement 与 /code-review：一个负责实现，一个负责验收

在准备好 issues 或者 tickets 后，就可以让 Agent 来领取实现。

/implement：是正式开发的执行技能。它根据已经确认的Specs、Issues 或Ticket 开始写代码，并优先使用 TDD，在开发过程中持续运行相关测试和验证，最后运行完整测试集并提交代码。
/code-review：在代码实现完成后审查所有的开发与改动。

Code-review 会从两个相互独立的角度审查改动：

Standards：是否符合项目规范，是否存在重复代码、职责分散、过度抽象等代码问题。
Spec：是否真正实现了 Issue 与 Specs 要求，是否存在遗漏、错误理解或范围膨胀（即实现与需求对齐）。

比如，代码虽然写得很规范、很漂亮，但遗漏了“过期优惠券不能返还”这个功能，那么 Standards 可能通过，Spec 仍然失败；反过来，功能实现了，但却把相同的代码在多处拷贝实现，可能就通不过 Standards 检查。

简单总结，implement 与 code-review 一个负责把功能做出来；一个负责检查做的对不对、做的好不好。

/diagnosing-bugs：先抓住问题，再分析原因

系统功能实现后，诊断与修复潜在的 Bugs 是最常见的任务（ TDD 的测试通过不代表没有 Bug），这时候你可以用 diagnosing-bugs 这个技能。

该技能的核心逻辑不是立即阅读代码并分析原因，而是试图建立一个快速、稳定、能够准确复现问题的反馈闭环，最终来修复问题：

比如，系统偶尔会出现“同一订单重复扣款”，你需要修复该 Bug。

/diagnosing-bugs 不会直接猜测是否并发控制有问题，而是会：

尝试真实的支付回调，并重复回放。
把复现步骤缩小到最少。
提高问题出现的概率，使结果足够稳定。
提出3到5个可以被证伪的原因假设。
每次只改变一个条件，通过断点、日志或对比实验排除假设。
在正确接缝处补充回归测试，再实施修复。

如果始终无法构造能准确捕获问题的反馈循环，它才会请求日志、现场环境或临时监控权限等，来辅助诊断。

这种方式的好处是可以预防 Agent 修复中经常出现的“越改越错”的问题。

/improve-codebase-architecture：优化代码架构，提高可维护性

随着大型系统的不断迭代，架构会越来越复杂，越来越难维护。

此时你就可以借助这个技能 — 通过对代码库的扫描，寻找提升可维护性的架构优化机会 — 特别是对于代码库中经常变化、难以理解与测试的区域，发现可以把“浅模块”改造成“深模块”的机会。

“浅”模块和“深”模块

所谓浅模块，是指它虽然把代码封装起来了，但调用者仍然需要了解大量内部细节。例如，一个优惠计算模块提供若干个方法：先查优惠券、再校验门槛、然后计算折扣、处理叠加规则，最后更新订单。

深模块则相反：它用较小的接口提供较多能力。例如，只暴露一个“计算订单报价”的接口，调用者传入订单、用户、优惠券，模块返回报价结果。

深模块的价值不仅是方便“面向接口编程”，更重要的是隐藏复杂性：

调用者获得更简单的使用方式；维护者可以在一个地方完成修改；测试也能够通过统一接口（即“接缝”）验证完整行为。

improve-codebase-architecture 技能就是扫描代码寻找这样的机会。扫描完成后，它会用可视化报告展示优化前后的结构，由你选择值得继续深入的方向，而不会直接对代码进行大规模重构。

以下是一个报告中的优化建议样例：

技能会给出“Before”和“After”的状态，方便你做决策。

这个技能适合代码后期越来越难改、逻辑散落、测试接缝不清晰的项目，可以帮助你看清问题和选择方向。

与其他的 SDD 工具的对比与选择

之前我们介绍过一些常见的 SDD 工具，但它们与 mattpocock/skills 解决问题的方法与定位并不完全相同：

mattpocock/Skills 更像一套可组合的工程纪律库：需要澄清需求时用 grilling，需要落规格时用 to-spec，需要测试、诊断或评审时再调用相应 Skill。它不会主动接管整套研发流程，适合已有开发方法、只希望补强 AI 工程质量的团队。
Superpowers 同样建立在 Skills 之上，但更强调自动化和强制纪律：从头脑风暴、计划、Worktree、TDD、子智能体开发到评审，关键步骤会被自动接管与串联。它适合希望 Agent 默认遵循完整开发闭环的团队，但对小修改可能偏重。
BMAD 则更像一支 AI Coding 时代的“虚拟研发团队”，通过产品、架构、开发等专业角色和大量工作流覆盖完整生命周期，适合复杂新产品或缺少成熟研发方法的团队，代价是需要学习更多角色、阶段和产物。
Spec Kit 使用 Spec → Plan → Tasks → Implement 的标准链路，通过总体宪法、模板和 Checklist 等统一组织内的 SDD 语言，适合团队协作、合规和标准化要求较高的场景，但复杂性与上手难度要比 BMAD 小。
OpenSpec 则更适合已有的存量系统：通过标准化的 Change 开发流程（基于 Skills）来组织与管理存量系统的持续迭代过程，维护过程中的制品。

简单总结：

已有流程、需要更多的工程方法与纪律，选 mattpocock/Skills
需要智能体自动接管与执行纪律，选 Superpowers
大型新项目，需要重量级的端到端 SDD 流程框架，选 BMAD 或 SpecKit
存量代码库、希望标准化需求开发，沉淀需求变化，选 OpenSpec

从笔者个人经验（仅供参考）：

mattpocock/skills 可以作为现有流程的一个工程纪律补充。比如让 Spec Kit 或 OpenSpec 管流程主线，再用 /tdd、/diagnosing-bugs 和 /code-review 补执行质量；但 BMAD 和 Superpowers 已经足够深度的管理了开发流程，不是很必要再叠加一套工程体系。

总结

AI 编程的普及让代码变得越来越廉价，但错误、重复和架构熵增的速度也前所未有。只追求生成代码速度，团队得到的可能不是更快交付的软件，而是更快堆积的“屎山”代码和技术债。

Mattpocock/skills 这套技能，可以更好的帮助你从 Vibe Coding 回到真正可控的软件工程轨道：把模糊意图澄清、沉淀成可验证的规格、把大需求拆成可持续验证的小任务闭环，并通过 TDD、代码评审与架构治理持续纠偏。

如果你在使用 AI Coding，且已经开始遇到需求越聊越偏、代码改了又改、越来越难维护，那么可以尝试这个项目，特别是正在探索 AI 研发规范的团队 — 你不需要把所有的 Skills 用起来，可以从效果最明显的环节开始。

END