企业官网建设流程全解析

1. 模式切换需求的“第一公敌”：自然语言说不清状态

我先说个真实体验。在接手过的不少项目和方案里，“模式切换”这四个字出现频率极高——无线设备的胖瘦模式切换、驱动软件的语言界面切换、照明系统的情景模式切换、设备的运行/配置模式切换。每次需求方开口都是同一句话：“就加个模式切换嘛，很简单。”但真正动手做的时候，你会发现几乎所有问题都出在“模式切换”这四个字上：切到什么状态、由谁触发、切换瞬间旧状态怎么处理、非法切换怎么办、切换失败回滚到哪。

这些用大白话聊，大家都能聊个大概齐，可一旦要落地实现，就发现每个人都理解得不太一样。项目经理理解的切换是界面上一个按钮，开发理解的切换是一堆if/else，测试理解的切换是十几条用例。语言太含糊，代码太啰嗦，这时候伪代码的价值就出来了——它卡在中间那一层，用近乎结构的语言把切换逻辑定死，谁看了都得承认“对，就是这个意思”。

这篇文章我想专门聊聊一个话题：如何用伪代码把各种模式切换场景描述清楚。不是讲某一种特定语言，而是讲伪代码本身怎么组织、怎么分支、怎么写状态流转、怎么描述边界，再配上几个真实的模式切换案例让你能直接抄。

适合看的人包括：要写设计文档和方案说明的工程师、需要把算法或流程讲清楚的老师/学生、做嵌入式或无线设备维护的现场人员、以及任何被“模式切换”需求折磨过的人。

模式切换的本质，说穿了就是状态转换。而伪代码擅长干的事，恰好就是描述状态转换。它不需要你纠结某一行语法能不能编译，不需要你考虑内存分配，只需要你把“什么条件下做什么事、做完之后变成什么状态”讲明白。

2. 先梳理模式切换的完整边界，再动笔写伪代码

很多人写伪代码上来就写if(条件) mode = 0，写得飞快，一周后回来看不知道自己在写什么。我自己的习惯是：动手前先把模式切换的所有边界条件列清楚，伪代码才写得快。

2.1 一个实用的模式切换分析清单

先说结论，任何模式切换需求，动手前至少要回答下面这些问题：

• 有哪几种模式？每种模式的正式名称和编号是什么？
• 当前模式的“初始状态”是什么？上电/启动之后进入哪个模式？
• 触发切换的事件有哪些？是按键、串口命令、网络指令、还是自动条件？
• 切换过程中，是否需要保存当前模式的现场（比如参数、临时数据）？
• 切换失败怎么办？是保持原模式，还是进入一个错误/降级模式？
• 是否有非法切换？比如从模式A不允许切到模式C，这种请求如何处理？
• 模式切换之后，哪些资源要重新初始化？哪些要关闭？
• 是否允许多个触发源同时发起切换？如何仲裁？

这些问题的答案，直接决定伪代码里的判断条件分支怎么写。你漏掉一项，后面实现的时候就得补一堆补丁。

我见过最典型的翻车现场是这样的：一台设备有“配置模式”和“运行模式”，切换条件写得清清楚楚，但需求里没提“当前模式正在执行关键任务时收到切换指令怎么办”。结果就是调试现场出现设备在写入参数的过程中被切到运行模式，参数写了一半，设备直接跑飞。伪代码里加一行“if 当前处于写参数状态 then 拒绝切换”就能解决的问题，因为没提前梳理，生生变成一次现场事故。

2.2 把状态转换画成一张表再编码

对于模式切换这种多状态场景，我强烈建议先做一张模式转换表，把“源状态”“触发事件”“目标状态”“动作/副作用”填进去，然后照着表来写伪代码。表格可以避免你在伪代码里漏掉某个分支，也方便后面评审。

假设一个简单的设备有三态：待机模式、配置模式、运行模式。合法转换有这些：

把这张表定下来之后，伪代码的骨架基本就出来了。你不需要在写代码的时候拍脑袋想“哦这里还能切一下”，表里没有的转换一律视为非法切换。

3. 伪代码描述状态转换的三种写法，以及各自的适用场合

