摩尔机到米利机的转换 (第10集)

前置知识： 米利机和摩尔机, 米利机和摩尔机的区别

在构建现代计算系统时，无论是处理底层硬件逻辑还是设计高阶的业务状态机，理解自动机理论都是至关重要的。在2026年的今天，虽然我们拥有了强大的AI辅助工具，但深入理解 摩尔机 到 米利机 的转换逻辑，依然是我们编写高性能、低延迟系统的基础。

在这篇文章中，我们将深入探讨如何将摩尔机转换为米利机，并结合现代AI辅助开发工作流（如 Cursor 或 GitHub Copilot），看看我们如何在实际工程中应用这一经典理论。

经典理论回顾：模 3 计数器

首先，让我们回顾一下 GeeksforGeeks 上的经典案例。上述摩尔机接受二进制数 {0, 1} 作为输入，并产生模 ‘3‘ 的余数作为输出。也就是说，当输入的二进制数转换为十进制后除以 3 时，机器会输出它的余数。

摩尔机的状态转换图：

!image

现在我们需要将上面的摩尔机状态转换图转换为等效的米利机状态转换图。让我们一步步来拆解这个过程，就像我们在进行代码审查一样严谨。

步骤-1：构建状态转换表

首先，我们需要根据上述摩尔机构建状态转换表。这一步类似于我们在编写代码前定义接口和数据结构。

!image

在上述转换表中，第一列列出了状态 ‘X‘、‘Y‘ 和 ‘Z‘。当输入为 ‘0‘ 时，它们分别转换到 ‘X‘、‘Z‘ 和 ‘Y‘ 状态（列在第二列）；当输入为 ‘1‘ 时，它们分别转换到 ‘Y‘、‘X‘ 和 ‘Z‘ 状态（列在第三列）。在第四列 Δ 下，是第一列状态对应的输出。在表中，箭头 (→) 表示初始状态。

步骤-2：算法转换核心

这一步是转换的核心。让我们思考一下摩尔机和米利机的根本区别：摩尔机的输出仅取决于当前状态，而米利机的输出取决于当前状态和当前输入。

利用上述摩尔机的转换表，我们可以构建米利机的转换表。逻辑非常简单：将当前状态的输出“提前”到通往下一状态的转换边上。

下面的转换表是借助上面的表及其条目形成的，只需使用第一列状态的相应输出，并将它们相应地放置在第二列和第三列中即可。

!image

在上表中，第一列的状态如 ‘X‘，在得到 ‘0‘ 作为输入时，它会转到状态 ‘X‘ 并给出 ‘0‘ 作为输出；在得到 ‘1‘ 作为输入时，它会转到状态 ‘Y‘ 并给出 ‘1‘ 作为输出。第一列中的其余状态以此类推。在表中，箭头 (→) 表示初始状态。

步骤-3：绘制米利机状态图

最后，我们可以借助上面的转换表，绘制出米利机的状态转换图。所需的图表如下所示：

!image

上述米利机接受二进制数 {0, 1} 作为输入，并产生模 ‘3‘ 的余数作为输出。即，当输入的二进制数转换为十进制后除以 3 时，它会输出其余数。

注意： 在从摩尔机转换为米利机时，两者的状态数量保持不变；但在米利机转换为摩尔机的情况下，状态数量可能会发生变化（因为一个状态的不同输出可能需要被拆分）。

—

现代工程实践：从图表到生产级代码

仅仅停留在图表层面是不够的。在 2026 年的软件开发中，我们经常需要将这种状态机逻辑嵌入到高性能的后端服务或前端交互逻辑中。让我们看看如何用现代 Python 实现这一转换。

在我们最近的一个项目中，我们需要实现一个协议解析器，这与模 3 计数器的逻辑非常相似。我们倾向于使用 米利机，因为它能减少不必要的状态开销，并且对输入流的响应更具实时性。

#### 生产级 Python 实现示例

from enum import Enum

class State(Enum):
    X = 0
    Y = 1
    Z = 2

class Mod3MealyMachine:
    """
    2026 风格的类实现：使用类型注解、文档字符串和清晰的映射结构。
    这种结构便于 AI 辅助工具理解并生成优化建议。
    """
    def __init__(self):
        # 初始状态
        self.current_state = State.X
        
        # 定义转换表: (NextState, Output)
        # 这是米利机的核心：输出依赖于输入和当前状态
        self.transition_map = {
            State.X: {0: (State.X, 0), 1: (State.Y, 1)},
            State.Y: {0: (State.Z, 1), 1: (State.X, 0)},
            State.Z: {0: (State.Y, 0), 1: (State.Z, 1)}
        }

    def process_input(self, input_stream: list[int]) -> list[int]:
        """
        处理输入流并返回输出流。
        这种流式处理是边缘计算和实时系统的常见模式。
        """
        output_stream = []
        for bit in input_stream:
            if bit not in [0, 1]:
                raise ValueError(f"Invalid input bit: {bit}. Only 0 or 1 allowed.")
            
            # 获取下一状态和当前输出
            next_state, output = self.transition_map[self.current_state][bit]
            output_stream.append(output)
            
            # 状态更新
            self.current_state = next_state
            
        return output_stream

