一間項目室裡長出的Qoder：阿里如何用一支AI Native團隊，押注Agent時代的入口

飛向TAI空2026.09.30 16:12 · 來自北京全文14106字當AI開始改變軟件生產，一支親自使用這些能力的團隊，會如何重新組織自己？2026年9月22日，杭州，雲棲大會技術主論壇。阿里巴巴ATH事業群副總裁、Qoder產品線總裁丁宇（花名叔同）站上講臺，帶來題為“不止編程，無限創造”的演講。他宣佈，Qoder全新升級為“面向所有人的Agentic Coding平臺”。這一天，距離Qoder在西溪園區一間小項目室裡成立，剛好478天。478天裡，Qoder從一款AI IDE，發展為覆蓋桌面、IDE、CLI、雲端、移動端和數字員工的產品家族。

據Qoder方面披露，其全球用戶已超過800萬。產品面對的人群也在變化：從專業開發者，到不以編程為職業的普通用戶，再到希望將Agent納入業務流程的企業。變化同樣發生在團隊內部。這支最初人數不多的創新團隊，已經成為阿里內部AI Native實踐最深入的團隊之一。演講結束後，聯合創始人劉湘明與丁宇再次坐到一起。一年前，兩人在雲棲大會上談論的，主要還是AI如何幫助人寫代碼。一年後，近一個小時的對話已經越過編程本身，延伸到軟件工程、組織協作，以及人在AI時代究竟應該保留什麼能力。因此，這場對話不只是關於一款編程產品如何擴張邊界。

它也提供了一個觀察窗口：當AI開始改變軟件生產，一支親自使用這些能力的團隊，會如何重新組織自己。起點：一個當天拍板的決定西溪園區的一次交流故事要從2025年年初說起。那天，丁宇在西溪園區向阿里高層做了一次彙報，話題是AI Coding。丁宇後來回憶，高層對Coding這件事非常看重，當天就決定孵化這個業務。接下來的節奏很快。Qoder團隊快速成立，被看作阿里參與全球AI Coding競爭的號角，也拉開了阿里全面投入Agent應用賽道的序幕。此後，團隊整建制搬到西溪C區，閉關了整整半年。一個做基礎設施的人，為什麼來做AI Coding丁宇在2010年加入阿里。

此後的十幾年裡，他長期與雲計算的底層技術打交道，帶領團隊攻堅全面容器化、統一調度、混合部署等技術，推動阿里業務上雲。這些工作很少直接出現在普通用戶眼前。用戶看到的是應用和服務，背後則是計算資源如何分配、不同業務如何協同運行，以及龐大的系統如何保持穩定。從雲基礎設施到AI Coding，工作對象發生了變化，工程問題卻沒有消失。過去要解決的是讓大量應用在雲上可靠運行；如今，除了運行，還要進一步參與這些應用的生產過程。

因此，基礎設施出身的創始人，也在Qoder身上留下了印記，不只是“重技術”，而是重視技術之間的銜接：模型如何與Harness配合，上下文如何被理解和傳遞，生成速度如何與測試、安全和交付能力匹配。丁宇在後來的採訪中反覆強調這些問題。閉關半年，一切從零開始閉關的那半年，團隊要做的遠不止寫一個產品。丁宇列過一張清單：端側產品、獨立官網、用戶體系、商業化鏈路、產品營銷、全球部署架構……“都是從無到有。”一家創業公司在頭兩年要搭的東西，這支團隊要在兩個月搭完。攻堅數月，首款產品Qoder在2025年8月上線。它率先支持Repo Wiki、Quest模式等功能，為開發者提供了一種新的開發範式。

