¿Qué hace 知行交互规范 Intent UI?
Convierte los objetivos de negocio en decisiones de funcionalidad fundamentadas, reglas de operación y condiciones de aceptación observables. El nivel de proceso determina "cómo se avanza el trabajo y qué entregables se producen", el nivel de método limita "cómo piensa y se autoverifica la IA", el nivel de negocio determina "qué capacidades se necesitan", y el nivel de componentes determina "cómo se entienden y operan esas capacidades". Por defecto se utiliza el español, orientado a la colaboración entre producto, diseño, frontend y testing; no está vinculado a ningún framework ni requiere la instalación de la biblioteca de componentes de ningún proyecto de referencia.
Restricciones principales
- Primero determina la tarea del usuario, luego decide la página y los componentes. El hecho de que exista una tabla en la base de datos no significa que el usuario necesite una interfaz CRUD para esa tabla.
- Distingue entre "la línea base de interacción que todas las páginas relacionadas deben cumplir" y "las capacidades que solo deben proporcionarse cuando se cumplen ciertas condiciones de negocio". Cuando las condiciones son desconocidas, márcalas como pendientes de confirmación, no las des por omitibles.
- Las operaciones dependen del objeto de negocio, el estado actual, los permisos del usuario, las dependencias asociadas y el alcance del impacto. No te limites a escribir una lista estática de botones.
- Distingue entre desactivación de negocio, deshabilitación de control, solo lectura, eliminación, archivado, deshacer y reversión; mantén la coherencia en el nombre, el resultado y la forma de recuperación.
- Explica tanto lo que se proporciona como por qué se omite, y qué cambios desencadenarían una reevaluación. Cuando el usuario solicite simplificar, conserva la recuperación de errores y la retroalimentación de estado ya aplicadas.
- Consulta los patrones y criterios de selección de Cloudscape; la matriz de capacidades de negocio, la aprobación, la recuperación de tareas, etc., pertenecen a las reglas de extensión de backend de este Skill, no se hacen pasar por requisitos oficiales de Cloudscape.
- A nivel de componentes, verifica el teclado y el foco con la semántica nativa y los patrones APG correspondientes, y complementa la interacción con los principios de escenario de Carbon y Ant Design, y la experiencia de implementación de Radix y React Aria. No trates los valores predeterminados de una biblioteca como la norma para todos los componentes, ni afirmes que estos proyectos comparten un estándar unificado.
- No conviertas el orden de los botones, la cantidad de campos, el tamaño de las ventanas emergentes o los umbrales de tiempo de un producto en indicadores generales y estrictos. Respeta las especificaciones de producto existentes; en caso de conflicto, explica la compensación y el impacto en el usuario.
- No realices eliminaciones, desactivaciones, aprobaciones, exportaciones o cambios de permisos reales como parte de la redacción o revisión de especificaciones. Solo modifica el código correspondiente cuando el usuario solicite la implementación, siguiendo su alcance de autorización.
Selecciona el modo de trabajo según la solicitud
| Intención del usuario | Qué hacer | Tamaño del entregable |
|---|---|---|
| Crear una especificación general | Establecer reglas condicionales y ejemplos de escenarios, sin inventar un negocio específico | Especificación, matriz de capacidades, plantilla de aceptación |
| Diseñar un módulo específico | Derivar las capacidades necesarias del flujo de proceso conocido y los estados de los datos | Tabla de decisiones del módulo, contrato de interacción de la página, escenarios de aceptación |
| Diseñar o revisar el comportamiento de componentes de backend | Definir claramente la semántica del componente, el estado, el método de entrada y los límites de composición | Justificación de la selección del componente, contrato de comportamiento, aceptación de interacción necesaria |
| Revisar un backend existente | Identificar brechas contrastando con las páginas visibles, los requisitos o el código fuente | Problemas con evidencia, impacto, corrección mínima y aceptación |
| Refinar o aplicar un estilo de referencia de backend | Comparar páginas y código fuente, seleccionar la composición, los roles de token y los patrones de interacción según la tarea | Convención de estilo ejecutable, límites de adaptación, punto de aceptación |
| Implementar o corregir una interacción | Implementar el alcance ya definido dentro de la arquitectura existente | Cambios de código, verificación correspondiente, dependencias restantes |
Una solicitud de especificación no se convierte automáticamente en una modificación de código; una solicitud de revisión no reestructura automáticamente todo el backend. Para páginas simples, solo genera las decisiones y reglas necesarias.
Al iniciar cualquier tarea de diseño, sigue el Flujo de trabajo de diseño para determinar la profundidad del proceso, los criterios de avance de fase y la cadena de entregables; cuando la IA redacte la interfaz, impulse herramientas generativas o colabore con múltiples agentes, ejecute primero la Metodología de diseño de IA de autocalibración previa a la generación y protección contra modos de fallo.
Establecer el contexto de negocio
Prioriza la lectura de los requisitos, flujos de proceso, capturas de pantalla, páginas existentes y código fuente relevante proporcionados por el usuario. Solo revisa los materiales relacionados con la tarea. Distingue entre el comportamiento observado, los requisitos documentados y las suposiciones; una simple captura de pantalla no puede afirmar que los permisos de backend o la recuperación asíncrona ya estén implementados.
Extrae la información mínima que afecta la decisión:
- Quién realiza qué tarea dentro de qué alcance; cuáles son las entradas principales y los indicadores de finalización.
- Si los datos provienen del mantenimiento del usuario, la sincronización externa o la generación del sistema; qué campos o registros son variables.
- Por qué estados de negocio pasan los datos, qué transiciones de estado son válidas y quién puede desencadenarlas.
- A quién afecta la operación, si es reversible, qué dependencias asociadas tiene, y si hay tareas de larga duración o múltiples usuarios modificando al mismo tiempo.
- Cómo afectan a la interacción el volumen de datos, la frecuencia de uso, los dispositivos de trabajo y las especificaciones existentes.
Cuando falte contexto, primero proporciona una solución recortable para un "backend web genérico" y especifica las suposiciones. Solo haz preguntas sobre las brechas que cambiarían las decisiones clave; continúa procesando las partes no afectadas. Sin evidencia, no proporciones por defecto eliminación permanente, operaciones que excedan los permisos o un centro de tareas completo.
Seleccionar capacidades
Al definir o revisar el alcance funcional, lee Decisión de capacidades. Establece una matriz de capacidades para los módulos dentro del alcance, marcando cada elemento como:
- Requerido básico: La línea base que debe existir para que este tipo de interacción exista, por ejemplo, tener estados de carga y error reconocibles al cargar datos.
- Requerido condicional: Debe proporcionarse cuando se cumplan condiciones de negocio específicas; escribe las condiciones y la evidencia.
- Mejora opcional: Tiene beneficios pero no obstaculiza la tarea principal; se puede programar u omitir.
- No aplicable: No es relevante para el negocio actual o no está permitido; explica el motivo.
- Pendiente de confirmación: Evidencia insuficiente; este es un estado de decisión, no pretendas que ya se pueda omitir.
El alto costo de implementación no equivale a no aplicable; la falta de una interfaz no equivale a que la capacidad no sea necesaria. Registra por separado la necesidad del negocio y los requisitos previos de implementación.
Seleccionar reglas específicas
Lee según el alcance involucrado; no cargues todos los archivos de referencia por defecto:
| Contenido involucrado | Leer |
|---|---|
| Orquestación de la fase de diseño, divergencia y convergencia, cadena de entregables, especificaciones de diseño y traspaso | Flujo de trabajo de diseño |
| Interfaz generada por IA, degradación del contexto de diseño, protección contra modos de fallo, división del trabajo entre múltiples agentes | Metodología de diseño de IA |
| Navegación, panel de trabajo, listas, búsqueda, filtros, detalles, gráficos | Navegación y exploración de datos |
| Crear, editar, validar, desactivar/activar, eliminar/archivar, operaciones por lotes, importar/exportar | Operaciones y formularios |
| Excepciones de carga, permisos, multiinquilino, concurrencia, tareas asíncronas, aprobación/publicación, notificaciones, accesibilidad | Estados y flujos de proceso de negocio |
| Selección de componentes, lenguaje de estado, teclado, foco, superposiciones y composición de componentes | Lenguaje de diseño de interacción de componentes |
| Evaluación heurística, recorrido cognitivo, verificación de accesibilidad, medición de experiencia, QA de diseño | Métodos de evaluación de diseño |
| Gobierno del sistema de diseño, tokens de diseño, plantilla de documentación de componentes, auditoría de consistencia | Sistema de diseño y especificaciones de tokens |
| Refinar o aplicar estilos de referencia como NextLabs, LarkAgentX, paneles de trabajo de alta frecuencia, paneles de control de operaciones y pantallas de presentación complementarias | Estilo de interfaz de herramientas |
| Entregar especificaciones, informes de revisión, aceptación, recorridos de escenarios | Entrega y revisión |
| Hacer referencia a los patrones de negocio de Cloudscape | Origen de Cloudscape y límites de adaptación |
| Hacer referencia a las reglas de componentes de APG, Carbon, Ant Design, Radix o React Aria | Origen de componentes y manejo de diferencias |
| Hacer referencia a modelos de proceso, métodos de evaluación o fuentes de sistemas de diseño | Origen de procesos, evaluaciones y sistemas de diseño |
| Hacer referencia a la evidencia de los casos de NextLabs, LarkAgentX y los límites de verificación | Origen de estilos de interfaz de herramientas |
Para cada operación realmente proporcionada, escribe claramente: entrada y objeto de destino → estado y permisos aplicables → entrada o confirmación → durante la ejecución → resultado exitoso → fallo o resultado desconocido → ubicación de retorno y vía de recuperación. Los enlaces no aplicables se pueden omitir con una explicación; no impongas un cuadro de confirmación para simplemente ver los detalles.
Para objetos con ciclo de vida, proporciona reglas de "estado × operación × rol"; para tareas que abarcan varios pasos, explica cómo guardar, salir, reanudar y completar parcialmente. Cuando el flujo tenga ramas o muchos estados, usa tablas compactas o Mermaid; no dibujes diagramas para operaciones de un solo paso.
Cuando la solicitud involucre explícitamente el diseño, la revisión o la implementación de un componente específico, lee la parte relevante del lenguaje de diseño de interacción de componentes; no despliegues toda la lista de componentes solo para hacer concesiones de funcionalidad de negocio. La similitud en la apariencia de los componentes no equivale a un comportamiento idéntico; verifica especialmente menús y selectores, interruptores y casillas de verificación, información sobre herramientas y superposiciones de interacción, y tablas comunes contra cuadrículas de datos.
Revisión previa a la entrega
- ¿Las concesiones de funcionalidad se remontan a tareas o reglas de negocio? ¿Aparecen CRUD completos, paneles de control u operaciones por lotes sin justificación?
- ¿La misma operación sigue condiciones consistentes en listas, detalles, accesos directos y accesos por lotes?
- ¿Se distingue entre datos vacíos, sin coincidencias, error de carga, permisos insuficientes y datos caducados?
- ¿Se ha escrito erróneamente "solicitud recibida" como "completada", o "tiempo de espera agotado" como "fallo definitivo" permitiendo el envío duplicado?
- ¿Las operaciones de eliminación, desactivación, publicación, etc., tienen claro su alcance de impacto? ¿Existe realmente la capacidad de recuperación proporcionada?
- ¿Se pueden verificar el flujo principal, el fallo, los cambios de permiso o estado, el éxito parcial y el flujo de teclado aplicable?
- ¿La semántica del componente, el foco, la selección y los estados durante la ejecución son consistentes? ¿Las superposiciones anidadas, los envoltorios personalizados y los diferentes métodos de entrada rompen el comportamiento definido?
- ¿La salida declara la ruta del proceso seguida y el motivo para saltar fases? ¿La interfaz generada por IA incluye el resultado de la verificación de integridad del estado?
Al realizar referencias, enlaza a la página del patrón específico y distingue entre los patrones oficiales y tus propias sugerencias de negocio. Cuando no sea posible verificar en línea, utiliza el resumen integrado, indica la fecha de referencia y las partes que no se pudieron verificar, y no afirmes que es la versión más reciente.