牧惜萱

作者：董道力王兆洋

最近一周，AICoding產(chǎn)品簡直如同井噴。

7月22日，騰訊也正式發(fā)布了它的AIcoding產(chǎn)品：CodeBuddyIDE。

在多少有些相似的各家產(chǎn)品里，CodeBuddy的特點也足夠有差異性：它想讓用戶通過自然對話，就能實現(xiàn)應(yīng)用從產(chǎn)品構(gòu)想、設(shè)計、開發(fā)部署的全流程。而不只是強(qiáng)調(diào)自動寫代碼，或者在結(jié)果上只強(qiáng)調(diào)前端或者原形的展示。

作為互聯(lián)網(wǎng)時代產(chǎn)品能力很強(qiáng)的騰訊，在今天AI競爭最激烈的AIcoding賽道交出的產(chǎn)品究竟什么樣？CodeBuddy真的可以搞定產(chǎn)品設(shè)計到代碼落地的全流程？CodeBuddy和Cursor到底有什么不同？以及更深刻的，隨著技術(shù)進(jìn)步下去，AIcoding會改變大廠人才結(jié)構(gòu)嗎？

在深度體驗了一段時間CodeBuddy后，我們發(fā)現(xiàn)這個產(chǎn)品確實有點東西，另外我們也有機(jī)會和騰訊云開發(fā)者產(chǎn)品總監(jiān)，同時也是CodeBuddy的產(chǎn)品負(fù)責(zé)人黃廣民聊了聊，看看這款產(chǎn)品背后，騰訊的思考是什么。

1

實測CodeBuddy：這就是擁有一整個產(chǎn)品團(tuán)隊的感覺嗎？

首先一起來仔細(xì)看看CodeBuddy這個產(chǎn)品。

如果要問當(dāng)你打開CodeBuddy，第一眼感覺它與Cursor等最顯著的差異體現(xiàn)哪里，那一定是CodeBuddy的工具欄：

它集成了Figma、MCP、預(yù)覽等功能，在AI編程模式邊上還有設(shè)計模式、計劃模式的選項。

在打開界面后還有個小機(jī)器人在那兒陪著你。

我們嘗試從0創(chuàng)建一個項目來體驗一下。

我們的prompt也很簡單直接：我想做一款A(yù)I編程工具，主要功能是“一句話生成一個網(wǎng)站”。

CodeBuddy并不會立即生成代碼，而是給用戶一些選項，幫助明確需求。就像老板想要做一個網(wǎng)站，成熟的打工人不會直接發(fā)個鏈接過去，而是摸清楚老板到底想要做什么。CodeBuddy問了我們幾個問題，項目的目標(biāo)用戶是誰，你的網(wǎng)站是商業(yè)性的還是個人博客，你有沒有想用的技術(shù)框架等。

這些問題在幫助用戶完成需求澄清的同時，CodeBuddy也基于這些問題的答案生產(chǎn)了一套完整的預(yù)開發(fā)方案框架：

包括產(chǎn)品實施路線圖、最小可行產(chǎn)品功能清單、原型結(jié)構(gòu)、技術(shù)架構(gòu)、UI設(shè)計等。

這感覺就像一個專業(yè)團(tuán)隊，將產(chǎn)品制作前需要的計劃，事無巨細(xì)的告訴用戶。

大部分AIcoding工具到此就結(jié)束了，而CodeBuddy與騰訊云聯(lián)動，支持一鍵把文檔上傳到騰訊云中，把枯燥的文檔通過網(wǎng)頁展示出來，這樣的一個作用是協(xié)作，用戶可以通過鏈接把需求文檔分享給其他人。

我們來詳細(xì)看一下CodeBuddy生成的MVP計劃。

MVP計劃作為方案核心，并非簡單文檔聚合，而是對產(chǎn)品戰(zhàn)略的結(jié)構(gòu)化表達(dá)。其框架包含六大核心模塊：項目概述、目標(biāo)受眾、MVP核心功能、技術(shù)架構(gòu)、MVP開發(fā)階段和業(yè)務(wù)指標(biāo)。這個邏輯縝密性已超越多數(shù)未經(jīng)過培訓(xùn)的小白，甚至不輸一些新手產(chǎn)品經(jīng)理了。

接下來，基于對AI生成方案的信任（其實是作為技產(chǎn)品小白別無選擇），我們?nèi)P采納了CodeBuddy的MVP框架。

