當互聯網用AI卷效率時，這家公司先問了一連串“能不能”

作者 | Tina

采訪嘉賓 | 吳娟

在金融行業，引入一項新技術從來不是一場“軍備競賽”，而是一場嚴苛的“壓力測試”。當 AI 編程工具以驚人的提效速度席卷整個軟件行業，許多互聯網公司和小型團隊迅速將“代碼行數”和“Token 消耗”掛上績效考核，甚至直接與裁員掛鉤時，神州信息這家深耕銀行核心軟件系統的金融科技企業，卻選擇了一條截然不同的路。

它沒有盲目跟風，而是先回到了一個根本問題：我們到底該不該用 AI？ 從 2025 年初開始，神州信息展開了一場長達數月的系統性驗證。他們不滿足于“代碼生成快不快”，而是用真實的金融項目需求做對比測試，從代碼質量、任務拆解能力、存量工程匹配度，到開發規范與文檔體系的兼容性，每一個維度都經過反復校驗，直到確認 AI 生成的代碼在缺陷密度和掃描覆蓋度上與人工開發“基本持平”，才謹慎地邁出推廣的第一步。

更關鍵的是，當外界將“提效”與“裁員”劃等號時，神州信息給出了完全不同的答案。面對金融系統固有的復雜性——賬務一致性、7×24 小時高可用、嚴格的合規與問責——他們深知，AI 現階段只能作為經驗工程師的“副駕駛”，而非替代者。省下來的人效，被用來承接更多項目、覆蓋更多場景，而非減少一個崗位。他們甚至警惕“能力斷層”的風險，堅持保留初級工程師的培養路徑。

正是這種基于嚴謹驗證、拒絕激進裁員、重視人機協同的實踐，讓神州信息在喧囂的“AI 取代人類”敘事中，提供了一個稀缺而理性的樣本。下面這篇對神州信息軟件工藝創新部的獨家專訪，將帶你深入一家金融科技企業如何科學地落地 AI，了解它的邏輯、它的指標，以及它對未來開發者能力的冷靜預判。

1 在金融場景里用 AI：不是先上工具，而是先反復驗證

InfoQ：能不能先介紹一下您所在的部門，以及您現在主要負責的工作？

吳娟：我在 25 年初就開始做一些和 AI 落地應用推廣相關的工作了。去年 11 月，神州信息專門成立了 AI 創新中心，下面設了兩個部門，一個是軟件工藝創新部，一個是業務場景創新部，我現在就在軟件工藝創新部。

神州信息一方面是一家軟件公司，另一方面又長期為銀行提供金融軟件服務，所以我們在軟件工藝上本身就有比較深的積累，包括開發規范、技術棧、技術架構等。去年 AI 開始大規模落地之后，公司也希望把 AI 真正融入現有的軟件工藝過程中，切實去推動降本增效。我們這個部門，主要就是在這個方向上做應用落地和智能化改造。

從去年到今年，我們整體的定位一直比較明確，就是基于 AI 來推動軟件工藝的智能化升級。前期會先從編碼、測試等具體研發環節入手，把 AI 逐步用起來；后續再往整個軟件工藝全流程的智能化方向推進。

同時，公司管理層對 AI 的價值一直非常認可。從去年開始，組織層面就在持續推動“AI for process”這件事。無論是內部提效，還是面向外部業務和交付，公司都希望盡可能去嘗試、去挖掘 AI 能真正帶來的價值。

InfoQ：AI 這三年從補全到 Agent 的演進，對你們帶來的最大變化是什么？你們內部有沒有做相應的調整？

吳娟：從時間上看確實是三年的演進，但對我們來說，真正帶來質變的時間點，其實是在 2025 年 2 月之后。

我們其實一直在嘗試，AI 到底能不能在研發環節里真正幫我們提效。前期比較早做的一件事，就是想用大模型來輔助完善設計文檔。因為在實際開發里，代碼和文檔經常會不一致，團隊在“文碼一致”這件事上會消耗很多精力。所以我們當時最先切入的一個場景，就是希望借助 AI 的能力，根據代碼去同步更新文檔，減少這類維護成本。但從實際效果來看，當時生成的文檔質量整體是不可用的，這是我們當時一個比較直接的判斷。

