2026年3月26日3 分鐘閱讀
你會讓同一個工程師自己寫、自己測、自己 review 再自己上線嗎？
Anthropic 的新文章讓我更確定，AI agent 也需要分工。很多人類團隊踩過的坑，AI 會重新踩一次。
AI Team DesignAgent ArchitectureCTOWorkflow
Read ArticleDeep Tech & Advisory
PurismEV
在 PurismEV 主要協助技術發展、產品規劃與方向的探討
這段合作裡，我比較像技術顧問加上一點研發協作。主要在方向策略、商業模式、技術能估上幫忙，也有參與 IoT 裝置核心演算法與 AI 電池節能相關研究。
2024-至今Smart Mobility / AI Powertrain / IoT Systems
Smart MobilityAI PowertrainIoT SystemsEnergy OptimizationTechnical Advisory
TY Wang2025年6月14日最後更新: 2026年3月11日
智慧載具系統顧問案例
Role
技術顧問 / 策略、能估與演算法研發協作
Client
PurismEV
Industry
Smart Mobility / AI Powertrain / IoT Systems
Outcome
幫團隊把節能控制、智慧充電與 IoT / AI 研發整理成比較清楚、也比較能往前推的產品方向。
Strategy + R&D
我參與像是以資深產品人的角度，協助讓產品順利落地
PurismEV 對外講的是 IEMS、AI powertrain、AIoT。我參與的部分，主要是策略、商業模式、技術能估，以及一部分核心演算法工作。不是整個產品都我做，但剛好有機會在幾個關鍵點上幫忙。
Vehicle Prototype
很多想法，一上車就知道哪個是真的
這也是這類題目有趣的地方。簡報上都很合理，但進到真實載具、電池、電控之後，優先順序常常得重排。
公開測試效率改善
40%+
EV 平台驗證
10+
商業路徑
OEM + Fleet
Case Study Summary
先看這個案例的核心重點
>PurismEV 展現的是我如何在智慧載具與節能系統裡扮演高密度技術顧問，而不只是產品 owner。
>這個案例適合看複雜硬體、車載系統與資料層之間如何拆解問題。
>它的價值在於深科技研發判斷與產品化節奏，而不是單一功能成果。
這個案例適合誰看
>智慧載具、AIoT 與節能系統決策者
>需要高密度技術顧問拆解複雜問題的人
>想看深科技題目如何產品化的人
核心成果
>協助釐清車載、車隊與能源管理相關系統架構
>在多模組、多資料流環境中建立較清楚的產品分層
>讓研發判斷更貼近可執行的商業化節奏
關鍵限制
>硬體、車載控制與資料服務層之間的邊界容易混淆
>深科技題目常受限於供應鏈與驗證時間
>產品化節奏往往比純軟體慢很多
可複製方法
>先拆清模組責任，再談整體系統路線
>用資料流與操作情境界定產品層次
>把顧問角色做成可執行的決策框架，而不是抽象建議
FAQ
常見 問題
Problem
Problem
方向不是沒有，方向太多。真正難的是先做哪個。
先講結論：這個題目難的，不是沒有方向，而是可以做的方向太多。
電池、馬達、throttle control、IoT data、fleet management，每一個看起來都合理。問題是，新創資源有限，不可能全部同時往前推。怎麼取捨、怎麼排優先順序，才是最難的地方。
首先我們很明確的知道，電動載具是未來巨大的趨勢，但是目前相關廠商在這方面的研究，很少在電池跟載具的優化上，做得很好。
但最難的又是，要怎麼證明給他們看，你的目前的狀況距離優化標準還很遠，可以透過我們的技術，推進到一個更好的狀態，這中間是需要很多溝通跟實驗數據的證明。
Solution
Solution
我做的比較像一起判斷，不是一次把所有東西都往前推。
我在這段合作裡，比較像是一起判斷的人，不是主導整個產品的人。主要在三件事上幫忙：
-
#方向策略 幫團隊一起討論現在重點在哪裡。了解目前產品的優勢跟客戶的痛點，不管是往 IEMS、AI powertrain、AIoT 這種方向，都有著重的功能方向。
-
#商業模式 一起釐清 OEM 端的整合路徑，和 fleet 端如果要做成 service，大概應該怎麼切。了解目前有哪些相關的國外競品，大家發展的方向跟我們可以努力的目標。
-
#技術能估 幫忙看節能控制、智慧充電、SOC / SOH、續航估算、資料蒐集這些題目，在技術上的可行性，哪些部分是關鍵點，協助討論並且解決問題。我也有參與 IoT 裝置核心演算法，以及 AI 電池節能相關研究。
Execution
Execution
對外看得到的是產品圖和技術圖；我比較常做的，是把背後的技術和商業邊界先想清楚。
實際參與之後，我花最多時間的，是協助釐清產品與商業邏輯。
-
#vehicle-side 跟 cloud-side 怎麼分 這裡包含了資料蒐集、節能控制、電池健康估算、駕駛行為分析等等，當功能越來越多，需求越來越多，架構的設計與區分就很重要了。
-
#throttle control 跟效率區間怎麼看 我也從中學習了一些跟 throttle response、馬達效率區間、能耗曲線有關的設計討論和研究。這比較不像一次做出一個大 feature，而是慢慢把關鍵邏輯補齊，甚至找到最前沿的研究結果，繼續延伸下去。
-
#OEM 跟 fleet 要不要一起談 同時也會一起看，哪些能力比較適合做成 OEM 可整合的東西，哪些更適合留在 fleet 的 AIoT 平台上。
整套系統目前稱作 In-Vehicle Energy Management System。對我來說，這段過程之中，盡量協助把這些題目串成一條比較順的產品路線。
IEMS Architecture
IEMS 這件事，先別急著講大，先把路徑串起來
公開資料裡的 IEMS，從 data collection、driving pattern analysis、AI throttle optimization，一路接到 OEM 與 AIoT 兩邊。我當時協助的重點之一，就是把這條路徑梳理清楚。
AI Powertrain
throttle control 這題，關鍵其實很務實
不是把曲線畫漂亮就好，而是要看馬達效率區間、輸出反應和真實使用情境能不能對上。
Efficiency Comparison
數字不一定代表全部，但至少能幫忙判斷方向
這種比較表的價值，是讓團隊知道哪些策略是真的有幫助，不然很容易大家各自有感覺。
Impact
Impact
這案子對我來說，重要的不只是數字，而是方向有沒有慢慢站穩。
這段過程中產品越來貼近市場的需求，把原本很強的技術底子，逐漸轉換成市場能理解的產品過程。
目前來說，有幾件事是看得到的：
- 相關效率優化方案已在 10+ EV 平台 測試，也有特定情境下 40%+ 效率改善 的對外說明。
- 產品能力不只停在節能控制，也延伸到 SOC / SOH、續航估算、駕駛行為分析等能力。
- 從產品包裝來看，也慢慢分出 OEM integration 和 fleet subscription 這兩條不同路徑。
主要協助方向策略、商業模式與技術可行性估算。
也參與 IoT 裝置核心演算法與 AI 電池節能研究。
協助把 OEM 與 fleet 兩條產品路徑講得更清楚。
Commercial Model
另一塊我花比較多時間的，是別太早把不同產品混在一起
同一套技術可以講成 different stories，但 OEM 和 fleet 的買法、部署法、開發節奏真的差不少。先拆清楚，後面會省很多事。
>OEM：比較接近車端整合，會碰到 throttle control、VCU、motor / controller 與 battery-management 這些模組。
>Fleet：比較像 AIoT 平台服務，會延伸到 SOC / SOH、續航估算、駕駛行為分析與車況資訊。
>這兩條路徑可以共用核心技術，但產品包裝和銷售方式其實差很多。
Advisor Note
Lessons
❝ 如果先後順序沒想清楚，deep-tech 題目很容易做很多，但不一定越做越清楚。
deep-tech 題目，通常最難的都是怎麼把技術能力轉換成市場需求。
我通常都會先回到三個問題：
- 這件事做不做得出來？
- 做出來之後，要怎麼包成產品？
- 現在最該先做哪一段？
這三件事如果順序沒想清楚，團隊很容易很努力，但主線還是不夠清楚。反過來說，只要順序抓對了，很多原本看起來很硬的題目，其實也會慢慢變得可處理。
Contact
討論一個類似的 產業挑戰
幫團隊把節能控制、智慧充電與 IoT / AI 研發整理成比較清楚、也比較能往前推的產品方向。
Related Writing
與這個案例相關的 延伸文章
2026年3月26日4 分鐘閱讀
一個不寫 code 的人，為什麼能在 30 天內用 AI 產出 263 個 commits？
AI 把執行成本壓低之後，真正稀缺的變成規劃、判斷，以及知道該先做什麼。
AI CodingPlanningWorkflowCTO
Read Article