从全自动洗衣机看程序员的自我修养：状态机、技术债与自动化

说个真事儿。我家的洗衣机买了六七年，最近老是在脱水中途“哐哐”响，我掀开顶盖想看看咋回事，结果发现那块不过巴掌大的控制板上，密密麻麻排着电容、电阻、继电器，主控芯片上的丝印小到要拿放大镜才看得清。就这么一块板子上的程序，撑死了几KB，却要管进水、洗涤、漂洗、排水、脱水、门锁保护、防溢出这一大堆状态，还得保证一个完全不懂控制原理的人摁一下启动键就能把脏衣服洗成能穿的状态。

那一刻我突然意识到，全自动洗衣机大概是全世界普及率最高、但最不引人注意的“程序自动执行装置”。它每天都在跑程序，却极少有人把这玩意儿和程序员的日常联系起来。而“全自动洗衣机程序员的自我修养”这个标题，恰恰可以有两种读法：一种是为洗衣机写固件的嵌入式程序员，另一种是把自己活成“全自动洗衣机”式的应用开发程序员。顺着这条线往下琢磨，我发现这两个身份背后修的是同一套东西——状态管理、感知能力、容错设计、定期清理、对结果负责。今天这篇文章就想把这套东西拆开聊透，不管你是写固件的、写后端的还是刚入行的小白，应该都能从一台白色家电身上，重新审视自己的工作方式。

1. 洗衣机里的代码，比你想象的更“程序”

说起洗衣机的程序，很多人的第一反应是面板上那个旋钮或者一排触摸按键——标准洗、快速洗、轻柔洗、单脱水。你选一个模式，它就按部就班地跑一遍。但多数人不知道的是，几十年前的第一批“全自动洗衣机”，程序是靠机械定时器实现的，一个微型电机带动一组凸轮，按角度触发开关，进水阀开多久、电机转多久、排水泵什么时候启动，全看齿轮和触点的硬接线。那时候真没有一行代码，核桃那么大一个定时器就是全部“软件”。

后来微控制器普及，机械定时器换成了主控芯片，洗衣机的“程序”才真正变成代码里的事情。你现在拆开一台主流的波轮或滚筒洗衣机，里面跑的“程序”本质上是一张参数表加一段状态转移逻辑。所谓“模式”，就是对几个核心参数做预设：进水时长或目标水位、电机正反转的转停比、漂洗次数、单次脱水转速、中间有没有浸泡等待。标准洗和轻柔洗的区别，很多时候就是转4秒停2秒还是转2秒停4秒的区别；快速洗和常规洗之间，往往是洗涤时间短一截、漂洗次数少一次。这让程序员很容易产生共鸣——这不就是配置项嘛。

参数表的价值在于，它让一台机器用极其有限的计算资源覆盖了千变万化的使用场景。我见过一块洗衣机的控制板，RAM以字节算，Flash以KB算，连操作系统都没有，跑的就是裸机循环加中断，但代码里把进水、排水、电机驱动、安全保护全部拆成了清晰的功能模块。反过来看我们写的业务系统，动不动几百兆依赖、几十个微服务，却有几个能拍着胸脯说自己的流程管理得比这台洗衣机还清楚？

这里就引出了“洗衣机程序员”的第一条自我修养：把业务流程拆成“时序”和“参数”，而不是把过程写死成一大串if。我早年间写业务代码，最大的毛病就是喜欢一层一层把逻辑堆在同一个函数里，一个方法四五百行，从入口到出口每一步都写死。后来接手过一个设备控制类的项目，A同事把自己的处理逻辑做成了一个配置驱动的流程引擎，新需求来了只改参数表和配置，我改一行代码就得测半天。那次对比给我的教训很深：好程序是数据驱动、逻辑通用的，坏程序是逻辑里藏着无数硬编码的“这个项目特殊情况”。

不妨列个表，看看一台洗衣机的核心“程序模式”到底在调什么参数，这能帮助我们把“程序”这件事看清楚：

看到没有，所谓“程序”，不是密密麻麻的步骤编号，而是一组组可调节的参数配上时序控制。你的业务代码也一样：如果把下单、支付、发货的流程拆成可配置的环节和规则参数，而不是一梭子if塞到底，后续的维护成本能降一大截。这就是我从一块洗衣机的控制板上学到的最朴素的一课。

2. 一门“全自动”的功课：把流程变成状态机