上線後僅僅5天，用戶規模就衝上了10萬。考慮到它面對的是一向挑剔的專業開發者，這個速度並不多見。此後，團隊幾乎每個月都有一次重量級發佈：JetBrains插件、Qoder CLI、企業版和Teams版、桌面智能體QoderWork（後合併至千問辦公）、數字員工QoderWake、雲端Cloud Agents、移動端相繼推出。半年時間，一套面向AI Coding場景的全產品矩陣就搭了起來。丁宇說，這在AI時代以前是很難想象的速度。一年，三次擴大邊界去年還在聊怎麼寫代碼在今年雲棲大會的直播間，劉湘明和丁宇又坐在了一起。一年前的雲棲大會，兩人也是這樣對談。

劉湘明記得，那時Qoder剛剛冒頭，“咱們聊的很多都還是怎麼寫代碼”。一年後，他聽完丁宇的演講，第一反應是“這個進步太快了”：不只是寫代碼，已經到了軟件工程、到了完成任務，甚至開始考慮生態。熱度也肉眼可見。劉湘明說，他們在三亞辦的一場AI編程分論壇，一個小會場前後加了三次椅子。丁宇把這一年多的變化分成三個階段。第一階段是輔助編程，AI幫人補全代碼。第二階段進入代碼工程，AI能理解整個代碼庫，完成知識問答、多文件編寫，但仍以代碼為中心。

到了2026年，模型能力大幅提升，Computer Use、Browser Use等工具能力快速進步，Agent能處理的任務越來越長，AI Coding開始覆蓋軟件全生命週期。“Coding Agent本身就是一個通用Agent。”丁宇說。很多人已經在用它做和編程無關的事，AI Coding因此可以服務每一個人。回看Qoder的發展路徑，它並不是簡單地把一個AI編程工具做得更大，而是在短時間內完成了三次能力邊界的外擴：先服務專業開發者，再走向普通崗位，最終進入組織的生產流程。第一階段：先把專業開發者做深、做透2025年下半年，Qoder IDE、JetBrains插件、CLI和企業版相繼推出。

這個階段，Qoder的目標十分明確：圍繞專業開發者構建一套完整的AI Coding產品矩陣。它解決的不再只是代碼問題，而是逐步深入真實的軟件工程場景——理解項目上下文、跨文件修改代碼、執行長週期開發任務，並適配不同開發者的工作習慣。從IDE、插件到命令行，再到面向企業的管理能力，Qoder正在覆蓋開發者從個人編程到團隊協作的完整鏈路。這也是Qoder後續擴展邊界的技術基礎。無論產品形態如何變化，其底層始終圍繞同一套核心能力展開：以模型、Context和 Harness的聯合優化，讓Agent不僅能夠生成代碼，也能夠理解環境、調用工具並完成任務。

第二階段：在“全民養龍蝦”的熱潮中，選擇另一條路2026年1月，OpenClaw爆火，“全民養龍蝦”成為當時最受關注的Agent現象之一。大量產品試圖把Agent放進個人電腦，讓它在本地自主執行任務。Qoder也看到了這股趨勢，但沒有直接複製一隻“住在電腦裡的龍蝦”，而是選擇從“人與Agent如何協作”出發，開發面向所有崗位的桌面Agent工具QoderWork。它不再只面向程序員，而是試圖服務產品、設計、運營、市場等更廣泛的職業人群。這款產品延續了Qoder團隊一貫的AI Native開發方式。團隊對外給出的說法是“五個人、七天完成上線”。

後來，面對外界對這一速度的追問，丁宇在一次內部會議上給出了更出人意料的答案：“我們其實沒用七天，只用五天就完成上線。之所以對外說五人七天，是怕捲到大家。”這句話指向的不只是開發效率的變化。它指向了AI Native團隊與傳統軟件團隊的根本差別：當代碼生成、測試、評審和任務執行逐漸交給Agent，制約產品迭代的主要因素，開始從“有多少人寫代碼”轉向“團隊能否定義清楚目標、組織好上下文，並管理多個Agent協同工作”。2026年5月，Qoder 1.0發佈，通用任務處理、能力擴展和全流程執行能力進一步增強。

