嘉賓 | 張家瑞、陳奕名

對話 | 唐小引

編輯 | 屠敏

出品 | CSDN（ID：CSDNnews）

“大模型應用開發時代，人人都是程序員。”這是許多人對 AI 時代的美好想象：不懂代碼也能構建應用；幾小時內做出一款小游戲；寫幾句 Prompt，AI 就能幫你生成 UI、補全邏輯、連通接口。從此，軟件開發似乎不再是程序員的專屬技能。

然而，這種體驗更像是“玩具”層面的創意實踐，距離真正的產品化落地仍有不小的距離。簡單來看，應用想要跑在真實業務場景中，無疑意味著系統之間的穩定集成、任務鏈條的有效承接、用戶需求的真實滿足，甚至是與業務邏輯的深度嵌套。而當開發者試圖往這個方向邁進一步時，很快會發現：僅靠 Prompt 寫代碼遠遠不夠。

這正是 Agent 概念走紅的背景，也是 MCP 等系統性架構被提出的原因——人們希望構建的不只是“會對話”的模型，而是“能做事”的智能體。但從構想到現實，To B 和 To C 場景下的問題各不相同，大模型的集成牽涉系統架構與業務邏輯的深度適配，Agent 的上線過程遠比想象中更復雜，MCP 架構在接入業務中也并非萬靈藥。

為此，在CSDN &《新程序員》執行總編、《萬有引力》主理人唐小引的主持下，CSDN《萬有引力》欄目在全球機器學習技術大會上特別邀請了兩位來自一線的應用實踐者——恒生電子研究院算法團隊負責人陳奕名、金山辦公 AI 應用算法負責人張家瑞，圍繞大模型開發中的關鍵難點展開深度對談。他們分別深耕金融科技和辦公產品場景，代表了當前大模型 To B 與 To C 應用的兩條典型路徑。通過他們的實戰經驗，也許我們能更清晰地理解，大模型真正落地之前，還要跨過哪些坎。

AI 產品爆發，但你的痛點解決了嗎？8.15-16 北京威斯汀·全球產品經理大 會 PM-Summit，3000+ AI 產品人社群已就位。
直面 AI 落地難題、拆解頭部案例、對接精準資源！

掃碼登記信息，添加小助手進群，搶占 AI 產品下一波紅利：

進群后，您將有機會得到：
· 最新、最值得關注的 AI 產品資訊及大咖洞見
· 獨家視頻及文章解讀 AGI 時代的產品方法論及實戰經驗
· 不定期贈送 AI 產品干貨資料和秘籍

ToB 與 ToC 的真實戰場：大模型行至何處？

唐小引：從 ChatGPT 到 DeepSeek-R1 的出圈，大家都在關注：大模型應用開發到底走到哪一步了？請兩位老師先做一下自我介紹，然后分別基于自身所在的 To C、To B 行業分享 AI 應用的最新進展。

張家瑞：我于 2019 年加入金山辦公，目前負責金山辦公的 AI 算法應用團隊。我們團隊的日常核心工作是將機器學習、深度學習等算法應用到具體業務中，提升用戶的辦公體驗。

進入大模型時代后，我們也迅速轉向、積極擁抱這一新技術，將其應用于文檔、演示、表格等核心組件中，推動一系列新功能的落地。可以說，我們的工作就是打通從算法到產品的“最后一公里”，也是最具挑戰的一步。

時下，我們的重點工作集中在 WPS AI 2.0 的開發上。從 WPS AI 1.0 迭代到 2.0，我們上線了許多全新的 AI 功能，并提出了四個核心的 AI 助手，覆蓋日常辦公中最常見的應用場景。

以文檔處理為例，用戶最常進行的操作無外乎“讀”和“寫”。在寫作方面，寫作助手可以提供潤色、改寫、錯別字糾正等支持；在讀文檔方面，閱讀助手具備文檔翻譯、內容總結和問答等能力。

除了文本的撰寫和理解，文檔處理還包括一些視覺和排版相關的任務。例如，插圖生成、圖像超分辨率處理、智能摳圖、PPT 頁面設計等，我們將這類功能整合為AI 設計助手模塊。

最后一個模塊是數據分析助手，主要面向對表格有深度使用需求的用戶，比如財務人員，他們常常需要處理復雜的、成千上萬行的報表數據。通過自然語言描述，用戶可以借助該助手完成數據分析、生成透視表、編寫公式以及進行表格的整理和美化等操作。

除此之外，我想重點介紹一個我們近期著重推進的方向——文檔生成 PPT。

大家可能已經在如 Kimi、豆包、天工等大模型產品中看到“一鍵生成 PPT”這一功能。這類工具通常基于一句話輸入，再結合大模型自身的知識儲備或搜索引擎返回的結果自動生成一份 PPT。這種方式的優點是生成速度快，操作簡便。

但它也有明顯的局限——無法利用用戶自身的私有文檔內容。比如，如果我想基于過去四周的周報生成一個月度總結，大模型并不了解這四周我具體做了什么。

因此，我們當前重點打磨的，是一種能夠“基于文檔生成專屬 PPT”的能力。用戶可以選擇自己的總結、財報、報告、教案等內容作為輸入，讓系統生成一個高度貼合自身需求、真正個性化的 PPT。這種方式也獲得了時下用戶較高的認可和反饋。

唐小引：大模型在辦公場景中，已經能勝任哪些任務？還有哪些能力尚未實現？在這個過程中，人與 AI 的協作處于怎樣的階段？你理想中的人機協作形態又是什么樣的？