接下來是CodeBuddy的另一個亮點，它的設(shè)計能力。

以往AI編程的工作流是在確認(rèn)需求后，將功能架構(gòu)交給Lovable等擅長原型設(shè)計的AI工具，為什么不直接給Cursor？因為Cursor不擅長。

而CodeBuddy在原型設(shè)計上給出多個解決方案。里面最明顯的一個“賣點”，就是它支持接入原型設(shè)計工具Figma，也就是說設(shè)計師在Figma中做完的軟件/網(wǎng)站頁面可以給到CodeBuddy，實現(xiàn)像素級生成。同時CodeBuddy也考慮小白用戶，可以識別用戶上傳的圖片，相當(dāng)于把“草圖變成網(wǎng)站”。

我們選了一個任務(wù)：將Lovable的界面進(jìn)行“逆向工程”。我們把Lovable的頁面截圖上傳給CodeBuddy，驗證其設(shè)計能力。

在逆向還原Lovable界面的實測中，CodeBuddy首先繼承了頁面的風(fēng)格，比如主色調(diào)、字體、卡片投影等。并且Lovable的關(guān)鍵文本元素如"Community"、"Pricing"等實現(xiàn)像素級復(fù)現(xiàn)，但是導(dǎo)航欄等部分響應(yīng)邏輯存在偏差。

大致的原型有了，接下來，就讓CodeBuddy按照生成的網(wǎng)頁，以及MVP計劃，完善項目。

在這一步我們順便測試了一下CodeBuddy的prompts優(yōu)化功能。

產(chǎn)品小白知道自己想要什么，但很難用有邏輯的精確的產(chǎn)品語言表達(dá)出來。此時prompts優(yōu)化功能的作用就體現(xiàn)出來了?？梢园l(fā)現(xiàn)，CodeBuddy對原文理解到位，優(yōu)化后邏輯清晰。CodeBuddy把我們的簡單一句話，拆解成5個不同步驟，涉及了業(yè)務(wù)邏輯、用戶體驗、后端性能等方面。

promtps：好好好，那繼續(xù)完善項目的各個功能修改后promtps："請繼續(xù)完善當(dāng)前項目的所有功能模塊，確保每個功能都經(jīng)過充分開發(fā)和測試。具體包括:1)核心業(yè)務(wù)邏輯的優(yōu)化與錯誤處理;2)用戶界面的交互體驗提升;3)后端API的性能調(diào)優(yōu);4)數(shù)據(jù)庫查詢的優(yōu)化;5)安全性增強(qiáng)措施。要求所有功能實現(xiàn)完整閉環(huán)，保持代碼風(fēng)格統(tǒng)一，并確保各模塊之間的無縫集成。同時建立完善的文檔說明和單元測試用例。"

在正式啟動項目開發(fā)前，CodeBuddy會對整個項目展開系統(tǒng)性規(guī)劃——涵蓋項目分析、技術(shù)棧確認(rèn)、設(shè)計優(yōu)化及任務(wù)拆分等環(huán)節(jié)。我們可以看一下CodeBuddy的官方案例來體驗一下。

可以看到，CodeBuddy會先分析整個項目的產(chǎn)品需求文檔，找出核心功能，隨后確認(rèn)技術(shù)架構(gòu)，前端用什么語言，后端用什么語言。同時還會確認(rèn)項目的設(shè)計風(fēng)格，頁面規(guī)劃，交互方式等。最后生成一個詳細(xì)的計劃列表，告訴用戶自己會先做什么在做什么。

這不就是包含了產(chǎn)品經(jīng)理、設(shè)計師、程序員、項目經(jīng)理的產(chǎn)品團(tuán)隊嗎？

此外，用過Cursor的用戶，想必對其indexing&doc功能留有印象。簡單來說，Cursor在執(zhí)行任務(wù)前，會先讀取項目的所有文件，以此為基礎(chǔ)提升編程輔助效果。而這一功能，CodeBuddy直接整合進(jìn)了項目執(zhí)行環(huán)節(jié)：它會自動逐個讀取文件，省去了用戶在執(zhí)行前手動確認(rèn)的步驟。

經(jīng)過等待，CodeBuddy完成任務(wù)后會給出一份簡報，清晰說明自己完成了哪些工作，以此證明它并未“摸魚”。

