李佳奇談企業AI工程化落地

從「能用 AI」到「AI 能規模化創造價值」

李佳奇把企業 AI 的實踐分成三個相互連動的方向：AI 研發、AI 營運與 AI 決策／數據分析。前兩者覆蓋更多一線工作者，後者雖然服務人數較少，卻直接支援管理者與業務負責人的判斷，因此同樣是高價值切入點。整體策略不是為了展示模型能力，而是讓 AI 能在企業內持續、規模化地產生價值。

企業AI落地Harness EngineeringAI營運AI研發數據分析決策支援

• 先從能直接創造業務價值的場景切入，再逐步擴大 AI 研發投入。
• 平台層是核心：把模型能力轉成產研營日常工作中的生產力。
• 不只看覆蓋人數，也看是否能支援高價值決策與一線執行。

「通過平台來去讓我們的產研運，把 AI 的能力轉化成我們在企業內的生產力。」
— 李佳奇

平台策略：模型採購，關鍵能力自建

在模型層，團隊採取較精實的採購與整合思路，而非自行部署算力、從頭訓練模型；但在平台與工程能力上，則以自建為主。重點是透過內部平台、網關與工具鏈，將不同模型與既有工作環境串起來，降低第一線人員的使用門檻。

這種分工也反映一個落地原則：員工不想多學一個獨立網站或新介面，而是希望在原本順手的工具裡直接使用 AI。把能力嵌回既有工作流，比另開一個「很厲害但沒人用」的產品更重要。

自建平台模型整合既有工作流工具鏈開箱即用

四類產品：讓 AI 進入每天的工作現場

分享中提到的產品布局，涵蓋 AI 營運、數據分析、個人辦公助手與研發平台。這些工具不是各自孤立，而是共同承接從日常取數、分析、協作到程式開發與交付的流程。

在 AI 營運方面，團隊從商家、客服、日常營運到使用者營運等多樣場景切入；在數據側，則先解決一線人員「想查一個數，卻要反覆確認口徑、排隊請人寫 SQL」的痛點，讓基本取數與初中階分析不再過度消耗專業分析人力。

QNova 被定位為日常的商業分析與數據分析工具，也支援重要業務線負責人檢視分析結果。當分析結果會影響判斷時，平台可用性與數據正確性就不再只是技術指標，而是實際的業務需求。

辦公助手 QPAW 的設計也從早期的設定導向，轉向降低配置成本的開箱即用。講者特別提醒，團隊原本以為只是小摩擦的設定流程，對使用者其實就是採用門檻；因此，真正的產品化必須把這些「看似不是主線」的操作一併處理。

研發自動化：先把交付流程變成可執行系統

天弦是研發平台的核心載體。它把雲端流程與部分本地工作串接，讓開發、測試與驗證等任務能在指定時間、特定條件或流程節點觸發。重點不是讓 AI 自由發揮，而是把可重複、可觀測的交付步驟系統化，減少人員在流程切換與等待上的負擔。

研發與一般辦公任務不同，不能只看最後答案。需求、程式碼、編譯、測試、發佈與回溯，都有既定規範；一旦生產環境出問題，也需要釐清過程與責任。因此，AI 若要進入研發，必須在既定流程中穩定執行，而不是跳過檢查直接產出結果。

「研發是一個對於交付、對於交付過程，不忽悠交付，要求非常嚴格的場景。」
— 李佳奇

天弦研發流程自動化程式碼交付測試環境可追溯性流程控制

Agent 可靠性：把流程控制留在平台手上

講者的核心觀點是：Agent 的強項是執行與局部判斷，不必把整個流程控制都交給 Agent。平台負責規定「現在該做什麼、下一步往哪裡走、什麼情況必須停止」；Agent 則在受控範圍內呼叫工具、分析問題、完成當前任務。這樣既能利用模型能力，也能守住企業流程的確定性。

以程式碼修改為例，流程可以先依需求定位相關程式碼，再進行修改、編譯驗證、部署至測試環境、讀取日誌與執行測試。若出現紅燈，系統回傳失敗資訊並要求修復，而不是讓任務在錯誤狀態下繼續往前。部署、查日誌、觸發任務、程式碼審查與日誌分析等共用能力，也被封裝為可被 Agent 使用的工具。

• 嚴格編排流程：每個關卡有明確順序，避免跳過必要驗證。
• 先編譯、再測試：盡早攔截問題，避免錯誤一路流到後段環境。
• 失敗可回收：抓取測試與日誌資訊，提供 Agent 分析並重新修復。
• 共用能力工具化：讓不同任務直接使用部署、查詢、審查與分析能力。

可靠性往往藏在介面細節裡。團隊發現，直接沿用給人使用的工具介面，可能讓 Agent 面對太多參數、不同語意或不必要選項，進而傳錯環境與設定。改善方向是縮小工具暴露面、將必要資訊固化在流程中，並提供清楚的錯誤訊息與下一步指引。

