指令列介面 (CLI) 工具指南

總覽

指令列是工程師與 Fuchsia 互動的主要介面 及其工具、驅動程式和裝置提供清楚、一致且連貫流暢 維護所有開發人員的工作效率和滿意度都至關重要 開發 Fuchsia 的工程師和團隊。本文件提供 為 Fuchsia 開發及改良 CLI 工具。

這些規範分為三大部分：

• 注意事項
• 使用者體驗指南
• 技術指南

注意事項

Fuchsia 和搭載 Fuchsia 的裝置建構出廣泛的開發人員介面， 不同堆疊層級使用者的需求和需求。時間 開發 Fuchsia 工具和子工具，確保一致性、 架構可預測性、可靠性，以及持續的支援與維護 讓使用者享有低延遲和高可用性

視發布範圍而定，各項工具可能會有差異 期望。下列指南和評分量表將可協助您 工具開發人員瞭解使用者體驗考量、技術相關規定及 說明文件預期對 Fuchsia CLI 工具的預期。

目標對象

Fuchsia CLI 工具由許多不同的人員建構、維護及使用， 團隊。一體適用的方法將不適用於 區分的結構定義，例如樹狀結構內與樹狀結構外或 SDK 使用者。 此外，有些使用者對於某些產業別有獨特的工作流程 例如驅動程式、核心或產品設定

開發或更新 Fuchsia 工具時，必須瞭解目標對象 因此想要建立更完善的 開發人員體驗

Fuchsia CLI 工具

確保 CLI 工具可供偵測，並有詳盡記錄將有助於減輕負擔 以便尋找現有工具、瞭解工作流程並找出差距。 在某些情況下，擴大現有工具的應用範圍，或許更有幫助。 無須建立新的子工具舉例來說，如果您希望刷新的 請優先將 TCP 選項新增至 ffx target flash，而非使用 TCP 不同的工具

這時應使用哪項工具？

您可以根據用途選擇合適的工具、指令碼或程式庫。 ffx 是用來與目標裝置或開發應用程式互動的 CLI 工具 例如智慧螢幕。fx 等樹狀結構內工具是 例如建立和測試 系統、存放區和整合項目

範例

• 使用 ffx 與 Fuchsia 裝置互動 (例如，ffx target flash 在裝置上刷新 Fuchsia 圖像，ffx component run或用來進行互動 個別裝置的元件)
• 使用 FX 在樹狀圖中開發 Fuchsia (例如fx set：設定建構作業，或 fx test：在主體機器上執行測試)

使用 CLI 工具與或管理 Fuchsia 裝置

• 隨 SDK 一起發布；開發人員也用過這個平台 Fuchsia，包括樹狀結構內開發人員。
• 根據使用者體驗操作，強調曝光度、一致性和穩定性 準則
• 大家對說明文件和--help內容的需求較高 支援開發人員
• 有些工具是直接由開發人員使用，有些是透過 整合指令碼或建構系統

平台原始碼樹狀結構中用於開發 Fuchsia 的樹狀結構內工具

• 適用於在 fuchsia.git 工作的樹狀結構內開發人員
• 強調低進入障礙，並快速演進工具、 通常是工具作者
• 預期異動會頻繁，可能沒有詳盡記錄

建構系統工具和指令碼 (例如 cmc、fidlc)

• 只能透過指令列選項和/或回應檔案控制。
• 強調 CLI 中的穩定性，以協助建構系統。
• 隨 SDK 一起發布；所有使用者均不明 也不知道/存取整合功能
• 通常不會由開發人員直接執行，且只會在建構作業中執行 有些人會將 Cloud Storage 視為檔案系統 但實際上不是

工具替代方案

除了 ffx 外，也有可用於互動和編寫指令碼的程式庫 開發主機與 Fuchsia 目標的互動。

• Fuchsia 控制器 是一種 Python 介面，可讓開發人員透過 FIDL 與目標互動
• 寬鬆 是以 Fuchsia Controller 為基礎， 無法純粹在目標端執行的指令碼測試，例如： 並需要重新啟動目標。

