Power Apps 開發在 2026 年突然變了：從手動拖拉到 AI 直接生成 Canvas App

| PowerPlatform | 2 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1334

如果你在 2026 年年初接觸過 Power Apps，現在重新看它，可能會產生一種非常強烈的違和感：

幾個月前不是還只能在 Power Apps Studio 裡手動拖控制項嗎？為什麼現在 Codex、Claude Code 之類的 AI，突然可以直接建立和修改 Canvas App 了？

這並不是記憶出錯，也不是以前一直存在某個隱藏功能，只是我們沒有發現。

Power Apps 的 Canvas App 開發方式，確實在 2026 年 5 月前後出現了一個非常大的轉折。

一、2026 年初，實務上仍然只能手動製作 Canvas App

在 2026 年年初，製作 Canvas App 的主要方式仍然是打開 Power Apps Studio，然後由開發者手動完成以下工作：

  • 建立 Screen
  • 拖入 Button、Label、Text Input、Gallery 等控制項
  • 設定控制項的位置、尺寸和樣式
  • 編寫 Power Fx 公式
  • 設定 Dataverse、SharePoint 或其他資料來源
  • 逐個測試畫面跳轉、資料更新和權限邏輯

當時 Power Apps 雖然已經加入 Copilot，也能根據 Dataverse 資料產生一些基本 App，但它更接近「協助建立初始畫面」，而不是一套可以自由控制整個 Canvas App 的外部開發方式。

也就是說，當時你不能很可靠地對 Codex 說：

請在案件查詢畫面新增一個案件編號輸入框，
再新增查詢按鈕，點擊後從 Dataverse 篩選案件，
並把結果顯示在 Gallery 裡。

然後期待它自動完成全部工作，並把結果同步回 Power Apps Studio。

在當時，這種做法基本還不存在。

二、以前雖然能看到 YAML，但不代表可以靠 YAML 開發 App

Power Apps 很早就開始把 Canvas App 的部分內容表示成 YAML。

例如，一個 Canvas App 可以包含以下檔案：

App.pa.yaml
HomeScreen.pa.yaml
SearchScreen.pa.yaml
DetailScreen.pa.yaml

這些檔案看起來很像普通程式碼，因此很容易讓人產生一個想法：

既然畫面和 Power Fx 都能表示成 YAML，那我直接讓 AI 修改 YAML，不就能自動生成 Power Apps 畫面了嗎？

問題在於，當時官方產生的 .pa.yaml 主要是用來查看 Power Apps Studio 所做的變更。

Microsoft 的文件曾明確說明，這些 YAML 檔案是唯讀的。直接修改後，變更可能被忽略，也可能在下一次儲存時遺失。

換句話說，當時的關係主要是：

Power Apps Studio
        ↓
產生 Canvas App YAML
        ↓
供開發者查看、比較和進行版本管理

而不是：

開發者或 AI 修改 YAML
        ↓
重新生成完整 Canvas App
        ↓
穩定同步回 Power Apps Studio

因此，當時即使已經能「看到原始碼」，也不等於已經具備成熟的外部程式碼開發能力。

三、PAC CLI 的 pack 和 unpack 也不是完整解法

Power Platform CLI 過去提供過以下命令：

pac canvas unpack
pac canvas pack

它們可以把 .msapp 拆成原始檔，再把原始檔重新封裝成 .msapp。

從理論上來說，開發者可以：

  1. 匯出 Canvas App
  2. 解包 .msapp
  3. 修改其中的檔案
  4. 重新打包
  5. 再匯入 Power Apps

但這條路一直存在不少限制：

  • 相關格式長期處於實驗或預覽狀態
  • 不同版本的 YAML 格式可能發生變化
  • 部分 App 資訊並不完全包含在可讀的 YAML 中
  • 修改後不一定能正常重新打包
  • 很容易產生 Studio 無法識別或無法載入的 App
  • 缺少與正在編輯中的 Power Apps Studio 即時同步的能力