Qoder仍以專業Coding Agent為能力底座，也試圖通過更低門檻的交互，把這種能力開放給更廣泛的人群。同月推出的Qoder Cloud Agents，則把任務執行從本地延伸到了雲端。長時間、高資源消耗的任務可以交給雲端Agent持續運行，開發完成的應用也能進一步部署上線。第三階段：從服務個人，到走進組織當Agent能夠幫助一個人完成任務，接下來的問題自然變成：它能否成為組織生產體系的一部分？此後，Qoder團隊用18天開發並上線數字員工產品QoderWake。與普通AI助手不同，QoderWake被定義為一種“生產可用、安全可控、持續進化”的數字員工。

它可以被賦予崗位角色、接入企業流程、學習組織知識，並在權限和安全規則的約束下持續工作。這意味著Qoder面對的對象發生了變化。過去，它關注的是一個開發者怎樣更高效地完成任務；現在，它需要回答一個更復雜的問題：一個組織如何招聘、訓練、管理和考核數字員工，又如何讓人與Agent形成新的分工關係。市場反饋也隨之出現。截至目前，Qoder全系產品已服務全球超過800萬用戶，企業客戶達數十萬家，覆蓋中國東方航空、中國移動、中國交建、廣東交通集團、同濟大學等企業和機構，成為國內用戶規模最大的Agent應用之一。根據IDC市場調研報告，Qoder在中國AI Coding市場份額位居第一。

從IDE、插件和CLI，到桌面Agent、Cloud Agents，再到數字員工，Qoder的產品邊界一直在向外擴張。但貫穿三次躍遷的主線沒有改變：以Coding Agent為底層能力，把代碼從開發者的專業工具，轉化為所有崗位都可以調用的生產力基礎設施，最終嵌入組織的真實業務流程。這也解釋了丁宇為何反覆強調，AI Coding的終點並不是“讓AI寫出更多代碼”。真正的變化在於，當Agent開始理解上下文、調用工具並進入協作流程，軟件生產的基本單位將不再只是程序員，而可能變成“人和一組Agent”共同組成的新型團隊。

水面之下：Qoder把最多的精力花在Harness上對談中，劉湘明問了一個很直接的問題：過去一年，你們的精力主要花在提升代碼可用性上，還是花在周邊這些工作上？丁宇的回答是：“都不少。但要說排優先級和投入，我們還是在基建上花的精力最多。”他解釋，Qoder的產品理念和別人不太一樣，做的是“產品、Context、Harness加模型的端到端聯合優化”。這個回答，很像一個做了十幾年雲基礎設施的人會給出的答案：用戶看見的是產品能不能完成任務，背後決定結果的，卻不只是模型本身。上下文是否充分、工具是否合適、執行過程是否受控，都會影響模型能力最終能兌現多少。

所謂“周邊工作”，並不只是代碼能力之外的附加項，而是讓這些能力真正可用的一部分。丁宇接著說出了他的“暴論”：“如果你只做一個Harness，跟任何一個模型都不沾邊，幾乎是做不好的。”這句話強調的不是工具和模型必須出自同一家公司，而是兩者不能彼此割裂。Harness負責組織上下文、調用工具、約束執行，但這些機制如何設計，離不開對模型能力和行為特點的理解。一套看起來通用的框架，並不天然意味著它能讓所有模型都發揮出最佳表現。在Qoder內部，這種聯合優化首先體現在與千問的深度協同上。

從評測、數據、分析、優化到灰度驗證，Qoder的Harness都與千問深度結合；千問進行強化學習（RL）訓練時使用的腳手架，也是Qoder的Harness。它不只存在於模型交付之後的產品層，也參與到模型的訓練與改進過程中。這也觸及遞歸自我改進（RSI）所關注的一個關鍵問題：模型如何藉助實際執行環境獲得反饋，並將反饋用於後續改進。Harness離不開模型，模型的進化同樣需要合適的工具和環境。對Qoder而言，兩者不是先後交接的關係，而是需要持續磨合的一個系統。不過，基建並不只體現在訓練和評測中。落到工程現場，它往往是一條條具體、甚至瑣碎的約束。例如，如何讓AI遵守代碼倉庫的架構規則？