張家瑞：就當前的情況來看，大模型在辦公場景中已經在多個方面顯著提升了效率。例如，在寫作時，甚至在我自己寫代碼時，都會借助 AI 生成初稿，幫助快速搭建出大致框架。

但要說已經發展到可以“閉著眼睛”直接交付文檔或運行代碼的程度，我認為還存在一定差距。這個差距來自兩個方面：

• 一方面，是對 AI 的信任度問題。當前即便使用 AI 生成了報告或文章，用戶仍會選擇人工復核、校對。這說明我們在實際使用中，仍需要人為把關內容的準確性和質量。

• 另一方面，在對外展示或正式匯報的場景中，例如需要制作一份“滿分級別”的 PPT，通常還需要設計師參與美化與排版，或者由本人對內容進行多次修改和完善。

我認為，AI 目前已經能夠幫助我們完成從 0 分到 60 分、70 分，甚至 80 分的初步工作。但要將成果打磨到 100 分，仍需人工介入：一部分是用戶自身的檢查與潤色，另一部分則是設計等專業環節的人工優化。

唐小引：從 To B 角度來看，金融行業以及恒生電子團隊在 AI 領域的最新進展如何？

陳奕名：我目前主要聚焦于恒生自研大模型 LightGPT 的訓練，并在此基礎上構建上層應用，比如金融場景下的 RAG、審核、信息抽取等。在這個過程中，我們踩過不少“坑”，積累了不少實戰經驗。

在我們探索金融場景中的 AI 應用時，用我們院長白碩的一句話來說，就是產品與技術在“雙向奔赴”。產品團隊基于大量客戶需求，深入挖掘真正的痛點；而技術團隊則思考，如何以盡可能低的成本，同時解決多個需求點。

舉個例子，如果過去需要 10 個人才能解決的問題，技術團隊就需要評估當前的技術趨勢，判斷是否有可能通過未來的發展來更高效地解決。有些問題，當前解決成本較高，但如果預判某項技術將在兩年內成熟，我們可能會選擇暫時擱置這個需求，待技術成熟后再回頭解決。

唐小引：如何判斷某項技術兩年后一定能夠成熟？這樣的判斷依據是什么？

陳奕名：我可以舉一個例子來說明。現在大模型的發展趨勢，實際上與 2017 年計算機視覺（CV）領域中 CV 模型的興起非常相似。

彼時 CV 模型剛興起時，我在京東數科實習期間曾參與過一個項目，是做豬臉識別——即給豬進行面部識別。這項技術本質上與人臉識別非常接近。

我們當時嘗試了各種 CV 算法，比如 YOLO、Faster RCNN、Mask R-CNN 等。效果最好的模型參數量往往非常大，例如 Mask R-CNN 可以達到 800MB 或 1GB 的規模，而 YOLO 模型通常只有 50MB。盡管大型模型效果更好，但在當時很難實際部署。

但到了 2020 年，隨著邊緣計算能力的提升，我們開始能夠在小型設備上運行當年的大模型。例如 Mask R-CNN 已經可以較為順暢地在邊緣設備上部署。換句話說，早期選擇效果更好的模型做積累，當硬件成熟時就可以順利落地。

今天的大模型也有類似趨勢。最初流行的多是參數量高達 72B 的模型，而如今，隨著 DeepSeek 等項目的發展，我們已經可以使用經過蒸餾壓縮的 32B 模型。這種模型在保持性能的同時，參數量更小，更易部署。

硬件的發展也在不斷推進。無論是華為的 NPU 還是其他國產 GPU，整體性能和性價比都在提升。再加上算法層的持續優化，模型的部署門檻會不斷降低。因此，我們的策略是，先用當前性能最優的大模型（比如 72B）完成任務，而不是過早地為“如何壓縮模型”而犧牲效果。未來隨著硬件與算法的進步，自然會推動成本的下降與部署的普及。

唐小引：金融領域的不少從業者認為，通用大模型難以滿足行業的垂直需求。你怎么看待這個問題？

陳奕名：垂直場景可以分為兩類：

• 第一類，是可以在互聯網上搜索得到的內容，比如金融法律法規數據。這類數據往往也被通用大模型所覆蓋，因此專屬模型在這方面的優勢空間正在被不斷壓縮。

• 第二類，是企業內部的專屬數據，例如我們公司內部的生成代碼相關內容。這些知識既無法公開獲取，也缺乏外部語料支持。比如我們曾遇到一個問題：在開發中，如何快速定位“注冊模塊”的代碼位置？從常規邏輯看，應該搜索與“注冊”相關的文件。但實際上，在我們內部，它被歸在一個名為“網絡投票（特殊）”的模塊中。這種與業務強綁定的語義，通用模型是難以理解和處理的。

  對于此類任務，我們會訓練較小規模的定制模型，通過注入企業內部知識，實現更高效的提效。

唐小引：恒生電子內部的實際使用中，目前采用的是大模型與小模型協作的方式？

陳奕名：是的。

唐小引：結合團隊的實際經驗，金融行業在大模型應用中最受關注的技術瓶頸和已有的突破是什么？

陳奕名：可從兩個方面來看：

第一是金融類長表格的處理問題。在金融類大模型的實際應用中，很多人可能第一反應是模型的金融知識不夠，導致回答不準確。但我們發現，這類問題其實通過優化提示詞（Prompt）已經能夠解決 95% 的情況。

