使用 Claude Code 和 Android CLI 進行代理式工程

大家好，我是 Android 開發人員關係團隊的 Ben。

我是產品經理 Steven。

今天我們要談談如何使用 Claude Code 和 Android CLI，以代理方式建構應用程式。

因此，我認為開發人員的角色正在轉變，而且變化速度極快。老實說，這場演講的內容可能已經過時，尤其是線上觀看的觀眾。

因此，我們在撰寫內容和呈現資訊時，採取了前瞻性的立場，但他們今天執行的示範是以現實為基礎，因此現在應該是可靠的。

另外，雖然我們在這次演講中使用 Claude Code，但這些資訊與代理無關。

這比較像是一種思維模式，因此無論您偏好使用什麼工具建構應用程式，都應該套用這種模式。

因此，我們希望您開始思考，在管理自主代理團隊的世界中，如何協助他們取得成功。

如果 AI 無法實作某項功能或類似工作，我們不應直接放棄，認為「AI 還做不到這點」，而是要退一步思考缺少了哪些資訊，並像處理錯誤一樣處理這個問題。

如果您看過 Claude Code、Codex、Antigravity 等代理駕馭系統開發團隊的任何文章，就會發現他們的團隊實際上就是這樣開發這些代理駕馭系統的。如果我們把這些工具當作未來的縮影，這可能就是我們所有人的發展方向。

因此，現在可能是 Android 開發人員最興奮的時刻，但如果您和我一樣，可能會發現很難確切知道該專注於什麼。

開發人員需要能隨著智慧技術擴充的工具和工作流程，這樣一來，當新模型拓展技術疆界時，我們就不必重複做白工。

我們希望每次模型改良都能讓服務專員的工作流程更智慧，最終為使用者帶來更好的結果。

今天會討論四個主題。

首先，我們會說明為什麼必須為代理設定合適的環境，才能發揮最大效益。

接著，我們會概略介紹情境，以及管理情境的最佳做法。

接著，我們會介紹一些適合 Android 開發人員在代理中使用的最佳工具，最後則會說明為何要在 Agentic Workflows 中加入迴圈。

好，我們開始吧。

所以，環境。

但這究竟代表什麼？

就像我剛才說的，我們想打造一個能讓代理順利運作的環境，而且不需要使用者一直坐在那裡，不斷重新提示或修正代理。因為這樣一來，就能同時執行多個代理，讓這些代理團隊幫你完成工作，真正提高工作效率。

但這不只是存取程式碼而已。

他們需要存取準確的文件，包括專案規格和專案工作規則。

這點顯而易見。

此外，有些人會將代理連結至團隊聊天室，不只是為了啟動代理，也是為了提供決策背景資訊，說明為何要開發某項功能。身為開發人員，您在解決問題時會潛意識地使用這類資訊，因此這對代理也很有幫助。

以及先前的決策記錄和提取要求。

他們應該能看到您在提取要求上收到的留言、他們收到的通知類型等，然後您會發現他們可以處理並修正這個問題。

此外，如果無法存取裝置或模擬器，您就無法編寫 Android 程式碼，因此也不應期望代理能做到這一點。

我知道它們看起來很厲害，好像什麼都能做，但模擬器真的很有幫助。

剖析器也是如此。

如果想讓他們處理效能問題，他們應該要能進行分析，這需要存取實際裝置。

理想情況下，代理也應能與應用程式使用的任何後端服務通訊。

這時 Android CLI 就能派上用場。

如果您沒聽過，這也是「開發人員工具新功能」演講的主題，Android CLI 是我們的新 CLI，可與各種 Android 工具互動。

它本身不是 AI 產品，只是 CLI，也就是指令列介面。

因此，您可以存取 Android SDK Manager、啟動模擬器等。

還能連結 Crashlytics 等工具和後端。

無論使用哪種代理，這項功能都能在殼層空間中運作。

所以，

您可以透過這個連結安裝，但我想直接示範會更簡單。

現在我們來做個小測驗

因此，我們不只是說明為何要協助代理奠定成功基礎，更想將這項原則實際應用在我們建構的正式版應用程式 Sideline。

