從星皓作業平台，走向可持續擴充的代理式人工智慧平台（Agentic AI Platform）

一、先把問題說清楚：星皓要解決的不是「缺一個畫面」

投影片 01提案的起點：把日常工作變成可追蹤的流程

這案子的目標，是整合工單、派工、工作日誌與行政表單，降低重複輸入，並建立一個可追溯、可控管、可擴充的公司資料平台。需求 PDF 的封面提供了規模背景：目前約 15 人，公司的第一階段擴充目標是支援 50 人；公司的主要業務是半導體設備的維修、保養、改造與裝移機。

因此提案的重點不是先列出一堆 AI 功能，而是先讓工作順序、資料來源與責任變得清楚。當每一筆工單、每一份日誌、每一個附件都有關聯，Agent 才有可靠的上下文可以協助人員。

投影片 02先核准共同底座，再核准星皓作業方案

第一件要確認的是共同底座：帳號、人員、權限、表單、檔案、操作紀錄、備份與版本。第二件是星皓作業方案：工單、派工、工作日誌、改造工程紀錄、驗收文件與行政表單。這兩層穩定後，才適合加上智慧協助。

投影片 03現況痛點是工具彼此接不起來

需求 PDF 描述了數個互相牽連的現況：Excel 檔案彼此沒有連結，檔案過大容易當機；工作日誌格式不一致，需要人工轉填出勤與薪資；TimeTree、BizForm 與 Email 表單各自保存資料，缺少一致的簽核與權限控管；員工離退後，歷史資料的原始身分也不容易保留。

這些問題的共同核心不是工具數量，而是資料沒有沿著工作流程流動。當同一個客戶、廠別、機台或員工在不同地方被重打，系統就無法判斷哪一份是最新；當附件與狀態沒有跟著案件走，接手者就只能重新詢問背景。

投影片 04-05四層責任與可擴充方向

投影片把方案分成四層來理解：共同基礎、星皓工作規則、智慧助理，以及主管把關。這個分層很重要，因為「Agent 可以協助產生規格」不代表「Agent 可以自行決定公司規則」；「系統能執行狀態轉換」也不代表「系統可以跳過核准」。

未來如果增加報價、訂單、財務、物料或其他產業作業，應沿用同一個平台底座，而不是再複製一套帳號、權限、流程與稽核。通用平台規劃建議將這個方向定義為：先完成 P0 平台底座，再完成 P0 的 Service Operations Pack，接著才進入 P1 Agentic 客製與 P2 其他領域套件。

投影片 06共同基礎是看不見、但最影響導入成敗的部分

共用基礎至少包括身份與組織、RBAC 權限、主檔、設定管理、表單與流程、關聯與搜尋、稽核與版本、檔案與文件、通知與首頁、匯入匯出、手機使用，以及備份、健康檢查與版本回復。這些能力不一定都是第一眼看到的畫面，卻決定現場敢不敢每天使用。

二、平台架構：把共用能力留在平台，把星皓規則放進領域套件

投影片 07六個工作面：先打通資料會反覆交接的地方

六個工作面是：共用主檔；工單與派工；工作日誌與機台履歷；改造工程與驗收文件；個人人事作業；首頁與管理。它們不是六個互不相干的功能，而是同一條營運鏈上的六個觀察角度。

投影片 08-09表單編碼與權限，是資料關聯的兩條骨架

試算表中的編碼規則包括：標準工單 WO-年月日-流水號、臨時工程 PWO-01-年月日-流水號、工作日誌 DR-年月日-流水號、請休假 LR-年月日流水號、差旅 TV-年月日流水號，另有報價單 Q-年月日流水號。正式格式仍需在需求確認時鎖定，投影片使用的是溝通版範例。

權限試算表不是單純的「有權限／沒權限」清單，而是以部門與職稱雙軸管理讀取、寫入、修改、匯出／匯入與核決，另以「限本人」等資料範圍限制可見內容。行政管理主管通常負責主檔與核決；工程服務主管負責派工、日誌與工程紀錄的審核；工程師以自己的派工與工作紀錄為主，同時可依規則閱讀歷史資料。正式製作前仍要逐張表單核准，不應把摘要當成最終 RBAC 設定。

投影片 10畫面設計的重點，是少填一次而且不失去控制

工單畫面先建立案件型態、工單單號、客戶、廠別、機台、案件名稱、工程需求、工程團隊與狀態；送出後，工作日誌可依派工帶入工單、客戶與廠別，工程師只補充現場時間、施工內容、異常、處理結果與後續事項。

「少填一次」不代表所有欄位都開放任意修改。例如工單單號應由系統產生，客戶與廠別應來自主檔，工作日誌的工單選擇應受派工團隊限制；送出後不能刪除，但可以用補充或更正留下新歷程。這是資料便利性與稽核可靠性之間的平衡。