真正的難點在于長表格。比如在處理招股說明書時，會遇到各種表格，其中利潤表通常篇幅較短，但專利信息的表格可能會持續 10 到 20 頁，涉及多個維度，如發明專利、外觀專利等。這種大體量的結構化信息超出了當前大模型的上下文窗口，很容易造成處理失敗。

我們的應對方法是：用工程化的方法把解析過程拆分成了幾個步驟。首先，我們先定位關鍵信息的位置，這相當于先做了一次檢索；接著再把這些關鍵區域的內容提取出來，送給大模型進行處理。通過這種方式，就能較好地應對一些超長表格的解析問題。

第二個難點在于模型能力的提升。其實提升模型能力無外乎幾種方式：第一種是改 prompt，這也是最簡單的方式；第二種是調整采樣方式，就是在不重新訓練模型的前提下，通過控制它的輸出采樣策略來增強表現；第三種才是直接對模型進行訓練。

但問題在于，大多數人首先就傾向于選擇訓練這條路。然而只要一涉及訓練，就繞不開一個非常現實的難題。比如我說想訓練一下這個模型的能力，我的領導就會立刻問我：“那你準備投入多少人力？”我算了一下，大概需要一到兩周的數據準備時間，可能得 14 個人，再加上算力工程師的支持也得 7 個人日。他說：“我現在沒有這么多人手，沒法專門為一個場景投入。”所以這條路徑基本上就被“掐死”了——尤其當我們還要同時服務多個客戶時，靠訓練是覆蓋不過來的。

其次，改 prompt 雖然簡單，但能力提升也比較有限。最后，我們轉向了采樣控制的方式。我們探索的是，如何通過調整采樣策略，讓模型在生成時“意識到”：在某些場景下不要太發散，需要更嚴謹一些。我們用這種方式去“管住”它的輸出，盡可能逼近我們預期的效果。

不同場景下，如何寫好 Prompt？

唐小引：我個人一直覺得提示工程并不容易，很多人說模型不給力，其實是提示詞寫得不對。但提示詞怎么寫才算“對”？這在金融場景中，你是怎么把握的？

陳奕名：確實，我們在實踐中也總結出幾個關鍵要點：

第一，避免“腦補”信息。比如之前我們提到某個“注冊”模塊，業務中實際代碼放在“網絡投票（特殊）”模塊里。這種非通用、綁定業務語義的知識不能默認模型“應該知道”，而是必須在 Prompt 里明確說明。不能以為模型能理解你腦中隱含的上下文。

第二，避免依賴情緒化或模糊表述。以前我也犯過類似錯誤，比如在 Prompt 中加入類似“你一定要寫得很好”、“請一定幫我完成”等祈求式措辭。但這種話對模型沒有實際約束力，反而會造成生成內容發散、結果不可控。關鍵還是要明確任務目標、具體約束，而非情緒化引導。

唐小引：在張老師看來，提示工程在面向行業和面向 C 端用戶時，有什么不同嗎？

張家瑞：我們在產品設計時，通常不會直接把 Prompt 寫作的接口開放給用戶。提示詞是由內部的產品經理或 Prompt Engineer 預先編寫好的，用戶點擊某個按鈕時，實際調用的是我們封裝好的 Prompt。

當然，我們也接入了 DeepSeek、MiniMax 等模型，允許用戶自己設定提示詞。

從我們實際使用來看，Prompt 編寫質量的好壞，最好的辦法是把你寫好的提示詞交給一個完全不熟悉這個業務的同學去看，看看他能不能通過這段提示詞快速理解你要完成的任務是什么、有哪些注意事項。如果他能理解，大模型通常也能理解；但如果他覺得提示詞里有規則漏洞、說明不清，或者不知道下一步該怎么做，那么大模型也大概率會“卡殼”。

之所以一定要找不熟悉業務的人，是因為熟悉業務的同學腦中已有任務的背景知識，他們在寫提示詞時，很多內容其實是依賴了腦海中的默認信息，可能提示詞里有些缺失自己也察覺不到。但對一個“陌生人”來說，這些信息必須寫清楚、寫完整——能否讓陌生人看懂，其實就是判斷提示詞質量的最好方式。

大模型應用開發的最新進展

唐小引：大模型出圈以來，“如何做好落地”是一個熱門話題。早期應用常常面臨兩個問題：幻覺問題和數據隱私問題，尤其在金融行業尤為突出。如今，經歷了兩三年的發展，再加上今年 DeepSeek 的爆火和 Agent 概念的火熱，大模型應用開發上發生哪些新變化？

陳奕名：在金融領域，我們通常通過外掛知識庫的方式來緩解模型的幻覺問題，也就是采用 RAG 技術。但如果從根本上希望減少幻覺，仍需從模型本身著手，比如通過強化學習對模型進行微調。

我們在今年 1 月 DeepSeek 發布 R1 模型后觀察到一個現象：當模型的“思考過程”變得較長時，其幻覺問題依然比較明顯。

為了解決這一問題，我們在工程實踐中通常會將任務進行拆解。首先需要分析幻覺產生的原因。總結來看，幻覺往往出現在以下幾種情況：

1. 回答事實性問題時；

2. 面對復雜任務時；

3. 提示詞表達不清晰時。

自行優化第一種和第三張情況后，我們重點聚焦在第二種：任務本身是否過于復雜。我們的做法是盡可能將復雜任務拆解成多個小步驟。比如，讓模型識別“陳奕名”這個名字或回答“水是什么”這樣的任務非常簡單，幾乎不會出錯。但如果讓它先抽取名字、再生成十個名字、再為每個名字構建一個族譜，模型就容易出現幻覺，甚至每次輸出都不同。