Sideline 是一款 Android 應用程式，可為網球選手提供球、球員和球場位置的即時回饋。

這款應用程式會透過影片重播提供離線指導意見，並提供最快速度、移動距離和最長來回擊球次數等運動資料。

這一切都是透過直接在 Android 裝置上執行的自訂 TF Lite 模型提供。

首先，我們顯然無法解決不知道存在的問題。

因此，我們使用 Android CLI 將 Firebase Crashlytics 新增至開發人員環境，找出一些我們甚至不知道發生的問題。

第一個是 Pixel 11 Pro Fold 裝置發生應用程式無回應 (ANR) 錯誤，但無法在模擬器中重現。

幸好，Android CLI 支援 Android 裝置串流。

我們要求代理修正問題後，代理會連線至發生 ANR 的裝置，這對我來說特別實用，因為當時我沒有 Pixel 11 Pro Fold，無法驗證修正結果。

因此，只要讓代理存取裝置，驗證修正結果，就能擴大可能的能力。

為了節省時間，我已事先執行所有實驗，並在這裡總結。

簡單來說，我們遇到的問題是與 Android 17 相關的親和性呼叫。

這項修正只有兩行，看起來沒問題。

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

因此，我建立了提取要求，合併後更新，並將新版本提交至 Play。

因此，如果我們沒有設定好程式碼環境，讓它具備成功所需的條件，就無法找出實際問題，也無法驗證修正。

因此，在 1.0 版本中，您可以看到問題已解決。

不過，新的問題也隨之而來，我們稍後會再討論。

現在我們來做個小測驗

接下來是背景資訊。

大約 1 年半到 2 年前，時間不算太長，但在 AI 領域，這已經是一段很長的時間了。當時，大家都在競相擴大脈絡窗口，理論上，我們能提供給模型的資訊越多，得到的結果就越好。我們甚至嘗試在提示中加入整個 developer.android.com，但效果不佳。

不過，即使脈絡窗口大致上已趨於穩定，模型能力仍在提升。

這就是 Android Bench 1.0。

Android Bench 是我們用來評估 AI 編寫 Android 程式碼能力的基準。

其中的工作符合實際情況。

這就是您努力的方向。我們可以看到脈絡窗口在 100 萬個詞元左右達到高原期，但模型能力持續提升。

不過，脈絡長度仍有固定預算，因此應保留給重要資訊。

如果內容與您正在處理的問題無關，請不要加入。

許多代理工具實際上並未向您提供完整的 100 萬個詞元脈絡窗口，因為他們認為這沒有意義。

這樣做只會讓結果更糟。

其實有一個最佳平衡點，雖然會因模型而異，但如果能將對話控制在 15 萬個詞元左右，就能充分發揮模型效能，避免脈絡腐化。

但背景資訊不只是你輸入的內容。

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

其實背後有許多您看不到的細節。

由多個部分組成。

首先是系統指令。

系統指令是由代理提供。

這就像是提示，告訴代理如何運作，以及應該採取什麼行為。

此外，工作區資訊 (例如目前使用的目錄、擁有的 SDK、任何已安裝的技能，我們稍後會說明) 和 MCP 工具，以及代理提供的任何工具，也都會納入考量。

模型必須知道可以呼叫這些函式，因此會占用脈絡。

但最重要的是，每次提示和傳送新訊息時，系統都會將完整的訊息和工具呼叫記錄傳送給代理。

這會造成很大的影響，尤其是使用 Gradle 時。

我想大家都知道，Gradle 記錄非常長，而且非常冗長。

其中大部分都不是必要資訊。

因此，請務必留意這點。

您可以在安靜模式下執行 Gradle。

./gradlew assembleDebug --quiet

或由較大的代理駕馭系統為您截斷。

因此，Claude Code 和 Android Studio 不會傳送完整的 Gradle 記錄。

但如果使用精簡型代理，由於其核心理念是將所有內容傳送給模型，讓模型自行判斷，因此 mini-SWE-agent 會傳送完整的 Gradle 記錄，這可能會導致成本迅速飆升。