轉折點出現在 2025 年初。一方面是模型能力明顯提升，比如 DeepSeek 等模型出來之后，效果有了一個明顯躍遷；另一方面，編程助手工具開始快速豐富起來，像 Cursor、通義靈碼這一類工具逐漸成熟。我們也在這個階段開始引入工具做系統性的驗證，整體感受是：對 AI 的認知需要重新評估了。

當時我們專門選了一款編程助手工具做深入驗證，核心不只是看這類工具能不能生成代碼，更重要的是看它能不能適配我們現有的研發模式，尤其能不能用于金融行業這類業務復雜、系統復雜的軟件開發場景。驗證之后，我們的判斷是，它整體上能夠達到預期。

我們當時看的其實不只是它能不能幫我們節省時間，而是從幾個維度一起評估，包括代碼生成質量、任務拆解情況、功能實現情況，還有一個最關鍵的點，就是它到底能不能適配我們現有的開發模式。

代碼生成質量這部分，相對還是比較基礎的，主要看準確性、健壯性和可讀性。真正要求更高的，其實是任務拆解能力。因為這不只是寫代碼的問題，而是它能不能理解我們現有的需求和設計文檔，能不能把功能描述覆蓋全。

還有一點對我們特別重要，就是定位能力。因為我們的系統不是從零開始搭的，而是在現有產品和解決方案上不斷做增量開發，所以我們會特別看它能不能在已有工程里找對位置，修改代碼時能不能準確找到對應邏輯。同時也會看它生成出來的邏輯是不是合理，是否符合業務邏輯和執行順序。

功能實現這一塊，我們更關注的是完整性。也就是說，它不只是把主流程做出來，還要把異常情況和邊界場景一并覆蓋到。

在與現有開發模式的匹配度上，我們主要看了幾個方面。

第一是開發規范的匹配。也就是說，它能不能符合我們現有的一些基礎要求，比如數據標準、數據字典，以及日常開發中的命名規范等。

第二是內部工程的匹配度。我們會重點看它能不能識別我們現有的工程體系，包括已有的架構設計和長期形成的標準體系，并在這個基礎上按照既有的架構結構去生成代碼。

第三是內部文檔的匹配度。因為我們在初期使用時也發現，很多 AI 工具更適合處理 Markdown 這類格式，但我們現有的大量存量文檔，無論是項目、產品研發還是交付過程中的文檔，很多仍然是以 doc 或者 excel 這類傳統格式來管理的。所以我們也會評估，它的引入會不會額外增加文檔維護、格式轉換等成本。

當然，驗證下來也不是沒有問題。我們當時覺得，它在一些基礎錯誤上還需要繼續改進，比如類型轉換這類問題；另外像依賴包解析、現有開發規范的加載，也還不夠穩定。再加上上下文長度受限，token 一旦過長，有時就會出現任務中斷這類異常情況。這些都是我們當時重點關注、也認為后續需要優化的地方。

基于這一輪驗證，我們在 2025 年 5 月之后，開始在內部項目中逐步推廣編程助手的使用，優先在一些關鍵的交付項目中落地。同時我們也會重點考慮金融行業的一些要求，比如數據安全、私有化部署等，確保工具能夠真正用在安全的環境中，沒有后顧之憂。

I*nfoQ：也有人認為，AI 現在的提效主要還是集中在寫代碼這一段，對整個軟件工程鏈路的影響其實還比較有限，您怎么看？

吳娟：這個說法其實是成立的，但只說對了一半。編碼確實是最容易被 AI 改造的環節，但它在整個軟件工藝流程里的占比本身就不算太高，所以如果只停在這里，整體提效是有限的。所以我們一開始也是從編碼切入，但很快就往測試、需求、設計這些環節去擴展，比如用 AI 生成測試用例、測試腳本，或者在需求和設計階段用智能體去輔助相關角色。

2 AI 提效，不是為了裁人，而是為了解決人手不夠

InfoQ：在引入 AI 之后，研發提效應該怎么衡量？像 DORA、SPACE 這些體系還適用嗎，還是需要新增一些指標？

