作者 | AICon 全球人工智能開發與應用大會

策劃 | 李忠良

編輯 | 宇琪

隨著技術的快速發展，大模型在各行業的應用潛力日益凸顯，但如何將大模型能力高效轉化為實際業務價值，仍是企業面臨的核心挑戰。

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請了華為云 AI 應用首席架構師鄭巖擔任主持人，和螞蟻集團高級技術專家楊浩、明略科技高級技術總監吳昊宇一起，在AICon全球人工智能開發與應用大會2025 上海站即將召開之際，共同探討大模型如何驅動業務提效。

部分精彩觀點如下：

• 選擇模型時，應重點考慮推理還是生成、上下文長度、響應性能三個方向。

• 做 AI 應用就像做工廠，雖然做的事情看似高大上，但在實際操作中，還是要在“車間”里與客戶一起，逐步解決一個又一個問題。

• 理想中的 AI 智能體應該類似于生命體，它具備感知、認知和行動能力，并能夠在實踐中不斷迭代和反饋。

在 5 月 23-24 日將于上海舉辦的 AICon 全球人工智能開發與應用大會 上，我們特別設置了 【大模型助力業務提效實踐】 專題。該專題將圍繞模型選型與優化、應用場景落地及效果評估等關鍵環節，分享行業領先企業的實戰經驗。

查看大會日程解鎖更多精彩內容：

https://aicon.infoq.cn/2025/shanghai/schedule

以下內容基于直播速記整理，經 InfoQ 刪減。

場景探索

鄭巖：在探索大模型應用場景時，企業常會遇到“看起來很美但落地難”的需求，各位在實際項目中是如何判斷一個場景是否值得投入的？

吳昊宇：企業應用 AI 時，需要關注三個關鍵點：首先是識別最重要且值得解決的問題；其次是確保有高質量的相關數據支撐 AI 應用；第三，當效率低或解決效果差時，AI 可以作為輔助工具提升效率。

企業選擇 AI 應用場景時，應遵循高頻和有價值兩個原則。通過識別最有價值和最頻繁的問題，可以明確解決范圍并合理投入資源，確保短期內看到效果。

楊浩：財務領域 AI 應用可以分為三大類型：一是提升基礎作業效率，過去在工程化階段很難通過逐行代碼寫清楚審核規則，而 AI 應用后，審核場景的效果顯著提升。二是風險防控，我們會根據不同指標建立模型，利用大模型分析并形成 SOP。三是創造增量價值，財務領域的司庫投資場景可以通過大模型優化投資決策。

在落地具體場景時，我們關注 ROI，評估項目需求、人員和卡的投入，最終判斷效果是否能覆蓋投資成本。

鄭巖：ROI 如果僅僅考慮人力和卡的成本，實際上投入非常大，這樣是否會限制我們的場景選擇呢？

楊浩：確實會有影響。舉個例子，如果我們投入兩個人和兩張 L20 推理卡，能夠節省五個財務人員的工作量，那么我們認為投入產出是正向的。

雖然 AI 應用還不完全成熟，初期技術成本往往高于傳統技術，但在財務領域，我們會根據三個分類優先評估那些高優先級的場景。

鄭巖：AI 大模型帶來的價值和長期發展趨勢確實讓我們無法忽視，但如果我們全面投入，嘗試用 AI 大模型重做所有場景，成本又會非常高。因此，關鍵在于找到一個平衡點。

我們內部有總結一個 AI 場景識別的 checklist，稱之為“AI 場景 12 問”，簡單說，就是通常會從三個維度來考量：第一個維度是業務價值，也就是商業價值。我們雖然不會精準的衡量 ROI 來看這場要不要做，但是這會是一個重要的排序因素。接下來是成熟度，正如吳老師提到的業務、數據和技術的準備情況。

最后，我們還加入了一個維度：是否有持續運營的能力。因為我們通常認為 AI 應用上線后，很多時候無法達到普通員工的作業效果，還需要持續投入精力去優化和迭代。