但要如何將數量控制在 15 萬個以下？

關鍵在於使用工作流程。

工作流程有很多種。

我最喜歡的是 Matt Pocock 的課程，他有一系列技能可協助你管理這些工作階段。

因此，首先要建立名為「grill-me」的技能。

在開始整個專案或專案中的新功能時，執行這項技能，代理就會向您提出一系列問題。

因此，你可能會說「grill-me.

我想在應用程式中建構新的鬧鐘管理工具。」

接著，Gemini 會開始詢問你一些問題，例如應該用什麼語言實作、程式碼屬於哪裡。

這樣一來，問題就不會再模糊不清，你也不必再費心思考，只要將問題寫在紙上即可。

接著，我們執行下一個技能，也就是撰寫大型規格文件。

另一項技能則會將這些問題細分，並提交到你偏好的問題管理工具。

接著，每個問題都應該大致符合 15 萬個詞元的限制。

接著，您可以在終端機或 IDE 中挑選一個問題，視您的偏好而定，然後建構、驗證迴圈，最後清除內容，不再保留對話記錄，並保持在視窗內。

現在我們來做個小測驗

接下來，我們來聊聊 AGENTS.md。

AGENTS.md：您可以為代理提供額外資訊，適用於代理在這項專案或整個工作區 (視您選擇而定) 處理的任何問題。

不過，由於系統會將這項資訊提供給每則提示，因此請務必只提供理想情況下始終適用的資訊。

因此，架構和模組規則等做法會比較有效。

這些是代理不可能知道的事情，尤其是當您開發封閉原始碼應用程式時。

但一開始就瞭解這項功能屬於哪個部分，可以省去推論的時間，因此非常重要。

因此，您可以將 UI 元件等內容放入設計系統模組，或將常見的程式碼審查錯誤，或只是您經常需要輸入的常見內容，放入設計系統模組。

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

So, you know, in this project, we prefer to use kotlinx.datetime, things like that.

我真的很想提供一套放諸四海皆準的最佳做法，但現實是，每次推出新模型，做法就會改變。

不同模型在處理額外背景資訊時，行為會有所不同。

舉例來說，在 Opus 4.6 時代，很常看到大寫字母寫著「絕對不要這樣做」。

Opus 5 推出後，Anthropic 發表聲明表示：「實際上，大寫字母的效果不再那麼好。

請一律使用小寫字母。」

這就是我的意思：你必須隨時掌握最新資訊。

不過，有些原則仍普遍適用，例如保持簡短。

因此，請將程式碼控制在 250 行以內。

接下來這個做法有點爭議，因為我知道很多人喜歡這樣做，但今年 2 月發表的一項研究顯示，如果讓代理修改自己的 AGENTS.md，效能會降低約 2% 到 3%，這其實沒什麼大不了。

但重要的是，成本增加了 20%。

因此，我們損失了一點效能，成本也大幅增加，這都是因為讓代理自行編寫 AGENTS.md。

我發現一種解決方法，就是讓代理在每次提取要求結束時撰寫回顧，然後團隊成員在回顧時一起閱讀，並決定要進行哪些修改。如果大型團隊與代理合作，這個檔案就會成為重要的團隊基礎架構。

現在，我們快速看一下 Sideline 應用程式的 AGENTS.md。

這裡有兩點需要特別說明。

首先，明確定義架構可節省權杖和脈絡長度。

基本上，這可讓代理避免不斷查看更多程式碼集，並做出越來越多推論。

為模型提供明確的指引。

第二點我想特別強調的是封閉原始碼應用程式。

顯然，如果您的程式碼集是封閉原始碼，任何代理都無法使用 LLM 訓練。

因此，在這些情況下，花費額外時間和精力，持續清理、審查、修正及改善AGENTS.md，就顯得特別重要，因為這對您長期而言是有益的。

如果不能把所有內容都放在 AGENTS.md，該如何變更代理或模型的行為？

首先是掛鉤，掛鉤非常適合用於使用者在 AGENTS.md 中執行的操作，例如在寫完程式碼後一律執行 Linter。

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

