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