作者 | Tina

采訪嘉賓 | 吳娟

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

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

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

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

1 在金融場景里用 AI：不是先上工具，而是先反復(fù)驗(yàn)證

InfoQ：能不能先介紹一下您所在的部門，以及您現(xiàn)在主要負(fù)責(zé)的工作？

吳娟：我在 25 年初就開始做一些和 AI 落地應(yīng)用推廣相關(guān)的工作了。去年 11 月，神州信息專門成立了 AI 創(chuàng)新中心，下面設(shè)了兩個(gè)部門，一個(gè)是軟件工藝創(chuàng)新部，一個(gè)是業(yè)務(wù)場景創(chuàng)新部，我現(xiàn)在就在軟件工藝創(chuàng)新部。

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

從去年到今年，我們整體的定位一直比較明確，就是基于 AI 來推動(dòng)軟件工藝的智能化升級(jí)。前期會(huì)先從編碼、測試等具體研發(fā)環(huán)節(jié)入手，把 AI 逐步用起來；后續(xù)再往整個(gè)軟件工藝全流程的智能化方向推進(jìn)。

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

InfoQ：AI 這三年從補(bǔ)全到 Agent 的演進(jìn)，對你們帶來的最大變化是什么？你們內(nèi)部有沒有做相應(yīng)的調(diào)整？

吳娟：從時(shí)間上看確實(shí)是三年的演進(jìn)，但對我們來說，真正帶來質(zhì)變的時(shí)間點(diǎn)，其實(shí)是在 2025 年 2 月之后。

我們其實(shí)一直在嘗試，AI 到底能不能在研發(fā)環(huán)節(jié)里真正幫我們提效。前期比較早做的一件事，就是想用大模型來輔助完善設(shè)計(jì)文檔。因?yàn)樵趯?shí)際開發(fā)里，代碼和文檔經(jīng)常會(huì)不一致，團(tuán)隊(duì)在“文碼一致”這件事上會(huì)消耗很多精力。所以我們當(dāng)時(shí)最先切入的一個(gè)場景，就是希望借助 AI 的能力，根據(jù)代碼去同步更新文檔，減少這類維護(hù)成本。但從實(shí)際效果來看，當(dāng)時(shí)生成的文檔質(zhì)量整體是不可用的，這是我們當(dāng)時(shí)一個(gè)比較直接的判斷。

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

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

我們當(dāng)時(shí)看的其實(shí)不只是它能不能幫我們節(jié)省時(shí)間，而是從幾個(gè)維度一起評(píng)估，包括代碼生成質(zhì)量、任務(wù)拆解情況、功能實(shí)現(xiàn)情況，還有一個(gè)最關(guān)鍵的點(diǎn)，就是它到底能不能適配我們現(xiàn)有的開發(fā)模式。

代碼生成質(zhì)量這部分，相對還是比較基礎(chǔ)的，主要看準(zhǔn)確性、健壯性和可讀性。真正要求更高的，其實(shí)是任務(wù)拆解能力。因?yàn)檫@不只是寫代碼的問題，而是它能不能理解我們現(xiàn)有的需求和設(shè)計(jì)文檔，能不能把功能描述覆蓋全。

還有一點(diǎn)對我們特別重要，就是定位能力。因?yàn)槲覀兊南到y(tǒng)不是從零開始搭的，而是在現(xiàn)有產(chǎn)品和解決方案上不斷做增量開發(fā)，所以我們會(huì)特別看它能不能在已有工程里找對位置，修改代碼時(shí)能不能準(zhǔn)確找到對應(yīng)邏輯。同時(shí)也會(huì)看它生成出來的邏輯是不是合理，是否符合業(yè)務(wù)邏輯和執(zhí)行順序。

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

在與現(xiàn)有開發(fā)模式的匹配度上，我們主要看了幾個(gè)方面。

第一是開發(fā)規(guī)范的匹配。也就是說，它能不能符合我們現(xiàn)有的一些基礎(chǔ)要求，比如數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)字典，以及日常開發(fā)中的命名規(guī)范等。

