用 GPT-6 Astra 建構《皇室戰爭》基礎牌組：從策略分析到 4K 教學海報

讓 AI 推薦一套《部落衝突：皇室戰爭》卡組並不難。真正有價值的問題是：為什麼選擇這八張卡？它們如何互相配合？進攻和防守時應該怎樣出牌？推薦結果又該如何驗證？

本文以一套平均聖水消耗為 3.5 費的巨人防守反擊卡組為例，介紹如何把自然語言需求轉化為結構化的策略分析，再透過程式碼校驗和圖像生成，得到一份可以理解、練習和迭代的教學方案。

整個流程不是讓模型隨口給出「最強卡組」，而是將工作拆成四個部分：

明確約束 → 分析卡組 → 校驗結果 → 製作視覺化教學。

¶ 一、先明確：我們希望 AI 解決什麼問題？

「幫我配一套容易贏的卡組」看似明確，實際上缺少大量必要條件：玩家處於哪個競技場？已經解鎖哪些卡牌？卡牌等級是否接近？是否使用進化卡牌、英雄技能或特殊塔兵？玩家更熟悉快速輪轉，還是防守反擊？所謂「容易」，指操作簡單，還是對特定對手優勢明顯？

如果這些資訊沒有提供，模型很容易給出一套理論上合理、實際卻不適合玩家帳號的陣容。因此，本案例先設定以下邊界：

維度	本次約束
卡牌選擇	優先基礎、常見的普通與稀有卡牌
卡牌型態	普通型態，不依賴進化或英雄技能
塔兵條件	普通公主塔
等級條件	預設雙方卡牌等級接近
操作目標	分工明確，適合學習
戰術方向	防守成功後組織反擊
評價邊界	不宣稱即時版本最強，不虛構勝率

這些約束決定了後續分析方向：我們尋找的是容易理解、職責互補的基礎方案，而不是一套未經實戰驗證的「必勝公式」。

¶ 二、讓 GPT-6 Astra 負責分析，讓程式負責校驗

本案例透過 AceDataCloud 的 Chat Completions 介面呼叫 GPT-6 Astra，請求中的模型識別為 gpt-6-astra。介面網址、認證方式與訊息結構遵循平台接入文件；模型可用性與參數應以呼叫時的平台設定為準。這裡使用的是平台提供的模型識別，不由此推斷其他服務入口的可用性。

工具	負責的工作	不應承擔的工作
GPT-6 Astra	解釋卡牌分工、分析配合、組織攻防步驟	代替真實對戰資料證明勝率
Python	校驗卡牌數量、重複項、費用與組合成本	僅憑加法判斷實戰強弱
GPT Image 2	將戰術方案轉化為教學海報	作為遊戲機制的權威來源

還需要區分歷史過程與復現方法：本案例的八張卡組已在前期分析中形成，隨後實際呼叫 GPT-6 Astra 對它進行了結構化複核；並不是讓 Astra 從完整卡池中搜尋出全域最優解。教學海報則由 Image 2.0 生成。

這樣記錄過程，既便於復現，也避免把「模型參與了分析」誇大為「模型證明了最優」。

¶ 三、提示詞設計：從「推薦卡組」變成「約束下的推理」

¶ 1. 開放式組牌提示詞

如果從自己的卡池開始，可以使用下面的範本：

你是一名严谨的《皇室战争》教学分析助手。

目标：
从我提供的可用卡牌中，选择一套适合基础玩家的八张卡组。

条件：
1. 只使用我已解锁的卡牌。
2. 不依赖进化或英雄技能。
3. 默认普通公主塔，卡牌等级接近。
4. 优先职责互补、操作简单、方便学习的体系。
5. 必须说明主要拆塔手段、对空、清群和防守方式。

输入：
- 我的竞技场与杯数：……
- 可用卡牌及等级：……
- 常见对手：……
- 我的操作偏好：……

输出：
- 八张卡牌及职责
- 总费用与平均费用
- 选择理由
- 进攻与防守步骤
- 明确的弱点和替换代价