因此，我們在實際項目中會將任務盡量拆分細化，以提高準確性。不過，歸根結底，幻覺問題的長期解決方案仍然是提升模型本身的能力。

唐小引：除了幻覺問題，金融行業對數據安全也高度重視。而在應用端，大家近來都在關注 Agent 的發展，比如從年初的 DeepSeek 火爆開始，再到 MCP 等新技術的推進。你在這方面有看到哪些變化或趨勢？

陳奕名：其實我們過去一年一直在重點投入 Agent 相關方向。可以說，隨著大模型能力的增強，Agent 的應用也逐漸具備現實可行性。

在 DeepSeek R1 發布之前，Agent 面臨的一個主要問題是“規劃能力不足”。在模型能力尚未成熟的階段，Agent 經常無法按照設計意圖執行任務，甚至會陷入無限循環。比如我們測試過一個問題：“關羽和張飛誰的戰力更強？”模型會先嘗試比較戰功，發現差距不大后，又回頭再比戰功，如此循環，一直跳不出來。這種情況下，Agent 的表現就很難稱得上智能。

因此在那之前，我們當時重點在提升 Agent 的插件調用能力。但 R1 模型發布之后，它引入了“同步深度思考”機制，規劃能力顯著提升，我們也開始將 Agent 引入金融業務的實際場景。

不過這過程中也有一個認知轉變。正如我們院長白碩老師所說：數字化程度越低的場景，越容易與 AI 結合。反過來，在一些高度結構化、已通過傳統軟件工程（如 if-else 邏輯）構建完善的流程中，引入 AI 的空間非常有限。但對于那些數字化程度低、流程復雜、規則模糊的場景，AI 反而能大幅提升效率。

我們目前的主要應用集中在這些“長尾場景”，比如客服系統。客戶的問題千變萬化，無法預設流程，而 Agent 可以通過識別意圖，動態響應。

當然，在某些標準化流程中，如開戶等業務，我們也在嘗試讓 Agent 參與優化。雖然這些流程已有成熟系統支撐，但 AI 可以進一步幫助判斷流程中的步驟是否有冗余，是否可以簡化。例如，原本需要執行 123 和 456 兩個獨立步驟，AI 通過分析可能將其融合為兩步完成，提高整體效率。我們相信這類流程優化將是 Agent 在金融領域的重要落點，也是我們接下來會重點投入的方向。

唐小引：能否具體舉個例子說明在數字化程度較低的場景下，你們是如何通過 AI 實現突破的？

陳奕名：比較典型的還是客服場景。嚴格來說，不能簡單認為客服“數字化做得不好”，但它的“智能化”確實存在較大短板。

很多企業已經搭建了基礎的 AI 客服框架，比如用戶輸入后會出現推薦問題、可點擊選項等，看似實現了“數字化”。但實際上，它們的對話系統內核仍較為薄弱，導致理解能力不足，響應不準確。

舉個例子，我最近訂票時嘗試聯系人工客服。我說“轉人工客服”，系統卻回復“好的，現在為你轉接到訂票服務”，完全沒有理解我的意圖。這種情況在傳統 NLP 體系下是常見的，因為模型泛化能力有限，準確率往往只有 60% 左右。

我們通過引入基于 Agent 的大模型對話框架，能將準確率提升到 90% 左右。這種能力邊界的拓展，就是我們所謂的“切入點”。相比之下，那些流程化、結構化極強的業務模塊，我們反而很難找到明確的 AI 介入空間，甚至會被質疑“你到底在優化什么？”

唐小引：從 To C 的角度來看，張老師最近有哪些新的觀察或趨勢判斷？你的團隊在這一方向上又有哪些最新的實踐探索？

張家瑞：雖然大家更熟悉我們 WPS Office 在 To C 場景的表現，但其實我們在 To B 方向也在持續發力。WPS 365 就是我們面向企業推出的一站式 AI 辦公平臺。

WPS 365 將聊天、協同辦公（OA）、會議、日程、郵箱、文檔等功能整合在一個平臺上。一旦引入智能 Agent，辦公體驗可以發生質的變化。

舉例來說，日程安排、郵件發送、會議預約這些任務可以由 Agent 自動完成。Agent 會先解析用戶的需求、提取相關參數，再調用內部組件完成任務，實現高效自動化。這背后其實釋放了巨大的效率提升潛力。

唐小引：在日常辦公中很多人已經在用飛書、企業微信、釘釘等工具實現了，WPS 365 與之相比，差異在哪？

張家瑞：目前 WPS 協作的用戶可能還不算多，它也提供類似的群聊、辦公溝通體驗。但我最大的感受是，它在與文檔的打通方面做得更深入。比如在釘釘中發送文檔后，如果要打印、排版，還得回到 WPS 操作。而在 WPS 協作中，聊天中分享的文檔可以直接編輯、評論，甚至通過 @ 精準通知協作者。這種無縫協作體驗，是我們比較突出的優勢。

唐小引：對標微軟 Teams，WPS 在使用習慣或場景上有何不同？

張家瑞：我身邊很多朋友反饋，WPS 在文檔處理和在線協作方面，功能設計更貼近國人的使用習慣。

唐小引：在企業端應用上，請分享你的一些觀察和思考？

張家瑞：剛才提到企業通過 Agent 能實現任務規劃與串聯，我們還看到了更深層的想象空間。

隨著 MCP 協議的提出，企業可以把自己的內部工具，比如出差審批、報銷流程、訂票系統，甚至代碼審核等功能，統一接入 MCP。WPS 365 作為平臺，就可以通過 MCP 協議調度這些工具，打通企業內外的系統與服務。