有了上面的转换表，接下来就是怎么写的问题。伪代码没有统一标准，但描述模式切换，市面上常见的写法大致有这三种：顺序分支型、事件循环型、状态表驱动型。我分别说清楚它们的写法、优缺点，以及什么情况下选哪种。

3.1 顺序分支型：最简单，适合单任务小逻辑

这种写法最接近普通人的思维，就是一层一层if/else嵌套。优点是直白，缺点是模式一多、嵌套深了以后可读性暴跌。

// 顺序分支型模式切换伪代码 当前模式 = 待机模式 收到指令(指令内容) { if 当前模式 == 待机模式 { if 指令内容 == 进入配置 { 加载配置参数() 初始化配置接口() 当前模式 = 配置模式 } else if 指令内容 == 启动运行 { 初始化外设() 当前模式 = 运行模式 } else { 忽略指令() // 待机模式不接受的指令 } } else if 当前模式 == 配置模式 { if 指令内容 == 退出配置 { 保存参数() 关闭配置接口() 当前模式 = 待机模式 } else if 指令内容 == 启动运行 { 加载新配置() 初始化运行环境() 当前模式 = 运行模式 } else if 指令内容 == 设置参数 { 更新配置参数(指令内容) } else { 忽略指令() } } else if 当前模式 == 运行模式 { if 指令内容 == 停止 { 停止任务() 释放资源() 当前模式 = 待机模式 } else if 指令内容 == 进入配置 { 暂停任务() 打开配置接口() 当前模式 = 配置模式 } else { // 运行模式下的业务指令处理 执行业务逻辑(指令内容) } } else { 报错("未知模式") } }

这段伪代码一看就懂，对3~4种模式、每次事件只做一件事的小系统完全够用。但你要是系统里有8种模式、每个模式能响应10种事件，这段代码就没法看了——嵌套层级会变得极深，加一种模式要动五六处地方。

3.2 事件循环型：适合持续运行、事件驱动的场景

很多设备不是“收到指令才动”，而是“永远在跑循环，轮询各种事件”。这种场景下，伪代码的主结构是一个while循环，模式切换在循环内部处理。它的优势是贴合实时系统的真实运行方式，缺点是写起来容易把业务逻辑和切换逻辑混在一层。

// 事件循环型模式切换伪代码 当前模式 = 待机模式 while (系统运行中) { event = 等待或轮询事件() // 按键、串口、定时器、网络消息都算事件 切换与处理分析(event) { if event == 按键短按 { if 当前模式 == 运行模式 { 暂停任务() 打开配置接口() 当前模式 = 配置模式 } else if 当前模式 == 配置模式 { 保存参数() 关闭配置接口() 当前模式 = 运行模式 } } if event == 串口指令 { 解析串口数据(指令) if 当前模式 == 配置模式 { 按指令处理配置事务() } else { 回复("当前模式不允许此操作") } } // 其他事件处理 } 模式特有业务处理() { if 当前模式 == 运行模式 { 执行运行任务分钟片() } else if 当前模式 == 配置模式 { 刷新配置界面状态() } } }

这种写法有一个隐藏陷阱：模式切换判断分散在事件处理的各个角落里，一旦你忘了在某个事件分支里判断当前模式，就可能出现“配置模式下还执行着运行动作”的问题。我的习惯是：所有模式判断尽可能集中在一个处理函数里，不要在多个地方重复判断模式，否则后面排查模式相关bug会非常痛苦。

3.3 状态表驱动型：模式一多，这是最优解

如果模式超过5个、事件超过5类，顺序分支和事件循环都会变得很臃肿。这时候业界通用的做法是状态表驱动，把“哪个模式遇到哪个事件执行什么动作、切到什么模式”提取成一张二维表。伪代码写出来的不再是嵌套判断，而是查表。

