Antes, un usuario me preguntó cuál era mi proceso de desarrollo de IA. Justo hace unos días utilicé IA para implementar una pequeña función, y vale la pena presentarla como caso de muestra, o también como referencia.
Esta función nació porque alguien me dejó un mensaje en las Issues de GitHub (Figura 1) preguntándome si podía añadir al app de traducción y transcripción de subtítulos BaoCut la función de transcripción remota.
Es decir, tengo dos ordenadores: uno es un ordenador potente A con tarjeta gráfica NVIDIA; el otro, el B, es solo para trabajo diario. Quiero aprovechar la capacidad de cómputo del ordenador A, pero normalmente solo uso el ordenador B. Cuando utilizo BaoCut en el ordenador B para transcribir, lo que hace que consuma cómputo es la parte de transcripción; esa parte la puede realizar el ordenador A.
Me pareció una necesidad muy buena, pero no había hecho ese trabajo antes, y no sabía si era factible.
Por eso mi primer paso no fue empezar a escribir código de inmediato, sino hacer primero un análisis de viabilidad.
1. Análisis de viabilidad
No hacer un análisis de viabilidad y lanzarte a hacerlo a ciegas me ha hecho perder demasiado. Muchas veces terminas trabajando en vano. Además, incluso con un análisis de viabilidad, a veces puedes tomar decisiones equivocadas. Por ejemplo, hace unos días implementé un modelo de texto local que ayudaba a dividir y alinear; durante el análisis de viabilidad parecía que no había problema. Pero cuando lo probé en la práctica, el resultado era bastante malo. Al final lo cancelé, perdiendo varios días de trabajo y además gastando muchos tokens. ¡Menos mal que al menos solo fueron tokens!
El análisis de viabilidad normalmente tiene dos niveles:
Uno es desde la perspectiva de producto: si esta función aporta valor al usuario y si encaja con el posicionamiento del App.
El otro es desde el punto de vista técnico: si la función es viable tecnológicamente y si el costo es controlable.
Aquí, desde la perspectiva de producto, yo sentí que esta función sí aportaba valor a los usuarios y encajaba con el posicionamiento del producto, así que me enfoqué únicamente en el análisis de viabilidad técnica.
Entonces fui a Claude Code y le envié la necesidad original, para que, junto con la situación actual del proyecto, hiciera un análisis de viabilidad (Figura 2). Tras analizarlo, dio un veredicto: que era factible, y además propuso varias opciones (Figura 3).
Estas opciones pueden entenderse mejor si tienes un poco de base técnica. Luego de revisarlas, yo llegué a mis propias conclusiones:
La opción 0 y la opción C, aunque no requieren modificar código, para el usuario son demasiado poco amigables: tendría que idear cómo montar un servidor asr.
La opción A parece buena: con instalar la App, ya puedes iniciar tu propio servicio de transcripción.
La opción B no es amigable con Windows.
Por eso decidí avanzar con la opción A. Además, aunque la opción 0 no era muy fiable, dentro ofrecía una API HTTP de transcripción que también era una funcionalidad adicional interesante, que se podía añadir de paso.
2. Escribir el documento de diseño
Una vez confirmado que era viable, y además que ya había definido una opción técnica inicial, tampoco empecé a escribir código de inmediato: primero redacté el documento de diseño.
Este documento de diseño es más bien una mezcla entre un documento de diseño de producto y una propuesta de diseño técnico. Básicamente, describe con claridad los requisitos, el diseño de la arquitectura y una mezcla del documento de diseño de UI.
El objetivo es ayudar a que la IA organice y deje claro qué tecnologías se necesitarán para implementar, cuál es el estado actual del proyecto y registrar todo eso en un documento. Luego, durante la implementación, sirve como una buena referencia; y en el futuro, también puede servir para el mantenimiento. Lo más importante es que la persona pueda confirmar si la dirección es correcta (Referencia Figura 4).
Por supuesto, admito que aquí fui un poco perezoso: le pedí que lo terminara de escribir y ya puse manos a la obra. Principalmente porque las opciones que me habían dado antes no parecían tener grandes problemas, y también confiaba bastante en Fable. Si tienes condiciones, mejor mirarlo con más detalle.
3. Diseño de prototipo
La razón por la que antes de escribir código hice un prototipo es que, mediante el prototipo, puedes validar la necesidad con bajo costo y definir rápidamente el diseño de interfaz y las interacciones. En mi caso, ya tengo instalado el skill de baoyu-design (github.com/jimliu/baoyu-design), así que con solo indicar que es para prototipado, se activa automáticamente.
Mi App tiene una página de prototipo incluida, y cada vez que se agrega o modifica una función, primero se actualiza esa página de prototipo.
Con el documento de diseño anterior, el prototipo salió bastante fluido. La primera versión (Figura 5) ya tuvo un efecto bastante bueno: en la página de configuración se añadió una nueva pestaña, con la que puedes activar el servicio y ver los nodos.
Ten en cuenta que aquí el prototipo que hice en realidad fusiona prototipado y diseño de UI de alta precisión: el prototipo es el diseño de la UI. Este es uno de los grandes rasgos de Claude Design.
Una vez hecho el prototipo, aún hay que ajustarlo. En ese punto, la persona necesita dar retroalimentación basada en el resultado del prototipo para que el agente lo ajuste. Por ejemplo, aquí repetí muchos ajustes. (Referencia Figura 6)
Primero cambié el diseño a pestañas (Tabs), separando la activación del servicio y el acceso a otros nodos. Porque, en mi opinión, son dos escenarios diferentes. Además, añadí iconos para mostrar el estado del servicio, para que puedas saber claramente, solo mirando los iconos, si el servicio está iniciado o detenido. (Referencia Figura 7)
Luego descubrí que ponerlo dentro de la página de configuración no era conveniente para ver el estado del servicio, así que lo moví a la interfaz principal. Al final sentí que ya estaba bastante bien. (Figura 8, Figura 9)
4. Implementación
Si ya tienes el documento de diseño y también el prototipo (diseño de UI), entonces al pedirle a la IA que escriba el código, para los agentes actuales es una tarea bastante sencilla.
Normalmente, en ese momento, utilizo /goal para enviar junto con los documentos a Claude Code (Fable 5) para que lo implemente. Lo hará siguiendo los Milestones planificados en el documento, uno por uno, y además se tomará capturas para verificar el resultado. (Figura 10, Figura 11)
5. Verificación y pruebas
Aunque el agente nos ayude a verificar, eso no significa que podamos confiar completamente en los resultados de la IA. Después de eso, aún hay que probar manualmente varias veces, reportar los problemas que encuentres al agente, para que los ajuste (Figura 12).
Tras varias rondas de ajustes, ya casi estaba listo para usarse.
Mira el producto final (Figura 13, Figura 14).
¿Me preguntas si hice una revisión del código?
No. Me puse en el rol de QA, solo hice pruebas de caja negra. Aun así, confío en la capacidad de Fable.
Esta función nació porque alguien me dejó un mensaje en las Issues de GitHub (Figura 1) preguntándome si podía añadir al app de traducción y transcripción de subtítulos BaoCut la función de transcripción remota.
Es decir, tengo dos ordenadores: uno es un ordenador potente A con tarjeta gráfica NVIDIA; el otro, el B, es solo para trabajo diario. Quiero aprovechar la capacidad de cómputo del ordenador A, pero normalmente solo uso el ordenador B. Cuando utilizo BaoCut en el ordenador B para transcribir, lo que hace que consuma cómputo es la parte de transcripción; esa parte la puede realizar el ordenador A.
Me pareció una necesidad muy buena, pero no había hecho ese trabajo antes, y no sabía si era factible.
Por eso mi primer paso no fue empezar a escribir código de inmediato, sino hacer primero un análisis de viabilidad.
1. Análisis de viabilidad
No hacer un análisis de viabilidad y lanzarte a hacerlo a ciegas me ha hecho perder demasiado. Muchas veces terminas trabajando en vano. Además, incluso con un análisis de viabilidad, a veces puedes tomar decisiones equivocadas. Por ejemplo, hace unos días implementé un modelo de texto local que ayudaba a dividir y alinear; durante el análisis de viabilidad parecía que no había problema. Pero cuando lo probé en la práctica, el resultado era bastante malo. Al final lo cancelé, perdiendo varios días de trabajo y además gastando muchos tokens. ¡Menos mal que al menos solo fueron tokens!
El análisis de viabilidad normalmente tiene dos niveles:
Uno es desde la perspectiva de producto: si esta función aporta valor al usuario y si encaja con el posicionamiento del App.
El otro es desde el punto de vista técnico: si la función es viable tecnológicamente y si el costo es controlable.
Aquí, desde la perspectiva de producto, yo sentí que esta función sí aportaba valor a los usuarios y encajaba con el posicionamiento del producto, así que me enfoqué únicamente en el análisis de viabilidad técnica.
Entonces fui a Claude Code y le envié la necesidad original, para que, junto con la situación actual del proyecto, hiciera un análisis de viabilidad (Figura 2). Tras analizarlo, dio un veredicto: que era factible, y además propuso varias opciones (Figura 3).
Estas opciones pueden entenderse mejor si tienes un poco de base técnica. Luego de revisarlas, yo llegué a mis propias conclusiones:
La opción 0 y la opción C, aunque no requieren modificar código, para el usuario son demasiado poco amigables: tendría que idear cómo montar un servidor asr.
La opción A parece buena: con instalar la App, ya puedes iniciar tu propio servicio de transcripción.
La opción B no es amigable con Windows.
Por eso decidí avanzar con la opción A. Además, aunque la opción 0 no era muy fiable, dentro ofrecía una API HTTP de transcripción que también era una funcionalidad adicional interesante, que se podía añadir de paso.
2. Escribir el documento de diseño
Una vez confirmado que era viable, y además que ya había definido una opción técnica inicial, tampoco empecé a escribir código de inmediato: primero redacté el documento de diseño.
Este documento de diseño es más bien una mezcla entre un documento de diseño de producto y una propuesta de diseño técnico. Básicamente, describe con claridad los requisitos, el diseño de la arquitectura y una mezcla del documento de diseño de UI.
El objetivo es ayudar a que la IA organice y deje claro qué tecnologías se necesitarán para implementar, cuál es el estado actual del proyecto y registrar todo eso en un documento. Luego, durante la implementación, sirve como una buena referencia; y en el futuro, también puede servir para el mantenimiento. Lo más importante es que la persona pueda confirmar si la dirección es correcta (Referencia Figura 4).
Por supuesto, admito que aquí fui un poco perezoso: le pedí que lo terminara de escribir y ya puse manos a la obra. Principalmente porque las opciones que me habían dado antes no parecían tener grandes problemas, y también confiaba bastante en Fable. Si tienes condiciones, mejor mirarlo con más detalle.
3. Diseño de prototipo
La razón por la que antes de escribir código hice un prototipo es que, mediante el prototipo, puedes validar la necesidad con bajo costo y definir rápidamente el diseño de interfaz y las interacciones. En mi caso, ya tengo instalado el skill de baoyu-design (github.com/jimliu/baoyu-design), así que con solo indicar que es para prototipado, se activa automáticamente.
Mi App tiene una página de prototipo incluida, y cada vez que se agrega o modifica una función, primero se actualiza esa página de prototipo.
Con el documento de diseño anterior, el prototipo salió bastante fluido. La primera versión (Figura 5) ya tuvo un efecto bastante bueno: en la página de configuración se añadió una nueva pestaña, con la que puedes activar el servicio y ver los nodos.
Ten en cuenta que aquí el prototipo que hice en realidad fusiona prototipado y diseño de UI de alta precisión: el prototipo es el diseño de la UI. Este es uno de los grandes rasgos de Claude Design.
Una vez hecho el prototipo, aún hay que ajustarlo. En ese punto, la persona necesita dar retroalimentación basada en el resultado del prototipo para que el agente lo ajuste. Por ejemplo, aquí repetí muchos ajustes. (Referencia Figura 6)
Primero cambié el diseño a pestañas (Tabs), separando la activación del servicio y el acceso a otros nodos. Porque, en mi opinión, son dos escenarios diferentes. Además, añadí iconos para mostrar el estado del servicio, para que puedas saber claramente, solo mirando los iconos, si el servicio está iniciado o detenido. (Referencia Figura 7)
Luego descubrí que ponerlo dentro de la página de configuración no era conveniente para ver el estado del servicio, así que lo moví a la interfaz principal. Al final sentí que ya estaba bastante bien. (Figura 8, Figura 9)
4. Implementación
Si ya tienes el documento de diseño y también el prototipo (diseño de UI), entonces al pedirle a la IA que escriba el código, para los agentes actuales es una tarea bastante sencilla.
Normalmente, en ese momento, utilizo /goal para enviar junto con los documentos a Claude Code (Fable 5) para que lo implemente. Lo hará siguiendo los Milestones planificados en el documento, uno por uno, y además se tomará capturas para verificar el resultado. (Figura 10, Figura 11)
5. Verificación y pruebas
Aunque el agente nos ayude a verificar, eso no significa que podamos confiar completamente en los resultados de la IA. Después de eso, aún hay que probar manualmente varias veces, reportar los problemas que encuentres al agente, para que los ajuste (Figura 12).
Tras varias rondas de ajustes, ya casi estaba listo para usarse.
Mira el producto final (Figura 13, Figura 14).
¿Me preguntas si hice una revisión del código?
No. Me puse en el rol de QA, solo hice pruebas de caja negra. Aun así, confío en la capacidad de Fable.