القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/aaione/everything-claude-code-zh --skill mle-workflowيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Kubernetes 工作负载模式、资源管理、RBAC、probes、autoscaling、ConfigMap/Secret 处理，以及面向生产级部署的 kubectl 调试。
完成任何非平凡任务后使用。智能体按 5 个维度自评输出——准确性、完整性、清晰度、可执行性、简洁性——每项都给出具体证据。生成结构化 1-5 评分卡和具体改进建议。
在 competitive-platform-analysis 产出分层竞品集合后使用。按九个加权维度（定位、声音、视觉工艺、offer packaging、证据、enterprise-readiness、thought leadership、定价、客户 strategic tension）为每个竞品评分，使用明确 1–5 rubrics 和 tension-plot。位于 competitive-report-structure 之前。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | mle-workflow |
| description | 生产机器学习工程工作流，用于数据契约、可重现训练、模型评估、部署、监控和回滚。在构建、审查或强化一次性笔记本之外的 ML 系统时使用。 |
| allowed-tools | Read, Write, Edit, Bash, Grep, Glob |
使用此技能将模型工作转化为生产 ML 系统，具有清晰的数据契约、可重复的训练、可测量的质量门槛、可部署的工件和操作监控。
仅使用适合面前系统的路径。此技能对排名、搜索、推荐、分类器、预测、嵌入、LLM 工作流、异常检测和批量分析有用，但不应强制将一种架构用于所有这些。
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：服务、机密、容器和生产强化不要将 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 利用率以及每次预测或重新训练的成本 |
在规划或审查 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、、 |
在接触模型代码之前，将工作压缩为一个可审查的工件。这应该足够短以适合 PR 描述，并足够精确，以便另一个工程师可以挑战权衡。
目标：
谁关心：
决策所有者：
模型改变的用户或系统操作：
成功指标：
护栏指标：
错误预算：
不可接受的错误：
可接受的错误：
假设：
约束：
标签和数据快照：
基线：
候选信号：
阈值或配置计划：
评估切片：
已知风险：
下一个实验：
回滚或后备：
此简报是强 SWE 设计说明的 MLE 等价物。它防止团队优化没人信任的指标、添加不解决真正错误模式的特征，或在没有回滚的情况下发布复杂性。
当任务模糊、高影响或指标繁重时使用此循环：
(概率, 置信度) x (成本, 严重性, 重要性, 影响) 对选择进行评分。从失败成本而不是习惯中选择指标：
每个指标选择都应陈述它使哪个错误更便宜，使哪个错误更有可能，以及谁吸收该成本。
特征应来自分离理论：
在错误分析显示基线因额外信号或容量可以合理修复的原因失败之前，不要增加模型复杂性。
在每个基线、训练运行、阈值更改或配置更改后：
最强的 MLE 循环不是训练 -> 指标 -> 发布。它是错误 -> 聚类 -> 假设 -> 实验 -> 证据 -> 更简单的系统。
在代码、PR、实验报告或运行手册旁边保留紧凑的决策和证据跟踪：
迭代：
更改：
为什么这很重要：
指标移动：
切片移动：
误报：
漏报：
意外错误：
决策：
接受的权衡：
捕获的教训：
添加的回归：
创建的债务：
下一次迭代：
使用账本使模型工作累积。目标是让每次迭代使下一个决策更容易，而不仅仅是产生另一个工件。
在编写模型代码之前捕获产品级契约：
不要接受"改进模型"作为要求。将模型与可观察的产品行为和可测量的接受门槛联系起来。
每个 ML 任务都需要明确的数据契约：
首先防范泄漏。如果特征在预测时间不可用或使用未来信息连接，删除它或将其移动到仅分析路径。
训练代码应可由另一个工程师运行，无需隐藏的笔记本状态：
优先使用不可变值和纯转换函数。避免在特征生成期间变异共享数据帧或全局配置。
import hashlib
from dataclasses import dataclass
from pathlib import Path
@dataclass(frozen=True)
class TrainingConfig:
dataset_uri: str
model_dir: Path
seed: int
learning_rate: float
batch_size: int
def artifact_name(config: TrainingConfig, code_sha: str) -> str:
config_key = f"{config.dataset_uri}:{config.seed}:{config.learning_rate}:{config.batch_size}"
config_hash = hashlib.sha256(config_key.encode("utf-8")).hexdigest()[:12]
return f"{code_sha[:12]}-{config_hash}"
应在训练完成前声明推广标准：
PROMOTION_GATES = {
"auc": ("min", 0.82),
"calibration_error": ("max", 0.04),
"p95_latency_ms": ("max", 80),
}
def assert_promotion_ready(metrics: dict[str, float]) -> None:
missing = sorted(name for name in PROMOTION_GATES if name not in metrics)
if missing:
raise ValueError(f"模型推广指标缺少所需门槛: {missing}")
failures = {
name: value
for name in (direction, threshold) in PROMOTION_GATES.items()
for value in [metrics[name]]
if (direction == "min" and value < threshold)
or (direction == "max" and value > threshold)
}
if failures:
raise ValueError(f"模型未通过推广门槛: {failures}")
将离线指标用作门槛，而非保证。当模型改变产品行为时，在完全推出之前规划影子评估、金丝雀推出或 A/B 测试。
ML 工件仅在服务契约可测试时才可用于生产：
永远不要让仅训练特征代码与服务特征代码分歧，而没有证明同等性的测试。
模型监控需要系统和质量信号：
每个部署都应有回滚计划，命名先前工件、配置、数据依赖和流量切换机制。
使用此技能时，返回具体工件：数据契约、推广门槛、管道步骤、测试计划、部署计划或审查发现。调用阻止生产准备的未知数，而不是用假设填充它们。
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、服务路径、监控和文档 |
browser-qaaccessibility| 预测端点或批量作业，具有响应包络、超时、批处理、后备、模型版本、置信度、反馈日志记录和产品流程测试 |
| 服务、批量推理、后备、用户工作流 |
| 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 证据 | 监控、事件响应、重新训练 |