有請 Canva AI 產品負責人,Danny Wu 上台。

Canva AI 2.0 是什麼

大家好。非常感謝各位來參加 Code with Claude 的這個場次。我是 Danny,Canva 的 AI 產品負責人。我很興奮能跟大家分享我們用 Claude 打造 Canva AI 2.0 的幾個最重要的學習,希望對在座的 builder 都有幫助。

那麼,從議程開始。我會先快速介紹 Canva AI 2.0 是什麼,然後分享幾個最重要的教訓,包括我們如何重新定義成功的標準、我們在打造 agent harness 上學到的事、我們如何在服務數千萬使用者的規模下管理成本,以及一點關於回應並真正傾聽社群回饋的部分。

先簡單介紹什麼是 Canva AI。如果你不知道 Canva,它是一個平面設計與視覺溝通平台,讓你創作各種東西:文件、簡報、海報、電子郵件——幾乎任何你想得到的,都能用 Canva 做。而 Canva AI 的設計初衷,就是幫助我們的使用者與社群完成所有設計與生產力工作流程。這裡有段小影片:你可以連接你所有的資料來源,像是 Slack、Google Drive、行事曆等等,真正用 Canva AI 在 Canva 裡把工作做完——取得所有對的 context,然後用它建立文件、建立一份可以原生編輯、非常容易協作的設計,把工作完成。

我也想談談 Claude。在 Canva,我們從 Sonnet 3 模型的年代就開始用 Claude。就像今天大家在 Fable 上看到的,Claude 模型的前緣智慧持續推進。

我們看到它越來越能解決我們一些最難的挑戰——那在幾個月前還幾乎難以想像。當然,我們在品質、成本、延遲這三位一體上,對各式各樣的任務與工作負載跑相當完整的評測,而 Claude 始終穩定交付。

我們特別喜歡 Claude 模型的一點是視覺超能力。這不只限於前端設計。我們發現它能很好地泛化到各種東西:從製作精緻的簡報——包括符合品牌的 deck——到各種視覺產出物,從可列印物到文件等等。

另一個特別棒的是彈性的部署選項。對我們來說,Claude 在 Bedrock、Vertex 和 Microsoft Foundry 上可用,不只是另一個 API endpoint——它讓我們能在我們所有的 AWS 帳號裡,用我們的 IAM 角色、權限與成本追蹤來建置與使用 Claude。整合起來真的非常容易。

接著我介紹一下 Canva AI 2.0,它其實是一個相當複雜的 agentic 系統。

表面上看起來只是一個簡單的文字框,但它實際上編排了多種不同的 agent 的組合,像是我們的設計 agent,或是驅動 Canva Code 的 code agent——就像今天稍早你們看到的。它還有數百種工具應付各種任務,從圖片生成、背景移除到 magic layers。本質上,我們持續在做的,是把一般使用者能在 Canva 平台上做的所有功能、所有事情,整合並加入成我們的 AI 與 agent 能呼叫的工具。當然還有平台層,那裡有所有的 connector、所有的 MCP、記憶、排程等等。表面看也許有點簡單,但要讓它運作起來、為使用者創造一個連貫的體驗,就複雜一些了——尤其是在 AI 模型的能力與使用者任務都不斷升級的情況下。

我也想說幾個挑戰。在 Canva,我們的 AI 團隊是分散式的。我們希望整個組織都在做 AI。例如,我們希望影片小組擁有影片 AI 的所有權;我們希望印刷小組真正擁有我們所有印刷功能的所有權。所以我們必須找到能在大約五千五百人的組織裡規模化的模式。而 Canva 要處理的工作範圍非常廣。在規模上,尤其是 Canva AI 2.0 推出之後,一切都持續成長。所以規模化絕對是個有趣的挑戰。

教訓一:重新定義成功——賦能人,而不是一次到位的輸出

第一個教訓,是關於定義問題,並真正打造能與使用者產生連結的方案。對我們來說,是學到「賦能使用者去設計」不必然只關乎一次到位的輸出或它有多好。因為——雖然這顯然是個夢想,我們很想從一開始就把一個非常寬泛的 prompt 變成驚人的輸出——有很多要考量的事。

例如,設計本質上是主觀的。不同使用者有不同品味、不同偏好。還有不同的團隊與公司——他們有特定的品牌系統與品牌套件需要被整合。而且不必然存在一個對任務而言完美的「正確設計」。有評分準則、有評測、有使用者偏好,但設計本質上是主觀的。

而且我們發現——透過內部測試以及真正與使用者、Canva AI 的早期測試者交流——人的手感真的很重要。

