最近一周，AI Coding產品簡直如同井噴。
7月22日，騰訊也正式發布了它的AI coding產品：CodeBuddy IDE。
在多少有些相似的各家產品里，CodeBuddy 的特點也足夠有差異性：它想讓用戶通過自然對話，就能實現應用從產品構想、設計、開發部署的全流程。而不只是強調自動寫代碼，或者在結果上只強調前端或者原形的展示。
作為互聯網時代產品能力很強的騰訊，在今天AI競爭最激烈的AI coding賽道交出的產品究竟什么樣？CodeBuddy真的可以搞定產品設計到代碼落地的全流程？CodeBuddy和Cursor到底有什么不同？以及更深刻的，隨著技術進步下去，AI coding會改變大廠人才結構嗎？
在深度體驗了一段時間CodeBuddy后，我們發現這個產品確實有點東西，另外我們也有機會和騰訊云開發者產品總監，同時也是CodeBuddy的產品負責人黃廣民聊了聊，看看這款產品背后，騰訊的思考是什么。
實測CodeBuddy：這就是擁有一整個產品團隊的感覺嗎？
首先一起來仔細看看CodeBuddy這個產品。
如果要問當你打開CodeBuddy，第一眼感覺它與Cursor等最顯著的差異體現哪里，那一定是CodeBuddy的工具欄：
它集成了Figma、MCP、預覽等功能，在AI編程模式邊上還有設計模式、計劃模式的選項。
我們嘗試從0創建一個項目來體驗一下。
我們的prompt也很簡單直接：我想做一款AI編程工具，主要功能是"一句話生成一個網站"。
CodeBuddy并不會立即生成代碼，而是給用戶一些選項，幫助明確需求。就像老板想要做一個網站，成熟的打工人不會直接發個鏈接過去，而是摸清楚老板到底想要做什么。CodeBuddy問了我們幾個問題，項目的目標用戶是誰，你的網站是商業性的還是個人博客，你有沒有想用的技術框架等。
包括產品實施路線圖、最小可行產品功能清單、原型結構 、技術架構、UI設計等。
這感覺就像一個專業團隊，將產品制作前需要的計劃，事無巨細的告訴用戶。
MVP計劃作為方案核心，并非簡單文檔聚合，而是對產品戰略的結構化表達。其框架包含六大核心模塊：項目概述、目標受眾、MVP核心功能、技術架構、MVP開發階段和業務指標。這個邏輯縝密性已超越多數未經過培訓的小白，甚至不輸一些新手產品經理了。
接下來，基于對AI生成方案的信任（其實是作為技產品小白別無選擇），我們全盤采納了CodeBuddy的MVP框架。
接下來是CodeBuddy的另一個亮點，它的設計能力。
以往AI編程的工作流是在確認需求后，將功能架構交給Lovable等擅長原型設計的AI工具，為什么不直接給Cursor？因為Cursor不擅長。
而CodeBuddy在原型設計上給出多個解決方案。里面最明顯的一個"賣點"，就是它支持接入原型設計工具Figma，也就是說設計師在Figma中做完的軟件/網站頁面可以給到CodeBuddy，實現像素級生成。同時CodeBuddy也考慮小白用戶，可以識別用戶上傳的圖片，相當于把"草圖變成網站"。
我們選了一個任務：將Lovable的界面進行"逆向工程"。我們把Lovable的頁面截圖上傳給CodeBuddy，驗證其設計能力。
在逆向還原Lovable界面的實測中，CodeBuddy首先繼承了頁面的風格，比如主色調、字體、卡片投影等。并且Lovable的關鍵文本元素如"Community"、"Pricing"等實現像素級復現，但是導航欄等部分響應邏輯存在偏差。
大致的原型有了，接下來，就讓CodeBuddy按照生成的網頁，以及MVP計劃，完善項目。
在這一步我們順便測試了一下CodeBuddy的prompts優化功能。
產品小白知道自己想要什么，但很難用有邏輯的精確的產品語言表達出來。此時prompts優化功能的作用就體現出來了?？梢园l現，CodeBuddy對原文理解到位，優化后邏輯清晰。CodeBuddy把我們的簡單一句話，拆解成5個不同步驟，涉及了業務邏輯、用戶體驗、后端性能等方面。
promtps：好好好，那繼續完善項目的各個功能
修改后promtps："請繼續完善當前項目的所有功能模塊，確保每個功能都經過充分開發和測試。具體包括:1)核心業務邏輯的優化與錯誤處理;2)用戶界面的交互體驗提升;3)后端API的性能調優;4)數據庫查詢的優化;5)安全性增強措施。要求所有功能實現完整閉環，保持代碼風格統一，并確保各模塊之間的無縫集成。同時建立完善的文檔說明和單元測試用例。"
在正式啟動項目開發前，CodeBuddy會對整個項目展開系統性規劃 —— 涵蓋項目分析、技術棧確認、設計優化及任務拆分等環節。我們可以看一下CodeBuddy的官方案例來體驗一下。
可以看到，CodeBuddy會先分析整個項目的產品需求文檔，找出核心功能，隨后確認技術架構，前端用什么語言，后端用什么語言。同時還會確認項目的設計風格，頁面規劃，交互方式等。最后生成一個詳細的計劃列表，告訴用戶自己會先做什么在做什么。
這不就是包含了產品經理、設計師、程序員、項目經理的產品團隊嗎？
此外，用過Cursor的用戶，想必對其indexing&doc功能留有印象。簡單來說，Cursor在執行任務前，會先讀取項目的所有文件，以此為基礎提升編程輔助效果。而這一功能，CodeBuddy直接整合進了項目執行環節：它會自動逐個讀取文件，省去了用戶在執行前手動確認的步驟。
我們來看一下，全程沒有修改過，完全由CodeBuddy生成的項目"一句話生成一個網站"。
整個項目的框架已經完成了，后續接入編程大模型添加一個預覽框等。截止到這一步，其實已經可以看出CodeBuddy和Cursor等AI編程工具的差別主要在于編程之外，比如產品文檔的設計、產品開發規劃、技術架構規劃、提示詞優化等等，這些都是Cursor所欠缺的，而這些恰恰又是小白和大型復雜項目所需要的。
對話黃廣民：CodeBuddy讓創意直通代碼，模糊角色界限，重塑研發全流程
這只是我們實測的一個案例，在諸多測試后我們對CodeBuddy充滿好奇，也和黃廣民聊了聊背后的思考。
以下為對話實錄。
從內部輔助編程工具，到對外AI IDE產品
硅星人：CodeBuddy這個產品背后的開發故事是怎樣的，經歷了哪些關鍵節點？
黃廣民：
我們的AI輔助編程工具項目始于2023年初，當時看到GPT對生產力的影響，又受海外Copilot啟發，就想著做輔助編程工具。公司里我們部門和工蜂團隊各自做了3-4個月，后來溝通后整合了，資源、需求池、代碼全共享，既服務騰訊內部也面向外部，那會兒團隊才十幾二十人。
2023年底到2024年初，能明顯感覺到這工具提升生產力。當時代碼生成率約20%，但內部接受度很高，所以2024年初加大投入，優化模型、增強端側能力、調整補全策略。
2024年5月，這工具在公司內落地不錯，我們就想著對外發布，幫更多外部企業提升效率，于是當月對外發布了。
2024年我們開始孵化IDE產品形態，內部已經在試用了，但沒廣泛推廣。25年年初我們對IDE做了重新的定位——希望它能解決軟件工程全生命周期的問題。于是又重新打造了就是今天看到的這款CodeBuddy IDE。
硅星人：在你們自己測試、使用中，包括用戶案例收集里，最驚艷最印象深的作品是什么？
有一個外科醫生做的健康管理軟件印象挺深的吧。我們有個用戶是外科醫生，想用我們的插件來做個健康管理軟件——用戶輸入體檢指標，能快速識別問題并給健康建議。不過開發中遇到了些問題。比如在小程序里讀取Excel數據做呈現，他卡殼了。我跟他一起用Prompt工程解決，把內容轉成JSON，再用數據渲染頁面，這問題就搞定了。
第二個問題是UI美化。他（醫生）對審美有要求，但AI生成的頁面不好控，小程序多頁面風格還可能不統一，加上他不會寫CSS，想微調排版也難。最后也是通過調整Prompt解決了。如果用我們今天發布的IDE來編寫，就可以精確調整UI了。
#小程序://智算助手/GzOydzMnEFjQbhj（排版的時候要加一下小程序）
硅星人：醫生算是我們身邊的高知群體了，他在使用AI Coding工具時，有什么優勢和劣勢
優勢很明顯，他們對業務理解深，他知道應用要做成什么樣，這是他的大優勢。不足主要是缺工程訓練。他不知道怎么精準提問，常把很原始的想法直接丟給AI，導致生成的內容沒嚴格約束，技術方案也跟不上他的想法；而且他提的需求往往很大，模型沒好好拆解的話，生成效果就差。后來我跟他交流時，把工程里的最佳實踐教給他，告訴他做項目得先拆解需求，再讓CodeBuddy去實現子任務，這樣才能更精準地達到業務要求。
AI編程不能變成"開盲盒"
硅星人：我體驗產品的過程里發現很多產品字節都還挺有意思，比如，你們把「設計模式」和「計劃模式」作為核心功能分離了，而同類產品（如Cursor）更傾向一體化交互。這種設計是出于怎樣的考量？
我們之所以將設計模式和計劃模式單獨分離，主要有兩方面考量：一方面，傳統研發過程本就分階段，而不同角色的訴求各有側重。像Cursor更多面向開發者，沒兼顧產品經理、設計師等角色的使用體驗。但我們的產品希望覆蓋所有相關角色 —— 產品經理需要寫需求單，設計師需要用自然語言生成設計稿，這些都是他們的高頻訴求。高頻訴求作為獨立功能存在，能更好滿足各角色的使用需求，是合理的。
另一方面，這兩個模式能為后續的 Coding Agent（編碼階段）提供規范和約束。如果沒有前期的這些規約指導，生成的代碼可能像 "開盲盒"，需要花大量時間調整，造成不必要的浪費。而按研發流程先明確前期規約，給下游代碼生成強約束，能讓生成的代碼更符合訴求，成功率也會大幅提升。
硅星人：體驗中我發現，相較于Cursor，CodeBuddy當前沒有indexing&docs選項，這功能還挺重要的，每次做項目前都要確認indexing閱讀率百分百。CodeBuddy采用了每次執行項目前讀取一遍所有文件，這兩種方法CodeBuddy是怎么取舍的。
關于indexing相關功能的設計，我們主要基于這些考量。我們其實嘗試過兩版Codebase Induction方案。第一版是本地對代碼倉庫做embedding，靠語義搜索召回內容，但效果一般；第二版換成遠程服務端版本，效果也沒達預期。
核心問題在于，單純的index搜索只能召回關聯內容，卻搞不清這些內容之間的依賴關系——而項目里的文件、類型間其實有很強的依賴關聯。語義召回的內容是離散、片段化的，模型很難借此真正理解整個項目，所以評估下來效果不理想。后來我們就回歸到模擬人類理解項目的模式：就像開發者面對陌生工程時，會先看目錄結構、找關鍵文件再深入理解一樣，CodeBuddy現在也是這么做的。這種方式看似"笨"，但效果更好。大項目可能會多花點時間，但這些時間是前置的，很值得——要是前期對項目理解不到位就貿然修改，后期調整的時間會比前期理解的時間多得多。
硅星人：在AI編程模式下，CodeBuddy有Ask和Craft模式，相較于Cursor缺少了manual和background（云端模式）模式。這么設計是出于什么考慮？ Cursor中background模式也是一個Beta階段，你覺得background模式有必要嗎？
關于模式設計，我們目前聚焦兩種模式，主要是因為manual模式已屬過渡產物。在agent模式推出前，manual模式是主流，但隨著模型進化，agent模式能更好幫用戶達成目標——人機交互大幅減少，只需最后確認代碼采納即可，所以manual的用戶逐漸減少，自然無需再保留。
而對于background模式（即任務全由模型完成、無需值守，僅關注結果），其本質是人機交互從多到少的演化，但目前它還處于Beta階段，我們暫未推出。一是用戶使用門檻高；二是它更面向專業開發者，且存在矛盾點——插件提供AI操作UI，卻不在本地運行（本地已有代碼倉庫和環境），反而在后端沙箱運行代碼，顯得多此一舉，不太適配大部分用戶場景。
不過，background模式在被集成場景可能是未來趨勢：比如用戶提交代碼后，沙箱里的CRAgent拉取代碼、完成評審、修復甚至合并，再推結果給開發者，這更偏向L4、L5階段的高級形態。
核心是如何用更少的步數解決用戶問題
硅星人：CodeBuddy整合了Figma轉代碼、Supabase后端等功能，試圖覆蓋產品設計到開發的全流程。這些整合里的挑戰是什么？
我們考慮到當下主流設計工具（國內外都以Figma為主），所以肯定要支持Figma，不過整合過程中挑戰不小，尤其是和Figma的對接，核心難題是怎么實現設計稿的一比一還原。
Figma自身的開發者模式能生成CSS、HTML樣式，靠AI生成的話，很容易丟失關鍵信息，還原度根本達不到生產要求。所以我們做了大量優化，結合規則轉換和AI調整，目前已經能做到95%以上的還原度了。
硅星人：您認為用戶對AI生成代碼的「容忍迭代次數」（如20次內完成需求）是競爭關鍵指標嗎？CodeBuddy如何定義當前技術下的體驗平衡點？
用戶對AI生成代碼的容忍迭代次數，無疑是AI工具的關鍵指標。
從我們后端數據來看，用戶完成單個任務的平均輪次在 10 次左右，大家的容忍度大概在 20 到 30 次之間。我們也在努力平衡輪次，核心是思考如何用更少的步數解決用戶問題 —— 內部會持續跑Benchmark，對比不同 IDE、不同Agent 在相同任務下的消耗成本、迭代輪次和完成時間，不斷優化這一指標。
硅星人：人們都在關注AI coding和模型之間的關系，一種普遍的"誤解"是最終能力都來自模型能力，但事實上這中間依然有大量工程挑戰，如何解決這些挑戰也是AI coding類產品的競爭點之一。CodeBuddy在這方面主要做了哪些事情？
對，由于當前模型在推理能力和上下文窗口上存在限制，工程層面的優化就變得尤為關鍵。
以代碼補全為例，它作為用戶高頻操作，對響應速度要求極高——若超過600-800毫秒，用戶可能就失去耐心，寧愿自己編寫。因此補全場景會采用小模型，核心目標是"又快又準"：上下文不能過長，但必須包含足夠關鍵信息，比如待補全代碼的前后內容、依賴的頭文件、方法簽名及語法樹等，這些都需要在工程層面精準抽取，確保模型能一次性補對。
（CodeBuddy的）Craft Agent也面臨類似的上下文限制問題。對此，我們的策略是讓Agent快速檢索相關上下文，對過往交互內容進行總結，將這些總結作為"二次上下文"反饋給模型。這樣能避免重復操作已有的路徑，減少模型和用戶的不必要負擔。本質上，這些優化都是為了在模型限制下，用更少的步驟、更高的效率解決問題，貼合用戶對迭代次數和響應速度的容忍度，這也是我們持續通過Benchmark對比優化的核心方向。
豐富的交互、美麗的頁面設計，都不如生成效果好
硅星人：今天AI coding 的競爭最大的一個落點就是"快"，我們了解到Cursor內部也在近乎極致的做功能迭代，但同時這類產品又非常早期，這意味著可以做的也有很多，那么CodeBuddy在今天的開發優先級是什么？迭代速度？產品交付質量？新的創新的功能？背后思路是怎樣的？
在AI應用里，最核心的命題無疑是解決生成效果問題。如果生成效果不佳，哪怕做再多交互、視覺上的表面優化，用戶也不會買單。
所以我們的開發優先級，首先必然聚焦在提升生成效果上，通過優化生成效果來進一步提高開發效率，這是我們的核心關注點。
其次，數據顯示開發人員實際聚焦在開發過程的時間占比僅約37%，其余大量時間都花在溝通對齊上。
因此我們也在思考，如何大幅縮短這部分時間，具體來說，就是在整個研發生命周期中，想辦法消除不必要的浪費，這也是我們重點考量的方向。
硅星人：在Cursor有先發優勢的背景下，CodeBuddy目前是更側重側重吸引/培育什么類型的新用戶，專業程序員、產品經理/設計師，或者是純小白？還是你們對這種比較簡單的劃分有不同定義？
目前我們在三類用戶群體上都有推廣動作，不過策略和側重點不太一樣。對于專業開發者，推廣會更側重產品的技術深度，比如代碼生成的精準度、與復雜項目的適配性，以及如何通過Agent模式減少他們的重復勞動，提升核心開發效率。
而針對有互聯網經驗的人群，像產品經理、設計師這類，推廣會更貼合他們的工作場景，比如強調如何用自然語言快速生成需求文檔、設計稿，以及這些成果如何無縫銜接后續開發，降低他們跨角色協作的門檻，讓他們不用懂代碼也能推動創意落地。
至于小白用戶，推廣則更注重簡化操作和引導性，比如通過更直觀的交互、一步到位的任務模板，讓他們即使沒有技術基礎，也能快速上手，用AI工具把自己的創意變成實際的成果，降低入門的心理門檻和操作難度。
整體還是圍繞我們"逐步向上游擴展"的理念，針對不同群體的核心訴求去做推廣，讓每個群體都能感受到產品對自己的價值。
硅星人：目前市面上比較流行的AI編程工具，大致可以分為Lovable和Cursor兩種類型，前者偏向生成原型，后者偏向編程。CodeBuddy的slogan是"設計和開發實時融合"，那是否可以理解為在做一個類似Lovable+Cursor之間的東西。
從用戶場景和畫像來看，Lovable和Cursor的用戶群體其實都是我們的目標用戶。
雖然這兩者聚焦的點各有不同，但我們的產品希望能把他們覆蓋的能力、涉及的工作環節更好地串聯起來——從一個想法的誕生，到設計落地，再到最終的代碼生成，以及后續的部署、分享、運行，形成一個完整的閉環。
硅星人：CodeBuddy作為騰訊的一款產品，這些產品設計思路，哪些帶有獨特的"騰訊味兒"？把文檔上傳到騰訊云這個功能我用了很驚艷，未來會不會增加一鍵接入混元大模型？
我們的工具在打通騰訊生態上，一方面已經通過內置混元大模型，以及接入騰訊云的API知識庫、插件工具等，實現了與騰訊云產品的良好聯動。
另一方面，騰訊自身的小程序開發生態其實是個重要方向——目前已有300多萬小程序開發者，市面上小程序數量達1000萬款，這是個非常龐大的群體。所以后續我們會和小程序開發場景做更緊密的結合，目標是讓小程序開發變得更易上手：只要有好的創意，就能快速生成對應的小程序，降低開發門檻，讓更多人能把想法落地到小程序場景中。
硅星人：騰訊內部會使用CodeBuddy嗎，有多少項目用到了CodeBuddy，有一個量化的指標嗎。可以談談你在開發中，用AI Coding的程度，大概占比多少，有沒有印象特別深刻的場景？
在騰訊內部，目前有90%的開發崗員工都在使用CodeBuddy。
我自己每天開發都會用到它，有兩個印象很深的場景：一個是2024年我開發一個C++項目，我已經十年沒碰過C++了，是CodeBuddy幫我快速掌握了最新特性，比如智能指針這些。那年我提交了差不多14萬行代碼，至少一半是AI幫忙寫的。
另一個是CraftAgent的重構：1.0版本我們花了一個半月才開發上線，后來讓CraftAgent自己重構2.0版本，只用了不到兩周就完成了，等于它自己重構了自己。
CodeBuddy這類AI輔助工具本質是SaaS產品
硅星人：近期Cursor修改收費模式引起熱議，有競品的模式是按照一次請求（對話）而非token計費。付費似乎也在變成競爭的關鍵環節，CodeBuddy會采取什么樣的收費模式。您覺得AI產品應該采用什么樣的收費模式。
關于AI產品的收費模式，目前行業還在探索中，Cursor調整模式也是對商業模式的嘗試，可能說明之前的模式尚未實現盈利。
像CodeBuddy這類AI輔助工具本質是SaaS產品，采用token計費其實不太合適。
C端用戶很難理解每次請求消耗多少token，對他們來說，一次交互就是一次請求，所以按請求（比如對話次數）計費可能更合理，用戶能直觀知道一次多少錢，更容易接受。當然，具體定價還是要結合成本核算，畢竟商業模式的核心是平衡用戶接受度和商業可持續性，這也是行業需要持續探索的方向。
目前國內市場的AI輔助工具，（ToC）整體還處于未盈利狀態，基本都采用免費模式。在ToB領域，行業正處于快速發展階段，大家的重心還是先聚焦于幫助B端企業提升效率，商業模式的探索會在這個基礎上再逐步推進——先解決用戶的核心價值需求，再考慮商業層面的可持續性。
AI放大能力，低技術用戶獨立開發簡單應用，全棧工程師需求轉向架構把控
硅星人：CodeBuddy試圖覆蓋從產品設計到代碼實現的完整流程。這是否意味著未來「低技術背景用戶」能獨立完成應用開發？團隊如何看待由此帶來的職業角色變革？
從目前的情況來看，開發門檻的降低確實會讓低技術背景的用戶有能力獨立完成一些簡單應用的開發，他們可以借助AI工具把創意落地，不用再完全依賴專業程序員。
但對于復雜的企業級應用，還是離不開專業開發者。因為AI雖然能處理大量細節編碼工作，甚至比人寫得更規范，但它缺乏基于業務場景的需求拆解能力和架構設計能力，這些需要人來主導。
這種變化也會帶來團隊結構的調整。比如我們團隊現在招聘更傾向于全棧工程師，核心是看他是否有開闊的技術視野和扎實的架構能力——畢竟很多基礎編碼環節AI能高效完成，而如何基于業務拆解需求、搭建合理架構，這些才是更關鍵的，需要人來把控。所以并非不需要技術程序員，而是對技術人員的能力要求在變化，從"專注細節編碼"轉向"聚焦業務理解、架構設計和AI協作"；同時，產品經理、設計師等角色的作用可能更突出，因為他們能更直接地通過AI工具推動創意落地，但核心技術崗位依然不可或缺，只是能力重心在遷移。
硅星人：您覺得1-2年內的未來，會不會設計師、產品經理成為項目/產品的起點。過個5-6年，真正意義上的純小白，直接成為起點？您有相關的判斷嗎？
隨著AI輔助開發的深入，角色界限變得模糊會是一個明顯的趨勢。
海外硅谷沒有專門的產品經理角色，大家更偏向全棧，這背后其實是工具在打破"專業壁壘"——當AI能幫產品經理生成設計稿、寫基礎代碼，幫設計師理解開發邏輯，幫開發者更精準捕捉產品需求時，跨角色的協作門檻會大幅降低，每個角色都能觸達研發流程的更多環節。
國內未來很可能也會朝著這個方向發展：不再有嚴格的"產品經理只做需求、設計師只畫稿、開發者只編碼"的界限，更多人會具備"從想法到落地"的全流程能力。AI工具就像一個"能力放大器"，讓有創意的人能自己推動設計，讓懂設計的人能參與開發，讓開發者也能更好地理解業務本質。
硅星人：昨天Trae2.0發布，前幾天AWS發布kiro，您這邊會感到壓力嗎？你是怎么看到大廠之間AI Coding工具的競爭，有沒有一個最關鍵的競爭指標？
目前AI Coding工具領域還處于藍海階段，各家廠商都在不同賽道探索，這是好事——大家先一起把市場做起來，還沒到"搶地盤"的地步，也沒有明顯的競爭指標說誰能一統江湖。往后很可能會出現不同維度的AI Coding工具，分別服務不同用戶、不同研發流程和角色，幫他們把核心工作做得更好。
其實海外也是如此，一開始有Copilot，后來Cursor、Claude這些也吸引了不少用戶，沒有哪個產品能完全統一市場。這類工具的本質是幫用戶達成業務目標，粘性很難靠數據或社交關系，核心還是看產品體驗和生成效果——做得好，自然能吸引用戶。