ffx 總覽

ffx 是頂層工具，可為開發人員提供核心功能 與執行 Fuchsia 的裝置互動。ffx 具有可延伸介面 可讓 Fuchsia 開發人員註冊為 子工具，方便您找到這些管道

ffx 的目標是打造緊密整合的工具平台， 指令列引數介面和指令的標準化 JSON 輸出內容。 在理想情況下，ffx 子工具將能使用常用服務，例如設定、 記錄、錯誤處理和測試架構這樣一來 一系列鬆耦合的工具，可依需求調整 專案需求

ffx 子工俱生命週期

在開發、更新或淘汰 ffx 子工具之前 需要考量的事項這項工具適合哪些對象？會不會公布 只有在 SDK 或樹狀結構內？是否有類似的工具？

建立新工具時，您可以參考下列提示。你也可以 參閱 CLI 工具開發評分量表，判斷您的 符合 Fuchsia 需求。

使用者體驗注意事項

這項工具的目標使用者是誰？要如何使用這項工具？

• 工具在現有命令結構中的何處？

真人使用者和指令碼/其他工具能否同樣使用這項工具？

• 工具有明確定義工具的哪些部分適用於機器和 自動化工作流程呢？
• 機器介面是否已記錄妥善？

命令介面是否符合 Fuchsia 指南且最適合 做法是什麼？

• 這項工具是否遵循使用者體驗指南？
• 這項工具是否為使用者提供完善的說明文件和說明 是否符合 CLI 說明規定？
• 工具是否提供清楚實用的錯誤訊息？
• 您是否曾考慮無障礙設計？

是否有其他使用者測試這項工具？

• 請團隊外部人員執行命令和輸出內容 確認是否可用

技術相關規定

工具是否已編譯並獨立於執行階段環境？

• 這項工具能盡量減少執行階段連結依附元件嗎？
• 這項工具是以 fuchsia.git 原始碼建構而成嗎？

這項工具支援機器介面嗎？

• 是否有關於機器介面的詳盡說明文件？
• 這項工具是否包含用於機器輸入的資訊清單或 JSON 檔案？

這項工具的相容性保證是什麼？

此工具是否會收集指標？

• 指標是否符合收集指標的隱私權相關規定？

產品管理

您將如何發布這項工具？

• 它只能存在樹狀結構內，還是包含在 SDK 中？

誰將由誰負責維護？

• Google 目前是否有更新、改善或淘汰這項工具的計畫？

使用者可以在哪裡找到常見問題的解答或新提問 有任何問題嗎？

Google 如何追蹤使用者回報的問題？

• 說明輸出和錯誤輸出內容是否含有錯誤連結？

已檢測哪些事件？哪裡可以找到這項指標的指標 工具？

CLI 工具開發評分量表

金鑰

1. 需要大幅改善
2. 需要改善
3. 符合基本規格需求
4. 超出預期
5. 極佳

使用者體驗指南

提供明確、一致且一致的工具，是提升公司成效的關鍵 讓所有開發工程師和團隊 紫紅色。這些使用者體驗指南的用意在於協助使用者建立並 整合 CLI 工具則可為使用者提供一致的開發人員體驗。 這些指南使用 Fuchsia 主要的開發人員工具 ffx 來表示 做法。

設計原則

請一律將目標放在盡可能簡化 ffx 介面。

• 優先考量使用者：考量所有潛在使用者的需求：工具 包括使用者、工具整合商、工具建構工具和工具平台建構工具
• 清楚明確：確認工具的用途、使用方式和意見回饋皆簡單明瞭 容易理解提供實用且可行的錯誤訊息和說明文字。
• 保持一致：在輸入/輸出模式、語言、 和 Fuchsia 的核心概念
• 採取全方位方法：確保工具有效運作 與其他服務整合，並在 定義。
• 以提升效率為目標：設計工具以提升效率和回應能力。 盡可能縮短延遲時間並快速執行疊代週期。
• 優先打造無障礙體驗：使用淺顯易懂的用語，並遵循無障礙設計規範 指南，確保不同能力的使用者享有可用性。
• 預先規劃：盡可能提高靈活性、擴充性和擴充性， 以因應未來的需求和成長