第二是內(nèi)部工程的匹配度。我們會(huì)重點(diǎn)看它能不能識(shí)別我們現(xiàn)有的工程體系，包括已有的架構(gòu)設(shè)計(jì)和長期形成的標(biāo)準(zhǔn)體系，并在這個(gè)基礎(chǔ)上按照既有的架構(gòu)結(jié)構(gòu)去生成代碼。

第三是內(nèi)部文檔的匹配度。因?yàn)槲覀冊诔跗谑褂脮r(shí)也發(fā)現(xiàn)，很多 AI 工具更適合處理 Markdown 這類格式，但我們現(xiàn)有的大量存量文檔，無論是項(xiàng)目、產(chǎn)品研發(fā)還是交付過程中的文檔，很多仍然是以 doc 或者 excel 這類傳統(tǒng)格式來管理的。所以我們也會(huì)評(píng)估，它的引入會(huì)不會(huì)額外增加文檔維護(hù)、格式轉(zhuǎn)換等成本。

當(dāng)然，驗(yàn)證下來也不是沒有問題。我們當(dāng)時(shí)覺得，它在一些基礎(chǔ)錯(cuò)誤上還需要繼續(xù)改進(jìn)，比如類型轉(zhuǎn)換這類問題；另外像依賴包解析、現(xiàn)有開發(fā)規(guī)范的加載，也還不夠穩(wěn)定。再加上上下文長度受限，token 一旦過長，有時(shí)就會(huì)出現(xiàn)任務(wù)中斷這類異常情況。這些都是我們當(dāng)時(shí)重點(diǎn)關(guān)注、也認(rèn)為后續(xù)需要優(yōu)化的地方。

基于這一輪驗(yàn)證，我們在 2025 年 5 月之后，開始在內(nèi)部項(xiàng)目中逐步推廣編程助手的使用，優(yōu)先在一些關(guān)鍵的交付項(xiàng)目中落地。同時(shí)我們也會(huì)重點(diǎn)考慮金融行業(yè)的一些要求，比如數(shù)據(jù)安全、私有化部署等，確保工具能夠真正用在安全的環(huán)境中，沒有后顧之憂。

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

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

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

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

吳娟：從我們的實(shí)踐來看，像 DORA 這類傳統(tǒng)指標(biāo)，在金融行業(yè)其實(shí)不會(huì)因?yàn)?AI 的引入而失效，反而依然是最核心的衡量標(biāo)準(zhǔn)。

比如部署頻率、變更前置時(shí)間、變更失敗率、服務(wù)恢復(fù)時(shí)間，這些對銀行核心系統(tǒng)來說都是非常關(guān)鍵的健康指標(biāo)。因?yàn)殂y行系統(tǒng)上線本身就有非常嚴(yán)格的流程，要提前報(bào)備、審批、對外公告，而且不能隨意停機(jī)，所以生產(chǎn)穩(wěn)定性始終是第一優(yōu)先級(jí)。在這樣的前提下，這些指標(biāo)本身不會(huì)因?yàn)?AI 出現(xiàn)而改變。

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

在質(zhì)量指標(biāo)上，我們依然非?？粗?，比如代碼掃描覆蓋度、缺陷密度等，而且在 AI 介入之后，要求甚至?xí)摺?/p>

我們在做驗(yàn)證時(shí)，是拿真實(shí)項(xiàng)目需求來對比的：一邊是項(xiàng)目組按傳統(tǒng)方式開發(fā)，另一邊是用 AI 編程助手生成代碼再由人工審核。然后用同一套標(biāo)準(zhǔn)去評(píng)估兩邊的結(jié)果。一方面用代碼掃描工具去看問題數(shù)量和分布，另一方面讓測試人員對兩個(gè)版本做同樣的功能驗(yàn)證，統(tǒng)計(jì)缺陷密度，比如千行代碼的缺陷數(shù)量。