不得编造胜率。
若没有实时资料，不得声称这是当前版本最强卡组。

關鍵不是提示詞有多長，而是有沒有提供允許選擇的範圍、最佳化目標和必須承認的限制。

¶ 2. 本案例使用的複核提示詞

為了檢驗既有方案，本次進一步收緊任務。下面是實際複核要求的整理版：

请复核以下卡组，而不是重新寻找全卡池最优解：

巨人5、迷你皮卡4、火枪手4、炸弹兵2、
亡灵3、加农炮3、万箭齐发3、火球4。

默认：
卡等接近、普通公主塔、普通形态，
无进化、无英雄技能。

请返回一个有效的 json 对象，包含：
deck、total_elixir、average_elixir、
advantages、attack_steps、defense_cases、
limitations、validation_note。

要求：
- 说明每张卡的职责。
- 区分“利用防守残兵”和“免费获得单位”。
- 不得把11费组合说成满10费即可立即全部部署。
- 不承诺无伤防守。
- 不提供没有来源的精确伤害或胜率。

本次實際呼叫得到的核心結論是：卡組分工清楚，適合練習防守反擊，但對空單位需要保護，推進階段也必須保留應對另一側進攻的資源。這屬於基於給定機制的理論分析，並不等於模擬器測試或天梯統計。

¶ 四、透過 API 取得結構化分析

Chat Completions 介面使用 Bearer Token 驗證，生成的文字可以從 choices[0].message.content 讀取。

下面是一個精簡的 Python 重現範例。執行前安裝 requests，並在自己的執行環境中設定 ACEDATACLOUD_API_KEY。不要把金鑰寫進程式碼儲存庫或瀏覽器前端。實際案例透過 MCP 工具呼叫；以下程式碼示範對應的 HTTP 存取方式，並非聲稱這段指令碼已在讀者環境測試。

import json
import os

import requests

URL = "https://api.acedata.cloud/openai/chat/completions"

# 本案例已核对的输入快照。
# 实际项目应维护版本化卡牌资料，不要依赖模型猜测费用。
cards = [
    {"name": "巨人", "elixir": 5, "role": "只攻击建筑的高血量前排"},
    {"name": "迷你皮卡", "elixir": 4, "role": "地面单体高伤"},
    {"name": "火枪手", "elixir": 4, "role": "远程对地对空"},
    {"name": "炸弹兵", "elixir": 2, "role": "地面范围伤害"},
    {"name": "亡灵", "elixir": 3, "role": "空中部队，可对地对空"},
    {"name": "加农炮", "elixir": 3, "role": "仅对地的防守建筑"},
    {"name": "万箭齐发", "elixir": 3, "role": "清理脆皮群"},
    {"name": "火球", "elixir": 4, "role": "范围伤害与补伤害"},
]

task = """
请复核输入卡组，返回有效的 json 对象。

输出字段：
deck（每项包含 name、elixir、role）、
total_elixir、average_elixir、advantages、
attack_steps、defense_cases、limitations、validation_note。

默认卡等接近、普通公主塔、普通形态，无进化无英雄。
这是已有卡组复核，不是全卡池最优搜索。
没有实时对战数据，不得编造胜率、无伤承诺或精确伤害。
"""

response = requests.post(
    URL,
    headers={
        "Authorization": f"Bearer {os.environ['ACEDATACLOUD_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "model": "gpt-6-astra",
        "messages": [
            {
                "role": "system",
                "content": (
                    "Return a valid json object. "
                    "你是严谨的游戏教学助手，只基于给定事实分析。"
                ),
            },
            {
                "role": "user",
                "content": task + "\n输入卡组：\n"
                + json.dumps(cards, ensure_ascii=False),
            },
        ],
        "response_format": {"type": "json_object"},
        "max_tokens": 2200,
    },
    timeout=(10, 180),
)

response.raise_for_status()
body = response.json()