吳昊宇：以前在營銷工作中，我們需要大量的數據支持，主要是寫報告和查數據。過去，我們常用小模型，雖然成本低，但靈活性差。換個新行業看數據時，發現之前用的實體無法適應新需求，這時我們通常會依靠人力投入，進行大量人工標注。

然而，使用大模型后，情況就變得簡單了。業務人員只需要定義新領域的實體詞，大模型就能自動識別。這樣，社交媒體洞察報告可以根據行業定制，客戶需求越細致，報告就越詳細。報告的速度和質量也得到了顯著提升。

鄭巖：在立項初期，如何向決策層證明大模型投入的性價比？各位有哪些量化的“價值錨點”可以分享？

楊浩：在財務領域，很多問題都可以通過 ROI 來衡量。對于效率提升的場景，我們會根據單量來衡量。例如，若通過輔助工具或無人值守模式提升了效率，我們會計算這種模式能節省多少人工工時。

財務高層最關心的往往是風險控制，而非純粹的效率提升。在這種情況下，我們首先衡量場景的風險敞口，并評估引入大模型后能夠覆蓋的風險防控比例。

對于增量價值的創造部分，比如智能資金調撥、結構性存款和量化投資等，這些可以直接為公司帶來實際的資金增值，能夠明確計算出為公司賺了多少錢。

此外，像稅務規劃等場景，也能通過大模型收集數據，支持相關決策。這些場景的收益可以明確衡量，無論是減少風險敞口還是提升人效，投入的成本都能得到初步估算。如果 ROI 不為負，通常老板會愿意進行投資。

鄭巖：風險是怎么估算的？

楊浩：通常通過掃描風險敞口，來確定能夠管控的風險比例。比如審核流程中，財務有時會盲目審核一些采購單或報賬單，這些單據可能存在巨大的風險敞口，特別是單筆金額上億的情況下。使用大模型審核時，我們會逐個審核這些環節，并通過模型管控相應的風險比例。

鄭巖：最終還是需要人工核查吧？

楊浩：當大模型的準確率足夠高并且穩定時，某些場景我們已經能夠實現無人值守。

吳昊宇：在我們做營銷時，很多時候并不是單純關注錢的問題。我們對接了許多跨國公司，在這些公司里，中國區更加注重創新，如果實現了一個好的 AI 應用，它可能成為總部認可的機會，從而在總部獲得更大的支持。

我們與一家醫藥客戶合作，幫助他們的內部咨詢部門關注一線人員的滿意度。這個醫藥公司有大量的業務代表需要與醫生接觸，但因為醫學專業性強，一線代表往往不敢直接提問，特別是擔心問得多了會被視為不專業。

因此，我們幫助他們創建了一個基于知識庫的應用，除了查詢功能外，還包括內部培訓和考試。經過這一套培訓和練習后，他們的一線代表開始變得更加自信，敢于與醫生溝通，見面的頻率也有所增加，這對他們的銷售工作幫助巨大。

技術落地

鄭巖：在選擇大模型技術路線時，不同業務場景對模型能力的側重點可能完全不同，能否結合各位的實踐，分享一下技術選型時的優先級考量？在改造傳統系統時，各位是選擇“顛覆重構”還是“漸進升級”？

楊浩：不同版本的模型適用于不同的需求。選擇模型時，我們主要考慮三個因素：首先，場景的重點是側重推理還是生成；其次，上下文的長度，一些場景需要處理長上下文，而其他場景可能只需要短上下文；最后，響應性能。在某些場景中，高性能響應是必須的，特別是深度思考的模型常常響應遲緩，可能需要幾秒到幾分鐘才開始返回結果，這在某些應用中是不可接受的。

另外，關于選擇顛覆重構還是漸進升級，也需根據具體場景分析。AI 應用有三種范式：AI Embedding、AI Copilot 和 AI Agent。其中，前兩者偏向漸進升級，AI Agent 則偏向顛覆重構。

尤其是在財務領域，第三種模式（AI Agent）占據了大部分比重，可能超過 50%。從 2023 年下半年開始，我們先進行了一些 AI 嵌入的工作，將 AI 能力融入現有財務體系中。