我們來看一下，全程沒有修改過，完全由CodeBuddy生成的項目“一句話生成一個網(wǎng)站”。

整體上來看是一個比較完整的網(wǎng)站原型。首頁，基本上遵循了我們上傳的圖片，一個輸入框以及一些建議。下半部分是網(wǎng)站功能介紹，甚至有用戶評價的假數(shù)據(jù)。當(dāng)我們在輸入框中輸入點需求，項目會彈出一個工作頁面，頁面左側(cè)是一些主題、網(wǎng)站類型選擇，右邊是預(yù)覽界面，甚至還有發(fā)布功能。

我們來做第一次版本迭代，通過截圖，修改頁面。我們將頁面中的某個部分截圖發(fā)送給CodeBuddy，并讓他刪除，這一步CodeBuddy運行的很快結(jié)果也很ok。此外，CodeBuddy還能點對點的修改項目UI元素，打開預(yù)覽模式后，用戶可以直接在頁面上精準(zhǔn)選擇需要修改的地方。

感興趣的讀者可以查看一下項目：https://github.com/ddlpmj/CodeBuddyTest.git。

整個項目的框架已經(jīng)完成了，后續(xù)接入編程大模型添加一個預(yù)覽框等。截止到這一步，其實已經(jīng)可以看出CodeBuddy和Cursor等AI編程工具的差別主要在于編程之外，比如產(chǎn)品文檔的設(shè)計、產(chǎn)品開發(fā)規(guī)劃、技術(shù)架構(gòu)規(guī)劃、提示詞優(yōu)化等等，這些都是Cursor所欠缺的，而這些恰恰又是小白和大型復(fù)雜項目所需要的。

1

對話黃廣民：CodeBuddy讓創(chuàng)意直通代碼，模糊角色界限，重塑研發(fā)全流程

這只是我們實測的一個案例，在諸多測試后我們對CodeBuddy充滿好奇，也和黃廣民聊了聊背后的思考。

以下為對話實錄。

從內(nèi)部輔助編程工具，到對外AIIDE產(chǎn)品

硅星人：CodeBuddy這個產(chǎn)品背后的開發(fā)故事是怎樣的，經(jīng)歷了哪些關(guān)鍵節(jié)點？

黃廣民：我們的AI輔助編程工具項目始于2023年初，當(dāng)時看到GPT對生產(chǎn)力的影響，又受海外Copilot啟發(fā)，就想著做輔助編程工具。公司里我們部門和工蜂團(tuán)隊各自做了3-4個月，后來溝通后整合了，資源、需求池、代碼全共享，既服務(wù)騰訊內(nèi)部也面向外部，那會兒團(tuán)隊才十幾二十人。

2023年底到2024年初，能明顯感覺到這工具提升生產(chǎn)力。當(dāng)時代碼生成率約20%，但內(nèi)部接受度很高，所以2024年初加大投入，優(yōu)化模型、增強(qiáng)端側(cè)能力、調(diào)整補全策略。

2024年5月，這工具在公司內(nèi)落地不錯，我們就想著對外發(fā)布，幫更多外部企業(yè)提升效率，于是當(dāng)月對外發(fā)布了。

2024年我們開始孵化IDE產(chǎn)品形態(tài)，內(nèi)部已經(jīng)在試用了，但沒廣泛推廣。25年年初我們對IDE做了重新的定位——希望它能解決軟件工程全生命周期的問題。于是又重新打造了就是今天看到的這款CodeBuddyIDE。

硅星人：在你們自己測試、使用中，包括用戶案例收集里，最驚艷最印象深的作品是什么？

黃廣民：有一個外科醫(yī)生做的健康管理軟件印象挺深的吧。我們有個用戶是外科醫(yī)生，想用我們的插件來做個健康管理軟件——用戶輸入體檢指標(biāo)，能快速識別問題并給健康建議。不過開發(fā)中遇到了些問題。比如在小程序里讀取Excel數(shù)據(jù)做呈現(xiàn)，他卡殼了。我跟他一起用Prompt工程解決，把內(nèi)容轉(zhuǎn)成JSON，再用數(shù)據(jù)渲染頁面，這問題就搞定了。

第二個問題是UI美化。他（醫(yī)生）對審美有要求，但AI生成的頁面不好控，小程序多頁面風(fēng)格還可能不統(tǒng)一，加上他不會寫CSS，想微調(diào)排版也難。最后也是通過調(diào)整Prompt解決了。如果用我們今天發(fā)布的IDE來編寫，就可以精確調(diào)整UI了。