這可以當做開場白。

代理程式會公開所有可訂閱的事件，這就是掛鉤。幾乎所有想得到的事件都有對應的掛鉤，但主要的是啟動工作階段、停止工作階段、讀取和寫入檔案。

因此，您不必在 AGENTS.md 底部寫入「一律執行 Linter」或「一律在說完成前執行測試套件」，只要設定停止掛鉤，就能執行確定性指令碼，有助於控制 AI 的輕微隨機性。

另一個例子是，如果你有不希望代理讀取或寫入的檔案，例如機密檔案，不希望傳送到伺服器，或不希望代理寫入 AGENTS.md，就可以使用掛鉤。

因此，您可以使用讀取或寫入掛鉤，取得系統嘗試編輯的檔案，然後傳回「不，您無法執行這項操作」。

只是用來增加確定性。

下一個是技能。

現在，你還能運用技能，將 AGENTS.md 轉換為 Hook。

這完全是另一回事。

但技能只會在相關時新增背景資訊。

因此，AGENTS.md 適用於始終相關的事物。

技能適用於特定情況，主要是說明文件。

技能由三個部分組成：名稱、說明 (這是重要部分，說明長度上限為 1,024 個半形字元) 和主體。

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

內文可能非常龐大，甚至包含其他指令碼，這相當常見。

技能的用途相當廣泛。

一起來看看這個範例。

這是 Android CLI 的說明。

你不必唸完所有內容。

只要知道這是一段簡短說明，描述 Android CLI 的相關資訊即可。

接著是內文。

這個檔案很大，所以我們不會想一直載入，對吧？

我們只想在嘗試使用 Android CLI 時載入這個項目，而這正是技能的作用。

不過，請務必慎選要安裝的技能。

我們不希望只是盲目安裝網路上看到的那些存放區，其中包含數百種代理工程技能。

第一，這會造成巨大的安全風險。

你不知道這些技能包含什麼內容，可能會指示代理執行任何操作。

我們確實有一套 Android 技能，我保證我們審查過，他們不會這麼說。

第二，100 個說明乘以 1,000 個字元，等於您在開始編寫程式碼之前，就已經新增了 100,000 個字元。

所以你已經快要達到這個目標了。

因此，我們建議您安裝 Android CLI 基本技能，Android CLI 就能搜尋可用的技能，並安裝適合您應用程式的技能。

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

或者，如果您確實有查看，最好知道有哪些技能可用，您可以手動新增適合您專案的技能，例如 Compose 技能、無邊框技能，這些都是相當通用的技能。

當然，稽核技能也需要技巧。

Claude Code 中有 /skill-doctor，會檢查並告訴你哪些技能從未啟用，這樣你就不會浪費一千個字元的說明。

如果不是使用 Claude Code，幾乎所有代理駕馭系統都有某種統計資料或稽核畫面，可執行相同操作。

再次提醒，Android CLI 的連結如下。

但它有技能清單指令，假設您的專案中有 Navigation 3。

android skills list
android skills add navigation-3

Navigation 3 是相當新的程式庫，因此尚未經過大量訓練，您可以新增 Navigation 3 技能。

我們經常…抱歉

下一個是 MCP。

但我們常被問到，為什麼 Android CLI 是 CLI，而不是 MCP 伺服器？

我們在 AI 出現之前，甚至在滑鼠出現之前，就已經在建構這些 CLI，因此它們速度快、可組合，而且因為它們在您的殼層工作階段中本機執行，所以實際上是免費執行的。

此外，Terminal Bench 等基準測試已成為軟體工程領域最重要的基準測試，因此模型製作者積極提升終端機使用率，現在他們非常擅長使用 CLI。

但這不代表 MCP 沒有用武之地。

MCP 伺服器非常適合用於您已使用的外部服務，尤其是已託管 MCP 服務的外部服務。

您可以直接連結，不必安裝就能為代理提供額外背景資訊。

GitHub、Figma、Slack 等平台現在都提供 MCP 伺服器。

