陳科｜從底座到 AI，技術人的成長進化論

資深技術專家 陳科

在數字技術持續重構產業格局的今天，從分布式架構到人工智能的技術躍遷，正成為傳統金融行業數字化轉型的核心驅動力，而大模型與企業級知識服務的深度融合，更是券商在科技賦能業務中的關鍵探索方向。

如何將互聯網高并發、微服務與 PaaS 架構的成熟經驗，遷移至強合規、高穩定的金融技術體系；如何通過大模型與企業知識庫建設，破解內部知識沉淀、場景落地、數據安全與應用實效等核心難題，成為金融科技領域亟待突破的焦點議題。

近日，我們有幸邀請到資深技術專家陳科老師，圍繞技術轉型與能力沉淀、金融數字化架構實踐、企業級大模型平臺建設、職業成長與技術路徑選擇，為理解全棧技術能力如何支撐金融 AI 轉型、重構企業技術價值提供深度洞察。

01

風采展示

問1：您好，陳老師！很榮幸有機會采訪到您，先簡單介紹一下您自己！

謝謝主持人，也很高興和大家交流。

我2012年畢業后進入互聯網行業，早期在網易和vivo主要做中間件研發、微服務架構和PaaS基礎設施，長期和高并發、分布式系統、服務治理這些問題打交道。后來進入證券行業，參與金融科技平臺和數字化轉型相關工作，把互聯網架構思維帶到金融場景里。最近兩年，隨著大模型技術的發展，我又把工作重心逐步轉向企業知識庫和大模型應用落地。一路走來，從中間件到平臺，再到AI應用，我一直在做一件事，就是用技術解決復雜業務問題。

問題2：從互聯網到券商，再切入大模型，三次大的方向躍遷，您是如何快速建立新領域認知，并把過往經驗遷移過去的？

我進入一個新領域，通常先做三件事。第一，快速建立全局認知，先把業務鏈路、核心系統、關鍵約束搞清楚。第二，分辨哪些是行業特有的，哪些是通用規律。比如架構設計、穩定性治理、平臺化建設，這些底層方法在很多行業都是通的；變化更多是在業務語義、監管要求和落地方式上。第三，就是盡快通過真實項目把認知壓實。因為很多東西只有做過才真正理解。對我來說，跨領域不是推倒重來，而是把過去積累的能力，在新問題上重新組合、持續升級。

問題3：隨著技術的快速發展，如何保持對新技術、新趨勢的敏感度？你平時通過哪些渠道獲取行業前沿信息，又是如何篩選和判斷哪些信息對自己有價值并值得深入學習的？

我覺得保持敏感度很重要，但更重要的是判斷力。平時我主要通過幾個渠道獲取信息：一是頭部技術公司、云廠商、開源社區和技術博客，二是行業會議和同行交流，三是和業務、監管相關的信息。因為尤其在金融行業，技術能不能落地，不只是看先進不先進，還要看業務價值和合規邊界。至于篩選，我主要看四點：是不是在解決真實問題，能不能工程化落地，和當前業務階段是否匹配，能不能沉淀成長期能力。很多熱點我不會一上來就重投入，而是先做小范圍驗證，看效果、成本和復雜度，再決定要不要深入。

02

微服務架構與PaaS基礎設施

問題4：在金融行業進行數字化轉型過程中，遇到了哪些技術難點和問題，是如何解決這些問題的？

金融行業數字化轉型最大的難點，不是在新系統上做建設，而是在大量存量系統之上做升級。這里面往往是多廠商、多技術棧、強監管、不能輕易中斷，這幾個問題疊加在一起。我們的做法不是一刀切替換，而是先做分層治理和標準化接入。通過統一網關、統一 API 管理、服務邊界梳理，把新老系統逐步接起來。對于受監管業務，則強調訪問隔離，核心服務盡量放在私有域里，對外只通過全局網關暴露有限 API，并做好鑒權和權限控制。同時在治理上，把核心 API、高延遲 API、外部 API 做分組隔離，發布必須灰度、滾動、可回滾。我的體會是，金融行業轉型的關鍵不是上了多少新技術，而是能不能在復雜存量和強監管約束下，穩步演進。

