Algunas tareas pendientes

Ahora son las 0:00 del 4 de febrero de 2026.

He trabajado todo el día, en general ha sido un proceso de dejar que la IA trabaje mientras pienso. Estoy un poco cansado, lo continuaré mañana.

Hay algunas cosas que vale la pena hacer, las anoto.

1. Abrir nuestro sistema

¿Se puede diseñar de forma asimétrica los permisos dentro del host de Yuan, o los permisos para conectarse al host? Es decir, no todos los terminales que se conecten al host obtendrán los mismos permisos. Esto nos ayudaría a controlar mejor los permisos y, por lo tanto, a abrir mejor nuestros datos. Actualmente, debido a la falta de un mecanismo de permisos dentro del host, nos vemos obligados a cerrar temporalmente algunas fuentes de datos y no nos atrevemos a hacerlas públicas a la IA. En última instancia, esto afecta el progreso de los experimentos.

En concreto, ¿se pueden otorgar permisos de lectura de SQL? ¿Y permisos de escritura de SQL? A nivel de Método, ¿el acceso debería estar permitido por defecto o prohibido por defecto? ¿Y cómo se debería realizar la autorización? Todas estas cuestiones necesitan un buen diseño.

La ventaja es que podemos darle a Yuan CLI permisos más altos, permitiendo así que la IA trabaje mejor.

En el futuro, Yuan podría convertirse en una plataforma de fuentes de datos y ejecución de órdenes. Y las estrategias intermedias probablemente serán muy diversas. Por ahora, además de la plataforma de estrategias del sistema Kernel+Agent integrado en Yuan, está la plataforma de estrategias TimeLab desarrollada por Mage, y el repositorio de experimentos de "guerra prolongada" en el que he estado trabajando recientemente. Se basan en diferentes filosofías de diseño y pilas tecnológicas, y es probable que coexistan en el futuro. Sin embargo, todas estas plataformas de estrategias necesitan acceder a los datos y a las interfaces de ejecución de órdenes de Yuan.

Por lo tanto, cómo diseñar bien el sistema de permisos es un problema importante. Para abrir, primero hay que protegerse (tono Feng Hua).

2. Capacidad de capitalización de la IA

Recientemente, al usar algunas API intermediarias, he notado que utilizan el proyecto New API para la gestión de usuarios y la facturación. Esencialmente, están capitalizando sus pools de suscripción, vendiéndolos al por mayor y al por menor a los usuarios. Pero esta forma de venta, al no estar vinculada a un negocio específico, no permite vender a un precio alto. Aquí, el poder de negociación se cede al lado del negocio ascendente.

En cierto modo, esto es una capitalización de la API de IA, una forma primaria de capitalización de la IA. Construir productos de IA ascendentes puede aprovechar los activos de API subyacentes, facilitando el negocio ascendente, permitiendo a los usuarios no enfrentarse directamente a la complejidad de la configuración de la API, mejorando así la experiencia del usuario. ¡Suscripción directa al producto o pago por uso! Los usuarios solo se preocuparán por el producto combinado final, no por cómo se configuran las API subyacentes. Aquí hay otra capa de margen de beneficio.

Actualmente, la gestión de las API KEY sigue siendo una barrera para el usuario promedio. Muchos usuarios no entienden el concepto de API KEY, ni siquiera saben cómo solicitarla o gestionarla. Por lo tanto, los intermediarios en el negocio de la IA aún tienen una gran oportunidad. En realidad, es un problema de diferencia de conocimiento. Este tipo de beneficio es extremadamente escalable.

Por supuesto, creo que en el futuro, BYOK (Bring Your Own Key) será una tendencia. Los usuarios querrán usar sus propias API Key para evitar problemas de fuga de datos. Por otro lado, los usuarios también querrán comprar servicios de IA al precio de coste de la API, en lugar de pagar un margen al intermediario. En realidad, los intermediarios también realizan mucho ensamblaje de negocio, lo cual tiene valor. En el lado del negocio, BYOK puede ser una opción, pero en los próximos años, antes de que el concepto de API KEY esté completamente extendido, BYOK no será la corriente principal.

3. Mejora del sistema de usuarios

Supabase sigue siendo una buena opción, pero su sistema de usuarios aún tiene algunas deficiencias. Por ejemplo, no admite métodos de inicio de sesión sin contraseña como PassKey. Se me ocurre un esquema para que Supabase admita PassKey, que proviene de:

En una Edge Function, usar la identidad de administrador (service_role) para crear una sesión de Supabase para un usuario determinado, obtener el access_token / refresh_token y devolverlo al frontend.

• Supabase no tiene una API oficial para que un "administrador genere directamente una sesión para cualquier usuario".
• La práctica recomendada oficial: en el backend (Edge Function) usar la combinación auth.admin.generateLink + auth.verifyOtp para simular un flujo de inicio de sesión con magic link, obteniendo así el objeto de sesión de ese usuario (que contiene access_token / refresh_token, etc.).
• Este flujo se puede completar completamente dentro de la Edge Function, sin necesidad de enviar realmente un correo al usuario ni de que el usuario haga clic en un enlace.

Por lo tanto, podemos implementar completamente la funcionalidad de inicio de sesión con PassKey a través de una Edge Function. A partir de entonces, el sistema de usuarios basado en Supabase permitirá registrarse con correo electrónico, iniciar sesión con correo electrónico y también iniciar sesión con PassKey. Todo el proceso es sin contraseña, lo que mejora la experiencia del usuario. Sin embargo, PassKey es un método de interacción pesado, no es adecuado para usarlo en cada operación, solo es apropiado para el inicio de sesión inicial y para algunas operaciones importantes (como cambiar la contraseña, modificar el método de pago, etc.). Para mantener la sesión normalmente, basta con reutilizar el mecanismo de access_token / refresh_token de Supabase, el mecanismo JWT es muy útil.

4. Sistema de pagos

Un problema muy antiguo y real, ¿cómo hacer que los usuarios paguen? ¿Cómo recibir el dinero de forma legal en la cuenta de la empresa? ¿Cómo vincular un código QR para que el usuario escanee y pague, y el dinero llegue a la cuenta de la empresa? Todas estas cuestiones necesitan solución.

Tendremos varias soluciones, integrarnos con una plataforma de pagos quizás sea una buena opción. Hay que seguir el proceso, luego compartiré la experiencia.