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 总结了四类失败模式失败模式根因对应 SkillAgent 没做我想做的事需求对齐失败/grill-me、/grill-with-docsAgent 太啰嗦缺乏项目术语和表达边界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 skillslatestaddmattpocock/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 个调用者里如果复杂度只是扩散了那说明这个模块虽然看起来麻烦但它在承担架构价值。七、不同规模项目怎么组合 Skills1. 小项目快速 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/tddAI 运维系统/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 运维平台这类复杂系统这种“小而可组合”的工作流比一个巨大的万能提示词更可靠也更容易在团队里长期使用。
用 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 总结了四类失败模式失败模式根因对应 SkillAgent 没做我想做的事需求对齐失败/grill-me、/grill-with-docsAgent 太啰嗦缺乏项目术语和表达边界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 skillslatestaddmattpocock/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 个调用者里如果复杂度只是扩散了那说明这个模块虽然看起来麻烦但它在承担架构价值。七、不同规模项目怎么组合 Skills1. 小项目快速 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/tddAI 运维系统/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 运维平台这类复杂系统这种“小而可组合”的工作流比一个巨大的万能提示词更可靠也更容易在团队里长期使用。
