基礎結構即程式碼的提示詞工程

  • 10 分鐘

GitHub Copilot 的實用性取決於你給的指令。 對於基礎架構任務，模糊的提示會產生一個通用範本，可能不符合你的命名慣例、安全標準或架構模式。 精心設計的提示詞會產生接近實際執行就緒的輸出。

這不是小差別。 像 create a Bicep template for a 虛擬網路 這類提示可能會產生一個沒有子網、沒有標籤且有硬編碼區域的最小範例。 像您在本單元結束時撰寫的提示詞，可能會產生完整參數化、已加上標記、包含多個子網路的虛擬網路，並具有 NSG 關聯和診斷設定。 結構正確，隨時可驗證。

寫出好提示的技巧是可以學習的。 本單元涵蓋持續從 GitHub Copilot 產生更優質基礎架構輸出的技術。

有效 IaC 提示詞的結構

每個強大的基礎設施提示包含四個元素的某種組合：

背景

情境告訴 Copilot 你正在做什麼樣的工作，以及適用哪些限制。 沒有上下文，Copilot 會做出假設。 這些假設可能不符合你的環境。

較不佳的提示詞：「在 Bicep 中建立儲存體帳戶。」

最佳化提示詞：「建立 Azure 儲存體帳戶的 Bicep 資源定義。 在澳洲東部區域的生產環境中執行。 帳號應該使用Standard_LRS，且要求僅使用 HTTPS 存取權限。」

情境包括目標環境（開發/暫定/生產環境）、區域、工具或語言、現有約束條件（命名慣例、標籤政策），以及你希望遵守的任何標準。

要求

需求是指該資源必須具備的特定能力、屬性或行為。 明確說明需求可以防止 Copilot 遺漏無法推斷的內容。

例如：

The storage account must: have soft delete enabled for blobs (7 days), use a private endpoint, disable public blob access, and be tagged with Environment, Owner, and CostCenter.

如果有多個需求，將需求列出並使用項目符號或編號。 Copilot 在處理結構化清單時表現良好，且不太容易漏掉項目。

輸出格式

請告訴 Copilot 您所期望的輸出。 對於 IaC 來說，通常指的是指定語言或工具，是想要完整檔案還是只想要片段，以及參數應該如何處理。

例如：

Output a complete Bicep file with parameters at the top, a resource block in the middle, and outputs at the bottom. Use decorators to add descriptions to all parameters.

如果你沒指定格式，Copilot 會選擇一種。 當你需要參數時，它可能會選擇內嵌硬編碼值，當你想要完整檔案時則選擇片段。

條件約束

限制條件告訴 Copilot 該避免什麼。 這很容易被忽略，但對安全性或合規來說尤其重要。

例如：

Do not use any deprecated API versions. Do not expose any management ports (22, 3389) in NSG rules. Do not hardcode any subscription IDs or tenant IDs.

零樣本提示

零樣本提示表示您描述想要的內容，而不提供任何範例。 這是最常見的方法，根據 Copilot 的訓練資料，適用於標準基礎結構模式。

例如：

Generate a Bicep template for an Azure Key Vault with the following requirements:
- SKU: Standard
- Soft delete enabled with a 90-day retention period
- Purge protection enabled
- RBAC authorization model (not access policies)
- Public network access disabled
- A private endpoint connected to a subnet parameter
- Tags: Environment, Owner, CostCenter (all as parameters)
Use descriptive parameter names and add @description() decorators to each.

零射擊在資源類型普遍且需求明確時效果最佳。 如果你使用的資源類型較少見，或需要特定的結構，請考慮提供一個範例。

少量樣本提示

少量樣本提示表示您在提示詞中提供一或多個範例，讓 Copilot 了解您想要的模式或樣式。 當你已有已有的程式碼庫，裡面有 Copilot 原本不會知道的慣例時，這很有用。

少量樣本提示詞範例可能如下所示：

Here is an example of how we define storage accounts in our Bicep codebase:

[paste your existing storage account resource block]

Using the same naming convention, parameter style, and tag structure, generate
a similar resource block for an Azure Service Bus namespace with these requirements:
- Standard SKU
- Geo-redundant disaster recovery enabled
- Minimum TLS 1.2
- Same tagging pattern as the example

透過向 Copilot 展示你現有的模式，你會得到與程式碼融合的輸出，而不是遵循 Copilot 預設風格的輸出。 在整合生成程式碼與現有範本時，節省了大量清理時間。

角色型提示

角色型提示會要求 Copilot 在產生輸出前採用特定觀點。 它對安全審查和架構指導非常有效。

在安全脈絡中，舉例可以是這樣的：

You are a senior Azure security engineer reviewing Bicep templates for enterprise
production deployments. Review the following template and identify:
- Any security misconfigurations or missing security controls
- Resources that expose public endpoints unnecessarily
- Missing diagnostic settings or logging configuration
- RBAC assignments that are too broad
- Any deprecated API versions

For each issue found, explain the risk and provide the corrected Bicep snippet.

基於角色的提示會將 Copilot 的輸出從「這是有效的程式碼」轉變為「這是有效、安全且遵循最小權限原則的程式碼」。品質差異是明顯的。

迭代精煉

在基礎設施即程式碼的任務中，與 GitHub Copilot 合作的最有效方式並不是寫出一個完美的提示。 這是先從廣泛範圍開始，再逐步精簡。

範例創作流程會循環以下幾個階段：

步驟一：從核心資源開始

Generate a Bicep template for a hub-spoke VNet topology with one hub and one spoke.

