醒醒吧！CEO猛吹AI寫95%代碼，績效考核卻還在拼程序員手速？

在 ai 工具席捲開發圈之後，一批技術老兵的工作方式悄然發生變化。superhuman （原生 ai 郵件應用）工程負責人 loic houssier 正是這場轉型的親歷者之一。

這位出身數學背景、擁有密碼學工程經驗的 vp，曾帶領團隊經歷了從大型 b2c 到核心底層架構的複雜挑戰。而當 chatgpt、claude code 等工具走進日常，他選擇放棄流程式控制制權，把實驗權交還給一線工程師——預算公司全包，工具隨便試，甚至不設「推薦清單」。

「ai 時代沒有黃金路徑，」他說，「你得自己摸索自己的節奏。」

在這篇深度對談中，我們將看到：

• 流程重構：「過去我們靠標準化工具（如統一 ide 和 ci/cd）提供『黃金路徑』來提升效率，但現在工具每周都在變，這條路徑本身已不穩定。」

• 績效評估新法：沒有單一 kpi 來衡量 ai 帶來的真實效率提升，「如果我們能找到一個衡量一切的指標，我們就都可以退休了，也不需要什麼工程領導」。

• 觀望代價在變大：「我們那時可以花一年去慢慢學 jquery，沒關係。但現在你等得太久，再找工作可能就困難了。」

• ai 是加速器不是方向盤：ai 不能代替領導力，也無法繞過「產品判斷和用戶調研。」

主持人：我想從一個簡單的問題開始：你們是怎麼進入軟體和科技行業的？

loic houssier： 我這邊其實進入編程領域已經是很久以前的事情了，我現在頭髮已經有點花白，能說明問題了（笑）。我第一次接觸代碼，是在中學的時候。我那時候拿到了一台 amstrad cpc 6128（對於老一輩來說，可能會有一些回憶）。那時你會在報紙上訂閱內容，末尾會附一些教程，你可以照著教程，在機器上做一些很酷的東西。那是我第一次接觸編程。

但到了大學，我愛上了數學。我並不是計算機科學出身，我一路念的是數學，一直到碩士階段。在碩士期間，我開始嘗試把數學應用到安全領域，做了很多密碼學方面的東西——你既要理解演算法和理論，也要能在真實世界中驗證它是否可行。那是我第一次深入理解諸如 c 語言、指針、演算法優化、內存管理等等。

你提到職業起伏，我也一樣經歷了很多高低起伏，甚至可以說是左右橫跳（笑）。雖然我大部分時間都在科技行業，但也幸運地在軟體行業之外工作了兩年。那段經歷讓我從領導力方面學到很多，可能我們後面可以聊聊這個。

ben matthews（stack overflow 的工程高級總監）：我一直很喜歡聽別人分享自己是如何進入科技行業的。每個人的路徑都不一樣，特別是那些從別的行業轉行進入科技的人，他們會帶來很多獨特的視角和背景。那麼你是如何讓擁有不同背景的工程師們，統一對「成功」的認知呢？你有哪些方法促使他們達成共識？

loic houssier： 我自己的背景是數學，而數學的核心是發現模式，試圖對現實進行建模，用模型近似現實。我覺得作為一個技術領導者，其實工作本質上是一樣的：幫助人們退一步看問題。你今天面臨的狀況，可能和幾年前經歷過的事情並沒有本質不同。

我的職責之一就是幫助大家建立這種連接：原來這之間是有模式的，也許我在做一些事情時不是最優方式，但只要我退一步思考、從別人的經驗中學習，我就能改進自己。我曾在 b2c、b2e 領域工作，也做過核心技術工作，但回頭看，很多問題其實是相似的。所以我認為，我工作中很大一部分是在幫助團隊成員跳出當下，避免陷入太多眼前的具體細節，而是能夠看到更廣的背景、更高的視角。