// 状态表驱动型模式切换伪代码 定义事件类型： E_进入配置、E_退出配置、E_启动运行、E_停止、E_设置参数 定义模式编号： S_待机、S_配置、S_运行 定义状态表transition[模式][事件]： transition[S_待机][E_进入配置] = {动作: 加载配置参数+初始化配置接口, 下一模式: S_配置} transition[S_待机][E_启动运行] = {动作: 初始化外设, 下一模式: S_运行} transition[S_配置][E_退出配置] = {动作: 保存参数+关闭配置接口, 下一模式: S_待机} transition[S_配置][E_启动运行] = {动作: 加载新配置+初始化运行环境, 下一模式: S_运行} transition[S_配置][E_设置参数] = {动作: 更新配置参数, 下一模式: S_配置} transition[S_运行][E_停止] = {动作: 停止任务+释放资源, 下一模式: S_待机} transition[S_运行][E_进入配置] = {动作: 暂停任务+打开配置接口, 下一模式: S_配置} // 表格里没有的组合均为非法切换，统一忽略或报错 主流程(event) { if transition[当前模式][event] 不存在 { 记录错误("非法切换: 模式=" + 当前模式 + " 事件=" + event) return } 执行动作(transition[当前模式][event].动作) 当前模式 = transition[当前模式][event].下一模式 }

这种写法的优势非常突出：要加一种模式，只需要在表里加一行；要看所有合法状态，扫一眼表就行；切换逻辑错误也只可能出现在表定义里，而不会散落在大量if/else中。

我参与过的项目里，凡是模式超过5种的，最后几乎都改成状态表驱动。如果你现在准备新写一个模式切换逻辑，我建议直接上状态表，别犹豫。

4. 对号入座：三个真实的模式切换场景伪代码拆解

理论说了一堆，下面用三个具体场景把前面的写法串起来。这三个场景分别对应热词里提到的“AP胖瘦模式切换”“驱动调试软件语言切换”“设备模式切换”，我把每个场景的伪代码都给出一个可直接参考的版本。

4.1 无线AP胖模式和瘦模式切换：嵌入式设备现场配置场景

胖模式（Fat AP）和瘦模式（Fit AP）是无线网络设备里特别典型的模式切换需求。胖模式下AP独立工作、自己管配置；瘦模式下AP被AC集中管控，AP自己的配置功能关掉。实际现场操作里，很多AP默认瘦模式，需要切到胖模式做独立组网，这个切换一般通过设备上预留的按键、串口或专用配置页面完成。伪代码可以这么写：

// AP胖瘦模式切换伪代码 当前角色 = 瘦模式(Fit) 保存配置标记 = false 循环 { if 读取按键 == 模式切换键长按5秒 { 提示用户("即将切换工作模式，切换后设备将重启") if 当前角色 == 瘦模式 { 备份当前配置到持久化存储() 写入启动标志 = 胖模式 重启设备() } else if 当前角色 == 胖模式 { 写入启动标志 = 瘦模式 恢复出厂配置中的受管参数() 重启设备() } } if 串口收到切换指令 == "switch-to-fat" { 校验指令权限() 写入启动标志 = 胖模式 设置需重启标记 = true } if 串口收到切换指令 == "switch-to-fit" { 校验指令权限() 写入启动标志 = 瘦模式 设置需重启标记 = true } if 需重启标记 == true { 完成当前事务保存() 执行重启() } }

这段伪代码里的关键点其实是“重启设备”这个动作。很多AP的模式切换不能热切换，必须重启才能生效，所以伪代码里把“写入启动标志”和“重启”分开处理，中间留出了保存事务的空间。你在写类似场景时，一定要确认目标设备到底支持热切换还是只能冷切换，这决定了伪代码要不要在切换动作后面加上“需重启”这一步。我见过有人照着“改一个寄存器就能立即切换”的思路写伪代码，结果设备根本做不到，调试时全场傻眼。

4.2 英文驱动软件切换中文界面：软件本地化的模式切换细节

这个场景看着很简单，但里面有个容易踩的坑：语言切换不只是一句“改个变量”，它涉及界面刷新、字体重载、菜单重建、甚至部分控件的尺寸调整。伪代码里如果只写“语言=中文”，那这个伪代码就是个废的——它漏掉了模式切换后必须执行的配套动作。

