Lucid Guard
活躍開發中異常事故報告撰寫平台
專案背景
在實際的工作管理中，尤其是自從接任管理角色之後，就持續遇到各種異常事件需要處理。每一次事件發生，除了要即時排查問題、協調人力、追進度、對外回報，過程中還得不斷做判斷與決策；等事情告一段落，最後一定還會面對異常事件報告的撰寫。為的就是後續可以分析與歸納統計，找出問題的根源，並提出改進措施。
一開始在撰寫報告時，雖然對於異常事件報告有些許概念，但確不知道該寫到什麼程度、要包含哪些資訊，才能算的上一份好的報告。
後來才比較清楚，一份「至少不會被問一堆問題」的 Incident Report，大概需要包含這些內容：
- 問題是什麼
- 影響到哪些系統或使用者
- 真正的原因是什麼（Root Cause Analysis）
- 事情是怎麼一路發生的（Timeline）
- 當下做了哪些處理
- 之後要怎麼避免再發生
- 過程中有哪些關鍵決策
但實際做起來才發現，真正花時間的不是「寫」，而是整理。
事件發生時的資訊非常零散：聊天記錄、口頭交代、臨時決定、不同角色的觀點，全都混在一起。等事件處理完，人早就累到不行，卻還得把這些東西重新拼成一份結構完整、能被回顧的報告。
也正是在反覆處理這些異常事件的過程中，我開始認真思考：這件事一定只能這樣做嗎？，而且讓所有處理異常事件的人員，也可以簡單而有效率的產出報告(這也是他們的績效)。
隨著 AI 技術逐漸成熟，我發現它其實很適合用來處理這類工作——協助整理零散資訊、補齊報告結構、減少工程師在事後撰寫報告時的負擔。
但我同時也很清楚，不能什麼都丟給 AI。 所以在這個想法裡，我一直希望即使在沒有 AI 協助的情況下，也能有一份清楚的確認清單，讓實際處理異常的人知道：
- 當下哪些資訊一定要留下來
- 哪些決策點不能漏記
- 事後的報告應該要能回答哪些關鍵問題
這整個過程，並不是一開始就打算做成產品，而是單純源自於我在管理角色中，反覆被同一件事情困擾。
工程師在處理完緊急事件後，往往已經精疲力盡，很難再靜下心來整理一份高品質的事故報告。 Lucid Guard，就是在這樣的背景下，慢慢成為我自己的 side project。
我開始嘗試把這些實際踩過的雷、處理流程，以及該注意的關鍵點，結合 AI 一起整理，希望至少能讓「寫事故報告」這件事，不再成為下一個壓力來源。
技術架構
透過 AI Agent 的協作，在基本的評估後，採用 React + Vite + TailwindCSS 為前端框架，並使用 TypeScript 為主要程式語言。
並採用 MVP 的產品設計思維，先從純前端開始，以先滿足報告撰寫與產出的核心訴求，先解決撰寫異常事件報告的痛點後，再來討論使用者之間的協作問題。