作品
案例研究與進行中的研究主軸——談「做什麼」與「為什麼」，不涉及專有的「怎麼做」。
案例研究
問題、限制、原則、成果與經驗教訓。
01
平台架構
一套 SaaS 平台核心，圍繞清晰的用戶端、BFF、領域、身分、通知與整合邊界設計。
架構視角
system.map許多 SaaS 產品在產品團隊能自信而快速地推進之前，需要一套可延續的用戶、認證、授權、通知與整合基礎。
難點在於平衡小團隊的營運模式與架構選擇，同時仍能支撐清晰的邊界、未來的協定演進，以及可靠的驗證。
把商業規則留在領域層、用 BFF 塑造用戶端體驗、記錄架構決策，並設計能從簡單協定演進到更強內部契約的整合路徑。
一套平台基礎，具備文件化架構、營運手冊、手動驗證流程，以及服務間通訊的演進路徑。
平台架構不只是服務拆解，而是一門讓邊界、營運與未來變更對人與 AI 協作工作流都清晰可讀的學問。
02
設計系統架構
一套主題驅動的設計系統架構，服務於可重複使用的 SaaS 介面、生成式版面，以及可辯護的企業 UI 組合。
架構視角
system.map產品團隊常在儀表板、工作區、生成頁面與客製體驗之間重複做出 UI 決策，使品牌調適與版面可靠性隨時間變得昂貴。
困難之處在於把品牌資料與 UI 機制分離，同時讓元件在密度、主題、版面、內容長度與響應式邊界情況下都保持韌性。
把機制與品牌資料分離、讓元件綁定語意設計契約、把版面韌性納入系統，並把複合元件當作產品基礎設施而非孤立的小工具。
一套架構，涵蓋主題引擎、語意 Token 層、版面系統、防禦性 UI 規則，以及企業級的複合元件模式。
一套認真的設計系統不只是元件庫，而是品牌、版面、無障礙、資料密度與產品演進之間的一份執行環境契約。
03
AI 協作工程工作流
一套規劃系統，把白話的產品意圖轉譯為結構化工程規格、分階段行動計畫，以及可審查的交付限制。
架構視角
system.map產品構想往往在意圖、技術限制、驗收標準與工程治理被明確化之前，就進入了實作。
難點在於讓 AI 產出的規格對非技術利害關係人與工程師都有用，同時不洩漏敏感的內部流程細節。
保存用戶意圖、把需求轉譯為工程概念、讓限制可見、把規劃與執行分離，並讓人為審查 AI 產出的產物負責。
一套產品設計，用於產生可編輯的規格產物、技術轉譯表、分階段實作計畫、可匯出文件，以及可追溯的規則版本脈絡。
當系統在請代理實作之前，先產出結構化的意圖、限制與驗收標準時，AI 協作工程會更有價值。
研究主軸
橫跨 AI 原生工程、治理、脈絡、執行環境系統與相鄰決策系統的長期問題。
2025 - 至今
進行中
研究 AI 協作的工程環境應如何保存延續性、讓自主性可被觀測，並支援從不確定性中負責任地復原。
在 AI 代理能安全參與長時間工程工作之前，其周圍必須存在什麼？
根本的設計挑戰是延續性與問責，而非單純的自主性。
2024 - 至今
進行中
探索工程脈絡如何在長時間工作中維持有用、可信與可延續，同時保護敏感的實作選擇。
工程脈絡應如何在不揭露敏感機制的前提下，跨工作階段、系統與決策維持有用？
脈絡品質取決於刻意的結構、更新的紀律，以及人可讀的邊界。
2026
草擬中
為 AI 協作工程設計治理模型，讓決策、限制與審批維持可見且可執行。
團隊如何在提升 AI 協作自主性的同時，仍保有審查、風險管理與歸屬？
當治理是工程系統的一部分，而非事後外掛的獨立審批層時，效果最好。