ben matthews：我特別認同這種觀點。每個人背景不同，從彼此身上學習，才是最重要的。也不是非要讓大家統一看法，而是通過融合不同方法論，構建新的共同理解。我很好奇，你是如何創造這種「面對面溝通、一起創新」的機會的？

loic houssier： 首先，你得刻意去創造這種機會。這並不容易。我們節奏很快，面臨市場壓力、競爭壓力、業務壓力，執行是第一優先順序。在這種高壓之下，往往很難抽出時間去建立人與人之間的聯繫。superhuman 是一個完全遠程、分散式的公司。我們的員工從舊金山到阿根廷的巴塔哥尼亞、加拿大的新斯科舍省的哈利法克斯，甚至還有人在倫敦。時區跨度非常大。如果我們只專註執行，就會錯失那種人際聯繫、關係的建立。

所以我們會定期組織線下團建，比如組織各級管理者的線下聚會。你需要為此刻意創造空間，真正有意識地去做，尤其是在初創公司這種節奏中，信息的流動方式和信任的建立方式都不同於線下辦公。這就要求我們更有「刻意性」（intentionality）。

我們在某次「管理者團建」中做了一些戰略對齊的工作：統一對公司目標的認知、統一我們的價值觀和工作方式。因為一旦這些達成一致，團隊就可以有更大的自主權，每個人都知道公司的方向、我們作為領導者的定位、我們希望怎麼傳達這些給組織的其他成員。當對齊完成後，團隊就能基於這種共識快速行動。我們稱之為「對齊中的自治」（aligned autonomy）。通過線下團建建立連接和信任，然後形成一致性，最終加快組織節奏。

ben matthews：我完全同意麵對面聚會的價值。我們在 stack 做線下團建時，也誕生了很多好點子，甚至場地的改變都能激發創新，不是因為換了場所，而是換了人與人互動的方式。你剛剛提到「對齊中的自治」，有沒有一些具體的例子，能說明這個策略如何推動團隊加速前進？

loic houssier： 一個很好的例子，就是 ai 的落地。

我剛加入 superhuman 的時候，正值我們開始談論 chatgpt、claude code 等各種 ai 工具陸續出現。superhuman 的團隊中有不少是經驗豐富的老員工，所以我們已經形成了一些習慣、一些默認的工作方式，包括預算使用、引入新工具的流程等等。

在 superhuman，我們做了一件事是：我們意識到這是一個全新的時代。我們還不知道最佳實踐是什麼，也不知道將來會用上哪些工具，但我們知道這一定會帶來某種程度上的顛覆。那麼我們能做什麼？

這就回到「對齊式自治」（aligned autonomy）的概念。我們開始思考：對一個身在巴西的工程師來說，來自高層的哪些信息和資源能真正幫助他更快地適應並使用這些新工具？我們得出的答案歸結為兩個方面：

第一，是要移除繁文縟節。我們要明確告訴大家：「你想嘗試什麼都可以。」這是我們的首要原則。不要太擔心合規性，我們會簡化流程，承諾在 24 小時內完成合規審查。不管你提交的是 soc 2 type 2 或其他合規相關事項，交給我們。我們會掃清這些障礙，讓你可以輕鬆嘗試各種工具。

這就是我們第一個對齊點：我們會盡一切努力讓你們可以輕鬆地嘗試任何你想試的工具。沒有任何限制，也沒有所謂的「優先廠商」。你只要覺得有意義就可以試。

第二個方面是：預算我們來承擔。如果你想同時嘗試三四五個工具，需要購買訂閱服務，那也沒關係，我們支持。我們做了相應的預算分配，確保大家在試新東西時不會顧慮成本。

有時候你可能會猶豫：「這個工具看起來不錯，但有點貴，而且我已經在用 copilot 了，或者我們公司已經用了其他工具，感覺可能會多此一舉。」所以我才特彆強調我們團隊中有很多「老兵」，有些習慣已經根深蒂固，不太會主動去質疑和挑戰它們。

所以我們主動設定了新的對齊方式：這是一個全新的世界，規則已經變了。大膽一點，瘋狂一點，你完全有資格去嘗試新東西。