用戶并未感知到這是 AI 應用，只是看到了自動化的流程。比如在界面的右下角彈出一個機器人，用戶可以與其交互進行智能分析、審核等任務。對于 AI Agent，我們正在定義數字員工，實際上是在重新構建整個財務系統的入口，這屬于顛覆重構的方式。

鄭巖：財務體系相對其他業務領域，數字化成熟度是比較高的。如何在如此成熟的數字化體系中，深度采用 AI 且以超過 50% 的比例進行重構，如何確保業務能夠適應這些變化？

楊浩：財務領域確實有很多子領域，每個子領域基本上都有后臺管理系統。在新的 AI Agent 模式下，我們設計了一個 AI Native 的財務體系，提供統一的入口，后端連接各個子系統，并且這些不同領域的 Agent 通過協議進行通信。

從業務角度來看，用戶不再關注各個系統的功能，而是關注自己的業務需求。我們內部提出的口號是“從做功能到做服務”，舉例來說，報銷和報賬是每個公司都會涉及的內容。

傳統的系統需要用戶手動處理提單、審核結算等復雜流程，而現在我們的系統只需要用戶簡潔地輸入一句話，比如“我要報一個賬”，并上傳發票，后續的提單和審核等流程系統會自動完成，這是對用戶體驗的一次重要變革。

吳昊宇：對于營銷類客戶，他們更加關注模型是否能夠從多樣化的材料中挖掘出相關信息。例如，若客戶查詢草莓相關內容，但歷史報告只包含藍莓數據，嚴格排除藍莓內容可能導致無法提供有用信息。

因此，模型需要具備一定的靈活性。而對于醫療客戶，他們對準確性、引用的精確性以及可解釋性要求非常高。在這種情況下，模型必須嚴格按照原文回答，不能自行生成或引用其他知識。

在推理模型的應用中，處理報告和問答時，我們首先進行發散性推理，探索用戶可能的需求和相關問題，但在回答時，必須確保模型的高準確性，避免過多的推理。這些差異決定了模型選擇時需要根據客戶需求進行權衡。

在傳統系統的改造過程中，我們逐步升級。例如，在頁面上添加類似 Copilot 的插件，用戶可以通過該插件直接進行問答或操作。同時，我們將一些傳統的判斷邏輯轉交給大模型處理，特別是在涉及關鍵節點的場景。

過去，這些節點依賴代碼規則或小模型判斷，而現在，大模型可以更好地利用工作流上下文，從而提供更準確的結論。雖然界面變化不大，但系統架構已發生顯著變化。

鄭巖：我們在實際選型和采用各種模型時，還會考慮到一個問題：我們不希望模型的種類過于發散。技術團隊若要熟悉多種不同模型的能力、風格、架構和部署方法，成本會相當高。

因此，在進行 POC（概念驗證）或原型驗證時，我們可以適度發散，但在生產環境中，我們更傾向于收斂。

鄭巖：從 Open AI 提供 Agent 架構之后，大家都在 Agent 都有創新，在大家各自的領域，Agent 架構有哪些創新？或者實踐？

楊浩：我們自己定義了一套 Agent 體系，并將其分為四個主要部分：感知、決策、執行和反饋。

感知分為主動感知和被動感知。被動感知比較簡單，就是用戶通過對話給我們的信息。主動感知則是我們在企業內部應用中，通過感知用戶的角色、崗位、權限和任務等，來為用戶打標簽并進行畫像。

系統會根據這些信息推薦相關的任務和操作。決策部分涉及到存儲和各種決策模型，決策模型幫助 Agent 決定要做什么以及如何做。執行部分則涉及各種工具的調用，比如 API、SQL 等，Agent 通過調度這些工具來完成任務。

我們在反饋鏈路方面進行了創新。例如，用戶遇到問題并認為大模型的回答有誤，但如果不做調整，下次用戶再問相同問題時，大模型可能仍無法給出正確答案。

為了解決這一問題，我們構建了一個反饋鏈路，讓用戶可以格式化地反饋問題，指出模型在某些場景中的不足之處。

