一个仓库装下整个工程师 AI 工作流：google-engineer-skills 横评
如果让你给一个 Google Cloud 工程师配一整套 AI 助手，你会怎么做？装十几个分散的 Skill？一个个找 GitHub？等 Prompt 漂移、版本错乱？
最近挖到一个仓库，把这个痛点直接打包解决：benjaminwestern/google-engineer-skills —— 一个仓库、14 个 Skill，覆盖 Terraform、写文档、画架构图、跑 SQL、自动化浏览器、做终端 UI，几乎包圆了 GCloud 工程师的整个工作流。
这是什么形态？
它不是”一个 Skill 解决一个问题”，而是典型的”主题合集”形态：以 Google Cloud 工程师这一身份为锚点，把该身份下高频需要的工具、流程、写作、绘图能力一次性整合到一个仓库。SkillsMP 上它显示为单一 creator 下的 14 个 skill，按”Software Developers / Technical Writers / Web Developers” 等多职业分类，覆盖率 100%。
类似的形态还有 K-Dense 的 177 个 scientific skills（已发过）、obra/superpowers 的全流程工程化 Skill 包，本质都在说同一件事：单一 Skill 已死，工作流合集才出效率。
里头的”狠角色”
挑几个我读完 SKILL.md 后印象最深的：
- writing —— 通用技术写作”house voice”模板。它强制规定：先确认文档类型和受众、默认 Australian/British 拼写、用 web research 验证技术声明、而不是靠模型记忆。每种类型有独立骨架（README/ADR/runbook/blog/release notes 都不一样），但又不锁死结构。这是对抗 AI 文档那股”模板味”的一剂猛药。
- tech-writer —— 更严格的版本，锁定 Pyramid Principle 和视觉化 markdown 输出，专门面向说服型文档和解决方案设计。
- terraform —— 八个 mantra 直接列在 SKILL.md 第一屏：必须 versions.tf / backend.tf / locals.tf、按领域纵向切文件、YAML factory 模式…… 配合 Cloud Foundation Fabric 模块使用，等于把 IaC 经验浓缩进几百行 Prompt。
- d2 —— 专门做架构图的 D2 声明式绘图，比 Mermaid 更现代、语法更干净。
- playwright-cli / duckdb / jq / worktrunk —— 覆盖浏览器自动化、本地分析 SQL、JSON 处理、并行 agent 编排。
主题合集为什么是趋势？
2025 年 Anthropic 开放 SKILL.md 标准后，社区经历了两个阶段：
- 第一阶段（单 Skill 爆发）：所有人都在写”一个 Skill 解决一件事”，GitHub 上出现了海量独立的 pdf-skill、image-skill、git-skill。
- 第二阶段（合集化）：开发者意识到——AI 真正吃不动”几百个零散 Skill”，它需要的是”按角色组合的工作流套餐”。于是主题合集开始井喷。
google-engineer-skills 就是第二阶段的典型实践：用职业身份切分 Skill 边界，而不是按工具切分。
怎么用？
一行命令即可：
npx skills add https://github.com/benjaminwestern/google-engineer-skills
或者单独装某个 Skill：
npx skills add https://github.com/benjaminwestern/google-engineer-skills --skill tech-writer
依赖用 mise 统一管理（Terraform、D2、Playwright CLI 等）。仓库本身是 MIT License，技能可商用。Stars 目前 30+（SkillsMP 收录），社区维护持续更新到 2026 年 7 月。
我的看法
如果你正做”主题合集型”Skill 库，这条仓库值得逐行抄作业——先把一个身份的所有高频能力打全，再考虑扩展到下一个身份。比漫无目的堆”通用 PDF 工具”有意义得多。
仓库地址 👇
https://github.com/benjaminwestern/google-engineer-skills
GitHub: https://github.com/benjaminwestern/google-engineer-skills
评论区
登录后可评论。