這也帶來了一些有趣的現象。比如在最初的一兩個季度里，我們看到各種零散的嘗試，大家各自採用不同工具，有些使用 chatgpt，有些在試新 ide，我們沒有強行干預，也不限定平台或工具。雖然並非所有嘗試都可控，但我們營造出一種緊迫感和「被賦能感」。

結果是，幾乎每個人都開始使用一些新東西。有人用 chatgpt，有人嘗試新的 ide，各種不同的方式。我在這不點具體工具名稱，但總之是百花齊放。

而一旦我們成功創造出這樣一個開放、自由、積極嘗試的環境，接下來就是時候重新強調「對齊」了：你們已經擁有了充分的自主，現在我們要開始建立共識，形成統一方向。

ben matthews：我特別想聽聽，這些 ai 工具是如何改變你們的日常開發流程的？現在的 ai 工具層出不窮，有點像「西部蠻荒時代」，你們如何在其中找到新常態，提升工程效率？

loic houssier： 這確實是一種全新的範式，不只是給一線工程師（ic）帶來了新工具，對於我們這些管理者來說也是一樣。

過去我們提升團隊效率的方式，是通過一定程度上的標準化，比如為大家提供一條「黃金路徑」（golden path），這樣大家可以在類似的流程和工具中優化自己的開發方式。比如將 ide、 ci/cd 平台進行適度標準化，然後圍繞這些標準化工具建立相應的開發者支持系統。

但現在的問題是，這些工具幾乎每周都在發生變化，你說的沒錯，而且你提到一個很重要的現象是——有些新工具只是嵌入到現有流程中的補充，比如它可能集成在你正在使用的 vs code 中，那麼體驗上是延續的，流程也大致不變。

還有些人可能主要是通過終端開發，或其他工具，把它們整合進自己的開發流程。

但越來越多的情況是：整個流程本身都在發生變化。比如說，openai 的 codex 就代表了一種全新的工作方式。你會給這個 agentic 框架發一個請求，然後它返回一個 pr。你甚至不需要打開 github，只要發出一句話：「嘿，我發現某個區域有內存管理問題，幫我修一下。」它就會返回一個修復 pr。

我們現在確實有一些開發者就是這麼乾的。他們早上會發出一堆請求，完全非同步處理，然後專心去做自己核心項目的開發。到了中午或某個時間點，他們再回來看 agentic 框架生成的 pr，這時他們更多是在做 review，而不是親自寫代碼。

工作流程變了，思維方式變了，連日常的時間安排都變了。

而現在我們還處於一個太早期的階段，還不足以確定哪種新流程會真正成為「新常態」。所以我們目前的做法，是先去捕捉當前的最佳實踐。

所以我們成立了一個 ai 公會（ai guild），參考 spotify 的公會模式。

我們以前就有前端公會、後端公會，確保各技術棧的一致性。現在 ai 公會由各個平台代表組成，因為不是每個工具都適用於所有人，比如 ios 工程師的需求就很不同。

ai 公會的工作是識別並分享最佳實踐，追蹤工具的使用情況，了解哪些團隊沒有採用 ai、原因是什麼、他們的工作流程是否存在特殊性或差異。總之，我們正在非常有意識地推動這場變革。

ben matthews： 我們在 stack 也有 ai 公會，遇到的挑戰和好處都非常類似。來自不同崗位的人不斷分享新工具，也有人跳出來唱反調，說「我們絕不該用這些工具」。

loic houssier： 對（笑）。

ben matthews： 但這其實是個很好的平衡。每個人都有自己判斷的標準，比如這個場景可以用 ai，那個場景暫時別碰。但希望未來我們能繼續發展這些工具，逐步形成更系統的工作模式。如何獲取數據、如何不斷改進它、以及如何在內容生成與內容交付之間形成一個循環反饋機制。