一種方式是把要求寫進提示詞，期待模型記住並照做；另一種方式，則是把要求變成可以執行的檢查，讓不符合規範的操作無法繼續。Qoder選擇的是後者：把原本依賴“事後質檢”的一部分工作前移，將架構規則和檢查步驟固化為代碼倉庫中的檢查關卡，通過lint、類型檢查和自定義腳本識別違規操作，並在觸發約束時攔截報錯。區別在於，規則不再只是AI應當理解的一段文字，而是執行過程中必須通過的一道關。可靠性也就不再完全依賴模型的“自覺”，而有了工程機制的支撐。同一套底座之上，Qoder再按使用人群和工作方式提供不同入口。今年8月發佈的全新Qoder已經不像一個傳統IDE，但仍然保留了按IDE方式使用的可能。

它試圖改變的不是所有用戶的工作習慣，而是讓不同用戶都能以適合自己的方式進入同一套能力體系。上層可以越來越簡潔，下層卻需要足夠深厚。用戶不必理解模型適配、上下文管理和執行約束的全部細節，但產品必須把這些工作做好。統一的Harness，正是支撐不同產品形態的共同底座。這套底座也經歷過一次高強度的工程檢驗。Qoder CLI最初使用Go語言開發，後來團隊判斷，原有技術方案已難以適應產品快速迭代的需要，決定整體遷移到TypeScript。按照對談中的介紹，七個人、30天，產出二十多萬行代碼，在用戶無感的情況下完成了這次語言層面的遷移。底層與千問深度協同，並不意味著產品層只向千問開放。

Qoder同時為多個頭部模型進行單獨適配。原因很實際：不同模型的訓練數據、能力邊界和行為偏好並不一致。工具選擇、執行路徑、提示詞設計、上下文壓縮，乃至是否支持原生多模態，都可能需要不同的處理方式。接入一個模型，只是讓它能夠被調用；適配一個模型，才是讓它在具體任務中更好地發揮作用。丁宇舉例，有的模型當時還不支持原生多模態，團隊就需要補上相應能力；有的生圖模型受到用戶歡迎，就把它引入產品。模型之間的差異，不應該全部變成用戶需要自行研究和處理的問題。“想用A家的模型，就得用A家的Harness；想用B家的模型，就得用B家的Harness。一個用戶桌面上要裝十幾個桌面應用？

”這句反問背後，是Qoder對產品邊界的判斷：用戶可以有模型偏好，但不應該因為切換模型，就反覆更換工作環境、學習另一套使用方式。“Qoder is all you Need”所表達的，是希望在一個產品裡承接不同場景和模型選擇，把適配的複雜性留給產品，而不是留給用戶。與千問深度聯合優化，和向多個模型開放，因此並不矛盾。前者追求協同的深度，後者服務於用戶選擇的廣度。開放也不是不做適配，恰恰意味著要為不同模型做更多細緻的適配。也正因如此，當劉湘明聽說Qoder開源了Harness時，有些意外：“我覺得這其實應該是一個很大的護城河。”丁宇的解釋是，這與千問模型開源的思路一脈相承。

既然模型已經開放，與之深度協同的執行框架也應該讓社區用得上。第三方Harness未必會專門為千問投入同等程度的優化；如果缺少這部分配套，開發者體驗到的效果，就可能與模型在充分適配後的表現存在距離。按照他的說法，開放Harness，是希望社區開發者能夠直接受益於聯合優化帶來的成本、效率和效果改善，減少實際使用中的失敗案例。“很多開發者在評測Qwen模型的時候，也一定要選擇我們的Harness，這樣才能給一個真實的反饋。”人不再做Agent的“搬運工”丁宇在對談裡描述了一個很多人都經歷過的場景：把一個大任務一句話甩給Agent，它執行了7個小時，做完才發現過程不對、路走偏了。

