Inicio rápido: Uso del modo de plan para el diseño de bases de datos controladas por especificaciones

El modo Plan es una función de Visual Studio Code que permite a GitHub Copilot razonar sobre una solicitud sin realizar ningún cambio. Al diseñar una base de datos, el modo de planificación traduce un documento de requisitos del producto en lenguaje natural (PRD) en un modelo de datos fundamentado (tablas, relaciones, tablas de unión, dirección de las claves externas y restricciones) antes de escribir una sola instrucción CREATE TABLE. A continuación, debe entregar el plan al modo de agente o al Diseñador de esquemas para compilar el esquema real.

Tip

Use el modo de plan cuando necesite pensar antes de escribir lenguaje de definición de datos SQL (DDL), especialmente para esquemas de campo verde o refactorizaciones grandes. Para los cambios en una sola tabla, use en su lugar el modo Ask.

Conclusiones clave

El modo de plan genera un plan escrito (a menudo guardado como plan.md) que puede revisar antes de la ejecución.
El modo Plan reconoce el esquema cuando se usa junto con el participante de chat @mssql o cuando adjuntas archivos con #file:.
Emparejar el modo de plan con instrucciones personalizadas para que el plan herede automáticamente las convenciones de Transact-SQL (T-SQL).
El modo de plan es una característica de Visual Studio Code, no una específica de MSSQL, pero se adapta bien al diseño de la base de datos.

Prerequisites

Visual Studio Code con la extensión MSSQL instalada.
Una suscripción activa a GitHub Copilot con el modo Plan disponible en la lista desplegable del modo de chat.
Carpeta del área de trabajo donde puede crear un requirements.md archivo.
Opcional: una conexión de base de datos de destino para la transferencia en modo agente.
Opcional: un archivo de instrucciones personalizado para las convenciones de T-SQL.

¿Qué es el modo de planificación?

El modo de planificación es uno de los modos de chat de Visual Studio Code, junto con el modo de consulta, el modo de edición y el modo agente. En el modo de planificación, GitHub Copilot:

Lee la solicitud y cualquier contexto adjunto.
Genera un plan escrito que divide el trabajo en pasos razonados.
No modifica archivos ni ejecuta herramientas. El plan es un artefacto de pensamiento, no una ejecución.

A continuación, puede cambiar al modo de agente (o diseñador de esquemas) para ejecutar el plan. Para obtener documentación general, consulte Modos de chat en Visual Studio Code.

Por qué el modo de plan se ajusta al diseño de la base de datos

Decisiones compuestas del modelo de datos. Las tablas de unión, el sentido de las claves foráneas, las columnas de auditoría y las opciones de normalización son más fáciles de revisar en un plan en Markdown que en el DDL ya publicado. El modo plan le permite:

Valida el diseño antes de construirlo. Revisa el esquema propuesto, cuestiona las decisiones cuestionables e itera sobre el plan.
Exponer relaciones ocultas. El modo de planificación muestra tablas de unión y relaciones de muchos a muchos que no solicitó explícitamente.
Separe la especificación de la ejecución. El PRD permanece orientado al producto; el plan se convierte en el artefacto técnico; el DDL se convierte en el resultado.

Escenario integral: esquema de TaskManager

Este inicio rápido le guía a través de un flujo completo: PRD en lenguaje natural → plan en Markdown → tablas integradas en el Diseñador de esquemas.

Paso 1: Crear un documento de requisitos de producto

Cree requirements.md en la raíz de su espacio de trabajo. Describir la aplicación en lenguaje natural, incluidas las entidades de dominio, las relaciones y las reglas de negocio. Mantenga el documento centrado en el producto. No especifiques los tipos de columna ni las restricciones (para eso está tu archivo de instrucciones personalizadas).

# TaskManager - Product Specification

## Overview
A task management application for small development teams. Supports user
registration, role-based project membership, task tracking with multi-assignee
support, and team collaboration.

## User management
- Users register with email, username, first and last name, hashed password.
- Email and username must be unique across the system.
- Users can be deactivated (soft delete) rather than removed.
- A user can belong to multiple projects, each with a role: owner, admin, or member.