吳娟：從我們的實踐來看，像 DORA 這類傳統指標，在金融行業其實不會因為 AI 的引入而失效，反而依然是最核心的衡量標準。

比如部署頻率、變更前置時間、變更失敗率、服務恢復時間，這些對銀行核心系統來說都是非常關鍵的健康指標。因為銀行系統上線本身就有非常嚴格的流程，要提前報備、審批、對外公告，而且不能隨意停機，所以生產穩定性始終是第一優先級。在這樣的前提下，這些指標本身不會因為 AI 出現而改變。

另外，SPACE 這類框架本身就是從人的視角出發的，所以到了 AI 時代，我覺得它反而更有洞察力。像滿意度、績效、溝通協作這些維度都不會變。AI 更多是作為一個新的成員，或者輔助成員，參與到這些維度里面。

在質量指標上，我們依然非?？粗?，比如代碼掃描覆蓋度、缺陷密度等，而且在 AI 介入之后，要求甚至會更高。

我們在做驗證時，是拿真實項目需求來對比的：一邊是項目組按傳統方式開發，另一邊是用 AI 編程助手生成代碼再由人工審核。然后用同一套標準去評估兩邊的結果。一方面用代碼掃描工具去看問題數量和分布，另一方面讓測試人員對兩個版本做同樣的功能驗證，統計缺陷密度，比如千行代碼的缺陷數量。

從結果來看，在代碼掃描覆蓋度和缺陷密度這兩個維度上，AI 生成的代碼和人工開發基本是持平的。也正是基于這一點，我們才認為它在質量上是可接受的，具備推廣的前提。所以從這個角度來說，傳統的質量指標在 AI 時代依然是必須堅持的。

至于一些效率類指標，比如人均代碼行數、人均提交次數，我們其實在 AI 之前就已經淡化了。因為在我們的業務場景里，不同角色的工作性質差異很大，比如架構師可能每天產出的代碼不多，但價值很高，而一些基礎開發的提交量可能會更大，用這種指標去衡量并不合理。

即便在 AI 介入之后，這類指標可能更容易“做高”，但從軟件質量和業務價值的角度來看，它們并不能反映真實的工程效果，尤其是在金融行業，這類指標的參考意義其實是比較有限的。

InfoQ：很多人覺得，AI 帶來的提效更多還是停留在個人層面，還沒有真正反映到組織績效上，您怎么看？您這邊的情況是怎樣的？

吳娟：這種情況確實存在。AI 在初期更多體現為個人提效，比如原來兩天做完的事，現在一天就能做完。但從項目整體來看，人員投入和交付周期未必馬上會變，所以這部分效率提升，短期內不一定能直接反映到組織績效上。

不過從我們的實踐看，一些具體環節已經開始出現比較明顯的組織級提效。

比如在測試用例編寫這個環節，原來可能計劃 5 個人一個月來完成，現在借助 AI 生成測試用例，只需要 1 個人做審核即可，而且在異常場景的覆蓋上，AI 有時甚至比人工考慮得更全面。在這個環節，我們是可以明確統計出人力節省的。

再比如文檔維護，特別是“文碼一致性”這類工作。以前在項目交付后期，如果代碼和設計文檔嚴重不匹配，往往需要投入大約 15 個左右的人月來做文檔補齊和修訂?，F在通過 AI 根據代碼反向生成設計文檔，這部分工作可以縮減到 3 到 5 個人月，節省效果也比較直觀。

所以從我們的實際情況來看，AI 帶來的提效，確實是可以逐步體現在組織層面的，只是它不是一開始就以“整體效率提升”的形式出現，而是先從局部環節突破，再慢慢累積出來。

InfoQ：現在有不少聲音在說，AI 提效最終會走向裁員，您怎么看？

吳娟：從我們公司的情況來看，短期內還不會出現這種情況。

不過，如果企業一開始就把“用 AI 提效”的目標直接等同于裁員，其實反而會影響推廣效果。員工的使用意愿會明顯下降，甚至會出現抵觸。

我們去年就看到過兩種比較典型的反應：一種是覺得 AI 生成的代碼質量不行，不愿意用；另一種則是覺得 AI 已經能寫得很好了，反而擔心被替代，也會產生抗拒心理。

