用 Skills 驱动 AI 开发：Matt Pocock 工作流在 DevOps 场景里的落地实践

AI 编程助手已经不只是"帮我写一段代码"的工具了。真正用进日常开发后，我们很快会遇到几个熟悉的问题：

• 需求还没说清楚，Agent 已经开始写代码。
• 代码能生成，但跑不起来。
• Bug 修复像猜谜，改了几轮还是不确定根因。
• 项目越做越大，模块边界越来越糊。
• Agent 输出太啰嗦，很多 token 花在重复解释上。

这些问题并不是某一个模型独有的，而是 AI Coding 进入真实工程场景后必然暴露出来的流程问题。

Matt Pocock 的 skills 仓库给出了一套很有意思的解法：不要试图用一个"大而全"的超级流程接管项目，而是把开发过程拆成一组小而可组合、模型无关的技能。需要需求澄清时用 /grill-me，需要写 PRD 时用 /to-prd，需要拆任务时用 /to-issues，需要修 Bug 时用 /diagnose，需要架构治理时用 /improve-codebase-architecture。

重点讲这套 Skills 工作流如何落到 DevOps、Kubernetes、自动化平台和 AI 运维系统这类工程场景里。

地址：https://github.com/mattpocock/skills

命令	作用	使用场景
/grill-me	深度需求访谈	复杂功能设计前、消除模糊点
/grill-with-docs	基于领域文档需求对齐	已有项目上下文 / ADR，需统一术语
/to-prd	将对话转化为正式 PRD	需求确认后，生成可追溯的产品文档
/to-issues	垂直切片式任务拆分	多 Agent 或多人并行开发
/prototype	快速可运行原型构建	MVP 验证、UI/状态逻辑比选
/tdd	标准的红-绿-重构循环	后端 API、核心业务逻辑实现
/triage	问题分类与优先级排序	Bug 管理、任务队列整理
/diagnose	严格的多步骤诊断流程	复杂 Bug、性能回归排查
/zoom-out	提供更高层次的全局视角	复盘设计、理解不熟悉代码
/improve-codebase-architecture	主动寻找架构优化点	技术债治理、代码腐化修复
/caveman	极简沟通模式（省 Token）	防止 Agent 啰嗦，加速对话
/write-a-skill	编写并沉淀团队新技能	工作流标准化、团队规范自动化

# 1. 需求与架构
/grill-me 或 /grill-with-docs → /to-prd → /zoom-out

# 2. 任务拆分
/to-issues   ->  /triage (问题分类与优先级排序)

# 3. 并行开发
/prototype (前端/UI) → /tdd (后端/逻辑) → /diagnose (故障排查)

# 4. 问题治理
/zoom-out

# 5. 长期维护
/improve-codebase-architecture → /write-a-skill

---

一、AI Coding 的四个常见失败模式

很多人以为 AI 写不好代码，是因为提示词不够细。实际用久了会发现，问题往往不在"提示词长度"，而在"工作流断层"。

Matt Pocock 总结了四类失败模式：

失败模式	根因	对应 Skill
Agent 没做我想做的事	需求对齐失败	/grill-me、/grill-with-docs
Agent 太啰嗦	缺乏项目术语和表达边界	CONTEXT.md、/caveman
代码不工作	缺乏运行反馈	/tdd、/diagnose
代码变成泥球	架构持续腐化	/improve-codebase-architecture、/to-prd

这四个问题在 DevOps 场景里尤其明显。

比如你说"做一个 AI 运维平台"，Agent 可能直接开始生成前端页面，但真正的问题还没展开：要接 Kubernetes 吗？要接 Prometheus 吗？告警是只展示，还是要做自动诊断？用户是 SRE、研发，还是值班人员？要不要支持多集群？这些没问清楚，后面写得越快，返工越多。

所以这套工作流的第一条原则是：拷问先于建造。

---

二、先搭三块基础设施

在真正使用这些 Skills 前，最好先搭好三块基础设施。

1. CONTEXT.md：共享领域语言

CONTEXT.md 不是实现文档，也不是项目说明书，而是一个术语表。

它要回答的是：

• "服务"在这个项目里是 Kubernetes Service，还是业务服务？
• "告警"是 Prometheus Alert，还是平台里的事件记录？
• "集群"指单个 K8s 集群，还是多租户资源池？
• "用户"是登录账号，还是业务系统里的最终用户？

术语清楚以后，Agent 的命名、变量、文档和回答都会更稳定。更重要的是，它能用一个词替代一长串解释，降低 token 消耗。

2. docs/adr/：架构决策记录

ADR 不需要什么都记，只记录那些满足三个条件的决策：

• 难以逆转。
• 缺少上下文会令人困惑。
• 是真实权衡后的结果。

比如"为什么告警规则不直接存在数据库，而是通过 GitOps 管理"，这就适合写 ADR。以后 Agent 做相关改动时，就不会随手把架构打回另一个方向。

