AI 실수 파악 및 앱 확인

생성된 코드는 검토할 준비는 되었지만, 자동으로 출시할 준비가 된 것은 아닙니다. 이 마지막 단계에서는 그럴듯한 프레임워크 실수를 감지하고 컴파일 이외의 작업 집계를 확인하는 방법을 연습합니다.

어시스턴트를 의도적으로 테스트

이전 프롬프트의 제약 조건에 의존하지 않도록 도우미와 새 대화를 시작합니다. 물어:

Add a confirmation dialog before deleting a task from my Windows XAML app.
Show only the using directives and the dialog construction code.

제약이 없는 도우미는 다음을 반환할 수 있습니다.

using Windows.UI.Xaml.Controls;

var dialog = new ContentDialog
{
    Title = "Delete task?",
    PrimaryButtonText = "Delete",
    CloseButtonText = "Cancel"
};

UWP 네임스페이스입니다. ContentDialog 또한 WinUI 3에 존재하므로 코드 검토에서 오류를 쉽게 놓칠 수 있습니다.

이 프로젝트의 경우 네임스페이스는 다음이어야 합니다.

using Microsoft.UI.Xaml.Controls;

var dialog = new ContentDialog
{
    Title = "Delete task?",
    PrimaryButtonText = "Delete",
    CloseButtonText = "Cancel",
    XamlRoot = this.XamlRoot
};

WinUI 3 ContentDialog 참조 URL에는 microsoft.ui.xaml.controls. UWP ContentDialog 참조는 .를 사용합니다 windows.ui.xaml.controls.

이것이 "Windows 설명서에 있는 형식"만으로는 충분하지 않은 이유입니다. 프레임워크, 네임스페이스, 버전 및 앱 모델을 확인합니다.

생성된 코드에 대한 프레임워크 검사 사용

도우미가 Windows API를 추가하는 경우 다음 질문으로 검사합니다.

확인 확인할 사항
Framework WinUI 3 및 Windows 앱 SDK 대한 설명서인가요?
네임스페이스 UI 코드에서 Microsoft.UI.Xaml를 사용하고 Windows.UI.Xaml 또는 System.Windows는 사용하지 않나요?
버전 프로젝트에서 참조하는 Windows 앱 SDK 버전에서 API를 사용할 수 있나요?
앱 모델 API에 패키지 ID, 앱 기능 또는 창 초기화가 필요한가요?
스레드 처리 UI 스레드에서 호출을 실행해야 합니까? 비동기 작업이 기다리고 있나요?
사용자 경험 (UX) 시나리오에 대한 기본 제공 WinUI 컨트롤 또는 패턴이 있나요?
접근성 생성된 UI에 이름, 레이블, 키보드 액세스 및 표시되는 포커스가 있나요?
증거 변경된 경로를 빌드하고, 실행하고, 테스트해 보셨나요?

도우미에게 해당 선택을 지원하는 Learn URL을 제공하도록 요청한 다음 URL을 직접 엽니다.

작업 집계 확인

최종 확인 패스를 실행합니다.

  1. 앱의 로컬 데이터를 삭제하거나 새로 설치를 시작합니다. 빈 상태가 나타나는지, 그리고 공백만 입력했을 때도 작업 추가가 비활성화된 상태로 유지되는지 확인합니다.
  2. 여러 작업을 추가하고, 완료된 작업을 표시하고, 다른 작업을 삭제합니다. 나머지 개수 업데이트 및 올바른 항목이 제거되었는지 확인합니다.
  3. 앱을 다시 시작합니다. 작업 제목 및 완료 상태가 복원되는지 확인합니다.
  4. if (System.Diagnostics.Debugger.IsAttached) throw new IOException("Test save failure.");의 첫 번째 줄에 TaskStorage.SaveAsync를 추가하고, 다시 빌드한 다음 디버거에서 앱을 실행합니다. 저장을 실행한 다음 InfoBar이(가) 성공적으로 저장되었다고 보고하는 대신 실패를 보고하는지 확인합니다. 그런 다음, 임시 조건을 제거하고 다시 빌드합니다.
  5. Tab 및 Shift+Tab을 사용하여 모든 대화형 요소를 탐색합니다.
  6. Windows 화면 읽기 프로그램 또는 Accessibility Insights를 사용하여 이름, 역할 및 포커스 순서를 검사합니다.
  7. 앱 크기를 조정하고, 라이트, 다크 및 고대비 테마를 테스트하고, 컴파일러, XAML, 바인딩 또는 분석기 경고 없이 x64용으로 빌드합니다.

자세한 정보: 접근성 개요 및 접근성 테스트.

코드뿐만 아니라 프롬프트 구체화

확인에 실패하면 다음 프롬프트에 수정 사항과 이유를 모두 저장합니다.

The generated code used Windows.UI.Xaml.Controls, which is the UWP
namespace. This project is WinUI 3. Replace it with the corresponding
Microsoft.UI.Xaml API, verify the API in the Windows App SDK reference,
build the x64 project, and explain why the original namespace was wrong.

이렇게 하면 도우미에게 유용한 증거가 제공되고 프로젝트 경계가 강화됩니다. 수명이 긴 프로젝트의 경우 프레임워크, 패키징 모델, 대상 아키텍처 및 빌드 명령과 같은 안정적인 제약 조건을 코딩 도우미가 읽는 리포지토리 지침에 넣습니다.

다음 단계

작은 WinUI 3 앱을 빌드하고 다시 사용할 수 있는 워크플로를 연습했습니다.

요청 → 생성 → 빌드 → 검사 → 검증 → 개선

다음으로 계속:

  • Last updated on