此外，我們一向在殼層中執行的項目可以保留在殼層中，因此透過 Android CLI 執行的 Android 指令，以及 Perfetto 和 Gradle，都適合放在本機，以便存取您在開發過程中使用的所有項目。

我以前負責效能。

我以前常說，Perfetto 是解決任何效能問題的必備工具。

但學習曲線非常陡峭，正如我們在 Rahul 的上一場演講中所見。

一起來看看 AI 如何協助提升成效。

謝謝 Ben。

因此，為了讓 Sideline 應用程式正常運作，必須以每秒影格數 30 的速度即時執行。

如這部 Pixel 10 Pro Fold 所示，每秒影格數只有 20 到 22 左右。

這些影格遺失會造成問題，因為這表示應用程式無法正常運作，因此我們必須修正這個問題。

Android CLI 包含 Android 分析器指令。

當我們將這項工具新增至程式設計代理，並指示其滿足每秒影格數 30 的要求時，發生了兩件有趣的事。

首先，它會使用 Android 分析器指令找出修正方法。

它記錄了所連接 Pixel 10 Pro Fold 裝置的系統追蹤記錄，發現 AI 執行緒是在裝置上最慢的核心上執行。

第二，有趣的是，它在我們沒有明確要求的情況下，使用了 Android 文件搜尋功能，並擷取了 Performance Hint API 的官方指南。

代理學會最佳化系統排程，因此能達到每秒影格數 30 的要求。

因此，基本上，修正措施是按照指引進行。

因此，Android CLI 的關鍵在於，透過與代理連結，即使您不熟悉該工具，也能協助您找到合適的工具，完成任何需要完成的工作。

執行後，可以看到 Sideline 達到使用者要求的每秒影格數，現在可以在 Pixel 10 Pro Fold 上運作。

現在我們來做個小測驗

現在，我們要用迴圈將所有內容整合在一起。

相信大家都遇過這種情況：要求代理執行重大變更，代理回報已完成，

如果你在安裝應用程式後，手動點選應用程式並回報錯誤，這就是我們需要停止的做法。

我們不應再擔任代理的品質確保測試人員，而是要預先定義「完成」的標準。

舉例來說，

我們想將整個專案遷移至 Nav3，接著代理會消失一段時間，但它會自信地回來並說：「遷移完成。

我最厲害。」

但當然，旋轉手機後，應用程式會當機，錯過所有投影片轉場效果，且未清理 Gradle 檔案。

這有點像我們現在所處的世界。

理想情況下，我們不希望這樣做，但這是目前的實際情況。

因此，我們應該先定義所有預期結果，這樣代理就能持續循環，直到符合所有條件。

這就是驗證迴圈。

我們有非常強大的資料，可以證明這項做法的成效。

這就是 Android Bench 2.0，也就是我在演講開頭提到的新版 AI 基準。

目前通過率約為 40%。

這些工作非常困難，而且非常龐大且實際，但其中一項是 Nav2 到 Nav3，這是您目前在專案中執行的工作。

如果使用 Fable 5.1，通過率為 22%，這是使用自然提示設定 (例如「將 Nav2 遷移至 Nav3」) 得到的結果。

但如果我們事先提供失敗的測試套件，也就是不提供答案，也不告訴它如何遷移至 Nav3，只是提供一個已經失敗的測試套件，並在所有工作完成後通過，那麼它在整個基準測試中的通過率就會躍升至 90%。

這表示這些模型現在確實能執行我們想得到的任何 Android 工作，只是不一定知道「完成」的定義。

因此，您不必事先編寫完整的失敗測試套件。

驗證迴圈可以很簡單，例如新增提示。

舉例來說，如果您正在處理 UI，可以要求 Gemini 轉譯 Compose 預覽畫面，確保符合 Figma 規格，然後顯示結果。

如果要求它顯示結果並證明已完成，而不是只接受「我完成了」的文字回覆，似乎真的有效。

如果您正在處理商業邏輯，可以要求它執行單元測試。或者，如我們在開頭所見，如果您正在修正當機問題，可以要求它透過遠端測試實驗室，在發生當機的實際裝置上驗證問題是否已修正。