中國AI Coding的滲透率已經遠超50%，手寫代碼和手工調試不再是主流。生產力的瓶頸，已經從寫代碼本身，轉移到了人和Agent怎麼協作上。於是，Qoder的產品思路也從“人機交互”變成了“人機協同”。把討論搬進任務現場丁宇拆解過傳統的工作流程：定一個需求，先拉視頻會議、現場會議討論；然後立項，定一系列需求，找人跟進，打勾看進度。“這些東西，過去跟AI都沒有什麼關係。”更麻煩的是上下文。討論完了，有人手寫一份文檔，再委派一個人去和AI交互，把活幹了。每轉一次手，上下文就可能丟一截，或者變得碎片化，有統計說，人與人溝通時，信息的接收率大概只有25%。

Qoder的做法是，把人和Agent拉進同一個討論組。Project把大目標拆成可討論、可委派、可驗收的事項；Discussion讓多個人和智能體在一個群組裡，從討論的第一句話，到委派幹活，再到結果驗收，所有信息都共享，由模型識別哪些是關鍵信息、哪些不需要。“人也不用去做一些不願意乾的活，就是整理彙總。”解決“跑偏”的另一層辦法是約束。Agent Team可以針對一類目標組建一支編隊，有角色、有分工，每個Agent都有自己的約束條件，彼此牽制。丁宇說，這支編隊幹活時“會非常遵循你的意志”，“就像你帶了一個真人團隊一樣”。

目前，Agent Team專家團已經能讓一個開發者同時擁有8個Agent並行幹活。入口的擴展服務於同一個目的。圍繞一個人工作的Agent越來越多，人需要隨時調度和管理它們，又不能被綁在電腦前。“所以我就用手機、眼鏡，或者我的耳機，各個設備去跟它連接、管理。”丁宇的說法更直白：“就是讓每個人可以養更多的Agent。”看不見的效率：軟件工程與安全AI Coding讓代碼產能過剩，隨之而來的是整個行業都面臨的難題：代碼寫得越快，“屎山”也堆得越快。如果大家只沉浸在生產代碼的快樂里面，產生了大量代碼，而測試、Code Review、集成迴歸的自動化程度和數量不成比例，它最後一定會拖垮你。

我們的經驗是：“如果你多產生了五倍的代碼，就要多產生十倍的測試，把大回歸的自動化提升十倍，才能把缺陷率壓下來。”軟件架構、質量、安全生產、穩定性和高可用，這些人類沉澱下來的最佳實踐依然適用。區別在於，執行者換成了Agent，“不是說模型就可以放飛自我”。丁宇說：“在Harness之上還可以再做Harness。”Qoder走的是“循環工程”（Loop Engineering）的路子。補測試用例、Code Review、集成迴歸、線上答疑、修Bug，都由循環工程裡的智能體唱主角。團隊的考核方式也跟著變了：看的是智能體在循環裡獨立完成了百分之多少的工作。

Qoder從30%左右做起，現在很多領域能做到60%。Code Review已經到了70%，也就是說，七成代碼經過智能體審查就可以直接合並。為了把這個比例往上推，團隊不斷加能力、加校驗規則，還會換一個模型來交叉驗證。據瞭解，Qoder團隊的月代碼產量，比2026年初提升了五倍。讓發現漏洞的，也去修漏洞當AI把代碼生產速度推高，安全就不能繼續留在開發流程的末端。否則，前端節省下來的時間，很可能變成後端排查漏洞、修復問題和反覆驗證的成本。Qoder Security要解決的，正是從“發現問題”到“解決問題”之間的這段距離。

