用途
mw-mr-mf 是一套系统化的迭代开发工作流，灵感来自 Jack Harrington（jherr）以及经典的软件开发原则。它用于指导软件功能、组件或系统的构建过程，核心思想是把开发拆分为三个不同阶段，每个阶段有各自的优先级和成功标准，避免过早进入下一阶段而引发问题。
主要能力
工作流围绕三个阶段展开：
第一阶段：Make it work（先能用） 目标是尽快做出一个能端到端演示功能可用的最小方案。优先事项包括：尽快得到可运行的东西、聚焦主流程（happy path）、采用直接的做法、必要时硬编码、跳过非关键的错误处理、暂时接受代码重复。若结合 TDD，则先为核心主流程写测试并让其通过，把边界情况测试推迟到第二阶段，使用红-绿循环（失败测试 → 最小代码 → 通过测试）。成功标准是功能展示出预期行为、核心用例可用、能向他人演示并让人理解其作用。常见错误包括：立即处理所有边界情况、在理解问题前就构建抽象、在验证方案可行前就优化、添加超出核心需求的功能。
第二阶段：Make it right（再正确） 目标是把可运行的代码重构为可维护、结构良好的软件。优先事项包括：消除重复（DRY）、补充错误处理与边界情况、抽取可复用函数与组件、改进命名与代码清晰度、增加类型安全（TypeScript 类型、Python 类型提示）、为关键路径编写测试、为非显而易见的行为添加文档。若结合 TDD，此时补充边界测试、错误与边界条件测试，借助测试安全重构，达到重要行为的良好覆盖率。成功标准是代码可读可维护、常见错误被优雅处理、组件职责单一清晰、测试覆盖主要功能、其他开发者能理解并修改代码。常见错误包括：在模式尚未显现前过度抽象、过早优化、追求一次到位地完美覆盖、添加“以防万一”的推测性功能。
第三阶段：Make it fast（后快速） 目标是在实际测量出瓶颈的基础上优化性能。进入条件包括：性能测试揭示真实问题、用户反馈生产环境变慢、性能剖析发现明确瓶颈、有明确的性能要求需要满足。优先事项包括：先剖析找出真实瓶颈、优先优化最慢的部分（80/20 法则）、测量每项优化的影响、考虑缓存策略、评估算法改进、查找不必要的重渲染或重复计算。若结合 TDD，则添加性能测试记录基准，确保优化后既有测试仍通过，用测试验证优化不改变行为。成功标准是实测性能满足要求、优化针对真实瓶颈、性能改进有记录、代码仍可维护。常见错误包括：未测量就优化、为微小收益让代码变复杂、优化并非瓶颈的部分、不必要地牺牲可维护性。
使用方式
工作流给出了若干操作指引：
- 开始新功能时：明确核心需求 → 勾勒最简单可行的方案 → 执行第一阶段 → 演示/验证可用 → 进入第二阶段。
- 出现问题时：在当前阶段内修复，不要不必要地退回“先能用”模式，保持已达到的质量水平。
- 判断何时推进：第一阶段 → 第二阶段，当核心功能可用时；第二阶段 → 第三阶段，当既有性能要求、又有测量显示存在问题时；大多数代码应长期停留在第二阶段——干净可用的代码不需要优化。
- 危险信号：在第一阶段写复杂抽象、在第一阶段讨论性能、完全跳过第二阶段、未测量就进入第三阶段。
与 TDD 的整合方式：TDD 回答“怎么做”（先写测试再实现），本工作流回答“何时做”（何时重构、何时优化）。阶段映射为：第一阶段用红-绿循环覆盖主流程（最少测试、最少代码）；第二阶段补充边界测试，在测试安全网下重构；第三阶段用性能测试验证优化不破坏行为。若全程使用 TDD，则在所有阶段保持红-绿-重构循环，让测试失败引导实现，把重构步骤作为进入第二阶段的信号，仅在第三阶段添加性能断言。
适用场景
适用于构建软件功能、组件或系统，尤其适合希望快速迭代、以反馈驱动改进、避免过早优化的开发场景。文档也给出了不适用的情况：构建安全关键系统（正确性优先）、一开始就有严格性能要求、对现有代码做小修复、原型探索（可停留在第一阶段）、以及“正确”方案从一开始就显而易见的情况。
限制
资料未提供该工作流的具体工具形态、安装方式、平台支持或收费信息，暂未提供。