// 软件界面语言切换伪代码 当前语言 = 英文(默认) 函数 切换语言(新语言代码) { if 新语言代码 == 当前语言 { 返回(无需切换) } 检查新语言的翻译资源文件是否存在() if 资源文件缺失 { 弹窗提示("语言包不存在，保持原语言") 返回 } 是 保存当前界面状态(): 记录当前窗口位置 = 主窗口坐标 记录当前焦点控件 = 焦点控件ID 否 保存当前界面状态无法完成(): 弹窗提示("有未保存的修改，请先处理") 返回 当前语言 = 新语言代码 重新加载菜单文本() 重新加载工具栏图标和提示文本() 重建当前打开的所有对话框() 按语言特性调整字体和控件尺寸() // 中文通常需要更高的行高 恢复窗口位置和焦点() 写入配置文件(语言 = 新语言代码) 提示用户("切换成功，部分界面将在重启后完全生效") }

4.3 从启动到运行的设备工作模式切换：多个起点与中断处理

有的设备不是简单的收到指令才切换，而是从上电开始就一路切换：启动模式→初始化模式→就绪模式→运行模式，中间还可能插入休眠模式、故障模式。这种伪代码更复杂的地方在于“启动过程本身就是一个模式切换序列”，同时还要考虑故障打断。

// 设备工作模式全生命周期伪代码 当前模式 = 启动模式 上电流程() { 硬件自检() if 自检失败 { 当前模式 = 故障模式 记录故障码(硬件自检失败) return } 加载配置() if 配置文件损坏 { 使用默认配置() 记录警告("配置损坏，使用默认参数") } 当前模式 = 初始化模式 初始化外设1() 初始化外设2() 初始化通信接口() if 任一初始化超时 { 当前模式 = 故障模式 记录故障码(初始化超时) 进入看门狗等待复位() return } 当前模式 = 就绪模式 通知上位机("设备就绪") } 主循环() { if 收到启动命令 and 当前模式 == 就绪模式 { 启动业务任务() 当前模式 = 运行模式 } if 收到停止命令 and 当前模式 == 运行模式 { 停止业务任务() 保存运行参数() 当前模式 = 就绪模式 } if 收到休眠命令 { 保存全部上下文() 关闭非必要外设() 当前模式 = 休眠模式 } if 当前模式 == 运行模式 { 执行周期业务() 检查运行异常() if 检测到严重异常 { 当前模式 = 故障模式 紧急停止输出() 记录故障码() 触发看门狗复位() } } }

这个场景里最容易被忽略的是故障模式。很多初版伪代码只有正常切换路径，没有异常路径，结果真实设备一跑就露馅。伪代码写得好的一个重要标准就是：正常路径覆盖完整，异常路径和非法路径也有明确归处。

5. 直接把伪代码改成可运行代码：一个从设计到编码的转化实例

伪代码写得好不好，有一个试金石：能不能顺畅地翻译成真实代码。尤其是模式切换逻辑，翻译过程中若需要大改结构，说明伪代码的结构有问题。下面用一个完整的例子来演示从伪代码到C语言代码的转化过程。

5.1 场景设定：多模式设备的状态机实现

设设备有三个输入事件：按键事件、定时器事件、串口数据事件。设备有三种模式：空闲模式、采集模式、传输模式。要求如下：空闲状态按按键进入采集模式；采集模式下定时器每100ms采集一次数据，收到串口“停止采集”指令回到空闲模式；空闲状态收到串口“传输数据”指令进入传输模式，传输完成后自动回到空闲模式。

5.2 先写伪代码，定死逻辑

事件：按键按下、定时器超时、串口收到"停止采集"、串口收到"传输数据"、传输完成 模式：空闲模式、采集模式、传输模式 状态表： 空闲模式 + 按键按下 => 动作[启动采集定时器] 下一模式[采集模式] 空闲模式 + 串口"传输数据" => 动作[开始传输数据] 下一模式[传输模式] 采集模式 + 定时器超时 => 动作[采集一次数据并存储] 下一模式[采集模式] 采集模式 + 串口"停止采集" => 动作[停止采集定时器] 下一模式[空闲模式] 传输模式 + 传输完成 => 动作[清理传输资源] 下一模式[空闲模式] 其他组合 => 忽略

5.3 再转成C语言实现

