在 startup 工作 6 個月

作為一個對做酷東西和做產品感興趣的人而言，在一家優秀的新創公司實習是一件很幸運的事。一方面是因為能與很強的人共事，可以學到他們的心法以及做事方法論，另一方面是因為新創公司速度快、人少的特性，讓我有機會接觸到一些我現在能力範圍外的任務 (punch above my weight)。這篇文章主要寫的是這幾個月對專注的新理解，以及在 AI 時代做技術工作的一感想。

專注是持續、有意識地在一個明確的方向耕耘。

專注是持續、有意識地在一個明確的方向耕耘。這至少意味著兩件事，一是知道想前往哪個方向，二是清楚知道對於前往這個方向而言，什麼是重要的。

過往，我幾乎只會在課堂小組討論的時候使用 focus 這個詞。而在 Heptabase 的工作語境下，「專注」和「聚焦」這兩個概念是不斷出現在各種地方的，讓我感到熟悉卻陌生。對我而言，這可能也是那種要見到貫徹這個概念的同儕，切身體會到專注的力量後才能學會的事情。

在每週的工作都需要妥善聚焦的環境下，很容易感受到專注對做好一件事的重要性。比方説有一次我認為我的一個目標是「改進XX的生成機制」，這個問題我想不出一個非常優的解法，因此當我在網路上看到一些講交互的文章後，就突然「恍然大悟」，想說原來這個東西做不好是因為缺乏「好的交互」。於是我就設計了一套交互系統，覺得自己的想法非常棒，殊不覺這裡「XX的生成內容」才是這個產品的關鍵。這是我數次失焦經驗中的一次。

如果沒想清楚什麼是重要的，就很容易找到理由去逃避面對重要的任務，通常這個時候我們會下意識地去找一些簡單的、自己會做的事情去做，從而喪失實質產出。

Peter Thiel 基於這個觀察，在擔任 PayPal CEO 的時候，推行了一套非常不尋常的管理政策： One Thing，即每個人只負責一個事情。他不會和人們討論他們 One Thing 之外的工作。他認為如果讓一個人同時負責一件困難但有價值的 A+ 級任務和多件不困難但也沒什麼價值的 B+ 級別任務，那人們就會因為害怕困難而拖延解決 A+ 級任務，而去處理 B+ 任務。當一間公司所有人都在執行 B+ 任務時，那這間公司就只會是一間平庸的公司。他需要所有人——即使是因為困難而痛苦地——專注在解決需要他們解決的困難 A+ 任務，如此才能造就優秀的公司。

在 Heptabase 的社群裡，可以很清晰的感受到 CEO Alan 是如何把公司有限的資源聚焦在重要的事情上。比如在今年八月份對公司的公開問答中，Alan 對 「Heptabase 對軟體共通性的態度」的回答「我們不釋出產品 API 是因為產品還在快速迭代中，過早的釋出 API 會大幅增加維護成本，降低團隊對核心功能的研發速度，還容易暴露一些缺口給不懷好意的人。這些不是我們現階段想擔心的問題。」；「對團隊擴張的計劃」的回答「我們不會因為競爭對手開發速度快、團隊規模很大就擴張團隊。只有當我們需要更多的人力去設計和開發，且公司有足夠的經常性收入可支付員工薪水的時候，我們才會擴張團隊規模。」在 AI 能力爆炸增長的時代，幾乎所有產品都想在產品裡面加上一些 AI 功能。對於這個時代課題，Heptabase 的答案我覺得把「專注」的意思展現地淋漓盡致 [1]，「Heptabase 的一個專注點是打造能更好幫助用戶理解複雜課題的能力 (capability)，因此我們首先會專注在那些可能能幫用戶達成上述目標的、更困難的功能，其餘簡單但對用戶有幫助的功能我們會慢慢落實。」

總結一下，專注是持續、有意識地在一個明確的方向耕耘。專注的具體表現就是不斷問自己，這個會耗費有限時間和精力的行為能如何幫助我們實現我們想實現的目標與價值。

在 AI 時代做技術工作，比起技術細節，更重要的是能用軟體工程的概念解決問題。

對於做技術工作而言，我認為比起技術，更重要的是能用軟體工程的概念解決問題，並理解如何更好的與他人協作。

剛加入 Heptabase 的時候，我是一個只會用 Python 寫算法、邏輯，用終端 (terminal) 做用戶界面的物理系大學生，沒寫過 API，沒寫過 JavaScript。