據丁宇介紹，Qoder Security基於阿里巴巴安全團隊自研的安全大模型，針對代碼安全場景進行強化，用一個專門檢查安全的模型，交叉檢查另一個模型生成的代碼。生成模型關注如何實現功能，安全模型則從另一種視角審視產物：功能實現的同時，是否引入了安全問題。這背後的思路，不是要求一個模型同時把所有事情做好，而是讓不同能力的模型相互補充，把安全檢查嵌入代碼生產過程。更重要的變化發生在檢查時機上。過去，安全問題如果到了工程完成後才被發現，往往需要重新定位代碼、理解業務邏輯，再修改和驗證。問題發現得越晚，牽涉的環節就可能越多。為什麼不在生成第一行代碼的時候，就檢查出安全問題？

因此，Qoder Security將“安全左移”和“默認安全”作為產品設計理念：安全不應是一項等開發結束後才想起來的附加工作，而應成為開發流程的一部分。為此，產品設置了四個檢查切面，由管理員統一下發配置，在相應環節觸發掃描。發現問題後，系統給出修復建議，開發者確認後即可執行修復。丁宇用一句話概括這種變化：“以前代碼是你生產的、我發現的，你來修復。現在是它生產的、它發現的，它來修復。”當然，自動修復不等於安全責任也可以一併交給AI。開發者仍需判斷修改是否符合業務要求，企業仍需明確安全規則和驗收標準。“默認安全”也不是對代碼絕無漏洞的承諾，而是儘可能讓檢查與修復更早發生、更容易執行。

據發佈會披露，Qoder Security累計完成安全掃描180萬次，發現並修復漏洞5.8萬個。劉湘明把這稱作“看不見的效率”——它不像生成一個頁面、上線一項功能那樣直觀，卻體現在少一次跨團隊溝通、少一輪事後返工，以及更早消除一個可能進入生產環境的問題。用Qoder造Qoder：一支團隊的AI Native創新Qoder團隊是阿里內部最早的AI Native團隊之一。丁宇的邏輯很簡單：“我們自己在創造Agent，在改變別人的生產力和生產關係，就要先改變自己。”丁宇形容這一年的狀態，“就像腳踩風火輪，每天雙十一，持續駐紮在作戰室打仗”。很多同學加入團隊後，就再沒離開過項目室。

速度就是這樣被跑出來的。QoderWork從研發到發佈的閃電速度，是團隊的“標誌性事件”，它讓團隊真正進入了AI Native的組織形態和研發範式。QoderWake、移動端、語音功能，都在18天內完成。從通義靈碼到Qoder CN版的整套升級遷移，用了30天。“我們創造了奇蹟，奇蹟成就了業務。”丁宇說。工種消融，中間產物消亡在Qoder團隊裡，產品經理、設計師、前端、後端、架構師、測試，不再按工種排隊交接，而是圍繞一個需求坐進同一個“項目作戰室”。隨時共享上下文，需要時隨時開會，不需要時誰也不打擾。“用Agent所有事情都已經同步完了，會也不用開。

”大家也不再各自向自己的老闆彙報，而是都為同一個需求和產品負責。工種的邊界隨之模糊。後端不一定寫代碼，產品經理可能也不寫需求文檔。討論需求時產品經理仍然主導，但可能只是用語音把討論錄成素材，直接交給模型去做。設計師也開始開發功能。丁宇回憶過去的流程：設計師出一張視覺稿，交給前端拆圖、切圖，大家為像素對不齊糾結半天；前端做完頁面，再交給後端對接數據庫和架構。“在AI能力非常強的今天，這些角色之間的區別已經被彌合掉了。”被取消的還有中間產物。設計稿、PRD、測試文檔，統統被Spec取代。

丁宇說，過去的文檔有生命週期，寫完需求文檔，大家去做新需求，文檔就廢棄了；Spec則直接丟給模型，模型照著就把東西生產出來，“設計即代碼”。人要掌控的，是整體的定義、結構、約束和非功能性需求，所以團隊裡依然保留架構師。他算過一筆賬：開發者過去只有三分之一的時間在寫代碼，另外三分之二花在溝通、對齊、開會、培訓和各種事務上。AI Native組織要做的，就是把那三分之二優化掉。結果是，團隊效率至少提升了十倍，發版從“一週一次就算非常高效的互聯網團隊”，變成了一天1到2次。“這就是AI時代的速度。