例如,平均一份 Canva 設計在發布前會被編輯大約 110 次。我們在 Canva AI 2.0 想打造的,不只是一個在背景執行、能完成設計、然後給你一個小小「完成」開關的 agent——而是真正能與你一起工作、你能掌舵、你能與之並肩同行的超級設計協作者。

最後,延遲與回應速度是最重要的目標之一。

因為 Canva AI 是互動式的,我們的使用者期望能快速、輕鬆地完成設計需求,我們實際發現非常強的相關性:使用者滿意度、功能留存率,一切都與延遲高度相關。有時甚至比我們的品質指標和評分準則更重要。所以,弄清楚怎麼讓這個 agentic 系統不只很好、還要很快,非常重要。

我給大家看一個我們把這套想法實際應用在設計 agent 上的例子。

在,姑且說,起點,我們有模板,那顯然不是個人化、不是客製的,但是一個非常非常好的起跑點。而中段是我們找到的甜蜜點——至少目前如此——在「投入多少力氣」與「我們想在交回初版設計給使用者之前達到多少設計品質」之間。如果我們讓 LLM、讓模型工作得更久,花更多 token、更多力氣,但相應也更多時間,那我們能得到更精緻一點的產出,就像投影片上看到的。但那不必然是我們大多數使用者偏好的。當然,如果你真的開口要求某個很驚人的東西,我們會幫你做出來。

所以,至少在我們看來,模型存在一條效率前緣、一個甜蜜點。重點不必然是品質最大化,也不必然是追求最低成本,而是找到對的 effort level、為你的 agentic harness 找到對的 prompt,抵達讓我們大多數使用者最開心的那個位置。

教訓二:harness 是用過即丟的;評測不是

第二個教訓,是關於我們的 agent harness,以及我們如何越來越把它視為用過即丟的。我想,隨著 agent 工程的威力,加上像 Fable 這樣的新模型,還有 Opus 與更強的模型——這只是我自己的話,但我認為:今天聰明的 harness,就是明天的死程式碼。

harness、你設定的邊界,會隨著新模型不斷改變——你會發現新的最佳做法。我們在自己的旅程裡看了很多。Canva AI 以某種形式存在了三年,而我們基本上把整個 Canva AI harness 重寫了至少三次,隨著新模型調整。

我們最初做的是內部 chain-of-thought 提示,後來轉向利用模型的原生能力。我們開始運用越來越多工具——早期版本的 Canva AI 可能只有三四個工具,現在我們可以有數百個。我的重點是:你的 agent harness 是該持續迭代、持續演進的東西。持續打造、持續測試是可以的。特別是模型出現大躍升時——例如 Claude 5 家族——那是重新評估你真正需要什麼的完美起點:

給模型更多權力,能否帶來更低延遲、更高品質的更好產出。

這裡真正重要、不是用過即丟、而是非常有價值的,是評測。

具體來說,我們最近開始轉向端到端評測。

我的理解方式是:如果你是軟體工程師,你會寫單元測試,那可以對應傳統評測——衡量某個特定任務或功能的表現。但當你打造的是一個複雜的 agentic 系統,有使用者記憶、有外部 connector、有各種整合,那你真的要確保端到端的流程如你預期地運作——在你做 A/B 測試時、在你測試不同 system prompt 修改時,甚至測試不同模型、不同 effort level 等等。這些端到端評測,才是真正讓我們有信心推出新功能、或把東西全量上線(rollout 到 100%)的東西,也讓我們真正理解利用模型能力的最佳方式。這份清單我們持續在擴充,而它可以說是我們把 Canva AI 越做越好的護城河。

到達那裡並不簡單,絕對是一個迭代的過程。

你可以從小開始——我們最初的版本大概只有 10 個、一打測試案例,後來加到好幾百個,然後我們開始只跑其中一部分評測,純粹為了時間能跑得完。我們發現超級有用的,是擁有把功能與實驗盡早推給使用者、推給早期採用者(不只內部團隊)的介面與機制。一旦推給部分使用者——每一次我們都發現,使用者的期望跟我們想的不一樣,通常差距不大,但總有些不同。而那些回饋、使用者實際使用你 agentic 產品的方式——不是你行銷影片或新聞稿裡的方式——那才是獨特的。那才是你要加進評測裡的東西,才能真正交付出色的體驗。