從結(jié)果來看，在代碼掃描覆蓋度和缺陷密度這兩個(gè)維度上，AI 生成的代碼和人工開發(fā)基本是持平的。也正是基于這一點(diǎn)，我們才認(rèn)為它在質(zhì)量上是可接受的，具備推廣的前提。所以從這個(gè)角度來說，傳統(tǒng)的質(zhì)量指標(biāo)在 AI 時(shí)代依然是必須堅(jiān)持的。

至于一些效率類指標(biāo)，比如人均代碼行數(shù)、人均提交次數(shù)，我們其實(shí)在 AI 之前就已經(jīng)淡化了。因?yàn)樵谖覀兊臉I(yè)務(wù)場景里，不同角色的工作性質(zhì)差異很大，比如架構(gòu)師可能每天產(chǎn)出的代碼不多，但價(jià)值很高，而一些基礎(chǔ)開發(fā)的提交量可能會(huì)更大，用這種指標(biāo)去衡量并不合理。

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

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

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

不過從我們的實(shí)踐看，一些具體環(huán)節(jié)已經(jīng)開始出現(xiàn)比較明顯的組織級(jí)提效。

比如在測試用例編寫這個(gè)環(huán)節(jié)，原來可能計(jì)劃 5 個(gè)人一個(gè)月來完成，現(xiàn)在借助 AI 生成測試用例，只需要 1 個(gè)人做審核即可，而且在異常場景的覆蓋上，AI 有時(shí)甚至比人工考慮得更全面。在這個(gè)環(huán)節(jié)，我們是可以明確統(tǒng)計(jì)出人力節(jié)省的。

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

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

InfoQ：現(xiàn)在有不少聲音在說，AI 提效最終會(huì)走向裁員，您怎么看？

吳娟：從我們公司的情況來看，短期內(nèi)還不會(huì)出現(xiàn)這種情況。

不過，如果企業(yè)一開始就把“用 AI 提效”的目標(biāo)直接等同于裁員，其實(shí)反而會(huì)影響推廣效果。員工的使用意愿會(huì)明顯下降，甚至?xí)霈F(xiàn)抵觸。

我們?nèi)ツ昃涂吹竭^兩種比較典型的反應(yīng)：一種是覺得 AI 生成的代碼質(zhì)量不行，不愿意用；另一種則是覺得 AI 已經(jīng)能寫得很好了，反而擔(dān)心被替代，也會(huì)產(chǎn)生抗拒心理。

所以我們在推廣的過程中，一直給大家傳導(dǎo)的思想是 AI 不會(huì)淘汰人，但是會(huì)淘法不會(huì)使用 AI 的人，鼓勵(lì)大家用好 AI。AI 其實(shí)是檢驗(yàn)人的水平的試金石，是輔助個(gè)人放大自身優(yōu)勢和能力的工具。

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

另外一個(gè)原因在于，我們面對的是金融這類復(fù)雜業(yè)務(wù)系統(tǒng)，整體工程復(fù)雜度比較高，所以 AI 在代碼生成這一環(huán)節(jié)的效果，目前還存在一定邊界。

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

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

當(dāng)然，隨著模型能力持續(xù)演進(jìn)，再加上我們自己也在做智能體和知識(shí)庫建設(shè)，這種能力還會(huì)繼續(xù)提升。

但至少在當(dāng)前階段，我們認(rèn)為它還不足以替代現(xiàn)有開發(fā)人員，尤其還替代不了那些經(jīng)驗(yàn)比較豐富的開發(fā)人員。

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

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

尤其是在金融合規(guī)這方面，AI 可以生成代碼，但像合規(guī)判斷、數(shù)據(jù)安全邊界的控制，以及在出現(xiàn)問題時(shí)的責(zé)任承擔(dān)，這些都必須由人來完成，而且依賴的是長期積累下來的經(jīng)驗(yàn)。如果把 AI 帶來的提效，直接用來壓縮這部分人力，我們認(rèn)為是一個(gè)風(fēng)險(xiǎn)很高的誤判。

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

3 現(xiàn)在看質(zhì)量，未來看閉環(huán)：生產(chǎn)力考核的變化方向