”不限Token，一人一臺Mac mini劉湘明問：很多人說AI提高了個人效率，組織效率反而降低了，你們是怎麼形成正向循環的？丁宇的第一條經驗是：先放開Token，讓大家充分釋放生產力。第二條，是給每個人配一臺Mac mini，作為“第二臺電腦”，專門跑數字員工。“有個人在你的工位上一直幫你幹活，或者在你的會議室裡一直幫你幹活。”人拿著自己的電腦去做別的事，注意力被釋放出來。他的邏輯是：人很難一天8小時、10個小時高強度產出，但Agent可以，“它不會累，不需要休息，不需要下班”。人要做的，是變成管理者，管好它們。第三條，是把最優秀的人當底線。

團隊會挑出最優秀員工沉澱下來的技能和Agent，“蒸餾”後複製給其他人。“大家PK一下，誰的閉環率高，誰的循環工程做得好，大家就都用他的，再在上面二次發揮。不是把你自己作為底線，而是把最優秀的人作為底線，大家再去提升天花板。”從團隊實踐到產品：QoderWake與Cloud Agents那臺“第二臺電腦”，變成了一款產品團隊給每個人配的那臺Mac mini，在雲棲大會上變成了一款產品：QoderWake數字員工。QoderWake不是一個AI工具，而是企業的“新的headcount”。

招人、培養人，對企業來說一直是件難事；而一個數字員工，一天之內就能完成安裝部署、技能啟用和各種配置，然後上崗幹活。“像一個員工”，是這個產品的關鍵。它可以部署在自己的電腦上，但自己的電腦會關機。所以更好的選擇是部署在雲電腦，或者Mac mini這樣的獨立設備上，7×24小時持續工作。接下來就像帶一個新人。一個研發團隊的leader，可以給自己配上設計師、產品經理、研發等不同角色的數字員工，把它們加進IM和各種流程，給它們素材，讓它們看別人怎麼工作，自己整理歸納、學習。它們可以拉群討論，可以整理會議紀要，可以是你的數字分身，也可以是你的下屬或同事。“其實就跟咱們帶一個新的實習生、新的同學一樣。

”但是這個比培養一個人快得多，模型的智商是很高的。你把相應的技能、流程數據和上下文給它，它就會做得很好。有的企業不僅給數字員工配了工位和電腦，還給了它一個工號，讓它在群裡參與討論，真的像一個員工一樣做事。由此也提出一個組織度量標準：看一個組織是不是AI Native，就看數字員工的比例。數字員工比例高、能實現5到10倍提效的，就是優秀的AI Native組織。據發佈會披露，QoderWake已服務超過2000家企業，部署數字員工10萬個，崗位覆蓋產品、市場調研、設計、文檔、研發、測試、數據、客服等，生產力提效10倍。

本地跑也挺香，為什麼還要上雲人可以隨時切換工作場景，正在執行的任務卻未必適合跟著中斷。Agent越能承擔複雜工作，執行時間和資源需求就越可能超出一臺個人電腦的承載範圍。這讓丁宇重新審視了團隊已經擁有的能力。“今天雲的能力這麼強”，CPU、GPU、雲端電腦、雲沙箱、開放API等配套設施已經具備，Coding Agent也能承擔越來越複雜的任務。那麼，能不能把兩者組合起來，讓適合在雲端執行的工作，不再被綁定在用戶的電腦上？這是Cloud Agents要解決的第一層問題：把開發任務委派到雲端，減少長任務對本地設備的佔用。但更深一層的需求，發生在開發完成之後。