我也想特別提一下成功訊號。我認為做實驗時,非常刻意地衡量對的指標真的很重要。我們發現像「使用者在 Canva AI 上花了更多輪對話」這種指標其實沒什麼幫助。因為當你有一個更強大的 AI agent,使用者可能用更少輪就完成任務,或更快拿到設計、在你的平台上花更少時間就把工作做完——而那是好事。

所以我的建議是:不要執著於互動指標,或時間、token 消耗這類東西,而是:它有沒有幫使用者把事情做成?他們會不會回到你的系統?你的留存率如何?這些加總起來,才會幫你打造真正有表現的 agent。

教訓三:在規模下管理成本——token 預算、模型路由、成本意識文化

接著進入一個更有料、希望也更刺激的主題:在規模下管理成本。Canva AI 有數千萬使用者在用,而且每個月都在成長,還在持續加速。而 Canva 絕大多數使用者是免費的。我們相信讓所有人都用得到 AI 非常重要——學生、目前可能負擔不起升級 Canva 的人。所以我們盡可能把它做得有效率。

我們找到三個特別有用的重點。第一是設定 token 預算上限。公開平台上的 task budget 功能效果好得出奇,模型的伸縮能力也確實讓我們驚訝。

聰明的模型路由是另一個重要領域。話題熱度通常都繞著最強、最新的模型,但老實說,整個 Claude 模型家族裡有一些非常出色的選手。優化成本最大的方法之一,就是確保你永遠用對的模型做對的工作負載與任務。最後,我會談談在組織裡建立成本意識的文化——尤其當你在一家有很多很多開發者、很多很多 builder 都在貢獻與打造你的 AI 的大公司。

第一個是 token 預算上限。為什麼要有這個東西?如果你習慣用 Claude Code,你大概會想:唉,如果產品在任務完成前打斷並擋下使用者,挺煩的。

但我們的產品的使用者橫跨各種 AI 技能與提示功力,我們常常看到不太有效的 prompt。例如看這個 prompt:「把這份 deck 的每一頁都繼續做下去」——可能是 40 頁、有時甚至 100 頁的 deck——「直到它真的非常好。」前緣模型在無限時間、無限預算下會做得很出色。但如果你能給使用者的用量或預算不是無限的、或在一個 session 裡、或當成本攸關時,那麼設下約束、實際指示模型、給它一個完成任務的預算,真的有幫助。還有,無論你怎麼測、怎麼優化——尤其在接外部系統或外部 connector 時——你遲早會看到我們所謂的 doom loop:agent 一次又一次重試同一件事。如果它把使用者的整個額度燒光,那可不妙。所以 token 預算的目標,是幫使用者從他們擁有的 AI 額度裡榨出最多價值,最終獲得更開心的體驗。

我鼓勵大家最先嘗試與探索的(如果還沒的話),是 token 預算——Anthropic 平台最近為最新模型推出的。

透過 token 預算,你基本上可以指示 Claude:嘿,你有 32,000 token 的預算、你有 50k token 的預算。然後把決策權留給模型,讓它自己編列預算、管理任務的執行。這裡有些例子,用的是我們其中一個設計生成 harness。同一個模型、同樣的 prompt,例子中唯一的變因是 token 預算。你可以看到 Opus 的伸縮能力驚人——在橫跨大約半個數量級的 token 預算下,交付的簡報都保持住了水準。至於 token 預算該設多少——那絕對是非常 harness 相關的事。但前緣模型,Opus 甚至 Fable,在 effort level 與 token 預算兩個維度上都伸縮得非常好。這些都是你能用來交付更優化 AI 體驗的控制桿。真的,它們非常強大。

有一點我要提醒:task budget 只計算 token。如果你有一個 agentic 系統,你大概還有工具呼叫的成本。例如圖片生成要花一點錢,web search 之類的也可能要錢。我們實際做了、而且發現非常有效的,是仿照 task budgeting 的實作模式,自己為所有工具追蹤並計算成本。

做法很類似:任務開始時,我們告訴模型(例如 Opus)這個 session 的預算是多少;過程中每隔一段時間提醒它:嘿,你已經用到這裡了;最後,當它觸及 token 預算,我們請模型收尾、完成工作。我要說明:這些做法一般相當穩定,但不是 100%。它們是建議性的,不是硬上限。所以如果硬預算對你很重要,你也應該有系統層級的強制機制。

最終,你的應用、你的使用情境的甜蜜點在哪裡,得由你根據想支援的工作負載與成本結構自己側寫。

這其實——具體數字我們遮掉了,但這是 Canva AI 2.0 的真實資料。我們分析了使用者 session,努力設一個既允許非常合理、相當足量的工作,又能超有效率地使用最新最強前緣模型的上限。

