跟 Cursor 的 Ian Huang 散步：Coding Agent、創業，還有別忘了記錄過程
前陣子在舊金山跟 Ian Huang 散步。Ian 是 SF 最 hot 的 Startup Cursor 的 Founding Engineer，去年也共同署名了 Cursor 的 Agent CLI 發表文。我們一開始聊他們被 SpaceX 收購後的生活，再到 Cursor 到底是一個 IDE，還是一個 coding agent？結果一路聊到產品怎麼驗證、我正在做的 communication agent，以及一個我到現在還在想的問題：AI 應該幫我們把話重寫得更漂亮，還是應該教我們怎麼把話說清楚？
Foreword
去年認識了 Ian, 就跟他說等他回台北要一起去 barcode, 到現在都沒有去，感覺跟他約舊金山的 Monroe 比較快。 我個人也在人在大廠的好兄弟在做自己有興趣的產品 MVP (最小可行性產品)，做好就錄好 Demo 給我身邊牛逼的朋友看看。
Cursor 其實在做 IDE，還是 coding agent？
我問 Ian：Cursor 現在到底把自己看成 IDE，還是 coding agent？
他的答案很直接：coding agent。 IDE 的部分比較像是在追上既有使用者對開發環境的期待；真正讓產品往前走的，是 agent 能不能理解任務、動手做、再自己驗證結果。
這個說法和 Cursor 後來公開的方向也很一致。Cursor 把 Agent 擴展到 editor 以外的環境，讓它能搜尋 codebase、改檔案、跑 terminal command；他們對下一個階段的描述，是讓人逐漸從逐行寫 code，轉向指揮能長時間獨立工作的 agents。可以看 Cursor 的 agent 實作建議 和 第三個 AI software development 時代 的說明。
我覺得這裡最有意思的地方是：IDE 並不會突然死掉。Ian 自己還是會直接讀 diff、讀檔案來理解 codebase；只是「打開一個 editor 然後自己逐字寫」不再是唯一、也未必是最重要的 interaction。IDE 變成一個人在需要時進去理解、介入、review 的地方；agent 才開始接手比較長的 execution loop。
不是 IDE 消失了，而是「人親自打字」不再是開發流程的中心。這也讓我重新理解我之前寫的 為什麼大公司要自己做 coding agent。真正有價值的不只是模型會不會寫 code，而是它拿得到什麼 context、接得上什麼 tools、能不能在正確的環境裡完成工作。
後來我們也聊到 Ramp、Stripe 這些公司為什麼還要做自己的 coding agent。Ian 的看法是：如果那不是公司最主要的收入來源，最後就很容易被 deprioritize。這不代表 internal agent 沒價值，而是它要真的變成重要能力，得有足夠深的組織承諾。Cursor 公開的方向其實也在往同一個地方走：讓 agent 不只待在 editor 裡，而是能在不同環境工作、跑更長的任務，再把人放在 direction 和 review 的位置。
先決定你想成為誰，然後開始做
在聊產品之前，我們先聊到一個更個人的問題：人到底怎麼找到方向？
Ian 說，他很相信一件事：你先有一個很具體的目標，相信自己能做到，之後就一直找方法。不是每一步一開始都看得很清楚，但只要一直往那裡走，你會慢慢變成那個人。重點不是把願望講得多漂亮，而是有沒有真的開始做。
他給的例子很具體：25 歲前，讓銀行帳戶裡有 500k。他沒有在聊天裡說明幣別；重點也不在那個數字本身，而是它逼你把願望拆成可執行的事情——把 project 做好、找到工作、學投資、存錢。很多人也有同樣的目標，但永遠停在「我很快會開始」。
我很喜歡他提到的一個畫面：把人生過得像有一組紀錄片團隊正在拍。不是要 fake it，也不是每一刻都要很成功；而是你每天做的選擇，能不能讓你對著鏡頭說，這是我真的想做的事。這個概念聽起來很中二，但其實很實際。它逼你問自己：今天我是在累積一個作品、能力或關係，還是在逃避該做的事？
「We just code」其實是一套產品方法
聊到新產品怎麼做、怎麼知道一個 idea 值不值得做時，我問 Ian：Cursor 有沒有一個很明確的 roadmap 或 validation pipeline？
他的回答是：「We just code。」
這句話聽起來很像工程師的玩笑，但後面其實有一套很務實的邏輯。Cursor 有自己的使用者、beta testers，也有內部團隊可以 dogfood。先把東西做出來，讓真的會被它影響工作的人每天用，再根據問題一直調。不是先花很久把 idea 講得很完整，才開始碰產品。
Ian 說他記得早期 Cursor 團隊每天都在想同一件事：怎麼讓明天的自己用這個產品時感覺更好？如果你正在做的產品也是你自己每天需要、而且你真心期待明天用到更好的版本，那已經是很強的訊號。
這不是說不用訪談、數據或計畫。比較像是把它們放回對的位置：它們幫你修正方向，但不能取代你真的把東西交到人手上。對做 developer tool 的團隊來說，最短的 feedback loop 往往不是 dashboard，而是自己今天有沒有因此少卡一個小時。
我後來把這件事跟 GTM 是一個工程問題 放在一起想：產品和 distribution 其實都需要可觀察的 feedback loop。差別只在於，產品 loop 問的是「使用者有沒有更快完成工作」，distribution loop 問的是「下一個對的人會不會因此找到它」。
個人品牌不是 networking 的替代品，但它會留下證據
我們也聊到接下來什麼能力最重要。Ian 說，與其把它叫成一個 skill，他更在意 personal brand。
我很同意。履歷當然有用，但一個能直接打開的 personal website、一個公開的 GitHub、幾個真的有人用的 side project，會比一行「我很有熱情」更有說服力。你可以在面試現場直接 demo 自己做過什麼；recruiter 也有機會在你投履歷之前，先看到你在公開世界留下的東西。
這不代表 networking 不重要。我們的結論比較像是：networking 是 multiplier，不該是你唯一的資產。如果沒有作品、沒有能力、沒有可以交出去的東西，再多認識人也很難長期成立；但如果你已經做出一個不錯的 project，network 才能幫它被更多對的人看見、拿到第一批 feedback。
我現在做這個網站，本身也是同一件事。它不是一張比較漂亮的履歷，而是一個持續更新的證據庫：我在想什麼、做過什麼、在往哪裡走。
我一直想解的，不是「溝通不夠漂亮」
我跟 Ian 說，我最近一直在想一個自己遇過很多次的問題。
當你在 sales 或 GTM 端，會直接看到 customer request；當你在 engineering 端，看到的則是 code、既有承諾、系統限制和 backlog。兩邊對 P0 的理解很容易不一樣，而且未必是其中一邊不夠努力。很多時候只是各自拿到的 context 不同。
我真正想做的不是另一個幫人把 Slack 訊息改得更禮貌的 Grammarly。我的想像是一個 agent：它理解一個人怎麼工作、知道團隊有哪些脈絡；當你要傳訊息、提需求、做決定時，它可以告訴你還少了什麼 context、對方可能在意什麼、以及下一個該問的問題。
但 Ian 馬上拆出兩個其實不該混在一起的問題：
| 問題 | 真正缺少的東西 | 比較合理的產品行為 |
|---|---|---|
| 我不知道工程團隊現在在做什麼 | 工作 context | 每日更新、決策紀錄、blocker 與 ownership 的可見性 |
| 我知道狀況，但不知道怎麼把話講給對的人聽 | 溝通判斷與 social cues | 提醒、示範、角色扮演與事後回饋 |
這個拆法對我很重要。第一個問題可以靠更好的資訊流解；第二個問題不是資訊夠多就會消失。你可能知道 engineer 已經 overloaded，卻還是不知道怎麼提出 request、不知道該先問誰、也不知道怎麼讓對方知道你理解他的 constraint。
先做一個很小、但會讓人變好的版本
Ian 最後給我的建議其實很簡單：先 build，先 demo，看看有沒有人真的喜歡。
所以如果要把這個想法做成第一版，我現在不會從「讀完公司所有 Slack、Notion、GitHub，再理解每個人」開始。那太大，也太容易走向監控。
我會從一個很窄的 interaction 開始：在跨職能的人要提出 request 時，幫他做一個短 check。
- 把 request 的目標說清楚。
- 補上 user evidence 或 business impact。
- 主動寫出自己知道的 constraint。
- 問一個能讓對方補 context 的問題，而不是直接丟一個 P0。
接著測一件事就好：使用者在 agent 不幫忙的下一次，能不能也把 request 講得更好？如果答案不行，這可能只是一個 rewrite tool；如果答案可以，才比較像一個真的能降低 communication cost 的 product。
創業、讀書，還有不想把大學當職業訓練所
聊到後面，我們開始談各自對未來的想像。我一直對哲學和文學有興趣，也希望有一天能回到學校好好讀；但我不想現在就把大學只當成一個換工作的 credential factory。
我給自己設了一個不太浪漫但很具體的時間線：在三十歲前完成學位。在那之前，我想先 work、先 build、先把一些只靠自己也能學到的東西學完。這條路跟直接念完大學、去大公司工作的典型路徑不一樣，所以我當然也會懷疑它到底對不對。
但 Ian 的提醒又回到一開始那件事：如果你真的想要的東西很清楚，就應該開始往它走。不是等到所有 doubt 消失才開始。doubt 大概不會消失；你只能一直做，然後在做的過程裡修正。
回到「build for yourself」
跟 Ian 聊完，我反而沒有覺得這個 idea 被否定了。比較像是被逼著把它講得更清楚。
我原本想像的是一個能替團隊補 context 的 AI；Ian 提醒我，context 和溝通能力是兩件不同的事。前者可以做成 daily update、決策紀錄或搜尋系統；後者要設計成能讓人練習、理解、慢慢內化的 feedback loop。
而這也讓第一版變得更實際：不是做一個無所不知的 workplace agent，而是先替正在跨職能溝通的人補上一個他原本看不到的盲點。
Idea 當然便宜。真正有用的是把它做出來，讓自己和幾個真的有這個痛點的人用，然後看隔天的工作有沒有變得比較順。
這大概也是那天所有話題最後指向同一件事。不管是在做 coding agent、嘗試創業、經營 personal brand，還是想弄清楚自己到底要不要回學校：先不要把想法停在腦中。做出一個版本，讓它被世界碰到，然後再決定下一步。
延伸閱讀：Cursor 的 Agent CLI 由 Ian 與團隊共同發表；如果你對 agent 的 context layer 感興趣，也可以看我整理的 MCP、Skills 與 Workflows。