最近一週，AI Coding產品簡直如同井噴。
7月22日，騰訊也正式釋出了它的AI coding產品：CodeBuddy IDE。
在多少有些相似的各家產品裡，CodeBuddy 的特點也足夠有差異性：它想讓使用者透過自然對話，就能實現應用從產品構想、設計、開發部署的全流程。而不只是強調自動寫程式碼，或者在結果上只強調前端或者原形的展示。
作為網際網路時代產品能力很強的騰訊，在今天AI競爭最激烈的AI coding賽道交出的產品究竟什麼樣？CodeBuddy真的可以搞定產品設計到程式碼落地的全流程？CodeBuddy和Cursor到底有什麼不同？以及更深刻的，隨著技術進步下去，AI coding會改變大廠人才結構嗎？
在深度體驗了一段時間CodeBuddy後，我們發現這個產品確實有點東西，另外我們也有機會和騰訊雲開發者產品總監，同時也是CodeBuddy的產品負責人黃廣民聊了聊，看看這款產品背後，騰訊的思考是什麼。
1
實測CodeBuddy：這就是擁有一整個產品團隊的感覺嗎？
首先一起來仔細看看CodeBuddy這個產品。
如果要問當你開啟CodeBuddy，第一眼感覺它與Cursor等最顯著的差異體現哪裡，那一定是CodeBuddy的工具欄：
它集成了Figma、MCP、預覽等功能，在AI程式設計模式邊上還有設計模式、計劃模式的選項。
在開啟介面後還有個小機器人在那兒陪著你。
我們嘗試從0建立一個專案來體驗一下。
我們的prompt也很簡單直接：我想做一款AI程式設計工具，主要功能是“一句話生成一個網站”。
CodeBuddy並不會立即生成程式碼，而是給使用者一些選項，幫助明確需求。就像老闆想要做一個網站，成熟的打工人不會直接發個連結過去，而是摸清楚老闆到底想要做什麼。CodeBuddy問了我們幾個問題，專案的目標使用者是誰，你的網站是商業性的還是個人部落格，你有沒有想用的技術框架等。
這些問題在幫助使用者完成需求澄清的同時，CodeBuddy也基於這些問題的答案生產了一套完整的預開發方案框架：
包括產品實施路線圖、最小可行產品功能清單、原型結構 、技術架構、UI設計等。
這感覺就像一個專業團隊，將產品製作前需要的計劃，事無鉅細的告訴使用者。
大部分AI coding工具到此就結束了，而CodeBuddy與騰訊雲聯動，支援一鍵把文件上傳到騰訊雲中，把枯燥的文件透過網頁展示出來，這樣的一個作用是協作，使用者可以透過連結把需求文件分享給其他人。
我們來詳細看一下CodeBuddy生成的MVP計劃。
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最佳化功能的作用就體現出來了。可以發現，CodeBuddy對原文理解到位，最佳化後邏輯清晰。CodeBuddy把我們的簡單一句話，拆解成5個不同步驟，涉及了業務邏輯、使用者體驗、後端效能等方面。
promtps：好好好，那繼續完善專案的各個功能 修改後promtps："請繼續完善當前專案的所有功能模組，確保每個功能都經過充分開發和測試。具體包括:1)核心業務邏輯的最佳化與錯誤處理;2)使用者介面的互動體驗提升;3)後端API的效能調優;4)資料庫查詢的最佳化;5)安全性增強措施。要求所有功能實現完整閉環，保持程式碼風格統一，並確保各模組之間的無縫整合。同時建立完善的文件說明和單元測試用例。"
在正式啟動專案開發前，CodeBuddy會對整個專案展開系統性規劃 —— 涵蓋專案分析、技術棧確認、設計最佳化及任務拆分等環節。我們可以看一下CodeBuddy的官方案例來體驗一下。
可以看到，CodeBuddy會先分析整個專案的產品需求文件，找出核心功能，隨後確認技術架構，前端用什麼語言，後端用什麼語言。同時還會確認專案的設計風格，頁面規劃，互動方式等。最後生成一個詳細的計劃列表，告訴使用者自己會先做什麼在做什麼。
這不就是包含了產品經理、設計師、程式設計師、專案經理的產品團隊嗎？
此外，用過Cursor的使用者，想必對其indexing&doc功能留有印象。簡單來說，Cursor在執行任務前，會先讀取專案的所有檔案，以此為基礎提升程式設計輔助效果。而這一功能，CodeBuddy直接整合進了專案執行環節：它會自動逐個讀取檔案，省去了使用者在執行前手動確認的步驟。
經過等待，CodeBuddy完成任務後會給出一份簡報，清晰說明自己完成了哪些工作，以此證明它並未 “摸魚”。
我們來看一下，全程沒有修改過，完全由CodeBuddy生成的專案“一句話生成一個網站”。
整體上來看是一個比較完整的網站原型。首頁，基本上遵循了我們上傳的圖片，一個輸入框以及一些建議。下半部分是網站功能介紹，甚至有使用者評價的假資料。當我們在輸入框中輸入點需求，專案會彈出一個工作頁面，頁面左側是一些主題、網站型別選擇，右邊是預覽介面，甚至還有釋出功能。
我們來做第一次版本迭代，透過截圖，修改頁面。我們將頁面中的某個部分截圖傳送給CodeBuddy，並讓他刪除，這一步CodeBuddy執行的很快結果也很ok。此外，CodeBuddy還能點對點的修改專案UI元素，開啟預覽模式後，使用者可以直接在頁面上精準選擇需要修改的地方。
感興趣的讀者可以檢視一下專案：https://github.com/ddlpmj/CodeBuddyTest.git。
整個專案的框架已經完成了，後續接入程式設計大模型新增一個預覽框等。截止到這一步，其實已經可以看出CodeBuddy和Cursor等AI程式設計工具的差別主要在於程式設計之外，比如產品文件的設計、產品開發規劃、技術架構規劃、提示詞最佳化等等，這些都是Cursor所欠缺的，而這些恰恰又是小白和大型複雜專案所需要的。
1
對話黃廣民：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了。
矽星人：醫生算是我們身邊的高知群體了，他在使用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這些也吸引了不少使用者，沒有哪個產品能完全統一市場。這類工具的本質是幫使用者達成業務目標，粘性很難靠資料或社交關係，核心還是看產品體驗和生成效果——做得好，自然能吸引使用者。