檢查輸出。 基本結構正確嗎？ 地址空間合理嗎？

步驟 2：新增安全要求

Add an NSG to the application subnet in the spoke that blocks all inbound
internet traffic except HTTPS (port 443). Add a deny-all rule at the end.

步驟 3：新增可觀察性

Add diagnostic settings to the NSG that send flow logs to a Log Analytics
workspace. Add the Log Analytics workspace as a new parameter.

步驟 4：加入參數化

Replace all hardcoded values (address spaces, location, resource names)
with parameters. Add @description() and @allowed() decorators where appropriate.

步驟五：新增標籤

Add tag parameters for Environment, Owner, and CostCenter. Apply tags to
every resource in the template using a tags object parameter.

這種五步驟方法持續產生比單一複雜提示更好的輸出，因為每個步驟都是建立在前一個經過驗證的輸出基礎上。 你在加入下一層要求前，先審查並接受每個增量。

常見的提示錯誤

過於模糊

問題：使用類似 Create a Bicep template for my infrastructure 的提示詞

結果： 一個簡陋的模板，只有猜測值、錯誤的資源類型，且沒有安全設定。

修正方法： 請具體說明你需要哪些資源、哪些 SKU、哪些區域，以及適用哪些安全要求。

忘記了安全限制

問題： 產生虛擬機範本卻不指定管理埠不應開啟

結果： 一個允許從網際網路進站 SSH 和 RDP 的 NSG。 這是嚴重的安全設定錯誤

修正方法： 在每個基礎設施提示中明確說明安全需求。 不要假設 Copilot 預設採用安全設定

未指定 API 版本偏好

問題： 使用類似的提示 Use the latest API version

Result： 沒有 MCP，Copilot 仍可能使用訓練資料中的版本，而這些資料可能已過時。

Fix： 啟用Bicep MCP 伺服器，或如已知 API 版本，請明確說明。 至少要求 Copilot 標示其是否不確定 API 版本。

在一個提示詞中要求過多內容

Problem：一個20行的提示，要求建立一個完整的Azure著陸區，包含網路、身份、治理與監控功能。 一次全部完成。

Result： 一個繁雜的模板，有很多缺口、缺少跨資源引用，以及Copilot所猜測的屬性。

修正方法： 使用迭代精煉。 將範本分層建立，並在新增下一層前驗證每一層。

沒有提供現有程式碼庫的背景說明

問題：要求 Copilot add a subnet to the 虛擬網路，卻未提供現有的虛擬網路資源定義。 結果： 一個可能與現有定義結構或命名相衝突的新子網資源。 修正方法： 當你擴充或修改現有範本時，務必將相關現有程式碼貼到提示中。

基礎架構的提示模式

以下模式直接適用於本模組中的任務。

世代模式

從零開始時的使用方法：

Generate a [tool: Bicep/CLI/YAML] [resource type] with the following requirements:
- [requirement 1]
- [requirement 2]
- [requirement 3]
Parameterize: [list of values to parameterize]
Tag every resource with: [tag names]
Do not: [constraints]

延伸模式

新增現有範本時的使用：

Given this existing [tool] [resource definition]:

[paste existing code]

Add the following:
- [addition 1]
- [addition 2]
Maintain the existing naming convention and parameter style.

審查模式

審核現有範本時的使用方法：

Review this [tool] template for:
- Security misconfigurations
- Missing required properties
- Deprecated API versions
- Resources exposed to the public internet unnecessarily
- Missing tags or diagnostic settings

For each issue, explain the problem and provide the corrected snippet.

[paste template]

翻譯模式

工具轉換時的使用方法：

Translate this [source tool] [script/template/pipeline] to [target tool].
Preserve:
- The same variable/parameter names where possible
- Error handling logic
- The same resource naming and tagging
Do not add features that are not in the original.

[paste source code]

解釋模式

當你需要了解現有基礎設施時可以使用：

Explain what this [tool] template deploys in plain language.
Describe each resource, its purpose, and how the resources relate to each other.
Identify any security controls that are configured.
Highlight anything that looks unusual or that might cause problems in production.

[paste template]

審查心態

GitHub Copilot 是協作者，而非權威。 它產生的每個輸出都應該在使用前進行審查。 尤其是基礎設施，錯誤設定可能會讓系統暴露於網際網路、無法使用資源，或產生意外成本。

檢視 Copilot 基礎設施產出時應該提出的問題：

  • API 版本是最新的嗎？ 請參考 Azure 文件或使用 Bicep MCP。
  • 所有必需的屬性都齊全了嗎？ 執行 az bicep build 以檢查缺少的必填欄位。
  • 安全預設值合適嗎？ 檢查公開網路存取、管理埠外洩和加密設定。
  • 資源是否正確地被交叉參考？ 確保資源參考使用符號名稱，而非硬編碼 ID。
  • 它是否具備冪等性？ 重複執行這個範本會造成衝突或重複嗎？

把 Copilot 的成果當作初稿而非最終答案，才是能產生最佳成果的心態。

重點摘要

  • 有效的 IaC 提示包括上下文、需求、輸出格式與限制條件。
  • 零樣本提示適用於常見資源類型；當您有要比對的現有程式碼模式時，少量樣本提示效果較佳。
  • 基於角色的提示（「你是資深 Azure 安全工程師......「）提升審查品質與架構指導。
  • 透過分層建置進行反覆精簡，會比使用一個大型提示詞產生更好的輸出。
  • 使用前務必先檢視 Copilot 的輸出：檢查 API 版本、所需屬性、安全設定及資源參考。