我們將這些反饋信息整理成學習知識庫，并通過動態調整來優化模型性能。通過這一動態反饋機制，Agent 能夠不斷學習，逐步提升模型的能力。

鄭巖：可以舉一些動態反饋的例子嗎？

楊浩：在智能審核場景中，我們關注每個審核點，如核對稅率是否與合同一致。若從合同提取的稅率錯誤，用戶可結構化反饋，系統自動生成反饋內容。

收到反饋后，我們會人工確認其質量，確保數據準確無誤，再將其加入知識庫并定期更新。更新后的模型用于評測歷史數據，若準確率提升，經過灰度測試后正式投入使用。最終，模型能像人一樣理解并響應反饋，達到智能優化的效果。

鄭巖：不僅讓大模型能“聽懂人話”，還能讓用戶參與到大模型的持續演進過程中，形成一個非常有價值的循環。

楊浩：關鍵在于讓業務方真正成為大模型應用的“老師”。

鄭巖：這真的就變成了“AI 訓練師”——用戶在不斷地幫助 AI 進行訓練。

吳昊宇：在我們的內容營銷系統中，我們傾向于將整個系統看作一個 AI Agent，最終目標是實現內容生產的全自動化。我們將內容營銷 Agent 分為三個部分：感知、認知和行動。

感知系統方面，我們需要了解市場上發生了什么，避免盲目做內容。在做營銷之前要“五看”：看趨勢、看行業、看目標人群、看競品和本品。這些信息都依賴于我們的“魔方 Pro”系統來收集，它能從市場中提取相關信息，作為內容創作的基礎，決定創作方向。

認知系統方面，我們基于明敬超圖多模態大模型創造了一個通過模擬人的主觀感受來評估內容的系統。這個系統能夠從不同年齡層或性別的人群角度出發，通過模型模擬他們的反應。通過這種方式，我們可以提前預判廣告的受眾反應，避免不必要的內容測試，減少成本，提高 ROI。

行動系統則關注廣告內容的自動化生產，以及如何與人工合作進行內容創作。廣告投放后，需要通過收集數據進行迭代反饋，確保廣告的 ROI 持續提升。如果某個廣告效果好，我們可以加大投入，進行加熱推送，讓其表現更佳。

整體來說，我們的反饋和行動系統核心在于內容的迭代和反饋，通過這個過程使營銷活動實現自動化。我們的最終目標是將整個營銷過程——從感知、認知到行動——整合為一個連貫的系統。在不需要太多人力干預的情況下，廣告商能把內容交給 AI Agent，放心地期待回報。

鄭巖：MCP 非常火熱，不同的技術棧應用如何快速支持，以及是否決定支持？

吳昊宇：MCP 在開發全新 AI 應用時非常有用，但對于一些相對成熟、流程固定的產品，MCP 的優勢不如傳統技術明顯，甚至在某些情況下還不夠成熟。

所以，對于舊產品，我們根據現有情況進行測試和選擇；而對于新產品，我們更多地進行適配。之前，我們調用內部工具時通常使用函數調用的方式，將所有內容寫成一個非常長的 prompt，交給大模型來調度。現在，我們搭建了 MCP Server，各團隊接入時操作變得更加簡便。

盡管如此，在新的 AI 應用中，我們也發現 MCP 的變動非常大。因此，目前我們還是在有限制地使用 MCP，并且希望 MCP 協議能夠盡快成熟，以便我們可以更加放心地使用它。

楊浩：螞蟻內部 MCP 的應用比較激進。舉個例子，像支付寶的支付 API，現在可以通過 MCP 的方式結合，直接在 Agent 中完成支付操作，這在支付領域的應用非常前衛。我們在 AI 應用進程中，作為客戶端去調用螞蟻內部的各種服務，這部分使用較多。

另外，針對一些財務領域的老舊系統，很多是基于 Java 架構的，我們在這些小眾場景中嘗試將 MCP 應用進行試點。為了支持 MCP，我們會在一些小眾場景中，通過 Server list 等模塊來支持 MCP 的應用。所以，作為消費者，我們更多的是調用螞蟻內部的 MCP 服務器。

