今年以來 Coding 領域的最大變數是 AI labs 們的加入，模型大廠紛紛發力，和創業公司共同競爭這一關鍵場景：兩週前，all-in coding 的 Anthropic 更新了 Artifacts 功能，使用者可以在聊天介面裡直接生成、預覽和編輯程式碼，實現類 vibe coding 的體驗；同一天，Google 也推出了自己的命令列工具 Gemini CLI，開發者可以使用自然語言直接呼叫 Gemini 2.5 Pro 來實現編碼、除錯和內容生成等操作。
毫無疑問，模型廠商最大的優勢是對模型能力理解和成本。Claude Code 從今年 2 月上線以來，迅速在開發者群體中積累了口碑，我們觀察到不少深度開發中表示自己已經從 cursor 遷移到了 Claude code。產品角度，它所提供的 agentic 非同步性幾乎已經讓 AI coding 的 L4 時刻得以實現。
為什麼開發者“放棄”Cursor 紛紛遷移到 Claude Code？ Claude Code 的 10x 開發體驗是如何實現的？它的增長會給 cursor、lovable 等其他現象級 coding 產品帶來哪些影響？它所主打的 CLI 會是 coding 產品的最好形態嗎？
…
為了更好地理解 Coding 領域正在發生的變化、梳理關鍵問題，我們邀請到了黃航、Tony、周弋涵三位開發者組織了一場「Best Ideas」討論會，他們結合自身的開發體驗分享了對 Claude Code、cursor、lovable 等 coding 產品的觀察，並和海外獨角獸社群成員一起討論了對 coding agent 賽道的觀點與洞察。
💡 目錄 💡
01 開發者視角下的 Claude Code
02Claude Code 是第一個 L4 Coding Agent
03 Anthropic 可能會成為 Coding 領域的 AWS
04 Agent 的核心理念比前端形態更重要
05 Coding 的終級的贏家會是誰？
01.
開發者視角下的
Claude Code
Part 1: 為什麼 Claude Code 會成為 Anthropic 的 Killer App
分享人：
• 黃航：InsForge 創始人，創業前在 Amazon 擔任 Senior PM
• Tony：InsForge 聯合創始人，創業前在 Databricks 工作
1. 為什麼開發者遷移到了 Claude Code
1）成本低：Claude Code 極大降低了使用者使用最先進的 model 的成本，非常適合每天都寫程式碼的高頻開發者。
目前 Opus 是交付能力最好的模型，但在 Cursor 的產品設計中，預設提供的是 Sonnet 模型，使用者如果要使用 Opus 模型就需要按使用量單獨計費。
和 Sonnet 比，Opus 非常昂貴，消耗的 token 量為 Sonnet 的 5 倍，費用大約為每小時 20–40 美元。對於高頻開發者來說，在 Cursor 目前的產品設計下，如果要持續使用 Opus 模型，月支出往往會達到 4000-5000 美元。
作為對比，Claude Code 可以直接選擇 Opus 模型，幾乎可以無限使用 token，月固定費用為 200 美元，成本可以降低至之前的 1/20，顯著低於 Cursor。
即便不使用 Opus 模型，只採用 Sonnet 模型，在 Cursor 按使用計費的情況下，開發者每月需要花費約 400–500 美元。同等開發量和 token 使用量在 Claude Code 上通常只需每月 100–200 美元，成本至少可以降低 1/2，且在交付效率和響應質量方面，Claude Code 也明顯優於 Cursor。
Cursor 官網定價
2）效率高：端到端建立專案的成功率和效率都極高
Cursor 沒有自主拆解任務的能力，所以需要開發者在使用 Cursor 的時候就要有對於如何構建這個 project 的具體想法。
相比之下，Claude Code 具有 planning 能力，使用者只需要在 prompt 中給出大致需求後，Claude Code 就可以自主地將任務拆分為子任務，逐步完成且即時反饋。
而且 Claude Code 在讀已有的很大的 codebase 的時候，還會自主建立一個 context 檔案並學習 context，能夠在開發過程中生成 test command，進行自主地除錯，出了問題會自己 debug 等。
比如，就有開發者提到，提高 vibe coding 成功率的關鍵就是要有測試依據。除了單元測試（時間成本與維護成本都較高）之外，基於 language server 及時編譯（比如 tsc）的檢查更有價值，Cursor、Windsurf 在今年都陸續支援了這個功能。此外，Claude Code 的出色能力，不僅受益於大模型本身智商的提高，工程也很關鍵，Windsurf、Cursor 早期經常出現編譯錯誤，但 Claude Code 幾乎就沒這個問題。
3）非同步 async 開發和高代理（L4）：Claude Code 對於超長文字有記憶管理能力，是真正的 agentic 模式，大幅減少了需要人介入的部分。
由於 Cursor 有 context window 限制，在長 context 的場景下會遺忘最開始的 prompt 和需求，因此需要開發者輔助定義 workflow 和進行 debug。而 Claude Code 有 memory context 的功能，可以在即將遺忘 context 的情況下自主地回顧、壓縮先前的 prompt，形成 memory。
2. 雖然 CLI 很火，但 GUI 才是未來
今天我們看到的 Claude Code 的產品形態其實是內部工具直接開發給外界使用者的產品，並不是 Anthropic 為了專攻 coding 領域而專門規劃、打造出來的產品。
Anthropic 的 CPO 就專門講過這件事，Anthropic 團隊內部已經有 90% 的程式碼都由 Claude Code 生成了，後來，公司覺得這個工具有潛力對外試水，於是在幾乎沒有進行任何產品最佳化的情況下，就釋出了。
在程式設計領域，開發者更關注工具的最終效果，因為 Claude Code 所使用的底層模型 Opus 能力非常強大，所以即使沒有進行產品化設計、即便 CLI 很難用，大家也願意使用。因此 Claude Code 爆火更多證明了 Opus 模型能力很強，並不能驗證 CLI 這個形態是 coding agent 的終局。
最近 CLI 之所以討論度很高，還因為 Google 在看到 Claude Code 的成功和市場需求後，為了快速入局並搶佔市場份額，選擇直接推出免費且量大的 Gemini CLI，迅速吸引了價格敏感、對產品忠誠度不高的 coding agent 開發者，進一步推高了 CLI 的聲量和熱度。
但如果站在使用者體驗角度看 CLI，其實 CLI 的侷限相當明顯：
1）AI 是直接生成程式碼的，一旦出現幻覺或錯誤，使用者不能修改與撤銷，只能依賴 Git 等外部工具進行版本回滾，操作非常繁瑣；
2） 在安裝外掛、配置記憶體或指定任務等高階操作上，使用者需要手動編寫和修改配置檔案，對普通使用者而言，使用門檻很高；
3）處理圖片等多媒體檔案非常不便，使用者無法像在 GUI 中那樣透過拖拽來實現圖片上傳、即時展示等功能，多模態互動體驗很差。
因此，coding 工具只有透過 GUI 來最佳化體驗，才能被更廣泛的使用者群體所接受。Claude Code 也已經開始推出 UI 介面和 VSCode 擴充套件。
此外，未來的產品形態將會是 GUI，但不一定是 IDE。
因為 IDE 是過去數十年軟體開發模式下的產物，它本身也存在一定的學習曲線和歷史包袱。AI-native 開發工具可能會帶來全新且更高效的互動模式。
3. Cursor or Claude Code?
如果綜合 coding 領域所有 use case，結合使用者使用偏好和工具交付效果來看，Cursor 還是優於 Claude 的。
這是因為 Cursor 對使用者體驗做了很多最佳化，而且 Cursor 在處理簡單任務時的速度非常快。
此外，Cursor 的市場認可度和滲透率也是最高的，滿足了大企業對 SLA（服務穩定性）、資料隱私和安全性的嚴格要求，比如 Tony 就提到 Databricks 目前就與 Cursor 談合作，內部數千名員工都可以使用 Cursor。此外，黃航還提到 Amazon 也正在與 Cursor 進行合作談判。
但 Cursor 和 Claude Code 並不是簡單的取代關係，目前來看，二者會在不同的應用場景中展現出各自的優勢：
• 對於修改按鈕樣式這類需要快速提供 context 的簡單場景，Cursor 的執行速度更快；
• 對於需要理解數萬個檔案構成的大型程式碼庫，或需要完成端到端的複雜任務的時候，Claude Code 會更加合適。
比如在企業日常開發環境中，Cursor 這類 Agent+IDE 的模式因為可以融合現有的工作流，更加使用者友好，企業忠誠度也會更高，而在自動化場景中，Claude Code 這樣的 CLI 工具更具優勢。
4. 現在的 Coding Agent 還缺什麼？
1）語音輸入
透過鍵盤輸入冗長、結構化的文字指令，對普通人來說費時且困難。人類更擅長說話來描述複雜需求，而這恰好是 LLM 最擅長的。未來 coding agent 或許可以將語音作為主要的互動方式，使用者只需要透過說話下達命令，AI 就可以理解並執行。
現在已經有開發者在 coding 時會使用轉錄工具，將語音直接轉為指令，這很大程度上提升了開發的效率。
也有開發者認為，目前的語音輸入技術能滿足轉錄需求，但長期來看，考慮到 coding 任務的複雜性，效率較高的互動方式或許並不是單純依靠語音輸入，而是可以實現定向修改，類似在使用 PS 工具的時候，選中某一區域讓 AI 針對性修改。
2）GUI 編排非同步程式設計
GUI 編排非同步程式設計也是一個值得發展的方向，比如，使用者可以在一個畫布上同時讓多個 Claude Code 分別執行不同任務，並可以對任務進行終止或回退，在這種工作流下，使用者扮演的是專案管理者的角色，這將大幅提升開發效率和靈活性。
5. Demo 互動：搭建一個互動提問網頁
在分享過程中，黃航也演示瞭如何用 AI coding 工具搭建一個即時互動的 Q&A 網站，並對 Lovable 和 Claude Code 的效果進行了對比。
需要指出的是，Windows 系統下的使用者需要先安裝並切換到 Linux 命令列環境才能進行 Claude Code 操作，沒有做原生整合這一點也是影響 Claude Code 市場滲透率的因素之一。
網站設計的 prompt 如下：
幫我開發一個觀眾 QA 產品：觀眾可以登入然後 Post 自己的問題每個 Post 的問題可以被點贊，問的 list 按照贊數從高到低排列，每個使用者對每個問題只能點贊一次，也可以取消點贊合適的劇新機制，讓現眾能看到重新排列的 list贊數排列和交替位置的特效要比較 cool，除了數字以外，模向能有 bar 來展現贊數的多少效果Lovable VS Claude Code
從效果來看，Lovable 和 Claude Code 生成的網頁在前端上沒有顯著差別，但是在後端上，Lovable 使用 Supabase 進行後端資料庫的連線，但在上傳問題時，Lovable 會顯示報錯，也就是說 Lovable 並沒有成功連線資料庫。而 Claude Code 透過 MCP 連線到黃航自己的產品 InsForge，交付的網頁可以成功使用。
注：InsForge 是一個專門為 AI 打造的後端系統，能讓 coding agent 自己連線和配置後端。在本次演示中，Claude Code 透過 InsForge 的 MCP 成功配置了使用者登入和鑑權功能（authentication），並實現了資料庫中的使用者資訊儲存、 QA 點贊數記錄以及排行榜的即時更新等功能。
Claude Code 配合上 InsForge 可以實現從 prompt 到應用的端到端流程，整個過程都在 Claude Code 介面中進行，並且始終透過 agent 完成。
左右滑動檢視完整圖片
Lovable VS Claude Code
Part 2: Claude Code 互動方式
分享人：
• 周弋涵：AI 創業者，探索用遊戲化方式評估人類使用 AI 的能力
注：這一 Part 的 deck 均由 Claude Code 生成
1. Claude 的 CLI 互動體現了Anthropic 對自己模型 Coding 能力的信心
Claude Code 目前使用的互動方式，其實是 Anthropic 對自身模型能力更有信仰的體現。
Claude Code 的設計會讓使用者在修改程式碼的時候非常不方便，迫使使用者減少手動改程式碼的次數，這有可能是 Anthropic 並不鼓勵使用者手動修改程式碼的體現，相比之下，使用 Cursor 等 GUI 的工具時，使用者會不自覺地進行大量手動修改，頻繁地接受或拒絕 AI 的建議。
2. AI-native IDE 或許是偽命題
未來 GUI 很可能會繼續存在，但未必是以 IDE 的形態。
GUI 本質上是在限制使用者，透過編輯區、檔案區、預覽區等固定的區域，引導人類的操作，GUI 雖然犧牲了操作自由度，但也降低了人類在操作上的心理負擔。
IDE 本質是對 shell line 的 wrapper，經過多年發展，IDE 在互動介面上積累了大量為了方便工程師手動程式設計而做的功能，比如語法高亮、一鍵執行、程式碼快速預覽等，它更像是服務於工程師的“手套和鏟子”，但 AI 其實並不需要這些“手套和鏟子”。相比之下，CLI 可以更方便地被指令碼呼叫，融入到自動化的 pipeline 裡，AI 可以輕鬆地將多個獨立的 CLI 工具串聯起來，形成自己的工作流。
比如，Claude Code 只有 chat 這一種互動模式，在 IDE 介面可以做的所有事情現在都可以透過 chat 去做。這種自由對普通使用者來說可能是一個負擔，但對於需要高度定製化的人來說，是一個比較舒服的方式。
而且 AI 操作 CLI 比操作 GUI 容易，如果是 GUI，也就意味著工作流中需要拖拽，那開發方式就又變回人工手動了。因此比較好的產品開發方式是，先開發一個 CLI 讓 AI 用起來，然後做一個方便與人類互動的介面，比如語音互動，從而實現優先最佳化 AI 對工具的使用，避免過渡最佳化人類對工具的使用。
在這一點上，有開發者指出，Cursor 基於 GUI，可以把對程式碼的修改分散到多個 tab 裡，從而保持對話歷史簡潔，而 Claude Code 基於 CLI，修改記錄只能嵌入對話歷史裡，在最初使用 Claude Code 的時候，由於使用者對 Claude Code 不信任，會非常仔細地審查 AI 生成的程式碼，但隨著對 Claude Code 信任度的提升，使用者會更傾向於同時開啟多個命令列，來並行操作多個專案。
3. Claude Code 的產品形態是模型開發者工作習慣的對映
Claude Code 之所以選擇 CLI，與大模型開發者自身的工作習慣密切相關。Claude Code 原來是 Anthropic 內部使用的工具，相比使用者體驗，內部工具一般會更在意可定製化程度、可程式設計性和可組合性，也就是說希望這個工具在內部 pipeline 中是可以自動化的。
相比之下，Cursor 是 GUI，其實是沒有辦法自動化執行或可程式設計地執行。
此外，每個工程師都有自己的習慣，這和入行時間、工種等因素相關。比如，前端開發工程師大機率是使用 IDE 的，但模型訓練工程師的工作天然就是非同步、多執行緒的，他們習慣於同時開啟多個命令列視窗，提交訓練任務後便去處理其他事情，大部分時間都在等待而非即時互動，這樣的開發者工作習慣造就了 Claude Code 的 CLI 產品形態。
4. Demo：用 Claude Code 製作 ppt
將文件裡的文字轉成 ppt 的 prompt 如下：
use reveal js to create a slide using contentfrom prm-163 in main branch左右滑動檢視完整圖片
在第一版生成的結果中，文字都集中在了 ppt 上方。
左右滑動檢視完整圖片
為了進一步最佳化 ppt 排版，再次輸入瞭如下 prompt：
use playwright to screen shot each page of @shixiang_main/index.html，如果內容都擠在上邊，請你重新改一下排版，然後重新截圖確認一下第二次執行後，Claude Code 透過自行截圖並進行影像理解，修正了之前的問題。
左右滑動檢視完圖片
02.
Claude Code 是
第一個 L4 Coding Agent
1. 如何定義 Coding 領域的“L4 能力”？里程碑事件會是什麼？
Claude Code 在很大程度上已經達到了 L4 級別。
雖然 coding agent 需要的執行時間越來越長了，但開發者需要手動介入（如 Debug、審查、修改程式碼）的時間和精力大幅減少。開發者的角色從先前的程式設計師變為了定期對流程進行監測和管理的指揮出現問題的背後原因往往是使用者自己提出的 prompt 不夠清晰。
而且 L4 級別的 agent 不需要使用者手動提供所有相關的 context，目前 Claude Code 就可以實現自主閱讀整個程式碼庫，在多個檔案中自動尋找和理解完成任務所需的資訊，然後進行正確的跨檔案操作，這是它與像 Cursor 這樣的上一代工具的區別。
有開發者提到，在 Claude Code 釋出之前，即便 Windsurf 的工程質量和使用者體驗遠低於 Cursor，但 Windsurf 卻是他唯一一個即使明知有這些問題，仍然長期重度使用並持續付費的產品，就是因為 Windsurf 的 context awareness 能力極強，由此帶來的開發體驗要更好。
2024 年 11 月 21 日在 Windsurf 官網的截圖
此外， Claude Code 不僅能執行計劃，還能在執行中發現自身規劃的漏洞並進行自我修正。比如 Claude Code 會發現自己出現了幻覺，應該先讀取檔案才能寫入檔案時，它會主動調整自己的行為順序。這種反思能力是 L4 的重要體現，讓使用者可以更放心地將任務交付給它。
2. Claude Code 的能力邊界在哪裡？背後體現了 coding model 和 coding agent 哪些底層能力的不足？
相較於 Cursor 等產品，Claude Code 在能力邊界上的拓展在於有拆解任務的 multi-agent 思維和 workflow 管理能力，能將一個複雜的 coding 任務，自動拆解成幾十個更小的、專門的子任務，分派給不同的子 agent 去執行，最後再將結果整合。
也有開發者認為 Claude 和 Cursor 的核心差異並不在於是否是 multi-agent，而在於 context 理解能力有差異，進而導致 planning 水平有差異，最後導致交付結果存在差異。也有開發者認為 Claude 和 Cursor 的區別在於能否 parallel executation，但 parallel 理論上不能提升效果，只能提升效率。
總的來說，目前 AI coding 產品的不足在於對冷門或私有知識的掌握能力比較差。
因為 AI 模型的能力來源於 online 訓練，本質上還是 pre-training 的狀態，因此，它在主流、公開的技術（如 Web 開發）上表現出色，但對冷門的程式語言（如 Jsonnet，Scala）或公司內部的私有程式碼庫的效果就很差。
而要突破這個邊界，需要讓 agent 具備呼叫外部知識庫的能力。像給遊戲機插上記憶卡，為 agent 提供一個即插即用的知識庫（如某個特定庫的文件、某個行業的專業知識），讓它能瞬間獲得特定領域的專業能力，從而極大地擴充套件其應用的能力邊界。
3. Coding agent 能力達到 L4 後，下一個機會會在哪裡？
當 AI 寫程式碼的能力足夠強時，下一個機會將會從程式碼生成，轉移到程式碼的運維部署和互動最佳化。
• 自動化程式碼後端的運維與部署
DevOps 這類工作目前仍是人力密集、繁瑣且易錯的重災區。AI 寫程式碼的效率越高，後端運維的壓力就越大。這需要深度的行業知識，是純粹的 coding 能力無法解決的。痛點在於怎麼讓模型使用工具來自主完成這種任務，讓它們能自動化處理像 AWS 這類主流雲平臺的雲服務配置、持續整合/部署（CI/CD）。
因為配置雲服務是一個極為複雜的任務。如果一個遊戲公司要搭建測試叢集，需要專門的工程師花費數天時間進行復雜的配置、連線、許可權設定和除錯。這個過程不僅耗時，而且高度依賴個人經驗，一旦該工程師請假，工作就會停滯。而透過 agent，可以將這些複雜的的任務，簡化為一句話指令，agent 就能自動完成所有後續工作。
因此，能跨所有主流雲平臺（AWS、GCP、Azure）實現上述功能的 agent 將會很有市場。因為人為配置的系統，即使能用，也往往不是最高效的。人類的精力很難對龐雜的系統進行持續的、精細化的監控和最佳化。比如有創業團隊在內部配置了 AWS，過了很久才發現每月多花了 10 萬美元，只是因為沒有關閉一個不需要的功能。
• 人機互動層面的最佳化
不同的人用 AI 的效果是有差異的，未來 1-2 年，會用 AI agent 將不再是優勢，但不會用 AI agent 將成為劣勢，就像招聘的時候，如果候選人不會用電腦，那大機率是不會得到錄用的。
有一位開發者曾為了測試 Cursor 和 Windsurf 的能力邊界，去開發了一個飛機大戰遊戲，結果發現 AI coding 工具在數值設計等複雜場景效果不佳，還是需要人類專家的 know how，因此如何能準確描述自己的需求預期會極大影響 AI coding 工具的使用效果。
因此有一個機會就是幫助非專業使用者去發現自己的需求並將使用者的需求結構化，比如有開發者之前想開發一個訪談式 AI，透過對話和即時構建原型產品來幫助使用者澄清和定義需求。
4. Coding Agent 會不會像 Siri 一樣成為未來作業系統的附屬功能？
從構想來看，AI agent 或許不會成為作業系統的附屬，相反，未來的 OS 可能會成為 AI agent 的附屬，甚至可以說 LLM 本身就是新的 OS。
Coding agent 本質上是一個能透過寫程式碼完成任何任務的通用問題解決器。只要使用者向 agent 輸入一個任務，agent 就會自行決定是呼叫現有功能，還是透過即時 coding 來完成任務。比如歐美的 AI-native 初高中生已經把 ChatGPT 作為解決一切問題的主要入口，無論是搜尋還是情感陪伴。對他們而言，ChatGPT 在功能上已經扮演了 OS 的角色。
但對未來的長期預測是非常困難的，因為 AI 領域發展非常快，任何超過一兩年的推演都存在巨大的不確定性，討論的過程中應該更尊重短期事實，而對長期預測保持謹慎。
5. 從使用者體驗角度，開發者最希望 Claude Code 支援的功能是什麼？
未來的方向應該是 multi-agent 並行開發。重點是將開發者從繁重的執行工作中解放出來，開發者只需要將執行任務分派給 AI，自己則可以專注於更高層次的產品設計、架構規劃和專案管理。
這事的難點在於 multi-agent 之間的通訊與記憶體共享，需要確保 agent 在協作時能夠同步狀態。現在可以透過一些手動操作來模擬簡易的並行開發，但這並非原生支援，缺乏真正的記憶體共享。
在人應該如何與 AI 進行日常互動的這個問題上：
• 支援 GUI 的開發者認為，在拖拽式新增檔案、配置 API、檢視變更等日常操作上，GUI 比輸入繁瑣的命令列指令要直觀和高效得多，比如新增 MCP 時只需要將網路上的程式碼直接複製到 GUI 中，因此在大眾軟體開發上，純 CLI 會是一個缺點。目前比較理想的狀態是在 IDE 中整合並使用 Claude Code 的強大能力，形成一個 GUI 外殼 + CLI 核心的混合模式。
• 支援 CLI 的開發者認為，真正的效率提升，不應該是讓人更快地完成某個步驟，比如手動貼上 MCP 配置，而應該是讓 AI 自主完成配置的全過程。使用者無需學習如何配置，只需向 AI 下達做什麼的指令，不用關心實現細節，這才是 CLI 的價值所在。給 Claude Code 套一個 GUI 的殼是不難的，但讓 GUI 把全部底層功能用 CLI 或者 MCP 開放出來，是比較難的。
03.
Anthropic 可能會是 Vibe Coding 的 AWS
1. 如何看待 Lovable 等 vibe coding 產品長期價值？
Lovable 的技術護城河其實已經消失了，原因在於：
• Lovable 依賴大量硬編碼的工具和流程來構建應用，這使得 Lovable 在面對複雜場景，或者呼叫像 Supabase 這樣的外部工具時非常脆弱，很容易出現連線失敗的 bug。相比之下，Claude Code 能透過 MCP 動態地呼叫後端服務。
• Lovable 作為 vibe coding 產品最大的亮點是能快速生成漂亮的 UI。但今天使用者完全可以透過給 Claude Code 輸入一個特定的 prompt，例如要求 Claude Code 把 UI 生成的更好看一點，也就是說 Lovable 最大的亮點已經可以透過最佳化 prompt 被 100% 復現，並且隨著模型能力提升還能比 Lovable 做得更強大。
• 雖然 Lovable 作為一個 web，可以不需要任何的下載配置，但長期來看，任何人都可以把 Claude Code 部署到 web 上去實現。
目前有一種趨勢是，產品經理、設計師等非專業開發人員會傾向於使用 Lovable 這類簡單直觀的工具，而專業開發者則會使用 Cursor 或 Claude Code。
考慮到給專業開發者和完全不會程式碼的人做產品，在產品最佳化的方向上可能不同，因此 Lovable 這類產品未來更明智的商業路徑應該是基於 Claude Code 這類強大的底層 agent 進行封裝，做好底層模型不會最佳化的環節，比如做專案的分發與消費，成為專注於作品分享的創作者平臺；幫助使用者在 coding 前理清思路，做構思和 prompt 生成的助手等。
此外，Claude 的 Artifacts 功能也會對 Lovable 和 Bolt 這類產品產生很大的衝擊，未來 3-5 年，使用者最關心的是 AI 工具能不能交付一個高質量、可迭代的產品，產品越複雜，意味著對底層 coding agent 的能力要求就越高，而 Claude 憑藉強大的底層模型，就會有競爭優勢。
Anthropic 在上週更新了 Artifacts 功能，使用者可以在聊天介面裡直接生成、預覽、編輯和執行程式碼，相當於把“AI 原型開發工具”整合到了對話裡。
2. 在 ToC 場景中，AI coding 產品需求卡點在哪？
第一個卡點在於需要對產品做大量的體驗最佳化。大眾使用者需要傻瓜式的體驗，所以要將所有複雜技術都封裝起來。
Claude Code 還有很多人沒有用的原因就在於安裝和使用方法不太完善。這一點 Anthropic 未必會自己花精力做，它有可能會選擇扮演新時代 AWS 的角色，只提供核心模型能力並收取訂閱費用，讓其他公司在它們的模型基礎上封裝簡單易用的 ToC 產品。
第二個卡點在於部署環境。
AI coding 在技術上已具備滲透 ToC 市場的能力，但 ToC 的核心需求多是臨時、具體的需求，需要即時生成一次性的軟體。比如使用者如果想下載某個 Youtube 上的影片並總結內容，AI 會即時生成一個指令碼，呼叫 yt-dlp 和 whisper 等工具完成任務，這個指令碼是一次性的。AI 生成程式碼後，普通使用者可能沒有能力在本地配置環境來執行它。
因此或許需要提供一個 Sandbox 或雲，讓 AI 生成的一次性軟體可以更方便地執行。在這個模式下，程式碼本身變得廉價，而清晰的需求和測試用例變得更有價值。
真正的 ToC 產品爆發點可能在於，每個人都可以為自己創造一次性或高度個性化的應用。個人自用型 APP 可以繞過分發和商業化問題，比如開發個人郵件系統，在使用者開車時幫助總結郵件內容，透過語音互動安排日程或回覆訊息。
04.
Coding Agent 的核心理念比前端形態更重要
1. 如何從 Gemini CLI 的不足中反向理解 Claude Code 的優勢？
• 人才聚集效應
在 Claude 3.5 模型展現出極強的 Coding 能力後，Anthropic 就將幾乎所有資源都傾注於 coding，而並沒有像其他大廠在影像、影片等多個領域分散精力，而 coding 作為目前 AI 最明確的落地場景，也吸引了頂尖的 AI coding 人才向 Anthropic 聚集，形成馬太效應，進一步加強了 Claude 的壁壘。
• 清晰的產品審美
此外，Claude Code 的 CLI 設計背後有清晰的產品審美，但 Gemini CLI 沒有，Gemini CLI 的不足主要源於 Google 急於推出這個產品。它既缺少了 Compact mode，也缺少 Headless mode，在 context window 和 command line 的可互動性上都有欠缺，產品邏輯不清晰。
• 頭部 AI lab 內部 AI coding 最佳實踐的積累
Claude Code 在公開發布前，已經作為內部工具得到了 Anthropic 團隊的長期使用和最佳化，體驗和效能都非常成熟，而 Gemini CLI 的 GitHub 首次提交在 4 月底，缺乏產品的打磨，只是為了市場競爭，利用了大廠的免費策略進行推廣。
即使在開源的 GitHub Copilot CLI 中更換底層模型並補齊相應的功能，也是難以真正復刻 Claude Code 的體驗。因為 Claude Code 的 agent 流程和各項功能都是專門針對自家模型深度最佳化的，GitHub 若替換底層模型，這既不符合 Claude 的利益，也會導致相容性和效能折損，像用 5 號電池的轉接頭去適配 7 號電池的裝置，雖然可以勉強執行，但無法達到最佳效率和效能。
2. Cursor 未來是否可以進化到以任務為互動的方式？並且增加 GUI 進行產品迭代從而增強開發者粘性？
目前 Cursor 可以透過 background agent 來實現這個功能，但使用者已經可以透過開啟多個 Claude Code 的終端來達到類似的多工並行處理效果。Cursor 在這方面並沒有很強的壁壘。
而且在 coding 領域，Claude Code 與 Cursor 其實並不能完全用設計行業的 Canva 和 Figma 對比，底層 coding 的通用性會導致開發者在不同 coding 工具間的遷移成本極低，市場會更偏向去整合，並不會存在 niche 市場。
3. 如何看待 Claude Code（類 iOS 的封閉生態）和 Gemini CLI（類 Android 的相對開放生態）的區別和未來？
Agent 的核心能力比前端形式更重要。
有開發者提到自己最初是因為看重 GUI 的便利性而沒有使用 Claude Code，但重度使用這些 coding 產品後發現，Claude Code 的核心優勢其實在於 agent 的能力本身就已經遠超 Cursor 這樣的競品了，這比前端是 CLI 還是 GUI 更為重要。
但 GUI 和 CLI 並非互斥，可以在 CLI 上加一層 GUI（如在 IDE 中使用）來達到最佳效率，但歸根結底，使用者最終會選擇效果最好的工具，而不在乎其形式。
Anthropic 做產品一直是閉源狀態，有自己的審美，有點 IOS 的感覺，Google 的特點總是起了個大早，趕了個晚集，但憑藉雄厚的資金，總能慢慢追上，就像當年 GCP 追 AWS。
但需要承認的是 Google 的長期優勢在於擁有云服務和自家頂尖模型的完整生態，成本控制能力極強，無需向外部模型廠商付費，Google 模型能力的體現在，Gemini 2.5 Pro 在某些任務上的幻覺率可能是最低的。
4. Claude Code 生成的程式碼的幻覺率有多高？
Claude Code 的幻覺率極低，因為 agentic flow 具有工程上的自主糾錯能力，透過詳細的 To-do list 和自我修正機制，在工程層面解決了底層模型的傳統幻覺問題，能把跑偏的模型拽回來。相比之下，Cursor 會經常出問題，在複雜專案下，出現問題的機率大概是 30-50%，需要人及時檢視檢查。
此外，Claude Code 的幻覺可能更多表現在：
1）生成冗餘程式碼或檔案，也就是說雖然程式碼能跑，但不整潔高效，使用者需要主動去提醒它定期掃描並 Refactor 程式碼庫；
2）修改範圍超出預期，比如在修改功能 A 時，意外地改動了功能 B 的相關程式碼。
有一個減少幻覺率的 Claude Code 使用技巧是，開發者可以在處理下一個不相關任務前，及時清空當前的歷史記錄，因為模型的效能在長對話中會斷崖式下跌，因此，需要解構相互不影響的獨立任務。
在任務複雜度上，Claude Code 已經能處理遠超 CRUD（建立 create、讀取 read、更新 update、刪除 delete）的複雜任務。比如整合兩個不同的大型開源專案時，程式碼量會高達幾十萬行，使用者要求 Claude Code 理解兩個專案後，透過替換核心元件將它們結合，Claude Code 能夠成功完成了主體連線，整體表現能達到 75-80 分。
而對於純演算法問題，比如在特定約束下最佳化矩陣演算法，只要能提供足夠好的測試用例和明確的最佳化指標，Claude Code 也能夠很好地學習和勝任。
05.
AI Coding 的
終級贏家會是誰？
Coding 這個領域的贏家一定會是 LLM 的模型提供商，其次是雲服務廠商。因為他們在產業鏈上的位置更具話語權，同時雲廠商擁有巨大的成本優勢，比如 Amazon 內部正在開發的類似 Cursor 的產品，定價（20 美元/3600 次請求）遠低於 Cursor（20 美元/500 次請求）。
因此，真正具備長期競爭力的，將是那些能夠深度整合先進大模型和雲計算基礎設施的玩家，比如 Google（GCP+Gemini）、AWS 與 Anthropic。微軟和 OpenAI 雖然曾緊密合作，但近期各自的重點也在分化，OpenAI 正將更多精力投入到泛娛樂和泛應用領域。
在中國市場，國內最頂尖的科技公司為了追求最佳的交付效果和全球競爭力，可以使用頂尖的海外模型進行開發，但對於大多數人，比如中小型企業，阿里雲和通義千問會是一個值得關注的組合，海外產品因為地緣政治問題難以進入，而阿里雲可以結合口碑不錯的通義千問模型，切入這個市場。
此外，位元組擁有海量的影片和語音資料，這使位元組在多模態 AI 的研發上限很高，可能在特定領域超越阿里，比如在手勢模型方面，阿里只有約 11 種，而火山的手勢模型有高達 37 種，這種差距在複雜度和飛輪效應方面可能會越來越大。
不過，也有人認為，位元組的優勢在於產品工程能力，底層語言模型的能力一直未能領先。優秀的多模態產品更像是堆工程的結果，而非基礎模型的突破。
排版：夏悅涵
延伸閱讀