作為 Cursor 和 Claude Code 的研發者，他們是如何看待和使用 AI

近日，Cursor 副總裁 Lee Robinson 和 Claude Code 之父 Boris Cherny 都分享了他們的 AI 感悟和經驗，特別是 Lee Robinson 的《AI codes better than me. Now what?》就很好展示了對於開發者來說，2026 開始程序員應該如何轉變自我的定位。

類似的，在之前的《AI 讓我誤以為自己很強，未來程序員的轉型之路》也思考過未來 AI 浪潮下程序員的轉變。

首先對於 Lee Robinson 來說，他總結的現狀是：他已經很少親手寫代碼了，比如最近他使用 Rust 實現了一個圖片壓縮工具，可編譯成 WebAssembly 並在 SvelteKit 應用中運行，而這個過程裡他沒有親手寫一行代碼，完全由 AI 代理完成。

另外一個例子就是 Space Invaders 遊戲克隆，他為 Analog Pocket（類似 Game Boy 的掌機）開發了一款遊戲，而這個過程需要用到 Verilog 硬體描述語言，但是他對 Verilog 一無所知，不過在 AI 的幫助下，他最終還是完成了硬體層面所有的編程。

這兩個例子很直觀的體現出了 AI 的能力和對開發者的影響，未來 AI 肯定是讓 AI 者不再只是局限在某個技術標籤下，所以他在半年前加入了 Cursor，因為他強烈感覺到軟體工程的版圖正在發生巨變，所以他希望參與到定義這種變化。

Cursor 確實也在影響著開發者的開發習慣，基本上你不用 Cursor 也用過 Trae？

對比過去的模型指令遵循能力差，並且經常出現幻覺的情況，現在的 Codex Max 或者 Opus 4.5 都表現出了非常強大的代碼完成效果（就是貴），對於 Lee Robinson 來說，他覺得目前的模型在寫代碼方面確實已經比他更強。

所以，對於未來開發者而言，確實不應該糾結於在“寫代碼能力”上去和 AI 對比，因為你真寫不過它，沒它持久也沒它能輸出。

所以 Lee Robinson 認為，對於開發者來說，寫代碼這件事不再是瓶頸，他建議：

不要因為過去 AI 現在不擅長某個領域（如 Rust 或底層代碼）就認為它永遠不行，模型在這些領域的進步速度極快

讓 AI 接管軟體開發中大量繁瑣和重複性的工作

當生成代碼變可用時，工程師的價值將體現在“品味”上，開發者不要只關注代碼，更要關注產品本身、使用者體驗 (UX)、市場行銷以及如何構建使用者真正喜歡的東西

所謂未來的核心不再是“如何寫代碼”，而是“如何構建和管理好優秀的產品”，並如何使用好 AI 完成需求。

就連 Android Studio 的全新 AI Agent，都在不斷增加 vibe coding 的支持，AI 在開發者領域如今確實已經成為不可或缺的存在，就像 StackOverflow，隨著 AI 的發展，如今的“活人”流量可以說是幾乎跌停，這大概也是 AI 浪潮的典型體現：

另外前些日子 Manus 賣身 Meta 的身價也引起熱議，實際上一些專業開發者“看不上” Manus 的產品，但為什麼它還是能有如此身價？

實際上 Manus 的服務對象很多是非專業技術的人，使用 Manus 的核心用戶，大多是那些不需要知道該使用什麼技術棧或如何構建資料庫，他們更多是完全不理解技術的人，這些用戶基本是追求一個結果，不在意過程的創業者和企業主。

這也是一個方向，如果 AI 可以產出初步結果驗證產品，那也許代碼這個中間過程如何，未來或者也沒那麼重要？

就連谷歌 Gemini API 負責人都自曝，用競品 Claude Code 在 1 小時復現自己團隊一年成果，雖然還不夠完美，但這已經很能說明問題：不要和 AI 比代碼輸出的能力。

那麼為什麼 2026 了，還有很多人使用 AI 的過程中發現，AI 並不好用？這個問題可能 Claude Code 之父 Boris Cherny 的經驗分享可以給出答案，他在 30 天內跑了 259 個 PR ，所有代碼都是 CC + Opus 4.5 完成，最長的 session 跑了近 42 小時。

也許你覺得不好用，主要是因為沒用好沒用對，而不是 AI 不行。

Boris Cherny 提供了一些 CC 的使用技巧：

在端中並行運行 5 個 Claude 進程，並且將標籤頁編號為 1-5，通過系統通知來了解哪個 Claude 進程需要人工處理，這樣可以有效提供任務並行效果：
團隊共享一個用於 Claude Code 的 CLAUDE.md 文件，每當發現 Claude 做錯了什麼，團隊可以添加到 CLAUDE.md，讓 Claude 下次避免犯同樣的錯誤
Code Review 時 @.claude 自動更新規則到 CLAUDE.md，這裡主要通過 Claude Code Github action 來實現
大多數會話都從 plan 模式（Shift+Tab twice）開始，一個好的 Plan 非常重要，不要一上來就盲目開始需求
高頻工作流都做成 slash commands 並存放在 .claude/commands/，這樣 Claude 自己也能調用，可以減少人工的重複處理接管
使用一些 subagents，例如 code-simplifier 會在 Claude 完成工作後簡化代碼，verify-app 會提供詳細的端到端 Claude 代碼測試指南，這些 subagents 的作用是自動化處理大多數 PR 時最常用的工作流
不使用 --dangerously-skip-permissions 參數，推薦使用 /permissions 參數預先允許一些環境中安全的常用 bash 命令，以避免不必要的權限提示，這些配置大部分會提交到 .claude/settings.json 文件並與團隊共享
長任務用可以用 ralph-wiggum 插件讓 Claude 自動循環直到完成
要想讓 Claude Code 發揮最佳效果，最重要的一點可能是給 Claude 提供驗證運行結果的方式，如果 Claude 擁有這種反饋機制，最終結果的質量將提升 2-3 倍，比如 Claude 可以使用 Claude Chrome 擴展程序測試提交的每一個變更。