「我們現在大家想到的，都是它負面的東西：我要先確定它哪些事兒幹不了。」
— 李佳奇

這句話點出工程化思維的轉變：先設想模型可能犯的錯、可能越過的紅線與可能卡住的地方，再把限制、驗證與終止條件寫進流程。追求的不是「看起來很聰明」，而是「結果可接受、行為可預期」。

上下文三層：給夠資訊，也別讓資訊失控

隨著平台涵蓋的角色與流程增加，Agent 不可能一直帶著所有歷史資訊工作。分享提出三層上下文概念：固定的流程地圖、當前任務所需的上下文，以及可依需求檢索的知識或方案。這樣既讓 Agent 知道作業規則，也能在任務切換時取得剛好需要的資訊。

當流程從單純的拉程式碼、修改、編譯與發佈，擴展到需求、開發、測試、前端、SRE 與生產節點時，統一控制器的價值更明顯：它能依當前任務注入必要內容，而不是讓所有上下文無限制堆積。

上下文三層流程地圖任務上下文知識檢索統一控制器多Agent協作

從需求到專案：把關鍵資訊一路帶到交付

自動化不只發生在寫程式碼之後。團隊也關注需求輸入是否足夠完整，讓後續流程有可成功執行的基礎。尤其當開發與業務共同參與需求形成時，更需要把需求討論中關鍵、但容易散落在會議裡的資訊收斂進專案脈絡。

在專案層，平台嘗試把某個需求、專案相關的內容與關鍵資訊關聯起來，讓參與流程的 Agent 可取得當初需要知道的脈絡。這不只提升自動化效果，也降低需求在多人協作與長流程中失真的風險。

營運 Agent：驗證、恢復與終止條件缺一不可

營運工作流通常由許多非同步、跨系統的節點組成，難點不在於能不能配置流程，而在於流程是否能照預期一路執行。為此，團隊在執行前做檢查與驗證，在執行中處理狀態與恢復，並設置必要的終止條件，避免模型在生產場景無限制發散或長時間卡住。

工作流驗證狀態恢復終止條件非同步流程生產環境可靠性

數據分析不是一問一答，而是一項受治理的工作

數據分析是分享中另一個重點。講者強調，企業中的分析結果會交給產研人員採取行動，也會提供管理者做結論，因此不能把它當成一般聊天式問答。真正需要管理的是：分析是否有用、是否能收斂、是否符合不同業務場景的口徑與品質要求，以及是否遵守安全邊界。

「真正的在企業裡面用起來的話，它應該不再是一次的問答，而是真正的要把它當成一個計畫。」
— 李佳奇

做法上，團隊主張分場景建設：不同業務、不同角色、不同安全等級，應有不同的資料範圍、分析工具、模型與輸出品質要求。先把一個具體場景做透，再逐步複製到其他場景，比一開始就追求全公司通用的萬能分析助手更可靠。

數據安全治理：權限細到欄位與資料量

數據治理不是分析完成後再補上的檢查，而是任務設計的一部分。分享提到的控制粒度包含欄位與資料筆數：申請分析權限時，需說明要用哪些資料、預計或最多會處理多少筆，再與 OA 審批串接；實際執行時，也依核准範圍嚴格限制，超出即通知。

• 分權限：不同角色只能看見與工作相關的資料範圍。
• 控欄位、控資料量：不只限制能否存取，也限制可取用哪些欄位與多少筆資料。
• 審批與執行一致：核准範圍直接成為運行時的限制，而非紙上規範。
• 模型不直接取得敏感原始資料：以中間結果與受控執行方式降低外流風險。

在敏感資料處理上，團隊不讓模型直接接觸完整原始數據；模型主要根據必要的中間資訊或結果撰寫、調整分析程式碼，再於受控環境執行。這個設計同時呼應了前面的流程控制：模型能看什麼、能做什麼，以及每一步如何驗證，都必須被工程系統清楚定義。

數據安全治理欄位權限資料筆數限制OA審批受控執行數據與事實

重點回顧：把 AI 放在邊界清楚的系統裡

• 企業 AI 落地要從具體業務價值與既有工作流出發，平台化才能規模化。
• 研發自動化不能只求產出程式碼，還要把編譯、測試、發佈、日誌與修復納入閉環。
• Agent 的可靠性來自嚴格流程、精簡介面、明確狀態、充分證據與終止條件。
• 上下文要分層管理，讓 Agent 在正確時間取得正確資訊，而非塞入全部歷史內容。
• 數據分析是有權限、有口徑、有品質要求的任務；安全治理必須落到欄位、資料量與運行時控制。
• 最終分工很清楚：平台決定大流程與邊界，Agent 專注做好當前任務的判斷與執行。

「把這個事情做就行了；但是你在一個更大的流程裡面，當前要做什麼，更大的流程給它調度。」
— 李佳奇