Claude Code 內建一項技能，可協助您建立驗證迴圈。

請務必查看。

如果您在 Android Studio 中使用自己的代理，Android Studio 會提供許多工具，您可以根據工作內容建立迴圈。

舉例來說，您可以要求它在修正所有程式碼檢查錯誤前不要停止，或是我最喜歡的歷程，您可以要求它執行歷程，並確保歷程仍可正常運作。

或者，如果你已編寫歷程 (歷程很容易編寫，只是關於你正在處理的功能的提示)，可以指示它執行該歷程，並確保在宣告完成之前通過。

但歷程需要一段時間才能執行。

因此，你也可以將驗證迴圈分級。

因此，我們可以要求它先確認單元測試和 Compose 預覽畫面都能正確算繪。

通過後，請執行連線測試和 Android Journeys，只有在通過後，才執行完整的遠端裝置測試實驗室，也就是需要數小時的完整測試套件。

如果提供這項額外資訊，我們發現它會按層級循環，而不是在每次執行時嘗試執行每個步驟。

因為模型非常有自信。

因此，他們總是認為自己已經完成，而且總是認為自己會一次通過所有測試。

我們來看看 Sideline 的這項功能。

現在，我們將這個概念套用到 Sideline 應用程式，方法是新增一項功能，專為即將推出的 XR 眼鏡設計。

由於我們還沒有硬體，因此會使用 XR 模擬器，並指示程式碼代理程式擴充 Sideline，以支援新的板型規格。

屆時，我們會特別要求代理依序執行 JVM 測試、Compose 預覽測試和模擬器測試。

並指示每個迴圈以前一個迴圈為基礎。

這樣做時，我們首先會注意到，在迴圈一和二之間，JVM 測試是用來定義六個 Compose 預覽狀態。

當然，由於沒有呼叫模擬器，因此執行速度非常快。

同樣地，在第二和第三個迴圈之間，長字串等問題會在模擬器執行前就浮現並修正。

最後，模擬器迴圈執行後，會找出 JVM 測試和 Compose 預覽無法修正的其他錯誤。

但基本上，每次循環都會進一步強化應用程式，因此建議先執行速度最快但效果最弱的循環，再執行速度最慢但效果最強的循環。

以下是結果。

眼鏡會顯示揮拍類型和球離開球拍的速度，因此你可以在打網球時，即時獲得比賽回饋，不必將視線從球上移開。

對了，我先前提到會回頭處理之前發生的兩個 Crashlytics 問題。

既然我們已驗證這個方法可行，就可以在 Claude Code 中使用 /schedule 指令，設定任何想要的頻率，讓應用程式自我修復、修正所有錯誤、驗證錯誤已修正，並將修正結果以提取要求傳送給工程師，供他們查看及合併。

酷！

今天的內容大致到此結束。

如果只能記住一個重點，那就是開始思考如何為代理打造成功的環境，並像對待軟體開發和錯誤一樣對待這個環境。

這就是我們解鎖平行代理的方式。

網路上有很多關於這個主題的建議，而且許多建議彼此衝突。

這就是這個快速變動環境的現實。

因此，最好的做法是自行編寫專案評估。

當有新的建議或模型推出時，你就能實際評估並瞭解是否對你有幫助。

當然，每項工作都需要特定技能。

Claude Code 有一項技能可協助您建立評估。

/claude-api build-eval

強烈建議您前往查看。

今天我介紹了 Android Bench。

Android Bench 是我們的評估工具。

我們透過這項指標，確保情況有所改善。

如果想瞭解我們在建構過程中學到的經驗，避免犯下相同錯誤，請觀看 Android Bench 講座。

另有兩個面板。

一個在美國，一個在倫敦。

這兩部影片都會在網路上發布，討論這個概念在社群中的實際應用。

因此，我們邀請 Android 開發人員社群成員加入座談，分享他們如何在工作中實踐這項原則。

我們也十分期待您的意見回饋。

我們非常想知道，我們打造的產品是否真的對您有幫助。

請填寫問卷調查。

我會將這張投影片留在畫面上。

沒錯。

感謝收聽

感謝您！