投影片 11關係圖：從資料、表單、狀態到產出

關係圖要讓業主用一張圖回答四個問題：一開始有哪些資料？要填哪張表？案件目前走到哪裡？最後留下什麼？主檔資料接到 WO／PWO，工單再接到 DR，改造紀錄、HR 表單、驗收文件與附件則被共同的狀態、稽核、匯出與報表能力串起來。

狀態不應被畫成一條只有成功路徑的直線。來源中的正式狀態包括未派工、已派工、施工中、工程取消、工程暫停、已完工、待驗收與已結案；PDF 另提出待報價、待訂單與待請款等業務節點，實作時要把它們與例外分支、補件與退回原因一起確認。

投影片 12工單主鏈：從建立、派工、現場紀錄到結案

工單的價值在於它成為跨角色的共同編號。業務、主管、工程師、行政與後續財務不必各自創造一個案件識別方式，而是沿著同一個工單追蹤實際工作。報價與訂單目前屬後續階段，不能在第一階段被誤解成已承諾完成。

三、六大工作面怎麼落地：把每一個流程講成可驗收的工作

投影片 19主檔與權限先建立，後續表單才不會各填各的

主檔包含員工、客戶、業主與廠別；員工資料還有部門、職稱、直屬主管、在職狀態、到職日期與工安訓練資料。客戶資料包含客戶編號、名稱、簡稱、付款條件與工程類別；業主資料包含英文名稱、廠別與完整廠區識別。這些資料建立後，工單才有一致的下拉選單與關聯。

機台碼與機型在來源中主要出現在工單及工作日誌的欄位，通用平台規劃則建議把設備／機台納入可管理主檔。這是建議設計，正式導入時要再確認是否要獨立成機台主檔，以及歷史機台資料如何整理。

投影片 20工單與派工：狀態要能說明下一步，而不是只變色

工單包含案件型態、WO／PWO 編號、建立日期、報價單號與 PO、客戶與廠別、機台碼與機型、案件名稱、需求內容、聯絡窗口、工程負責人、派工團隊、預計施工日、物料需求、客戶文件需求、工單狀態、完工日期、驗收文件狀態、建立人與最後修改時間。標星號的必填欄位與下拉選單規則需在測試案例逐一驗證。

派工可多位、多次，試算表備註指出團隊成員可以異動；工程師只能從自己被派工的工單中選擇工作日誌的關聯案件。已完工工單應從可派工選單過濾，避免誤選；取消、暫停與改期則必須有原因與歷程。

投影片 21工作日誌：現場交接、機台履歷與計薪的共同資料

工作日誌的規則很具體：每位工程師每次出勤建立一筆；同一筆日誌可對應多個工單；送出後不能刪除，只能修改或補充，而且修正要保留內容與異動紀錄；最晚填寫時間是工作日隔天中午 12:00 前。日誌欄位包括工程師、課別、工作日期、工作時間、工單、客戶、廠別、機台、進出廠日期與時間、施工內容、異常、補充、更正事項、施工狀態、日誌狀態、送出時間、主管確認人與最後修改時間。

這份資料同時被三個下游工作使用：主管用它交接與確認；系統依機台碼累積機台履歷；行政以工作時間、進出廠時間、請假與加班資料作為出勤與計薪的輸入。投影片中的「計薪依據」是資料用途，不等於第一階段已完成完整薪資計算引擎。

投影片 22改造工程紀錄與驗收文件：取代零散表單，但不能丟掉歷史

需求文件要求以新的改造工程紀錄表取代原有 BizForm，並保留歷史資料可匯出 Excel 的能力；另需預留超過作業天期的說明欄位。導入不應把舊資料直接覆蓋進新欄位，而應先做欄位對照、格式檢查、錯誤列報告與匯入預覽，再決定哪些資料寫入。

新紀錄要能連回工單、工作日誌、附件與驗收狀態。驗收文件的語意也要固定：已完工代表現場作業完成，待驗收代表客戶未簽收或驗收單未回，已結案代表驗收文件已收回。缺件待補、退回與再次送出都要保留原因。

投影片 23HR 表單：先從申請、核准與查詢做起

個人人事範圍包括請休假、差旅、個人請款與薪資單查詢。請休假單需要假別、起訖日期時間、附件與年度特休資訊；差旅單需要日期、作業廠別、費用項目、憑證、金額、起訖地點與附件；請款單承接 BizForm 與 Excel 匯出統計。行政管理與工程服務主管依部門、職稱與表單權限進行多層核准。

薪資的第一階段應保持務實：既有做法是 Excel 計算後轉成 PDF，再以 Email 提供同仁；平台先提供依權限的歷史查詢與下載，並把工作日誌、請假、加班與請款資料整理成可交給既有計薪流程使用的資料。不要把「有薪資單查詢」講成「平台已完全取代薪資系統」。