不過我真的很喜歡「ai 小組」這個設定。我們在 stack 也很幸運地得到了高層的支持，鼓勵大家去嘗試、去實驗、重新組合已有的方式，看看新的可能性。我們鼓勵大家跳出舒適區，探索 ai 可以在哪些地方真正幫上忙。

像文檔處理、測試生成這些地方，我們發現 ai 有一些顯著的「快速勝利」。現在我們正繼續探索其他代碼區域，看看哪些地方可以穩定、可靠地交給 ai 去重寫，同時也在權衡人類上下文理解的不可替代性。某些地方 ai 確實給出了新穎的解法，整個過程很有意思，也很像是在探索一片技術的新邊疆。

loic houssier： 確實有意思。ai 另一個真正帶來幫助的地方，是我們以前一直想做、卻總沒有時間做的「邊角項目」。這些項目通常不是直接面向生產環境或客戶的，而是一些輔助腳本、數據處理器——你一直想著「要是有空寫個腳本多好」，但總是抽不出時間。而現在你可以把它當作一個副項目快速搞定。我們在這類繁瑣工作上收穫了不少「快感」。

ben matthews： 而且不只是工程師才能用 ai，現在很多非工程背景的同事也可以用 ai 快速搭個小應用來輔助他們的工作。這真的是打開了一扇門，大大縮短了學習曲線。

loic houssier： 是的。在 superhuman，我們非常注重設計體驗。我們花了很多時間去思考用戶流程和交互細節，因為我們希望產品用起來「感覺對」。而這種「對的感覺」，光靠 figma 等工具是體驗不出來的。你需要真的去「用」這個功能才知道是否順暢。比如 v0 這樣的工具，讓產品經理和設計師可以快速生成一個能運行的交互版本，你可以馬上知道：「啊，這個用起來卡卡的，雖然圖上看不錯，但實際不順暢。」而這些工具能做出非常像樣的 poc（原型），讓你提前試用，這是對我們幫助非常大的一個領域。

ben matthews： 我也很喜歡這種「原型」的使用方式，它真的能幫你解釋清楚某個功能。我們在 stack 最近準備推出一個新功能，其實一開始並不是工程師團隊提出來的，而是別的同事有了個想法。他們一開始很難用語言解釋清楚，但通過 ai 工具快速搭了個 demo，雖然不是完整功能，也沒準備好上線面對數百萬用戶，但這個交互原型一下子讓我們都懂了：「噢，原來你是這個意思！」這比起單純講解要有說服力得多。

loic houssier： 確實如此。在設計師、產品經理、工程經理或者技術負責人之間的協作中，ai 工具極大地加速了溝通和試驗。

這也帶來了另一個變化：ceo 和董事會開始期待，「嘿，你們是不是可以把速度提升一倍？」於是整個行業的期待值也在上升。

你看到很多 ceo 在外面宣稱他們有 95% 的代碼是用 ai 生成的——我對這些說法持保留態度，但這種「吹」的風氣無形中製造了同行間的壓力，讓你也不得不評估自己團隊的 ai 應用成效。

我很好奇你們在 stack 是如何面對這些壓力的？

ben matthews： 我們在 stack 引入了很多 ai 工具，我自己一直堅持的一點是：任何要上線的東西都必須有人類把關。有些工具我們用來做內部的事情，比如數據整理、分類、排序等，生產壓力不大，我們就不強求人工介入。

但 我們把 ai 看作是加速工程師，而不是取代他們。 特別是那些重複性高、枯燥的任務，比如排序或操作執行幾十次，ai 非常適合幫忙。而人類依然在負責 pull request 檢查、構建流程監控等關鍵環節。

ai 幫我們很大的一點，是提升了監控與可觀測性的響應速度。例如，我們可以更快地被 alert 通知某些代碼變化或異常，甚至還能幫助我們合併重複邏輯。它確實幫某些項目大大縮短了開發時間，尤其是那些以前要花很多時間寫「基礎支撐邏輯」的場景，現在能用 ai 快速完成，交付效率和穩定性都提升了不少。

