01既有系統規模
關於弋揚科技
弋揚科技成立於 2004 年 於 2008 年推出車隊管理品牌「衛星犬（EUP）」 目前為台灣市佔率第一的車隊管理系統服務商，服務遍及全球
2004
成立
180
人
25,000+
家企業
250,000+
台車輛
產品線涵蓋衛星車隊管理系統（FMS）、運輸管理系統（TMS）、樂圾通，以及各類專案運輸管理系統 車載裝置為自製，包含 GPS Tracker、BLE Gateway、感測器與 AI 行車記錄器 從多套管理系統到自製車載裝置，提供車隊管理整體解決方案
導入訪談
Ian弋揚科技工程處副總
×
水球潘水球軟體學院執行長
這場訪談回顧導入 AI x BDD 前後的變化：開發時間、PM 與 RD 的合作，以及對團隊文化的正面影響。
訪談主題與時間點
0:00開場：介紹 Ian 與合作背景
0:27弋揚科技：車隊管理系統與開發挑戰
1:00從 Cursor、Claude Code 到遇見水球軟體學院
2:27決定合作的轉機：BDD 真的能結合 AI 嗎？
3:09導入前：一個人月、人月神話與 Vibe Coding 的坑
4:54導入 AI x BDD 後：從一個月縮短到一個多禮拜
6:14對公司的實質改變：Spec by Example 與 GWT
7:20招募與團隊文化的化學變化
8:08老闆的支持：工具與經費
8:55數據回顧：476 份 Feature Files、8,000 多個測試案例
9:38什麼樣的企業不適合導入 AI x BDD
10:54給企業負責人的建議：為什麼推薦水球軟體學院
導入成果
本次導入合作包含三種服務
線上課程
＋
企業內訓
＋
四個月技術專案導入服務
導入後，AI 開發效率大幅提升
同一個複雜功能模組，從需求規劃到功能上線
這是團隊剛學會這套方法時做出的成果 從需求規劃到功能上線，只花一個多禮拜 前三天用來和 PM 討論需求、寫可執行規格、產測試；OneShot 開發約兩到三天
AI x BDD × Skill-engineering
用可執行規格，讓 AI 自我驗證
把「想驗收的系統行為」寫成可執行規格，讓 AI 拿它自我驗證。
想驗收的系統行為
可執行規格
AI 自我驗證
476
份 BDD Feature Files（可執行規格）
5,025→8,000+
份測試案例。水球軟體學院團隊協助導入結束時 5,025 份，弋揚後續自行成長到 8,000 份以上，持續做回歸測試。
462
個 API 的功能正確性，由這批回歸測試保證
導入結束後，測試案例仍持續成長，用來做回歸測試，保證 API 的功能正確性。
導入前，弋揚遇到的開發問題
這些問題，讓弋揚決定導入 AI x BDD，加快開發速度並提升穩定性。
02角色溝通
需求橫跨業務、PM 與 RD，傳遞過程容易產生理解落差
03產品相依
軟體與硬體彼此相依，任何變更都可能牽動兩端
04原有系統整合
與現有 ERP 系統整合複雜，系統、資料與流程都必須正確對接
傳統開發太慢，直接讓 AI 寫又難以維護和控制品質
每個工程師都有自己的一套方法
即使試著建立規範，要改變每個人的工作習慣仍有難度。
規格傳到 RD 手上，中間有落差
PM 寫出的文件需要 RD 自行解讀，容易形成溝通上的 Gap。
直接讓 AI 寫
AI 可能改 A 壞 B，很難收斂，也難以維護和控制品質；最後甚至可能比工程師自己寫還慢。
團隊真實變化
PM 與工程師發展新的合作文化
規格成了團隊的共同語言之後，角色不再被職稱框住：PM 追得進開發情境，工程師看得懂需求全貌。團隊也開始建立新時代軟體開發的合作方式。
職缺與時俱進
方法論在團隊裡普及之後，弋揚招工程師不再切前端、後端，直接開出「AI Agent 工程師」。開發流程升級，職缺與人才需求也相應變化。
求職市場正面訊號
JD 不只寫「AI 開發」，也清楚列出團隊採用的方法論與工作方式。求職者能從外部看見弋揚正在推動的開發轉變，也更容易吸引認同這套方法的人才加入。
公司對 AI 開發更具信心
模糊地帶被壓低之後，AI 的產出變得可驗收、可控。即使未來模型持續演變，團隊也能更具適應性。
AI x BDD，成為弋揚招募人才的工作條件
弋揚開始招募「AI Agent 開發工程師」 並把 AI x BDD、BDD / TDD 與 Gherkin 直接寫進工作職責與加分條件
工作職責
「設計與開發 AI Agent 系統，運用 AI 輔助開發方法論（如 AIxBDD、GSD、gstack、speck-kit 等）加速公司後端與前端系統的開發流程，實現從需求到程式碼的自動化與智慧化」
加分條件
「有 BDD / TDD 開發經驗，了解 Gherkin 語法與行為驅動測試」
職缺清楚寫出團隊怎麼用 AI 開發。求職者看到的不只是「AI」兩個字，而是一家公司已經形成的開發方式。
節錄自弋揚科技「AI Agent 開發工程師」職缺。
查看弋揚科技目前職缺學習成效
PM 與 RD 從不同角色出發：PM 把關「標準」，RD 用「測試」驅動「開發」。兩者共同為組織留下一套能持續用在開發上的可執行規格與測試。
PM｜把關「標準」
- 更快速地設計新功能雛形
- 大幅減少 RD 因需求誤解造成的返工
- 留下能交接與持續使用的流程規格
RD｜用「測試」驅動「開發」
- 用測試驅動 AI 開發
- 降低「改 A 壞 B」的情況
- 讓團隊能專注在新功能開發
參與軟體工程變革，從增加知識與底氣開始
《AI x BDD：規格驅動全自動開發術》
企業團購
5 人以上享企業折扣
想把 AI x BDD 帶進團隊的開發流程？加入 LINE，和我們討論適合你們的課程與團購方案。
加入 LINE 洽詢《軟體設計模式精通之旅》
企業團購
5 人以上享獨立 Code Review 教練批改時間
想讓團隊建立共同的軟體設計語言與 Code Review 方法？加入 LINE，了解企業團購與教練批改安排。
加入 LINE 洽詢或填表告訴我們你的團隊需求
選擇想了解的服務並留下聯絡方式，我們會與你聯繫。