這樣一來，不僅是我們向企業輸出能力，企業也能反向將自身流程標準化、組件化，接入平臺進行統一管理和調用。對企業用戶而言，這帶來的提效空間，甚至超過個人用戶。

唐小引：金山辦公已經在落地 MCP 協議了嗎？

張家瑞：我們確實在積極推進這方面的工作。當前主要是在將 WPS 365 中的組件接口，逐步封裝為符合 MCP 協議的標準接口。

其實在 MCP 協議正式提出之前，我們已經在內部做了很多相關探索，也做過不少 demo，支持類似的功能調用。但過去這些調用往往是單個函數級別的 function call，沒有統一的協議框架。

現在 MCP 提供了一個通用的協議標準，我們內部也開始考慮是否要搭建一個 MCP 工具管理平臺，方便更多組織以標準方式接入自己的工具和服務。

唐小引：也就是說，未來 WPS 也能支持部署多個 MCP server 嗎？

張家瑞：目前我們主要聚焦在企業工具的接入，還沒有完全走到 MCP server 的層面。但隨著 Agent 架構的普及和成熟，這肯定是發展方向。

“快速部署 DeepSeek”引發的誤區

唐小引：今年年初 DeepSeek-R1 發布后，很多公司一窩蜂地接入 R1。你們怎么看這種“快速上馬 DeepSeek”現象？有沒有看到一些誤區或值得警惕的問題？

張家瑞：確實，今年年初 R1 特別熱的時候，我們也感受到了某種“政治正確”的壓力。很多單位，包括體制內的，也在嘗試接入 R1，仿佛不接就落伍了。

但是以我在實際業務中遇到的一個典型場景為例，分享一些誤區。我自己平時也經常使用 DeepSeek，給我最直觀的感受是：它讓人有種在“跟一個人對話”的感覺，尤其在生成文章時，無論是文筆還是語言組織都非常自然。

但如果接入的是 R1，你會發現它有一個比較明顯的“Think”（同步思考）過程。但在辦公場景下，并不是所有任務都需要這種深度思考。很多時候，用戶的需求是非常明確且直接的：我有一個問題，你能不能盡快給我一個答案？

比如我們在 2023 年上線了一個功能叫“AI 幫你寫公式”。背景是這樣：表格里常用的函數大約有 420 多種，而且這些公式之間還能進行各種組合、嵌套運算，基本屬于無法完全枚舉的復雜體系。許多用戶在學習函數時會遇到門檻，不得不去論壇、社區求助。

而我們希望解決的就是：用戶不必再去問人，只需要輸入一句自然語言描述，就能生成對應的表格公式。

比如：“我想根據 B 列的身份證號提取出生年月日”——這個公式其實挺復雜的，很多人寫不出來，但確實是很常見的需求。

在這種場景下，用戶的核心訴求是：我有一個問題，你快速給我一個能用的公式就好，甚至他不在乎公式的原理，只要結果對、能復制粘貼使用即可。而 R1 如果在這個過程中進入較長的 sync 狀態，生成時間可能會達到 30~40 秒，這對辦公效率來說其實是個明顯的延遲。反而我們現在線上自研的模型，因為響應速度快，用戶的體感更好。

但這并不意味著 R1 不適用于辦公場景。我們也有一些場景，比如“數據助手”功能中涉及數據分析——需要根據自然語言生成一段 Python 代碼，運行后完成數據繪圖、分析并輸出結論。這類任務本身就比較復雜，用戶對生成時長的容忍度更高，而這時候 R1 的規劃能力和準確率就能發揮出優勢。

所以我的看法是：不同場景對大模型的響應速度和思考深度的要求不一樣，不能一概而論，還是要具體問題具體分析。

陳奕名：今年 1 月份 DeepSeek-R1 發布時，我們注意到它是一個具備“深度思考”能力的大模型。它在回答問題時會先進行一段系統的推理過程，然后再輸出最終答案。這種“慢思考”模式，其實在此之前 OpenAI 也做過類似的探索，比如 o1 模型，也是先進行推理，再給出結果。

我印象特別深的是一個具體場景，也是我職業生涯中有些“痛苦”的時刻。當時我們在做 RAG 系統，客戶提出了不少挑戰，我老板也對效果表示擔憂——他們都覺得系統“太慢了”。那時候我們用的是自研的 72B 模型 LightGPT，雖然我們在追求準確率，但確實在響應速度上沒能滿足客戶期望。

客戶很直接地提出：“你們這個系統太慢了。”但我們團隊技術上是有堅持的，我當時跟團隊說：“我們不能為了快而犧牲準確率，哪怕慢一點，我們也要保證它是準的。”但現實就是，客戶希望我們既快又準，這個平衡確實很難。

轉折點出現在 R1 發布之后。R1 的“慢思考”雖然響應時間更長，但我們測試下來發現，它的準確率提升非常明顯。可以說是上了一個臺階。

我們隨即在恒生的 RAG 系統中接入了 R1，結果發現它在實際應用中的準確性確實提升顯著。雖然響應時間變長了，但這一次我們面對客戶時就更有信心了。我們會直接跟客戶解釋：“是的，速度確實慢了一些，但這是為了換取一個質的準確率飛躍。”客戶看到效果之后，也確實提升了對“慢一點”的容忍度——只要答案準，他們愿意等。