前兩年大家專注于模型的研發和提升，而最近，MCP 開始引起關注。可以看出，大家已經從單純的卷模型轉向卷應用。MCP 作為一個標準化的通信協議，解決了通信協議這一層的工程化問題，它不是模型層的創新。

鄭巖：從實驗室效果到生產環境穩定表現，各位是如何實現的？能否揭秘關鍵評測環節的設計思考？

吳昊宇：POC 階段大家認為一切順利，但只有真正進入生產并面向客戶時，才發現實際上工作才剛剛開始。面對不確定性系統，最重要的就是多測試。測試不僅是覆蓋多個場景、領域和行業，還要反復進行，而不是一次性測試完就結束。

舉個例子，在與客戶一起上線知識庫系統時，需要不斷測試其材料，客戶提了意見后，我們要去驗證解決方案。有時甚至需要人工與客戶一起整理資料，因為客戶提供的資料質量可能很差，我們需要與客戶合作，提升資料質量，從而提高最終的問答質量。

當然，客戶會有基本的預期，期望在經過一定的測試和優化后，達到預定效果。你不可能一直修改下去，因此要設定好標準，并與客戶不斷磨合。做 AI 應用就像做工廠，雖然做的事情看似高大上，但在實際操作中，還是要在“車間”里與客戶一起，逐步解決一個又一個問題。

鄭巖：在交付給客戶時，您是否會和客戶約定一個準確率的承諾指標，或者其他類似的標準？

吳昊宇：準確率的承諾指標通常建立在數據集基礎上。客戶會提供他們日常問答中常見的問題和問題類型，我們會根據這些問題，進行優化，力爭解決 90% 的日常問題。達到了這個目標后，就可以交付了。

鄭巖：像 AI 大模型這種技術我們無法做到“零 BUG”，這意味著可靠性評估最終還是要依賴評測集。但設計評測集的方式會影響指標的表現，所以，業界的各種評測集也在不斷迭代和優化。

吳昊宇：客戶關注的不是你給出的評測指標，而是從他們日常應用或者業務價值出發。因此，每個客戶的評測集都可能不同，包括文檔范圍、內容，甚至他們想問的問題類型都有差異。所以，評測集的設計和應用確實是因客戶而異的。

楊浩：在做模型時，大家常聽到“數據決定效果”，這條規則仍然適用于確保應用的穩定性。在 POC 階段，效果可能很好，但在線上面對更多不可控因素時，問題就暴露出來了，本質上是因為數據集不夠全面。

那么，如何解決？在實踐中，首先，我們會根據場景設置詳細的指標體系。例如，在審核場景中，我們會針對不同的審核要素、審核點和審核單據等維度，設計精確度、召回率、準確率等指標。

第二，在上線過程中，我們采取了兩種模式。最初，我們并沒有完全用 AI 替代人工，而是將其作為輔助審核，最終決策依賴人工。在這個階段，我們與業務方密切合作，每周分析所有錯誤案例，持續優化模型。

上線初期，審核場景的準確率僅為 20%，幾乎無法使用。經過三個月的調優，準確率提高到 90% 以上，在審核要點維度上達到了四個 9 的準確率。

財務領域對準確性要求極高，因此，我們首先采用輔助審核模式，不斷對齊和調整，確保準確性。當某個場景的準確率足夠高時，比如單一類目下審核的準確率在三個月內持續保持 100%，我們才會將該場景轉為無人值守，AI 自動替代人工審核。但這并不意味著人完全不參與。

我們設有后續檢查流程，定期抽檢 AI 審核的單據。如果 AI 審核錯誤，系統會回退到輔助模式。這種流程提供了容錯空間，也允許我們逐步過渡到完全無人值守的模式。

鄭巖：從 20% 到 90% 準確率的提升過程中，最有效的措施是什么？

楊浩：首先，我們設計了非常詳細的指標體系，通過這些指標，我們可以反推每個案例的問題所在。針對這些問題，我們與業務方一起逐一對齊。我們將人工經驗注入到模型應用中，這是一個非常復雜的過程。

鄭巖：您是通過 Prompt 工程還是通過訓練將人工經驗對齊到模型中？