硅星人：醫(yī)生算是我們身邊的高知群體了，他在使用AICoding工具時，有什么優(yōu)勢和劣勢

黃廣民：優(yōu)勢很明顯，他們對業(yè)務(wù)理解深，他知道應(yīng)用要做成什么樣，這是他的大優(yōu)勢。不足主要是缺工程訓(xùn)練。他不知道怎么精準(zhǔn)提問，常把很原始的想法直接丟給AI，導(dǎo)致生成的內(nèi)容沒嚴(yán)格約束，技術(shù)方案也跟不上他的想法；而且他提的需求往往很大，模型沒好好拆解的話，生成效果就差。后來我跟他交流時，把工程里的最佳實踐教給他，告訴他做項目得先拆解需求，再讓CodeBuddy去實現(xiàn)子任務(wù)，這樣才能更精準(zhǔn)地達(dá)到業(yè)務(wù)要求。

AI編程不能變成“開盲盒”

硅星人：我體驗產(chǎn)品的過程里發(fā)現(xiàn)很多產(chǎn)品字節(jié)都還挺有意思，比如，你們把「設(shè)計模式」和「計劃模式」作為核心功能分離了，而同類產(chǎn)品（如Cursor）更傾向一體化交互。這種設(shè)計是出于怎樣的考量？

黃廣民：我們之所以將設(shè)計模式和計劃模式單獨分離，主要有兩方面考量：一方面，傳統(tǒng)研發(fā)過程本就分階段，而不同角色的訴求各有側(cè)重。像Cursor更多面向開發(fā)者，沒兼顧產(chǎn)品經(jīng)理、設(shè)計師等角色的使用體驗。但我們的產(chǎn)品希望覆蓋所有相關(guān)角色——產(chǎn)品經(jīng)理需要寫需求單，設(shè)計師需要用自然語言生成設(shè)計稿，這些都是他們的高頻訴求。高頻訴求作為獨立功能存在，能更好滿足各角色的使用需求，是合理的。

另一方面，這兩個模式能為后續(xù)的CodingAgent（編碼階段）提供規(guī)范和約束。如果沒有前期的這些規(guī)約指導(dǎo)，生成的代碼可能像“開盲盒”，需要花大量時間調(diào)整，造成不必要的浪費。而按研發(fā)流程先明確前期規(guī)約，給下游代碼生成強(qiáng)約束，能讓生成的代碼更符合訴求，成功率也會大幅提升。

硅星人：體驗中我發(fā)現(xiàn)，相較于Cursor，CodeBuddy當(dāng)前沒有indexing&docs選項，這功能還挺重要的，每次做項目前都要確認(rèn)indexing閱讀率百分百。CodeBuddy采用了每次執(zhí)行項目前讀取一遍所有文件，這兩種方法CodeBuddy是怎么取舍的。

黃廣民：關(guān)于indexing相關(guān)功能的設(shè)計，我們主要基于這些考量。我們其實嘗試過兩版CodebaseInduction方案。第一版是本地對代碼倉庫做embedding，靠語義搜索召回內(nèi)容，但效果一般；第二版換成遠(yuǎn)程服務(wù)端版本，效果也沒達(dá)預(yù)期。

核心問題在于，單純的index搜索只能召回關(guān)聯(lián)內(nèi)容，卻搞不清這些內(nèi)容之間的依賴關(guān)系——而項目里的文件、類型間其實有很強(qiáng)的依賴關(guān)聯(lián)。語義召回的內(nèi)容是離散、片段化的，模型很難借此真正理解整個項目，所以評估下來效果不理想。后來我們就回歸到模擬人類理解項目的模式：就像開發(fā)者面對陌生工程時，會先看目錄結(jié)構(gòu)、找關(guān)鍵文件再深入理解一樣，CodeBuddy現(xiàn)在也是這么做的。這種方式看似“笨”，但效果更好。大項目可能會多花點時間，但這些時間是前置的，很值得——要是前期對項目理解不到位就貿(mào)然修改，后期調(diào)整的時間會比前期理解的時間多得多。

硅星人：在AI編程模式下，CodeBuddy有Ask和Craft模式，相較于Cursor缺少了manual和background（云端模式）模式。這么設(shè)計是出于什么考慮？Cursor中background模式也是一個Beta階段，你覺得background模式有必要嗎？