當然，我們不會就此滿足于“慢”。在產品設計上，我們也做了很多優化，確保用戶在使用過程中不會出現“轉圈圈”等卡頓體驗，即便底層模型響應較慢，前端交互也依然流暢、自然。

所以從我們的角度來看，DeepSeek-R1 的出現解決了我們此前很頭痛的一個關鍵問題。

大模型開發技術棧：到底是在進化，還是在“內卷”？

唐小引：去年大家還在熱議如何用 RAG 解決大模型應用的落地問題，結果到今年，RAG 卻被不少人認為是“過時技術”，討論的焦點轉向了 Agentic RAG。類似的還有 Function Calling——MCP 一出，很多人也說前者已經不夠用了。時下，大模型應用開發中的關鍵技術真的是這樣“快速更替”的嗎？技術棧的演進，是否真如開發者圈子里那樣被迫不斷更新？有哪些新技術現在確實在大量落地？

陳奕名：其實 RAG 并沒有過時，它仍然是當前大模型應用中非常關鍵的方案。Agentic RAG 之所以現在火，是因為它能處理更復雜的任務，在某種程度上是對 RAG 的增強。

比如說，用傳統 RAG 比較恒生電子 2022 和 2023 年財報，模型一次檢索上下文的能力是有限的，很難同時處理兩年的數據。而引入 Agentic RAG 后，可以先獨立處理 2022 年，再處理 2023 年，最后再融合結果，從而解決了傳統 RAG 無法處理的復雜任務。換句話說，Agentic 是在“協助”RAG，而不是取代它。

關于 MCP 與 Function Calling，其實兩者的差異并不只是接口定義。MCP 做的更重要一件事是“權限統一”。接口的統一相對容易，但權限校驗就非常復雜。像恒生和金山這樣的公司，各自的身份認證體系差異很大。如果沒有 MCP，開發者需要分別去對接多個身份系統，非常低效。

而 MCP 的設計理念就是，所有服務端各自實現認證能力，對外則只暴露一個統一的認證接口。調用方只需接入 MCP 就能訪問多方服務。這在企業級系統里是非常關鍵的能力。

當然，統一認證也帶來了安全風險。一旦 MCP 被攻擊成功，攻擊者可能就能獲得對所有系統的訪問權限。因此 MCP 的部署是權衡場景、規模與安全性的選擇。在小規模應用中，直接調用反而更靈活。

多模態發展雖有些許滯后，但是一個重要發展方向

唐小引：除了 Agent 與 MCP，近期在大模型應用開發中，還有哪些值得關注的技術變革？

張家瑞：我認為，目前仍值得持續關注的重要方向之一是多模態技術的發展。

相較于當前主流的大語言模型，多模態大模型的整體進展仍相對滯后，可能還落后半步甚至一步。在多模態模型中，各模態間的融合方式整體上仍偏淺層，尚未實現真正意義上的深度融合。

以當前主流的開源多模態模型為例，比如千問 VLM、InternVL，以及近期新發布的一些 VLM 模型，大多采用類似的結構：通過 Vision Transformer（ViT）處理圖像，再將其與文本的 token 一起輸入到上層的大語言模型中。這種方式雖然實現了形式上的融合，但在我看來，并未真正做到深度融合和語義對齊。

回顧大語言模型的成功，很多分析都指出其龐大的參數量使其能夠儲存和調取大量知識——這些知識多數被認為存在于 KV Cache 中，源自其預訓練階段攝取的大規模語料。事實上，圖像同樣蘊含豐富的知識，無論是文檔圖、自然圖像還是其他形式的視覺數據。

在早期，我們使用 VGG 或 ResNet 作為視覺模型的 backbone 時，其預訓練權重中其實也包含了知識。這些知識可能體現在從底層紋理信息到中高層語義特征的提取能力上。然而，如何將這種視覺知識與人類通過文本積累的海量知識體系進行有效結合，目前的多模態模型仍未給出理想的解決方案。

更進一步說，除了圖文融合，我們還面臨語音、視頻等模態的集成挑戰。因此，在我看來，多模態不僅是未來模型能力提升的重要方向，也可能是當前技術瓶頸突破的關鍵路徑之一。

值得一提的是，像 Kimi 最近開源的多模態模型，也開始探索更復雜的結構設計。雖然它可能不是第一個，但它采用了 MoE（Mixture of Experts）架構，并在前端引入 Vision Encoder 與 Adapter Layer，再將融合后的結果輸入主模型。這種嘗試在結構上具備一定創新性。

然而，目前還沒有團隊將類似 GPT-4 或 DeepSeek-R1 這種超大規模模型應用到這樣的多模態融合架構中。這說明，在模型體量、融合方式以及模態擴展等方面，仍有很大的探索空間。

因此，無論未來多模態技術是否會被其他路徑替代，它本身仍將是一個極具價值的研究方向，值得持續投入與追蹤。

唐小引：這確實是一個關鍵領域。尤其是在經歷兩年的大語言模型熱潮后，文本處理已經較為完備，但視頻等多模態仍存在很多挑戰。我舉個例子，我們 CSDN 是面向開發者的社區，程序員日常會使用 AI 編程工具。例如出現錯誤時，我會截圖標注出報錯位置，交給 AI 助手進行分析和 debug——這其實就是一個實用的多模態應用。在恒生和金山辦公的實踐中，是否也有類似多模態落地的例子？進展如何？

張家瑞：金山辦公的多模態場景還是蠻多的。譬如，當我們處理一篇文檔時，里面往往既有文本也有圖片。如果想理解圖像內容，并將其與上下文、標題、摘要等建立關聯，就需要多模態能力。