typedef enum { MODE_IDLE, MODE_ACQUIRE, MODE_TRANSMIT } device_mode_t; typedef enum { EVT_BUTTON, EVT_TIMER, EVT_STOP_ACQ, EVT_START_TX, EVT_TX_DONE, EVT_INVALID } event_t; device_mode_t current_mode = MODE_IDLE; static void do_start_acq_timer(void) { /* 启动定时器 */ } static void do_stop_acq_timer(void) { /* 停止定时器 */ } static void do_sample_data(void) { /* 采集一次 */ } static void do_start_tx(void) { /* 开始传输 */ } static void do_clean_tx(void) { /* 清理资源 */ } void handle_event(event_t evt) { switch (current_mode) { case MODE_IDLE: if (evt == EVT_BUTTON) { do_start_acq_timer(); current_mode = MODE_ACQUIRE; } else if (evt == EVT_START_TX) { do_start_tx(); current_mode = MODE_TRANSMIT; } else { /* 非法事件忽略 */ } break; case MODE_ACQUIRE: if (evt == EVT_TIMER) { do_sample_data(); /* 保持采集模式 */ } else if (evt == EVT_STOP_ACQ) { do_stop_acq_timer(); current_mode = MODE_IDLE; } else { /* 忽略 */ } break; case MODE_TRANSMIT: if (evt == EVT_TX_DONE) { do_clean_tx(); current_mode = MODE_IDLE; } else { /* 忽略 */ } break; default: /* 未知模式，恢复正常态 */ current_mode = MODE_IDLE; break; } }

对比一下伪代码和C代码就能看出，伪代码里的“事件”对应C代码里的枚举，“下一模式”对应变量赋值，“动作”对应函数调用。转换过程不需要拍脑袋加任何逻辑，只需要做机械翻译，这就是一份合格伪代码的验证标准。

这里附带一个实战中常见的问题：事件有可能同时到达，比如定时器刚触发，串口指令也到了。单线程裸机编程里这通常表现为中断嵌套，需要你决定事件优先级。伪代码阶段就要把这些写清楚，比如“定时器事件优先级高于串口事件”，否则写C代码时中断优先级配置会让人非常头大。

6. 在WPS Word里把伪代码排得像回事：字体、缩进和格式设置

前面所有内容都在讲伪代码怎么写，现在说一个非常接地气的话题——很多人在WPS Word或Word里写伪代码，结果排版丑得不行，缩进乱、字体不统一、看起来像一段普通的正文。我在这上面被折腾过不少次，说几个实践经验。

6.1 字体选择要贴近代码风格

伪代码虽然不是真正的代码，但它有代码的要素：关键字、变量名、缩进、符号。排版上最好按代码的风格来处理，核心就是等宽字体。我最常用的组合是：

• 等宽英文字体：Consolas 或 Courier New，必要时用中文语境也凑合的开源等宽字体，比如思源等宽。
• 中文字体：在WPS里直接设置等宽字体时，中文会回退到宋体或默认字体，观感尚可。如果你在意，可以把中文字体单独设为“等线”或“微软雅黑”，保持中文字符的清晰度。
• 字号：建议正文12磅，伪代码统一用小5号（10.5磅），行距设成固定值18磅左右，避免伪代码行与行之间太挤或者太松。

6.2 建立一个专门的“伪代码”段落样式

这是最省事的方法。我是在WPS里这样做的：

• 新建一个段落样式，命名为“伪代码”。
• 字体设为Consolas，西文字体和中文字体分别指定。
• 段落左缩进设为0.74厘米或1厘米，代表每层缩进的基础单位，后面手动加空格或制表符时都基于这个基准。
• 行距设为“固定值18磅”，关掉“如果定义了文档网格，则对齐到网格”，不然行距会被网格顶乱。
• 段前段后各设6磅，让伪代码块与正文之间有明显间隔。
• 背景色基本不加。如果确实想要代码块效果，可以给整个段落加个浅灰底纹，但我个人觉得白底黑字在技术文档里最稳妥，打印也正常。

6.3 缩进和换行不要用全角空格

这是一个非常隐蔽的坑。在中文输入法状态下按空格，输入的是全角空格，两个全角空格看着挺齐，实际上在等宽字体下宽度不一致，会导致伪代码的对齐在视觉上歪掉。写伪代码时，我建议把输入法切换到英文半角状态，缩进统一用“Tab”或“两个半角空格”。