loic houssier： 我們還有一個明顯的變化是新人的入職體驗變得更好。比如新工程師加入一個他們不熟悉的代碼模塊，可能涉及一堆 api，不是他們擅長的語言，還有很多依賴關係。以前他們需要花很多時間搞清楚「地圖」。但現在通過 claude code、copilot 等工具，他們可以像請教一個懂代碼的同事那樣直接提問：「這個模塊怎麼工作的？」「這個庫和那個庫之間有什麼聯繫？」工具會一步步引導他們，像個貼身導師一樣。

我有個工程師在評審中就說到這一點：「過去我可能得花兩三天才能理解這個模塊的來龍去脈，現在只要用對了工具、問對了問題，一個小時就搞清楚了。」這真的很讓人震撼。

ben matthews：換個話題，我們聊聊 ai 背景下的一些「傳統問題」。比如，如何衡量工程團隊的績效？ai 是否改變了你對「高績效團隊」的判斷標準？

loic houssier： 我覺得，評估生產力永遠都會涉及定量和定性兩個方面。我真希望有人能發明出一個唯一的定量 kpi，讓我一看就知道——對，就是這個指標能告訴我真實情況。

但現實是，我現在還主要依賴一個特定的匯總性 kpi，它更多是用來看趨勢，而不是看絕對值。這個指標就是「每位工程師每周的 pr 數量」。

我們當然也用 dora 指標、space 模型這些通用框架，但我發現這個 pr 數量的指標更像是一個帶寬吞吐量的參考。它僅代表帶寬，不會影響結果。這個指標是可以被「玩弄」的，比如說你可以故意拆分成一堆小 pr 來灌水。但只要你明確告訴團隊：「這個指標不是用來考核你們的，不要作弊，它只是用來發現哪些團隊遇到了阻力。」比如某個團隊 pr 數突然下降，可能是他們的技術棧比較複雜，也可能是正在重構大模塊。那你就要深入去了解原因，而不是一味要求數字好看。

對我來說，這個指標一直很好用。它能幫我了解每位工程師每周提交多少 pr，我們會按團隊人數進行歸一化，這樣即使團隊人數變多，仍能衡量整體的吞吐量。從定性的角度來說，你回頭看，有時你會感覺，「哇，這個月他們效率爆表」，你可以把這種感覺和實際數據聯繫起來。

我覺得這是一個挺有意思的指標。而且自從我們引入 ai 之後，這個數字確實變高了。換句話說，從純粹的吞吐量來看，ai 讓我們的效率更高了。但這不意味著最終交付給用戶的成果質量也變好了。 這方面我們得通過其他方法去衡量。所以我們也補充了一些定性分析。比如我們每個月會做一次員工問卷調查，問大家：「ai 對你有沒有幫助？」「你每天都在用 ai 嗎？」「使用體驗如何？」

我們確實看到一些很明顯的變化：九個月前，大家還帶著懷疑態度；但現在，絕大多數人都會說，「ai 是我日常工作的一部分了。」根據我們最近在四月份做的一次調查，大家主觀反饋是，ai 幫他們節省了大約 20% 的時間，也就是生產力提升了 20%。這還是個比較保守的估計。

有些人在項目的特定階段能達到 40% 的提升。特別是你剛加入一個新項目、還在接觸階段，有這些 ai 工具輔助時，成長速度就會越來越快。

所以，從總體來看，在我們這種以資深工程師為主的團隊里，大家對 ai 的接受度和理解度已經很高了。保守估計，ai 至少提升了 20% 的生產力，實際可能比這還要高。

ben matthews： 你剛才說的內容我太有共鳴了，尤其是那種「如果我們能找到一個衡量一切的指標，我們就都可以退休了，也不需要什麼工程領導」——太對了。我也同意數字很重要，但它們只是指標，是一些變數，幫助你判斷團隊的運行狀態。