黃廣民：關(guān)于模式設(shè)計，我們目前聚焦兩種模式，主要是因為manual模式已屬過渡產(chǎn)物。在agent模式推出前，manual模式是主流，但隨著模型進(jìn)化，agent模式能更好幫用戶達(dá)成目標(biāo)——人機(jī)交互大幅減少，只需最后確認(rèn)代碼采納即可，所以manual的用戶逐漸減少，自然無需再保留。

而對于background模式（即任務(wù)全由模型完成、無需值守，僅關(guān)注結(jié)果），其本質(zhì)是人機(jī)交互從多到少的演化，但目前它還處于Beta階段，我們暫未推出。一是用戶使用門檻高；二是它更面向?qū)I(yè)開發(fā)者，且存在矛盾點——插件提供AI操作UI，卻不在本地運行（本地已有代碼倉庫和環(huán)境），反而在后端沙箱運行代碼，顯得多此一舉，不太適配大部分用戶場景。

不過，background模式在被集成場景可能是未來趨勢：比如用戶提交代碼后，沙箱里的CRAgent拉取代碼、完成評審、修復(fù)甚至合并，再推結(jié)果給開發(fā)者，這更偏向L4、L5階段的高級形態(tài)。

核心是如何用更少的步數(shù)解決用戶問題

硅星人：CodeBuddy整合了Figma轉(zhuǎn)代碼、Supabase后端等功能，試圖覆蓋產(chǎn)品設(shè)計到開發(fā)的全流程。這些整合里的挑戰(zhàn)是什么？

黃廣民：我們考慮到當(dāng)下主流設(shè)計工具（國內(nèi)外都以Figma為主），所以肯定要支持Figma，不過整合過程中挑戰(zhàn)不小，尤其是和Figma的對接，核心難題是怎么實現(xiàn)設(shè)計稿的一比一還原。

Figma自身的開發(fā)者模式能生成CSS、HTML樣式，靠AI生成的話，很容易丟失關(guān)鍵信息，還原度根本達(dá)不到生產(chǎn)要求。所以我們做了大量優(yōu)化，結(jié)合規(guī)則轉(zhuǎn)換和AI調(diào)整，目前已經(jīng)能做到95%以上的還原度了。

硅星人：您認(rèn)為用戶對AI生成代碼的「容忍迭代次數(shù)」（如20次內(nèi)完成需求）是競爭關(guān)鍵指標(biāo)嗎？CodeBuddy如何定義當(dāng)前技術(shù)下的體驗平衡點？

黃廣民：用戶對AI生成代碼的容忍迭代次數(shù)，無疑是AI工具的關(guān)鍵指標(biāo)。

從我們后端數(shù)據(jù)來看，用戶完成單個任務(wù)的平均輪次在10次左右，大家的容忍度大概在20到30次之間。我們也在努力平衡輪次，核心是思考如何用更少的步數(shù)解決用戶問題——內(nèi)部會持續(xù)跑Benchmark，對比不同IDE、不同Agent在相同任務(wù)下的消耗成本、迭代輪次和完成時間，不斷優(yōu)化這一指標(biāo)。

硅星人：人們都在關(guān)注AIcoding和模型之間的關(guān)系，一種普遍的“誤解”是最終能力都來自模型能力，但事實上這中間依然有大量工程挑戰(zhàn)，如何解決這些挑戰(zhàn)也是AIcoding類產(chǎn)品的競爭點之一。CodeBuddy在這方面主要做了哪些事情？

黃廣民：對，由于當(dāng)前模型在推理能力和上下文窗口上存在限制，工程層面的優(yōu)化就變得尤為關(guān)鍵。

以代碼補全為例，它作為用戶高頻操作，對響應(yīng)速度要求極高——若超過600-800毫秒，用戶可能就失去耐心，寧愿自己編寫。因此補全場景會采用小模型，核心目標(biāo)是“又快又準(zhǔn)”：上下文不能過長，但必須包含足夠關(guān)鍵信息，比如待補全代碼的前后內(nèi)容、依賴的頭文件、方法簽名及語法樹等，這些都需要在工程層面精準(zhǔn)抽取，確保模型能一次性補對。