## Project management
- Projects have a name, description, and active/inactive status.
- Each project tracks who created it.
- Project membership is role-based - one entry per user per project.

## Task tracking
- Tasks belong to exactly one project.
- Required: title. Optional: description, due date.
- Status must be one of: todo, in-progress, done.
- Priority must be one of: low, medium, high, critical.
- Tasks can be assigned to multiple team members.

## Collaboration
- Team members can comment on tasks.
- Comments are text-based, tied to both a task and the author.

## Data integrity
- Every record must track when it was created and last updated.
- All relationships must enforce referential integrity.
- Deletes should be restricted (no orphan records).
- Status and priority fields must only accept valid values.

Paso 2: Cambia GitHub Copilot Chat al modo de planificación

Abra la vista Copilot Chat de GitHub.
En la lista desplegable del modo de chat, seleccione Plan.

Paso 3: Enviar el PRD al modo de plan

Adjunte requirements.md como contexto, ya sea arrastrando el archivo a la entrada de chat, usando #file:requirements.mdo seleccionando el botón adjuntar.

Based on the requirements document, think through the full data model:
identify all tables, relationships, junction tables, and constraints.
Save the plan so I can use it in the next step.

GitHub Copilot genera un plan razonado y lo guarda como plan.md en el área de trabajo. El plan normalmente incluye:

Una lista de tablas con su propósito
Relaciones (de uno a varios, de varios a varios) y las tablas de unión que las hacen posibles
Restricciones (de unicidad, de comprobación, clave foránea) que imponen las reglas de negocio del PRD
Preguntas abiertas o suposiciones en las que se basa el plan

Revise el plan antes de continuar. Si falta una relación o una restricción es incorrecta, repita el proceso enviando indicaciones de seguimiento en modo Plan. El modo de planificación no tiene estado y es económico, por lo que es normal realizar varias rondas de refinamiento.

Paso 4: Entregar el plan al modo de agente o al Diseñador de esquemas

Una vez que el plan se lea correctamente, cambie al modo de agente y compile el esquema.

En la lista desplegable modo de chat, seleccione Agente.
Envíe un mensaje que haga referencia al archivo de plan y a la superficie de destino:

Based on #file:plan.md, use Schema Designer to create all the tables
and relationships in my database. Focus on the database schema only -
skip any application layer items from the plan.

El modo de agente abre el Diseñador de esquemas y crea cada tabla, solicitando su aprobación en cada paso. Las instrucciones personalizadas se aplican automáticamente: la nomenclatura de columnas, las columnas de auditoría, la calificación de esquema y la nomenclatura de restricciones siguen todas las convenciones.

Tips

Emparejar con instrucciones personalizadas. El plan hereda automáticamente tus convenciones cuando tienes un archivo de instrucciones personalizadas para **/*.sql.
Mantenga el PRD centrado en el producto. Evite especificar tipos de columna o restricciones en requirements.md. Deja que el plan los complete según tus convenciones.
Iteración en el plan, no en el DDL. Es más barato revisar un plan de Markdown que quitar y volver a crear tablas.
Guarde el plan en el control de código fuente. El plan es una documentación valiosa para futuros colaboradores y para revisar las decisiones de diseño.
Usa diagramas Mermaid en el PRD. Los diagramas de entidad-relación en Mermaid ayudan al modo plan a extraer relaciones con precisión.

Para ayudarnos a refinar y mejorar GitHub Copilot para la extensión MSSQL, use la siguiente plantilla de problema de GitHub para enviar sus comentarios: Comentarios de GitHub Copilot

Al enviar comentarios, considere la posibilidad de incluir:

Escenarios probados: Háganos saber en qué áreas se ha centrado, por ejemplo, la creación de esquemas, la generación de consultas, la seguridad, la localización.
Lo que funcionó bien: describa las experiencias que se sintieron suaves, útiles o superaron sus expectativas.
Problemas o errores: incluya cualquier problema, incoherencias o comportamientos confusos. Las capturas de pantalla o las grabaciones de pantalla son especialmente útiles.
Sugerencias para mejorar: comparta ideas para mejorar la facilidad de uso, expandir la cobertura o mejorar las respuestas de GitHub Copilot.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-06-23