所以我們在推廣的過程中，一直給大家傳導的思想是 AI 不會淘汰人，但是會淘法不會使用 AI 的人，鼓勵大家用好 AI。AI 其實是檢驗人的水平的試金石，是輔助個人放大自身優勢和能力的工具。

所以從組織推進的角度來看，AI 的落地不僅是技術問題，也是人的問題。如果一開始就把它和裁員綁定在一起，這件事本身就很難真正推開。

另外一個原因在于，我們面對的是金融這類復雜業務系統，整體工程復雜度比較高，所以 AI 在代碼生成這一環節的效果，目前還存在一定邊界。

這里面一方面是代碼生成之后的可用度問題，另一方面也和具體場景有關。并不是所有場景都適合交給 AI。比如一些復雜的賬務處理、事務一致性保障，以及銀行 7×24 小時運行機制相關的代碼實現，這些都高度依賴長期積累下來的工程經驗，只有對業務和系統都非常熟悉的人，才能寫出足夠穩健的代碼。

AI 目前在一些相對簡單、標準化程度更高的場景里，效果還是比較明顯的，比如查詢、交易處理，或者增刪改查這類業務邏輯。在金融這類復雜業務系統的開發過程中，它現階段更適合承擔輔助角色，幫助研發人員完成其中一部分工作。

當然，隨著模型能力持續演進，再加上我們自己也在做智能體和知識庫建設，這種能力還會繼續提升。

但至少在當前階段，我們認為它還不足以替代現有開發人員，尤其還替代不了那些經驗比較豐富的開發人員。

從另一個角度來看，如果只保留經驗豐富的開發人員，而忽略初級工程師的培養，反而可能帶來能力斷層。在金融系統開發中，這種斷層的代價是很高的。當中間層級出現斷檔時，知識傳遞會受影響，進而影響系統穩定性。所以 AI 并不能簡單地用來替代某一類人群，尤其不能通過削減初級工程師來換取所謂的效率提升。

從我們服務的客戶來看，銀行本身就受到嚴格監管，對合規、安全、穩定性都有很高要求。在新技術應用上，我們也會更關注這些方面。所以現階段，AI 生成的代碼仍然需要結合人工審核和把關，才能更好地應用到金融場景中。從這個角度來看，AI 目前更多還是起到輔助作用，還不足以支撐人員的直接縮減。

尤其是在金融合規這方面，AI 可以生成代碼，但像合規判斷、數據安全邊界的控制，以及在出現問題時的責任承擔，這些都必須由人來完成，而且依賴的是長期積累下來的經驗。如果把 AI 帶來的提效，直接用來壓縮這部分人力，我們認為是一個風險很高的誤判。

所以從我們的實際情況來看，目前的思路并不是“用 AI 減少人”。一方面，我們本身項目就比較多，經常會出現人員緊張、資源不夠用的情況；另一方面，我們更希望把 AI 節省出來的人效，用來承接更多項目、覆蓋更多場景，是把事情做得更多，而不是把做事的人變少。

3 現在看質量，未來看閉環：生產力考核的變化方向

InfoQ：現在很多大模型廠商會強調“AI 生成代碼直接進入生產”的比例，你們會把這個作為過程指標去關注嗎？

吳娟：我們內部其實更強調的是人機協同，而不是單純去看“AI 生成代碼占比”這樣的指標。

即便引入了 AI，我們仍然有一套比較嚴格的流程規范。比如 AI 生成的代碼，首先需要對應的工程師進行審核；工程師提交之后，開發組長還需要再做一輪代碼 review。整個過程里，責任主體始終是開發人員，最終的提交和責任歸屬也都是以人為主。

所以我們并不會特別去強調“有多少 AI 代碼直接進入生產”。從金融客戶的角度來看，這類指標本身也不是他們最關心的。和一些互聯網公司的開發模式相比，我們的流程會更加嚴格。所有代碼都需要經過完整的開發、審核、測試流程，包括多輪測試和回歸驗證之后，才會進入不同環境，比如測試環境、行方的 FAT、UAT，最終再到生產環境。而在生產環節，流程會更加嚴格。所以在整個過程中，一定是有人參與、有多環節把控的，而不是簡單地把 AI 生成的代碼直接部署到生產環境。

