背景
我长期在 BGC（Bonifacio Global City）生活，对这里的交通信号有一个很强烈的感受：BGC 道路规划并不算复杂，路网也相对规则，但部分红绿灯的控制水平非常低，甚至存在相邻路口互相制造拥堵的情况。
最明显的几个例子：
- McKinley Parkway 与 10th Ave 的路口，在很多情况下看不出有效的单路口车流自适应能力。即使一个方向明显没有车辆，另一个方向仍可能按照固定周期等待。
- McKinley Parkway、7th Ave、Rizal Drive 附近有两个距离非常近的信号路口，间距大约只有几十米，但经常出现前一个绿灯、后一个红灯的情况。
- 车辆刚通过第一个路口，马上在几十米外被第二个红灯截停；队列一长，又可能回堵第一个路口。
- 部分信号周期体感接近 120 秒，使这种不合理的 offset 对交通体验影响尤其明显。
BGC 多年前已经宣传使用 adaptive traffic signal，后来又建设所谓 AI-powered smart traffic system。但从实际道路体验来看，至少部分路口并没有表现出成熟的 corridor-level coordinated control。
我的基本判断
解决这个问题实际上并不需要一个复杂的“实时 AI 控制红绿灯”系统。
对于 BGC 这种面积有限、道路拓扑相对固定、每天交通规律高度重复的区域，成熟的交通工程方法加上今天已经非常廉价的摄像头、边缘计算、5G 通信和服务器，就足以大幅改善体验。
核心原则是：
AI 不应该在线实时决定红绿灯下一秒怎么变化。AI 最有价值的工作应该发生在离线阶段——根据真实交通数据寻找更好的信号控制方案。最终上线运行的反而应该是一套简单、稳定、确定、可审计的固定算法和预设方案库。
第一阶段：先把交通真实情况测清楚
在主要路口安装摄像头。
一个路口可以根据实际视野使用一个四方向摄像头、四个独立摄像头或者其他合适组合。
摄像头视频不需要持续上传中央服务器。
每个路口配置一个联网的 edge computer，本地完成车辆识别和统计，只需要输出结构化数据，例如：
- 各方向车辆流量
- 转向比例
- 排队长度
- lane occupancy
- 车辆平均通过时间
- P95 通过时间
- 不同时段的流量变化
- 下游道路剩余容纳能力
连续采集数周，至少覆盖：
- 工作日早高峰
- 午间
- 晚高峰
- 夜间
- 周末
- 特殊拥堵情况
最终得到 BGC 路网真实的 traffic demand model，而不是靠人工经验猜测应该给哪个方向多少秒绿灯。
第二阶段：建立 Digital Twin，让计算机离线试错
根据实际道路拓扑、车道数量、转向关系、行人相位和摄像头采集的真实交通数据，使用 SUMO、Vissim 或类似 microscopic traffic simulation 建立 BGC 的 digital twin。
然后让优化程序自动尝试大量红绿灯组合。
主要变量包括：
- Cycle：一个完整信号周期长度
- Split：不同方向分别获得多少绿灯时间
- Offset：相邻路口之间绿灯启动时间的偏移
- Phase sequence：不同交通相位的执行顺序
这里可以使用 AI，也可以使用更传统的优化方法，例如：
- Genetic Algorithm
- Bayesian Optimization
- Reinforcement Learning
- 其他组合优化方法
Codex/LLM 更适合帮助建立仿真系统、编写优化程序、分析结果和生成候选方案，而不是直接作为生产环境中的交通控制器。
优化目标不能只看平均车速或者 throughput。
至少应该同时优化：
- Average delay
- Number of stops
- Average travel time
- P95 travel time
- Maximum queue length
- Corridor throughput
- Pedestrian waiting time
- Queue spillback
其中应该对 queue spillback 设置很高的 penalty。
原因很简单：
如果上游绿灯把大量车辆放进一个只有几十米长的道路，而下游正好是红灯，那么即使整个系统平均 throughput 看起来还可以，实际道路体验也会非常差，甚至会发生队列反向堵塞上一个路口。
McKinley Parkway / 7th Ave / Rizal Drive 一带就是非常典型的这种场景。
第三阶段：AI 完成工作后，把结果固化
经过大量模拟以后，不需要让 AI 继续在线控制交通。
可以生成一个类似：
BGC Signal Plan Library
例如包含 10–20 套经过模拟验证的方案：
- Normal
- Low Traffic / Night
- AM Peak
- PM Peak
- McKinley Northbound Heavy
- McKinley Southbound Heavy
- 32nd Street Heavy
- 26th Street Heavy
- Local Incident
- Lane Blockage
- Gridlock Recovery
- Special Event
实际可能只有 5–8 个主要方案就能覆盖绝大多数时间，其他方案处理异常情况。
每套方案已经明确规定：
cycle + split + offset + phase sequence
因此生产系统并不需要实时求解复杂数学问题。
第四阶段：线上系统只判断“现在属于哪个状态”
摄像头继续实时统计交通状态。
中央系统每隔 1–5 分钟判断一次：
现在的交通状况最接近哪个预设 Traffic State？
例如：
Normal → McKinley Southbound Heavy
如果某种状态持续一定时间，例如连续 3 分钟或者连续两个 observation window 达到阈值，中央系统就在安全的周期边界切换到相应 Signal Plan。
这样可以避免方案频繁来回切换。
系统实际上只需要解决：
Traffic State Classification → Signal Plan Selection
甚至这一步也未必需要 AI。
完全可以采用透明的 rule-based algorithm，例如：
如果 McKinley Southbound queue > X，并持续 Y 分钟，同时 downstream capacity > Z，则进入 SB Heavy State。
这比一个不可解释的实时 AI controller 更可靠。
通信也不需要实时到毫秒级
各路口可以通过 5G 与中央系统通信。
但 5G 并不是安全关键的实时控制总线。
中央系统不应该通过网络发送：
“现在打开北向绿灯。”
而应该发送：
“下一安全切换点开始执行 Signal Plan 07。”
因此几十毫秒、几百毫秒甚至偶尔几秒的网络延迟都不会影响系统逻辑。
网络中断时，各路口继续运行当前方案；如果长时间无法与中央系统通信，则退回预设的 time-of-day fallback plan。
一个非常重要的安全设计
中央服务器永远不应该直接控制红灯、黄灯和绿灯的电气状态。
真正的：
- minimum green
- yellow interval
- all-red clearance
- pedestrian clearance
- conflicting phase protection
- fail-safe
仍然应该由经过认证的 local traffic signal controller 负责。
中央系统只能选择经过验证的 Signal Plan。
这样即使：
- 5G 断线
- 中央服务器死机
- 程序发生 bug
- 优化系统产生错误结果
也不能造成两个冲突方向同时变绿这种安全事故。
最坏情况只是自动退回传统固定配时。
为什么“绿波”特别重要
对于相邻路口，尤其是只有几十米距离的路口，真正关键的不只是各自给多少秒绿灯，而是 offset。
假设两个路口相距 50 米，车辆平均速度约 25 km/h。
车辆通过这段距离大约需要：
50 m ÷ 6.9 m/s ≈ 7 秒。
那么下一个路口的绿灯启动时间就应该考虑这约 7 秒 travel time。
这就是最基本的 signal progression / green wave。
如果反过来：
第一个路口 Green → 第二个路口 Red
然后：
第一个路口 Red → 第二个路口 Green
两个路口实际上就在轮流把中间几十米道路当成停车场。
这不是一个需要高级 AI 才能解决的问题，而是最基础的 signal coordination 问题。
甚至可以加入 Spillback Protection
如果下游摄像头发现：
下游道路 occupancy > 85%
那么上游即使按照正常时间应该放行，也可以暂时减少向这段道路释放车辆，把绿灯时间分配给其他方向。
当下游道路恢复容量后，再释放 upstream platoon。
因此整个系统不仅有：
Green Wave
还应该有：
Queue Spillback Protection
前者减少停车次数，后者避免局部拥堵扩散成 gridlock。
最适合 BGC 的实施方法不是一次改造全部路口
第一阶段完全没有必要一次改造整个 BGC。
可以选择：
McKinley Parkway Corridor Pilot
先挑选大约 5–8 个连续路口。
步骤：
- 摄像头采集真实交通数据；
- 测量目前所有 signal timing；
- 建立 corridor digital twin；
- 重现目前的拥堵情况；
- 自动优化 cycle / split / offset；
- 生成 5–10 套 Signal Plans；
- 仿真验证；
- 在真实道路灰度上线；
- 连续运行一个月；
- 与改造前进行 A/B comparison。
核心 KPI：
- Average travel time
- P95 travel time
- Average delay
- Stops per vehicle
- Maximum queue length
- Spillback events
- Corridor throughput
如果 McKinley Parkway pilot 明显改善，再逐步扩大到整个 BGC。
最核心的观点
这个项目最有意思的地方恰恰在于：
不需要迷信 AI。
AI 可以非常适合做一个人类很不愿意做的工作：
拿着几周甚至几个月真实交通数据，在数字孪生里不停试验成千上万种红绿灯组合，最终找出一批非常好的方案。
但当这些方案找到以后，AI 的工作实际上已经完成。
真正每天管理 BGC 交通的，可以只是一套非常普通、稳定、透明的确定性程序：
Sense → Classify → Select Plan → Execute → Measure
每隔几个月，再把积累的新数据放回 digital twin，让优化系统重新跑一遍，更新 Signal Plan Library。
也就是说：
AI 负责学习和设计，传统软件负责执行。
对于 BGC 这样一个道路规模有限、交通规律明显、但现有信号协调体验并不理想的区域，这种方案可能比追求一个昂贵、复杂、完全实时的“AI Traffic Control System”更容易实施、更安全，也更容易证明实际效果。