三位企業團隊成員共同檢視規格與測試結果的情境插畫

AI x BDD 企業導入實績|弋揚科技股份有限公司

弋揚科技整合 PM、RD 與測試
全面升級開發流程

過去一個複雜模組,光後端開發就要一個月 導入 AI x BDD 後,從需求規劃到功能上線,只花一個多禮拜 縮短的不只是開發時間,PM 與 RD 的合作方式也跟著改變。

關於弋揚科技

弋揚科技成立於 2004 年 於 2008 年推出車隊管理品牌「衛星犬(EUP)」 目前為台灣市佔率第一的車隊管理系統服務商,服務遍及全球

2004
成立
180
25,000+
家企業
250,000+
台車輛

產品線涵蓋衛星車隊管理系統(FMS)運輸管理系統(TMS)、樂圾通,以及各類專案運輸管理系統 車載裝置為自製,包含 GPS TrackerBLE Gateway、感測器與 AI 行車記錄器 從多套管理系統到自製車載裝置,提供車隊管理整體解決方案

導入成果

本次導入合作包含三種服務

線上課程
企業內訓
四個月技術專案導入服務

導入後,AI 開發效率大幅提升

同一個複雜功能模組,從需求規劃到功能上線

導入前傳統開發
一個月(光後端)
導入後AI x BDD
一個多禮拜(前後端)

這是團隊剛學會這套方法時做出的成果 從需求規劃到功能上線,只花一個多禮拜 前三天用來和 PM 討論需求、寫可執行規格、產測試;OneShot 開發約兩到三天

AI x BDD × Skill-engineering

可執行規格,讓 AI 自我驗證

把「想驗收的系統行為」寫成可執行規格,讓 AI 拿它自我驗證。

想驗收的系統行為
可執行規格
AI 自我驗證
476
份 BDD Feature Files(可執行規格)
5,0258,000+
份測試案例。水球軟體學院團隊協助導入結束時 5,025 份,弋揚後續自行成長到 8,000 份以上,持續做回歸測試。
462
個 API 的功能正確性,由這批回歸測試保證

導入結束後,測試案例仍持續成長,用來做回歸測試,保證 API 的功能正確性。

導入前,弋揚遇到的開發問題

這些問題,讓弋揚決定導入 AI x BDD,加快開發速度並提升穩定性。

大量程式模組與相依關係形成難以拆解的結

數十萬行程式碼、數百項功能,重構成本高到決定整套重寫

需求在不同角色之間傳遞時發生中斷與落差

需求橫跨業務、PM 與 RD,傳遞過程容易產生理解落差

軟體與硬體之間具有彼此牽動的相依關係

軟體與硬體彼此相依,任何變更都可能牽動兩端

兩套系統的資料與介面格式無法直接對接

與現有 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 BDDBDD / TDDGherkin 直接寫進工作職責與加分條件

工作職責

「設計與開發 AI Agent 系統,運用 AI 輔助開發方法論(如 AIxBDD、GSD、gstack、speck-kit 等)加速公司後端與前端系統的開發流程,實現從需求到程式碼的自動化與智慧化」

加分條件

「有 BDD / TDD 開發經驗,了解 Gherkin 語法與行為驅動測試」

職缺清楚寫出團隊怎麼用 AI 開發。求職者看到的不只是「AI」兩個字,而是一家公司已經形成的開發方式。

節錄自弋揚科技「AI Agent 開發工程師」職缺。

查看弋揚科技目前職缺

學習成效

PM 與 RD 從不同角色出發:PM 把關「標準」,RD 用「測試」驅動「開發」。兩者共同為組織留下一套能持續用在開發上的可執行規格與測試。

PM 建立流程與 Gherkin 測試計畫,RD 接續 API 規格、前後端測試與測試驅動開發的完整流程
PM 負責把關「標準」,RD 用「測試」驅動「開發」。

PM|把關「標準」

  • 更快速地設計新功能雛形
  • 大幅減少 RD 因需求誤解造成的返工
  • 留下能交接與持續使用的流程規格

RD|用「測試」驅動「開發」

  • 用測試驅動 AI 開發
  • 降低「改 A 壞 B」的情況
  • 讓團隊能專注在新功能開發

參與軟體工程變革,從增加知識與底氣開始

或填表告訴我們你的團隊需求

選擇想了解的服務並留下聯絡方式,我們會與你聯繫。

想了解的服務 *

感謝您的來信,我們已收到您的需求,將在 1–2 個工作天內與您聯繫。