if body.get("error"):
    raise RuntimeError(body["error"])

choice = body["choices"][0]
if choice.get("finish_reason") != "stop":
    raise RuntimeError("输出未正常结束，请检查返回状态或调整输出预算")

content = choice["message"].get("content")
if not content:
    raise RuntimeError("没有获得可解析的分析内容")

result = json.loads(content)
print(json.dumps(result, ensure_ascii=False, indent=2))

¶ 一個實際遇到的介面細節

本次呼叫中，首次 JSON 模式請求被伺服器拒絕，錯誤提示要求輸入訊息包含 json。將英文指令 Return a valid json object. 明確加入訊息後，請求成功。

這裡不需要推斷失敗一定由大小寫或其他因素造成。工程上更穩妥的處理是：明確要求輸出 JSON，同時設定回傳格式，檢查結束狀態，解析後繼續驗證欄位和數值。

能解析為 JSON，只說明語法成立，不代表遊戲分析正確。

¶ 五、最終卡組：3.5 費巨人防守反擊

本次方案如下。費用來自對應卡牌資料，職責與配合則用於解釋本套卡組的設計。

卡牌	聖水	主要職責	使用注意
巨人	5	承傷、推進、攻擊建築	不負責清除敵方部隊
迷你皮卡	4	處理高血量地面目標	容易被小兵圍住或拉走
火槍手	4	遠程輸出、主力對空	需要保護，避免與其他後排擠在一起
炸彈兵	2	清理地面群體	不能對空
亡靈	3	第二道對空、補充輸出	怕箭雨和範圍傷害
加農炮	3	中場拉扯、輔助防守	不能攻擊空中單位
萬箭齊發	3	清除脆皮群	應針對實際目標使用
火球	4	打集中後排、補傷害	不預設能秒殺同級火槍手

這套牌的價值不是單卡稀有度，而是職責互補：巨人提供主要拆塔壓力，迷你皮卡處理地面威脅，炸彈兵清理干擾單體輸出的小兵，火槍手與亡靈提供兩個持續對空點，加農炮爭取輸出時間，兩張法術負責清障與補傷害。

¶ 用程式碼驗證費用

不要只讀取模型回傳的 average_elixir。更可靠的方法是：用已核對的輸入資料重新計算，並與模型輸出交叉檢查。 把下面程式碼接在前面的範例之後：

trusted_costs = {card["name"]: card["elixir"] for card in cards}

deck = result["deck"]
names = [card["name"] for card in deck]

if len(names) != 8 or len(set(names)) != 8:
    raise ValueError("卡组必须恰好包含8张不同卡牌")

if set(names) != set(trusted_costs):
    raise ValueError("模型更改了本次要求复核的卡组")

for card in deck:
    if card["elixir"] != trusted_costs[card["name"]]:
        raise ValueError(f"费用不一致：{card['name']}")

total = sum(trusted_costs[name] for name in names)
average = total / len(names)

if result["total_elixir"] != total:
    raise ValueError("模型返回的总费用不一致")

if abs(float(result["average_elixir"]) - average) > 1e-9:
    raise ValueError("模型返回的平均费用不一致")

print(f"总费用：{total}，平均费用：{average}")

本例的獨立費用檢查結果為：

總費用：5 + 4 + 4 + 2 + 3 + 3 + 3 + 4 = 28
平均費用：28 ÷ 8 = 3.5

還可以繼續檢查常用組合：

組合	總費用	用途
巨人＋炸彈兵	7	應對地面小兵的輕推進
巨人＋火槍手	9	有對空能力的常規推進
迷你皮卡＋炸彈兵	6	分別處理肉盾與地面小兵
加農炮＋火槍手	7	拉扯與遠程輸出
巨人＋火槍手＋炸彈兵	11	利用殘兵或回費逐步形成完整推進

最後一項尤其值得注意：11 費組合不能在僅有 10 點聖水時立即全部部署。它更適合由防守存活的火槍手或炸彈兵，配合新部署的巨人形成，而不是把三張牌一次性堆出去。組合費用只是投入成本，並不證明能穩定賺費。