問題5：在微服務架構落地過程中，服務治理、限流、熔斷、降級這幾塊，您踩過最致命的坑是什么？

這個更多是我在互聯網公司時期做高并發系統時的經驗。踩得最深的坑，其實是治理策略過于粗暴，把局部問題放大成整體問題。比如下游只是少量實例抖動，但上游熔斷做得太粗，一觸發就把整個服務都熔斷了，結果本來只是局部異常，最后變成全鏈路不可用。還有一種情況是限流只考慮‘攔’，沒有考慮‘攔完以后怎么辦’，所有請求直接失敗，核心和非核心業務沒有區分，限流、熔斷、降級沒有按照層級和維度去區分，導致用戶體驗會非常差。我記得在網易工作時，APP推薦首頁就是一個高并場景，我們就是通過不同層級，不同維度去落地的，例如按照用戶比例去限流和降級，保障確保VIP用戶正常可用，保障普通用戶在觸發降級時看到的兜底內容是一致的。再就是重試配置不當，本來是為了提高成功率，結果在高并發下反而把下游打穿了。

所以我后來最大的經驗是，限流、熔斷、降級一定要分層、分級、分粒度設計，不能用統一模板一把梭。

問題6：做高并發系統時，是如何做容量規劃、壓測體系與全鏈路監控的？有哪些關鍵指標？

這部分也是我在互聯網時期的工作體會。高并發系統最核心的，不是流量來了能不能扛一次，而是你知不知道自己的邊界在哪里。容量規劃上，我一般會從業務峰值倒推整條鏈路，包括網關、應用、緩存、數據庫、消息隊列和外部依賴，最后形成容量模型，并且預留冗余。壓測體系不能只做單接口壓測，還要做核心場景壓測、混合流量壓測、全鏈路壓測，甚至故障演練，驗證系統在異常情況下能不能穩住。監控方面，除了 CPU、內存這些基礎指標，更要看 QPS、TPS、P95、P99、錯誤率、超時率、線程池、連接池、消息積壓，以及關鍵業務成功率。我的經驗是，真正的穩定性來自提前發現邊界，而不是出問題后再補救。”

03

技術實踐與落地

問題7：在券商內部建設企業知識庫平臺時，如何選擇適合金融領域知識處理的大模型，考慮了哪些模型性能指標和金融業務特點，不同模型之間有哪些差異和優劣？

企業知識庫平臺的核心，其實不只是選模型，而是知識治理、檢索體系、權限體系和模型能力的整體組合。金融場景里，不能簡單追求‘哪個模型最強’，而要先看場景到底要解決什么問題，是問答、檢索、總結、審核，還是結構化抽取。選型時我主要看幾個指標：專業理解能力、事實準確性、幻覺控制、長文本處理能力、結構化輸出能力、響應速度和部署成本。同時還要重點考慮私有化、安全隔離和審計留痕。閉源模型通常通用能力更強、效果更穩定，適合快速驗證；開源模型則更可控、更適合私有化和深度定制。所以實際落地時，往往不是單模型，而是基座模型、Embedding、Rerank、規則和權限系統組合起來一起工作。

問題8：券商擁有海量但分散的數據，大模型應用需要高質量、結構化的數據支持，如何建立有效的數據治理體系，對數據進行清洗、整合和標注，為大模型提供優質的數據輸入，有哪些數據治理工具和流程？

我一直認為，大模型在企業里的上限，很多時候是由數據治理決定的。券商的數據特點不是少，而是多、散、雜，而且權限邊界復雜、口徑不統一。所以第一步一定是數據盤點和分類分級，先搞清楚數據歸誰管、能不能用、有沒有敏感風險。第二步是標準化清洗和結構化處理，包括去重、糾錯、版本識別、元數據補全、標簽和摘要生成。第三步是權限和安全治理，要做到按業務域、按部門、按角色細粒度授權。第四步是效果反饋閉環，根據召回準確率、人工審核意見和實際使用效果持續優化。工具上會涉及文檔解析、OCR、元數據管理、脫敏、標注審核、向量檢索和評測體系，但核心還是要形成持續迭代的數據治理流程。

