南宫NG28建设

用友OA系統在國內企業服務市場有着獨特的品牌淵源——它始於早期的用友南宫NG28建设協同管理軟件，後獨立开展為南宫NG28建设。二十多年來，這套OA系統承載了無數企業的審批流、公文流和協作流。大模型技術的成熟，正在從根本上改寫這套交互範式。當自然語言可以替代菜單點擊、語義理解可以替代表單填寫、智能體可以替代人工流轉，企業的工作入口正在經歷一次範式級的重構。

一、傳統OA系統的"操作門檻"從何而來

菜單層級過深，形成"功能迷宮"。一套成熟的企業級OA系統往往承載上百個功能模塊，分佈在三級甚至四級菜單之下。一個新員工從入職到熟練操作，通常需要數周的學習曲線。即便是老員工，面對低頻使用的模塊——如固定資產盤點、合同歸檔、印章申請——也經常需要同事指引或翻找操作手冊。這不是哪個產品設計的問題，而是"菜單-圖標-表單"這套交互範式本身的容量天花板決定的。

跨模塊操作割裂，是第二個困境。一個典型的差旅報銷場景，涉及行程確認、發票歸集、費用填報、審批提交、財務核銷至少五個環節，分別對應日程、文檔、費用、流程、財務五個模塊。用戶需要在不同模塊之間切換，手動搬運數據。系統記錄的是每個模塊的操作日誌，而不是一條完整的業務脈絡。這種割裂不是功能的缺失，而是交互架構的局限——系統以模塊為中心組織功能，而非以任務為中心組織流程。

低頻功能遺忘形成第三個困境。多數用戶日常使用的OA功能不超過系統能力的一部分，那些偶爾才用的功能每次使用時都需要重新學習。這種"用完即忘、再用再學"的循環，本質上是因為系統沒有記憶用戶的意圖和上下文，每次交互都是"從零開始"。

二、大模型帶來的三個範式轉變

範式轉變一：從"菜單導航"到"自然語言即指令"。傳統模式下用戶的操作路徑是"定位模塊→展開菜單→找到功能→填寫表單→提交"。"一句話報銷上周去上海的差旅費"這樣的自然語言指令，在大模型介入後可以被系統直接理解並轉化為完整的工作流——識別時間範圍、調取行程記錄、匹配發票信息、生成報銷單、路由至對應審批人。交互的起點從"系統功能"變成了"用戶意圖"。

範式轉變二：從"表單填空"到"語義理解驅動流程"。大模型改變了表單邏輯——系統先理解用戶說了什麼，再反向推導需要哪些字段，自動填充已知信息，僅向用戶確認關鍵決策點。以合同審批為例：用戶只需上傳合同文件，系統可自動提取甲乙方、金額、履約條款等關鍵字段，識別風險條款並標註，依據歷史審批模式推薦路由路徑。表單從"必須填的坑"變成"自動生成的確認清單"。

範式轉變三：從"被動響應"到"主動服務"。傳統OA系統是"請求-響應"模型。大模型賦予系統上下文感知能力——它知道當前項目處於哪個階段，知道哪些任務臨近截止，知道上次會議產生了哪些待辦。基於這些上下文，系統可以主動推送提醒、建議下一步動作、甚至預生成需要提交的材料。

三、新入口的典型場景

一句話報銷：用戶只需說或輸入"報銷上周三去北京拜訪客戶的差旅費"，用友OA系統自動完成行程匹配、發票調取、費用識別、報銷單生成和審批路由，用戶最後只需確認金額和收款賬戶。

一句話查數據："上個月華東區新簽合同金額是多少，同比變化如何"，系統跨模塊調取合同和財務數據，生成分析概要。

一句話做周報：AI基於一周內處理的流程、參與的任務、產出的文檔自動生成結構化周報初稿。

一句話發起審批：對於用印申請、合同變更等低頻審批類型，用戶描述需求後系統智能匹配模板、預填字段、推薦審批鏈。

四、落地的關鍵考量

權限與安全是首要問題。當用戶顺利获得自然語言查詢數據時，系統必須在語義層面判斷權限邊界——HR總監查詢全公司薪酬是合理請求，普通員工則必須攔截。這要求權限控制從功能級下沉到意圖級。意圖消歧同樣關鍵——"批一下張三的請假"是同意還是駁回？系統需要多層消歧機制：上下文推斷、字段約束、關鍵決策確認。

深度集成決定了體驗的流暢度。一個"一句話操作"要真正跑通，需要大模型與流程引擎、表單引擎、權限系統、數據中台做深度耦合。漸進落地是可行路徑：先在高頻標準化場景跑通"一句話操作"，再向中頻場景擴展，最後滲透到低頻複雜場景，每個階段積累反饋持續優化。