ffx 使用者組成

• 工具使用者：引導 Fuchsia 工作流程使用 ffx 工具 ( 平台或產品)
• 工具整合商：將 ffx 工具與其他工具整合，或 只不過是適合特定環境中的金鑰其中包括編寫更高層級的工具 納入 ffx 功能
• 工具建構工具：編寫及維護一或多項由 ffx 代管的工具
• 工具平台建構工具：改進及維護基礎工具 執行 ffx 工具的平台

指令結構

ffx 指令在根 ffx 指令下以樹狀結構的形式建構。這項支援 簡化使用者體驗的階層式架構 系統會提供一系列工具，方便使用者在指令樹狀結構中掃遍 與所需功能無關的路徑

ffx 指令樹狀結構上的路徑應加上名詞 名詞... verb 成本中心的架構指令路徑由名詞使用的內部節點組成 提高明確程度，且難以在分葉節點 (即動詞) 中進行 執行指令

例如，ffx component run <URL> 有一個根指令名詞 (ffx)、 子工具名詞 (元件)、子指令動詞 (執行) 和引數 (網址)， 是在執行指令時傳遞至指令的值。

ffx component run /core/ffx-laboratory:hello-world fuchsia-pkg://fuchsia.com/hello-world-rust#meta/hello-world-rust.cm

指令結構設計注意事項

開發新的 CLI 工具時，請務必將開發人員納入考量 以及平台上的瀏覽體驗將指令的數量控制在工具底下 能以合理方式 在應用程式內妥善運作避免重複，或針對項目加入不相關的指令 如果偏好在終端機視窗中工作 可使用 Google Cloud CLI gcloud 指令列工具在說明和說明中提供指令的合理配置 說明文件。

一般而言，適用於涵蓋常見工作流程的工具 (例如主機轉目標) 系統整合及發布)，最好 工具不需要另外建立新的獨立工具新增旗標、選項或 子指令來利用共用程式碼和功能。

但如果已啟用的整體工作流程不存在，請考慮新的指令 或更高層級的子群組查看現有的指令介面參考資料 說明文件 建立新指令或工具的選項

目標對象

這些工具可能會用於不同的開發工作。這些角色在大型團隊中 可以是不同的人員考量哪些使用者可能會使用特定工具 與觀眾互動

範例

• 元件開發
• 驅動程式開發
• Fuchsia 開發 (SDK)
• 版本整合 (GN 等)
• 系統整合服務供應商 (例如裝置端網路工具)
• 發布 (從開發主機到伺服器)
• 部署作業 (從伺服器到客戶)

某些工具在整合方面的期望可能不同。舉例來說 進行元件開發時，可能會希望工具能夠與整合式工具整合 開發環境 (IDE)，而建構整合工具可能會從 指令碼

將相關指令分組

Fuchsia 工作流程的相關指令應歸類在常見工具底下。 舉例來說，ffx 分成子工具與指令群組 以及高階 Fuchsia 子系統這有助於鼓勵團隊成員 並提供單一管道探索方式

範圍

指令列工具會根據使用者需求和目標的範圍而不同。創作 符合人體工學所需的工具有時就是簡單的單一用途 很適合用來自動處理耗時繁瑣的程序更大、更特色 工具應涵蓋使用者 (開發人員) 層級的整個工作。

範例

• 避免設計出可以完成工作中一小步驟的工具 而是設計一項可執行完整工作的工具
  • 舉例來說，開發 C++ 應用程式時：執行預先處理器 執行編譯器、執行連接器、啟動建構的執行檔。
• 偏好預設會完成所有必要步驟的工具 則可讓進階使用者執行部分步驟
  • 例如，傳遞引數，要求 C++ 編譯器只會執行 預先處理工作

ffx 子工具設計注意事項

ffx 子工具 (原稱外掛程式) 會整理成指令群組 對應至高階 Fuchsia 子系統。在 ffx target 中，ffx 是根指令 而 target 則是子工具 (子指令)ffx 子工具可能有專屬的 引數和選項 (例如ffx target list --format [format] [nodename])。

