勝和｜企業 AI 導入案例

/04待確認部署完成 · 產業待確認

勝和

零散訊號自動內化成看得見的專案進度

產業

待確認(來源檔未載;config app_domain 為 shenghe_menu,但為空白 scaffold,不足以斷定)

合作型態

AIGO 商城自助安裝模板部署

導入產品

專案進度管理助手 project_progress_hub v1.0.0(productivity 類、internal 模式)

部署環境

正式站 ai-go.app,App slug 2079526fdc1e

勝和組織於 AIGO 商城安裝「專案進度管理助手」(project_progress_hub)模板,在正式站 ai-go.app 建立自有 App(slug 2079526fdc1e),安裝時自動建立專屬訊號收件匣資料表與三筆資料引用,並完成發布。此模板的設計立場是把 LINE、GitHub 等零散訊號自動歸戶到專案、內化成有跡可循的進度時間軸,決策權留在人手上、AI 只做歸戶建議與進度草稿。就目前可查的來源檔而言,勝和的部署已通過雲上 webhook 全鏈(gateway→SQS→dispatcher→runner pod→action→收件匣)的端到端測試,正確簽章訊號可落地、錯誤簽章被拒收;但勝和自身的實際使用場景、團隊規模與導入後產出,來源檔並未記載,屬素材偏薄的安裝案例。

導入前 · PAIN

專案訊號散落在 LINE 與 GitHub,要人工翻找才知道哪些事需要跟進
專案目前走到哪、有幾件事等處理,沒有單一總覽答得出來
進度回報靠人工彙整,耗時且容易與實際脫節(假進度)
訊號沒有和進度綁定,回頭追不出某個進度更新是根據什麼來的

AI 落地 · WHAT WE DID

訊號自動進件

LINE 與 GitHub webhook 以 HMAC 驗簽分流進件,錯誤簽章一律 403 拒收;同一訊號以 source_key 去重達成冪等,不會重複落地

自動歸戶

未歸戶訊號先走規則層(專案名/repo 對映),再由 AI(BYOK 選填)輔助;信心不足就留在收件匣等人判斷,不自動創建專案避免自餵爆炸

進度內化與可回溯

歸戶後自動內化成 project_updates 進度時間軸,每筆進度掛上來源訊號 id,證據鏈可回溯到原始訊號

GitHub 歷史補拉

以 GitHub Token 補拉 repo 的 commits/PR/issues(帶 since 游標與分頁上限),把歷史訊號一併納入

人為決策保留

進度%、狀態變更、改歸戶一律由人操作(origin=manual);AI 只產草稿建議,狀態變更不交給 AI

實際產出 · DELIVERABLES

四頁前端:進度總覽、專案時間軸、訊號收件匣、連接設定精靈三支 Server Action:receive_webhook(驗簽進件)、sync_github(歷史補拉)、ai_organize(規則+AI 歸戶)專屬訊號收件匣 Custom Object(signals_207952)+ 三筆對 project_projects/project_tasks/project_updates 的資料引用連接設定頁含各來源健康度(最後收到訊號時間)與 webhook 網址複製、手動觸發補拉雲上 webhook 全鏈(gateway→SQS→dispatcher→runner pod→action→收件匣)驗證通過無 OpenAI Key 時自動降級為純規則歸戶,不失效

推估年效益

5.3萬 / 年

NT$ 53,000 · 推估非稽核實績

NT$ 99,320 毛效益 − NT$ 12,000 系統成本 = NT$ 53,000

效益項	推估式(假設)	年效益
專案狀態彙整自動化	每週省 2hr × 2 人 × 52 週 × 250 NTD	52,000
訊號不漏接、免人工翻找	每週省 1.5hr × 2 人 × 52 週 × 220 NTD	34,320
進度回報省工(有跡可循免重編)	每週省 1hr × 1 人 × 52 週 × 250 NTD	13,000
AI 年成本(BYOK 輕量,推估)	−12,000 NTD/年	−12,000