（CodeBuddy的）CraftAgent也面臨類似的上下文限制問題。對此，我們的策略是讓Agent快速檢索相關(guān)上下文，對過往交互內(nèi)容進(jìn)行總結(jié)，將這些總結(jié)作為“二次上下文”反饋給模型。這樣能避免重復(fù)操作已有的路徑，減少模型和用戶的不必要負(fù)擔(dān)。本質(zhì)上，這些優(yōu)化都是為了在模型限制下，用更少的步驟、更高的效率解決問題，貼合用戶對迭代次數(shù)和響應(yīng)速度的容忍度，這也是我們持續(xù)通過Benchmark對比優(yōu)化的核心方向。

豐富的交互、美麗的頁面設(shè)計，都不如生成效果好

硅星人：今天AIcoding的競爭最大的一個落點就是“快”，我們了解到Cursor內(nèi)部也在近乎極致的做功能迭代，但同時這類產(chǎn)品又非常早期，這意味著可以做的也有很多，那么CodeBuddy在今天的開發(fā)優(yōu)先級是什么？迭代速度？產(chǎn)品交付質(zhì)量？新的創(chuàng)新的功能？背后思路是怎樣的？

黃廣民：在AI應(yīng)用里，最核心的命題無疑是解決生成效果問題。如果生成效果不佳，哪怕做再多交互、視覺上的表面優(yōu)化，用戶也不會買單。

所以我們的開發(fā)優(yōu)先級，首先必然聚焦在提升生成效果上，通過優(yōu)化生成效果來進(jìn)一步提高開發(fā)效率，這是我們的核心關(guān)注點。

其次，數(shù)據(jù)顯示開發(fā)人員實際聚焦在開發(fā)過程的時間占比僅約37%，其余大量時間都花在溝通對齊上。

因此我們也在思考，如何大幅縮短這部分時間，具體來說，就是在整個研發(fā)生命周期中，想辦法消除不必要的浪費，這也是我們重點考量的方向。

硅星人：在Cursor有先發(fā)優(yōu)勢的背景下，CodeBuddy目前是更側(cè)重側(cè)重吸引/培育什么類型的新用戶，專業(yè)程序員、產(chǎn)品經(jīng)理/設(shè)計師，或者是純小白？還是你們對這種比較簡單的劃分有不同定義？

黃廣民：目前我們在三類用戶群體上都有推廣動作，不過策略和側(cè)重點不太一樣。對于專業(yè)開發(fā)者，推廣會更側(cè)重產(chǎn)品的技術(shù)深度，比如代碼生成的精準(zhǔn)度、與復(fù)雜項目的適配性，以及如何通過Agent模式減少他們的重復(fù)勞動，提升核心開發(fā)效率。

而針對有互聯(lián)網(wǎng)經(jīng)驗的人群，像產(chǎn)品經(jīng)理、設(shè)計師這類，推廣會更貼合他們的工作場景，比如強(qiáng)調(diào)如何用自然語言快速生成需求文檔、設(shè)計稿，以及這些成果如何無縫銜接后續(xù)開發(fā)，降低他們跨角色協(xié)作的門檻，讓他們不用懂代碼也能推動創(chuàng)意落地。

至于小白用戶，推廣則更注重簡化操作和引導(dǎo)性，比如通過更直觀的交互、一步到位的任務(wù)模板，讓他們即使沒有技術(shù)基礎(chǔ)，也能快速上手，用AI工具把自己的創(chuàng)意變成實際的成果，降低入門的心理門檻和操作難度。

整體還是圍繞我們“逐步向上游擴(kuò)展”的理念，針對不同群體的核心訴求去做推廣，讓每個群體都能感受到產(chǎn)品對自己的價值。

硅星人：目前市面上比較流行的AI編程工具，大致可以分為Lovable和Cursor兩種類型，前者偏向生成原型，后者偏向編程。CodeBuddy的slogan是“設(shè)計和開發(fā)實時融合”，那是否可以理解為在做一個類似Lovable+Cursor之間的東西。

黃廣民：從用戶場景和畫像來看，Lovable和Cursor的用戶群體其實都是我們的目標(biāo)用戶。

雖然這兩者聚焦的點各有不同，但我們的產(chǎn)品希望能把他們覆蓋的能力、涉及的工作環(huán)節(jié)更好地串聯(lián)起來——從一個想法的誕生，到設(shè)計落地，再到最終的代碼生成，以及后續(xù)的部署、分享、運行，形成一個完整的閉環(huán)。