# 实际运行示例
if __name__ == "__main__":
    machine = Mod3MealyMachine()
    # 输入二进制 ‘110‘ (十进制 6) -> 6 % 3 = 0
    # 米利机输出逻辑：流式输出余数
    inputs = [1, 1, 0] 
    outputs = machine.process_input(inputs)
    print(f"Input: {inputs}")
    print(f"Mealy Output: {outputs}") 
    # 分析: 
    # 1 -> 余数 1 (状态 X->Y)
    # 1 -> 余数 0 (状态 Y->X, 即 3%3=0)
    # 0 -> 余数 0 (状态 X->X)

为什么我们在 2026 年依然关注这个？

你可能会问，既然 AI 可以写代码，为什么还要手动研究摩尔机和米利机的区别？

• 延迟敏感型应用：在 FPGA 设计或高频交易系统中，米利机通常比摩尔机少一个时钟周期的延迟（因为输出直接依赖输入，而不需要等待状态寄存器更新）。这在微秒级的竞争中是决定性的。
• 状态爆炸：在复杂的业务流程中（如订单状态机），使用米利机模型可以显著减少状态数量。例如，处理“支付中”状态时，如果输出（如 API 响应）依赖于具体的支付渠道（输入），摩尔机可能需要为每个渠道创建一个独立的“支付中”状态，而米利机只需一个状态。

AI 辅助开发：从 Vibe Coding 到严谨验证

虽然我们提倡 Vibe Coding（氛围编程）——即利用 LLM 快速生成原型——但在处理状态机逻辑时，我们必须保持警惕。

常见陷阱与 AI 调试技巧：

在让 AI（如 Cursor 或 Copilot）生成状态机代码时，你可能会遇到以下问题：

• 竞争条件：在并发系统中，米利机的输出依赖当前输入，如果状态更新不是原子的，可能会导致不可预测的行为。
• 状态不一致：AI 生成的代码有时会混淆“当前状态的输出”（摩尔）和“转换的输出”（米利）。

我们的建议：

在使用 AI 生成状态机逻辑后，务必编写基于属性的测试（Property-Based Testing）。不要只测试单个用例，而是要验证状态机的不变量。

#### 边界情况与容灾处理

在真实的生产环境中，输入总是不可信的。让我们扩展上面的代码，加入容灾逻辑和可观测性，这是现代云原生应用的标准配置。

import logging

class RobustMod3MealyMachine(Mod3MealyMachine):
    def __init__(self):
        super().__init__()
        # 配置日志记录，这对于在分布式环境中追踪状态转换至关重要
        self.logger = logging.getLogger(__name__)
        logging.basicConfig(level=logging.INFO)

    def process_input_safe(self, input_stream: list[int]) -> list[int]:
        """
        带有错误恢复和监控的安全处理版本。
        这模拟了现代 Serverless 函数中的健壮性处理。
        """
        output_stream = []
        for i, bit in enumerate(input_stream):
            try:
                # 检查输入有效性
                if bit not in self.transition_map[self.current_state]:
                    self.logger.warning(f"Invalid input ‘{bit}‘ at index {i}. Resetting to initial state.")
                    self.current_state = State.X # 灾难恢复机制
                    output_stream.append(-1) # 错误码
                    continue

                next_state, output = self.transition_map[self.current_state][bit]
                
                # 模拟可观测性：记录每一次状态跳转
                self.logger.info(f"Transition: {self.current_state} --[{bit}/{output}]--> {next_state}")
                
                output_stream.append(output)
                self.current_state = next_state
            except Exception as e:
                self.logger.error(f"Critical error processing bit {i}: {e}")
                # 根据业务需求，可以选择重置状态或抛出异常
                self.current_state = State.X
                raise
        return output_stream

总结

从理论上看，摩尔机到米利机的转换非常直观：将状态节点上的输出移到转换边（Transition Edges）上。但在工程实践中，这意味着我们选择了一种更紧凑、响应更快但可能更难调试的模型。

随着 2026 年开发范式的演进，虽然 AI 承担了更多的编码工作，但作为架构师和开发者，我们需要深刻理解这些底层逻辑，以便正确地指导 AI，并设计出既符合业务需求又具备高性能的系统。当你下次在设计工作流引擎或游戏 AI 逻辑时，不妨思考一下：我是在构建一个摩尔机，还是一个米利机？

这不仅关乎数学，更关乎系统的响应性和复杂度管理。