机器学习工程工作流
使用此技能，将模型工作转化为一个具有明确数据契约、可重复训练、可测量质量门禁、可部署制品和可操作监控的生产级ML系统。
何时激活
- 规划或审查一个生产ML特性、模型刷新、排名系统、推荐器、分类器、嵌入工作流或预测管线时
- 将笔记本代码转换为可重用的训练、评估、批量推理或在线推理管线时
- 设计模型升级标准、离线/在线评估、实验追踪或回滚路径时
- 调试由数据漂移、标签泄漏、过时特征、制品不匹配或不一致的训练和服务逻辑引起的故障时
- 添加模型监控、金丝雀发布、影子流量或部署后质量检查时
范围校准
仅使用适合您当前系统的部分。该技能适用于排名、搜索、推荐、分类器、预测、嵌入、大语言模型工作流、异常检测和批量分析，但它不应迫使所有系统都采用一种架构。
- 不要假设每个模型都有监督标签、在线服务、特征存储、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表面
不要将机器学习工程与软件工程分开对待。大多数ECC SWE工作流直接适用于ML系统，而且通常具有更严格的故障模式：
推荐的 minimal --with capability:machine-learning 安装使得核心代理表面与该技能同时可用。对于仅技能或代理受限的环境，在目标支持代理的情况下，将 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 | 在实现之前测试特征转换、拆分逻辑、指标计算、制品加载和推理模式 |
code-reviewer / mle-reviewer | 审查代码质量以及ML特有的泄漏、可复现性、升级和监控风险 |
build-fix / pr-test-analyzer | 诊断断裂的CI、不稳定的评估、缺失的fixture以及环境特定的模型或依赖失败 |
quality-gate / test-coverage | 要求对转换、指标、推理契约、升级门禁和回滚行为提供自动化证据 |
eval-harness / verification-loop | 将离线指标、切片检查、延迟预算和回滚演练转化为可重复的门禁 |
ai-regression-testing | 将每个生产bug保留为回归测试：缺失特征、过时标签、糟糕制品、模式漂移或服务不匹配 |
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 | 在编码前验证当前库在模型服务、特征存储、向量数据库和评估工具方面的行为 |
git-workflow / github-ops / opensource-pipeline | 将MLE变更打包以供审查，包含清晰的范围、排除生成的制品以及可复现的测试证据 |
strategic-compact / dmux-workflows | 将较长的ML工作拆分为并行轨道：数据契约、评估工具、服务路径、监控和文档 |
十个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 | 错误聚类报告：假阳性、假阴性、模糊标签、过时特征、缺失信号和包含经验教训的bug追踪 | 错误分析、bug追踪、迭代、回归 |
| MLE-07 | 打包模型制品用于批量或在线推理 | api-design, backend-patterns, security-review, security-scan | 带版本号的制品包，包含预处理、配置、依赖约束、模式验证、安全加载和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 | 观察账本和刷新计划，包含漂移检查、延迟标签健康、告警所有者、runbook更新、再训练标准和PR证据 | 监控、事件响应、再训练 |
迭代契约
在接触模型代码之前，将工作压缩成一个可审查的制品。它应该足够简短，能放入PR描述，并且足够精确，让其他工程师能够质疑其中的权衡。
目标：
关注者：
决策负责人：
模型改变的用户或系统行为：
成功指标：
护栏指标：
错误预算：
不可接受的错误：
可接受的错误：
假设：
约束：
标签和数据快照：
基线：
候选信号：
阈值或配置计划：
评估切片：
已知风险：
下一次实验：
回退或回滚：
这个契约是MLE中强力SWE设计说明的等价物。它让团队避免优化一个没有人信任的指标，避免添加不能解决实际错误模式的特征，或是在没有回滚的情况下发布复杂性。
决策脑回路
当任务含糊不清、影响重大或指标繁重时，使用这个循环：
- 从决策开始，而不是模型。命名改变下游行为的动作。
- 命名谁关心以及为什么。不同的利益相关者为假阳性、假阴性、延迟、计算开销、不透明性或错失的机会付出不同的成本。
- 将模糊性转化为假设。询问什么信号能区分结果，什么证据能反驳它，以及什么简单的基线应该难以击败。
- 在发明定制系统之前，研究现有成果或邻近的已知问题。
- 用
(概率， 置信度) x (成本， 严重性， 重要性， 影响)对选择进行评分。 - 考虑对抗行为、激励、选择性披露、分布偏移和反馈循环。
- 首选能减少最重要错误的最简单变更。简单不是懒惰；它是减少重大失误同时保持迭代速度的一种方式。
- 捕捉决策、证据、反驳论点和下一步可逆步骤。
指标与错误经济学
根据失败成本选择指标，而非习惯：
- 尽早使用混淆矩阵，以便团队讨论具体的假阳性和假阴性，而不是抽象准确率。
- 当不正确阳性决策的成本占主导地位时，偏好精确率。
- 当漏检阳性的成本占主导地位时，偏好召回率。
- 仅当精确率/召回率权衡真正平衡且可解释时，才使用F1。
- 当排序质量比单一阈值更重要时，使用AUC或排序指标。
- 将延迟、吞吐量、内存和成本作为一等指标进行追踪，因为它们决定了可行的模型复杂度。
- 在庆祝离线提升之前，与基线和当前生产模型进行比较。
- 将现实世界的反馈信号视为带有偏差、滞后和覆盖缺口的延迟标签；未经分析，不要将其视为事实真相。
每个指标选择都应说明它降低了哪种错误的成本，使哪种错误更可能发生，以及谁承担该成本。
数据与特征假设
特征应源于一种分离理论：
- 文本、分类字段、数值历史、图关系、新近性、频率和聚合值都是候选信号家族，而非自动特征。
- 对于每个特征家族，说明它为什么应该能分离结果，以及它如何可能泄漏未来信息。
- 对于嘈杂标签，考虑裁决、标签置信度、软目标或置信度加权。
- 对于类别不平衡，比较加权损失、重采样、阈值移动和校准的决策规则。
- 对于缺失值，决定缺失是否具有信息量、是否可插补，或者是否应弃权。
- 对于异常值，决定是裁剪、分桶、调查还是将其保留为罕见但重要的信号。
- 对于相关特征，检查它们是冗余的、不稳定的，还是作为不可用未来状态的代理。
在错误分析表明基线失败于一个额外信号或容量合理能够修复的原因之前，不要增加模型复杂度。
错误分析循环
在每次基线运行、训练运行、阈值变更或配置变更之后：
- 将错误分解为假阳性、假阴性、弃权、低置信度案例和系统故障。
- 按共同特征对错误进行聚类：语言、实体类型、来源、时间、地理位置、设备、稀疏性、新近性、特征新鲜度、标签来源或模型版本。
- 将模型错误与数据错误分开