投影片 24首頁與管理：不是重做資料，而是依角色集中呈現

首頁總覽包含公佈欄、活動與工安宣導附件、管理辦法連結、最近一週派工總覽、當月行事曆、個人頁面、待驗收數量與待辦事項。員工看到自己要完成的文件與申請；主管看到派工、待驗收與待核准；行政人員管理公告、附件、行事曆與整體查詢。

首頁的核心原則是「狀態集中、資料不複製」。它讀取各模組已經留下的狀態與權限結果，而不是再建立一套平行的工單或 HR 資料。

投影片 25後續報價、訂單、財務與物料：先畫接法，後做模組

需求 PDF 的 Phase 2 是報價管理與訂單管理，並要求能以第一階段工單系統編號串接；Phase 3 才是財務系統、領料系統、跨模組成本與分析。未來可以形成「報價 → 訂單 → 工單 → 物料／領料 → 驗收／請款 → 財務與成本分析」的鏈，但目前這張投影片是方向圖，不是第一階段功能承諾。

四、Agentic 客製：讓智慧協助加速交付，但不越過治理關卡

投影片 13新增智慧功能也要像專案一樣，一步一步確認

Agentic 的實際價值不是把一句自然語言直接變成正式功能，而是把需求澄清、規格整理、畫面草稿、流程定義、測試案例與操作說明串成可檢查的交付物。星皓提出「需要增加欄位、流程或表單」時，Agent 可以先產生需求草稿與規格，再由人員確認範圍，最後才進入測試與發布。

投影片 14業主、Agent、Tool 的責任不能混在一起

業主與主管決定目標、可使用的資料、可接受的風險與是否核准；Agent 協助整理資料、比較選項、產生規格與測試草稿；Tool 負責查詢、計算、格式轉換、狀態更新與留下紀錄。三者分開後，系統才可以回答「誰決定」「誰執行」「誰留下證據」。

例如 Agent 可以把「我要看到待驗收案件」轉成查詢條件與畫面草稿，但不應自行把所有案件改成已驗收；Tool 可以執行已核准的狀態轉換，但應在權限、輸入格式、冪等與稽核都通過時才執行。

投影片 15安全邊界：預設拒絕、最小權限、人工核准

平台的安全基線採 deny by default。Agent 不應讀取未授權的正式資料、密碼或 secrets；不應直接修改正式資料、寄信、付款、交易或用印；不應跳過測試、偷偷變更資料結構或繞過主管核准。任何高風險操作都要明確請求權限、由人員確認，並寫入 audit。

這裡的「人工核准」不是把所有事情都交回人手，而是把不可逆、對外、涉及金錢、權限或正式資料的決定放在正確的治理節點。低風險的查詢、分類、格式轉換與測試可以自動化；高風險的正式寫入與外部副作用則需保留人員控制。

投影片 16從需求到上線，每一步都要有驗收成果

建議的交付循環是：需求確認 → 表單與流程設計 → 測試環境製作 → 星皓以實際案例試用 → 修正與驗收 → 核准上線 → 版本、備份與維護。每一步都要有可以打開來看的產物，例如需求清單、欄位表、權限矩陣、流程圖、測試案例、缺陷清單、驗收紀錄、版本 manifest 與回復 runbook。

agentic-platform 原始碼的 DeliveryService 也採相同邏輯：先保存 requirement 與 specification，spec 核准後才 implement，接著跑 contract test 與 security pattern check，形成 release evidence，最後才 mount plugin；每次狀態轉移都寫入 audit。

投影片 17四階段導入：先讓資料可靠，再讓自動化變多

第一階段先確認規則、人員、權限、保存、手機、檔案與歷史資料；第二階段完成主檔、工單、派工、日誌、改造、驗收與首頁；第三階段加入請休假、差旅、請款、薪資查詢、公告、附件與報表；第四階段才評估 Agent 協助需求整理、外掛生成與測試檢查。這種順序讓自動化建立在已被業主確認的資料與流程上。

五、把流程變成可持續維護的平台

投影片 18-19流程總覽與主檔流程：每一筆資料都要回到共同能力

總覽流程可以用「建立資料與設定 → 接單與派工 → 現場紀錄 → 申請與核准 → 查詢與分析」理解。取消、改期、補件與退回不是例外到可以忽略，而是要有原因、操作者、時間與下一步的正式分支。

主檔流程先建立員工、客戶、業主、廠別、工程類型與必要的設備資訊，再建立角色與資料範圍，最後才開放工單、日誌、HR、驗收與公告。這樣做的目的，是讓表單能帶入已確認的資料，而不是每一張表都讓使用者重新輸入。

投影片 28工單、工作日誌、改造與 HR 的模組對照

投影片 25-27後續業務與模組清單：把「做什麼」對上「靠什麼支援」