给出的伪代码可以单行放下的尽量不换行。万一某行太长要换行，下一行缩进要比上一行多一层，同时行首用“|”或“→”之类的续行符标注，让人一眼看出这行是上一行的延续。不过技巧是：伪代码本来就不该写太长，一行超过80个字符就说明逻辑该拆分或变量名该缩短了。

6.4 直接在WPS里录制的实操步骤

为了不让大家觉得我在讲空话，我给出在WPS Word里的具体操作步骤：

1. 选中已经写好的伪代码段落。
2. 在“开始”选项卡里点“样式”右下角的小箭头，选择“新建样式”。
3. 名称输入“伪代码”，将基准样式设为“正文”。
4. 点击左下角“格式”按钮，选“字体”，西文字体选Consolas，中文字体选等线，大小为小五。
5. 再次点“格式”按钮，选“段落”，在对齐方式里选“左对齐”，缩进里的左缩进设为1字符，行距选固定值18磅，段前段后各6磅。
6. 保存样式，之后所有伪代码段落直接点这个样式就行。

另外，如果你要贴的伪代码里有大量的缩进和对齐，可以在Word/WPS里插入一个1×1的表格，把伪代码放进表格单元格里，表格边框设成无。这样伪代码块会被当成一个整体，不受页面分页影响，也不会被正文段落格式干扰。这个办法适合较长的伪代码。

7. 伪代码的正确性验证：拿“100到200之间的素数输出”做一次完整推演

讲了这么多模式切换，现在换一个完全不同的经典问题来收尾这一段——判断一个伪代码写得对不对、能不能直接用。就用热词里提到的这个经典算法题：输出100到200之间的所有素数。这个题目虽然简单，但正好能说明伪代码的几种表达方式之间的差异，以及如何验证伪代码的正确性。

7.1 用三种描述方式表达同一个算法

这个题目的标准解法是：遍历100到200之间的每个整数，判断它是否为素数（只能被1和自身整除），是则输出。有三种常见表达方式。

方式一：流程图

流程图的画法是：开始→初始化i=100→是否i>200？（是则结束）→否，初始化j=2→是否j < i且i能被j整除？→是则i加1并回到判断i的范围；否则j加1再重复内层判断→内层循环结束后检查j是否达到i，是则输出i。

流程图适合给人讲解“流程走得通不通”，它的优点是直观，缺点是写起来费纸，而且复杂逻辑画出来像蜘蛛网。执行力强的团队很少用流程图指导编码，更多用来做PPT汇报。

方式二：NS图

NS图（Nassi-Shneiderman图）用嵌套矩形描述逻辑，每个矩形块表示一个处理步骤或判断。它的好处是强制结构化，没有箭头跳转，缺点是绘制工具支持度差，大部分情况下是手工慢慢画，投入产出比很低。题目的NS图画出来就是外面一个大矩形“从100到200遍历”，里面再嵌一个内层循环矩形“判断是否为素数”，再嵌一个输出矩形。

方式三：伪代码

这是我在文档里和给团队评审时最常用的表达方式。

// 输出100~200之间的素数 for i = 100 to 200 { 是否为素数 = 真 for j = 2 to (i-1) { if i 能被 j 整除 { 是否为素数 = 假 break // 跳出内层循环，不是素数 } } if 是否为素数 == 真 { 输出(i) } }

这段伪代码的任何一行都不涉及某一门语言的语法细节，但任何会写程序的人都能看懂，也都能翻译成自己熟悉的语言。

7.2 验证伪代码的正确性：手动干跑和边界检查

伪代码写完不能拍胸脯说“肯定没问题”，尤其是给别人用的伪代码，我通常用“手动干跑”的方式过一遍。所谓干跑，就是拿几个典型输入值，把伪代码的每一条分支走一遍，核对变量变化和输出。

就拿100这个起始值来说，i=100，内层j从2跑到99，中间能被2整除，所以100直接标记非素数，不输出。再看101，j=2时101%2不等于0，j=3时也不等于0，一路跑到100，都没整除，于是101被输出。再检查边界200，200%2等于0，非素数，不输出。跑完三个值，基本能确定逻辑主干没问题。

