AI 工具能大幅加速 Windows 應用程式的開發，但速度並不會減輕責任。 你的 AI 代理產生的程式碼就是你交付的程式碼，你對應用程式裡的一切負責，不管它是怎麼寫的。
本頁涵蓋兩個相關主題： 使用 AI 工具開發應用程式的負責任做法，以及 AI 生成程式碼特有的安全議題。
你擁有這段程式碼
當 AI 代理產生函式、版面或 API 呼叫時，當你提交的那一刻，它就成為你的程式碼。 無論程式碼是手寫還是產生，標準相同：
- 在接受前，閱讀並理解每一項變更
- 測試 AI 生成的程式碼至少和手寫程式碼一樣徹底——模型能產生看似合理的程式碼，但其實有微妙錯誤
- 不要用「AI 寫的」來解釋生產環境中的錯誤或安全問題
AI 工具並不能消除程式碼審查的需求。 他們改變的是你審查的內容，而不是你是否進行審查。
哪些內容不該寄給 AI 工具
請審慎決定要在提示和情境視窗中包含哪些內容：
- 秘密與憑證 — 切勿將 API 金鑰、密碼或連線字串貼入提示中。 即使在私人聊天會話中，提示中的憑證也可能存在安全風險，並可能出現在日誌中。 詳見下方的 憑證與秘密處理 。
- 客戶資料與個人識別資訊（PII） ——不要用真實的客戶姓名、電子郵件或使用資料作為範例輸入，即使是用來解釋錯誤也不要。 使用合成資料。
- 專有商業邏輯 — 在分享內部系統程式碼前，了解貴組織對可傳送給外部 AI 服務的原始碼政策。
輸入驗證
AI 傾向於產生寬鬆的輸入處理。 在依使用者輸入採取行動前，務必先驗證長度、類型與範圍。
- 切勿將原始
TextBox.Text值傳給 shell 指令、檔案路徑或資料庫查詢。 - 在寫入儲存或透過網路傳送前，先驗證字串長度。
- 對於檔案路徑使用允許清單（allow-list）方法——檢查已解析的路徑是否停留在預期的目錄內。
在你的提示中加入這句：「 為所有面向使用者的欄位新增輸入驗證與長度限制。」
認證憑證與密碼管理
絕對不要硬編碼 API 金鑰、密碼或連線字串。 AI 經常產生佔位字串 "your-api-key-here" ——請把它們當作錯誤來處理。
將憑證存放在
Windows.Security.Credentials.PasswordVault：var vault = new PasswordVault(); vault.Add(new PasswordCredential("MyApp", username, password));執行時擷取：
var credential = vault.Retrieve("MyApp", username); credential.RetrievePassword();在伺服器端或 CI 情境下，使用 environment variables 或 Azure Key Vault 來管理服務憑證。
封裝與相依完整性
在加入專案前，務必檢視 AI 代理建議的每一個 NuGet 套件。
- 請在
nuget.org 確認出版商——找藍盾（Microsoft）或知名出版社。 - 掃描已知漏洞：
dotnet list package --vulnerable - 偏好有最新更新且維護積極的套件。
應用程式的功能與權限
AI 產生 Package.appxmanifest 的檔案通常包含廣泛的功能。 檢視該 <Capabilities> 區塊，移除所有應用程式不需要的內容。
常見且需要留意的過於寬泛能力：
-
broadFileSystemAccess— 只有當你的應用程式真的能讀取任意檔案系統路徑時才需要 -
documentsLibrary— 需商店特別核准;除非必要，否則避免 -
userAccountInformation— 僅在你需要使用者的姓名或相片時
程式碼審查檢查清單
在發佈 AI 生成程式碼前，請先確認：
- 沒有硬編碼的秘密或憑證
- 使用者輸入在使用前已驗證
- 檔案路徑是否符合允許的目錄
- 清單中宣告的最低必要能力
- 掃描 NuGet 套件以尋找漏洞 （
dotnet list package --vulnerable） - 儲存在
PasswordVault的敏感資料，不是ApplicationData.LocalSettings - 所有網路通話皆使用 HTTPS
- 例外訊息不會向使用者揭露內部路徑或堆疊追蹤
AI 模型的知識過時
你今天使用的 AI 工具是根據有截止日期的資料訓練的。 對於 Windows 開發來說，這代表模型看到的 UWP 範例遠多於 WinUI 3 範例——這正是這個文件區塊存在的原因。
不要將 AI 的輸出內容視為權威依據：
- 目前的 API 名稱與命名空間（請依照 WinUI 3 API 參考驗證）
- 目前的 SDK 版本與套件名稱
- 商店政策與提交要求（經常變動）
- 安全指引（模型可能重現過時的密碼學或認證模式）
Microsoft Learn MCP server 以及 WinUI 代理插件透過讓代理依據最新文件，減少陳舊知識，但任何安全關鍵內容都必須以原始來源驗證。
Accessibility
AI 生成的使用者介面經常省略無障礙支援。 以數百萬筆 XAML 範例訓練而成的模型，會重現這些範例的平均品質——而這種平均品質歷來往往會忽略 AutomationProperties、鍵盤導覽，以及足夠的對比度。
接受 AI 生成的 XAML 或控制程式碼時：
- 檢查互動元素是否包含
AutomationProperties.AutomationId和AutomationProperties.Name - 確認焦點順序是否合乎邏輯——定位點應遵循閱讀順序
- 出貨前，請使用朗讀程式或其他螢幕閱讀器進行測試
- 使用 Accessibility Insights for Windows 工具自動發現漏洞
請明確問你的客服人員：「在這個 XAML 裡，為所有互動元素新增無障礙屬性。」 別以為事情已經完成了。
如果你的應用程式使用 AI 功能
如果你是在應用程式中內建 AI 功能—— 而不只是用 AI 來撰寫應用程式——那麼會有額外的責任。
對使用者保持透明。 告訴使用者：
- 你的應用程式會傳送給 AI 服務哪些資料
- AI 是否做出影響他們的決策
- 如果適當，如何選擇退出
對於重大行動，應讓人類持續參與決策流程。 不要讓 AI 自動刪除資料、購買、代使用者發送訊息，或在未經明確確認的情況下採取其他不可逆的行為。
測試偏差和非預期輸出。 AI 模型可能會產生帶有偏見、冒犯性或事實錯誤的輸出。 在發佈前，先用多樣化的輸入和邊緣案例測試你的應用程式 AI 功能。
使用內容安全工具。 如果您的應用程式使用 AI 生成或處理面向使用者的文字、圖片或其他內容，請使用 Azure AI 內容安全或類似的過濾功能，在有害輸出抵達使用者之前將其攔截。
授權與歸屬
AI 工具可能產生類似現有開源程式碼的程式碼。 在商業應用程式中使用 AI 生成程式碼之前：
- 了解貴組織對 AI 生成程式碼貢獻的政策
- 查看 Microsoft 關於 Copilot 和智慧財產權的指引
- 請對任何第三方程式碼套用與開源授權合規檢查相同的標準
Microsoft 的負責任 AI 原則
Microsoft 設計 AI 產品與功能時，遵循六大原則：公平、可靠性與安全、隱私與安全、包容性、透明度與問責制。
詳情請見 microsoft.com/ai/responsible-ai。