目前 Microsoft 也已經把 pac canvas pack 和 pac canvas unpack 標記為非推奨，並建議使用新的 Git Integration 或其他正式工作流程。

所以它比較適合研究、版本比較或特殊自動化，而不是當作日常 Canvas App 開發的標準方式。

四、當時也不是完全沒有自動化

嚴格來說，2026 年年初並不是所有事情都必須從零開始手動完成。

當時已經存在：

  • Power Apps 內建 Copilot
  • 根據 Dataverse Table 生成基本 App
  • 從 Excel、SharePoint 等資料來源建立 App
  • 各種 Canvas App 範本
  • Power Platform CLI
  • PCF 自訂控制項
  • Power Platform Git Integration
  • 瀏覽器自動化工具

例如，pac canvas create 可以根據 Custom Connector 的 OpenAPI 定義生成一個 Canvas App。

但是它生成的是一套預先規定好的畫面、控制項配置和 Power Fx，用途主要是呼叫 Custom Connector 中定義的 Action。

它並不能讓開發者自由描述一個複雜業務系統，然後自動生成完全符合要求的多畫面 App。

因此，如果把問題限定為：

能不能像普通程式開發一樣，讓外部 AI 讀取、修改、驗證並同步任意 Canvas App？

那麼在 2026 年年初，答案基本還是：

不行，核心開發仍然需要在 Power Apps Studio 裡手動完成。

五、真正的轉折：2026 年 5 月的 Canvas Authoring MCP

2026 年 5 月，Microsoft 公開了使用 AI 程式碼生成工具建立和編輯 Canvas App 的預覽功能。

這次的變化不是單純在 Power Apps 裡增加一個聊天視窗，而是建立了一套新的外部開發流程。

目前的基本架構是：

自然語言需求
      ↓
Claude Code、GitHub Copilot CLI 等 AI 工具
      ↓
Canvas Apps Skills
      ↓
Canvas Authoring MCP Server
      ↓
生成和驗證 .pa.yaml
      ↓
Power Apps Studio Coauthoring Session
      ↓
Canvas App 畫面發生實際變更

這套流程第一次把以下能力連接在一起：

  • 讀取現有 Canvas App
  • 列出 Screen 和控制項
  • 查找可用的控制項類型
  • 發現 Dataverse Table、Connector 和 API
  • 生成新的 .pa.yaml
  • 修改既存 Screen
  • 編寫 Power Fx
  • 驗證生成的 YAML
  • 自動修正部分驗證錯誤
  • 透過共同編輯工作階段同步回 Power Apps Studio

這才是「AI 直接製作 Power Apps」真正成立的關鍵。

六、MCP 到底在這裡做了什麼？

MCP 的全稱是 Model Context Protocol。

可以把它理解成一套讓 AI 呼叫外部工具的標準協議。

沒有 MCP 時，AI 即使知道 Power Apps 是什麼，也只能提供建議或生成文字：

AI：
你可以新增一個 Button，
然後把 OnSelect 設定成 Filter(...)

它知道應該怎麼做，但沒有辦法直接碰你的 App。

有了 Canvas Authoring MCP Server 之後，AI 可以取得一組實際可呼叫的工具，例如：

  • 讀取目前 App 狀態
  • 取得可用控制項資訊
  • 尋找資料來源
  • 驗證 Canvas App YAML
  • 同步 Power Apps Studio 的共同編輯狀態

因此，AI 不再只是告訴你「應該怎麼操作」，而是可以實際執行操作。

可以用一句話概括：

MCP 為 AI 補上了可以操作 Power Apps 的眼睛和手。

七、Skills 和 MCP 並不是同一個東西

這套功能中還有一個容易混淆的概念：Skills。

Skills 更像是提供給 AI 的操作說明書，其中包含：

  • Canvas App 的正確工作流程
  • 控制項使用方式
  • 設計建議
  • YAML 格式要求
  • 驗證和同步步驟

而 MCP Server 則負責真正與 Power Apps 通信。

兩者的關係可以理解成：