硅星人：CodeBuddy作為騰訊的一款產(chǎn)品，這些產(chǎn)品設(shè)計思路，哪些帶有獨特的“騰訊味兒”？把文檔上傳到騰訊云這個功能我用了很驚艷，未來會不會增加一鍵接入混元大模型？

黃廣民：我們的工具在打通騰訊生態(tài)上，一方面已經(jīng)通過內(nèi)置混元大模型，以及接入騰訊云的API知識庫、插件工具等，實現(xiàn)了與騰訊云產(chǎn)品的良好聯(lián)動。

另一方面，騰訊自身的小程序開發(fā)生態(tài)其實是個重要方向——目前已有300多萬小程序開發(fā)者，市面上小程序數(shù)量達(dá)1000萬款，這是個非常龐大的群體。所以后續(xù)我們會和小程序開發(fā)場景做更緊密的結(jié)合，目標(biāo)是讓小程序開發(fā)變得更易上手：只要有好的創(chuàng)意，就能快速生成對應(yīng)的小程序，降低開發(fā)門檻，讓更多人能把想法落地到小程序場景中。

硅星人：騰訊內(nèi)部會使用CodeBuddy嗎，有多少項目用到了CodeBuddy，有一個量化的指標(biāo)嗎?？梢哉?wù)勀阍陂_發(fā)中，用AICoding的程度，大概占比多少，有沒有印象特別深刻的場景？

黃廣民：在騰訊內(nèi)部，目前有90%的開發(fā)崗員工都在使用CodeBuddy。

我自己每天開發(fā)都會用到它，有兩個印象很深的場景：一個是2024年我開發(fā)一個C++項目，我已經(jīng)十年沒碰過C++了，是CodeBuddy幫我快速掌握了最新特性，比如智能指針這些。那年我提交了差不多14萬行代碼，至少一半是AI幫忙寫的。

另一個是CraftAgent的重構(gòu)：1.0版本我們花了一個半月才開發(fā)上線，后來讓CraftAgent自己重構(gòu)2.0版本，只用了不到兩周就完成了，等于它自己重構(gòu)了自己。

CodeBuddy這類AI輔助工具本質(zhì)是SaaS產(chǎn)品

硅星人：近期Cursor修改收費模式引起熱議，有競品的模式是按照一次請求（對話）而非token計費。付費似乎也在變成競爭的關(guān)鍵環(huán)節(jié)，CodeBuddy會采取什么樣的收費模式。您覺得AI產(chǎn)品應(yīng)該采用什么樣的收費模式。

黃廣民：關(guān)于AI產(chǎn)品的收費模式，目前行業(yè)還在探索中，Cursor調(diào)整模式也是對商業(yè)模式的嘗試，可能說明之前的模式尚未實現(xiàn)盈利。

像CodeBuddy這類AI輔助工具本質(zhì)是SaaS產(chǎn)品，采用token計費其實不太合適。

C端用戶很難理解每次請求消耗多少token，對他們來說，一次交互就是一次請求，所以按請求（比如對話次數(shù)）計費可能更合理，用戶能直觀知道一次多少錢，更容易接受。當(dāng)然，具體定價還是要結(jié)合成本核算，畢竟商業(yè)模式的核心是平衡用戶接受度和商業(yè)可持續(xù)性，這也是行業(yè)需要持續(xù)探索的方向。

目前國內(nèi)市場的AI輔助工具，（ToC）整體還處于未盈利狀態(tài)，基本都采用免費模式。在ToB領(lǐng)域，行業(yè)正處于快速發(fā)展階段，大家的重心還是先聚焦于幫助B端企業(yè)提升效率，商業(yè)模式的探索會在這個基礎(chǔ)上再逐步推進(jìn)——先解決用戶的核心價值需求，再考慮商業(yè)層面的可持續(xù)性。

AI放大能力，低技術(shù)用戶獨立開發(fā)簡單應(yīng)用，全棧工程師需求轉(zhuǎn)向架構(gòu)把控

硅星人：CodeBuddy試圖覆蓋從產(chǎn)品設(shè)計到代碼實現(xiàn)的完整流程。這是否意味著未來「低技術(shù)背景用戶」能獨立完成應(yīng)用開發(fā)？團(tuán)隊如何看待由此帶來的職業(yè)角色變革？