又比如在文檔自動生成 PPT 的場景中，如何決定插圖應該落在第幾頁、與哪段內容關聯，也要靠多模態模型來理解整體語義和視覺要素。

這些功能目前已經基本落地，正在逐步開放給部分用戶體驗，等到技術能力和產品形態足夠成熟之后，再向更多用戶開放。

陳奕名：在恒生的應用場景中，我們對多模態技術的探索主要集中在“菜單導航”這一方向。具體來說，就是希望在客戶已有的系統頁面上，通過多模態能力識別用戶的問題或需求，并引導用戶點擊對應的菜單項。

目前我們主要采用的是“侵入式”的實現方式。這種方式下，我們預先知道系統中有哪些菜單項，比如“業務辦理”、“個人主頁”等，然后接入相應的接口，再通過 Function Call 或 Agent 調用來實現導航功能。

其實多模態的優勢在于，理想狀態是它可以幫助我們設計“無侵入式”的系統。也就是說，我們無需了解客戶系統中具體有哪些接口，僅通過視覺識別和人類直覺來判斷應該點擊哪里——這與 OpenAI 提出的 Computer User 能力比較類似。

不過，現實中會遇到一些挑戰。比如像張老師提到的 WPS 系統，是他們自己開發和控制的，這類場景部署會更順利。而我們的系統往往部署在客戶側，一些菜單結構和功能入口隱藏得非常深，不容易獲取。

從 AI 的角度來看，我們通常會先用人的方式去判斷一個任務是否具備“可解性”——也就是說，先看看一個人能否在不事先了解系統結構的情況下完成任務。如果人都很難判斷，那 AI 去做也會面臨同樣的挑戰。

唐小引：你們的產品路線目前是不是可以概括為：先是 Agent，然后 MCP，再到多模態？

陳奕名：可以這么理解。多模態的部分我們還是在觀察和評估階段。

唐小引：為什么要觀望？是產品和技術兩方面都有顧慮嗎？

陳奕名：目前技術能力和實際產品場景之間還存在一些差距。多模態能力在特定場景下表現不錯，但在客戶系統中，頁面復雜性極高，算法的通用性還不足。我們判斷，如果等一段時間，技術發展到更成熟的階段，比如模型本身的通用準確率提高，我們再介入，效果可能會更好。那我們就先等一等，讓子彈再飛一會兒。

另外，從產品角度來說，有些頁面的結構和邏輯連我們自己都很難迅速理解，更別說 AI 去識別并引導操作。只有當我們能保證讓一個完全不了解業務的人也能快速找到所需功能時，我們才認為“時機到了”。

唐小引：所以“等一等”的時間預期應該不會短，可能不會在今年落地？

陳奕名：大概率是這樣的。但如果技術上突然有突破，比如某個團隊推出了非常強的多模態模型，我們也可以快速跟進。

唐小引：那目前技術壁壘是決定性因素？

陳奕名：是的，技術問題更關鍵。

未來規劃及展望

唐小引：除了 Agent 和 MCP，還有什么是你們現在已經在規劃、調研或者正在推進的？

陳奕名：金融 Agent 產品，當前在研究院內部緊密研發與推進中，等待完成后會給大家展示。我們目前主推、并持續迭代更新的核心產品是 RAG。我們將它與 Agent 結合使用，以應對更復雜的問題場景。

比如，我們之前遇到一個典型案例：客戶上傳了一批金融相關的法律法規文檔，接著提問“交叉持股要不要繳稅？”。問題在于，客戶上傳的資料中并沒有出現“交叉持股”這四個字。文檔里的描述全是很平鋪直敘的，只有類似“公司 A 持有公司 B，B 又持有 A 股份”的描述。

這種情況下，不論是單純使用 RAG，還是加入 Agent 做增強檢索，都很難準確匹配到答案，因為中間存在一個明顯的語義 Gap。“交叉持股”其實是一種行業內的黑話，是從大量實際使用中逐漸總結出來的說法，可能只在論壇、律師口語或業內交流中出現。諸如“交叉持股”、“循環持股”這樣的“黑話”是不會出現在正式的法律文件中的。

我們的解決思路，就是把這些行業黑話和術語做歸納整理，并逐步映射到實際的檢索與理解系統中。因為在實際使用中，無論是業務人員還是其他用戶，他們更傾向于用這種口頭化、非正式的表達方式，而不是文檔里那種標準表述。我相信大家日常使用時也是一樣的。

唐小引：WPS 目前除了多模態和 Agent，還有其他規劃嗎？

張家瑞：從業務場景的角度來看，AI 應用與在實驗室里做基礎研究最大的區別在于：基礎研究和科研通常依賴標準的 Benchmark，只要指標夠好，就能發論文、實現 SOTA，成果相對直觀、明確。但在真實的業務中，算法落地的挑戰遠遠復雜，尤其是在面向客戶的應用場景中，會遇到大量的“長尾問題”。這也是為什么我認為算法應用是最難的一步。

舉個例子，我們曾分析用戶在平臺上提出的“寫公式”類需求。起初，我們統計了使用頻率最高的前 10 個公式，后來逐步擴展到 Top20 個、Top50 個。但即使是排名前 50 的高頻公式，加起來也只覆蓋了全部公式需求的約 30%。這說明，用戶實際提問中有大量使用頻率較低、但依然真實存在的“長尾需求”，這類需求在真實業務中非常普遍，也最難被算法全面覆蓋。