不管是開發速度還是 pr 提交數，經典那句話怎麼說來著：「你告訴我怎麼衡量我，我就能告訴你我會怎麼行為。」這正是問題所在。而當我在團隊里嘗試緩解這種擔憂時，我也會強調，「這個數字只是幫助我們發現一些模式。」

比如說我們用開發速度（velocity）作為例子，有時候某個團隊的故事點（story points）突然下降了，我們就會看看到底是故事本身變了，還是有人請病假了？我們會去看能不能從數據中讀出什麼信號。或者某個團隊數據突然暴漲，那我們也會問，是不是他們在某個領域特別擅長？是不是我們做了什麼事，真正提升了他們的效率？

所以我們更傾向於把這些指標看成「值得深入觀察」的線索。

loic houssier： 對我來說，這些指標是非常好的「對話起點」。當某個 kpi 出現上升或下降趨勢時，我就拿它出來和團隊對話，比如說：「大家，上周我們的數據有點下降，能不能幫我解釋一下情況？」這種交流不是為了責備誰，而是為了了解背景。

可能團隊會說，「我們剛剛從 coffeescript 遷移到另一個技術棧，重構量特別大，每個 pr 都很龐大。所以我這周只提了一個 pr。」這時候你就知道了，他們沒有問題，只是背景不同而已。

但與此同時，當你要跟董事會彙報，或者向 ceo 彙報團隊的進展時，你總得給他們一些指標，來幫助他們理解團隊的演進狀態，在面對 ai 的衝擊時：到底團隊在變好，還是在原地踏步？

ben matthews： 我覺得現在很多公司也在試圖用這些指標來彌補其他方面的短板。就像你說的，ai 可以加速工程師的效率，但它解決不了所有問題。

我看到有些領導常犯的一個錯誤就是，把 ai 當成救命稻草，比如 產品沒找到真正的市場匹配點（product-market fit），或者沒能真正理解客戶的真實需求。於是他們就說，「那我們用 ai 吧，這樣我們可以更快地構建產品。」但方向錯了，再快也沒用，甚至可能把問題放大。

所以 ai 無法解決那些本質上的領導力問題或產品定位問題。很多人現在對 ai 的期望是：「我們給工程師配上 ai，就能解決一切問題。」但其實，ai 是一個極其有價值的工具，是工具箱中的一個新工具，但你仍然需要為工程師提供正確的方向、正確的思路，以及足夠的支持，才能讓他們構建出真正有價值、真正契合市場需求的產品。

loic houssier： 是的，而且你需要合適的人員和資歷來把控這些事。你需要足夠資深的人來高效使用 ai。比如說，當你有數百萬用戶，或者每秒有海量交易時，你肯定不希望某個 ai 生成的「魔法 pr」只是被一個初級工程師草草審核就直接上線了——絕對不行，完全不行。我們現在還遠遠沒到那個階段。

當然，將來可能可以做到，但目前還不行。儘管如此，ai 已經在深刻改變我們的工作方式了。

那麼，我們要如何適應它？作為工程師，你有 10 年經驗，但這些工具不是你一出生就會用的。我之前提到，我最早接觸的是 amstrad cpc 6128，從那會兒到我研究生畢業，技術的變化雖然持續，但更像是線性推進，並不是範式的斷崖式變化。

是的，那些早期的教程讓你更深入地理解底層，比如底層處理器原理等等，但它們沒有改變我整個思考問題的方式。而現在我們所處的是一個真正的「範式轉變時代」。

你怎麼適應這種變化？你得想清楚對自己的職業意味著什麼，而這真的很難。

我上周還和一個朋友聊到這個，我們談到了剛從大學畢業的那批工程師。他們基本上從大一進校到大二，就已經置身於完全不同的世界了，因為這個範式轉換在他們學習過程中就發生了。

他們經歷了 ai 從「很酷」變成「可以用了」的整個過程。他們見證了 chatgpt 能夠迅速回答各種問題，然後意識到：「天啊，我們現在可以用 llms 來構建產品了。」接著又是：「天啊，現在還有智能體（agents）。」再之後是：「天啊，現在又有 mcp 了。」