ffx CLI 應遵循標準結構和詞彙，方便使用者 體驗 ffx 的整體整合體驗，而不是單獨使用個別工具進行修補作業。 熟悉一項 ffx 工具的使用者，應該能夠預測及瞭解 指令名稱

設計 ffx 子工具時，必須在複雜度與 簡潔有力。一般來說，ffx 子工具應對應至記錄的 Fuchsia 概念 子系統 (例如target, package, bluetooth)。如果可行，子工具指令 群組應限制為主要功能或能力，而且 將選項新增為標記我們不建議新增次要指令群組，但 有時候無法避免內容清晰比簡潔更重要。

命名

使用常見的美國英文名詞處理 ffx 指令，也稱為 ffx 子工具。子指令應為命令式動詞。

• 文件中出現的常見名稱 Fuchsia 概念或子系統。請參閱 ffx 參考文件 查看目前 ffx 指令的清單
• ffx 子工具名稱必須為 3 個字元以上。(例如ffx bluetooth，非ffx bt)
• 指令和選項一律為小寫英文字母 (a-z)
• 子工具名稱不得包含連字號。選項 (旗標) 可使用單字 視需要分隔字詞 (例如--log-level)。

結構

遵循名詞別動詞的結構。將 Nest 相關指令做為子指令 父項工具

請勿建立包含連字號名稱的工具，例如 add-foo 和 remove-foo。 而是改為建立可接受 add 和 remove 子指令的 foo 指令。

動作

請使用簡明扼要的動詞，如實反映指令的動作。

偏好使用多個連字號工具的子指令 (例如，避免使用 foo-start, foo-stop, foo-reset，而是讓 foo 接受指令 start|stop|reset)

一致性

符合既有的 Fuchsia 術語和模式，將認知降到最低 載入。使用常見的動詞組合 (例如start/stop, add/remove, import/export) 並依循現有的 ffx 指令模式

簡潔

以最短的命令和選項名稱為主，而不犧牲清晰度。 曝光度。指令名稱長度不得少於 3 個字元。

避免使用不明確定義的縮寫或縮寫 (例如bt可能代表 藍牙、Bigtable 或 British Telecom)。

指令列引數

引數是在執行時傳遞至指令的值。 ffx 中的引數可以是精確文字、有序 (也稱為位置) 或未排序的選項 (也稱為旗標)。

選項

選項 (也稱為旗標) 沒有順序，而且會顯示在 或是指令所在的群組或指令詳情請參閱 頂層 ffx 選項。

• 選項長度至少要有 3 個半形字元，並且清晰可讀
• 必要時，可以使用單一連字號分隔字詞。使用單一 在多字詞選項名稱中以連字號連接字詞 (例如--log-level)
• 前面加上雙連字號 (--)，可使用單連字號 (-) 單一字元選項，但短旗標應謹慎使用 避免模糊不清請參閱短別名指南

選項中請勿使用大寫字母。請勿使用數字選項。如果 產生索引鍵值，例如 --repeat <number>。

開關

如果有切換鈕代表這項功能處於「開啟」狀態同時 都表示「關閉」。將預設動作切換為「關閉」。

• 所有外接切換裝置都必須妥善記錄 (不得使用隱藏的外接切換裝置)
• 有別於按鍵選項，切換按鈕不接受值。例如：-v 是一種常見的交換器意義之後就不會採用任何值

使用外接切換裝置改善工具的功能。外接切換裝置更簡單 而非功能旗標

無法同時執行外接切換裝置，例如：-xzf 或 -vv，每個 都必須分開：-x -z -f 或 -v -v。

短別名

一般來說，UX 建議避免使用簡短標記。不過， 對專家來說，簡短別名 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可過度使用短別名可能會造成混淆和混淆 (例如 -b 是 --bootloader、--product-bundle 或 --build-dir？)。Shorts 必須謹慎使用別名