今年六月初的時候，第一個產品原型的 Python 後端雛型寫的差不多了，但要檢視輸出結果實在很麻煩，要製作一堆文字檔，然後貼到另一個軟體裡面才能查看。因此 Alan 表示我接下來需要學會做前端的網頁 App，於是我就花了一個多禮拜速成了 JavaScript 和 ReactJS 的概念。儘管我有三年多的 Python 基礎，但由於缺乏 JavaScript 的肌肉記憶，自己整合程序還是非常慢。在 ChatGPT 和 Claude.ai 的加持下又拼了快一週才把一個非常粗糙的原型搭好。

此時 ChatGPT 和 Claude.ai 的魔法已經顯得特別好用了：如果我能把一個大的功能拆成很多小的組件，那每個組件就可以讓他們高效編寫。我需要做的，就是做功能拆解，然後讓 AI 幫我 debug 直到可以成功運行。

這個階段，儘管有兩家 AI 公司加持，從沒搭過 API 的我搭建一隻能在前後端溝通的 API 還是需要 2 小時以上。因為我需要了解 RESTful API 的概念、了解如何在後端寫 GET/POST method、了解在前端要怎麼發送請求、測試、解決 CORS error 等。

接下來 Cursor 的出現改變了一切。Cursor 是一個號稱能當「你的 AI 搭檔程序員」的集成開發環境 (IDE)，或說一個 AI 加持的 VSCode。它除了基礎的生成程序、文字功能之外，還可以預測你接下來的游標位置、在了解 A, B 程序內容的情況下改寫 C 程式，甚至一次編輯數個程序。這個階段，我寫一隻能用的 API 最短的時間是 2 分鐘，我給它前端文件、後端文件和我希望這個 API 能做什麼，它就能立刻編輯那兩個文件。我接下來要做的就是打開前後端伺服器做測試（一次通過）。

十月中下旬的時候，在 Cursor 加持下，我做了另外一個比較簡單的產品原型，而這次前端加後端我只做了兩天。後端我還是用 Python 編寫，大概有 450 行（包含註解），基本全部都是 Cursor 用 Claude 3.5 Sonnet 幫我寫的。我需要做的全部剩下 (1) 想出後端邏輯 (2) 拆解成小的組件讓 AI 幫我寫 (3) 讓 AI debug 直到通過測試 (4) 寫 LLM 產品裡面的核心提示詞 (prompt)。

在知道自己最終要搭建什麼的情況下，為什麼十月的時候我只需要兩天就能做出一個還不錯的原型，而在六月的時候我需要花一個禮拜呢？我認為關鍵區別在於我對概念的熟悉度。透過對概念的學習與經驗的積累，我現在非常清楚 API 的功能、什麼是 RESTful API、什麼是數據庫的 CRUD 操作、為什麼會有 CORS error，因此我可以快速在內心建構後端的邏輯，並拆成小組件讓 AI 執行。有清晰的概念，才能利用好的工具快速搭建問題的解決方案。

至少就現在而言，我認為對軟體工程中概念了解的水平會直接影響你利用 AI 工具的產出。如果你本身的產出就是一般工程師的 10 倍，那 AI 工具會讓你的產出比一般工程師多 100 倍；如果你本身是一般工程師，那 AI 工具會讓你的產出比原本多 10 倍；但如果你本來什麼都不知道，那你還是什麼有用的產出都不會有，畢竟 0 乘任何數還是 0。

其它感想

  1. 寫好 prompt 最困難的部分在於成為執行這個工作的專家，並把腦中對執行問題的一切理解清晰地描述出來。
  2. Agent 的能力來源於模仿人類專家的工作模式，因此 Agent 的最終價值是允許所有工作被以最高效的方式完成。
  3. AI 讓技術的成本降低了，因此創意與發現問題的能力會顯得更有價值（一直都很有價值）；與人打交道的工作也許也會變得更有價值。
  4. 在公司看見好多 Y Combinator 創業哲學的具體表現，從環境中學習的感覺好讚！
  5. 看到新的東西被從沒被滿足的用戶需求裡創新出來的感覺真是太酷了！
  6. 有時候想不出好的解決方案時真的很難受，這時候會做很多 fake work ><
Thanks to PinChen Chong and Kelly Ong for reading drafts of this.

[1] 這個部分是我作為一個實習生對 “Heptabase's position in the PKM market and its attitude toward AI.” 和 “Heptabase's plans for upcoming feature direction.”，結合 Paul Graham 的創新公司應該要 “run upstairs” 的理解，不代表 Alan 或 Heptabase 的想法。