第一組基礎模組是帳號與組織、權限、共用主檔、設定管理、表單與流程、資料關聯與搜尋；第二組是稽核與版本、檔案與文件、通知與首頁、匯入匯出與 Connector、手機使用，以及備份、健康檢查與發布回復。投影片最後的流程與模組矩陣，目的就是讓業主可以逐列確認：每個流程要填哪張表、資料從哪裡來、需要哪個平台能力、哪些屬於後續階段。

未來報價、訂單、物料、財務與成本分析要沿用唯一工單編號，並透過 ports and adapters 保留與外部系統交換的入口。平台核心不應直接依賴某一個財務系統、檔案服務或模型供應商。

六、安全、發布與維運：Agentic 能跑得快，也要能停得下來

平台與外掛契約

agentic-platform 的架構是 HTTP／CLI／未來 Connector 進入 application use cases，再進入 domain objects，最後透過 repository 與 service ports 連到 SQLite 或未來 adapter。domain 不直接依賴 HTTP、SQLite、模型 SDK 或供應商 connector。這讓星皓的工單規則不會被某個介面或模型綁死。

外掛應宣告 manifest、api version、capabilities、dashboard widgets、flows、schema、migration、events、commands、policies 與 tests。現階段核心只載入 manifest 與宣告的靜態資產，不直接執行任意第三方 Python；未來若要支援可執行 adapter，還要再加入簽章、資源限制與 approval-aware command bus。

發布、Hot-fix 與回復

一般功能可依 feature → develop → release → main 的流程推進，產生不可變版本 artifact，通過測試站驗收後再分批切換。若資料結構已變更，不能把「程式回復」誤當成「資料回復」；必須預先定義 migration checksum、備份點、forward-fix 或資料還原 runbook，並做實際還原演練。

每一版至少要有版本 manifest、變更摘要、相依套件清單、migration、rollback／forward-fix 說明、unit／p2p／security smoke 結果、健康檢查、備份點與操作者紀錄。這些不是行政文件，而是讓組織敢於持續修改系統的基礎。

資料安全與離職帳號

需求 PDF 要求離職帳號可即時停權、前端登入立即失效、歷史資料保留原使用者姓名；資料備份要定義頻率、保存週期、還原方式、加密與權限紀錄；資料要能依頁區與條件匯出，且資料與帳號歸公司所有。這些項目應寫進正式驗收條件，不要只停留在架構圖。

七、開始實作前的六個決策，以及建議的驗收方式

投影片 29六件必須先決定的事

每一階段的驗收問題

Phase 0 要能回答「平台是否可登入、可設定、可備份、可測試、可掛載外掛？」；Phase 1 要能回答「一件真實工單是否可以從建立走到日誌、驗收與結案？」；Phase 2 要能回答「星皓能否用自己的案例確認 Agent 產生的規格與外掛？」；Phase 3 要能回答「報價、訂單、財務、物料或其他領域是否能沿用相同契約？」

每個問題都要轉成測試案例。例如：離職帳號在目前 session 是否立即失效；工程師是否只能選自己的派工工單；日誌送出後是否禁止刪除；驗收文件缺件時是否能退回並留下原因；匯入錯誤是否先顯示錯誤列而非半套寫入；Agent 是否在沒有核准時被阻止進入 implement 或 release。

投影片 30建議核准內容

建議核准的不是「一次買下所有未來功能」，而是核准一個可追蹤的第一輪：確認需求範圍，定稿表單與權限，完成測試與星皓驗收，再安排正式使用。第一輪完成後，依實際使用結果決定下一階段，讓每一次投入都有可見的成果、風險與退場方式。

八、來源覆蓋與投影片複核結果

本次完整核對的檔案

已修正的投影片問題

仍需由星皓正式確認的項目

來源之間有些內容是「方向一致但細節尚未定稿」，不能在演講中講成已決定。例如：是否要獨立建立機台主檔；PWO 的流水號完整格式；工單狀態是否同時納入待報價、待訂單與待請款；附件大小、格式與保存期限；手機是否需要離線；歷史 Excel、BizForm 與 TimeTree 的實際匯入範圍；以及各 HR 表單的限本人、匯出與核決細節。

另外，試算表的「薪資單」「差旅申請單」及「圖示」工作表中存在 #VALUE! 儲存格。這些是來源檔本身的試算表內容問題，不能被當成平台需求或驗收結果；正式匯入前應先由業主整理、修正或明確標記。

複核結論

目前 30 張投影片與 30 段講者備註數量相符；投影片涵蓋星皓 PDF 的現況、三階段 roadmap、Phase 1 核心模組、表單與權限、非功能需求與供應商討論，也涵蓋通用平台規劃的架構、外掛契約、Agentic 客製、安全發布與分期驗收。這份長文則把每張投影片的口頭脈絡補齊，方便演講者不必只依賴投影片上的短句。