洗衣机最让我佩服的一点，是它的状态管理极其干净利落。别看它外表是个只会嗡嗡转的大白盒子，内部固件其实是一个教科书级别的状态机：待机、进水、洗涤、排水、漂洗、脱水、结束，一个主流程走下来，每个状态之间还有水位、门锁、电机转速这些条件做转移判断。老式的机械定时器是“时间到就走下一步”，而现代微电脑洗衣机是“条件满足才允许转移”。比如进水环节，它会不停地读水位传感器的信号，水位到了才关进水阀；洗涤结束后，必须排水排到一定水位以下才允许进入脱水，否则电机带着一桶水硬转，等着烧电机吧。

我早期写代码的时候完全没这个意识。一个订单流程能写成七八层嵌套的if else，哪有什么状态机，全是一环套一环的“走迷宫”。结果就是线上偶发问题根本没办法定位：你说这个单子现在到底在哪个环节？我瞪着眼睛看了半天日志，也只能回答“大概走到中途挂了吧”。后来我重写那套逻辑，做了个简单的状态字段加状态转移表，每一次流转都留痕，每个非法转移都记日志，从此再也不用靠猜。

从洗衣机固件和订单流程这两件事里，我总结出状态机设计的三个关键点，算不上什么高深理论，但很实用：

• 每个状态必须定义“超时”和“异常分支”。洗衣机进水不可能永远进下去，超过规定时间水位还没到，必须报警停机；订单也不可能永远停在支付中，超过十五分钟未支付就该自动关单。
• 状态转移要收敛，不能有“游离状态”。所谓游离状态，就是代码跑了半天，你根本不知道它算在哪个步骤里。洗衣机的状态字段就那么几个，枚举清清楚楚，绝不搞字符串乱飘。
• 异常要能回到安全态。洗衣机一旦检测到漏水或者电机过流，不会继续往下硬跑，而是立刻排水、断电、亮故障码，回到一个用户可以干预的安全状态。我们的系统也该这样，下游超时就熔断，数据不一致就回滚，而不是硬着头皮往错误里钻。

我见过不少同事写的代码，流程越复杂越不敢动，因为每个状态之间像蜘蛛网一样互相牵连，改一个入口整个逻辑全崩。根源就在于当初没有用状态机模型去理清流转关系，顺手用if就堆上了。照搬洗衣机那套思路以后，我把业务流转的代码量砍掉了将近一半，不是因为代码写得快了，而是因为状态清晰后，大量重复的边界判断根本不再需要。

这里还可以对你日常开发做个提示：状态机的设计产物不一定要写得很玄，一张表就够用。字段列清楚“当前状态、触发事件、下一状态、前置条件、异常处理”，开发时照着表写，测试照着表测，文档也照着表写，比什么都强。洗衣机上的那个“程序选择旋钮”，本质就是一张状态转移表的用户界面。

3. 传感系统：全自动的前提是感知清楚

很多人以为“全自动”就是纯靠程序硬跑：设定好了，闷头把流程走完。但真实的洗衣机一点都不是闷头跑，它靠一堆传感器实时感知自己在干什么。

老式洗衣机用机械式水位开关，一根塑料气管从桶壁伸到底部，水位升高压缩空气，压力到了就触发触点，告诉主控芯片“水够了”；新一点的用电子压力传感器，能读连续数值，主控芯片据此精确定位水位档次。除此之外，很多中高端机型还内置称重传感器，启动前先让桶转两圈，凭负载的转动惯量估算衣服有多少，再决定进水量和洗涤时间——衣服少就少进水，衣服多就把水位抬高一档。个别型号还有浊度传感器，装在排水口，漂洗时实时测水脏不脏，水干净了提前结束漂洗，省水省电。你看，所谓“自动”，背后是多个信号源的持续感知和融合判断。

把这一套搬到程序员语境下，就是“全自动”的前提不是自动化执行，而是感知能力。一个系统如果对自身的运行状态、外部输入的变化、依赖服务的好坏一无所知，那么自动化的流程跑得再顺也只是瞎子走路，迟早出大事。我见过太多翻车的自动化：定时任务半夜跑挂，没人知道，第二天早上用户投诉才去翻日志；告警阈值随便设，一天响两百次，最后大家把告警群一关，真出问题反倒没人响。

感知清楚之后才谈得上决策，这是洗衣机给我的第二个重要启发：模糊控制。所谓“模糊洗”，不是玄学，它就是对感知到的信息做规则化处理——水温低就多洗一会儿，衣服多就把水加满，水脏就再多漂一轮。对照到程序员的日常工作里，我们开发一个功能之前，有没有真的感知清楚需求方要什么？还是拿到一句话就开始写代码？我们上线一个服务之前，有没有感知过它的容量边界和依赖关系？还是一梭子部署完就算拉倒？所谓“全自动程序员的自我修养”，七成功夫应该花在感知层，而不是执行层。

具体到实操，我可以分享一个比较朴素的感知清单，适配大多数业务开发场景：