InfoQ：現(xiàn)在很多大模型廠商會(huì)強(qiáng)調(diào)“AI 生成代碼直接進(jìn)入生產(chǎn)”的比例，你們會(huì)把這個(gè)作為過程指標(biāo)去關(guān)注嗎？

吳娟：我們內(nèi)部其實(shí)更強(qiáng)調(diào)的是人機(jī)協(xié)同，而不是單純?nèi)タ础癆I 生成代碼占比”這樣的指標(biāo)。

即便引入了 AI，我們?nèi)匀挥幸惶妆容^嚴(yán)格的流程規(guī)范。比如 AI 生成的代碼，首先需要對應(yīng)的工程師進(jìn)行審核；工程師提交之后，開發(fā)組長還需要再做一輪代碼 review。整個(gè)過程里，責(zé)任主體始終是開發(fā)人員，最終的提交和責(zé)任歸屬也都是以人為主。

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

InfoQ：現(xiàn)在有些公司會(huì)給開發(fā)者單獨(dú)的 AI 預(yù)算，比如每月幾千美元，用來調(diào)用模型。也有人說“如果不花掉與自己工資相當(dāng)?shù)?Token，就不算用好 AI”。從公司的角度看，這種投入怎么判斷是否合理？

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

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

另外，我們也不會(huì)完全局限在現(xiàn)有的私有化模型上。像最新的一些模型能力，比如 Claude 等，我們也會(huì)做對比評(píng)估，看看在代碼生成等場景下的差異，以及它們具體好在哪里。因?yàn)槲覀冞@個(gè)部門本身就是做軟件工藝創(chuàng)新的，所以會(huì)承擔(dān)一部分“先行探索”的角色。比如對一些新模型、新工具，我們會(huì)在小范圍內(nèi)做試點(diǎn)驗(yàn)證。但這種嘗試是可控的，不會(huì)直接用真實(shí)的全部工程代碼去做。

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

InfoQ：那在使用層面，你們會(huì)不會(huì)去評(píng)估個(gè)人的 ROI，比如有的人資源用得多，但產(chǎn)出相對少？

吳娟：我們目前更多還是正向鼓勵(lì)大家去使用，而不是去做這種“用得多、產(chǎn)出少”的評(píng)價(jià)。因?yàn)椴煌巧g其實(shí)是很難直接用同一套標(biāo)準(zhǔn)去衡量的。比如像架構(gòu)師，在做一份架構(gòu)設(shè)計(jì)方案時(shí)，可能會(huì)基于 AI 做多輪調(diào)研、反復(fù)推敲，過程中調(diào)用次數(shù)會(huì)比較多，但最終產(chǎn)出可能就是一份設(shè)計(jì)文檔，或者幾個(gè)架構(gòu)原型。而開發(fā)人員在做一些相對標(biāo)準(zhǔn)化的功能開發(fā)時(shí)，調(diào)用次數(shù)可能也很多，但對應(yīng)的代碼產(chǎn)出也會(huì)比較多。這兩類工作本身就不具備直接對比的基礎(chǔ)。

所以我們不會(huì)簡單用調(diào)用次數(shù)、資源消耗，或者產(chǎn)出多少，去判斷一個(gè)人的使用效果，更不會(huì)據(jù)此做評(píng)價(jià)。在當(dāng)前階段，我們更看重的是把 AI 用起來、用好。只要它能夠在實(shí)際工作中發(fā)揮作用，對我們來說就是有價(jià)值的。

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

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

比如代碼掃描問題分析、單元測試生成、設(shè)計(jì)文檔補(bǔ)充這類工作，更適合批量執(zhí)行，可以讓 AI 先跑完，再由人集中審核。但像架構(gòu)設(shè)計(jì)、功能開發(fā)這類工作，往往還是需要持續(xù)交互，去確認(rèn)代碼匹配度、功能完整性和業(yè)務(wù)邏輯是否正確。

所以我們更看重的是場景是否合適，而不是簡單判斷哪種方式更好。現(xiàn)階段，我們也不會(huì)因?yàn)橐粋€(gè)人用了 agent 或多 agent，就直接把這類差異納入個(gè)人考評(píng)。