問題9：金融監管政策不斷更新變化，大模型在券商應用中如何確保實時跟進并滿足新的合規要求，例如在反洗錢、投資者適當性管理等場景，有沒有建立動態的合規監測機制嵌入到大模型應用流程中？

在券商場景里，大模型不能只追求能力強，更要追求可控、可審計、可糾偏。我的理解是，合規必須前置，嵌入整個應用流程，而不是事后補丁。我們的思路是把外部監管要求和內部制度要求持續沉淀成動態更新的知識和制度體系，也就是常說的‘外規內化’。具體做法上，一層是知識檢索，確保模型引用的是最新、權威的制度依據；一層是規則校驗，對敏感內容和關鍵場景做硬約束；再往上是人工復核和審計留痕。像反洗錢、投資者適當性管理這些場景，我認為大模型更適合做輔助識別、歸納總結和風險提示，而不應該直接替代最終判斷。這樣既能提高效率，也能守住合規底線。

04

行業洞察與未來思考力

問題10：隨著大模型技術的不斷發展，未來在券商業務中還可能拓展出哪些新的應用場景，對于這些潛在場景，目前做了哪些前瞻性的研究和準備？

我覺得未來大模型在券商里的應用空間會非常大，而且不會只停留在智能問答這種淺層場景。隨著模型能力、工具調用能力和企業治理能力逐步成熟，它會從信息輔助，慢慢走向流程輔助，再進一步走向業務協同。

具體看，我比較看好的方向有幾類：一類是“外規內化”，比如監管規則理解、制度對齊、變更影響分析、執行檢查等，幫助機構把外部規則更快轉化成內部可執行能力；第二類是“數字員工”，比如投研、運營、合規、研發、客服等崗位的輔助；第三類是“智能工具化”場景，比如合同審核、制度文件審核、會議紀要、知識檢索、材料撰寫等，這類場景邊界清晰、收益也更容易驗證，應該優先落地。再往后，還可以逐步延伸到投顧輔助、財富管理、投行業務支持、風險排查、培訓傳承等更深層業務。

不過我覺得現階段也不能太激進，更現實的策略還是優先瞄準業內相對成熟的場景，讓子彈先飛一會。因為開源模型和智能體方案迭代非常快，今天花很大力氣做的定制優化，可能下一次模型升級后就被快速覆蓋，收益反而不如直接升級模型。比如有些最近很火的開源 Agent 方案，更適合個人產品，離企業級、強合規的券商場景還有距離。所以我認為現階段更重要的是先把知識庫、智能體平臺、模型服務平臺和安全治理底座搭好，為后續規模化落地做準備。

問題11：大模型正在重構技術棧，你認為未來工程師的核心能力模型會發生怎樣的變化？

我認為未來工程師的核心能力模型會繼續上移，但不是簡單地從“代碼實現者”變成“系統設計者”，因為今天的大模型和智能編程工具已經開始深入參與設計本身。真正稀缺的能力，將越來越體現在對問題和約束的定義、對方案優劣的判斷、對復雜系統的取舍，以及對最終結果的驗證和責任承擔上。換句話說，未來工程師依然要懂實現，也依然要懂設計，但更核心的競爭力會轉向“駕馭設計與實現過程”的能力。誰能把業務目標、系統約束、數據條件、風險邊界和工具能力說清楚，誰就更能借助AI放大產出。因此，未來工程師最重要的能力，第一不是單點編碼能力，第二也不只是傳統意義上的架構設計能力，而是更高一層的系統級判斷能力與人機協作編排能力。前者決定做什么、為什么這樣做，后者決定如何把模型、工具、流程和人工協同組織成一個可靠閉環。從這個意義上說，工程師不會被壓縮成“提示詞操作員”，也不會只剩下寫代碼或畫架構圖，而會逐步演變成面向復雜問題的解決者、約束定義者、結果校驗者和智能系統的指揮者。