我最早写代码的时候，总觉得“感知”这步很虚，不如直接把功能做出来来得实在。但随着线上问题见多了，我的观点完全反过来了：好多线上事故其实不是“处理”环节出的问题，而是“感知”环节被跳过了。需求场景没有感知清楚，功能做出来就是个半吊子；依赖链路没有感知清楚，一上线就被别人拖下水；自身的资源水位没有感知清楚，流量一冲就崩。洗衣机之所以能安安稳稳把衣服洗完，不是因为它会“算”，是因为它把“摸清楚情况”这件事做在了前面。

4. 脱水时的抖动，就是上线后的高并发

洗衣机整个流程里最刺激的阶段，绝对是脱水。电机从低速一路爬到每分钟上千转，整桶衣服被离心力压在桶壁上，水从孔洞甩出去。但这里有个致命问题：如果衣服在桶里分布不均匀，一边重一边轻，高速旋转时会产生剧烈的周期性振动，轻则噪音大到邻居敲门，重则整台机器在阳台上跳着走，搞不好还能把水管震脱。

洗衣机解决这个问题的方式很有意思。它不是一上来就冲高速，而是分阶段加速：先低速转几秒，感受一下偏心情况；如果检测到振动超标，不是硬着头皮硬甩，而是停下来，再低速转一下，借离心力把衣服重新分布一遍；如此反复，直到这桶衣服的偏心量在安全阈值内，才敢逐步提升到设定转速。这个过程你细品，和应对线上高并发简直一模一样。流量高峰来之前，你不能直接拿裸奔的系统硬接，你得先做压测，模拟低速、中速、高速几档负载，观察系统在哪个转速区间开始抖。

很多程序员对压测这件事抱着“走过场”的态度，觉得跑一遍压测工具，看看QPS数字没崩就完事。这种心态放到洗衣机上，就等于不看偏心量直接干拉最高转速，短期可能侥幸没事，长期必然翻车。真正的压测目标不是测出“我系统最高能扛多少”，而是测出“在流量升高的过程中，系统什么时候开始抖动、抖动的方式是什么、我怎么在下一次流量上来之前把衣服重新铺匀”——也就是搞清楚系统的重分布机制和降级预案。比如自动扩容策略、熔断阈值、排队削峰方案，这些东西就是洗衣机在低速阶段的那几次“试探性正反转”。

我记忆里特别清楚的一次线上教训，就是某次大促前我做压测，发现数据库连接池在并发超过一定阈值后开始剧烈波动，连接创建和释放频率暴涨，RT像心率不齐一样上蹿下跳。我当时的第一反应是背锅式地把连接池上限调大，结果没用，抖得更厉害。后来冷静下来排查才发现，根本原因是应用层没做连接复用，每次请求都新建连接，把连接池活活打爆。这就好比洗衣机发现桶抖，你的应对不是重新分衣服，而是把电机转速硬往上加，那只会抖得更欢。

再看故障码这套东西。洗衣机的面板上如果出现某个字母开头的故障码，意味着状态机走到了错误分支，固件会在第一时间停掉高危动作，排水、断电、亮码、蜂鸣。这个设计对我们的启发很直白：线上系统出故障时，定位路径也应该像故障码一样清晰。Error级别日志打了没有？调用链路的traceId串起来没有？异常堆栈里的业务上下文带全了吗？很多事故一查就是两小时，不是因为问题有多深，而是因为异常发生的时候，系统就像一台只会嗡嗡转的洗衣机，转不动了也不吭声，等你打开盖子才发现里面一团乱麻。

给个比较直观的对照，看看甩干和高并发治理的思维同源性：

5. 滤网里的毛絮：技术债不会因为自动化而消失

全自动洗衣机有个特别容易被人忽略的环节——维护。再智能的机器，用上几个月，滤网里也会积一层毛絮，洗衣液盒下面会黏一层滑腻的残留物，排水管拐弯的地方会慢慢挂上头发和纤维。你要是不管它，不会立刻出大事，但会出现“衣服越洗越不干净”“洗完有异味”“排水越来越慢”这种慢刀子割肉的毛病。我见过最夸张的一台，用户从来不清滤网，最后排水泵被毛絮堵死，洗完的水根本排不出去，一桶脏水泡了一夜，那酸爽——第二天拆开滤网，掏出来的东西能搓成一个小毛球。

把这个场景原封不动搬到程序员的日常里，它有一个耳熟能详的名字：技术债。代码里那些“先这样，后面再改”的临时补丁、注释掉的大段死代码、两个名字雷同实现却略有出入的Util方法、版本老到上游都停止维护的依赖包，以及“这个接口虽然没人用了但先留着反正不影响”的历史包袱——全部都是滤网里的毛絮和排水管里的头发。它们不会因为你上线了自动化部署、上齐了监控告警就自动消失。自动化只会让流程跑得更快，但快向着烂代码冲刺，早晚翻车。

