我做了一套號誌連鎖圖，協助台中市交通局改善了超過 200 個路口號誌

這是我九月份一邊準備刷 leetcode 找工作，一邊開發的個人專案。（2026 年了還有公司面試要看 leetcode 真的好哀傷。）

補充一些故事背景，我沒有學過交通工程，只是一個軟體工程師，起初我只是想要協助在交通局工作的朋友解決一個小問題：「算出兩個路口紅綠燈最適合的時差」。

每個路口的紅綠燈都是按照固定的秒數在循環的，例如 180 秒放行一遍所有方向的車流。時差的意思是，這個路口的週期相對於全市共同的時鐘晚幾秒開始。例如週期 180 秒、時差 15 秒，表示週期從全市時鐘的第 15 秒開始，到第 195 秒結束，然後重複。

通常一個紅綠燈會有多組設定，計算每組設定的時差，是一個容易出錯的工作。花了點時間釐清需求後，很快我就做出一個號誌時差計算工具，用戶能夠上傳兩個路口的設定文件，並且能夠計算出兩個路口間紅綠燈秒數的最佳時差。

過了幾天後我開始想，用戶需要自己上傳兩份路口的設定文件。如果我們可以把所有路口都放在地圖上，一眼看出哪個路口的時差設計得好、哪裡設計不良，那這樣肯定對於時差的調整會非常有幫助。

交通局沒有這樣的工具，於是我花了一個禮拜，把這套系統升級成了「號誌連鎖圖」。第二個禮拜我整合了台中 74 環內 2000 多個號誌路口，一個月後，我匯入了原台中市與舊縣區所有的紅綠燈。交通局的承辦人員現在用它檢查、修正紅綠燈的時差問題，到 10 月，局內同仁已經利用這套系統改善超過 200 個路口。

紅綠燈是怎麼設定的？

紅綠燈是依照路口進行設定的，專業術語叫做「時制計畫表」，一個路口會有一份時制計畫表。

時制計畫表能夠表達：

• 時相：哪個方向的車流要綠燈，例如放行東西向車流。複雜一點的路口，會有左轉專用或行人專用的時相。
• 時相組合：一系列的時相，例如先放行東西向、再放行南北向車流。
• 時制：設定每個時相的秒數，例如東西向綠燈 30 秒，南北向綠燈 50 秒。
  • 週期：所有時相輪完一次要幾秒，例如 120 秒。
  • 時差：這個週期相對於全市共同的時鐘，晚幾秒開始。
• 型態：例如尖峰用週期比較長的時制，離峰用比較短的。大部分的路口會有兩組型態，一個平日，一個假日，再指定禮拜幾用哪一組。也可能有更多。

左邊是一個簡單十字路口的時制計畫表，右邊是台灣大道上某個相對複雜的路口。

簡單的十字路口

台灣大道上的路口

連鎖性

知道紅綠燈是怎麼設定後，再來要介紹「連鎖性」（signal coordination）。

連鎖性俗稱綠波（Green Wave），是指相鄰路口的綠燈彼此配合：你在第一個路口遇到綠燈，開到下一個路口時，那裡的綠燈也剛好亮著，車流可以一路過去，開起來非常爽，不用每個路口都停下來。

連鎖有兩個前提：

1. 路口要相鄰

2. 週期要相同，或剛好成整數倍。 一個 120 秒、一個 90 秒的路口，綠燈每一輪都會錯開，怎麼調都沒用。但如果兩個都是 120 秒，或是一個週期 120 秒，一個 60 秒，那就可以調整來提升連鎖性。

下面兩張時空圖，左邊是連鎖的路口，前後路口的綠燈有非常高的重疊；右邊是不連鎖的路口，前一個路口綠燈的時候，下一個路口還會停在紅燈十幾秒，過一陣子才會變綠燈。

連鎖：綠燈高度重疊

不連鎖：下一個路口還在紅燈

路口的連鎖性是有取捨與限制的，沒辦法讓所有的路口都連鎖。大部分的設計原則會是，讓主要幹道一路暢通，讓支道配合主要幹道。

更進階的連鎖性會考慮車速，但因為市區路口間的距離通常都不長，經過與承辦人討論後，先暫時不考量車速差。

把連鎖畫在地圖上

理解連鎖性後，我們就可以在地圖上呈現連鎖。

連鎖是有方向性的，每一對要連鎖的相鄰路口，在地圖上能被畫成一條有色箭頭。

選定一個觀察的時間點，例如週一早上八點，工具會算出那個時刻兩個路口的連鎖性，比較它們的綠燈對的多準：對得越準越綠，差得越多越紅。

我們能在地圖上觀察不同的時間點，一整塊區域的連鎖性怎麼變化。

接著承辦人就可以直接對著地圖上點選要評估的方向，透過拖曳的方式，評估一個路口綠燈的偏移量，對相鄰路口的影響。

開發的挑戰

實際開發過程有數百個大大小小的決定要評估，因為這是一個沒有現成設計可以參考的系統。如果您也是個軟體開發者，您應該可以意識到我省略了諸多細節，我舉兩個比較大的挑戰。

1. 怎麼對路口的連鎖性建模？

我們透過不同顏色的箭頭呈現兩個路口的連鎖程度，同時這也代表箭頭需要知道，起點路口用哪個時相放行車流，終點路口用哪個時相接收車流。

最簡單的做法是在每一條箭頭直接記起迄兩個時相。但是背後的複雜之處在於：

1. 路口的時相並不是固定的，週末平日的時相可能是不同的
2. 每添加一條評估連鎖性用的邊，就需要去選擇兩個路口的時相，但細看路口的時相設定很麻煩（要對照圖片才知道方向），有時時相 1 是東西向，有時時相 1 是南北向。