3. /setup-matt-pocock-skills：初始化工作流

每个仓库建议运行一次初始化：

npx skills@latest add mattpocock/skills

安装后务必选择 /setup-matt-pocock-skills，它会帮你确认：

• 使用 GitHub、Linear 还是本地文件作为 Issue Tracker。
• /triage 使用哪些标签。
• PRD、ADR、上下文文档保存在哪里。

这一步看起来像配置，其实是在帮 Agent 建立"项目运行规则"。

---

三、标准功能开发：从想法到可交付

对于一个中大型功能，推荐链路是：

/grill-with-docs → /to-prd → /to-issues → /tdd

如果项目刚起步，还没有 CONTEXT.md 和 ADR，可以先用 /grill-me：

/grill-me "我要做一个 AI 运维平台"

第一步：用 /grill-with-docs 拷问需求

/grill-with-docs 不是普通的"帮我分析需求"。它会基于已有文档、CONTEXT.md 和 ADR 反复追问。

它适合问这些问题：

• 这个功能解决的是谁的痛点？
• 哪些场景明确不做？
• 输入和输出分别是什么？
• 失败路径怎么处理？
• 这个概念在项目术语里叫什么？
• 和现有模块的边界在哪里？

对于 DevOps 平台，这一步很值钱。比如"自动诊断 Pod 异常"这句话很模糊，至少要继续拆：

• 诊断 CrashLoopBackOff，还是 Pending，还是 OOMKilled？
• 诊断只给原因，还是给修复建议？
• 是否允许自动执行修复动作？
• 诊断数据来自 Kubernetes API、Prometheus、日志系统，还是事件流？
• 结果是否需要保存成工单？

这些问题没问清楚，后面很容易做成一个"看起来很智能、实际不可用"的功能。

第二步：用 /to-prd 生成 PRD

需求对齐后，再用 /to-prd 把对话上下文合成 PRD。

这里有个细节：/to-prd 不应该重新采访用户，而是综合已有讨论，把已经明确的目标、边界、验收标准写下来。

一个好的 PRD 应该包含：

• 背景和目标。
• 用户场景。
• 功能边界。
• 非目标。
• 数据来源。
• 验收标准。
• 风险和开放问题。

对于长期项目，PRD 还应该尊重已有 ADR，用项目术语写，而不是重新发明一套说法。

第三步：用 /to-issues 垂直切片

任务拆分时，最容易犯的错误是水平切片：

先做数据库
再做后端 API
再做前端页面
最后补测试

这看起来有条理，但很容易造成长时间没有可验证交付。

Matt Pocock 的工作流强调垂直切片：

一个 Issue = schema → API → UI → tests 的一条窄而完整路径

比如"Pod 异常诊断"可以拆成：

• 展示单个 Pod 的基础诊断结果。
• 增加 CrashLoopBackOff 规则识别。
• 增加 OOMKilled 诊断和 Prometheus 内存曲线。
• 增加诊断历史记录。
• 增加前端详情页和回归测试。

每个 Issue 都尽量小，但能独立验证。这样才适合多人或多 Agent 并行。

第四步：用 /tdd 实现

/tdd 的重点不是"先写很多测试"，而是红绿重构循环：

一个测试 → 一个实现 → 重构 → 下一个测试

尤其要避免水平 TDD：

先写所有测试，再写所有实现

正确方式是纵向推进。比如先写一个"CrashLoopBackOff Pod 应返回重启次数和最近错误事件"的测试，让它失败，再实现最小代码让它通过，然后重构。

测试应该验证行为，不验证实现。这样后续重构模块时，测试不会因为内部结构变化而大面积失效。

---

四、Bug 和线上故障：先分类，再诊断

线上问题来了，不要一上来就 /diagnose。

更合理的顺序是：

/triage → /diagnose → /tdd

/triage 和 /diagnose 都在处理"问题"，但它们完全不是一回事。

维度	/triage	/diagnose
核心目标	分类、定级、分配	重现、定位、修复
关注点	这是什么问题，谁来做，多急	为什么出问题，怎么修，如何防回归
产出物	带标签、优先级、负责人的 Issue	根因分析、修复代码、回归测试
是否改代码	不改代码	会改代码
适合角色	值班、项目管理、一线支持	开发者、SRE、平台工程师

一个线上告警进来，先用 /triage 判断：

• 是 P0、P1 还是普通问题？
• 是 bug、enhancement，还是误报？
• 是否信息不足，需要报告者补充？
• 是否适合交给 Agent 自主处理？

确认是明确的技术故障后，再进入 /diagnose。

---

五、/diagnose：把猜 Bug 变成科学排查

/diagnose 最重要的一点，是先构建反馈循环。

很多排障失败，不是因为不会修，而是因为没有稳定复现。没有复现，就只能靠猜。

