mle-workflow

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# 机器学习工程工作流

使用此技能将模型工作转化为生产 ML 系统，具有清晰的数据契约、可重复的训练、可测量的质量门槛、可部署的工件和操作监控。

## 何时激活

- 规划或审查生产 ML 功能、模型刷新、排名系统、推荐器、分类器、嵌入工作流或预测管道
- 将笔记本代码转换为可重用的训练、评估、批量推理或在线推理管道
- 设计模型推广标准、离线/在线评估、实验跟踪或回滚路径
- 调试由数据漂移、标签泄漏、陈旧特征、工件不匹配或不一致的训练和服务逻辑引起的故障
- 添加模型监控、金丝雀推出、影子流量或部署后质量检查

## 范围校准

仅使用适合面前系统的路径。此技能对排名、搜索、推荐、分类器、预测、嵌入、LLM 工作流、异常检测和批量分析有用，但不应强制将一种架构用于所有这些。

- 不要假设每个模型都有监督标签、在线服务、特征存储、PyTorch、GPU、人工审查、A/B 测试或实时反馈。
- 当数据契约、基线、评估脚本和回滚笔记会使更改可审查时，不要添加重量级 MLOps 机械。
- 当项目缺少标签、延迟结果、切片定义、生产流量或监控所有权时，使假设明确。
- 将示例视为可互换的脚手架。用项目原生等效项替换指标、服务模式、数据存储和推出机制。

## 相关技能

- `python-patterns` 和 `python-testing`：Python 实现和 pytest 覆盖率
- `pytorch-patterns`：深度学习模型、数据加载器、设备处理和训练循环
- `eval-harness` 和 `ai-regression-testing`：推广门槛和代理辅助的回归检查
- `database-migrations`、`postgres-patterns` 和 `clickhouse-io`：数据存储和分析表面
- `deployment-patterns`、`docker-patterns` 和 `security-review`：服务、机密、容器和生产强化

## 重用 SWE 表面

不要将 MLE 与软件工程分开。大多数 ECC SWE 工作流直接适用于 ML 系统，通常具有更严格的故障模式：

推荐的 `minimal --with capability:machine-learning` 安装使核心代理表面与此技能一起可用。对于仅技能或代理受限的 harness，在目标支持代理的地方将 `skill:mle-workflow` 与 `agent:mle-reviewer` 配对。

| SWE 表面 | MLE 用途 |
|-------------|---------|
| `product-capability` / `architecture-decision-records` | 将模型工作转化为明确的产品契约并记录不可逆的数据、模型和推出选择 |
| `repo-scan` / `codebase-onboarding` / `code-tour` | 在引入并行 ML 堆栈之前查找现有的训练、特征、服务、评估和监控路径 |
| `plan` / `feature-dev` | 将模型更改范围化为具有数据、评估、服务和回滚阶段的产品能力 |
| `tdd-workflow` / `python-testing` | 在实现之前测试特征转换、分割逻辑、指标计算、工件加载和推理 schema |
| `code-reviewer` / `mle-reviewer` | 审查代码质量加上 ML 特定的泄漏、可重现性、推广和监控风险 |
| `build-fix` / `pr-test-analyzer` | 诊断损坏的 CI、不稳定的评估、缺失的 fixture 和环境特定的模型或依赖失败 |
| `quality-gate` / `test-coverage` | 要求转换、指标、推理契约、推广门槛和回滚行为的自动证据 |
| `eval-harness` / `verification-loop` | 将离线指标、切片检查、延迟预算和回滚演练转化为可重复门槛 |
| `ai-regression-testing` | 将每个生产错误保留为回归：缺失特征、陈旧标签、坏工件、schema 漂移或服务不匹配 |
| `api-design` / `backend-patterns` | 设计预测 API、批量作业、幂等重新训练端点和响应包络 |
| `database-migrations` / `postgres-patterns` / `clickhouse-io` | 版本标签、特征快照、预测日志、实验指标和漂移分析 |
| `deployment-patterns` / `docker-patterns` | 使用健康检查、资源限制和回滚打包可重现的训练和服务映像 |
| `canary-watch` / `dashboard-builder` | 使推出健康可见，具有模型版本、切片、漂移、延迟、成本和延迟标签仪表板 |
| `security-review` / `security-scan` | 检查模型工件、笔记本、提示、数据集和日志中的机密、PII、不安全反序列化和供应链风险 |
| `e2e-testing` / `browser-qa` / `accessibility` | 测试消费预测的关键产品流程，包括可解释性和后备 UI 状态 |
| `benchmark` / `performance-optimizer` | 测量吞吐量、p95 延迟、内存、GPU 利用率以及每次预测或重新训练的成本 |
| `cost-aware-llm-pipeline` / `token-budget-advisor` | 通过质量、延迟和预算而不是默认到最大模型来路由 LLM/嵌入工作负载 |
| `documentation-lookup` / `search-first` | 在编码之前验证当前库行为，用于模型服务、特征存储、向量 DB 和评估工具 |
| `git-workflow` / `github-ops` / `opensource-pipeline` | 为审查打包 MLE 更改，具有清晰的范围、生成的工件排除和可重复的测试证据 |
| `strategic-compact` / `dmux-workflows` | 将长 ML 工作拆分为并行轨道：数据契约、评估 harness、服务路径、监控和文档 |

## 十个 MLE 任务模拟

在规划或审查 MLE 工作时使用这些模拟作为覆盖检查。强大的 MLE 工作流应将每个任务减少到明确契约、可重用的 SWE 表面、自动证据和可审查的工件。

