如果你问一个刚接触业务系统的人，什么最难？答案通常是：功能多、逻辑复杂、需求变化快。但只要你真的长期维护过系统，就会慢慢意识到：真正让系统失控的，大多数情况下不是功能，而是状态。
一、什么是“状态”？
在业务系统中，状态并不是一个技术概念，而是一个非常现实的东西：系统对“现在发生了什么”的正式承认。例如：
报名：未提交 / 已提交 / 已审核 / 已取消
订单：待支付 / 已支付 / 已退款
账号：正常 / 冻结 / 注销中
功能是你“能做什么”，状态是系统在说：“这件事现在算不算已经发生。”
二、为什么状态一多，系统就开始难以控制？
因为状态有三个天然属性。
1️⃣ 状态是累加的，而不是替换的
功能可以删，状态几乎不能。你可以删掉一个按钮，但你无法抹掉「已经发生过」的事实。于是系统里会慢慢出现：
已取消但曾经支付
显示成功但业务未完成
用户已看到，但后台想回滚
这些往往不是 Bug，而是状态关系在一开始就没有被定义清楚。
2️⃣ 状态之间并不是“随便跳”的
在真实世界里，状态有合法路径：
已支付 → 已退款（合理）
已完成 → 处理中（通常不合理）
但如果你没有明确限制这些路径，系统默认的逻辑是：“都能跳。”这也是很多系统出现“解释不清的中间态”的根源。
3️⃣ 一旦状态被用户感知，就不可随意修改
只要用户看到过诸如：报名成功、支付完成、审核通过等， 这个状态就变成了一种承诺。技术上你可以回滚，但业务上、心理上，已经回不去了。
三、复杂性不是来自状态数量，而是状态组合
很多人误以为：状态少 = 系统简单，但真正的复杂性来自：多个状态系统并行存在。
例如一个订单系统：
订单状态
支付状态
发货状态
售后状态
每一个单独看都很“清晰”，但组合在一起，复杂度是指数级的。
四、状态模糊时，系统只能靠“人”活着
当状态不清晰时，系统通常会退化为：
靠文档解释
靠口头约定
靠“大家都懂”
系统还能跑，但本质上已经开始依赖人来兜底。这也是很多系统“小规模还能用、一放量就出事”的根本原因。
五、最危险的状态，是“系统里没有的状态”
还有一类状态，尤其隐蔽：
是否已经人工处理过
是否已经通知过用户
是否正在被某个人操作
是否需要再次确认
这些状态：不在数据库里、不在界面上、只存在于某个人的脑子里 而这，恰恰是系统最脆弱的部分。
六、为什么在 Vibe Coding 时代，状态问题暴露得更早？
因为 Vibe Coding 非常擅长一件事：快速把“功能层”补齐。页面、流程、接口、按钮，很快就能跑起来。但它不会替你做这些判断：
状态应该有多少种
哪些状态是非法的
哪些变化必须被限制
于是结果是：功能很快完成，状态问题立刻显形。这并不是 AI 把系统变复杂了，而是它不再允许你用“慢开发”来掩盖判断缺失。
七、成熟系统的标志，不是功能多，而是状态被收敛
真正稳定的业务系统，往往有一个共同特征：
状态数量有限
状态转换路径清晰
非法状态不可达
每一次变化都有来源
换句话说：状态是第一公民，功能只是围绕状态展开的工具。
业务系统真正的复杂源头，不是功能、不是代码、也不是工具，而是：系统到底承认了多少种“正在发生的事实”。Vibe Coding 只是让你更早面对这个问题。而是否认真对待状态，决定了一个系统能不能活得久。