一個在線應用寫好了，Qoder已經能夠幫助用戶一鍵部署到雲上。如果開發出來的本身就是一個智能體應用，事情就不只是上傳代碼、啟動服務那麼簡單了。它需要持續調用模型、使用工具、執行任務，還要管理運行環境、Harness、訪問憑據和併發請求。隨著使用者增多，生命週期管理、穩定性和安全也都要納入考慮。換句話說，讓Agent替自己完成一次任務，與讓一個Agent上線、持續為其他人提供服務，是兩種不同的工程要求。前者解決“能不能做”，後者還要解決“如何持續運行、如何管理”。“這些東西其實都是ready的，只要你把它產品化。”丁宇說。

這裡的產品化，不是簡單地把一組雲服務入口放進開發工具，而是把原本需要開發者分別理解、配置和銜接的環節，組織成一條連貫的工作流程：在Qoder中開發應用，將任務交給雲端執行，再把開發出的智能體部署上線，並納入後續維護和生命週期管理。這也是阿里雲的基礎設施積累與Qoder的Coding Agent能力發生交匯的地方。前者提供運行所需的計算資源和環境，後者連接開發、部署與維護。對於用戶而言，目標不是多學一套雲產品，而是減少從“做出來”到“用起來”之間的障礙。目前，Cloud Agents已覆蓋數十個行業場景，服務超過千家企業。

這意味著，它所面對的需求，已經不只是個人電腦上的效率提升，還包括智能體如何進入真實業務、承接持續服務的問題。因此，本地與雲端並不是一道非此即彼的選擇題。本地運行有它的便利，雲端則承接那些需要更長執行時間、更多資源和持續在線能力的工作。當Agent從個人工具走向面向他人的服務，“在哪裡運行”就不再只是部署偏好，而成為產品能否進入生產環境的一部分。不做“中國版誰”，尋找自己的下一步在雲棲大會之前舉行的Qoder一週年內部大會上，阿里巴巴集團CEO吳泳銘、CTO吳澤明等核心管理層一同出席。吳泳銘說，自己也是Qoder的忠實用戶，使用中遇到問題，會直接轉給團隊。

他對這款AI Native產品的期待很具體：應該做到一天一個版本。更大的期待，則指向產品的邊界：Qoder要從“程序員工具”走向“所有人的操作系統”。工程師仍然是最重要的硬核用戶，但它未來要幫助的，是所有用電腦工作的人。這裡的“操作系統”，更適合被理解為一種工作入口的願景：用戶不必先判斷該打開哪個軟件、調用什麼工具，而是先表達目標，再與Agent一起完成任務。它要求Qoder不只會寫代碼，還要能理解不同崗位的上下文，把工具、信息和執行過程組織起來。這也構成了Qoder必須處理的一組關係：既不能丟掉專業開發者所要求的能力深度，又要讓不懂代碼的人用得起來。

用戶範圍擴大，不意味著專業能力可以降低；恰恰相反，只有底層能力足夠紮實，產品才有可能把複雜性留給自己，把簡單留給用戶。沿著這條路線，Qoder不可避免地被拿來與OpenAI的Codex比較。隨著Codex從編程向更廣泛的任務場景延伸，兩者的產品邊界出現更多交集，“中國版Codex”的說法也隨之增多。丁宇並不願意用這個標籤定義Qoder。“每一個產品有它的哲學和設計理念，我們不想成為中國的誰誰誰。”他承認，兩者在擴展能力、專業開發者與泛用戶的覆蓋上，有相近的選擇。但在他看來，區別不僅在功能清單裡，也在於如何進入用戶所在的行業和工作流程。Qoder更看重生態的結合、開放與集成。

“我們為什麼跟中國移動、聯想合作，他們要的未必是Coding這個動作，而是Coding的能力。”這句話劃出了一條重要的邊界：並不是所有合作伙伴都需要再做一款編程工具，但它們可能需要讓自己的產品具備理解任務、調用工具、生成代碼並完成執行的能力。Qoder想提供的，不只是一個供人直接使用的應用，也是一種能夠被其他產品和行業場景調用的能力。不願成為誰的翻版，並不意味著迴避