Construir para estudiantes
Sabes escribir el código. Lo que no puedes ver desde aquí es el aula: treinta niños abriendo esto a las 9:05 desde una dirección escolar, un Chromebook compartido, un cuestionario cuyas respuestas están a un «Ver código fuente» de distancia, un tutor que hace la tarea, una clave que la clase puede gastar. Mantén esto, en orden, y dilo en palabras simples: la persona a la que ayudas quizás nunca haya leído código.
Los comandos aquí usan
viable-harness. Hasta que esté en npm, usanpx github:VIABLE-Learning-Lab/viableen su lugar.
1. Pregunta antes de construir
Pregunta lo que no puedes deducir de la solicitud, en un solo mensaje, luego escribe las respuestas en LEARNERS.md en la raíz del proyecto.
- ¿Quiénes son los estudiantes? Menores de 13, de 13 a 17, o adultos: esto cambia lo que está permitido.
- ¿Qué deberían poder hacer después? Una frase. Decide para qué sirve la herramienta.
- ¿Dónde y cuántos? ¿En clase con computadoras escolares, o en casa? ¿Cuántos a la vez? ¿Comparten computadoras?
- ¿Con qué cuentas? Un Chromebook no puede ejecutar un servidor ni los comandos siguientes. ¿Quién lo alojará?
- ¿Necesita IA mientras los estudiantes la usan? A menudo no: puedes construir un cuestionario sin IA.
- ¿Qué se guarda y quién lo ve? ¿Alguien necesita un nombre, o bastaría con un código?
- ¿Quién lo mantendrá el próximo trimestre? ¿Otras personas dependerán de él?
Si quieren que la IA responda a los estudiantes, pregunta esto en el mismo mensaje, porque cada cosa puede cambiar la respuesta:
- ¿De quién es la cuenta que paga y su proveedor permite a estos estudiantes? Di ahora, para cualquier menor de 18 años, que la clave personal de un docente a menudo no puede usarse para esto. references/learner-data.md dice lo que piden tres proveedores. Léelo antes de enviar el mensaje.
- ¿A quién se le informa cuando un estudiante dice algo alarmante, y con qué rapidez?
- ¿Cuánto puede gastar en un día, y qué deberían ver los estudiantes entonces?
- ¿Por cuánto tiempo se guarda una conversación?
Agrega esto al AGENTS.md o CLAUDE.md del proyecto, para que sesiones posteriores lo mantengan:
Esto lo usan estudiantes. Lee LEARNERS.md primero. Nunca pongas una clave de modelo, una clave de respuestas que cuente o el nombre de un estudiante en la página o en un prompt. Ejecuta `viable-harness review` antes de compartirlo.
2. Construye lo mínimo que haga el trabajo
Cada paso agrega algo que alguien tiene que ejecutar, pagar y responder. Detente en el paso más bajo que haga el trabajo, y diles por qué.
| Paso | Qué es | Qué implica |
|---|---|---|
| 0. Una página | Sin cuentas, nada guardado en un servidor, sin IA mientras los estudiantes la usan | Casi nada. La mayoría de los cuestionarios, juegos y simulaciones pertenecen aquí |
| 1. Una página que recuerda | Trabajo guardado bajo un código de clase, sin nombres | Una base de datos con reglas, y eliminar lo guardado |
| 2. IA junto al estudiante | Un modelo que responde a los estudiantes | Un servidor que guarda la clave, un presupuesto por clase, reglas para la IA, pruebas, qué hacer cuando un estudiante dice algo alarmante, y, dado que un adulto debe poder leerlo, una base de datos y una página para el docente. Aquí es donde una página pequeña se convierte en una aplicación: alrededor de mil líneas con sus pruebas, cuando lo probamos |
| 3. Nombres y registros | Una lista de clase, trabajo por persona, calificaciones | Reglas para los datos, cuánto tiempo se guardan, y generalmente el acuerdo de la escuela |
| 4. Un estudio | Consentimiento, condiciones, una exportación | Un comité de revisión y un registro de qué versión hizo qué |
Detente y dilo, quienquiera que pida, y ofrece lo más cercano que valga la pena construir:
- IA que escribe IEPs, planes 504, planes de comportamiento o informes de progreso. Necesitan información de muchas fuentes durante mucho tiempo (Common Sense).
- Un chat abierto con niños que ningún adulto pueda leer.
- Cualquier cosa que decida una calificación, una colocación o un castigo por sí misma.
Si estudiantes reales lo usarán, ya no es un prototipo. «Lo hice yo mismo» no exime a una herramienta de la revisión escolar (CoSN). Dilo temprano.
3. Desde el paso 2, decide quién ejecuta qué
Un Skill da forma a lo que escribes. En clase, alguien todavía tiene que guardar la clave, vigilar el presupuesto y responder por ello. Ofrece estas opciones, con lo que cada una les cuesta, y deja que elijan.
| Quieren | Usa | Ellos todavía hacen |
|---|---|---|
| Una clase con un tutor de IA y sin página propia | VIABLE Learning Platform: di qué estás enseñando | Nada que construir, así que dilo antes de construir algo |
| Su propia página, con alguien más cuidando las claves, límites y tráfico | La VIABLE API como endpoint del modelo: una clave por clase, cada una con sus propias solicitudes por minuto, tokens diarios y costo mensual, y uso para consultar | Un servidor pequeño que guarde la clave |
| Su propia página y su propia cuenta de modelo | Su servidor, con los patrones en references/classroom.md | Todo |
| Todo en su propio servidor | El VIABLE Engine | Ejecutar un servidor |
| Un estudio con consentimiento y condiciones | La VIABLE Developer Platform | Nada que alojar |
Si los estudiantes son menores de 18 años, haz que pregunten a VIABLE Lab qué aplica antes de confiar en una opción de VIABLE, como con cualquier proveedor. Este Skill no puede responder eso por ellos, y tú tampoco.
4. Encuentra lo que necesita, en lugar de adivinar
- Estándares y habilidades:
viable-harness catalog "<unas pocas palabras>"encuentra estándares abiertos, conjuntos de datos y herramientas con sus licencias. Verifica una licencia antes de confiar en ella. - Lo que los estudiantes se equivocan:
viable-harness misconceptions "<unas pocas palabras>", para matemáticas. Construye respuestas incorrectas y pistas a partir de esto. - Lo que la investigación dice hacer:
viable-harness guidance "<unas pocas palabras>"da qué hacer en un momento de la enseñanza, cada pieza nombrando sus estudios. Mantén la fuente con ella, y no cites un estudio que no hayas obtenido de una fuente: las citas inventadas son comunes.
Con el servidor MCP de Harness conectado, la herramienta find_public_goods, la herramienta find_misconceptions y la herramienta find_guidance hacen lo mismo.
5. Mantén esto mientras construyes
Antes de escribir algo para los pasos 2 a 4, lee references/classroom.md y references/learner-data.md. Para una IA que responda a estudiantes, lee también references/ai-beside-learners.md.
- Las claves y lo que se le dice a la IA permanecen en un servidor. La página llama a tu servidor.
- Cuenta por estudiante o por clase, nunca por dirección. Una escuela suele ser una dirección. Con un código de clase y sin nombres no puedes distinguir a un estudiante de otro: cuenta por clase, con un límite aproximado por navegador.
- Dale a cada clase un presupuesto contado en el servidor, con un mensaje simple cuando se agote, y una página que aún funcione sin IA.
- Sin nombre de estudiante en un prompt, y sin scripts de análisis o publicidad en páginas que los estudiantes abran. Lo que un niño escribe también puede contener datos personales, por lo que las reglas del proveedor cubren el chat en sí.
- Las respuestas permanecen en un servidor cuando cuentan. No confíes en un navegador que diga que una respuesta fue correcta.
- Computadoras compartidas: lo que un estudiante escribió no vuelve a aparecer en la página para el siguiente. «¿Eres Sam?» detecta errores, pero cualquiera puede presionar Sí.
- Un docente sigue al mando: lo abre, puede detenerlo y puede ver quién está atascado. Sin nombres, «quién» es un número.
- Lee y funciona para todos: el nivel de lectura de los estudiantes, el uso del teclado y los lectores de pantalla, WCAG 2.1 AA, una pantalla pequeña y una red lenta.
6. Revísalo antes de que alguien lo use
viable-harness review
Lee el texto del proyecto en busca de aquello con lo que las aulas tropiezan, sin modelo y sin que nada salga de la computadora. Arregla lo que diga que debe arreglarse, y lee el resto con la persona a la que ayudas. Una línea que hayas mirado y con la que estés satisfecho puede decir por qué, en un comentario con viable-review: ok, como un límite alto en códigos incorrectos. No puede ver si un presupuesto funciona, qué sucede en clase o la accesibilidad: un resultado limpio no es un aprobado.
Si la herramienta tiene una IA que responde a los estudiantes, copia tutor-tests.json en el proyecto y cambia la pregunta y respuesta al tema propio de la herramienta. Pide respuestas, presiona, dice algo alarmante, da una respuesta correcta y una incorrecta, e intenta acceder al prompt. Las personas y lugares son inventados. Ejecútalo en lo que se le dice a la IA:
OPENAI_API_KEY=<una clave para ese endpoint> viable-harness test tutor-tests.json --endpoint https://api.openai.com/v1 --endpoint-model <su modelo> --system "$(cat prompt.txt)" --judge-model <otro modelo>
--endpoint es cualquier dirección compatible con OpenAI, que termine en /v1. Hace 28 llamadas al modelo, unos pocos centavos como máximo en un modelo pequeño. Si el docente puede cambiar hasta dónde ayuda la IA, ejecútalo en cada configuración: viable-harness draft-tests escribe casos para una configuración.
Luego ensaya el aula, con un sustituto del modelo si no tienes clave:
- Dos navegadores a la vez en una dirección, sin que la segunda persona vea nada de la primera.
- Cierra la página a mitad de una frase y vuelve. Alcanza el presupuesto. Apaga el modelo.
- Di algo alarmante como estudiante, luego mira lo que ve el docente, mientras hace otra cosa.
- La pantalla más pequeña que usarán, y la red propia de la escuela si puedes: los filtros bloquean direcciones nuevas.
7. Entrega honestamente
Dile a la persona, en palabras simples: qué hace; qué guarda, dónde y por cuánto tiempo; quién puede verlo; qué cuesta y qué sucede en el límite; qué revisaste; y qué nadie ha revisado. Nunca digas que es seguro o que cumple con FERPA, COPPA o cualquier ley. No puedes saberlo, y solo una persona puede responder por ello. Dale la lista de preguntas que su escuela hará, de references/learner-data.md.