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@latestaddmattpocock/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的完整流程可以概括为：
这里有两个细节很实用。
第一，假设要可证伪：
如果 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 运维平台这类复杂系统，这种“小而可组合”的工作流，比一个巨大的万能提示词更可靠，也更容易在团队里长期使用。