另外,有很多事可以讓 token 預算對使用者更友善,而且光靠 system prompt 和指示就能做到。

第一,我們發現特別在互動式 agent 應用裡很有效的模式,是溝通有幫助的下一步:告訴使用者 agent 實際完成了什麼;如果使用者要求的動作有哪些還沒做——例如這個案例,它加了 10 張投影片,但因為 token 預算還沒收尾——就向使用者要更多 context 或方向,同時也提供「直接繼續任務」的選項。

第二,在 token 預算與上限之外,是用 subagent 做聰明的模型路由。為什麼是 subagent?

我用 Canva Code 的例子帶大家走一遍。我們的最小可行產品、Canva Code 第一版,就是單純用 Sonnet——非常簡單直接。但對於簡單的 CRUD 查詢,像是改幾個字或換一張圖,你真的不需要它——Haiku 就能做得非常好。於是我們實驗了模型路由:對一個使用者 prompt,依複雜度送給 Opus、Sonnet 或 Haiku。一開始看起來可行,但其實有缺點:主要是每次切換模型,就得重寫一次快取。而因為我們在編輯程式碼,context window 可能已被污染,快取不再一致。很多情況下,我們付錢的那些快取寫入,並沒有抵過好處。

所以我們改採 subagent 方案,這最終是 Canva Code 最有效的做法。

我們有一個主 agent,握有所謂的權威 context,扮演一點編排者的角色;依任務不同,它可以選擇把工作委派給一個 Opus subagent 或一個 Haiku subagent 執行,完成後再送回主 Sonnet agent 的主線。這非常有效,因為快取命中率維持得很高——80 幾、90 幾——而不是不斷地快取失效與重寫。我們最終成本幾乎砍半,使用者滿意度還順帶提升。

成本的最後一件事,是擁有出色的報表與監控系統。

這不只對你有用——擁有好的儀表板,對所有呼叫、每個 session、agent session 裡牽涉的一切都有 tracing,是讓 Claude 也能幫你側寫、幫你尋找/測試/實驗優化方案的好方法。我們也發現,把成本顯示在內部員工的 UX 裡非常有幫助,尤其有助於發現邊角案例:某些本該簡單或非常便宜的請求,因為邊角案例或 bug 消耗了大量 token 或成本。我非常鼓勵大家不要害羞,把每一個 agent 動作、每一次互動花了多少錢,展示給你的內部團隊,甚至視你的客群展示給使用者。知道這件事、讓每個動作都附帶這個資訊,真的太重要了。

教訓四:把社群回饋導進評測

最後一個我簡短講,是使用者回饋。我分享我們最近一次發布的故事——image upscaler(圖片放大)。

我們幾個月前推出了自家內部的圖片放大模型,經過詳盡、紮實的 A/B 測試與評測。上線後,我們收到了一些褒貶不一的回饋。這裡是一些社群使用者對 image upscaler 的回饋。

而這是在我們信心十足的情況下發生的——放大功能的使用量翻了好幾倍,我們的評測案例普遍看起來不錯。但我們也有少數、卻非常大聲的使用者回饋。

那我們該聽什麼?我們發現有用的,是真正善用回饋與支援管道,建立能把任何使用者回饋直接捕捉並呈現給你的系統,用它來分類、路由給相關團隊、標上相關功能。

我們從社群拿到了數百個圖片放大模型表現不佳的例子。我們把這些加進了評測。我們學到很多:對某些特定輸入、某些特定藝術風格,它的表現不夠完美;還有一些其他邊角案例。

我們最終做的,基本上是把社群提交的所有例子都加進評測,訓練了我們的第二版,然後達到 100%。最後,與使用者把迴圈閉合。如果在座有任何使用者現在對 image upscaler 還有回饋,請務必傳給我們,我們永遠想把它做得更好。真的,把你最大聲的使用者回饋、甚至抱怨,轉化為學習,是非常有價值、非常強大的。即使只是少數使用者、只是百分之幾——就算你的評測看起來不錯、指標看起來不錯,也不代表你每次都命中靶心。

重點回顧

最後很快地——好讓大家去吃午餐——幾個關鍵教訓。核心是賦能人,確保你追求的是真正最能幫到使用者的東西。harness 越來越用過即丟。別依戀,別愛上它們。評測才是真正重要的。成本控制,像 task budget——還沒試過的話,強烈推薦,威力驚人。effort level、用對的模型做對的任務,以及 subagent。最後,傾聽你的社群和所有回饋。謝謝大家,arigatou gozaimasu。