ML Adoption Playbook 是一套自适应方法论，供 AI 智能体与软件工程师在既有软件工程项目中实现机器学习模型。它的定位是衔接传统软件工程与 MLOps，规范机器学习应如何被调研、解耦、训练和集成。
何时启用 当用户提出在已有代码库中“加入机器学习”或“加入算法”时；在规划把新模型（如推荐、分类、预测）集成进非机器学习应用时；需要为智能体编排一个自适应地构建、训练和部署机器学习组件的工作流时，可使用该技能。
第一阶段：问题界定与可行性 在编写模型代码之前，先确立“为什么”和“怎么做”。包括启发式检查：询问用户是否用简单启发式（如正则表达式、基于规则的排序）就能更快解决问题，如果可以则先从这里开始；指标定义：明确机器学习模型试图改善的业务指标（如点击率、降低延迟）；错误预算：定义“坏”预测是什么样，以及系统应如何处理。
第二阶段：数据就绪 没有干净、可访问的数据，机器学习毫无用处。需要审计数据来源：识别训练数据存放位置，是实时数据库、静态 CSV 还是 API；数据契约：为输入数据建立 schema，明确需要哪些特征、某个特征缺失时如何处理；防泄漏：确保用户提出的数据划分不会意外把未来信息泄漏进训练集（例如时间序列数据需按时间顺序划分）。
第三阶段：架构集成与解耦 不要把模型推理与核心业务逻辑紧密耦合。建议 API 边界：将模型放在 API 端点（例如使用 fastapi-patterns 或 django-patterns）或专用服务类之后；回退机制：设计默认状态，若模型响应过慢或抛错，系统必须优雅回退到硬编码规则；特性开关：把新的模型推理调用包在特性开关中，以便安全地发布或回滚。
第四阶段：模型实现与训练 围绕可复现性与迭代来组织代码。从简单开始：先构建基线模型（例如简单的 scikit-learn 逻辑回归或最简 PyTorch 线性层）；可复现性：应用 pytorch-patterns 或类似最佳实践——固定随机种子、让代码与设备无关、明确记录张量/数组形状；自动化证据：要求为数据转换和推理 schema 编写测试，不接受没有评估脚本将其与基线对比的模型。
第五阶段：交接给 MLOps 基线模型集成后，将重点转向持续运营。参考 mle-workflow：引导用户设置实验跟踪、模型注册表和漂移检测；CI/CD：把模型评估步骤加入现有 CI 流水线，确保后续提交不会降低模型性能。
迭代式智能体工作流 智能体依据该手册协助用户时应：在提出架构方案前先通过澄清问题完成第一阶段；在第二阶段起草数据契约供用户确认；在编写训练循环前，先在第三阶段写出解耦接口（API/服务）；在第四阶段交付一个可复现的脚本，用于训练模型并保存产物。