AI Engineer Europe 2026 · 演講 · 2026-04-21 · 29 分
AI 時代的品味與品質
Taste & Craft: A Conversation with Tuomas Artman, CTO Linear & Gergely Orosz, @pragmaticengineer · Tuomas Artman、Gergely Orosz,Linear / The Pragmatic Engineer
Linear 的 CTO 談 agent 讓出貨變得太容易之後,怎麼靠品質星期三與零 bug 政策守住品味,以及工程師為何得更懂產品。
概要
- 出貨太容易反而危險Tuomas 認為 agent 什麼都能立刻做,團隊可能來者不拒、把軟體塞到使用體驗混亂。Linear 仍然對很多客戶需求說不,先找出需求背後的真正問題再設計。
- 簡單的 bug 交給 agentTuomas 說 Linear 進來的 bug 有 10% 由單次 AI 自動產出 PR 並合併,預期未來幾年會往 100% 靠近。
- 品質星期三每位工程師每週要自己在產品裡找出一個品質問題並修掉,成員因此做別的功能時也會留意細節。Tuomas 說到目前已修了 2,500 或 3,000 個小問題。
- 零 bug 政策Tuomas 的算法是 bug 產生的速度大致固定,拖著不修只是晚點再修。Linear 停了約三週不做新功能把 bug 清到零,之後每個 bug 在七天內修掉,通常兩三個小時就好。
- AI 沒有品味Tuomas 認為 agent 沒有時間感,也看不出動畫好不好,拿設計工程師的動畫實驗當例子。
- 工程師都會變成產品工程師Linear 招人看重產品感,有為期一週的 work trial,也讓所有人接觸客戶的聲音。Tuomas 預期往後工程師得像迷你 PM。
原話
▶ 06:07“Over time, that will go up. I do foresee a future where it gets closer to 100% in the next few years.”
這個比例會隨時間上升,我確實預見未來幾年會越來越接近 100%
▶ 11:26“There will be no A-B test that you can do in order to figure out like whether you should invest in quality.”
不會有哪個 A/B 測試能告訴你該不該投資在品質上
▶ 16:57“Not every bug gets fixed if it's super hard or gnarly and it applies to one out of 100,000 users”
如果某個 bug 超難搞,又只影響十萬分之一的使用者,就不是每個都會修
▶ 20:03“No, they don't feel. They have no taste. They simply don't.”
不,它們沒有感受,沒有品味,就是沒有
▶ 26:36“I think everybody will become a product engineer in some sense”
我認為某種程度上,每個人都會變成產品工程師
延伸
- Tuomas 提到同事 Emil 發表的動畫實驗,對照了 agent 產出與人工調整後的版本,內容只有口頭描述,沒有數據。
- 對談中提到 Linear 的同步引擎與基礎設施規模挑戰,但這場沒有展開。
章節
點時碼直接跳到原片的那一段。
- 出貨太容易的風險當 agent 能立刻實作每個需求,Tuomas 擔心團隊來者不拒,做出使用者看不懂的軟體。
- Uber 的高速成長Tuomas 回想 Uber 對 Lyft 的贏者全拿,覺得現在人人都能大量出貨的 AI 環境很像,所以得靠品質拉開差距。
- Linear 不照單全收每個功能都先想過,客戶需求不直接做,而是找出背後的原因再設計,這花的是時間而不是工程。
- 自動修 bugbug 數量大致固定,現在 10% 由單次 AI 自動修好並合併,不需要工程師動手。
- 談 Claude CodeAnthropic 說 Claude Code 的功能都是 Claude 寫的,Tuomas 說看得出來:用起來幾秒內就能發現小 bug,並解讀成 Anthropic 要跟 OpenAI 競爭,跑得太快。
- Uber 怎麼衡量品質Uber 幾個核心指標以營收為主,品質很難量,所以事實上沒人量。
- 品質慢慢決定勝負以 Uber Pool 和 Lyft Pool 為例,價格功能相同時,使用者會慢慢轉向體驗更好的那個,而且 A/B 測試看不出來。
- Quality WednesdaysGergely 旁聽過,整個工程團隊約 25 人各報告一個品質修正,從一個像素到後端效率都有。
- 起源:35 個問題Linear 要求 hover 時立即高亮、移開時 150 毫秒淡出,Tuomas 厭倦一再提醒,就在 offsite 帶大家花一小時檢查一個選單,找出 35 個連自己都沒看到的小問題。
- 每週自己找問題規則是不能由別人遞問題給你,副作用是大家開發其他功能時就會留意,回歸問題變少。
- 零 bug 政策bug 一進來就用 agent 指派給負責的人,成為最高優先;停了三週清到零,之後都在七天內修完。
- AI 有沒有品味Tuomas 認為 agent 沒有感受、沒有時間感,也看不出動畫好不好,並引用同事的動畫對照實驗。
- 招募與一週試做特地找在意品質的人,每位新人要經過為期一週、有付費的 work trial,做一個從零開始的專案。
- 接觸客戶的聲音大客戶的 Slack 頻道對全公司開放,與客戶的會議都錄下來並標記重點,人人搜得到。
- 一年後的工程師Tuomas 預期若 AI 持續進步,工程師都會變得偏產品,要像迷你 PM 一樣直接與客戶談。
- 培養產品感的建議靠近客戶,或自己做東西給自己用再推出去,另外推薦讀 Apple 的 human interface guidelines。
名詞
- Tuomas Artman
- Linear 的 CTO,這場被訪談的人
- Gergely Orosz
- The Pragmatic Engineer,這場對談的提問者,曾與 Tuomas 在 Uber 共事
- Linear
- Tuomas 所在公司的專案管理工具,也是這場說明品質做法的對象
- Quality Wednesdays
- Linear 每週三的例行會議,每位工程師報告一個自己找到並修掉的品質問題
- zero-bug policy
- bug 一進來就指派並優先修復,不放進待辦清單
- product engineer
- 懂客戶要什麼、知道好功能與好體驗長什麼樣的工程師,Linear 招募的主要對象
- work trial
- Linear 招募流程裡為期一週、有付費的試做
- Claude Code
- Tuomas 舉例的 AI 開發工具,說用起來就能發現小 bug