我给自己定过一个技术债清理清单，按频率分三档，跟洗衣机维护的节奏差不多：

有人会问，技术债清理这种事不产生业务价值，优先级排不上去怎么办？我的回答是：洗衣机的滤网清理也不产生“洗净价值”，但你不清理，洗衣机的洗净能力会实打实地下降。技术债的可怕之处不在于你攒了多少，而在于它让每一次新功能开发的边际成本越来越高。你今天花一小时清理掉一段无人能解释的老逻辑，可能明天就少花三小时去猜它当年为什么要这么写。这个账算得过来。

我做技术债清理的另外一个体会是：不要搞“大扫除式重构”。那种“一鼓作气全部推倒重来”的冲动，就像把洗衣机整个拆了重新安装，风险极高且极度容易翻车。真正稳的做法是把清理工作嵌在日常开发的节奏里，像随手清理门封条上的残留物一样，顺手就做，大块骨头再单独立项。实实在在的收益不是一次性的，而是让代码库保持“可读、可改、可维护”的状态，就像一台定期清滤网的洗衣机，哪怕已经用了六七年，洗出来的衣服依然干干净净。

6. 从“全自动”到“自适应”：程序员的进阶路线图

洗衣机这个行业走到今天，也在不停进化。中高端的机型开始支持智能投放——洗衣液和柔顺剂不用你每次手倒，机器根据衣量和脏污程度自动决定投放多少；有的型号配了多个传感器，能识别不同衣物材质，自动推荐对应的洗涤程序；更有意思的是联网功能，手机App上能看洗涤进度，机器能自己下载固件更新，修复电机控制算法的细节问题。你会发现，这台机器的进化路径非常清晰：从机械定时器的“按时间跑完”，到微电脑的“按状态机跑完”，再到传感器融合的“按实际情况动态调整”，最后到联网学习的“越用越贴合你的习惯”。

这恰恰就是一条程序员自我修养的升级路线。第一层是能跑——代码写得通，功能能上线，这叫“机械定时器阶段”；第二层是自动化——流程清晰，状态可控，出问题有告警有回滚，这叫“微电脑状态机阶段”；第三层是自适应——能感知业务指标和系统边界，根据环境变化主动调节架构和代码策略，这叫“模糊控制阶段”；第四层是持续进化——通过复盘、日志分析、故障演练不断修正自己的“算法”，这才是真正的“联网智能阶段”。大部分人有意识地追求第二层，但懵懵懂懂也能过；真正拉开差距的，是从第二层走向第三层的那一步。

这一步怎么走？我觉得核心是转变身份心态。从“别人让做什么我就做什么”的执行者，变成“我自己搞清楚做什么、为什么做、做到什么程度为止”的负责人。全自动洗衣机不会因为自己叫“全自动”就不管桶里的衣服分布——它照样要感知偏心、照样要重新分布、照样要停下来报警求助。程序员也一样，就算你的工作流程很自动化，CICD全齐、监控告警全覆盖、需求文档写得明明白白，也不代表你可以当甩手掌柜。你要对你写出来的每一段代码产生的实际结果负责，尤其是它出错之后怎样收场。

还有件小事我想多说一句。不管洗衣机多智能，流程跑完之后，最后把衣服从桶里掏出来晾到阳台上的，永远是个人。这台机器不会自己把衣服晾了。这就对应着程序员的终极修养——自动化能帮你省掉大量重复劳动，但理解业务、判断取舍、对最终结果兜底这些事，得你自己来。我认识不少程序员，自动化做得飞起，代码仓库里全是脚本和流水线，但问起“你负责的这个功能到底给用户带来什么价值”，答不上来。这种人就像一台只会自己加洗衣液、自己选程序、自己洗得干干净净，却从来不知道衣服晾到哪儿去的洗衣机——工序全对，意义缺位。

我自己现在做技术复盘，经常套用洗衣机的这套逻辑问自己几个问题：这个流程的状态我有没有全部列清楚？我对当前的系统状态感知够不够敏锐？遇到偏心式的突发负载，我是硬扛还是知道怎么重新分布？滤网里的技术债上一次清理是什么时候？最后一个问题更关键——程序跑完了，衣服晾了吗？这几句话没什么技术含量，但每问一遍，都能把我从“闷头敲代码”的状态里拉回“为结果负责”的轨道上。希望你下次看到家里那台洗衣机嗡嗡转的时候，也能想起自己是一个写程序的，而且可以写得更像一台好洗衣机。