尤其在辦公場景中，不論是文字、演示還是表格，看似標準化的工具，用戶的使用方式卻高度自由。例如，有用戶在文字中插入大型表格，再在表格內寫大量文字；在表格中，也有團隊將其作為文檔工具，在單元格中寫上幾百字的 OKR 說明。這些非典型用法帶來了極高的復雜度，要求我們的模型和系統在各種變化場景下都能穩定、精準地表現。

再細分到當前我們重點專注的 PPT 場景，其中我們使用了 RAG 技術。RAG 的門檻看似不高，許多本科生、研究生的項目都可以搭建起一個基礎系統，譬如選一批財報數據、構建知識庫、做 Embedding，再結合開源工具完成召回與生成。但想從“可用”的 60 分，提升到 80 分、90 分，難度非常高。RAG 系統還存在典型的“木桶效應”——從解析到召回，再到答案生成，任何一個環節出現短板，都會成為整個系統的性能瓶頸。

因此，在我們看來，算法應用的發展，一方面要持續跟進前沿技術，另一方面也要把已經成型的方案做深做透，真正解決好那些分散、復雜、瑣碎但又影響體驗的長尾問題。這才是 AI 應用最具挑戰性、也是最有價值的部分。

大模型應用開發：需要腳踏實地，也不忘仰望星空唐小引：在大模型領域，模型層更多是在“仰望星空”，追求前沿技術的突破；而應用層則更強調“腳踏實地”，要解決實際使用中的各種痛點。這也是我們認為應用開發至關重要的原因。最后，請二位老師結合自己的實踐，給大家分享一些經驗、教訓或建議，幫助更多開發者更好地參與大模型應用開發？張家瑞：回顧我們在 WPS 的 AI 應用實踐，從早期的傳統機器學習、深度學習，到如今的大模型時代，再到未來的演進，我認為一個核心始終未變：要腳踏實地，關注真實業務中的“長尾問題”，解決那些看似瑣碎但真實存在的場景需求。 與此同時，我也想強調另一個同樣重要的方向——保持對新技術的敏感度。在當前這個階段，AI 的發展速度遠超以往，幾乎每天都有新模型、新工具、新思路涌現。如果長時間不關注最新進展，就很容易錯過重要的趨勢和技術機會。 我經常鼓勵團隊去讀 DeepSeek-V3 和 DeepSeek-R1 的論文。我們并不一定要自己訓練這些模型，硬件資源也有限，但更重要的是學習它們背后的工程思維。比如 DeepSeek 的出色之處，不僅體現在算法能力上，更在于其工程實現的高效性和實際問題的解決策略，這些往往是其他廠商在落地時容易忽視的。 所以我的建議是：一方面要扎實解決眼前的問題，另一方面也要持續關注行業前沿。腳踏實地的同時，不忘仰望星空。陳奕名：我非常認同張老師的觀點。因為我之前也在 To C 公司工作過，深有體會：To C 的技術挑戰非常大，面對的是成千上萬、甚至上億的用戶，需要在體驗、性能和效果之間找到一個最優解，技術要求非常高。 現在我在恒生電子，主要面向的是 To B 場景，這和 To C 是完全不同的兩條路徑。To B 更聚焦于垂直行業的具體需求，雖然問題本身技術難度可能沒那么復雜，但業務屬性更強，客戶更關注結果是否“好用”、“對業務有價值”。 我一開始轉向 To B 時其實有些不適應，還帶著 To C 的思維方式，想把所有問題一網打盡。后來才意識到，客戶不一定在意你解決的問題是不是“通用難題”，他們更在乎的是：在我的場景下，這個功能夠不夠準，能不能幫我把事辦好。哪怕是定制化方案、哪怕與其他模塊有沖突，只要能滿足他們當前的業務訴求，就是好方案。所以我們團隊逐漸摸索出一套合作機制：技術定方向，產品打細節。我們工程師很多時候不太了解客戶真正的痛點，而產品同事離客戶更近，能告訴我們哪些地方需要打磨，哪些地方不用花力氣。 當然，這個過程并不總是順利的。我們和產品幾乎天天“Battle”。但也正是這種“Battle式”合作，才能真正打磨出讓客戶滿意的產品。有時候吵得熱火朝天，客戶卻一試就說：“你們這個怎么做得這么準？”我們聽著當然高興，但心里也清楚：其實是產品把需求摳得太準了。 所以說，沒有“Battle”，就沒有“好用”。如果我們技術完全聽產品的，啥都不問、全盤接受，那這個項目基本就完了。

唐小引：讓我想起來程序員和產品經理的不共戴天之仇。

陳奕名：對，我們是白天吵，吵完之后晚上一起吃飯。

關于《萬有引力》：

這是由 CSDN &《新程序員》執行總編唐小引主理的對話欄目。技術趨勢多變，一不留神總擔心錯過。正在發生的技術事件，對于我們開發者意味著什么？我們面臨的諸多困惑從何尋找答案？《萬有引力》即志在于此，直面事件與困惑，抽絲剝繭，解讀技術真相。

• 欄目定位：一檔面向開發者群體，聚焦解讀技術事件的對話直播欄目。

• 直播觀看平臺：CSDN 視頻號、CSDN 網站 & App

• 多形式：文章、視頻、音頻都會有，持續關注 CSDN 公眾號都可獲取。目前《萬有引力》欄目已上線小宇宙平臺，歡迎大家關注！

2025 全球產品經理大會

8 月 15–16 日

北京·威斯汀酒店

2025 全球產品經理大會將匯聚互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。

更多詳情與報名，請掃碼下方二維碼。