• 每個選項都不需要別名。有疑慮時拼出你的字詞。
• 具有嚴重不可逆結果的命令應該有很長的名稱，所以 但因字體排版錯誤而沒有被叫用
• 只能使用小寫英文字母；不要使用數字

短別名應在整個 ffx CLI 中以一致的方式使用 (例如：在主要 ffx 工具中，-c 不應為 --config 簡寫。 一個子工具中的 --command，另一個子工具中的 --font-color)。

位置引數

位置或已排序的引數必須出現在指令名稱後方，且 顯示順序僅將已排序的引數用於 參數，順序對理解來說相當重要 (例如 copy <source> <destination>)。一般來說，請避免使用位置引數 偏好含有特定選項的文字引數

說明輸出內容

CLI 說明文字可透過 --help 存取，是重要的通訊工具， 使用者。這個名稱必須簡明扼要，且為 或是在需要時，取得更詳盡的說明文件。查看 CLI 工具說明規定 查看詳細資訊和範例

撰寫說明文字

終端機是極簡風的文字環境。提供過多資訊 卻可能導致使用者難以在當下獲得所需協助。說明 輸出內容應標準化，為使用者提供可操作的指引和 以視需要尋找更多資訊

必要元素

• 說明 - 工具功能和用途 (包括索引鍵) 的摘要 並取得使用資訊
• 用法 - 明確說明如何使用指令，包括語法和 引數 (使用 <&gt;來表示必要元素，[ ] 代表選用元素。
• 選項 - 詳細列出所有選項、效果與預設選項 價值
• 子指令：所有可用子指令的清單和摘要

建議元素

• 注意事項：重要細節與提醒事項
• 範例：工具使用說明示例
• 錯誤代碼：工具專屬錯誤及其含義清單

格式說明文字

說明文字應採用清楚的結構和風格，才能達到最佳成效 可讀性，包括在 80 時保持一致的縮排和換行 字元。文字應以清楚且文法正確的美國語言撰寫 英文，並遵循 Fuchsia 的文件標準。

錯誤訊息

錯誤可以為開發人員提供重要資訊， 。錯誤訊息和警告是讓開發人員充分瞭解相關知識的機會 對系統或工具的運作方式 以及其預期用途 相關單位會如何運用資料，並讓他們覺得自己 獲得充分告知，且能夠針對該使用方式表示同意Fuchsia 錯誤訊息應能幫助具有合理技術能力的使用者瞭解 並輕鬆快速地解決問題

這些規範適用於 Fuchsia 平台中產生的錯誤。錯誤數 如果 Fuchsia 以外的特定執行階段或語言建立，則可能無法遵循 這些規範。

寫入錯誤

• 說明問題：找出問題、原因和發生位置 加以修正。
• 協助使用者修正問題：提供清楚明瞭的解決方案， 合理且可行請提供連結以取得其他說明。
• 為人類撰寫內容 - 避免使用專業術語，確保語氣保持正向， 並保持一致

找出原因並提供解決方案

讓使用者瞭解問題發生、地點和原因。錯誤訊息 應該提供解決方案、後續步驟，或是說明特定錯誤的可能原因 已修正。

包含短連結

使用短連結將使用者重新導向至正確說明文件，並協助 進一步說明問題。請遵循這些指南 來建立短連結

狀態規定

指出不符合特定限製或先決條件。使用者 瞭解是否因輸入內容驗證而發生錯誤 (例如檔案不是 找到)、處理 (例如檔案中的語法錯誤)，或其他非預期的原因 (例如檔案損毀、無法從磁碟讀取)。

具體明確

如果錯誤涉及使用者可以修改的值 (文字、設定、command- 等行參數等)，那麼錯誤訊息中應會指出有問題 輕鬆分配獎金以便對問題進行偵錯。但值非常長 必須以漸進式或截斷的方式揭露。

使用一致的術語和結構

記錄資料可讓使用者進一步瞭解錯誤發生的方式和原因。使用 標準名稱、類別和值，並在 文件，協助您輕鬆參照錯誤。

建議做法：建立錯誤代碼目錄

加入專屬識別碼或標準化錯誤代碼，以及 訊息可協助使用者輕鬆找出錯誤，並在 錯誤索引或錯誤目錄舉例來說，FIDL 中的錯誤代碼一律會 後面加上一組 4 位數字的程式碼，例如 fi-0123。

• 請參閱範例：FIDL 編譯器錯誤目錄

技術規範

如要在 Fuchsia 中提供一致的開發人員體驗，CLI 工具應 使用標準程式庫、一致的設定、常見記錄和錯誤 處理和持續為使用者提供支援服務

程式設計語言

Fuchsia CLI 工具能以 C++、Rust 和 Go 編寫。工具必須經過編譯 而且獨立於執行階段環境Bash 等程式設計語言 不支援 Python、Perl 和 JavaScript。

執行階段連結依附元件

如要讓編譯工具更容易發布及維護，請將執行階段連結降到最低 依附元件最好改用靜態連結依附元件。在 Linux 上 對執行 glibc 程式庫 (libm 等) 有的執行階段連結； 系統不得使用其他執行階段連結依附元件

從來源建構

Fuchsia 工具應以 fuchsia.git 來源樹狀結構建構。使用相同的 建構和依附元件結構做為平台來源樹狀結構中的程式碼。禁止事項 建立獨立的系統來建立工具

指標

指標是衡量品質和業務決策的關鍵。類型 指標的內容必須謹慎選擇

使用指標找出解答的問題

• 我們的使用者使用哪種作業系統？- 優先處理不同平台的工作
• 他們使用哪些工具？- 以決定各項投資的優先順序，並學習 以及目前使用的工作流程，以便我們排定各項投資的優先順序， 辨識弱點
• 他們多久使用一次工具？我們瞭解該如何排定各項投資的優先順序 並瞭解目前使用的工作流程 也可以找出弱點
• 我們的工具在野外會當機嗎？多久採取一次？這樣我們就能知道 工具維護
• 他們如何使用工具？- 假設工具可以執行一或多項作業 我們希望瞭解如何排定特定工作流程的投資優先順序 工具

，瞭解如何調查及移除這項存取權。

設定和環境

工具通常需要對環境和情境的瞭解 以及 Pod 是可以運作的本節將說明 必須加以收集和/或儲存

閱讀資訊

工具不得嘗試從以下來源收集或讀取設定或狀態檔案： 以及執行容器的環境附加資訊： 目標 IP 位址、建構產品的 out 目錄，或是 寫入暫存檔案應從與平台無關的來源收集。 將執行平台特定工作的程式碼分開，可讓工具 也能移動到不同的平台之間

在可行情況下，應以熟悉 主體機器的使用者 (例如在 Windows 上使用登錄檔)。工具 從在封裝程式碼的 SDK 檔案或平台專用工具中收集資訊 從 Windows 登錄檔或 Linux 環境讀取資料的過程。

工具不應對任何建構系統或環境產生偏見。存取 建構輸入依附元件檔案等通用檔案除外

寫入資訊

除非 很清楚的設計目的是修改發布商的 環境。

如果修改工具在工具正常範圍外修改環境，可能有助於 但可在獲得使用者的明確授權的情況下進行。

測試

透過 SDK 發布或包含在建構系統中的工具必須 因此包含測試，以保證正確行為。同時加入單元測試和 整合測試測試會在 Fuchsia 持續執行 擷取及準備資料、針對特定領域進行預先訓練 調整指示、離線評估和整合

說明文件

所有 Fuchsia 工具都需要說明文件使用方式和 疑難排解指南。標準 --help 輸出內容必須包含：

• 說明：工具功能和用途的摘要，包括索引鍵 並取得使用資訊
• 用法：清楚說明指令的使用方式，包括語法和 引數 (使用 <>來表示必要元素，[ ] 代表選用元素。
• 選項：所有選項、特效和預設的詳細資訊細目 值
• 子指令：所有可用子指令的清單和摘要

如需更多詳細使用範例和解釋，請前往 Markdown fuchsia.dev.

使用者與程式輔助互動

不論是真人使用者，或以指令碼編寫程式，都能以互動方式執行工具 (或其他工具)。

如果工具可以的話，每項工具都會預設為互動或非互動模式。 而必須接受明確指示 指定模式 (例如，即使 工具是在互動式殼層中執行)。

標準

如果工具通常不會與使用者互動，請避免要求使用者輸入內容 (例如 。請勿加入非預期的提示，要求使用者輸入 問題。

像是 zxdb 這類會提示使用者輸入內容的互動式工具。

標準音樂

透過 stdout 傳送輸出內容給使用者時，請使用正確的拼寫和文法。 避免使用不尋常的縮寫。使用不尋常的縮寫或字詞時，請務必 且詞彙表中有條目。

護衛者

使用 stderr 回報無效作業 (診斷輸出)，例如 工具的行為異常。如果這項工具的用途是回報問題 (例如 Linter、 工具未失敗的情況下) 會將這些結果輸出至 stdout，而非 stderr。

結束代碼

系統一律會將結束代碼 0 視為「沒有錯誤」，結束代碼 1 一律為「一般 錯誤訊息。」請勿仰賴特定的非零值。使用機器輸出傳回 特定的錯誤代碼和訊息請參閱 FIDL 錯誤目錄範例。

• 若為成功，則傳回結束代碼 0
• 如果失敗，請傳回非零的結束代碼

除非輸出內容包含 也就是提供具體的關鍵資訊，能讓使用者 (例如檔案路徑)。不要列印「成功」除非使用者提出要求 取得詳細輸出選項

記錄

記錄與正常輸出內容不同，通常會設為 重新導向檔案，或應寫入 stderr。目標對象 記錄通常是工具開發人員或嘗試排解問題的使用者。

• 記錄多個執行緒的記錄不會與同一行內的字詞交錯， 輸出單位下限為整行文字。
• 每一行開頭都會註明嚴重性：detail, info, warning, error, fatal

自動化

在合理情況下納入程式輔助介面，以便執行自動化作業。如果 該網域目前已有通訊協定，請嘗試遵守 (或 而非我們推薦的這類產品)。MachineWriter (--machine) 可用於支援 結構化輸出內容

樣式規範

如要在 Fuchsia 中打造一致的開發人員體驗，CLI 工具應 請遵循程式設計語言的現有樣式規範 和 Fuchsia 說明文件。適用對象 例如，如果 Zircon 包含此工具並以 C++ 編寫，請使用 指南：Zircon 中的 C++ 指南。避免建立 分別適用於 CLI 工具的樣式指南

所有 CLI 工具、輸出內容和說明文件都必須遵循 Fuchsia 的「尊重行為」政策中載明。瞭解詳情 瞭解 Fuchsia 的說明文件標準。

檔案路徑中區分大小寫

請勿依賴檔案路徑中的大小寫機密性。不同平台可處理的操作 大小寫字母與大小寫不同Windows 不區分大小寫 區分大小寫。明確指出特定檔案名稱。發生情況 src/BUILD 和 src/build 是不同的檔案。

顏色

您可以在指令列介面中使用 ANSI 顏色，讓文字更容易閱讀 或突顯重要資訊使用顏色時，請務必選用顏色。 讀者可能無法看到所有畫面 (例如色盲)

• 請使用標準 8/16 顏色。 比 256 種顏色更容易重新對應到地圖
• 如果可以，請檢查終端機是否支援色彩並隱藏 並在輸出色彩時輸出不同的圖像
• 一律允許使用者手動隱藏色彩輸出，例如使用 --no-color 旗標和/或設定 NO_COLOR 環境變數 (no-color.org)

請勿完全依賴顏色傳達資訊。僅將顏色做為 調整模型一定要看到顏色，才能正確解讀 輸出內容進一步瞭解 Fuchsia 的無障礙功能。

ASCII 圖片

所有 Fuchsia 工具都應使用標準輸出格式，並採用一致的外觀 和風格請勿使用 ASCII 圖片設定表格格式，或以其他方式提升輸出內容。 ASCII 圖片可能難以讀取介面，且與下列項目不相容： 以及螢幕閱讀器的無障礙功能