지행 인터랙션 규범 Intent UI
비즈니스 목표를 근거 있는 기능 선택, 조작 규칙, 관찰 가능한 인수 조건으로 전환합니다. 프로세스 레이어는 "작업이 어떻게 진행되고 어떤 산출물이 나오는지"를 결정하고, 방법 레이어는 "AI가 어떻게 사고하고 자체 점검하는지"를 규정하며, 비즈니스 레이어는 "어떤 기능이 필요한지"를 결정하고, 컴포넌트 레이어는 "이러한 기능이 어떻게 이해되고 조작되는지"를 결정합니다. 기본 언어는 중국어이며, 제품, 디자인, 프론트엔드, 테스트팀 간 협업을 대상으로 합니다. 특정 프레임워크에 종속되지 않으며, 참조 프로젝트의 컴포넌트 라이브러리 설치가 필요하지 않습니다.
핵심 제약 조건
- 먼저 사용자 작업을 결정한 다음, 페이지와 컴포넌트를 결정합니다. 데이터베이스에 특정 테이블이 존재한다고 해서 사용자가 해당 테이블의 CRUD 인터페이스를 필요로 하는 것은 아닙니다.
- "모든 관련 페이지가 반드시 충족해야 하는 인터랙션 최소 요구사항"과 "특정 비즈니스 조건이 충족된 후에만 제공되어야 하는 기능"을 구분합니다. 조건을 알 수 없는 경우 "확인 필요"로 표시하고, 임의로 생략 가능한 것으로 간주하지 않습니다.
- 조작은 비즈니스 객체, 현재 상태, 사용자 권한, 연관 종속성 및 영향 범위에 따라 달라집니다. 단순한 정적 버튼 목록을 작성해서는 안 됩니다.
- 비즈니스 중단, 컨트롤 비활성화, 읽기 전용, 삭제, 아카이브, 되돌리기, 롤백을 구분합니다. 명칭, 결과, 복구 방법이 일관되어야 합니다.
- 무엇을 제공하는지뿐만 아니라, 왜 생략되었는지, 어떤 변화가 재평가를 촉발하는지도 설명합니다. 사용자가 간소화를 요청하더라도 이미 적용된 오류 복구 및 상태 피드백은 유지합니다.
- Cloudscape의 패턴과 선택 기준을 참조합니다. 비즈니스 기능 매트릭스, 승인, 작업 복구 등은 본 Skill의 백엔드 확장 규칙에 속하며, Cloudscape의 공식 요구사항으로 가장하지 않습니다.
- 컴포넌트 레이어는 네이티브 시맨틱과 해당 APG 패턴에 따라 키보드 및 포커스를 확인하고, Carbon, Ant Design의 시나리오 원칙과 Radix, React Aria의 구현 경험을 보충하여 인터랙션을 완성합니다. 라이브러리의 기본값을 모든 컴포넌트의 표준으로 간주하지 않으며, 이러한 프로젝트가 하나의 통일된 표준을 공유한다고 주장하지 않습니다.
- 특정 제품의 버튼 순서, 필드 개수, 팝업 크기 또는 시간 임계값을 범용 하드 지표로 만들지 않습니다. 기존 제품 규범을 존중하며, 충돌 발생 시 선택과 사용자 영향을 설명합니다.
- 규범 작성 또는 검토를 위해 실제 삭제, 중단, 승인, 내보내기 또는 권한 변경을 수행하지 않습니다. 사용자가 구현을 요청할 때만 해당 코드를 수정하며, 부여된 권한 범위를 따릅니다.
요청에 따른 작업 방식 선택
| 사용자 의도 | 수행 작업 | 산출물 규모 |
|---|---|---|
| 일반 규범 수립 | 조건 규칙 및 시나리오 예제를 생성하고, 구체적인 비즈니스를 허구로 만들지 않음 | 규범, 기능 매트릭스, 인수 템플릿 |
| 특정 모듈 설계 | 알려진 프로세스와 데이터 상태로부터 필요한 기능 도출 | 모듈 결정 테이블, 페이지 인터랙션 계약, 인수 시나리오 |
| 백엔드 컴포넌트 동작 설계 또는 검토 | 컴포넌트 시맨틱, 상태, 입력 방식 및 조합 경계 명확히 함 | 컴포넌트 선택 이유, 동작 계약, 필요한 인터랙션 인수 테스트 |
| 기존 백엔드 검토 | 보이는 페이지, 요구사항 또는 소스 코드를 기준으로 격차 식별 | 증거 기반 문제, 영향, 최소 수정 및 인수 조건 |
| 백엔드 참조 스타일 추출 또는 적용 | 페이지와 소스 코드를 대조하여 작업별로 구성, 토큰 역할 및 인터랙션 패턴 선택 | 실행 가능한 스타일 규칙, 적응 경계, 인수 포인트 |
| 인터랙션 구현 또는 수정 | 기존 아키텍처 내에서 결정된 범위 구현 | 코드 변경, 해당 검증, 남은 종속성 |
규범 요청은 자동으로 코드 리팩토링으로 확장되지 않습니다. 검토 요청은 자동으로 전체 백엔드를 리팩토링하지 않습니다. 간단한 페이지는 필요한 결정과 규칙만 출력합니다.
모든 설계 작업 시작 시 설계 워크플로우에 따라 프로세스 깊이, 단계별 진행 기준 및 산출물 체인을 결정합니다. AI가 인터페이스를 초안 작성하거나, 생성 도구를 구동하거나, 다중 에이전트가 협업할 때는 먼저 AI 설계 사고의 생성 전 자체 교정 및 실패 모드 보호를 실행합니다.
비즈니스 컨텍스트 수립
우선 사용자가 제공한 요구사항, 프로세스, 스크린샷, 기존 페이지 및 관련 소스 코드를 읽습니다. 작업과 관련된 자료만 확인합니다. 관찰된 동작, 문서 요구사항, 가정을 구분합니다. 스크린샷만으로 백엔드 권한 또는 비동기 복구가 구현되었다고 단정할 수 없습니다.
의사 결정에 영향을 미치는 최소 정보를 추출합니다.
- 누가, 어떤 범위 내에서, 어떤 작업을 완료하는지, 주요 진입점과 완료 표시는 무엇인지.
- 데이터가 사용자 유지, 외부 동기화 또는 시스템 생성인지, 어떤 필드나 레코드가 변경 가능한지.
- 데이터가 어떤 비즈니스 상태를 거치는지, 어떤 상태 전환이 유효한지, 누가 트리거할 수 있는지.
- 조작이 누구에게 영향을 미치는지, 되돌릴 수 있는지, 연관 종속성은 무엇인지, 장기 작업 또는 다중 사용자 동시 수정이 있는지.
- 데이터 규모, 사용 빈도, 작업 장치 및 기존 규범이 인터랙션에 어떤 제약을 가하는지.
컨텍스트가 부족한 경우 먼저 "일반 웹 백엔드"에 대한 사용자 정의 가능方案을 제공하고 가정을 명시합니다. 주요 결정을 변경할 격차에 대해서만 질문하고, 영향을 받지 않는 부분은 계속 처리합니다. 증거가 없는 경우 영구 삭제, 권한 초과 작업 또는 완전한 작업 센터를 기본으로 제공하지 않습니다.
기능 선택
기능 범위를 수립하거나 검토할 때 기능 판단을 읽습니다. 범위 내 모듈에 대한 기능 매트릭스를 생성하고, 각 항목을 다음으로 표시합니다.
- 기본 필수: 해당 유형의 인터랙션이 존재한다면 반드시 있어야 하는 최소 요구사항입니다. 예: 데이터 로드 시 식별 가능한 로딩 및 오류 상태.
- 조건부 필수: 특정 비즈니스 조건이 충족될 때 반드시 제공되어야 합니다. 조건과 증거를 작성합니다.
- 선택적 개선: 이점은 있지만 핵심 작업을 방해하지 않으며, 일정에 포함하거나 생략할 수 있습니다.
- 적용 불가: 현재 비즈니스와 무관하거나 허용되지 않습니다. 이유를 설명합니다.
- 확인 필요: 증거가 부족합니다. 이것은 결정 상태이며, 이미 생략할 수 있는 것처럼 가장하지 않습니다.
구현 비용이 높다고 해서 적용 불가능한 것은 아닙니다. 인터페이스가 없다고 해서 해당 기능이 필요하지 않은 것은 아닙니다. 비즈니스 필요성과 구현 전제 조건을 각각 기록합니다.
구체적인 규칙 선택
해당 범위에 따라 읽으며, 기본적으로 모든 참조 파일을 로드하지 않습니다.
| 관련 내용 | 읽을 파일 |
|---|---|
| 설계 단계 편성, 발산 수렴, 산출물 체인, 설계 사양 및 인계 | 설계 워크플로우 |
| AI 생성 UI, 설계 컨텍스트 저하, 실패 모드 보호, 다중 에이전트 분업 | AI 설계 사고 |
| 내비게이션, 워크벤치, 목록, 검색, 필터, 상세, 차트 | 내비게이션 및 데이터 브라우징 |
| 생성, 편집, 검증, 활성화/비활성화, 삭제/아카이브, 일괄 작업, 가져오기/내보내기 | 조작 및 폼 |
| 로딩 예외, 권한, 멀티테넌트, 동시성, 비동기 작업, 승인/발행, 알림, 접근성 | 상태 및 비즈니스 워크플로우 |
| 컴포넌트 선택, 상태 언어, 키보드, 포커스, 플로팅 레이어 및 컴포넌트 조합 | 컴포넌트 인터랙션 디자인 언어 |
| 휴리스틱 평가, 인지 도보, 접근성 인수, 경험 측정, 디자인 QA | 설계 평가 방법 |
| 디자인 시스템 거버넌스, design token, 컴포넌트 문서 템플릿, 일관성 감사 | 디자인 시스템 및 토큰 규범 |
| NextLabs, LarkAgentX 등 참조 스타일 추출 또는 적용, 고빈도 워크벤치, 운영 컨트롤 패널 및 관련 디스플레이 화면 | 도구형 UI 스타일 |
| 출력 규범, 검토 보고서, 인수 테스트, 시나리오 연습 | 전달 및 점검 |
| Cloudscape 비즈니스 패턴 인용 | Cloudscape 출처 및 적응 경계 |
| APG, Carbon, Ant Design, Radix 또는 React Aria의 컴포넌트 규칙 인용 | 컴포넌트 출처 및 차이점 처리 |
| 프로세스 모델, 평가 방법 또는 디자인 시스템 출처 인용 | 프로세스, 평가 및 디자인 시스템 출처 |
| NextLabs, LarkAgentX 사례 증거 및 검증 경계 인용 | 도구형 UI 스타일 출처 |
실제로 제공되는 각 조작에 대해 다음을 명확히 작성합니다. 진입점 및 대상 객체 → 적용 가능한 상태 및 권한 → 입력 또는 확인 → 실행 중 → 성공 결과 → 실패 또는 결과 불명 → 복귀 위치 및 복구 방법. 적용되지 않는 단계는 생략하고 이유를 설명할 수 있습니다. 상세 보기에 확인 대화상자를 강요하지 않습니다.
수명 주기가 있는 객체의 경우 "상태 × 조작 × 역할" 규칙을 제공합니다. 다단계 작업의 경우 저장, 나가기, 복구, 부분 완료를 설명합니다. 프로세스에 분기가 있거나 상태가 많은 경우 간결한 테이블 또는 Mermaid를 사용하며, 단일 단계 조작에 억지로 다이어그램을 그리지 않습니다.
요청이 특정 컴포넌트의 설계, 검토 또는 구현과 명시적으로 관련된 경우 컴포넌트 인터랙션 디자인 언어의 관련 부분을 읽습니다. 비즈니스 기능 선택만 하는 경우 전체 컴포넌트 목록을 펼치지 않습니다. 컴포넌트 외형이 유사하다고 해서 동작이 동일한 것은 아닙니다. 특히 메뉴와 선택기, 스위치와 체크박스, 툴팁과 인터랙티브 플로팅 레이어, 일반 테이블과 데이터 그리드를 확인하십시오.
전달 전 점검
- 기능 선택이 작업 또는 비즈니스 규칙으로 추적 가능한가? 근거 없는 전체 CRUD, 대시보드 또는 일괄 작업이 있는가?
- 동일한 조작이 목록, 상세, 바로가기 및 일괄 진입점에서 일관된 조건을 따르는가?
- 빈 데이터, 일치 결과 없음, 로드 실패, 권한 부족, 데이터 만료가 구분되는가?
- 요청 수락을 완료로 잘못 표기했거나, 타임아웃을 확정적 실패로 잘못 표기하여 중복 제출을 허용하지는 않았는가?
- 삭제, 중단, 발행 등의 조작에 대해 영향 범위가 명확하게 정의되었는가? 제공된 복구 기능이 실제로 존재하는가?
- 주요 흐름, 실패, 권한 또는 상태 변경, 부분 성공 및 적용 가능한 키보드 흐름을 인수 테스트할 수 있는가?
- 컴포넌트 시맨틱, 포커스, 선택 및 실행 중 상태가 일관된가? 중첩된 플로팅 레이어, 사용자 정의 래퍼 및 다양한 입력 방식이 기존 동작을 깨뜨리지 않는가?
- 출력물이 사용된 프로세스 경로와 건너뛴 단계의 이유를 명시하는가? AI가 생성한 UI에 상태 완전성 확인 결과가 첨부되었는가?
출력물에서 참조 시 특정 패턴 페이지에 링크하고, 공식 패턴과 자체 비즈니스 제안을 구분합니다. 온라인에서 확인할 수 없는 경우 내장 요약을 사용하고, 참조 날짜와 확인할 수 없는 부분을 명시하며, 최신 버전이라고 주장하지 않습니다.