InfoQ：最后一個(gè)問題，現(xiàn)在 Agent 整體還處在比較早期的階段，但從今年開始，它展現(xiàn)出來的能力已經(jīng)有了很大的變化。如果再往未來看 3 到 5 年，變化可能會(huì)更大。您覺得到了那個(gè)時(shí)候，開發(fā)者生產(chǎn)力考核里最需要調(diào)整的，會(huì)是什么？

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

第一點(diǎn)，是考核從“代碼產(chǎn)出”轉(zhuǎn)向“任務(wù)閉環(huán)”。從編碼這個(gè)角度來看，像提交次數(shù)、bug 修復(fù)數(shù)量這些指標(biāo)，肯定不會(huì)再是首要關(guān)注的了。未來更重要的是看任務(wù)有沒有形成閉環(huán)：開發(fā)者和編程助手（智能體）是怎么協(xié)同，把一個(gè)任務(wù)完整地做完，比如能不能把任務(wù)拆解清楚，讓智能體自主完成模塊開發(fā)，包括完成單測、功能驗(yàn)證，甚至自動(dòng)部署到測試環(huán)境，走完內(nèi)部“送測”的流程。

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

因?yàn)槲覀冊谕茝V AI 編碼的過程中也發(fā)現(xiàn)，對于一些能力表現(xiàn)相對更好的人員來說，他們真正拉開差距的一個(gè)點(diǎn)，就在于能不能把自己使用 AI 的經(jīng)驗(yàn)沉淀下來。比如在編碼過程中，他們會(huì)把提示詞，或者我們內(nèi)部說的 rule 規(guī)則，也可以說是 skills，沉淀得非常好。這種沉淀一方面會(huì)直接提升他自己當(dāng)前的代碼生成質(zhì)量，另一方面，這些積累下來的內(nèi)容也可以拿到項(xiàng)目組里給其他人使用，甚至可以跨項(xiàng)目組復(fù)用。因?yàn)楹芏鄦栴}本身就是共性的。

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

第三點(diǎn)，是“可審計(jì)、可追溯”成為基礎(chǔ)能力。不只是看事情有沒有做完，還要看整個(gè)過程是不是可追溯的。因?yàn)榻鹑谲浖Π踩院头€(wěn)定性的要求非常高，銀行系統(tǒng)的穩(wěn)定性通常要做到多個(gè)“9”的級(jí)別，比如核心系統(tǒng)要 99.999%。一旦某個(gè)環(huán)節(jié)出現(xiàn)問題，我們必須能夠追根溯源，找到問題是在哪個(gè)環(huán)節(jié)產(chǎn)生的，而不是只解決表面這一個(gè)問題，而是能夠定位并解決這一類問題。

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

第四點(diǎn)，是從“單一能力”轉(zhuǎn)向“跨域能力”。過去我們的角色劃分比較嚴(yán)格，需求、設(shè)計(jì)、開發(fā)、測試，各個(gè)環(huán)節(jié)的邊界都比較清楚。后面用了 AI 之后，因?yàn)?AI 在各個(gè)環(huán)節(jié)里都可能做得比較好，這其實(shí)會(huì)改變我們對開發(fā)者的考核方式。

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

因?yàn)橐郧伴_發(fā)人員有一個(gè)比較明顯的特點(diǎn)，就是把代碼寫出來、跑通、不報(bào)錯(cuò)，一個(gè)簡單功能實(shí)現(xiàn)了，好像就完成了。他未必真正關(guān)注這個(gè)功能到底實(shí)現(xiàn)了什么、原始需求是什么，所以版本一旦交給測試人員，往往還會(huì)暴露出很多問題。但現(xiàn)在如果用了 AI，它不僅能幫你寫代碼，還能進(jìn)一步生成各種業(yè)務(wù)場景下的測試用例，那開發(fā)人員就需要有能力去判斷，這些業(yè)務(wù)場景是不是都覆蓋到了。

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