楊浩：我們先通過工程化的方式將場景做到一定程度，然后再利用高質量的數據集進行訓練，最終將這些經驗融入到模型中。

觀眾：怎么看待 A to A?

楊浩：MCP 解決的是人與技能之間的問題，而 A to A 則是解決人與人之間的問題。在財務領域會涉及一些場景，比如在接入新的業務時，需要評估如何進行核算、稅率是多少、是否為關聯交易等，這些場景通常需要不同領域的 Agent 之間進行溝通和反復協作，但目前我們還沒有通過 A To A 實現 Agent 間的直接溝通，更多的還是在使用 MCP。

吳昊宇：A to A 其實是多 Agent 之間相互溝通的方式，這種方式會帶來更多的不確定性。不過，我相信當 Agent 系統足夠豐富或復雜時，Agent 之間如何互動將會是行業未來的研究重點。

但現在，我們的首要任務是先確保單一 Agent 的功能完善，確保它能夠充分發揮自己的技能，再考慮如何實現 A to A 的交互。

觀眾：幻覺問題如何解決？

吳昊宇：在做知識庫的過程中，我們發現幻覺問題很多時候是因為大模型在自由發揮。解決這個問題的方法就是不斷調整 Prompt，確保大模型按規定執行。比如，如果你發現它常常舉一些不存在的例子，就需要在 Prompt 中明確禁止它舉例，只允許引用原文。另一個常見問題是某些模型喜歡合并同類項，有時合并錯誤。在這種情況下，你需要提示模型不要合并同類項，而是直接按原文回答。

鄭巖：企業內部的很多“黑話”和術語，是導致幻覺問題的一個常見原因。比如說“膠片”，很多人都不理解這個是什么意思，而大模型更理解不了，其實是指 PPT。

我們所處的行業技術性較強，縮寫使用頻繁，很多時候我們需要幫助大模型理解這些縮寫和術語，來消解它們的歧義。整體來說，隨著技術的進步，大模型的幻覺問題從指標上來看已經越來越少了。

觀眾：提示詞和模型微調是否能達到四個 9 的準確率？

楊浩：提示詞與提示詞之間有很大的差異，編寫一個好的提示詞并不簡單。我們針對特定任務流程編寫了一套非常嚴格的專家框架，類似于 SOP。

在執行任務時，模型需要按照我們的要求一步步執行，而且每一步之間可能還存在依賴關系。因此，準確率的評估需要根據不同的場景來進行，不能一概而論。

未來展望

鄭巖：現在優秀的 AI 大模型層出不窮，企業 AI 應用如何應對？當大家都在談 AI Native 時，各位心中理想的“智能體”應該具備哪些特質？當前距離這個目標還有多遠？

吳昊宇：理想中的 AI 智能體應該類似于生命體，它具備感知、認知和行動能力，并能夠在實踐中不斷迭代和反饋。

此外，智能體應該具備學習能力。現在我們的模型進化依賴大量算力進行訓練，但生命體的學習速度遠快于此。未來理想的智能體應該能夠通過少量樣本或某種學習方式快速進化，而不是像現在這樣從零開始重新訓練。

楊浩：企業應對大模型發展的方式可從模型和應用兩個視角探討。底層大模型訓練方面，企業需快速掌握模型架構、訓練方法和優化算法，特別是獎勵函數設計，關注技術深度。

應用層面，核心是快速接入、評估、部署新模型，并利用其特性。替換底層模型時，必須確保新模型準確率優于現有模型，否則會影響業務。

雖然理想的智能體可自我演化，但現實中模型的智能是有限的。評估智能體時，應關注設計、數據、領域知識和動態性。AI Native 應用設計不同于傳統 GOI，需設計合適的卡片、工作流程和圖譜，復雜任務執行圖與傳統設計有很大不同。

企業要深入了解和掌握內部數據，確保模型能夠理解和處理數據。領域知識對專家系統至關重要，尤其是在財務領域，了解會計、稅法等知識。模型應具備動態性，根據人類反饋自我學習。