接下来是边界检查：如果i等于100，内层循环需要判断j从2到99，循环能正常进入；i如果等于200，也一样。如果把题目改成求2到3之间的素数，内层循环就要注意会不会出现j从2到1的脏数据，虽然这里用不到，但写伪代码的人心里要有这个意识。

这种验证习惯对模式切换伪代码同样重要。在写模式切换伪代码的时候，状态表里每一格你都要问一次：如果当前状态是X，来了事件Y，会发生什么？干跑一遍所有表格组合，很多漏洞都能在写代码前暴露出来。

8. 伪代码的六条军规：靠这些躲开九十年代就存在的老坑

最后把这几年做方案、写文档、审别人伪代码的经验总结成几条硬规则，你可以把这一部分当作一个速查清单。

8.1 命名有“代码样”，但别用具体API

伪代码里的变量、模式、事件，命名要和真实代码接近，使用有语义的英文单词或拼音缩写，比如current_mode、evt_button、AP_FAT_MODE。避免用a、b、c这种无意义命名。但又不要直接写死某个具体API调用，比如写“write_reg(0x1234, 0x56)”这就是真代码，不是伪代码。伪代码应该停留在“调用某个动作函数”层级，比如“写寄存器使能配置模式”，具体地址留给实现阶段。

8.2 分支条件必须写完整，不能只写一半

很多人写伪代码喜欢写：

if 模式 == 运行模式 { 执行运行逻辑 }

然后就没有else分支了。这倒也可以，但在模式切换这种场景下，我建议把非法的、不能处理的分支也写出来：

if 模式 == 运行模式 { 执行运行逻辑 } else { 报错并拒绝 }

原因很简单：模式切换的bug多半出现在“你不希望发生的分支”里，把它显式写出来会让问题提前暴露。

8.3 每个“下一模式”要出现在状态表能查到的地方

状态表驱动型伪代码里，如果某一行说“切换到配置模式”，那么配置模式必须和当前的源模式构成一个合法转换。否则即使伪代码写得工整，翻译成代码后也会出现一个“不可能到达的状态”，运行一段时间后炸出诡异bug。

8.4 注释写“为什么”，不写“做了什么”

伪代码本身的逻辑已经清楚表达了“做了什么”，所以注释别写成“设置当前模式为配置模式”，这种注释是废话。注释应该写“为什么要切到这个模式”“如果这里失败会有什么影响”。你过三个月回来看伪代码，看到的应该是决策依据，而不是一份流水账。

8.5 保持伪代码在“人类语言”和“编程语言”之间的平衡

伪代码太偏向人类语言，会含糊不清；太偏向编程语言，又失去了伪代码的意义。我的判断标准是：一个不懂你业务的人，拿到这份伪代码能不能猜到大概流程？如果能，这份伪代码的抽象层级就对了。模式切换伪代码尤其需要这个平衡，因为模式切换本身是业务逻辑，不是纯粹的计算逻辑，读者的背景可能千差万别。

8.6 配一个“模式转换总览”段落

如果伪代码所在的文档是设计文档，我建议在伪代码前面加一个模式总览：列出所有模式名、所有事件名、合法转换表。这相当于给读文档的人一张地图，伪代码只是地图上的一条条路径。这是我这些年写方案总结出来的习惯，每次加了这张表，评审会上关于模式切换的争论都会少很多。

一点收尾的实在话

干这行时间长了，你会发现伪代码被很多人当成一种可有可无的过渡产物——需求着急就直接写代码，伪代码反而是浪费时间。但就模式切换这类场景来说，我始终认为伪代码是性价比最高的设计工具：它花不了十分钟，却能把最容易被忽略的状态边界、非法组合、切换动作一次性暴露出来。我在实际项目里吃过“状态转换没提前梳理”的亏，也吃过“伪代码写得太烂完全无法指导编码”的亏，后来慢慢形成这套写法，再处理模式切换需求时明显顺了很多。

如果你现在正被某个“模式切换”问题困扰，我的建议是：先别打开编译器，先打开一个空白文档，把模式、事件、状态转换表列出来，再按这篇文章里的思路写一份伪代码。等你写完这份伪代码，大概率会发现之前想不清晰的细节，已经自己浮出水面了。