組成部分 作用
AI 模型 理解需求並決定下一步
Skills 告訴 AI 應該按照什麼流程工作
MCP Server 向 AI 提供可以實際執行的 Power Apps 工具
Power Apps Studio 真正儲存、顯示和執行 Canvas App

簡單來說：

AI 負責思考
Skills 負責教學
MCP 負責動手
Power Apps 是被操作的對象

八、以前和現在的差別

時期 Canvas App 的主要開發方式
2026 年初以前 主要依靠 Power Apps Studio 手動拖拉控制項和編寫 Power Fx
2025 年 可以查看新版 .pa.yaml，但一般匯出的 YAML 主要是唯讀審查用途
舊 PAC CLI 時期 可以實驗性解包和重新打包 .msapp，但不適合作為穩定的日常開發方式
2026 年 5 月以後 AI 工具可以透過 Skills、MCP 和 Coauthoring 建立或修改 Canvas App
2026 年 7 月目前 功能已經相當強，但仍然屬於 Preview，需要人工檢查和測試

九、這對 Access 遷移項目意味著什麼？

對一般的小型 Canvas App 來說，手動製作十幾個控制項可能並不是大問題。

但是對 Access Application 遷移項目而言，情況完全不同。

Access 系統往往包含：

  • 大量 Form
  • 複雜的輸入控制
  • 固定尺寸的業務畫面
  • 大量 Label、TextBox 和 Button
  • 根據使用者角色切換的功能
  • 查詢、更新、CSV 和報表輸出
  • 大量 VBA 業務邏輯

如果全部依靠人工在 Power Apps Studio 裡重建，不但工作量巨大，而且很容易出現位置、名稱和公式不一致的問題。

新的 AI Authoring 工作流至少提供了一種可能性：

  1. 先分析 Access Form 和 VBA
  2. 把畫面需求整理成結構化規格
  3. 讓 AI 生成 Canvas App Screen 和控制項
  4. 透過 MCP 驗證 YAML
  5. 同步到 Power Apps Studio
  6. 由開發者測試和修正業務邏輯

它不一定能一次完成整個遷移，但可以大幅減少重複的畫面建立工作。

十、現在也不能把它當成完全成熟的自動開發工具

需要注意的是，截至 2026 年 7 月，這套 Canvas App AI 外部開發功能仍然是 Preview。

Microsoft 也明確提醒，Preview 功能不適合未經檢查直接投入正式環境。

AI 仍然可能：

  • 選錯 Dataverse Table 或 Column
  • 生成錯誤的 Power Fx
  • 改壞既存畫面配置
  • 錯誤理解業務需求
  • 生成可以通過語法驗證、但業務邏輯錯誤的 App
  • 在複雜控制項或資料來源上同步失敗

因此，實際使用時仍然應該：

  • 在開發環境中操作
  • 把 App 放入 Solution 管理
  • 使用 Git 或其他版本管理方式
  • 每次重大修改後立即測試
  • 人工檢查生成的 Power Fx 和 YAML
  • 不要讓 AI 直接修改正式環境中的唯一版本

總結

所以，對於「2026 年年初做 Power Apps，除了手動是不是幾乎沒有其他辦法」這個問題，答案是：

基本正確。

當時雖然已經存在 Copilot、YAML、PAC CLI、範本和資料驅動 App 生成等功能，但並沒有一套成熟、官方支援的方式，讓外部 AI 自由讀取、修改、驗證並同步一個既存 Canvas App。

真正的變化出現在 2026 年 5 月前後。

Canvas Apps Skills、Canvas Authoring MCP Server、.pa.yaml 和 Power Apps Studio Coauthoring 被連接到了一起，AI 才第一次獲得了比較完整的 Canvas App 外部開發能力。

因此，這不是一項一直存在卻很少有人知道的舊功能。

它確實是最近才出現的新能力，而且很可能會改變未來 Power Apps 的開發方式。

參考資料

※ Microsoft Learn 的 Preview 文件及功能可能隨時更新，本文內容以 2026 年 7 月公開資訊為準。

This article was last edited at