鄭巖：大模型發展確實非常非常快，配得上“日新月異”，因此在變化背后，我們就更需要抓住大模型的發展過程哪些是不變的。我之前簡單總結過，稱為“五更”，分別是：更強、更便宜、更快、更長（的上下文）和更多模態，這些趨勢基本上在最近三年一直保持著。

從 AI 工程和應用的角度來看，我們要盡可能避開這些大模型的主航道，不要在大模型快速發展的過程中“繡花”。畢竟，升級一個版本后，可能會發現你費盡心力改進的幾個百分點，隨著更強的基模型發布，直接就可以帶來幾十個點的增益，之前的投入就白費了。

另外，我認為有一個問題很多同行沒有被重視，就是評測。很多人認為評測很基礎、低級，認為做大量的評測用例好像沒什么意義。但實際上，評測是 AI 能夠持續落地的關鍵。

如果測試集足夠好，它就能夠足夠好地還原業務本質。如果評測工程做的足夠好，就能夠以更快的速度迭代 AI 應用。在這個基礎上，再去優化 AI，才能有的放矢。如果評測的方向錯了或偏了，那很多努力就會浪費。

鄭巖：在組織能力建設方面，各位觀察到哪些新型崗位正在崛起？傳統團隊需要補充哪些“超能力”？

楊浩：第一個崗位是“企業知識管理師”，AI 應用依然遵循“有多少數據就有多少智能”的原則。因此，企業內部的應用需要有高質量的數據，知識越豐富，數字員工才有可能變得真正智能。

另外，很多互聯網公司實際上沒有完善的知識庫，尤其是在業務快速發展的情況下，知識庫往往是后置的。

接著，傳統團隊需要補充哪些超能力呢？比如我們這樣的工程型團隊，可能涉及的角色包括前端工程師、后端工程師、算法工程師、數據工程師、質量工程師等。前端工程師以前主要做一些傳統的 GUI 應用，比如有堆疊的導航欄和輸入框。

但在 AI 浪潮下，前端技術架構需要進行升級，不能再依賴傳統的框架。后端工程師過去主要以 Java 為代表的技術棧為主，使用分布式系統的架構。而現在，AI 應用更多依賴 Python 技術棧，框架可能會轉向使用 LangChain 等新的工具。算法工程師以前做的多是機器學習、深度學習的小模型，而現在則是大模型，尤其是 transformer 模型，訓練方法完全不同。

數據工程師過去可能更多使用 SQL 來處理數據，現在則需要做邏輯建模、指標工程，構建符合自然語言交互的數據集市。質量工程師過去測試主要關注功能驗證，而現在的核心任務是構建評測集，提升場景中的準確率、召回率和精確率等指標。核心是要加強這些技能的補充。

吳昊宇：首先，大家需要理解 AI 能夠做什么，不能做什么，這個是通過不斷使用 AI 來摸索和理解的過程。例如，寫代碼的同事需要知道如何通過 AI 代碼編輯器生成代碼，并理解 AI 寫出來的代碼能滿足什么樣的需求。他們需要與 AI 編輯器不斷交互，摸索出最適合的工作流程。

第二點是，AI 在日常工作中的作用。比如我們團隊的成員現在基本上都用 AI 來寫 PPT，這種方式在 PPT 制作上已經發生了巨大的變化。甚至在寫產品文檔時，AI 也在幫助我們完成這些任務。

最后，就是對于 AI Native 產品的理解能力。如何將這些充滿不確定性的內容展示給客戶，使其看起來具有確定性。這不僅是產品設計的問題，也需要研發團隊的同事去思考：如何確保產出的內容能夠最大程度地控制不確定性，并在此基礎上提供一個可交付的效果？這也是我們在工作中不斷摸索和積累出的能力。

AICon 2025 強勢來襲，5 月上海站、6 月北京站，雙城聯動，全覽 AI 技術前沿和行業落地。大會聚焦技術與應用深度融合，匯聚 AI Agent、多模態、場景應用、大模型架構創新、智能數據基建、AI 產品設計和出海策略等話題。即刻掃碼購票，一同探索 AI 應用邊界！！

今日薦文

你也「在看」嗎？