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