¶ 六、將分析轉化為能執行的攻防方案

¶ 進攻：先守住，再把殘兵變成壓力

這套卡組的主線不是開局就投入巨人，而是：

用加農炮或部隊處理敵方進攻。
觀察存活單位的血量、位置與當前費用。
條件合適時，在殘兵前方補巨人。
看見對方解牌後，再決定補部隊還是交法術。
保留處理另一條路進攻的能力。

例如，火槍手防守後仍然存活，在她過橋前部署巨人，讓巨人先承受傷害，火槍手繼續輸出。這裡的資源收益來自一張已付費單位同時參與防守和反擊，而不是憑空獲得了一張免費火槍手。

¶ 防守：按威脅選擇組件

對手威脅	優先處理思路
野豬騎士等建築目標單位	及時用加農炮中場拉扯，視支援情況補牌
高血量地面目標	迷你皮卡配合塔輸出，必要時先用建築改變路徑
地面小兵群	炸彈兵處理，或在合適時機使用萬箭齊發
空中進攻	火槍手與亡靈分散部署，避免同時被範圍傷害清除
聚集的後排支援	火球補傷害，再由部隊接手

這些方案都依賴位置、等級、時機和敵方支援，不能理解為固定的無傷公式。加農炮雖然可吸引只攻擊建築的空中單位，但自身不能對空輸出。

¶ 必須保留的弱點說明

一份合格的 AI 策略輸出，應該明確告訴玩家什麼時候會難打：

火槍手和亡靈被處理後，對空壓力會明顯增加。
本套沒有重置類法術，面對地獄系防守時不能盲目堆兵。
巨人投入後，另一條路可能成為對方施壓的目標。
3.5 費不等於極限速轉，關鍵防守牌交錯時，未必能及時回手。

因此，模型提供的是練習起點，後續仍應結合自己的卡等、常見對手和對戰紀錄調整。

¶ 七、把戰術方案生成 4K 教學海報

文字適合解釋原因，圖片則更適合展示站位關係和出牌順序。本案例沒有採用八張大卡牌機械排列的方式，而是將畫面設計成三個相連的教學階段：

低費防守 → 巨人頂前、殘兵跟進 → 看清解牌、補充支援。

下圖是本次由 Image 2.0 生成的教學海報。圖片檔案的尺寸經檢查為 3840×2160，16:9。

3.5費巨人防守反擊教學海報：八張基礎卡牌、費用與防守反擊步驟

圖：AI 生成的戰術教學示意，不是遊戲實戰截圖，也不用于表達精確射程與逐格站位。

¶ 提示詞要寫「教學關係」，不只是「畫面風格」

「4K、細節豐富、電影感」只能描述視覺方向，不能保證生成結果有教學價值。因此，提示詞應同時包含：

角色關係：巨人在前，火槍手與炸彈兵在後。
階段關係：左側防守，右側反擊，用箭頭連接。
機制約束：巨人只攻擊建築；加農炮與炸彈兵不能對空。
資訊層級：標題、三步教學、卡組列表、費用、注意事項。
邊界說明：普通形態教學，效果受卡等和操作影響。

下面是適合重現思路的精簡提示詞，並非原始長提示詞的逐字記錄：

制作一张16:9横版、3840×2160的中文战术教学海报。

主题：皇室战争“3.5费巨人防守反击”。
画面不是卡牌网格，而是生动的3D卡通竞技场教学场景。

左侧：加农炮中场拉扯，迷你皮卡处理地面肉盾，
火枪手对空，炸弹兵清理地面小兵。

右侧：巨人在最前方向敌方建筑推进，
防守存活的火枪手和炸弹兵在后方分散跟进，
亡灵提供空中支援。

用清晰箭头表达：
低费防守 → 补巨人反击 → 看清解牌再补支援。