黃廣民：從目前的情況來看，開發(fā)門檻的降低確實會讓低技術(shù)背景的用戶有能力獨立完成一些簡單應(yīng)用的開發(fā)，他們可以借助AI工具把創(chuàng)意落地，不用再完全依賴專業(yè)程序員。

但對于復(fù)雜的企業(yè)級應(yīng)用，還是離不開專業(yè)開發(fā)者。因為AI雖然能處理大量細(xì)節(jié)編碼工作，甚至比人寫得更規(guī)范，但它缺乏基于業(yè)務(wù)場景的需求拆解能力和架構(gòu)設(shè)計能力，這些需要人來主導(dǎo)。

這種變化也會帶來團(tuán)隊結(jié)構(gòu)的調(diào)整。比如我們團(tuán)隊現(xiàn)在招聘更傾向于全棧工程師，核心是看他是否有開闊的技術(shù)視野和扎實的架構(gòu)能力——畢竟很多基礎(chǔ)編碼環(huán)節(jié)AI能高效完成，而如何基于業(yè)務(wù)拆解需求、搭建合理架構(gòu)，這些才是更關(guān)鍵的，需要人來把控。所以并非不需要技術(shù)程序員，而是對技術(shù)人員的能力要求在變化，從“專注細(xì)節(jié)編碼”轉(zhuǎn)向“聚焦業(yè)務(wù)理解、架構(gòu)設(shè)計和AI協(xié)作”；同時，產(chǎn)品經(jīng)理、設(shè)計師等角色的作用可能更突出，因為他們能更直接地通過AI工具推動創(chuàng)意落地，但核心技術(shù)崗位依然不可或缺，只是能力重心在遷移。

硅星人：您覺得1-2年內(nèi)的未來，會不會設(shè)計師、產(chǎn)品經(jīng)理成為項目/產(chǎn)品的起點。過個5-6年，真正意義上的純小白，直接成為起點？您有相關(guān)的判斷嗎？

黃廣民：隨著AI輔助開發(fā)的深入，角色界限變得模糊會是一個明顯的趨勢。

海外硅谷沒有專門的產(chǎn)品經(jīng)理角色，大家更偏向全棧，這背后其實是工具在打破“專業(yè)壁壘”——當(dāng)AI能幫產(chǎn)品經(jīng)理生成設(shè)計稿、寫基礎(chǔ)代碼，幫設(shè)計師理解開發(fā)邏輯，幫開發(fā)者更精準(zhǔn)捕捉產(chǎn)品需求時，跨角色的協(xié)作門檻會大幅降低，每個角色都能觸達(dá)研發(fā)流程的更多環(huán)節(jié)。

國內(nèi)未來很可能也會朝著這個方向發(fā)展：不再有嚴(yán)格的“產(chǎn)品經(jīng)理只做需求、設(shè)計師只畫稿、開發(fā)者只編碼”的界限，更多人會具備“從想法到落地”的全流程能力。AI工具就像一個“能力放大器”，讓有創(chuàng)意的人能自己推動設(shè)計，讓懂設(shè)計的人能參與開發(fā)，讓開發(fā)者也能更好地理解業(yè)務(wù)本質(zhì)。

硅星人：昨天Trae2.0發(fā)布，前幾天AWS發(fā)布kiro，您這邊會感到壓力嗎？你是怎么看到大廠之間AICoding工具的競爭，有沒有一個最關(guān)鍵的競爭指標(biāo)？

黃廣民：目前AICoding工具領(lǐng)域還處于藍(lán)海階段，各家廠商都在不同賽道探索，這是好事——大家先一起把市場做起來，還沒到“搶地盤”的地步，也沒有明顯的競爭指標(biāo)說誰能一統(tǒng)江湖。往后很可能會出現(xiàn)不同維度的AICoding工具，分別服務(wù)不同用戶、不同研發(fā)流程和角色，幫他們把核心工作做得更好。

其實海外也是如此，一開始有Copilot，后來Cursor、Claude這些也吸引了不少用戶，沒有哪個產(chǎn)品能完全統(tǒng)一市場。這類工具的本質(zhì)是幫用戶達(dá)成業(yè)務(wù)目標(biāo)，粘性很難靠數(shù)據(jù)或社交關(guān)系，核心還是看產(chǎn)品體驗和生成效果——做得好，自然能吸引用戶。

點個愛心，再走吧