每一次都是一次範式轉變。

所以他們的大腦可塑性（brain plasticity）是把這種劇變當作日常的。而我們這一代人，是在一種「你總有時間慢慢學習」的假設下成長的。因為那個時代的技術變革並沒有現在這麼劇烈。比如我們從純 javascript 過渡到 jquery，再到 angular，再到 react，說實話如果你回頭看看，那其實算不上什麼「巨變」。而且這個過程花了將近 20 年才走到今天。

ben matthews： 你說得沒錯，特別是從 javascript 到 jquery，當時大家都驚嘆：「哇，現在我可以不用寫那麼多 js 就能實現這些交互了！」那確實是個進步。

loic houssier： 它只是一個抽象層的提升。對我來說，雖然它更簡單，但不是範式轉變。你怎麼看？

ben matthews： 我覺得，（jquery 的）真正範式轉變點在於，它讓更多新人更容易進入網頁交互的世界。雖然功能層面沒變，比如 dom 操作機制還是一樣，但以前你必須寫複雜的 javascript，還得兼容 ie6，各方都麻煩。所以我認為，就我們在 web 上做的事情而言，它沒有改變，但從多少人可以在 web 開發商更快地完成任務，我確實認為這裡發生了很大的轉變。

loic houssier： 沒錯，我的意思其實是，從個人能力成長的角度看，像 jquery 這種技術出現後，你不需要馬上去學也沒事。現在不一樣了，如果你對 ai 工具的演進保持觀望態度，哪怕只是等一個季度不學習，就可能被甩在後面。

這就是「腦部可塑性」越來越重要的原因。我們那時可以花一年去慢慢學 jquery，沒關係。但現在你等得太久，再找工作可能就困難了。

我相信 stack 也在思考如何將「ai 熟練度」引入面試流程。因為現在我們越來越傾向於尋找那些能熟練使用 ai 工具、提高效率的人。這將成為面試的一部分。

ben matthews：這些問題非常有價值。那麼，superhuman 接下來有什麼計劃？你們最期待什麼？

loic houssier： 我們接下來想解決的核心問題是：如何維持產品的「感知質量」。我們一直非常注重質量，我們的用戶對產品的感覺是：一切都很棒，一切都很快，一切都運轉良好。這種愉悅和信任的感受，就是我們在用戶與產品之間營造的「品質感」，就像你使用蘋果設備的那種感覺——「它就是好用」。

但隨著 ai 和大語言模型的引入，我們從一個完全可控、可 qa 的質量標準，進入了一個用戶輸入會顯著影響輸出質量的世界。你輸入的提示詞如果很爛，那結果也只會更爛。垃圾輸入就會導致垃圾輸出。

我們允許用戶在 superhuman 中搜索郵件、提問並獲得上下文相關的回答，但如果他們提問方式很糟糕，那結果也會很差。於是我們要思考：如何保證用戶不會因為「輸入垃圾」而怪我們「輸出垃圾」？怎麼提升輸入質量，確保最終體驗不受影響？這是一項我非常投入的工作，更偏向 ux 設計，而不是傳統 ai kpi 如精準率、召回率等。

這個問題其實是交互設計問題：我們如何引導用戶提問更聰明、表達更清晰？

另一個關注點是：生產力市場正在劇烈變動。我們不僅僅是一個郵箱工具，更是一個生產力工具。我們為用戶平均每周節省 3 個小時，這才是我們核心價值所在。市場上現在到處是與生產力相關的 ai 工具，大家都在嘗試通過 llm 實現更多交互、更快完成任務。

我們的目標很明確：我們已經「解決了郵件」，那接下來，我們還可以「解決什麼」？superhuman 的未來，是去理解 ai 帶來的生產力進化、理解用戶感知質量的問題，並用最優雅的方式去解決它們。

參考鏈接：

https://www.youtube.com/watch?v=sysrhmwa0as