底部展示八张卡及费用：
巨人5、迷你皮卡4、火枪手4、炸弹兵2、
亡灵3、加农炮3、万箭齐发3、火球4。

标注：
平均圣水3.5；
巨人＋炸弹兵＝7费；
巨人＋火枪手＝9费。

提醒：
保留防守圣水、后排分散站位、先看解牌再交法术。

确保中文清晰、战术指向准确。
不要画巨人攻击部队，不要画加农炮或炸弹兵攻击空中。

¶ 圖像介面設定

圖像生成介面文件支援透過 size 指定像素尺寸，16:9 的 4K 規格為 3840x2160；僅在提示詞裡寫「4K」，不能取代尺寸參數。

請求主體的核心設定如下，其中 prompt 應替換為完整的海報描述：

{
  "model": "gpt-image-2",
  "prompt": "此处填写完整的战术教学海报提示词",
  "size": "3840x2160",
  "quality": "high",
  "n": 1,
  "output_format": "png",
  "response_format": "url"
}

對應介面為：

POST https://api.acedata.cloud/openai/images/generations

¶ 實際生成過程中的失敗與切換

本次最初使用 Image 2.5，但任務以明確的上游服務錯誤結束，沒有產出圖片。隨後在確認切換後，改用 gpt-image-2，保留 4K 和 16:9 規格，最終生成成功。

這裡有一個重要的工程原則：

任務還在執行時，查詢同一個任務；任務明確失敗後，再決定是否重試或切換模型。

本次使用的 MCP 圖像工具以非同步任務方式執行：提交後取得任務 ID，再查詢至成功或失敗。直接呼叫 HTTP 介面時，則應依照對應文件處理同步回傳或非同步回呼，不要把不同呼叫方式的回傳結構混用。

¶ 八、如何進一步做成可持續迭代的工具？

如果要將這個案例擴展為真正的卡組助手，可以增加三層能力。

¶ 1. 版本化資料

記錄卡牌名稱、費用、攻擊目標、等級與資料更新時間。對於傷害、血量、射程等容易變動的資料，使用有來源的資料，而不是依賴模型記憶。

¶ 2. 使用者卡池約束

把使用者已解鎖卡牌和等級作為輸入。等級差距很大時，理論搭配合理不一定意味著實際表現更好。

¶ 3. 對戰回饋

持續記錄對手主要進攻手段、自己在哪個階段失去聖水優勢、關鍵對空牌是否交錯，以及問題來自卡組結構還是擺位與時機。

再讓模型根據這些記錄提出一次只改一兩個變數的調整建議，而不是每輸一局就換整套卡組。

海報也應進行獨立驗收：檢查八張牌是否完整、中文是否正確、費用是否一致、箭頭是否指向正確目標。生成成功不等於內容驗收通過，解析度正確也不等於戰術圖示完全準確。

¶ 結語

這個案例展示的不是「AI 自動算出最強卡組」，而是一套更可靠的使用方法：

用約束限定任務，用 GPT-6 Astra 解釋配合，用程式碼驗證數值，用 Image 2.0 展示戰術，再用實戰回饋修正方案。

最終得到的巨人卡組，核心思路可以濃縮為一句話：

加農炮拉扯，迷你皮卡處理肉盾，火槍手對空，炸彈兵清群；守住以後，讓巨人頂到前面。

比起只拿到八張卡的名字，這種方式更有價值的地方在於：玩家不僅知道「帶什麼」，也能理解「為什麼這樣帶，以及什麼時候應該這樣打」。

¶ 參考資料

Chat Completions API 整合指南
Chat Completions API 參數文件
GPT Image 圖像生成整合指南
圖像生成 API 參數文件
卡牌費用參考見卡組表中各卡牌資料連結；實戰數值與可用功能以目前遊戲內資訊為準。

本文為 AI 輔助策略與開發實務案例，非 Supercell 官方攻略。封面與教學海報為 AI 生成示意圖；《皇室戰爭》相關角色與商標歸相應權利人所有。