InfoQ：現在有些公司會給開發者單獨的 AI 預算，比如每月幾千美元，用來調用模型。也有人說“如果不花掉與自己工資相當的 Token，就不算用好 AI”。從公司的角度看，這種投入怎么判斷是否合理？

吳娟：我們的情況和很多互聯網公司不太一樣。很多互聯網公司是基于公有云環境，直接調用像 Claude、Gemini、GPT 或國內的這類模型，所以成本主要體現在 token 消耗上。但在我們這里，天然就有私有化部署的要求。尤其是銀行客戶，關鍵系統大多還是要求在私有環境中運行。所以我們整體的投入，不是在 token 上，而是在 GPU 資源上。

目前我們是自采 GPU 資源，在內部部署模型，比如 DeepSeek、智譜 GLM 等。這種模式下，對開發者個人來說，并不存在“token 用多少”的成本問題，主要是公司層面的資源投入。

另外，我們也不會完全局限在現有的私有化模型上。像最新的一些模型能力，比如 Claude 等，我們也會做對比評估，看看在代碼生成等場景下的差異，以及它們具體好在哪里。因為我們這個部門本身就是做軟件工藝創新的，所以會承擔一部分“先行探索”的角色。比如對一些新模型、新工具，我們會在小范圍內做試點驗證。但這種嘗試是可控的，不會直接用真實的全部工程代碼去做。

整體來看，這部分外部資源的消耗其實是比較小的，公司也可以支持。對我們來說，更核心的投入，還是在 GPU 資源這一塊。

InfoQ：那在使用層面，你們會不會去評估個人的 ROI，比如有的人資源用得多，但產出相對少？

吳娟：我們目前更多還是正向鼓勵大家去使用，而不是去做這種“用得多、產出少”的評價。因為不同角色之間其實是很難直接用同一套標準去衡量的。比如像架構師，在做一份架構設計方案時，可能會基于 AI 做多輪調研、反復推敲，過程中調用次數會比較多，但最終產出可能就是一份設計文檔，或者幾個架構原型。而開發人員在做一些相對標準化的功能開發時，調用次數可能也很多，但對應的代碼產出也會比較多。這兩類工作本身就不具備直接對比的基礎。

所以我們不會簡單用調用次數、資源消耗，或者產出多少，去判斷一個人的使用效果，更不會據此做評價。在當前階段，我們更看重的是把 AI 用起來、用好。只要它能夠在實際工作中發揮作用，對我們來說就是有價值的。

InfoQ：從個人評價的角度來看，現在有些開發者會大量使用 agent，甚至通過并行方式來完成工作；而有些人仍然停留在輔助型用法。不同使用方式帶來的生產力差異非常明顯。如果從個人考評的維度來看，這種差異你們會納入考量嗎？

吳娟：不同用法帶來的效率差異確實很明顯。像輔助式用法，更多是持續交互；而 agent，尤其是多 agent，在一些批量處理場景里效率會更高。

比如代碼掃描問題分析、單元測試生成、設計文檔補充這類工作，更適合批量執行，可以讓 AI 先跑完，再由人集中審核。但像架構設計、功能開發這類工作，往往還是需要持續交互，去確認代碼匹配度、功能完整性和業務邏輯是否正確。

所以我們更看重的是場景是否合適，而不是簡單判斷哪種方式更好?，F階段，我們也不會因為一個人用了 agent 或多 agent，就直接把這類差異納入個人考評。

InfoQ：最后一個問題，現在 Agent 整體還處在比較早期的階段，但從今年開始，它展現出來的能力已經有了很大的變化。如果再往未來看 3 到 5 年，變化可能會更大。您覺得到了那個時候，開發者生產力考核里最需要調整的，會是什么？

吳娟：我覺得變化一定會非常大?，F在開發者使用 AI 工具，已經不只是最早那種問一句答一句的輔助方式了，而是在往“直接把任務做完”這個方向走。以前很多事情還需要反復交互，但隨著多智能體協作越來越成熟，現在有些任務其實已經能由智能體自己閉環完成了。比如生成一份完整的 PPT，并直接放到指定路徑下，這種能力已經開始應用了。

