聯電的工程參數 AI 應用，從輸入需求到產生建議的完整流程是什麼？
希望了解 AI 如何讀取產品規格、試作要求與製程條件，最後產出工程人員可以採用的參數建議。
情境例子：新 IC 要進行工程開發試作，工程師輸入產品規格與限制條件後，Agent 如何比對歷史案例並形成整套參數條件？
建議追問
- 輸入是自然語言、表單、規格文件，還是混合方式？
- AI 產生建議，還是從規則庫與歷史資料組合？
- 工程師在流程中如何覆核、修改與採用？
這次交流要問的核心
不是只問「聯電用了哪一個 AI 工具」，而是要理解：企業如何把一個實際工作場景，設計成具備資料來源、專業規則、Agent 任務、驗證機制與持續改善的 AI 應用系統。
AI 的價值，不在於能不能回答問題，而在於能不能可靠地協助企業完成工作。
使用方式
- 先用上方「12 題關鍵字」快速跳到指定問題。
- 每題先看「提問」，再用「情境例子」說明為何要問。
- 需要深入時，展開「建議追問」。
企業 AI 應用的完整思考流程
交流時可沿著這條線索追問01 找場景哪一個工作值得改善？
02 接資料ERP、MES、QMS、文件如何串起來？
03 建知識規則與專家經驗如何形成？
04 做判斷Agent 如何查詢、分析、建議？
05 驗證如何知道結果可靠？
06 持續改善錯誤如何追蹤、修正、迭代？
12 個核心交流問題
顯示 12 題AI／Agent 提出的參數建議，企業如何驗證可信度？
重點不是 AI 能否給答案，而是企業如何判斷答案是否能進入正式工程流程。
情境例子：AI 建議的溫度、壓力或製程條件與資深工程師經驗不同時，系統如何決定要採用哪一個？
建議追問
- 是否使用規則檢核、模擬驗證、歷史成功率或工程師覆核？
- AI 建議、人工修改及最終採用結果是否留存？
- 曾發生錯誤建議時，如何追蹤與改善？
新產品試作過程中的零散經驗，如何整理成後續量產可用的知識？
試作過程常有大量臨時判斷、修改紀錄與異常處理經驗，如何避免試作結束後知識消失？
情境例子：某批試作出現良率異常，工程師調整設備條件後成功，但經驗只留在聊天訊息或個人筆記；如何轉成下一次量產可搜尋、可引用的知識？
建議追問
- 哪些資料要保留：原始條件、異常現象、調整動作、結果或判斷理由？
- 如何區分可複製規則與只適用於單一案例的特殊處置？
- 知識入庫前由誰確認有效？
老師傅經驗、工程判斷與內隱技能，如何轉成 AI 可使用的資料或規則？
企業最有價值的知識，往往不是標準文件，而是「看現象就知道問題在哪裡」的判斷能力。
情境例子：老師傅看到設備聲音、產品外觀或曲線變化，就知道可能要調整哪個條件；這種手感能否用照片、影片、感測數據、訪談或案例紀錄轉化？
建議追問
- 實務上會先用訪談、影像、操作紀錄、案例回放還是標註資料整理？
- 如何確認這是可驗證的專業經驗，而非個人習慣？
- 難以寫成規則時，如何變成 AI 輔助判斷的資料？
Agent 要怎麼接上 ERP、MES、QMS、文件與歷史案例等企業資料？
Agent 若只會讀文件或聊天，價值有限；真正的企業應用必須理解跨系統資料的關係。
情境例子：要分析一張訂單的交期風險，Agent 可能需要同時查訂單、製程進度、設備狀態、品質異常、客訴與試作紀錄。
建議追問
- 實務上是直接查 ERP／MES，還是透過 API、資料倉儲、中介資料層或知識庫？
- Agent 如何理解訂單、製程、設備、品質與客訴之間的關聯？
- 資料分散在不同系統與文件時，如何設計搜尋與引用優先序？
規則引擎如何設計、測試，並避免規則衝突或錯誤建議？
規則一多，就會出現條件重疊、優先順序不明與例外狀況，必須建立可靠的管理機制。
情境例子：規則 A 建議提高溫度，規則 B 因材料限制要求降低溫度；系統如何判斷哪一條優先，並說明衝突原因？
建議追問
- 如何設計規則層級、優先順序與例外處理？
- 如何用歷史案例、模擬資料與邊界條件測試規則？
- 如何建立「專家規則 → 系統判斷 → 測試驗證 → 上線 → 維護」流程？
面對企業機密、資料權限與 AI 幻覺，實務上如何設計控管機制？
企業導入 AI 必須同時兼顧效能、正確性、機密保護與責任可追溯性。
情境例子：同一份製程資料，工程師、業務、供應商與主管能看到的範圍不同；Agent 如何依身分限制回答內容？
建議追問
- 如何讓 AI 只引用企業內部確認過的資料並附上來源？
- 哪些情況可以自動處理，哪些情況必須人工覆核或異常升級？
- AI 輸出品質如何評估、校正與重新訓練？
第一版 AI／Agent 上線後，企業如何持續維護與迭代？
真正的挑戰通常從上線後開始：規則會變、資料會變、流程會變，Agent 也可能逐漸失準。
情境例子：製程規格更新後，舊規則仍被 Agent 引用，導致建議過時；企業如何發現、停用、更新並驗證這條規則？
建議追問
- 運作過程會自動迭代規則嗎？哪些內容禁止自動修改？
- 模型、提示詞、知識庫與規則是否有版本管理？
- 所謂 Agent 記憶是否永久有效？如何處理 context 限制與過期資訊？
聯電的 AI 專案團隊如何組成與分工？
希望理解大型企業如何讓 IT、現場、資料與管理者共同推動 AI，而不是由單一部門獨自承擔。
情境例子：工程師最懂問題、IT 最懂系統、資料科學家最懂模型、流程專家最懂改善；誰負責定義需求、驗證結果與承擔上線責任？
建議追問
- IT、現場工程師、資料科學家、流程專家與管理者如何分工？
- 如何讓現場人員願意提供知識與資料？
- 如何避免 PoC 成功後，沒有人負責正式維運？
企業應用中，有沒有必要設計多個 Agent 分工？
需要判斷多 Agent 是解決實際複雜度，還是只是增加架構與管理成本。
情境例子：資料查詢 Agent 找資料、異常分析 Agent 判斷原因、報告 Agent 整理結果、決策建議 Agent 提出處置；彼此如何協作？
建議追問
- 實務上是單一 Agent 處理全部任務，還是多 Agent 分工？
- 是否需要主控 Agent 負責派工與彙整？
- 如何避免重複查詢、互相矛盾或責任不清？多 Agent 目前是實用還是偏實驗？
Agent 不是傳統系統，企業通常如何設計測試方式？
Agent 的輸出可能具有變動性，不能只用傳統系統的固定輸入／固定輸出方式測試。
情境例子：同一個交期風險問題，Agent 兩次回答措辭不同；只要結論、依據與行動正確，就算通過嗎？企業如何定義標準？
建議追問
- 測試案例來自真實歷史案例、模擬問題，還是現場人員設計的題目？
- 是否評估回答正確率、引用來源、工具成功率、任務完成率與人工介入次數？
- 品質、製程參數、交期承諾等高風險場景，測試門檻是否不同？
Agent 應該放在哪個使用入口，才最容易被現場人員採用？
再好的 Agent，如果離現場工作太遠，最後可能只剩展示用途。
情境例子：員工平常都在 ERP、MES 或 Excel 工作，若還要另外打開一個 AI 平台，使用率可能很低；Agent 是否應嵌入原有工作環境？
建議追問
- 應放在企業入口網站、ERP／MES、Teams／LINE／Slack，還是獨立平台？
- 回答後能否直接建立工單、通知主管、產生報表或更新紀錄？
- 哪種整合方式最容易讓現場人員真的使用？
交流時要特別確認的治理檢核
避免只看到展示效果資料可追溯每個重要建議是否能回到來源資料、歷史案例或規則依據？
責任可界定哪些決策由 Agent 輔助，哪些必須由人員核准？
錯誤可診斷失敗時能否判斷是資料、規則、模型、提示詞或工具流程問題？
規則可管理規則是否具備版本、審核、測試、上線與退版機制？
成效可衡量是否能用週期、良率、重工、工時或決策品質衡量價值？
現場用得起來Agent 是否嵌入原有工作流程，而不是增加另一個孤立工具？
川海希望從交流帶回來的能力
轉化為協助客戶 AI 轉型的方法- 找出值得 AI 化的工作：從流程痛點、決策瓶頸與知識斷層，而不是從工具出發。
- 盤點企業知識與資料：把 ERP、MES、QMS、文件、案例與專家經驗放進同一個工作脈絡理解。
- 設計可驗證的 Agent：讓每個建議都有來源、規則、人工覆核與責任邊界。
- 建立持續改善機制：把錯誤、例外與人工修正轉成系統優化的輸入。
- 衡量質變價值：從省時間進一步走向縮短開發週期、提升良率、加速知識傳承與改善決策品質。