| ID | 常见 MLE 任务 | 简化的 ECC 路径 | 所需输出 | 覆盖的管道路径 |
|----|-----------------|----------------------|-----------------|------------------------|
| MLE-01 | 框架模糊的预测、排名、推荐器、分类器、嵌入或预测能力 | `product-capability`、`plan`、`architecture-decision-records`、`mle-workflow` | 迭代简报命名谁关心、决策所有者、成功指标、不可接受的错误、假设、约束和第一个实验 | 产品契约、利益相关者损失、风险、推出 |
| MLE-02 | 定义指标目标、标签、数据来源和错误预算 | `repo-scan`、`database-reviewer`、`database-migrations`、`postgres-patterns`、`clickhouse-io` | 数据和指标契约，具有实体粒度、标签时间、标签置信度、特征时间、时间点连接、分割策略和数据集快照 | 数据契约、指标设计、泄漏、可重现性 |
| MLE-03 | 在添加复杂性之前构建基线模型和评分路径 | `tdd-workflow`、`python-testing`、`python-patterns`、`code-reviewer` | 具有混淆矩阵、校准注释、延迟/成本估算、已知弱点和分数形状及确定性测试的基线评分器 | 基线、评分、测试、服务同等性 |
| MLE-04 | 根据关于什么分离结果的假设生成特征 | `python-patterns`、`pytorch-patterns`、`docker-patterns`、`deployment-patterns` | 特征计划和转换模块，涵盖信号源、缺失值、异常值、相关性、泄漏检查和训练/服务同等性 | 特征管道、泄漏、训练、工件 |
| MLE-05 | 在权衡下调整阈值、配置和模型复杂性 | `eval-harness`、`ai-regression-testing`、`quality-gate`、`test-coverage` | 阈值/配置报告，比较精确度、召回率、F1、AUC、校准、组切片、延迟、成本、复杂性和可接受的错误类别 | 评估、阈值、推广、回归 |
| MLE-06 | 运行错误分析并将错误转化为下一个实验 | `eval-harness`、`ai-regression-testing`、`mle-reviewer`、`silent-failure-hunter` | 错误集群报告，用于误报、漏报、模糊标签、陈旧特征、缺失信号和错误跟踪，包含捕获的教训 | 错误分析、错误跟踪、迭代、回归 |
| MLE-07 | 为批量或在线推理打包模型工件 | `api-design`、`backend-patterns`、`security-review`、`security-scan` | 版本化工件包，具有预处理、配置、依赖约束、schema 验证、安全加载和 PII 安全日志 | 工件、安全、推理契约 |
| MLE-08 | 推出在线服务或带反馈捕获的批量评分 | `api-design`、`backend-patterns`、`e2e-testing`、`browser-qa`、`accessibility` | 预测端点或批量作业，具有响应包络、超时、批处理、后备、模型版本、置信度、反馈日志记录和产品流程测试 | 服务、批量推理、后备、用户工作流 |
| MLE-09 | 通过影子流量、金丝雀、A/B 测试或回滚推出模型 | `canary-watch`、`dashboard-builder`、`verification-loop`、`performance-optimizer` | 推出计划，命名流量分割、仪表板、p95 延迟、成本、质量护栏、回滚工件和回滚触发器 | 部署、金丝雀、回滚 |
| MLE-10 | 在推出后运营、调试和刷新生产模型 | `silent-failure-hunter`、`dashboard-builder`、`mle-reviewer`、`doc-updater`、`github-ops` | 观察账本和刷新计划，具有漂移检查、延迟标签健康、警报所有者、运行手册更新、重新训练标准和 PR 证据 | 监控、事件响应、重新训练 |

## 迭代简报

在接触模型代码之前，将工作压缩为一个可审查的工件。这应该足够短以适合 PR 描述，并足够精确，以便另一个工程师可以挑战权衡。

```text
目标：
谁关心：
决策所有者：
模型改变的用户或系统操作：
成功指标：
护栏指标：
错误预算：
不可接受的错误：
可接受的错误：
假设：
约束：
标签和数据快照：
基线：
候选信号：
阈值或配置计划：
评估切片：
已知风险：
下一个实验：
回滚或后备：
```

此简报是强 SWE 设计说明的 MLE 等价物。它防止团队优化没人信任的指标、添加不解决真正错误模式的特征，或在没有回滚的情况下发布复杂性。

## 决策大脑

当任务模糊、高影响或指标繁重时使用此循环：

1. 从决策开始，而不是模型。命名改变下游行为的操作。
2. 命名谁关心以及为什么。不同的利益相关者为误报、漏报、延迟、计算支出、不透明性或错失机会支付不同的成本。
3. 将模糊性转化为假设。询问什么信号会分离结果，什么证据会反驳它，以及什么简单基准应该难以击败。
4. 在发明定制系统之前研究先前的艺术或附近的已知问题。
5. 用 `(概率, 置信度) x (成本, 严重性, 重要性, 影响)` 对选择进行评分。
6. 考虑对抗行为、激励、选择性披露、分布转移和反馈循环。
7. 优先选择减少最重要错误的最简单更改。简单不是懒惰；它是在保持迭代速度的同时最小化错误的一种方式。
8. 捕获决策、证据、反驳论点和下一个可逆步骤。

## 指标和错误经济学

从失败成本而不是习惯中选择指标：

From aaione/everything-claude-code-zh, MIT.

More from aaione/everything-claude-code-zh