因此我評估後認為，應該要讓路口自身可以表達「這個路口允許哪些方向的車流」，分別對應到哪些時相。

這樣給定兩個路口，只要拉一條箭頭，就可以依據道路的方向，推導出這條箭頭兩端各要用哪個時相。

這個設計帶來的好處是，上傳一個路口的設定，不需要知道周遭路口的任何資訊。只要上傳完畢後，再把周遭的箭頭連起來就好。而且還能夠用不同的觀察者時刻來推導出當前的連鎖要用哪一個時相設定。

也就是說，我們把一個路網建模問題，拆解成每個路口獨立建模，後續再對照地圖，把相鄰路口有路段的部分連起來，就能夠在短時間建起大片路網。

2. 要怎麼剖析 5000 份路口的設定？

台中有超過 5000 個路口(還沒算上公路局的路口)由交通局管理，也就是有 5000 份路口的設定 Word 檔。同時有分市區與舊縣區。

我一開始先處理環內市區的路口，因為這是最多人潮的路口，等到確定建模穩定不會有太大調整了，才處理縣區的路口。

我一開始以為可以單純的全部丟給 LLM 剖析就好，反正有訂閱額度沒有關係。結果跑一下下，5-hour limit 額度就被吃光了。

研究之後得出的結論是：

1. 沒有辦法用比 Anthropic Opus / OpenAI sol 更差的模型，讀出的內容有可能出錯
2. 一份一份 doc 讀取消耗 token 的數量極快，如果用 20 美金的方案，一個 5-hour window 大概讀取 20–40 份就吃光了。200 美金的方案也就是增加到 100–200 份，而且一旦碰到 weekly limit，接下來幾天就什麼事都做不了

後來重新評估程式化剖析的可行性，一開始本來以為 Word 資料會非常亂，需要全部靠 LLM 處理。但研究結果是寫一個程式來讀表格，就能有把握地讀完 86% 的文件，拿去跟模型讀出來的結果逐格比對，98% 完全一致，所以後來的流程變成：規則的部分交給程式，程式沒把握的才再交給模型。

再來是，真實世界的資料並不是完美正規化的，一定會有各種問題。偶爾會出現文件錯誤、設定前後矛盾。模型很聰明，會默默幫你把矛盾「修好」；但程式只會照實讀出來。我們需要選擇照實抄：文件印什麼就存什麼，矛盾的地方標成「時制異常」，讓承辦人員重新修正。因為這些矛盾可能代表現場的設定跟紙上寫的不一樣。這些矛盾的設定大概佔了資料的 5% 左右，我已經全部提交給台中市政府交通局來改善。

具體改善

1. 修正了 249 個路口（截至 10 月中）

到 10 月中，交通局的同仁已經修正過 249 個路口的時制，分成兩種：

• 文件修正：時制計畫表本身有矛盾，要到現場確認實際的設定再更新回文件。249 個裡大部分屬於這種。
• 時制調整：承辦人在地圖上看到某段路連鎖不好，重新配時或調整時差，一共 42 個路口，已經部署到路上的號誌控制器了。

2. 連鎖可視化提升了一倍每週調整路口的數量

以前要調整一段路的時差，承辦人需要打開附近相關路口的 Word 設定，開始手算連鎖性。很多路口的問題其實被隱藏在 Word 文件之內，難以發現。現在所有號誌設定全部呈現在地圖上，一眼就能看出哪些區域的紅綠燈設計可以調整，承辦人員也可以把心力投注在真正需要留意的區域。

原本平均交通局一週會約莫會調整 20 個路口，在有了這套系統後，上升到一週調整 40 個左右的路口。局內在複核審查路口的變更時，也可以直接在系統上觀測 before / after，大大節約了時間。

但比較不好意思的就是跑現場的維修隊工作量也增加了一倍，AI 開發軟體帶來的影響就這樣蔓延到物理世界了。

結語

整個專案的開發時間不到一個月，用 Claude Max 200 美金方案開發，雛形大約花了一週，大部分的時間花在剖析資料、討論需求和對領域建模，根據使用者意見調整 UI。使用 GitHub issue 開票切票，目前實作超過 300 張 issues。

同時這也是我近期第三個與 AI 深度協作開發的專案，有兩個心得：

1. 用 ccusage 估算，這個月燒掉了等價 8000 美金的 token，訂閱制省下非常多錢。方法上，全程用 mattpocock 的 skills 開發，多個 issue 各開一個 worktree 並行，開發效率才拉得上去；驗收則交給獨立 context 的 agent，分功能與品質兩個維度檢查，才能真的抓到問題。

2. 「決定不做什麼」和「做什麼」一樣重要。如果做一個功能很便宜，使用者會要求 100 個功能，有些是有道理的，有些則不適合現在做。我曾經嘗試過放手直接讓交通承辦人直接和 AI 對話做他要的功能，這樣他就可以自己開發，我就不用和 AI 對話，但發現不行，用戶很容易會添加對未來造成維護困難的功能。資深工程師的價值在於判斷什麼先不做。

如果您對這個專案有興趣，歡迎寄信給我或在文章下方留言討論。

另外，我也正在尋找下一份工作。我是一位九年經驗的資深工程師，主要做全端開發，參與過多種領域的專案，從線上平台的金流到去中心化交易所的交易系統都有。我擅長和第一線的使用者釐清需求，把系統落地上線、做出真的能影響真實用戶的產品。如果您的團隊在解決高價值或有趣的問題，歡迎透過 Email 或 LinkedIn 聯繫我。

最後附上兩張系統截圖：全市的號誌路口分布，以及單一路口的時制計畫編輯頁。