第一點，是考核從“代碼產出”轉向“任務閉環”。從編碼這個角度來看，像提交次數、bug 修復數量這些指標，肯定不會再是首要關注的了。未來更重要的是看任務有沒有形成閉環：開發者和編程助手（智能體）是怎么協同，把一個任務完整地做完，比如能不能把任務拆解清楚，讓智能體自主完成模塊開發，包括完成單測、功能驗證，甚至自動部署到測試環境，走完內部“送測”的流程。

第二點，是從“個人產出”轉向“可復用能力和知識沉淀”。不再只關注代碼寫得好不好，而是要看這個人的表達能力和邏輯完整性。換句話說，他是否能夠“教會 AI 做事”，是否能夠構建可復用的 Agent。這里有兩個關鍵點：一是 Agent 本身可以復用，二是過程中沉淀的知識庫、知識模板（例如提示詞、規則、模板）可以積累下來。

因為我們在推廣 AI 編碼的過程中也發現，對于一些能力表現相對更好的人員來說，他們真正拉開差距的一個點，就在于能不能把自己使用 AI 的經驗沉淀下來。比如在編碼過程中，他們會把提示詞，或者我們內部說的 rule 規則，也可以說是 skills，沉淀得非常好。這種沉淀一方面會直接提升他自己當前的代碼生成質量，另一方面，這些積累下來的內容也可以拿到項目組里給其他人使用，甚至可以跨項目組復用。因為很多問題本身就是共性的。

所以在這種情況下，后面可能就要更多去看，一個人在知識沉淀上的貢獻，或者說在智能體訓練上的貢獻。換句話說，就是他能不能成為一個“教會智能體做事”的人。通過這些能力，其實是為了提升 Agent 的復用能力，從代碼層面來看，就是提升代碼的可用度，以及在不同項目之間的復用占比。

第三點，是“可審計、可追溯”成為基礎能力。不只是看事情有沒有做完，還要看整個過程是不是可追溯的。因為金融軟件對安全性和穩定性的要求非常高，銀行系統的穩定性通常要做到多個“9”的級別，比如核心系統要 99.999%。一旦某個環節出現問題，我們必須能夠追根溯源，找到問題是在哪個環節產生的，而不是只解決表面這一個問題，而是能夠定位并解決這一類問題。

盡管很多工作可以交給智能體，但人依然需要具備能力去理解它做了什么。要能夠跟蹤 Agent 的行為軌跡，知道每一步的推理和調用關系。同時，開發者最終還是要對結果負責，這樣在出現問題之后，才能保證整個過程是可追溯、可回放的。

第四點，是從“單一能力”轉向“跨域能力”。過去我們的角色劃分比較嚴格，需求、設計、開發、測試，各個環節的邊界都比較清楚。后面用了 AI 之后，因為 AI 在各個環節里都可能做得比較好，這其實會改變我們對開發者的考核方式。

以前有些開發人員開發能力很強，但業務理解能力不夠，或者需求溝通能力不夠，未來這類單一能力可能就不夠了。后面可能會更看重廣度，而不只是深度，或者說，更看重這種跨域連接的能力。也就是他能不能把業務、數據和 AI 能力打通，成為中間的連接者；能不能讓智能體理解公司整個開發流程，并在這個基礎上去完成任務、優化過程；同時還要具備需求驗證的能力，以及從整體上閉環去看任務驗收的能力。

因為以前開發人員有一個比較明顯的特點，就是把代碼寫出來、跑通、不報錯，一個簡單功能實現了，好像就完成了。他未必真正關注這個功能到底實現了什么、原始需求是什么，所以版本一旦交給測試人員，往往還會暴露出很多問題。但現在如果用了 AI，它不僅能幫你寫代碼，還能進一步生成各種業務場景下的測試用例，那開發人員就需要有能力去判斷，這些業務場景是不是都覆蓋到了。

所以對開發人員來說，未來需要具備的，是一種從前到后、能夠把整個任務看完整的能力。