素材里把反馈循环排了优先级：

1. 失败测试
2. curl / HTTP 脚本
3. CLI 调用 + 快照对比
4. 无头浏览器脚本
5. 重放 trace
6. 一次性 harness
7. 属性 / 模糊测试
8. 二分 harness
9. 差分循环
10. HITL 脚本

目标很明确：

2 秒确定性循环，胜过 30 秒不稳定循环。

在 Kubernetes 场景里，这意味着不要一开始就盯着大集群反复手工操作。能不能用一段最小 YAML 复现？能不能用 kind 搭一个小环境？能不能把 Prometheus 查询固定下来？能不能把 HTTP 请求写成脚本？

/diagnose 的完整流程可以概括为：
构建反馈循环
复现问题
提出 3-5 个可证伪假设
按假设插入探针
一次只改变一个变量
确认根因
写回归测试
修复问题
清理调试日志和临时脚本

这里有两个细节很实用。

第一，假设要可证伪：

如果 X 是原因，那么改变 Y 会让 bug 消失。

第二，调试日志要能清理：

[DEBUG-1234] current pod phase: Pending

统一加前缀，修完后直接搜索删除，避免把临时调试信息留进代码库。

---

六、架构治理：别等泥球变大再处理

当项目开始长期维护，最值得定期使用的是：

/improve-codebase-architecture

它不是"帮我重构一下代码"，而是寻找架构深化机会。

什么叫深化？简单说，就是把浅模块变成深模块。

浅模块的特征是：

• 接口很大，实现也不简单。
• 调用者要知道很多内部细节。
• 一个概念分散在多个目录里。
• 想理解一个业务词，要跳很多文件。

深模块的特征是：

• 接口小。
• 实现可以复杂，但复杂度封装在内部。
• 调用者不用知道太多细节。
• 术语、边界和职责稳定。

在 DevOps 平台里，常见的深化机会包括：

• 把 Prometheus 查询拼接从多个页面抽到统一查询模块。
• 把 Kubernetes 事件解析封装成诊断上下文。
• 把告警等级计算从 UI 和后端散落逻辑中提取出来。
• 把"集群""租户""命名空间"等核心概念写入 CONTEXT.md。

这里有一个很好用的判断方法：删除测试。

问自己：

如果删掉这个模块，复杂度是消失了，还是分散到 N 个调用者里？

如果复杂度只是扩散了，那说明这个模块虽然看起来麻烦，但它在承担架构价值。

---

七、不同规模项目怎么组合 Skills？

1. 小项目：快速 MVP

适合个人工具、小型 Demo、自动化脚本。

/grill-me
/prototype
/tdd

先问清楚目标，再快速做一个能跑的原型，最后用 TDD 稳住核心逻辑。

2. 中型项目：推荐默认流程

适合中后台、AI 平台、DevOps 系统、Kubernetes 工具平台。

/grill-me
/to-prd
/to-issues
/prototype
/tdd
/zoom-out

这个流程比较均衡：有需求澄清、有正式文档、有任务拆分、有原型、有测试，还有架构复盘。

3. 企业级项目：完整闭环

适合大型微服务、企业 DevOps 平台、多团队协作、长期维护系统。

/grill-with-docs
/to-prd
/to-issues
/prototype
/tdd
/triage
/diagnose
/zoom-out
/improve-codebase-architecture
/write-a-skill

企业级项目不要追求"一个命令解决全部问题"。真正有效的是在不同阶段调用不同 Skill，让人始终参与关键决策。

---

八、DevOps 和 K8s 场景的推荐组合

结合 DevOps / Kubernetes 场景，可以直接按下面这张表选：

场景	推荐组合
Kubernetes 平台	/diagnose + /zoom-out
自动化运维平台	/to-prd + /tdd
AI 运维系统	/grill-me + /to-issues
可观测性平台	/prototype + /tdd
故障分析系统	/triage + /diagnose
架构治理	/improve-codebase-architecture

比如做可观测性平台时，前端体验很重要，可以先 /prototype 做多种交互方案，再用 /tdd 保证查询逻辑、告警规则和数据转换可靠。

做故障分析系统时，千万不要直接让 Agent "修复所有问题"。先 /triage 分类，再 /diagnose 对某一个明确故障建立反馈循环。

做 Kubernetes 平台时，/zoom-out 很有用。因为很多问题不是某一行代码错了，而是概念边界错了：集群、命名空间、工作负载、告警、事件、指标之间的关系没有建好。

---

十、总结

Skills 不是让 AI 接管开发，而是把经典工程实践拆成可组合的动作，让人和 Agent 在正确的阶段做正确的事。

对于 DevOps、Kubernetes、AI 运维平台这类复杂系统，这种"小而可组合"的工作流，比一个巨大的万能提示词更可靠，也更容易在团队里长期使用。