本文来自微信公众号： 防冷涂的蜡书斋 ，作者：防冷涂的蜡
2026年11月1日，一名乘客坐上D655次列车，准备在后半程享受一下一等座。她分段买了两张票：湖州至杭州东，3号车厢二等座；杭州东至宁波，9号车厢一等座。车票都有效，麻烦出在从一个座位走向另一个座位的途中。
这趟车采用8+8重联编组，两组车厢之间隔着驾驶室，无法从车内穿行。她发现时列车已经开出杭州东，下一站就是宁波，没机会下车绕行，只好站完后半程。12306客服向记者确认了通行限制，并表示这种情况不退差价。
票卖出去了，座位也确实存在，列车正常抵达目的地。拆开来看，似乎没有哪件事办不成；放在一起，乘客却享受不到已经付费的服务。
类似的事并不少见：影院卖出的座位被柱子挡住视线，代驾司机看着近却要绕山跨桥，骑手到了商场定位点仍找不到取餐入口。系统已经如此精密，为什么生活中还不断出现这些令人窒息的Bug？
系统看到的，只是真实世界的简化版本
《盐铁论·水旱》记下过一场关于农具的争论。汉武帝推行盐铁官营后，官府统一组织铁器生产。公元前81年的盐铁会议上，贤良文学批评部分铁器偏重大件，“务应员程，不给民用”：忙于完成规定的生产任务，却难以满足实际耕作需要。
管理者要计算产量、安排供应，需要一套统一的规格和考核办法。农民拿到手里，却要看农具能否割草、翻土，适不适合当地耕作。同一件铁器，在生产记录上可以交差，到了田里却可能使不上力。
大规模管理总要做这种取舍。逐户了解每块田的情况，再逐件安排农具，信息和协调成本太高。把需求归成几类，按规格生产，才容易组织成规模。但分类之后，那些被略去的差异，并不会从田里一同消失。
斯科特在《国家的视角》中讨论的“可读性”，解释了这种管理需求。人口需要登记，土地需要丈量，纷杂的地方情况被整理成统一记录，远处的管理者才能比较、调配和决策。简化让现实变得可管理，也决定了哪些现实会被看见。
数字系统把这项能力推得更远。车次、车厢、座位和价格都能准确记录，乘客换座却还需要一条可通行的路径。影院座位有编号、有库存，观众能否看清银幕，还取决于座位、柱子与银幕的位置关系。
这里需要分清对象的属性与对象之间的关系。知道两个人的坐标，不等于知道他们之间有没有桥；确认两个座位都能出售，也没有完成对换座路径的检查。关系一旦遗漏，再精确的单项记录也补不上。
于是，系统可以根据已有信息算出一个正确结果，现实任务却缺少完成条件。即使把这些固定条件逐一补齐，另一个麻烦仍然存在：现场会变。
计划安排得很完美，现实却不照着执行
1992年，伦敦救护车服务机构引入计算机辅助调度，试图把接警、定位、选车和派遣连起来。救护车在哪里、是否空闲，都可以进入系统，调度员似乎终于不必在大量电话和车辆信息之间来回查找。
10月26日至27日，严重混乱却发生了。调查报告指出，那两天计算机总体上按设计运行，设计本身却过度依赖准确、及时的车辆位置和状态。医护人员忙于现场救援，未必及时按下状态按钮，通信也会出现延迟和遗漏。
这些偏差逐渐累积，系统开始把多辆车派往同一事件，或没能派出更合适的车辆。迟迟等不到救护车的人再次打来电话，异常提示越积越多，调度员纠错更加困难。原本用于协调工作的系统，又增加了需要协调的工作。
困难在于，预先定义好“出发、到达、空闲”，并不能保证每次状态变化都会准时出现在屏幕上。现场人员必须先处理正在发生的事情，系统却要用已经收到的信息决定下一步。一处延迟，因而可能影响后续多次派遣。
露西·萨奇曼在《计划与情境行动》中强调，人的行动始终嵌在具体环境里。计划可以提供方向，实际步骤却要随着他人的动作和现场条件不断调整。人们能够把事情办成，常常正因为没有机械地照着原计划走。
商场取餐也如此。“到店、出餐、取餐、送达”很好画成流程，但骑手到了入口，可能临时被要求换门；找到货梯，前面又排着运货的人；轮到取餐时，商家还没有做好。上一单顺畅的路线，下一单未必同样顺畅。
固定的入口位置可以预先登记，临时封门和排队则需要现场调整。一套流程是否可靠，还要看它能否在执行中被修正。现场条件变了，后续派单和送达时间却没有调整，原本合理的安排就会逐渐失效。
每个环节都在提高效率，整体为什么反而出了问题？
有时候，问题甚至发生在各项改进都奏效之后。19世纪伦敦，抽水马桶逐渐普及，家庭清理污物方便了许多。过去需要储存、搬运的东西，用水就能冲走。对单个家庭来说，这当然是生活条件的改善。
但污物离开房屋后，进入了缺少完善处理设施的城市排污体系，大量流入泰晤士河。人口增长、工业污染再叠加夏季高温，1858年的伦敦迎来了“大恶臭”。沿河居民和在河边办公的议员，都得面对这股难以躲开的气味。
家庭完成了清理，城市没有完成处置。污物冲得越方便，下游承受的压力就越集中。如果只在房屋门口验收这项进步，改善已经发生；把河流和整座城市算进来，任务远未结束。
局部效率能否变成整体效率，取决于每个环节之间的衔接。复杂系统里的工作彼此依赖，上游增加处理量，下游未必同步扩容。一个部门省下的时间，也可能让另一处排起更长的队。
布雷斯悖论可以解释了这种反常：在特定道路网络里，新增一条路会改变司机的路线选择，反而让通行时间增加。每个人都选对自己有利的路线，汇集起来却未必最顺畅。单独看一条路的便利，容易忽略改道之后整张路网的流量变化。
2024年，《解放日报·上观新闻》调查上海外卖路线发现，部分平台推荐的路径包含逆行路段。其中一条只有1.4公里，按合法方向绕行却约需3公里。若只比较距离，前者显然更短；骑手真要完成订单，交通规则却绕不过去。
这里有两层问题。首先，缩短距离能否代表完成配送？送达时间、合法通行和安全都属于任务要求。其次，规划给下一环节留下了什么条件？若仍按1.4公里安排时间，骑手选择合法绕行，原本“高效”的安排便会变得紧张。
路程短是评价路线的指标，合法通行是路线成立的前提。只有先排除不可行方案，再比较其余路线，优化才有实际意义。任务是否完成，需要沿着服务的全过程检验，不能只停在某个环节的报表上。
各个部门都完成了任务，为什么整件事还是办不成？
把整体目标写清楚，还不足以让所有环节衔接顺畅。
19世纪英国铁路迅速扩张，大西部铁路采用宽轨，其他公司广泛使用较窄的轨距。各家的列车都能在自己的线路上运行，铁路接到一起，旅客却无法坐同一列车走完全程。
格洛斯特就是著名的交汇点。旅客要换车，行李、货物也要重新搬运。英国科学博物馆收藏的一幅约1846年的讽刺画，描绘了这一过程。两段铁路各自解决了运输，接起来却多出一道搬运手续。
1846年，英国通过立法推进轨距标准化，限制新建宽轨线路。单家公司可以自行选择技术，但只要乘客和货物需要跨公司旅行，就必须共同处理连接问题。运输网络的价值，取决于线路之间能否兼容。
梅尔文·康威提出过一个观察：组织设计出的系统，会反映其内部的沟通结构。工作怎样分组，信息通过哪些人传递，往往也会影响系统怎样划分、各部分怎样连接。组织里难以沟通的地方，产品中也容易留下接缝。
专业化分工因此带来一项额外任务。
每个人只负责其中一部分，才有精力把它做好；但完整服务涉及的条件，会分散在不同人的知识和权限里。把工作分配完，还需要把交接关系重新组织起来。
以外卖服务需要的几类工作为例：地图维护位置，算法估算时间，产品安排交易规则，运营协调商户和骑手。商场更改一个取餐入口，便可能同时影响路线、预计时间和页面提示。它很难靠某一项工作独立完成。
即使现场人员知道入口变了，也要有人确认信息、推动修改，并让相关环节同时生效。若地图已经更新，时间仍按旧路线计算，骑手照样遇到麻烦。知道问题的人与能够修改规则的人之间，需要一条走得通的协作路径。
1999年失联的NASA火星气候探测器，暴露了更昂贵的交接失败。一套软件提供英制数据，导航端按公制理解，轨道计算由此出现偏差。相关验证和沟通又没有及时发现错误，两个环节之间的单位差异最终毁掉了任务。
一个接口能收到数字，并不代表双方对数字有相同理解。跨团队协作要共同确认信息的含义、使用条件和异常处理办法，还要检验连接后的完整过程。许多Bug就出在这里：各部分都有负责人，连接后的结果却缺少持续检查。
系统出了Bug，为什么总要靠人来补？
存在这些漏洞，系统为什么仍能运转？明代地方征税留下过一个有意思的答案。赋役黄册登记人户、田地等情况，按规定十年大造一次。但人口迁移、田地买卖不断发生，一些地方又存在造册失实，正式记录逐渐脱离征派需要。
在一些地区，地方官府更多依靠实征册办理实际征派，按当地情况记录纳税对象和征收事项。于是，正式黄册与实用册籍并存：上面有一套管理记录，下面办事还要另一套。地方工作能够继续，依赖的正是这层补充。
今天，许多服务也靠这样的经验运转。熟练骑手知道从哪个门进商场，司机知道哪个出口适合接人，客服知道怎样处理特殊订单。它们未必写进统一流程，却能让原本办不成的事情顺利结束。
补救甚至可能让缺陷更难被看见。一笔订单最后完成了，记录里便只剩下“完成”，中间打了多少电话、绕了多少路没有留下。新人再遇到同样的情况，仍然要重新摸索。人补好了这一次，不等于系统学会了下一次。
2026年7月，《解放日报》报道上海部分商圈尝试“取送分离”：专职人员在商场内集中取餐，送到接驳点，再交给骑手配送。报道中的测算显示，这种模式可使配送平均提速约6—15分钟。
这项尝试把反复出现的困难变成了流程调整。骑手不必各自寻找商户、等待货梯，平台、商场和商户则要重新协调人手、交接与责任。现场经验进入系统之后，改变的可以是工作本身，未必只是在原有算法里再加一个参数。
系统之外，还有一个真实世界
回到那名站着抵达宁波的乘客。两张车票都有效，座位确实存在，缺少的却是一条她当时能够走通的路径。对售票来说，两笔交易已经完成；对乘客来说，购买一等座的目的还没有实现。
评价一套系统，也该沿着人的实际行动再走一遍。哪里无法继续，谁临时帮了忙，下一次是否还会卡住，都应该进入改进的依据。成熟系统的能力，包括发现异常、吸收现场反馈，并让同一种错误越来越少。一个人这次终于办成了，系统还要能让下一个人少费些周折。
