Developer Tools on KnightLi Blog

Cómo elegir planes de AI Coding: los usuarios ligeros priorizan comodidad, los intensivos necesitan flexibilidad

Sun, 10 May 2026 08:20:58 +0800

Los planes de AI Coding han cambiado muy rápido en los últimos seis meses. Muchas herramientas han pasado de un modelo de cobro por mensajes o por uso limitado a uno claramente basado en consumo, los planes baratos y generosos se han ido recortando, y algunos servicios extranjeros han añadido verificaciones de identidad, restricciones regionales y reglas de uso más estrictas.

Para un desarrollador, la pregunta ya no es solo qué modelo es el más fuerte. También importa cuánto vas a gastar cada mes, si la cuota alcanza, si la herramienta resulta cómoda de usar y si podrás cambiar sin demasiado dolor cuando un proveedor suba precios o cambie las reglas de repente.

Una conclusión bastante útil es esta: los usuarios ligeros deberían comprar comodidad, los usuarios intermedios deberían comprar relación calidad-precio y los usuarios intensivos deberían comprar flexibilidad. Cuanto más intensivo sea el uso, menos conviene atar el modelo y la herramienta dentro del mismo plan.

Cuatro cosas que conviene revisar antes de elegir un plan

Antes, al elegir un plan de AI Coding, normalmente bastaba con mirar tres cosas:

Si el modelo era lo bastante fuerte.
Si la velocidad de respuesta era estable.
Si la cuota incluida alcanzaba.

Ahora hay que añadir una cuarta: si el modelo y la herramienta se pueden separar.

El modelo aporta la capacidad de razonamiento, mientras que la herramienta gestiona contexto, edición de archivos, orquestación de Agent y experiencia de flujo de trabajo. Ambas cosas importan, pero es mejor no dejarlas completamente atadas entre sí. Por ejemplo, si te gustan los modelos de Claude, puedes usar el plan oficial o conectar la API a otras herramientas. Y si te gusta un editor o entorno Agent concreto, es preferible que pueda conectarse a varios modelos en lugar de obligarte a usar solo el suyo.

La gracia de esto no es complicarse por gusto. Es reducir riesgos. AI Coding es uno de los segmentos que cambian más rápido. Un plan que hoy parece generoso puede cambiar de precio en dos meses, y una herramienta que hoy parece cómoda puede empeorar después de un cambio en la integración con modelos. Separar modelos y herramientas te deja margen de maniobra.

Los planes extranjeros se están endureciendo

Herramientas como GitHub Copilot, Cursor, Windsurf y Claude Code siguen siendo la base de trabajo de mucha gente, pero la tendencia es cada vez más clara: mantener planes muy baratos con cuotas muy altas es más difícil, y la facturación por uso real es cada vez más común.

Cuando servicios como GitHub Copilot se apoyan más en facturación por uso, el supuesto margen de ahorro de algunos planes cae bastante. Para usuarios ligeros siguen siendo cómodos, pero para quienes usan agentes, contexto largo y tareas complejas de código con mucha frecuencia, el consumo real empieza a parecerse mucho más al coste real de API.

Cursor y Windsurf, en esencia, empaquetan capacidad de modelo dentro de una experiencia de IDE. Su punto fuerte es que funcionan bien desde el primer momento y ofrecen una experiencia de editor madura. Su punto débil es el mayor nivel de dependencia de herramienta. Cuanto más dependas de sus agentes propietarios, sus índices y sus flujos automáticos, más caro será migrar después.

Claude Code sigue siendo atractivo tanto por experiencia como por atención del ecosistema, pero las suscripciones internacionales, la verificación de identidad, las restricciones regionales y la seguridad de los servicios intermedios son riesgos que los usuarios en China necesitan valorar con cuidado. En especial, los relays de terceros pueden mezclar modelos, ser inestables, exponer datos o desaparecer, así que no son una gran base a largo plazo para trabajo importante.

Ventajas y límites de los planes nacionales

Una ventaja de muchos planes nacionales de AI Coding es que suelen ofrecerse en forma de API, lo que hace que queden menos atados a una sola herramienta. Puedes conectarlos a OpenCode, Cline, Continue, tus propios scripts o agentes internos.

El problema también es evidente: si quieres al mismo tiempo un modelo fuerte, buena velocidad y bastante cuota, hay pocos planes que cumplan todo a la vez.

La familia GLM es fuerte dentro del panorama nacional, pero en horas punta el rendimiento puede volverse inestable y las tareas pesadas acaban limitadas por velocidad. Kimi tiene buen nivel, pero sus reglas de precio y cuota hay que seguirlas de cerca, sobre todo la transparencia del límite real. Modelos como MiniMax son más amables en velocidad y cuota, lo que los hace útiles para tareas ligeras del día a día, lotes y ayuda de código no demasiado compleja, aunque pueden quedar un escalón por debajo en razonamiento de ingeniería difícil. DeepSeek puede parecer muy rentable cuando un modelo nuevo está en precio promocional, pero al acabar la promoción toca reevaluarlo con tarifa normal.

Por eso, en muchos casos, las opciones nacionales funcionan mejor como un grupo de modelos disponible para repartir trabajo según la tarea, y no como una apuesta total por un solo modelo y un solo plan.

Usuarios ligeros: elige lo que resulte cómodo y no sobrediseñes

Si solo usas AI para retocar scripts, completar documentación, explicar errores o generar herramientas pequeñas una o dos veces por semana, probablemente no necesitas una configuración complicada.

En este caso importa más la comodidad. Cursor, Windsurf, Trae, CodeBuddy, Tongyi Lingma, GitHub Copilot y herramientas similares son opciones razonables. El objetivo no es perseguir el coste unitario más bajo, sino reducir fricción: algo estable dentro de tu editor, con buenas sugerencias y fácil de revertir cuando se equivoca.

Para usuarios ligeros, construir capas de API, relays y proxys complejos solo para ahorrar un poco de dinero rara vez compensa. El tiempo, el riesgo de cuenta y el coste de depuración suelen costar más que la suscripción que te ahorras.

Usuarios intermedios: mira la relación calidad-precio, pero también la portabilidad

Si usas AI todos los días para programar, modificar proyectos, generar pruebas y preparar documentación, la cuota y el consumo real empiezan a importar mucho más.

En este caso conviene separar la herramienta principal de los modelos de respaldo. Por ejemplo, un plan cómodo de IDE puede servir para el trabajo diario, mientras que una API o plan agregador conectable a varias herramientas puede encargarse de tareas con contexto más largo o flujos de Agent más complejos.

Aquí hay tres preguntas clave:

Si se puede integrar con herramientas de terceros.
Si el consumo de tokens o cuota es visible y entendible.
Si al superar el límite se aplica throttling, degradación, corte del servicio o pura facturación por uso.

Si un plan parece barato pero solo funciona dentro de su propia herramienta, conviene contar también el coste de migrar más adelante. Si cuesta algo más pero puede conectarse a varias herramientas, puede ser mejor como base a largo plazo.

Usuarios intensivos: no bloquees modelo y herramienta juntos

Para los usuarios intensivos, la necesidad principal es la flexibilidad.

Cuando una persona o un equipo usa agentes de AI de forma intensiva todos los días, el consumo crece muy rápido. Búsquedas de repositorio, cambios con contexto largo, depuración en múltiples rondas y reparación automática de pruebas pueden multiplicar el gasto en tokens. Si en ese punto dependes de un solo plan, aparecen tres problemas con facilidad:

La cuota deja de ser suficiente de repente.
La regla de cobro cambia de forma inesperada.
Una herramienta o un modelo deja de estar disponible temporalmente.

La opción más estable es montar una estructura por capas: una herramienta Agent principal, uno o varios endpoints de modelo intercambiables, un modelo barato para tareas simples y un modelo fuerte para tareas difíciles. No conviene mandar todas las tareas pequeñas al modelo más caro, ni depender solo del más barato para las tareas críticas.

Para un usuario intensivo, que las herramientas puedan conectarse a cualquier modelo y que los modelos puedan moverse entre herramientas importa más que ahorrar unas decenas de dólares al mes. Lo realmente caro no suele ser la suscripción. Lo caro es quedar atrapado en un solo ecosistema y tener que reconstruir el flujo de trabajo después.

Una estrategia de combinación más estable

Una forma razonablemente sólida de organizarlo sería esta:

Usa un modelo de bajo coste para tareas ligeras como explicar código, escribir scripts pequeños, formatear y generar documentos simples.
Usa un modelo orientado a valor para tareas intermedias como desarrollo normal de funciones, completar pruebas y sugerencias de refactorización.
Usa un modelo fuerte para tareas difíciles como cambios de arquitectura, correcciones entre varios archivos, bugs complejos y razonamiento con contexto largo.
Mantén abierta la capa de herramientas, eligiendo soluciones que puedan conectarse por API, exportar configuración y cambiar de modelo.
Conserva un camino de respaldo, de forma que si tu plan principal cambia reglas puedas moverte rápido a otra herramienta o modelo.

Puede que no sea la configuración más barata posible, pero sí una mucho más resistente. Los precios y cuotas de AI Coding van a seguir cambiando. Lo valioso a largo plazo no es un plan que hoy parezca muy generoso, sino un flujo de trabajo portable.

Resumen

Los planes de AI Coding no deberían juzgarse solo por el precio mensual. Los usuarios ligeros deberían priorizar simplicidad y comodidad. Los usuarios intermedios deberían fijarse en cuota, consumo y capacidad de migrar. Los usuarios intensivos deberían separar modelos y herramientas para no quedar atrapados en un único ecosistema.

La idea más importante es que los planes cambian, los modelos cambian y las herramientas también. Mantener la capacidad de elegir en tus propias manos es la forma más importante de controlar costes cuando trabajas con AI Coding a largo plazo.

Codex vs Claude Code: cómo elegir entre dos diseños de Subagent

Fri, 08 May 2026 14:14:01 +0800

Las herramientas de programación con IA están prestando cada vez más atención a los subagentes. No es simple moda: un solo agente acaba encontrando límites cuando debe manejar tareas reales de ingeniería.

Si un agente lee código, revisa logs, modifica implementación, ejecuta pruebas, analiza errores y resume resultados a la vez, el contexto principal se ensucia rápido. Resultados de búsqueda, salidas de comandos, logs de pruebas y razonamientos intermedios se mezclan. Las decisiones posteriores se vuelven menos fiables. Además, explorar, implementar, verificar y revisar en un único hilo dificulta el paralelismo.

El objetivo de los subagentes es reducir esa presión. La sesión principal deja de hacerlo todo de principio a fin y pasa a coordinar: define objetivos, asigna trabajo, recibe resultados y los integra. Un subagente se ocupa de una parte local, como exploración, implementación, verificación o revisión, y devuelve una conclusión comprimida.

Un subagente no es “otra copia de mí”. Es una forma de dividir trabajo de ingeniería confuso en roles más claros.

Fundamentos compartidos

Un sistema maduro de subagentes suele necesitar cuatro bases:

Aislamiento de contexto.
Especialización de roles.
Configuración a nivel de proyecto y usuario.
Límites de herramientas y permisos.

El aislamiento de contexto es esencial. En un repositorio real hay mucho material intermedio: búsquedas, logs de pruebas, salidas de comandos. Si todo entra en la sesión principal, el hilo principal se vuelve ruidoso. Un subagente puede digerir ese proceso local y devolver solo las señales útiles.

La especialización de roles también importa. Multi-agent no significa abrir varias copias del mismo modelo. Un rol de exploración debe buscar, leer y resumir. Un rol de implementación debe centrarse en cambios locales. Un rol de verificación debe ejecutar checks, identificar riesgos e informar con claridad.

Los límites de herramientas y permisos determinan si el sistema es seguro. Un subagente no debería heredar automáticamente todas las capacidades de la sesión principal. Un explorer de solo lectura no necesita escribir archivos. Un verifier no siempre necesita modificar implementación.

Codex y Claude Code comparten estas preocupaciones, pero toman caminos distintos.

Codex: delegación explícita

El diseño de Codex es más contenido.

Ofrece un mecanismo de delegación controlado y ligero alrededor de la sesión principal actual. Cuándo delegar, a quién delegar y cuándo recoger resultados son decisiones explícitas. El flujo de control permanece en la tarea actual.

Sus rasgos:

La sesión principal delega explícitamente.
El conjunto de roles se mantiene pequeño.
La sesión principal sabe qué agente hace qué.
Los resultados vuelven a la línea principal.
Los límites de colaboración son transparentes.

Esto encaja con equipos que valoran orquestación manual, previsibilidad y determinismo. Puedes pedir a un explorer que inspeccione una cadena de llamadas, a un worker que haga un cambio acotado y a la sesión principal que integre el resultado.

La contrapartida es que la presión de orquestación sigue en la sesión principal. Debe decidir cuándo dividir, cómo dividir, a quién asignar y cómo fusionar resultados. Para colaboración ligera es cómodo; para flujos largos puede cansar.

Claude Code: agentes como puestos de trabajo

Claude Code toma una ruta más de plataforma.

Trata los agentes como objetos describibles, seleccionables, configurables, con memoria, aislables y capaces de ejecutarse en segundo plano. Un subagente no es solo una ayuda temporal en una conversación; se parece más a un puesto de trabajo dentro de un sistema de ingeniería.

El sistema puede exponer listas de agentes, casos de uso, descripciones y límites de herramientas al modelo, permitiendo que el modelo decida qué rol usar en cada turno. Eso hace la delegación más automática.

Varios elementos definen este enfoque.

Primero, un sistema de roles. Explorer, planner, general-purpose y verifier pueden tener descripción de uso, restricciones de herramientas, modelos por defecto y condiciones de ejecución. Un explorer de solo lectura no edita archivos; un planner diseña; un verifier comprueba.

Segundo, herencia y override. Un subagente no es completamente libre. Hereda los límites grandes de la sesión principal, pero puede ajustar comportamiento local dentro de reglas permitidas.

Tercero, memoria. La memoria no es solo recordar algo. Puede tener alcance: memoria de usuario para preferencias largas, memoria de proyecto para contexto del repositorio y memoria local para estado del entorno.

Cuarto, background y worktree isolation. Algunas verificaciones pueden seguir en segundo plano mientras el hilo principal avanza. Si hace falta aislamiento fuerte, el agente puede trabajar en un worktree separado.

Quinto, ecosistema de plugins. Si los agentes son objetos de primera clase, hay que pensar en distribución, instalación, prioridades, overrides y seguridad. Los plugin agents pueden entrar al sistema, pero campos de alto riesgo como permission mode, hooks o MCP servers deben estar controlados.

Esto hace que Claude Code se parezca más a un runtime de agentes que a una herramienta de colaboración de una sola sesión.

Diferencia principal

Codex se parece a una herramienta de delegación controlada:

Delegación explícita.
Roles ligeros.
Flujo de control claro.
Subtareas centradas en la sesión actual.
Adecuado para trabajo humano-orquestado y determinista.

Claude Code se parece a un sistema de puestos de ingeniería:

Los agentes están modelados formalmente.
Los roles son más sistemáticos.
Memoria, background, aislamiento y plugins forman parte del runtime.
El modelo puede ayudar a elegir roles.
Adecuado para proyectos largos y workflows de plataforma.

La pregunta no es cuál tiene más funciones. Es si quieres que un subagente sea “un ayudante al que llamo explícitamente” o “un puesto permanente dentro del sistema”.

Cómo elegir

Elige el estilo Codex si valoras control explícito, delegación ligera y paralelismo seguro dentro de la sesión actual. Encaja con revisiones, cambios pequeños, tareas claras y flujos donde la persona quiere mantener el ritmo.

Elige el estilo Claude Code si necesitas roles sistemáticos, memoria a largo plazo, ejecución en segundo plano, aislamiento por worktree, plugins y un runtime más completo.

Hazte dos preguntas:

¿Aceptas que el modelo decida quién debe hacer el trabajo?
¿Necesitas un runtime de agentes más completo?

Si la primera te incomoda, la delegación explícita es mejor. Si la segunda es sí, un sistema tipo plataforma encaja mejor.

Consejos prácticos

No trates los subagentes como “más modelos igual a más potencia”.

Define límites de tarea para cada rol.
Limita las herramientas de cada rol.
Pide conclusiones, no logs crudos.
Mantén la decisión final en la sesión principal.
Haz visibles tareas en background y worktrees.
Define límites de seguridad para plugins.

El valor de los subagentes no está en la cantidad, sino en la calidad de la división del trabajo.

Resumen

Codex y Claude Code resuelven el mismo problema: un solo agente no puede cargar cómodamente con todo el trabajo real de ingeniería. Ambos reconocen la importancia de aislar contexto, especializar roles, definir permisos y resumir localmente.

Codex es más contenido y prioriza delegación explícita y control de la sesión principal. Claude Code es más sistemático y trata los agentes como puestos configurables, con memoria, aislamiento, background y ecosistema de plugins.

La elección no depende de qué marca gana, sino de si tu flujo necesita una herramienta de colaboración controlada o un runtime completo de agentes.

9Router: conecta Claude Code, Codex y Cursor a un mismo router de IA

Fri, 08 May 2026 13:41:15 +0800

9Router es un router local para herramientas de programación con IA. Permite conectar Claude Code, Codex, Cursor, Cline, Copilot, OpenCode, OpenClaw y herramientas similares a un único endpoint compatible con OpenAI, y desde ahí enrutar las solicitudes a distintos modelos y proveedores.

No pretende ser otro cliente de chat. Se coloca entre tus herramientas de programación y los proveedores de modelos para resolver problemas prácticos: formatos de API incompatibles, cambios manuales entre proveedores, consumo rápido de tokens por salidas de herramientas, cortes por cuotas agotadas y configuración complicada de varias cuentas.

Según el README, 9Router admite más de 40 proveedores y más de 100 modelos. Incluye RTK Token Saver, fallback automático, seguimiento de cuotas, rotación multi-cuenta, traducción de formatos y registros de solicitudes. Está escrito en JavaScript, usa Node.js, Next.js, React, Tailwind CSS y LowDB, y tiene licencia MIT.

Para qué sirve

9Router tiene más sentido cuando usas varias herramientas de programación con IA y varias fuentes de modelos al mismo tiempo.

Claude Code usa una cuenta de suscripción.
Codex o Cursor necesitan un endpoint OpenAI personalizado.
Cline, Continue o RooCode necesitan una API compatible con OpenAI.
Los proveedores gratuitos sirven para pruebas.
GLM, MiniMax o Kimi funcionan como respaldo barato.
Los modelos de mayor calidad se reservan para tareas difíciles.

Sin 9Router, cada herramienta necesita su propio endpoint, API key, nombre de modelo y estrategia de fallback. 9Router centraliza todo eso en una capa local.

API local:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

Instalación rápida

Para uso local:

1
2

npm install -g 9router
9router

Desde el código fuente:

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

Modo producción:

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

El paquete npm requiere Node.js >=18.0.0. En VPS o Docker, configura JWT_SECRET, INITIAL_PASSWORD, DATA_DIR y API_KEY_SECRET.

Conectar herramientas de programación

Configuración típica:

1
2
3

Base URL: http://localhost:20128/v1
API Key: copiada desde el dashboard de 9Router
Model: nombre de modelo o combo configurado en 9Router

Para Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Para Cline, Continue o RooCode, elige OpenAI Compatible:

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

Los nombres dependen de los proveedores conectados, por ejemplo cc/, cx/, gh/, glm/, minimax/, kr/ y vertex/.

RTK Token Saver

En programación con IA, muchas veces lo que más tokens consume son salidas de herramientas:

git diff
git status
grep
find
ls
tree
logs
listas largas de archivos

RTK Token Saver comprime esas salidas antes de enviarlas al modelo. El proyecto afirma que puede ahorrar 20%-40% de tokens de entrada en muchas solicitudes.

La ventaja es que no tienes que cambiar de herramienta ni de modelo. Aun así, para logs críticos o contenido completo de archivos, conviene probar primero que la calidad de respuesta no baje.

Fallback automático

Puedes ordenar modelos por prioridad:

1
2
3

1. Modelo de suscripción
2. API barata
3. Proveedor gratuito

Ejemplo:

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

El fallback reduce interrupciones, pero cambia la consistencia de salida. Para refactors grandes, migraciones o tareas sensibles, es mejor fijar un modelo principal.

Cuidado con proveedores gratuitos

Kiro, OpenCode Free y Vertex pueden ser útiles, pero sus reglas cambian. Verifica siempre si el uso es gratuito, si hay límites regionales, si se permite usar herramientas de terceros, si puede haber rate limits o bloqueos, y cuándo caduca la cuota.

9Router enruta solicitudes; no cambia las condiciones del proveedor.

Despliegue local

Para uso personal, basta con escuchar en localhost. Si lo llevas a un VPS o LAN, cambia la contraseña por defecto, configura JWT_SECRET y API_KEY_SECRET, no expongas el dashboard directamente, y exige Bearer API key en /v1/*.

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

Resumen

9Router es una puerta de enlace local para herramientas de programación con IA. Unifica Claude Code, Codex, Cursor y Cline en http://localhost:20128/v1, y gestiona selección de modelo, traducción de formatos, compresión de tokens, cuotas y fallback.

Es más útil para usuarios intensivos que ya alternan entre varios proveedores. Empieza con una herramienta y un proveedor, y añade combos poco a poco.

Referencias

goose: un agente de IA open source con escritorio, CLI y API

Fri, 08 May 2026 13:41:15 +0800

goose es un agente de IA open source que corre en tu propia máquina. No se limita a completar código; busca cubrir código, investigación, escritura, automatización, análisis de datos y otros trabajos. El README lo presenta como aplicación de escritorio, CLI y API para usuarios normales y flujos personalizados.

El proyecto pasó de block/goose a la Agentic AI Foundation (AAIF), dentro de Linux Foundation. El repositorio actual es:

`1`	`https://github.com/aaif-goose/goose`

goose está escrito principalmente en Rust y TypeScript, con licencia Apache-2.0. Su descripción en GitHub dice que es un agente de IA extensible que va más allá de sugerencias de código: puede instalar, ejecutar, editar y probar con cualquier LLM.

Qué problema resuelve

Muchas herramientas de programación con IA se centran en sugerencias o cambios locales. goose apunta a algo más amplio: permitir que un agente de IA complete tareas directamente en tu máquina.

Puede servir para:

Cambios de código y pruebas.
Automatización local.
Investigación y escritura.
Análisis de datos.
Flujos multi-paso.
Integración mediante API.
Extensión mediante MCP.

Si solo necesitas autocompletado en el IDE, una herramienta tipo Copilot puede bastar. goose es más útil cuando quieres IA dentro de la cadena local de ejecución de tareas.

Escritorio, CLI y API

La aplicación de escritorio soporta macOS, Linux y Windows.

La CLI encaja con flujos de terminal y automatización local.

La API permite insertar goose como runtime de agente en otros sistemas o herramientas internas.

Para uso personal, empieza por escritorio o CLI. Para equipos, conviene revisar también la API y las distribuciones personalizadas.

Instalación

Aplicación de escritorio:

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI:

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases ofrece builds para varias plataformas. La versión latest consultada fue v1.33.1, publicada el 2026-04-29, con assets para macOS, Linux, Windows, deb, rpm y Flatpak.

Después de instalar, configura un proveedor siguiendo el Quickstart oficial y prueba primero en un directorio de bajo riesgo.

Proveedores

goose admite más de 15 proveedores, entre ellos Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock y otros proveedores cloud o compatibles con OpenAI.

Puede usar API keys y también suscripciones existentes de Claude, ChatGPT o Gemini mediante ACP.

ACP es relevante porque muchos usuarios ya tienen suscripciones, pero no todas las herramientas las reutilizan bien. goose las integra en un flujo de agente. Aun así, verifica siempre términos del proveedor, cuotas y políticas para código corporativo o datos sensibles.

Extensiones MCP

goose soporta extensiones Model Context Protocol. El README menciona más de 70 extensiones.

MCP permite conectar el agente con documentación, bases de datos, navegadores, sistemas internos, búsqueda, herramientas de diseño o gestión de proyectos mediante interfaces estándar.

Para equipos, MCP puede ser una capa de integración más segura que exponer todos los sistemas directamente al modelo.

Diferencia frente a un asistente de código

goose no es solo autocompletado. Es más bien un runtime local de agente.

Los asistentes comunes se enfocan en completar, explicar, generar funciones y editar en el IDE. goose se centra en ejecución local de tareas, flujos multi-paso, proveedores intercambiables, extensiones, escritorio y CLI, API embebible y tareas que no son solo código.

Eso también implica más complejidad: configuración de modelos, permisos, extensiones, workspace, logs y credenciales.

Distribuciones personalizadas

CUSTOM_DISTROS.md explica cómo construir una distribución de goose con proveedores, extensiones y branding preconfigurados.

Un equipo puede predefinir proveedores permitidos, conectar servidores MCP internos, configurar seguridad y logs, bloquear servicios externos y aplicar onboarding propio.

Recomendaciones

Instala la app de escritorio o CLI.
Configura un proveedor conocido.
Ejecuta tareas simples en un directorio de prueba.
Observa qué archivos lee y qué acciones ejecuta.
Añade extensiones MCP.
Prueba repositorios complejos después.

Haz commit antes de cambios importantes, no guardes API keys en archivos del proyecto, limita los modos de alto permiso a workspaces confiables y revisa la política de datos antes de usar código de empresa.

Resumen

goose es un agente de IA open source bajo AAIF/Linux Foundation. Ofrece escritorio, CLI y API, soporta más de 15 proveedores, acceso a suscripciones vía ACP y más de 70 extensiones MCP.

Su valor no es solo escribir código, sino unir modelos, herramientas, extensiones y ejecución local dentro de un mismo marco de agente.

Referencias

Cómo cambiar el idioma de la interfaz de VS Code: chino, inglés y otros idiomas

Fri, 08 May 2026 13:18:57 +0800

VS Code admite muchos idiomas de interfaz. Lo habitual es instalar primero el paquete de idioma correspondiente y luego elegir el idioma de visualización desde la paleta de comandos. Si necesitas fijar VS Code a un idioma concreto, también puedes modificar manualmente el valor locale en argv.json.

Este método no solo sirve para chino simplificado; también funciona con inglés, chino tradicional, japonés, coreano, francés, alemán, español y otros idiomas.

Instalar el paquete de idioma correspondiente

Si quieres cambiar a una interfaz que no sea inglés, normalmente debes instalar primero un paquete de idioma.

Abre el panel de extensiones de VS Code en la barra lateral izquierda, o usa el atajo Ctrl+Shift+X.
En el cuadro de búsqueda, escribe el idioma objetivo, por ejemplo Chinese, Japanese, Korean o French.
Selecciona el paquete de idioma correspondiente y haz clic en Install.
Cuando termine la instalación, reinicia VS Code si se te solicita.

Para chino simplificado, el paquete habitual es Chinese (Simplified). Para chino tradicional, usa Chinese (Traditional).

Cambiar el idioma desde la paleta de comandos

Este es el método recomendado para la mayoría de los usuarios.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe Configure Display Language.
Selecciona el comando Configure Display Language.
Elige en la lista el idioma que quieres usar.
Reinicia VS Code si se te solicita.

Después del reinicio, los menús, las páginas de configuración y los mensajes habituales usarán el idioma seleccionado. Si el idioma objetivo no aparece en la lista, instala antes su paquete desde el panel de extensiones.

Especificar el idioma manualmente en argv.json

Si el cambio desde la paleta de comandos no funciona, o si quieres fijar explícitamente el idioma de visualización, puedes editar directamente el archivo de argumentos de ejecución de VS Code.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe y selecciona Preferences: Configure Runtime Arguments.
Busca o agrega la opción locale.
Cambia su valor por el código del idioma objetivo.
Guarda el archivo y reinicia VS Code.

Por ejemplo, para cambiar a inglés:

1
2
3

{
  "locale": "en"
}

Para cambiar a chino simplificado:

1
2
3

{
  "locale": "zh-cn"
}

Para cambiar a japonés:

1
2
3

{
  "locale": "ja"
}

argv.json es un archivo JSON, así que presta atención a las comas y las comillas. Si la configuración no es válida, VS Code puede no leer correctamente el idioma configurado.

Códigos de idioma de interfaz comunes

Idioma de visualización	locale
English (US)	`en`
Chino simplificado	`zh-cn`
Chino tradicional	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

Qué hacer si el idioma no cambia

Revisa estos puntos en orden:

Confirma que el paquete del idioma objetivo está instalado.
Confirma que locale usa el código correcto. Por ejemplo, chino simplificado es zh-cn, no zh-CN.
Cierra VS Code por completo y vuelve a abrirlo después de cambiar el idioma.
Si editaste argv.json manualmente, comprueba que la sintaxis JSON sea válida.
Si la configuración está desordenada, elimina la entrada locale y vuelve a elegir el idioma mediante Configure Display Language.

En la mayoría de los casos, Configure Display Language es la opción más sencilla. Edita argv.json solo cuando necesites forzar un idioma concreto o cuando el cambio desde la paleta de comandos no surta efecto.

Referencias

VScode: cambiar el idioma de la interfaz de VS Code a chino simplificado y alternar el idioma de visualización

24 consejos de Claude Code: modo plan, rewind, CLAUDE.md, Skills, Agents y plugins

Fri, 08 May 2026 08:54:14 +0800

Claude Code no es solo una caja de chat. Se parece más a un Agent de programación que puede entrar en un directorio de proyecto, leer y escribir archivos, ejecutar comandos y mantener contexto.

Si solo le das un requisito y esperas código, pronto aparecen problemas: el plan no queda claro, los permisos se repiten, el contexto crece, el resultado no convence, no sabes cómo volver atrás y no hay un lugar estable para reglas del proyecto.

Estos son consejos prácticos para quienes empiezan con Claude Code.

Empieza dentro del directorio del proyecto

Claude Code funciona mejor cuando se inicia dentro del directorio del proyecto, no desde una terminal cualquiera.

Crea una carpeta de proyecto, entra en ella, abre la línea de comandos e inicia Claude Code:

claude

Si al entrar por primera vez pregunta si confías en la carpeta actual, confirma antes de seguir. Así podrá leer archivos, crear archivos y ejecutar operaciones alrededor del proyecto.

Una práctica sencilla es pedirle que cree una web personal de fotógrafo. Es una tarea visual, permite inspeccionar el resultado y sirve para practicar generación de archivos, comandos, rewind y refactorización.

Usa modo plan para aclarar la dirección

Ante tareas complejas, Claude Code puede entrar en modo plan. Su función es discutir requisitos, dividir pasos y pedir aprobación antes de ejecutar.

Tras escribir un plan, suelen aparecer opciones como:

Aprobar el plan y permitir automáticamente herramientas de edición posteriores.
Aprobar el plan, pero pedir confirmación manual para futuras ediciones.
Pausar y seguir discutiendo el plan con Claude Code.

Si la tarea está clara, aprueba y continúa. Si no, pídele que complete el plan: estilo de página, stack técnico, estructura de carpetas, interacciones y criterios de aceptación.

El modo plan reduce retrabajo. Si el Agent empieza directamente, puede crear muchos archivos rápido; si la dirección era incorrecta, luego todo se vuelve más difícil de corregir.

Cambia de modo con Shift + Tab

En Claude Code, Shift + Tab permite cambiar entre modos de trabajo. Se usa a menudo para entrar en modo plan o para cambiar a un modo de aprobación automática de edición.

Hábitos recomendados:

Proyecto nuevo, función nueva o cambio grande: primero modo plan.
Cambio pequeño o arreglo claro: ejecutar directamente.
Borrado, reemplazos masivos o instalación de dependencias: mantener confirmación humana.

En modo plan, Claude Code puede preguntar detalles del proyecto. Usa flechas para elegir opciones y Enter para confirmar. Después de enviar feedback, actualizará el plan.

No abras todos los permisos

Cuando Claude Code ejecuta comandos, edita archivos o inicia programas, puede pedir permisos.

Opciones comunes:

Permitir solo esta vez.
Permitir el mismo tipo de comando en esta sesión.
Rechazar o pausar.

Para abrir una página local, iniciar un servidor de desarrollo o revisar archivos, aprueba según necesidad. Pero no uses durante mucho tiempo un modo de “permitir todo” solo por comodidad.

La aprobación total automática solo tiene sentido en tareas de bajo riesgo, muy claras y con respaldo Git. En el uso diario, conserva confirmación humana para borrar, sobrescribir carpetas, instalar dependencias, usar red, hacer commits o ejecutar scripts.

Ejecuta comandos locales en modo terminal

Claude Code puede entrar en modo de comandos de terminal y ejecutar comandos locales.

Por ejemplo, después de generar una página, puedes abrir un archivo HTML con:

`1`	`start index.html`

start es un comando de Windows para abrir archivos. Es más rápido que buscar el archivo manualmente.

El modo terminal sirve para:

Abrir páginas generadas.
Ver contenido de directorios.
Iniciar servidores locales.
Ejecutar pruebas o builds.

Pero los comandos de alto riesgo siguen requiriendo cuidado: borrado recursivo, mover directorios, sobrescrituras masivas y cambios de entorno.

Usa rewind cuando el resultado se desvía

Si la página o el código que hizo Claude Code no es lo que quieres y cada corrección lo empeora, usa rewind temprano.

Rewind puede devolver conversación o código a un punto anterior. Opciones comunes:

Revertir código y conversación.
Revertir solo conversación.
Revertir solo código.
Comprimir contenido anterior como resumen.
Cancelar.

Cuando la dirección se desvió claramente, conviene volver código y conversación juntos. Así contexto y archivos regresan a un estado más limpio.

Ten en cuenta que el rewind de Claude Code normalmente cubre archivos creados o modificados con herramientas internas. Archivos creados por comandos externos quizá no se reviertan por completo. Para proyectos importantes, usa Git.

Escribe prompts largos en un editor

No metas requisitos complejos en una sola línea.

Si el sistema permite editar un prompt largo en un editor, úsalo, guarda y luego envíalo a Claude Code.

Un prompt largo debería aclarar:

Objetivo.
Stack técnico.
Qué no debe hacerse.
Qué archivos deben conservarse.
Cómo verificar el resultado.
Criterios de aceptación.

Por ejemplo, si quieres refactorizar una página HTML a un stack más moderno, no escribas solo “refactoriza”. Explica estructura por componentes, preservación visual, diseño responsive y pide ejecutar una comprobación de build.

Recupera sesiones después de salir

Si necesitas salir de Claude Code, hazlo normalmente. Luego vuelve al mismo directorio y arranca otra vez:

claude

Si el historial anterior no aparece, usa comandos de historial para ver sesiones recientes y cargar la sesión anterior.

Esto sirve para continuar trabajo interrumpido. Pero no uses el historial como única memoria. Reglas del proyecto, stack, comandos comunes y notas deben estar en archivos del proyecto.

Guarda reglas del proyecto en CLAUDE.md

CLAUDE.md es un archivo de memoria importante para Claude Code. Normalmente está en la raíz del proyecto y registra reglas, stack, estructura de carpetas y restricciones de colaboración.

Puedes inicializarlo con:

/init

CLAUDE.md sirve para registrar:

Objetivos del proyecto.
Stack técnico.
Comandos de inicio, prueba y build.
Estructura de directorios.
Estilo de código.
Acciones prohibidas.
Reglas de commit y despliegue.

En cada conversación, Claude Code puede usar estas reglas como parte del contexto. Piensa en él como un manual del proyecto.

Una prueba sencilla es añadir una regla evidente en CLAUDE.md y luego preguntar algo. Si la respuesta sigue la regla, leyó la memoria del proyecto.

Usa @ para referenciar archivos

En el cuadro de entrada, @ permite seleccionar archivos o Agents y añadirlos al contexto actual.

Sirve para:

Hacer que Claude Code lea un archivo de configuración.
Pedir cambios en una página concreta.
Continuar según CLAUDE.md u otro documento.
Decir explícitamente “mira solo este archivo, no adivines la estructura”.

Comparado con pegar el contenido del archivo, @ es más claro y menos propenso a omisiones.

Revisa y comprime contexto

Tras una conversación larga, el contexto crece. Si se vuelve demasiado largo, el modelo puede ralentizarse o ignorar detalles antiguos.

Usa:

`1`	`/context`

Si el contexto ya es largo, comprime el historial:

`1`	`/compact`

Si aun así el efecto es malo, limpia el contexto actual:

/clear

Después de limpiar, Claude Code todavía puede entender parte del proyecto mediante archivos, CLAUDE.md y el directorio actual, pero no conserva todo el historial de conversación.

Una regla útil: abre una conversación nueva al terminar una tarea, escribe reglas del proyecto en CLAUDE.md, y no acumules discusión temporal para siempre en un solo chat.

Skills: convierte flujos fijos en instrucciones

Skills son instrucciones reutilizables para Claude Code. No son prompts de una sola vez, sino flujos de tarea empaquetados.

Por ejemplo, si generas informes semanales a menudo, crea una Skill de informe semanal con:

Información de entrada necesaria.
Formato de salida.
Tono y estructura.
Qué debe conservarse.
Qué no debe inventarse.

Las Skills suelen contener name, description e instrucciones detalladas. Al instalarlas en el directorio global de Skills, Claude Code puede reconocerlas y cargarlas cuando la tarea encaja.

Candidatos adecuados:

Informes semanales.
Plantillas de revisión de código.
Organización de documentos.
Procesamiento de imágenes por lotes.
Artículos con formato fijo.
Flujos de inicialización de proyectos.

Si copias el mismo prompt muchas veces, conviértelo en Skill.

Agents: delega subtareas a asistentes independientes

Agents no son lo mismo que Skills.

Una Skill es un manual de instrucciones. Un Agent se parece más a un asistente independiente que trabaja fuera de la conversación principal y devuelve resultados.

Su valor está en aislar contexto. Para una revisión de código, puedes crear un Agent de solo lectura que lea el proyecto y entregue un informe sin modificar archivos. Así no contamina la conversación principal y reduce riesgos.

Al crear un Agent, considera:

Si será de proyecto o de usuario.
Si Claude Code debe generar la configuración.
Qué herramientas puede usar.
Qué modelo usará.
Si guardará memoria.
Si el prompt del Agent es claro.

Para Agents de auditoría de código, da solo permisos de lectura. Primero que entregue un informe; luego la conversación principal decide si cambia código.

Plugins: empaqueta Skills, Agents, MCP y Hooks

Los plugins son paquetes de capacidad más completos. Pueden incluir:

Skills
Agents
MCP
Hooks

Frente a una Skill aislada, un plugin sirve mejor para capacidades de conjunto. Un plugin de diseño frontend puede empaquetar estética de página, reglas de layout, hábitos de componentes y Agents relacionados.

Al instalar plugins, suele haber opciones:

Directorio de usuario, efectivo para todos los proyectos.
Directorio de proyecto, compartido con el proyecto.
Directorio local del proyecto, solo efectivo en tu ordenador.

Para capacidades personales frecuentes, usa el directorio de usuario. Para acuerdos de equipo, usa el proyecto. Para pruebas temporales, usa instalación local.

Los plugins mejoran tareas concretas

En generación de páginas frontend, un plugin suele ser más estable que un prompt desnudo.

Por ejemplo, para “crear una web personal de fotógrafo”, un prompt normal puede crear una página aceptable. Si usas explícitamente un plugin de diseño frontend, la estructura, jerarquía visual, espaciado, color y acabado suelen mejorar.

Esto no reemplaza el criterio humano. Lo razonable es dejar que el plugin genere un primer borrador mejor y luego ajustar detalles manualmente.

Un flujo de trabajo más estable

Combinando todo lo anterior, queda un flujo más estable:

Inicia claude dentro del directorio del proyecto.
Discute requisitos primero en modo plan.
Confirma stack y criterios de aceptación antes de aprobar.
Mantén confirmación manual para acciones de alto riesgo.
Usa modo terminal para previsualización y pruebas.
Usa rewind cuando el resultado se desvíe.
Escribe reglas en CLAUDE.md.
Revisa y comprime contexto en conversaciones largas.
Convierte flujos repetidos en Skills.
Delega inspección, investigación y análisis a Agents de solo lectura.
Usa plugins para tareas de dominio específico.
Mantén puntos de commit Git en proyectos importantes.

Así Claude Code será mucho más estable que enviar una frase y esperar generación.

Resumen

La eficiencia de Claude Code no viene solo del modelo, sino también del control del flujo.

El modo plan define la dirección, los permisos controlan el riesgo, rewind reduce retrabajo, CLAUDE.md guarda reglas del proyecto, /context, /compact y /clear gestionan contexto, Skills reutilizan flujos, Agents aíslan subtareas y plugins empaquetan capacidades completas.

La mejor forma de usar Claude Code es dejar que avance dentro de límites claros, no entregarle todo el proyecto de una vez.

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Guía de instalación de uv: cómo elegir entre macOS, Linux, Windows, pipx, Homebrew y WinGet

Thu, 07 May 2026 23:23:58 +0800

uv es un gestor de toolchain de Python creado por Astral. Sirve para gestionar versiones de Python, entornos virtuales, dependencias, scripts, proyectos y herramientas. Tiene muchas formas de instalación. La documentación oficial ofrece instaladores independientes y también admite PyPI, Homebrew, WinGet, Scoop, Docker, GitHub Releases y Cargo.

Si solo quieres instalarlo rápido, da prioridad al instalador independiente oficial. Si prefieres mantener la versión mediante el gestor de paquetes del sistema, usa Homebrew, WinGet o Scoop. Si ya acostumbras instalar herramientas de Python en entornos aislados, puedes usar pipx.

Elección rápida

Escenario	Método recomendado	Comando
Instalación rápida en macOS / Linux	Instalador independiente oficial	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux sin curl	Script oficial + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Instalación rápida en Windows	Instalador de PowerShell	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Instalación aislada de herramientas Python	pipx	`pipx install uv`
Instalación temporal o tradicional de Python	pip	`pip install uv`
Gestión de paquetes en macOS	Homebrew	`brew install uv`
Usuarios de MacPorts en macOS	MacPorts	`sudo port install uv`
Gestión de paquetes en Windows	WinGet	`winget install --id=astral-sh.uv -e`
Usuarios de Scoop en Windows	Scoop	`scoop install main/uv`
Usuarios de Rust	Cargo	`cargo install --locked uv`

Las opciones generales más recomendables son:

macOS / Linux: instalador independiente oficial;
Windows: instalador oficial de PowerShell o WinGet;
si ya gestionas herramientas CLI de Python con pipx: pipx install uv.

macOS y Linux: instalador oficial

El método oficial más directo consiste en descargar el script con curl y ejecutarlo con sh:

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

Si el sistema no tiene curl, puedes usar wget:

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

Si quieres instalar una versión concreta, coloca el número de versión en la URL. Por ejemplo, el ejemplo oficial usa 0.11.11:

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

Este método encaja con la mayoría de entornos personales de desarrollo. Es simple, multiplataforma y funciona mejor con el mecanismo oficial de actualización de uv.

El instalador coloca binarios como uv y uvx bajo el directorio del usuario, y puede modificar el shell profile para que los comandos puedan usarse directamente desde la terminal. Si no quieres que el instalador modifique PATH, revisa las opciones oficiales del installer, por ejemplo configurando UV_NO_MODIFY_PATH=1.

Windows: instalador de PowerShell

El método oficial en Windows es ejecutar el script de instalación con PowerShell:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

Para instalar una versión concreta, también puedes poner el número de versión en la URL:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

Aquí ExecutionPolicy ByPass permite obtener y ejecutar el script de instalación desde internet. Como hábito de seguridad, puedes revisar el contenido del script antes de ejecutarlo:

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

Si estás acostumbrado a gestores de paquetes de Windows, también puedes priorizar WinGet o Scoop.

Instalar con pipx

La documentación oficial indica que uv se publica en PyPI. Si lo instalas desde PyPI, se recomienda ponerlo en un entorno aislado, por ejemplo con pipx:

`1`	`pipx install uv`

Este método es adecuado si ya usas pipx como gestor de herramientas CLI de Python. Evita mezclar uv con el entorno del proyecto actual.

Si no tienes pipx, también puedes usar pip directamente:

`1`	`pip install uv`

Pero ten en cuenta que uv ofrece wheels precompilados en muchas plataformas. Si una plataforma no tiene un wheel compatible, se construirá desde código fuente, y en ese caso necesitarás una toolchain de Rust.

Mi recomendación: en una máquina personal, pipx install uv es más limpio que pip install uv; dentro de un entorno de proyecto, no recomiendo instalar uv como dependencia del proyecto.

Homebrew, MacPorts, WinGet y Scoop

Si prefieres gestores de paquetes del sistema, uv también admite canales comunes.

En macOS, usa Homebrew:

`1`	`brew install uv`

Los usuarios de MacPorts pueden usar:

`1`	`sudo port install uv`

En Windows, usa WinGet:

`1`	`winget install --id=astral-sh.uv -e`

Los usuarios de Scoop pueden usar:

`1`	`scoop install main/uv`

La ventaja de estos métodos es que delegan el mantenimiento en el gestor de paquetes del sistema. La desventaja es que el ritmo de actualización depende del origen de paquetes correspondiente, no del instalador oficial de uv.

Docker, GitHub Releases y Cargo

uv también ofrece imágenes Docker en GitHub Container Registry:

`1`	`ghcr.io/astral-sh/uv`

Esto sirve para CI, Dockerfiles, creación de imágenes y entornos temporales de ejecución. En uso real, conviene revisar también la documentación oficial de integración con Docker.

Si quieres descargar binarios manualmente, puedes hacerlo desde GitHub Releases. Cada página de release suele incluir binarios para las plataformas compatibles y explicar cómo llamar al instalador independiente usando una URL de GitHub.

Los usuarios de Rust también pueden instalar desde crates.io:

`1`	`cargo install --locked uv`

Pero este método compila desde código fuente y requiere una toolchain de Rust compatible. A menos que necesites instalarlo explícitamente desde el ecosistema Rust, los usuarios normales no tienen por qué elegir Cargo primero.

Actualizar uv

Si uv se instaló mediante el instalador independiente oficial, puedes usar el comando de autoactualización:

`1`	`uv self update`

La documentación oficial indica que actualizar uv vuelve a ejecutar el instalador y puede modificar el shell profile. Si no quieres que la actualización modifique PATH, configura:

`1`	`UV_NO_MODIFY_PATH=1`

Si lo instalaste de otra forma, debes actualizarlo con el gestor correspondiente. Por ejemplo, si lo instalaste con pip, usa:

`1`	`pip install --upgrade uv`

Homebrew, WinGet, Scoop y MacPorts también deben usar sus propios comandos de actualización.

Activar autocompletado de shell

uv admite autocompletado de shell. La documentación oficial recomienda comprobar primero cuál es tu shell actual:

`1`	`echo $SHELL`

Bash:

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

Si también usas uvx con frecuencia, puedes activar el autocompletado de uvx por separado.

Bash:

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

Después de configurarlo, reinicia el shell o recarga el archivo de configuración correspondiente.

Desinstalar uv

Para desinstalar uv, primero puedes limpiar la caché y los datos gestionados por uv:

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

Después elimina los binarios.

macOS / Linux:

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows:

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

La documentación oficial también recuerda que antes de 0.5.0, uv se instalaba en ~/.cargo/bin. Si actualizaste desde una versión antigua, es posible que los binarios viejos sigan allí y debas eliminarlos manualmente.

Qué hacer después de instalar

Después de instalar, conviene confirmar primero la versión:

`1`	`uv --version`

Luego puedes empezar con algunas tareas comunes:

uv python install
uv venv
uv pip install requests
uvx ruff --version

Si es un proyecto nuevo, puedes seguir aprendiendo:

uv init: inicializar un proyecto;
uv add: añadir dependencias;
uv sync: sincronizar el entorno;
uv run: ejecutar comandos dentro del entorno del proyecto;
uvx: ejecutar temporalmente herramientas CLI de Python.

Mi recomendación

En una máquina personal de desarrollo, prioriza el instalador independiente oficial, porque es el método más alineado con la documentación oficial de uv y admite uv self update.

Si usas Windows y no quieres ejecutar un script remoto, puedes usar WinGet o Scoop. Si usas macOS y prefieres que todas tus herramientas las gestione Homebrew, puedes usar directamente brew install uv.

Quienes ya gestionan herramientas CLI de Python con pipx pueden usar pipx install uv. Pero no recomiendo ejecutar pip install uv dentro del entorno virtual de un proyecto concreto, porque eso mezcla la toolchain con las dependencias del proyecto.

Si se trata de CI o construcción de contenedores, revisa primero Docker y GitHub Releases, y fija la versión según el flujo de creación de la imagen.

Enlaces relacionados

Documentación de instalación de uv: https://docs.astral.sh/uv/getting-started/installation/
uv First steps: https://docs.astral.sh/uv/getting-started/first-steps/
Integración de uv con Docker: https://docs.astral.sh/uv/guides/integration/docker/
uv GitHub Releases: https://github.com/astral-sh/uv/releases

Warp Open Source: de terminal a entorno de desarrollo agentico

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp es el repositorio open source del cliente de Warp. Warp se describe ahora como un “entorno de desarrollo agentico, nacido del terminal”: parte del terminal, pero lleva agentes de programacion con IA, indexacion de codebase, gestion de tareas y flujos de desarrollo a un solo entorno.

No es un repositorio open source ordinario de emulador de terminal. Se parece mas a una respuesta a una pregunta mayor: cuando agentes como Claude Code, Codex y Gemini CLI se vuelven comunes, deberia el propio terminal convertirse en un entorno de desarrollo para planificar, observar y gestionar agentes?

La respuesta de Warp es si.

Estado actual del repositorio

Al 7 de mayo de 2026, warpdotdev/warp es un repositorio publico. GitHub muestra alrededor de 56k stars y 4.1k forks. El README dice que el codigo del cliente Warp ahora es open source y da la bienvenida a contribuciones de la comunidad.

El lenguaje principal es Rust. El desglose de lenguajes de GitHub muestra Rust por encima del 98%, lo que encaja con el posicionamiento de Warp: no es un wrapper web, sino una herramienta de desarrollo nativa y multiplataforma.

Varios detalles del README importan:

Warp es un entorno de desarrollo agentico, nacido del terminal.
Puede usar su agente de programacion integrado y tambien conectar con agentes CLI externos como Claude Code, Codex y Gemini CLI.
OpenAI es el patrocinador fundador del repositorio Warp recien abierto.
Los flujos de gestion agentica del repositorio estan impulsados por modelos GPT.
Los crates del framework de UI de Warp usan licencia MIT, mientras que el resto del codigo usa AGPL v3.

Esto muestra que el movimiento open source de Warp no consiste solo en publicar un terminal. Esta operando el proyecto como un campo de pruebas para flujos de trabajo con agentes.

Warp es mas que un terminal

Los terminales tradicionales hacen principalmente tres cosas:

iniciar una shell;
ejecutar comandos;
mostrar salida.

La diferenciacion inicial de Warp era hacer que el terminal se sintiera mas moderno: bloques de comandos, autocompletado, historial, colaboracion, interacciones con estilo de UI y pulido multiplataforma. Ahora el foco se ha desplazado mas hacia organizar el desarrollo alrededor de agentes de IA.

Segun el README, Warp ya no enfatiza solo “un mejor terminal”. Enfatiza:

agentes de programacion integrados;
soporte para agentes CLI externos;
triage de issues;
escritura de especificaciones;
revision de PR;
coordinacion de contribuidores;
sesiones de agentes observables.

En otras palabras, Warp quiere convertir el terminal de “donde escribes comandos” en “donde trabajas con multiples agentes”.

Oz y gestion de proyectos open source

El README menciona Oz varias veces.

La vista de contribucion de Warp muestra miles de agentes Oz trabajando en triage de issues, especificaciones, implementacion y revision de PR. Esto es interesante porque extiende los agentes de IA desde “ayudar a una persona a escribir codigo” hasta “ayudar a gestionar colaboracion open source”.

La parte mas dificil de muchos proyectos open source no es escribir codigo, sino mantener:

demasiados issues y poca clasificacion;
bugs y feature requests mezclados;
nuevos contribuidores sin saber que tareas son abordables;
presion de revision de PR;
maintainers intentando seguir cada hilo de comunidad.

La idea de Warp es dejar que los agentes asuman primero parte del trabajo de gestion de proyecto y colaboracion. El README tambien menciona Oz for OSS, un programa orientado a maintainers para llevar flujos similares de gestion open source agentica a otros repositorios.

Esto sugiere que la ambicion de Warp no es solo el producto terminal, sino tambien un nuevo modelo de mantenimiento open source en la era de la IA.

Estructura del repositorio y stack tecnico

Por la estructura del repositorio, Warp es un proyecto Rust grande.

La raiz contiene:

app/: codigo principal de la aplicacion.
crates/: crates Rust centrales.
assets/: archivos de recursos.
command-signatures-v2/: contenido relacionado con firmas de comandos.
docker/, script/, resources/, specs/ y otros directorios de ingenieria.
.claude/, .warp/, .agents/skills y otras configuraciones relacionadas con agentes.

WARP.md aporta mas detalle de ingenieria. Describe Warp como un emulador de terminal basado en Rust que usa un framework de UI interno llamado WarpUI.

Los modulos principales pueden entenderse aproximadamente asi:

app/: emulacion de terminal, gestion de shell, integracion de IA, Drive, autenticacion, ajustes, workspace y sesiones.
crates/warp_core/: utilidades centrales y abstraccion de plataforma.
crates/editor/: funcionalidad de edicion de texto.
crates/warpui/ y crates/warpui_core/: framework de UI interno.
crates/ipc/: comunicacion entre procesos.
crates/graphql/: cliente GraphQL y esquema.

WARP.md tambien menciona rasgos arquitectonicos como:

un sistema Entity-Handle;
una estructura modular de workspace;
targets para macOS, Windows, Linux y WASM;
integracion de IA, incluyendo Agent Mode, conciencia de contexto e indexacion de codebase;
sincronizacion cloud Warp Drive.

Esta complejidad esta mas cerca de un IDE completo que de un terminal tradicional ligero.

Comandos de build local

El README da un flujo local conciso:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Donde:

./script/bootstrap realiza la inicializacion especifica de la plataforma.
./script/run compila y ejecuta Warp.
./script/presubmit ejecuta formato, clippy, tests y otras comprobaciones previas al envio.

WARP.md tambien lista comandos mas detallados:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Si quieres contribuir a Warp, ./script/presubmit es practicamente obligatorio.

Flujo de contribucion

El flujo de contribucion de Warp no es simplemente “abre un PR”.

El README describe un proceso ligero desde issue hasta PR:

Buscar primero issues existentes.
Si no hay duplicado, abrir un bug o feature request.
Los maintainers revisan el issue y pueden anadir etiquetas de preparacion.
ready-to-spec significa que el diseno puede expandirse en una especificacion.
ready-to-implement significa que el diseno esta lo bastante claro para empezar un PR de implementacion.
Los contribuidores pueden tomar issues etiquetados.

Este proceso encaja con un proyecto open source grande. Separa ideas, diseno e implementacion, reduciendo el riesgo de que los contribuidores pasen tiempo construyendo en una direccion equivocada.

Tambien encaja bien con agentes de IA. Un agente puede organizar issues, redactar specs, anadir tests y luego pasar a implementacion. Warp usa este patron para demostrar gestion de proyecto agentica.

Licencia: MIT + AGPL v3

Warp usa una estructura de doble licencia.

El README dice:

el framework de UI de Warp, concretamente los crates warpui_core y warpui, usa licencia MIT;
el resto del repositorio usa AGPL v3.

Esto importa. AGPL v3 tiene requisitos open source mas fuertes para servicios de red y distribucion. Si estas aprendiendo, investigando o contribuyendo, normalmente es sencillo. Pero si quieres usar codigo de Warp en un producto comercial o en un derivado closed-source, debes leer la licencia con cuidado y consultar asesoria legal si hace falta.

En resumen, Warp es open source, pero no es open source de “tomalo y cierralo libremente”.

Por que merece atencion

Primero, Warp une terminal, agentes y gestion de proyecto.

Muchas herramientas de programacion con IA siguen siendo CLI o plugins de editor. Warp parte del punto de entrada del terminal e intenta unificar tareas de agentes, ejecucion de codigo, salida de comandos, flujos de PR y colaboracion de equipo.

Segundo, el enfoque open source de Warp es un buen lugar para observar flujos con agentes.

No solo publica codigo. Tambien expone vistas de contribucion, sesiones de agentes, triage de issues y flujos de especificacion. Para cualquiera que estudie como la IA puede participar en colaboracion open source, el propio repositorio es una muestra.

Tercero, Warp es una aplicacion de escritorio Rust compleja.

Si quieres estudiar GUI en Rust, emulacion de terminal, apps multiplataforma, clientes GraphQL, sincronizacion cloud e integracion de IA, el repositorio tiene mucho que leer. Pero no es un proyecto pequeno, asi que los nuevos contribuidores deberian leer primero la documentacion y el proceso de issues.

Cuarto, Warp soporta tanto un agente integrado como un enfoque “trae tu propio agente CLI”.

Esto es realista. Los desarrolladores no usaran un solo agente. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw y herramientas similares probablemente coexistiran. Si Warp puede convertirse en un banco de trabajo para ellos, se vuelve mas valioso que un terminal de proposito unico.

A quien deberia importarle

Si eres un usuario normal de terminal, Warp importa porque el terminal puede estar cambiando de herramienta de linea de comandos a banco de trabajo con IA.

Si eres usuario intensivo de agentes de programacion con IA, Warp merece seguimiento porque intenta gestionar multiples agentes en vez de actuar como otro punto de entrada de chat.

Si mantienes proyectos open source, la direccion de Oz for OSS merece atencion. Explora triage de issues con agentes, revision de PR, colaboracion comunitaria e incorporacion de contribuidores.

Si eres desarrollador Rust, Warp es una aplicacion de escritorio real y de gran escala que merece estudiarse por organizacion de UI, internals de terminal, sincronizacion cloud, integracion de IA y codigo multiplataforma.

Si solo quieres un terminal que pueda reemplazar al actual de inmediato, es mejor descargar primero la version estable y despues decidir si estudiar el codigo fuente. Compilar desde codigo es mas adecuado para contribuidores y usuarios profundos.

Lectura breve

El punto de que Warp se vuelva open source no es simplemente “un terminal moderno se hizo open source”.

Mas precisamente, Warp intenta actualizar el terminal hasta convertirlo en un entorno de desarrollo agentico: el terminal conecta shell, codebase, ejecucion de comandos, agentes, issues, PRs y flujo de colaboracion.

A medida que los agentes de programacion con IA sigan creciendo, el punto de entrada del entorno de desarrollo puede cambiar. Antes, el IDE dominaba la experiencia del desarrollador mientras el terminal ejecutaba comandos. Ahora el terminal puede convertirse en el centro de colaboracion con agentes. El repositorio de Warp explora esa posibilidad.

Enlaces relacionados

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

Guía inicial de Codex App: instalación, sandbox, tareas paralelas, Skills y MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App puede entenderse como un espacio de trabajo de tareas para programación con IA. No es un IDE tradicional ni solo una ventana de chat. Reúne multitarea, gestión de proyectos, permisos de sandbox, Git, ejecución en la nube, plugins, Skills, MCP y automatización en una sola interfaz.

Si ya usas Codex CLI, Claude Code, Cursor u otros coding agents, la parte más interesante de Codex App es que convierte “ejecutar varios agentes en paralelo” en un flujo de escritorio más claro.

Para qué sirve Codex App

El valor central de Codex App no es responder preguntas, sino permitir que la IA ejecute tareas de forma continua dentro de un directorio de proyecto:

Editar código, ejecutar comandos e iniciar servidores de desarrollo.
Gestionar múltiples proyectos y múltiples tareas.
Ejecutar tareas largas localmente o en la nube.
Llamar plugins, Skills y MCP para ampliar capacidades.
Gestionar cambios mediante Git, worktree y flujos PR.

OpenAI también posiciona Codex App como una interfaz para gestionar múltiples coding agents. Es adecuada para personas que necesitan avanzar varias tareas de programación a la vez, especialmente páginas frontend, scripts, apps pequeñas, documentación y flujos de automatización.

Preparación antes de instalar

Antes de usar Codex App, conviene preparar tres herramientas básicas:

Git
Node.js
VS Code o tu IDE preferido

Codex App soporta macOS y Windows. Después de instalar, inicia sesión con tu cuenta de ChatGPT. En el primer lanzamiento, puedes elegir tu escenario principal de uso, como programación o trabajo diario. Codex precargará algunos plugins y Skills según tus elecciones, y luego puedes ajustarlos en configuración y en el marketplace de plugins.

Las funciones principales en Windows y macOS son bastante parecidas, pero algunas capacidades de automatización del ordenador pueden depender de la plataforma y del soporte de plugins. Usa lo que tu versión actual muestre realmente.

Estructura de interfaz: proyectos, tareas y chats

Codex App usa un diseño clásico de tres columnas:

Izquierda: proyectos, tareas, historial de chats, plugins y entradas de automatización.
Centro: ventana de chat actual.
Derecha: archivos, navegador, terminal, resultados de ejecución y otros paneles.

Un proyecto normalmente corresponde a una carpeta local. Puedes abrir varios chats dentro del mismo proyecto, o abrir varios proyectos a la vez para que distintos agentes trabajen en paralelo.

La lista de tareas muestra distintos estados:

Running: el agente sigue ejecutando.
Waiting for approval: debes confirmar permisos, red, instalación de dependencias o una acción de alto riesgo.
Completed: la tarea terminó, y puedes inspeccionar el resultado o seguir preguntando.

Esto es más intuitivo que cambiar entre varias ventanas de terminal, y se adapta mejor a gestionar varias tareas de IA a la vez.

Sandbox y control de permisos

El sistema de permisos de Codex App se construye alrededor del sandbox. Por defecto, la carpeta actual del proyecto se convierte en el workspace principal del agente.

Los límites de permisos comunes incluyen:

Puede leer y modificar archivos dentro del directorio del proyecto.
Por defecto no puede modificar libremente archivos fuera del proyecto.
La red o comandos de alto riesgo están restringidos por defecto.
Cuando necesita acceso elevado, pide aprobación al usuario.

Un modo práctico es “auto review”: las acciones de bajo riesgo se permiten automáticamente, mientras que las acciones de alto riesgo siguen siendo confirmadas por el usuario. Esto reduce ventanas emergentes frecuentes y evita que operaciones peligrosas ocurran en silencio.

“Full access” debe habilitarse con cautela. Es adecuado cuando sabes exactamente qué necesita hacer el agente, el proyecto ya tiene respaldos Git y los archivos importantes tienen copias separadas. No se recomienda como valor diario permanente.

Contexto, modelos y cuotas

Codex App muestra el uso de contexto del chat actual. Cuanto más larga es la conversación y más historial contiene, más contexto necesita procesar el modelo.

Hábitos útiles:

Empezar un chat nuevo después de terminar una tarea.
Los chats largos pueden comprimirse manualmente, pero no trates la compresión como memoria perfecta.
Para tareas complejas, declara claramente objetivos, límites y criterios de aceptación.
No pegues de golpe logs, errores o archivos grandes e irrelevantes en un chat.

Para selección de modelos, ajusta la fuerza de razonamiento según la complejidad de la tarea. Ediciones simples, escritura y tareas repetitivas no siempre necesitan el modelo más fuerte. Migraciones de arquitectura, bugs difíciles y refactors entre archivos encajan mejor con modelos más potentes.

Si la interfaz tiene un modo rápido, recuerda que normalmente consume más cuota. Úsalo cuando la velocidad importe, pero no como valor diario predeterminado.

Generación de imágenes y entradas multimodales

Codex App puede aceptar imágenes y archivos como contexto, y puede llamar generación de imágenes en escenarios adecuados.

Esto es útil para proyectos frontend y de contenido. Por ejemplo, puedes pedir a Codex:

Corregir estilos de página según capturas.
Reemplazar imágenes inadecuadas en una web.
Generar imágenes de producto, imágenes de carrusel o assets de página.
Señalar qué debe cambiarse a partir de una captura de UI.

Un enfoque más eficiente no es decir solo “hazlo más bonito”, sino usar capturas y señalar problemas concretos, como “el espacio en esta tarjeta es demasiado grande”, “esta imagen no coincide con la escena del servicio” o “haz más clara el área del mapa”.

Steer: corregir dirección durante la ejecución

Steer puede entenderse como tomar control de la dirección durante la ejecución. Si el agente ya empezó pero notas que entendió mal, no siempre conviene esperar a que termine para corregirlo.

Puedes usar steering para insertar una nueva instrucción en el flujo de ejecución actual y hacer que Codex corrija el rumbo.

Buenos casos de uso para Steer incluyen:

El agente entendió mal el requisito.
El estilo de página generado es claramente incorrecto.
El plan actual es demasiado costoso o pesado.
Necesitas añadir una restricción clave temporalmente.

En general, mantén el comportamiento predeterminado en cola y usa Steer manualmente solo cuando se necesite intervención. Esto evita interrumpir tareas normales y aun así permite recuperar la dirección en momentos clave.

Modo plan y navegador integrado

Para tareas complejas, empieza con modo plan. En modo plan, Codex no modifica código de inmediato. Primero produce un plan y puede hacer preguntas clave con tarjetas.

Tareas adecuadas para modo plan incluyen:

Migración de frameworks, como pasar un proyecto React a Next.js.
Refactors grandes.
Funciones que involucran bases de datos, autenticación o despliegue.
Requisitos donde aún no has decidido la ruta técnica.

El panel derecho de Codex App puede abrir un navegador integrado para previsualizar el servidor local de desarrollo. Puedes anotar la página y dejar que Codex modifique una ubicación específica de UI. Este flujo de “mirar la página, hacer clic en la posición y pedir a la IA que la cambie” suele ser mejor para depuración frontend que descripciones puramente textuales.

Git, IDE y rollback de código

Codex App no es un IDE completo. Puede ver código y añadir anotaciones, pero la edición manual sigue siendo mejor en VS Code, Cursor, Windsurf u otro IDE.

Todo proyecto de Codex debería inicializar Git temprano:

Pedir a Codex que cree o revise .gitignore.
Hacer un commit al llegar a un estado usable.
Asegurar un punto de commit limpio antes de cada cambio grande.
Volver atrás con Git si no estás satisfecho.

Si haces rollback solo del historial de chat, el código no vuelve automáticamente. Un enfoque más seguro es devolver el chat al punto correcto y luego usar un hash de commit Git para devolver el código al estado correspondiente.

Worktree: desarrollo paralelo en varias direcciones

git worktree es especialmente adecuado para agentes paralelos en Codex App.

Crea varios directorios de trabajo independientes desde el mismo repositorio, cada uno correspondiente a una rama distinta. Esto permite que diferentes agentes trabajen en distintas carpetas al mismo tiempo sin sobrescribirse.

Uso típico:

Un worktree optimiza el componente de reseñas de clientes.
Un worktree ajusta información de tienda y diseño del mapa.
Fusionar ambas tareas de vuelta a main tras completarlas.
Eliminar worktrees temporales después de fusionar.

Esto es mucho más seguro que dejar que varios agentes modifiquen código en el mismo directorio. Si hay conflictos, revísalos y fusiónalos con flujos Git normales.

Entorno de ejecución en la nube

Codex puede trabajar no solo en tu máquina local, sino también en un entorno de nube.

La ejecución en la nube es adecuada cuando:

Estás fuera y solo tienes un teléfono.
Quieres que los agentes ejecuten tareas largas en segundo plano.
El código ya se sincronizó con GitHub y Codex necesita modificar el repositorio remoto.
Quieres revisar y fusionar cambios mediante PRs.

Un flujo típico es: subir el código local a GitHub, dejar que Codex descargue el repositorio en un entorno de nube, ejecutar la tarea, generar cambios y presentarlos como PR o diff para revisión.

Al continuar el desarrollo local, recuerda traer los últimos cambios remotos.

Sistema de memoria: escribe un buen AGENTS.md

Los chats nuevos no tienen memoria histórica completa por defecto. Una vez que un proyecto se vuelve complejo, explicar el contexto repetidamente es ineficiente.

La solución más general es mantener AGENTS.md en la raíz del proyecto. Este archivo puede registrar:

Objetivos del proyecto y stack principal.
Comandos comunes.
Estructura de directorios.
Estilo de código y convenciones de nombres.
Acciones prohibidas, como borrar archivos en masa.
Reglas de pruebas, build y despliegue.

También puedes pedir a Codex que lea el proyecto y genere una primera versión de AGENTS.md, luego revisarla manualmente. Para proyectos complejos, vale la pena mantener este archivo.

Las reglas globales deben usarse con cuidado. Son adecuadas para restricciones universales de seguridad, como “no borrar directorios recursivamente” o “confirmar antes de operaciones destructivas”. No pongas detalles específicos del proyecto en reglas globales, o contaminarán otros proyectos.

Plugins y automatizaciones

Los plugins conectan Codex con servicios externos como GitHub, Gmail, Google Drive, bases de datos y plataformas de despliegue.

Su valor está en reducir copiar y pegar. Por ejemplo, Codex puede:

Revisar tendencias de estrellas de un repositorio GitHub.
Resumir contenido de email y enviártelo.
Ejecutar una revisión recurrente.
Escribir el resultado como resumen.

Las automatizaciones son adecuadas para tareas repetidas. Por ejemplo, revisar datos de un repositorio todos los viernes por la tarde y enviar un informe por email. Las tareas simples de automatización normalmente no requieren el modelo más fuerte; basta un modelo más ligero.

Skills: convertir flujos de trabajo en capacidades reutilizables

Las Skills son “manuales profesionales” para Codex. No son prompts de una sola vez. Empaquetan un flujo de tarea, reglas, scripts y notas para que Codex pueda reutilizarlos de forma fiable después.

Fuentes comunes incluyen:

Skills oficiales.
Skills de terceros.
Skills escritas por ti.

Buenos candidatos para Skills incluyen:

Convertir subtítulos en notas ilustradas.
Escribir informes semanales con formato de empresa.
Procesar imágenes o documentos por lotes.
Revisiones de código con formato fijo.
Inicialización de proyectos para un framework concreto.

Si has copiado y pegado el mismo prompt muchas veces, vale la pena convertirlo en una Skill.

MCP: conectar herramientas externas y bases de datos

MCP puede entenderse como un protocolo estandarizado de herramientas para modelos grandes. Mediante MCP, Codex puede llamar servicios externos para completar tareas más concretas.

Por ejemplo, después de conectar Supabase, Codex puede:

Crear tablas de base de datos.
Leer esquemas de base de datos.
Modificar endpoints backend.
Enviar formularios frontend a la base de datos.
Depurar problemas según el estado de la base de datos.

Esto es poderoso, pero los permisos importan. Bases de datos, entornos de producción, plataformas de despliegue y cuentas de email son recursos de alto riesgo. Al conectarlos por primera vez, usa un proyecto de prueba y una cuenta con pocos privilegios.

Plugins de despliegue

Los plugins de plataformas de despliegue pueden permitir que Codex complete builds y releases directamente, como desplegar un proyecto frontend en Netlify.

Estos plugins son adecuados para sitios pequeños, prototipos, herramientas internas y demos. En uso real, presta atención a:

Ejecutar un build local antes del despliegue.
No escribir variables de entorno directamente en el código.
Comprobar que la página abre normalmente después de publicar.
Mantener revisión humana para proyectos de producción.

La IA puede ayudar a conectar el flujo de despliegue, pero los permisos de despliegue deben gestionarse con cuidado.

Automatización del ordenador

Con plataformas y entornos de plugins soportados, Codex también puede operar navegadores o apps de escritorio, completando tareas más cercanas a RPA.

Ejemplos:

Abrir una app de chat y preparar un mensaje.
Navegar un tablero de proyecto y resumir estado de tareas.
Generar un brief en inglés.
Enviarlo a un destinatario especificado después de tu confirmación.
Convertir el flujo en una automatización programada.

Estas capacidades son imaginativas, pero requieren los límites de seguridad más fuertes. Cualquier operación que implique enviar mensajes, enviar email, enviar formularios, pagos o eliminar datos debe conservar confirmación humana.

Sugerencias de uso

La forma correcta de usar Codex App no es dejarle tomar todo de golpe, sino dividir tareas y permitir que ejecute eficientemente en un entorno controlado.

Hábitos recomendados:

Inicializar Git en cada proyecto.
Usar modo plan para tareas complejas.
Usar worktree para tareas paralelas.
Poner reglas de proyecto en AGENTS.md.
Mantener confirmación humana para acciones de alto riesgo.
Convertir flujos repetidos en Skills o automatizaciones.
Validar plugins y MCP primero en un entorno de prueba.

Referencias

Resumen

Codex App no es “otra ventana de chat con IA”. Su foco es convertir la programación con IA en un espacio de trabajo gestionable, donde proyectos locales, tareas en la nube, Git, worktree, plugins, Skills, MCP y automatización puedan conectarse.

La clave para usarla bien es equilibrar libertad y control. Las tareas pequeñas pueden entregarse a Codex con confianza. Las tareas complejas deben empezar con un plan. Las acciones de alto riesgo deben confirmarse. Usada así, Codex puede convertirse no solo en un asistente que escribe código, sino en una herramienta de ingeniería de largo plazo.

Compound Engineering Plugin: convertir la programación con IA en un ciclo de planificación, ejecución y revisión

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin es un plugin de flujo de trabajo de programación con IA publicado como open source por Every Inc.

No se centra en “hacer que la IA escriba un fragmento de código más rápido”, sino en colocar la programación con IA dentro de un ciclo más parecido al de un equipo de ingeniería: primero planificar, luego implementar, después revisar y finalmente conservar la experiencia aprendida. Para quienes usan con frecuencia herramientas como Claude Code, Codex, Cursor o Copilot, este tipo de plugin resuelve un problema de flujo de trabajo, no solo de prompts.

Las herramientas de programación con IA son cada vez más fuertes, pero en proyectos reales lo más difícil no suele ser generar código, sino lograr que siga de forma continua las reglas del proyecto, entienda los límites de la tarea, evite repetir errores y acumule contexto durante iteraciones largas.

Qué problema resuelve

Muchas personas usan asistentes de programación con IA más o menos así:

Describen directamente el requisito
Dejan que la IA modifique código
Miran si el resultado puede ejecutarse
Si hay error, añaden más instrucciones
En la siguiente tarea vuelven a explicar desde cero

Este método puede completar tareas pequeñas, pero en proyectos complejos aparecen problemas con facilidad:

El requisito no se divide primero con claridad y la IA empieza a modificar directamente
Falta una review sistemática después de los cambios
Las reglas del proyecto dependen de que el usuario las recuerde una y otra vez
El mismo tipo de error vuelve a aparecer en la siguiente ocasión
Falta un método de trabajo común entre varias herramientas Agent
La experiencia no se convierte en reglas reutilizables

Compound Engineering Plugin quiere resolver precisamente estos problemas. Divide la programación con IA en varias etapas, para que el Agent no solo ejecute comandos, sino que participe en un proceso de ingeniería más completo.

Qué es Compound Engineering

Según la descripción del README del proyecto, Compound Engineering puede entenderse como un método de desarrollo de software asistido por IA.

Destaca un ciclo:

Planificación: entender primero el objetivo, dividir tareas y confirmar la ruta
Ejecución: modificar código según el plan, ejecutar comandos y tratar problemas
Revisión: comprobar calidad de implementación, riesgos y cobertura de pruebas
Aprendizaje: convertir la experiencia en reglas reutilizables para el futuro

Este ciclo se parece mucho a la forma de trabajo de un equipo de ingeniería real.

Un ingeniero fiable no recibe un requisito y empieza a cambiar cosas sin rumbo, ni entrega directamente después de modificar. Primero evalúa el alcance de impacto, luego implementa, después revisa riesgos y resultados de pruebas, y finalmente registra los problemas encontrados. Los AI Agent también necesitan restricciones similares.

Por qué hace falta un plugin

Un prompt puede decirle a la IA “planifica antes de ejecutar”, pero el prompt por sí mismo no siempre es estable.

Cuando la conversación se alarga y el contexto se vuelve complejo, el modelo puede saltarse la planificación, ignorar reglas o volverse demasiado confiado para terminar la tarea. El valor del plugin está en fijar el proceso para que distintos entornos Agent sigan un método parecido.

Este tipo de plugin suele dividir el flujo de trabajo en comandos, reglas, plantillas o subprocesos. El usuario no necesita escribir cada vez un prompt completo, sino que activa una etapa mediante una entrada fija.

Por ejemplo:

Pedir primero al Agent que genere un plan
Implementar después paso a paso según el plan
Activar review tras terminar los cambios
Volver a corregir cuando se encuentren problemas
Escribir las experiencias valiosas en memoria o reglas

Esto hace que la programación con IA se parezca más a una “colaboración controlada” que a una conversación de una sola vez.

Qué entornos Agent soporta

El README menciona que el proyecto soporta varios entornos de programación con IA, incluyendo:

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

Este punto es importante.

Muchas herramientas de flujo de trabajo están atadas a un solo cliente; al cambiar de herramienta, las reglas dejan de reutilizarse. Compound Engineering Plugin se parece más a un método de ingeniería transversal a distintos Agent, llevando procesos similares de planificación, ejecución y revisión a varias herramientas.

Si usas varios asistentes de programación con IA al mismo tiempo, este tipo de flujo unificado gana valor. Las herramientas tienen capacidades distintas, pero las normas del proyecto, los hábitos de review y el método de división de tareas deberían ser lo más consistentes posible.

Para qué sirve la etapa de planificación

El valor de la planificación es evitar que la IA actúe demasiado pronto.

En tareas complejas, las preguntas realmente importantes suelen ser:

Qué archivos hay que modificar
Qué módulos pueden verse afectados
Cuál es el patrón existente
Si hay pruebas
Dónde están los riesgos
Si hay que leer documentación antes
Si puede dividirse en pasos más pequeños

Si el Agent no piensa primero estas preguntas y se pone a escribir código directamente, es fácil que produzca una implementación que parece terminada, pero que se aleja de la estructura del proyecto.

El plan no tiene que ser largo. Un buen plan debería ser corto, concreto y ejecutable. Su objetivo no es fabricar documentación, sino dar límites a la implementación posterior.

Qué evitar en la etapa de ejecución

Cuando la IA ejecuta tareas de código, aparecen con facilidad varios problemas:

Refactorizar código no relacionado de paso
Sobrescribir cambios existentes del usuario
Cambiar solo el happy path
Ignorar manejo de errores
No seguir el estilo existente del proyecto
No ejecutar validaciones necesarias
Probar a ciegas tras encontrar errores

Un plugin de flujo de trabajo no puede garantizar que estos problemas desaparezcan por completo, pero puede reducir su frecuencia mediante reglas y restricciones por etapa.

Por ejemplo, la etapa de ejecución puede pedir al Agent que avance paso a paso según el plan; si descubre algo fuera del alcance previsto, primero explica el riesgo; si modifica módulos compartidos, añade pruebas o al menos ejecuta validaciones relacionadas.

Esta restricción es especialmente importante en codebases grandes. Cuanto más rápido escribe código la IA, más necesita un proceso que limite su inercia.

Por qué importa la etapa de review

Muchos fallos de programación con IA no ocurren porque el código no pueda ejecutarse en absoluto, sino porque los detalles están mal:

No se tratan condiciones límite
Las actualizaciones de estado no son consistentes
El contrato de API se cambia en silencio
Las pruebas no cubren rutas clave
Los mensajes de error no son claros
No se mencionan riesgos de rendimiento o seguridad

La etapa de review cambia al Agent de “modo autor” a “modo revisor”.

El modo autor tiende a justificar su propia implementación; el modo revisor debe buscar activamente defectos, riesgos de regresión y pruebas omitidas. Separar estas dos etapas suele ser más fiable que pedir en una misma respuesta que implemente y se autoevalúe.

Para el usuario, la salida de review también es más valiosa. Ayuda a decidir rápidamente si este cambio merece integrarse o si necesita otra ronda de trabajo.

El sentido de aprendizaje y memoria

La palabra “Compound” del nombre del proyecto sugiere una idea importante: la experiencia de ingeniería debería crecer con efecto compuesto.

Si cada vez que la IA comete un error solo lo arregla en ese momento, pero la próxima vez comete el mismo error, la mejora de eficiencia es limitada. Un mejor método es conservar la experiencia útil:

Convenciones de directorios del proyecto
Métodos de diagnóstico para ciertos errores
Comandos de prueba y precauciones
Archivos generados que no deben tocarse
Preferencias de estilo de código
Patrones de implementación habituales

Estas experiencias pueden convertirse en reglas, memoria, documentación o plantillas. En tareas posteriores, el Agent lee primero ese conocimiento acumulado y luego empieza a trabajar.

Esa es la clave para que la programación con IA pase de “pregunta y respuesta puntual” a “colaboración de largo plazo”.

Escenarios adecuados

Compound Engineering Plugin es adecuado para:

Usar AI Agent para escribir código de forma continua
Modificar un mismo proyecto durante muchas rondas
Querer que la IA planifique antes de implementar
Querer que después de modificar entre automáticamente en mentalidad de review
Equipos que quieren unificar el flujo de programación con IA
Personas que usan a la vez Claude Code, Codex, Cursor y otras herramientas
Querer convertir experiencia del proyecto en reglas reutilizables

Si solo pides ocasionalmente a la IA que escriba un pequeño script, el flujo completo puede parecer pesado.

Pero si estás tratando al asistente de programación con IA como un compañero diario de desarrollo, el ciclo de planificación, ejecución, revisión y aprendizaje se vuelve claramente útil.

Diferencia frente a plantillas de prompt comunes

Las plantillas de prompt comunes suelen resolver “cómo expresar bien la tarea”.

Por ejemplo:

Piensa paso a paso
Lee primero los archivos
Mantén el estilo de código
Ejecuta pruebas
Resume los cambios

Estas indicaciones son útiles, pero siguen dependiendo de que el usuario las use correctamente cada vez.

Compound Engineering Plugin se sitúa más en la capa de flujo de trabajo. Organiza estos requisitos en un proceso repetible y lo adapta a distintas herramientas Agent. Así, no partes de cero escribiendo prompts cada vez, sino que avanzas dentro de un proceso.

En pocas palabras, una plantilla de prompt se parece a un recordatorio; un plugin de flujo de trabajo se parece a un sistema.

Precauciones al usarlo

Primero, no conviertas el proceso en una carga.

Las tareas pequeñas no siempre necesitan un plan completo y una review larga. Un buen flujo de trabajo debería ajustarse a la complejidad de la tarea: resolver rápido los problemas simples y usar el ciclo completo en problemas complejos.

Segundo, la review no sustituye a las pruebas.

Una review hecha por Agent puede encontrar muchos problemas, pero aun así puede omitir errores reales de ejecución. El juicio final depende de pruebas, type checking, resultados de build y revisión humana.

Tercero, hay que limpiar reglas de forma continua.

Acumular experiencia es importante, pero demasiadas reglas también se convierten en ruido. Reglas obsoletas, repetidas o que solo servían para una tarea puntual deberían ordenarse periódicamente.

Cuarto, consistencia entre herramientas no significa identidad total.

Claude Code, Codex, Cursor, Copilot y otras herramientas tienen capacidades e interacciones diferentes. Lo que se unifica es el método de trabajo, no necesariamente cada comando ni cada detalle de configuración.

Qué equipos pueden aprovecharlo

Si un equipo ya permite que AI Agent modifique código real, no basta con discutir “qué modelo es más fuerte”.

Debería preocuparse más por:

Si la IA entiende la tarea antes de modificar
Si respeta límites del proyecto mientras modifica
Si revisa riesgos activamente después de modificar
Si aprende de errores históricos
Si el equipo tiene una norma común de uso de Agent

Ahí está el sentido de proyectos como Compound Engineering Plugin. Llevan la programación con IA desde una habilidad personal hacia un proceso reutilizable por el equipo.

Referencia

EveryInc/compound-engineering-plugin

Una última frase

Lo que merece atención de Compound Engineering Plugin no es que añada un comando más de programación con IA, sino que organiza la programación con IA como un proceso de ingeniería que puede mejorar en ciclos.

Cuando los AI Agent empiezan a participar en proyectos reales, planificación, ejecución, revisión y acumulación de experiencia importan más que generar código una sola vez.

Dominio de los ganchos de Claude Code: una introducción a los 13 eventos del ciclo de vida de los ganchos y al control de automatización

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery es un proyecto de aprendizaje centrado en Claude Code Hooks.

No es sólo una colección de guiones dispersos. Explica el ciclo de vida del gancho de Claude Code, los métodos de configuración, los patrones de script y los escenarios de automatización comunes en un solo lugar. Para las personas que quieren que Claude Code sea más controlable y más parecido a un asistente de ingeniería, vale la pena leer este tipo de material.

Claude Code ya puede leer código, editar archivos y ejecutar comandos de forma predeterminada. Pero si desea que verifique permisos automáticamente, bloquee operaciones riesgosas, inyecte reglas de proyecto, ejecute pruebas o le recuerde las convenciones del equipo en momentos específicos, las instrucciones de chat por sí solas no son lo suficientemente estables. El valor de los ganchos es que convierten las “reglas que necesito recordarle a la IA cada vez” en un flujo de trabajo ejecutable.

Qué problemas resuelven los ganchos

Después de usar Claude Code por un tiempo, los puntos débiles comunes incluyen:

Cada nueva sesión necesita repetir las mismas reglas del proyecto.
Te preocupa que pueda ejecutar comandos que no debería ejecutar.
Quieres verificaciones antes y después de la edición de archivos.
Quiere formatear, realizar pruebas o realizar análisis de seguridad antes de confirmar
Quieres que las convenciones del equipo sean un flujo de trabajo fijo en lugar de recordatorios verbales.
Quiere contexto antes y después de las llamadas a herramientas para iniciar sesión o bloquear
Quiere que tareas complejas activen subagentes o scripts dedicados

Los ganchos están diseñados para estas “acciones automáticas en momentos fijos”.

Puedes considerarlos como enlaces de eventos en el flujo de trabajo de Claude Code. Cuando se inicia una sesión, un usuario envía un mensaje, el modelo está a punto de llamar a una herramienta, finaliza una llamada a una herramienta o un agente está a punto de detenerse, Claude Code puede ejecutar los scripts que usted configuró.

Los 13 eventos del ciclo de vida del gancho

Uno de los puntos principales del proyecto README es que cubre sistemáticamente los 13 eventos de gancho del Código Claude.

Estos eventos abarcan varias etapas, desde el inicio de la sesión hasta las llamadas a las herramientas, y desde la entrada del usuario hasta la terminación del agente. Por finalidad, se pueden agrupar a grandes rasgos como:

Inicio de sesión: inicializa el entorno e inyecta el contexto del proyecto.
Entrada del usuario: inspeccionar indicaciones, agregar reglas y realizar auditorías
Antes de las llamadas a la herramienta: comprobaciones de permisos, bloqueo de comandos y validación de seguridad.
Después de las llamadas a la herramienta: registrar resultados, activar el formateo y ejecutar la verificación
Finalización de tareas: resumir, limpiar, notificar o guardar estado

Este diseño de ciclo de vida significa que no es necesario incluir todas las reglas en un mensaje muy largo.

Por ejemplo, el control de permisos debe realizarse antes de las llamadas a la herramienta. Las comprobaciones de formato son mejores después de editar los archivos. La inyección de reglas del proyecto es mejor al inicio de la sesión o después de la entrada del usuario. Poner reglas en el punto de enlace correcto suele ser más confiable que meter todo en un indicador del sistema.

Dónde vive la configuración

Los ganchos de Claude Code generalmente se configuran a través de archivos de configuración.

Las ubicaciones comunes incluyen:

Configuración a nivel de usuario: ~/.claude/settings.json
Configuración a nivel de proyecto: .claude/settings.json

La configuración a nivel de usuario es buena para las preferencias personales, como reglas generales de seguridad, bloqueo de comandos y rutas de registro.

La configuración a nivel de proyecto es mejor para reglas específicas del repositorio, como qué pruebas se deben ejecutar, qué directorios no se pueden editar, cómo se manejan los archivos generados y qué comprobaciones se requieren antes de la confirmación. Si usa Claude Code en un equipo, es mejor colocar la configuración a nivel de proyecto en el repositorio. De esa manera, todos inician el proyecto con las mismas limitaciones de colaboración de IA en lugar de depender de la memoria personal.

Por qué son importantes los scripts de un solo archivo

El proyecto enfatiza los scripts de un solo archivo “UV”.

El beneficio es una implementación simple. Un único archivo Python puede declarar dependencias y ejecutarse sin mantener un entorno complejo para un enlace. Esto encaja bien con los ganchos porque muchos ganchos solo hacen una pequeña cosa:

Comprobar si un comando está permitido
Determinar si la ruta de un archivo es segura
Leer las reglas del proyecto y devolvérselas a Claude.
Escanear la salida en busca de información confidencial
Ejecutar formateo o pruebas después de las ediciones.
Escribir eventos en registros.

Cuanto más pequeño sea un script de enlace, más fácil será de mantener y es menos probable que se convierta en un sistema nuevo y complicado.

¿Qué pueden hacer los ganchos con la automatización?

claude-code-hooks-mastery muestra muchas direcciones. En el trabajo real, los más comunes se encuentran a continuación.

1. Control de permisos y seguridad

Este es el uso más directo de los ganchos.

Antes de que Claude Code ejecute un comando, un gancho puede inspeccionar el contenido del comando. Si contiene acciones de alto riesgo, como eliminar, restablecer, limpiar o sobrescribir, puede bloquear la ejecución o requerir confirmación manual.

Se pueden aplicar reglas similares a las rutas de archivos:

No modificar la configuración de producción.
No escribir en archivos secretos
No eliminar scripts de migración
No tocar directorios específicos
No ejecute comandos de red no aprobados

Anteponer esta protección a las llamadas a herramientas es más confiable que escribir “no realizar operaciones peligrosas” en un mensaje.

2. Inyección de contexto

Muchos proyectos tienen información de fondo fija:

Pila de tecnología
Convenciones de codificación
Comandos de prueba
Estrategia de ramificación
Estructura del directorio
Acciones prohibidas
Reglas para archivos generados.

Decirle esto a Claude Code manualmente cada vez es molesto y fácil de olvidar. Los ganchos pueden inyectar automáticamente el contexto necesario al inicio de la sesión o después de que el usuario envía un mensaje.

Esto es como darle a Claude Code un manual de trabajo a nivel de proyecto. No reemplaza el README ni la documentación de desarrollo, pero ayuda a la IA a ingresar al estado correcto antes de ejecutar una tarea.

3. Verificación después de las ediciones

Después de que Claude Code modifica archivos, los ganchos pueden activar comprobaciones automáticamente.

Las acciones comunes incluyen:

Ejecutar formateo
Ejecutar pelusa
Ejecutar pruebas unitarias.
Verificar errores de tipo
Escanear archivos generados
Validar formato Markdown o JSON

Esto ayuda a reducir los errores de bajo nivel. Cuando la IA edita varios archivos, una verificación ligera después de la modificación puede revelar problemas antes.

Sin embargo, los ganchos no deberían ejecutar tareas pesadas de forma predeterminada. Ejecutar el conjunto de pruebas completo después de cada cambio de archivo puede ralentizar la experiencia. Un mejor enfoque es elegir comprobaciones según el tipo de archivo, el directorio y el riesgo de la tarea.

4. Validación de las reglas del equipo

Si un equipo ya tiene convenciones claras, algunas de ellas pueden colocarse en ganchos.

Por ejemplo:

Confirmar formato de mensaje
Reglas de estilo de código
No editar directamente ciertos archivos generados
La documentación debe actualizarse en conjunto.
Los cambios de API deben actualizar las pruebas.
Ciertos directorios sólo pueden ser generados por herramientas específicas Esto hace que Claude Code se parezca más a una parte del flujo de trabajo del equipo que a un asistente externo sin restricciones.

Por supuesto, los ganchos no deberían reemplazar a la CI. Son mejores para recordatorios locales y bloqueo temprano. La validación final aún debe pertenecer a los sistemas de CI, revisión y prueba.

5. Subagentes y tareas dedicadas

El archivo README también menciona contenido relacionado con subagentes.

Este tipo de uso es adecuado para enviar tareas complejas a flujos de trabajo más especializados. Por ejemplo, la conversación principal puede comprender el requisito, mientras que un enlace o una configuración desencadenan tareas dedicadas de verificación, auditoría, resumen o documentación.

Para los usuarios individuales, el primer paso útil no es la compleja orquestación de agentes. Es mejor entregar primero a los ganchos acciones repetitivas, claras y de bajo riesgo. Una vez que las reglas se estabilicen, puede producirse una automatización más compleja.

Línea de estado y estilos de salida

El proyecto también cubre la línea de estado y los estilos de salida.

Esto puede parecer un pequeño detalle de la experiencia, pero es importante para el uso a largo plazo del Código Claude. Una línea de estado puede mostrar el contexto actual, el estado de la tarea, información del entorno o sugerencias. Los estilos de salida pueden hacer que las respuestas de Claude Code se ajusten mejor a sus hábitos de trabajo.

Si colaboras con IA en el mismo terminal todos los días, estos detalles afectan la eficiencia. Las buenas sugerencias de estado reducen los errores y le ayudan a determinar rápidamente si la sesión actual se encuentra en el proyecto, rama y entorno correctos.

No hagas que los ganchos sean demasiado pesados

Los ganchos son poderosos, pero no son el lugar para poner todo.

Las buenas reglas son:

Las acciones de alta frecuencia deben ser rápidas.
El bloqueo de seguridad debe ser claro.
La salida debe ser corta.
Los motivos del fallo deben ser legibles.
Los scripts deben tener una única responsabilidad.
Las comprobaciones exhaustivas deben ser comandos explícitos o tareas de CI

Si un enlace tarda más de diez segundos cada vez, los usuarios pronto querrán desactivarlo. Si un gancho tiene reglas de bloqueo vagas, tanto Claude Code como el usuario tendrán dificultades para entender qué hacer a continuación.

Los ganchos son mejores para tareas con límites claros: permitir o rechazar, agregar contexto, registrar eventos, ejecutar comprobaciones ligeras y sugerir el siguiente paso.

¿Quién debería usarlo?

Si solo ocasionalmente le pides a Claude Code que edite un pequeño fragmento de código, es posible que aún no necesites estudiar los ganchos en profundidad.

Pero este proyecto es útil si:

Utilice Claude Code con frecuencia
A menudo deja que la IA modifique el código del proyecto real.
Preocupación por que la IA ejecute comandos peligrosos
Quiere inyectar automáticamente reglas de equipo en los flujos de trabajo de IA
Quiere que las comprobaciones se ejecuten automáticamente después de las ediciones
Quiere convertir recordatorios repetidos en configuración
Están creando un flujo de trabajo de codificación de IA más estable.

Los ganchos son especialmente significativos en proyectos colaborativos. Pueden convertir parte de la experiencia del equipo en guiones en lugar de depender de que cada persona se lo recuerde a la IA manualmente.

Notas de uso

Primero, comience con los ganchos de seguridad.

En comparación con la automatización compleja, el bloqueo de comandos, la protección de rutas y las comprobaciones de archivos confidenciales son más fáciles de implementar y reducen el riesgo de inmediato.

En segundo lugar, comprometa cuidadosamente las reglas a nivel de proyecto.

.claude/settings.json afecta a todos los que usan el repositorio. Antes de comprometer reglas, asegúrese de que no restrinjan demasiado el desarrollo normal ni dependan de rutas que solo existen en su máquina.

En tercer lugar, mantenga la salida del gancho concisa. Claude Code consume esta salida. Si es demasiado largo, contamina el contexto. Si es demasiado vago, no guía el siguiente paso. Lo mejor es devolver sólo el juicio necesario y la siguiente recomendación.

Cuarto, mantenga los ganchos depurables.

Cuando los ganchos aumentan en número, los problemas pueden provenir de la configuración, los scripts, los permisos, las rutas, las dependencias o el propio Claude Code. Los registros claros facilitan mucho la depuración posterior.

Referencia

disler/claude-code-hooks-mastery

Pensamiento final

El valor de “Claude Code Hooks” es convertir “reglas que espero que la IA recuerde siempre” en flujos de trabajo que realmente se ejecutan.

Si ya utiliza Claude Code en proyectos reales, los ganchos son un paso clave desde “un asistente de codificación que puede conversar” hasta “un colaborador de ingeniería limitado”.

Claude-Mem: Agregar memoria a largo plazo entre sesiones al código Claude

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem es un sistema de memoria persistente para Claude Code.

Intenta resolver un problema muy específico: cada vez que un asistente de codificación de IA inicia una nueva sesión, a menudo olvida decisiones de arquitectura anteriores, obstáculos pasados, preferencias de proyecto y contexto de implementación.
Si un proyecto dura mucho tiempo, explicar repetidamente los mismos antecedentes se convierte en una pérdida de tiempo.

La idea detrás de Claude-Mem es comprimir las conversaciones de Claude Code en recuerdos, almacenarlas en una base de datos local y en un almacén de vectores, y luego recuperarlas a través de una herramienta de búsqueda.

¿Qué problema resuelve?

Claude Code es bueno en tareas de código, pero el contexto de la sesión aún es limitado.

Los puntos débiles comunes incluyen:

Una nueva sesión no sabe lo que hicieron las sesiones anteriores.
Las decisiones de diseño del proyecto deben explicarse repetidamente.
Los problemas que ya fueron depurados son fáciles de repetir
Las tareas de larga duración carecen de continuidad.
El conocimiento del proyecto es difícil de acumular a través de conversaciones.

Claude-Mem está diseñado en torno a estos problemas.

No se trata simplemente de guardar registros de chat. En cambio, comprime las conversaciones en fragmentos de memoria que son más fáciles de recuperar. Cuando sea necesario más adelante, la búsqueda semántica puede recuperar el contexto relevante.

Cómo funciona

Según el diseño README, “Claude-Mem” consta principalmente de varias partes.

La primera parte son los ganchos.

Se integra con el flujo de sesión de Claude Code y captura datos de la conversación en el momento adecuado.

La segunda parte es un trabajador en segundo plano.

El trabajador procesa el contenido de la conversación en bruto y lo convierte en recuerdos más breves y fáciles de buscar.

La tercera parte es el almacenamiento local.

El proyecto utiliza SQLite para metadatos estructurados y Chroma para indexación de vectores. Esto preserva la información básica de la sesión al tiempo que admite la recuperación semántica.

La cuarta parte es “mem-search”.

Este es el punto de entrada de consulta para Claude Code. Cuando se necesita un contexto antiguo, se pueden buscar recuerdos relevantes a través de esta herramienta.

El flujo general se puede entender así:

Las sesiones de Claude Code generan contenido
Los ganchos capturan datos de la sesión
El trabajador lo comprime y organiza de forma asincrónica.
Los recuerdos se escriben en SQLite y Chroma.
Las sesiones posteriores los recuperan mediante mem-search

¿Cuándo es útil?

Claude-Mem es adecuado para proyectos de larga duración, no para tareas pequeñas y puntuales.

Por ejemplo:

Un repositorio se desarrolla durante muchos días.
La estructura del código es compleja y tiene muchos antecedentes.
Es necesario recordar las convenciones del proyecto, los hábitos de nomenclatura y las elecciones de arquitectura.
Claude Code se utiliza a menudo para corregir errores, funciones y documentación.
Quieres que la IA recuerde por qué se cambió algo antes

Si solo le pide a Claude Code que haga un cambio de una línea, la memoria a largo plazo no es muy significativa.
Pero si tratas a Claude Code como un colaborador a largo plazo, resulta útil.

Instalación y puesta en marcha

El README proporciona un flujo de instalación directo:

1
2

npm install -g claude-mem
claude-mem install

Empiece con:

`1`	`claude-mem start`

Verificar estado:

`1`	`claude-mem status`

Deténgalo cuando sea necesario:

`1`	`claude-mem stop`

El objetivo detrás de estos comandos es conectar el sistema de memoria como un servicio local de larga duración al flujo de trabajo de Claude Code.

Cómo utilizar `mem-search`

mem-search es el punto de entrada clave para recuperar la memoria.

No pretende reemplazar la búsqueda ordinaria. Permite a Claude Code consultar conversaciones pasadas por significado.

Por ejemplo, Claude Code puede buscar:

Por qué un módulo fue diseñado de cierta manera
Cómo se depuró un error anteriormente
Reglas de nomenclatura acordadas en el proyecto.
Compensaciones técnicas discutidas anteriormente
El trasfondo detrás de una refactorización.

Esto es diferente de la simple búsqueda de palabras clave.
Si la compresión de memoria y la indexación de vectores funcionan bien, puede recuperar contenido semánticamente relacionado incluso si no recuerda la redacción exacta.

¿En qué se diferencia de la documentación del proyecto?

La documentación del proyecto es buena para sacar conclusiones estables.

Por ejemplo:

Notas de arquitectura
Procedimientos de implementación
Convenciones API
Estructura de la base de datos
Reglas de desarrollo

Claude-Mem es mejor para el contexto creado durante las conversaciones.

Por ejemplo:

Por qué se rechazó un plan
Cómo se solucionó un problema temporal
La discusión detrás de una implementación.
Las preferencias del proyecto aún no están escritas en los documentos.
Antecedentes de tareas acumulados en múltiples conversaciones

Los dos no se reemplazan el uno al otro.
Un buen flujo de trabajo es escribir conocimientos estables en los documentos del proyecto y utilizar el sistema de memoria para ayudar a recuperar el contexto conversacional.

Cosas a tener en cuenta

En primer lugar, una mayor memoria a largo plazo no siempre es mejor.

Si cada conversación se guarda sin distinción, la recuperación posterior puede resultar ruidosa. Los recuerdos más valiosos son las decisiones del proyecto, los antecedentes de la implementación, el historial de depuración y las preferencias a largo plazo.

En segundo lugar, la memoria no puede reemplazar el código y la documentación.

El contexto antiguo encontrado por la IA es sólo una referencia. El juicio final aún depende del código actual, los resultados de las pruebas y los requisitos más recientes.

En tercer lugar, preste atención a la privacidad y los datos locales.

Dado que almacena el contenido de la conversación, debes saber qué proyectos son adecuados para él y qué información confidencial no debe entrar en la conversación.

Cuarto, los sistemas de memoria necesitan mantenimiento.

A medida que avanza un proyecto, los viejos recuerdos pueden quedar obsoletos. Si el contexto obsoleto se reutiliza incorrectamente, puede inducir a error en tareas posteriores.

Por qué es importante este tipo de herramienta

Las herramientas de codificación de IA están pasando de preguntas y respuestas únicas a una colaboración a largo plazo.

En preguntas y respuestas únicas, el modelo solo necesita responder la pregunta actual.
En una colaboración a largo plazo, es necesario conocer el historial del proyecto, las decisiones anteriores, las preferencias del equipo y los obstáculos que ya se han encontrado.

Aquí es donde importan herramientas como Claude-Mem: convierten el “recordar el contexto” de una capacidad de chat temporal en un sistema local que puede instalarse, ejecutarse y buscarse.

Para proyectos de ingeniería reales, esto es más práctico que simplemente alargar la ventana de contexto del modelo.
No es necesario contextualizar mucha información de una sola vez; es necesario recuperarlo en el momento adecuado.

¿Quién debería intentarlo?

Quizás quieras probarlo si:

Usas Claude Code con frecuencia
A menudo trabajas en el mismo proyecto durante varios días.
El contexto del proyecto es complejo.
Explicas repetidamente los mismos antecedentes a la IA.
Quieres preservar la experiencia de las conversaciones.

Si solo usas Claude Code ocasionalmente, o el proyecto es pequeño, es posible que aún no necesites este tipo de sistema.

Referencia

thedotmack/claude-mem

Pensamiento final

El objetivo de Claude-Mem no es “guardar registros de chat”. Ayuda a Claude Code a recuperar contexto útil en tareas posteriores. A medida que la codificación de IA pase de tareas únicas a colaboraciones en proyectos de larga duración, los sistemas de memoria serán cada vez más importantes.
No pueden reemplazar la documentación y las pruebas, pero pueden reducir las explicaciones repetidas y hacer que la IA se sienta más como un asistente que comprende el historial del proyecto.

Primeros pasos con la compilación de programas UEFI: desde uefi-simple hasta su primer .EFI

Thu, 30 Apr 2026 19:53:08 +0800

Compilar su primer programa UEFI no es precisamente sencillo. La configuración del entorno puede llevar tiempo, los errores del vinculador son comunes y un programa .EFI no tiene la misma experiencia directa de edición y ejecución que una aplicación de escritorio normal.

Este artículo organiza el tema desde la perspectiva de un principiante: si sólo desea compilar su primer programa UEFI, ¿por dónde debería empezar, qué conceptos importan primero y qué errores es más probable que aparezcan?

¿Qué es un programa UEFI?

Un programa UEFI suele ser un archivo .EFI.

No es un .exe ordinario en el que se hace doble clic en Windows. Es un ejecutable PE/COFF que se ejecuta dentro del entorno de firmware UEFI. Los casos de uso comunes incluyen:

Gestores de arranque
Herramientas de inicialización de hardware.
Herramientas de actualización de firmware
Herramientas de diagnóstico previas al arranque
Flujos de arranque personalizados

Muchas funciones que ve al principio del proceso de inicio del sistema pueden estar relacionadas con aplicaciones, controladores o servicios de firmware UEFI.

Para los principiantes, no es necesario comprender inmediatamente el desarrollo completo del firmware. El primer objetivo es simple: compilar un archivo .EFI que pueda cargarse mediante un UEFI Shell o un emulador.

¿Por qué no empezar con EDK II?

El desarrollo real de UEFI a menudo implica EDK II.

EDK II es completo y más cercano a la ingeniería de firmware real, pero no es muy amigable para principiantes:

La estructura del proyecto es compleja.
El sistema de construcción tiene una curva de aprendizaje.
Las variables de entorno y la configuración de la cadena de herramientas implican muchos detalles.
Los errores del compilador no siempre son fáciles de entender.
Es fácil quedarse atascado en el entorno antes de escribir cualquier código.

Si el objetivo es simplemente ejecutar un programa UEFI mínimo, un ejemplo ligero es un mejor punto de partida.

pbatard/uefi-simple es uno de esos proyectos. Su objetivo es sencillo: proporcionar un ejemplo UEFI Hello World sencillo para que puedas compilar un archivo .EFI primero.

¿Para qué sirve `uefi-simple`?

uefi-simple es un buen primer paso para los principiantes en UEFI.

Resuelve tres problemas prácticos:

Le brinda una estructura de aplicación UEFI mínima y compilable.
Evita la complejidad de grandes proyectos de firmware al principio
Le permite verificar que compilar, vincular y ejecutar todo funciona.

El proyecto admite múltiples métodos de compilación, incluidos Visual Studio 2022 y MinGW/gcc. También se puede probar con QEMU y OVMF.

En otras palabras, no es necesario reiniciar repetidamente una máquina real para los primeros experimentos. Ejecutar primero el programa en un emulador es mucho más seguro.

Qué preparar antes de comenzar

Necesita al menos algunas categorías de herramientas.

La primera categoría es la cadena de herramientas del compilador.

En Windows, puedes comenzar con:

Estudio Visual 2022
O MinGW/gcc

La segunda categoría es un entorno de ejecución UEFI.

Hay dos opciones comunes:

Ejecute el archivo .EFI en UEFI Shell de una máquina real
Pruébalo en un entorno virtual con QEMU + OVMF

La tercera categoría es un proyecto de ejemplo.

Los principiantes no deberían empezar escribiendo scripts de compilación desde un directorio vacío. Usar un ejemplo mínimo como uefi-simple ayuda a evitar muchos problemas del sistema de compilación.

Flujo de trabajo básico

Un flujo de trabajo mínimo de un programa UEFI se puede entender así.

Primero, obtenga el proyecto de ejemplo.

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

En segundo lugar, elija una cadena de herramientas de compilación. Si usa Visual Studio, cree con la solución Visual Studio en el proyecto.
Si usa MinGW/gcc, siga el Makefile o las instrucciones proporcionadas por el proyecto.

En tercer lugar, genere el archivo .EFI.

El punto clave aquí es confirmar la arquitectura de destino. Una PC común suele ser x86_64, es decir, un entorno UEFI de 64 bits.

Cuarto, coloque el archivo .EFI en algún lugar al que pueda acceder UEFI Shell.

En una máquina real, esto normalmente significa preparar una partición FAT32 o una unidad USB.
Con QEMU, puede montar un directorio o una imagen de disco.

Quinto, ejecútelo en UEFI Shell.

El resultado suele ser un resultado mínimo, como un mensaje estilo Hola mundo.

Donde los principiantes suelen quedarse estancados

La parte más difícil de compilar un programa UEFI no suele ser el lenguaje C en sí, sino el entorno y el proceso de vinculación.

Los problemas comunes incluyen:

Arquitectura de compilador incorrecta
Formato de destino incorrecto
Parámetros del enlazador incompletos
Falta el punto de entrada UEFI
Generar un ejecutable ordinario en lugar de un .EFI cargable por UEFI
QEMU u OVMF no configurados correctamente
Arranque seguro en una máquina real que bloquea un programa no firmado

Los errores del vinculador son especialmente fáciles de malinterpretar como problemas de código.
En muchos casos, el verdadero problema es la función de entrada, el subsistema, la arquitectura de destino o el script del vinculador.

Entonces, en la primera etapa, no se apresure a entrar en una lógica compleja. Asegúrese de que el ejemplo original se pueda compilar y ejecutar, luego cambie la salida poco a poco.

¿Por qué utilizar QEMU + OVMF para realizar pruebas?

Es posible probar programas UEFI en una máquina real, pero no es conveniente en la etapa principiante.

Es posible que tengas que repetir este ciclo:

compilar
Copiar a una unidad USB
Reiniciar
Ingrese al UEFI Shell
Ejecutar el programa
Registra el error
Regresar al sistema y modificar el código.

Ese bucle es lento.

QEMU + OVMF le permite simular un entorno UEFI directamente dentro del sistema operativo. Puede verificar si un archivo .EFI se carga más rápidamente y es menos probable que afecte sus entradas de arranque reales.

Una vez que el programa funciona básicamente, probarlo en una máquina real es mucho más manejable.

¿Qué deberían modificar primero los principiantes?

Si ya ha compilado su primer .EFI con el proyecto de ejemplo, no salte a funciones complejas de inmediato.

Un mejor orden es:

Cambie primero el texto de salida para confirmar que la recompilación realmente surte efecto.
Intente leer información sencilla proporcionada por UEFI.
Comprender la función de entrada, protocolo de salida y servicios básicos.
Luego considere funciones más complejas, como sistemas de archivos, salida gráfica o administración de entradas de arranque.

Este enfoque hace que cada paso sea verificable.
Si cambia demasiado a la vez, resulta difícil saber si el problema está en el código, el proceso de compilación o el entorno de ejecución.

¿En qué se diferencia de un programa C normal?

Aunque los programas UEFI se pueden escribir en C, su entorno de ejecución es completamente diferente al de los programas C normales.

Un programa C normal normalmente se ejecuta dentro de un sistema operativo y puede depender de la biblioteca, el sistema de archivos, el modelo de proceso y las llamadas al sistema estándar.

Un programa UEFI se ejecuta antes de que se inicie el sistema operativo. Se basa en los servicios proporcionados por el firmware UEFI. Muchas cosas a las que está acostumbrado en los programas normales no están disponibles aquí automáticamente. Al escribir programas UEFI, es necesario adaptarse a varias diferencias:

La función de entrada es diferente.
La salida funciona de manera diferente
Las bibliotecas disponibles son diferentes.
El acceso a la memoria y a los archivos funciona de forma diferente
La depuración funciona de manera diferente

Es por esto que partir de un ejemplo mínimo es mejor que escribir código como si fuera un programa C normal.

Un camino de aprendizaje práctico

Para principiantes, un camino realista es el siguiente:

Paso 1: compilar uefi-simple
Paso 2: Ejecútelo con QEMU + OVMF
Paso 3: Modificar la salida de Hola Mundo
Paso 4: Comprenda cómo UEFI Shell carga .EFI
Paso 5: aprenda la función de entrada UEFI y el protocolo de salida básico
Paso 6: Luego lea EDK II o material de desarrollo UEFI más completo

El objetivo de este camino es construir primero un circuito de retroalimentación que funcione.

Una vez que pueda generar un .EFI desde la fuente y ver el resultado en un entorno UEFI, ya habrá cruzado el primer umbral más difícil.

Referencias

-pbatard/uefi-simple

[Zhihu: material de compilación del programa UEFI] (https://zhuanlan.zhihu.com/p/643704056)

Pensamiento final

La parte difícil de compilar su primer programa UEFI generalmente no es escribir un poco de código C, sino conectar la cadena de herramientas, el formato de enlace y el entorno de ejecución.

No se apresure a utilizar funciones complejas.
Comience con un ejemplo mínimo como “uefi-simple”, obtenga primero un “.EFI” ejecutable y luego comprenda gradualmente los puntos de entrada, protocolos y métodos de compilación de UEFI.

Claude.md no es mejor cuando es más largo: cómo escribir archivos de memoria global para codificación AI

Wed, 29 Apr 2026 21:07:37 +0800

Recientemente vi una discusión sobre archivos de memoria global para codificación de IA: después de que los proyectos agregan archivos como Claude.md o AGENTS.md, los resultados no necesariamente mejoran. En algunos casos, las tasas de éxito pueden incluso disminuir mientras que el costo del razonamiento aumenta.

Al principio, esto parece contradictorio. Generalmente asumimos que si le damos a la IA más antecedentes del proyecto, más reglas y más explicaciones, debería escribir el código con mayor precisión.
El verdadero problema es que Claude.md no es un documento ordinario. Es un archivo de memoria global que se inyecta en el contexto de cada conversación. Cuanto más contiene, más tiene que leer el modelo cada vez; cuanto más vago sea, más juicio tendrá que hacer el modelo; y si contiene flujos de trabajo que no siempre deberían ejecutarse, el modelo puede desencadenar acciones innecesarias en tareas no relacionadas.

Entonces, la parte difícil de escribir Claude.md es no completarlo. Se trata de decidir qué piezas de información merecen ocupar contexto de forma permanente.

¿Qué es Claude.md?

En las herramientas de codificación de IA, archivos como Claude.md y AGENTS.md son esencialmente archivos de memoria global.

La conversación normal entra en el contexto, pero la longitud del contexto es limitada. Una vez que la conversación se vuelve larga, el contenido histórico se comprime y se pierden algunos detalles. Un archivo de memoria global fija reglas importantes para que el modelo pueda verlas al comienzo de cada tarea.

Esto significa dos cosas:

El contenido escrito allí es más difícil de olvidar.
El contenido escrito allí también cuesta algo en cada tarea.

No es como un README que se lee sólo cuando es necesario. Se parece más a un conjunto de limitaciones laborales de larga duración. Una vez que algo se coloca allí, afecta el juicio del modelo por defecto.

Por lo tanto, Claude.md no es una introducción al proyecto, ni una colección de consejos, ni un lugar para deshacerse de cada proceso de desarrollo. Sólo debe almacenar reglas que el modelo probablemente viole repetidamente si no las conoce.

Por qué puede empeorar las cosas

Un archivo de memoria global mal escrito suele provocar tres tipos de problemas.

Primero, consume contexto.

Si Claude.md tiene mil líneas, esas líneas permanecen en el contexto del modelo durante mucho tiempo. Es posible que se reduzcan el código, los mensajes de error y los requisitos que realmente son relevantes para la tarea actual. El contexto no es espacio libre. Cuanto más grande sea el archivo de reglas globales, más fácil será diluir la tarea actual.

En segundo lugar, puede desencadenar comportamientos innecesarios.

Por ejemplo, un archivo global podría decir:

1
2

Before every task, fully read the project directory.
After every change, run a complete end-to-end test.

Estas líneas parecen responsables, pero en un archivo de memoria global se convierten en “hacer esto para cada tarea”. Incluso si la tarea consiste solo en cambiar una línea de copia, el modelo puede realizar exploraciones y pruebas innecesarias debido a estas reglas. El resultado es un trabajo más lento, un costo más alto y, a veces, más interferencia.

En tercer lugar, aumenta la carga del juicio.

Declaraciones como “mantener el código elegante, conciso, mantenible y extensible” suenan correctas, pero son restricciones débiles. Cada vez que el modelo genera código, tiene que decidir qué significa elegante o extensible, sin recibir un límite claro.

Un mejor enfoque es escribir prohibiciones o contraejemplos concretos en lugar de virtudes abstractas. Por ejemplo:

1
2
3

Do not add a generic abstraction for a single call site.
Do not change shared parsing logic without test coverage.
Do not put temporary scripts in the application source directory.

Estas reglas son más específicas y más fáciles de seguir.

¿Qué debería entrar?

Puedes usar un estándar simple para decidir si algo pertenece a Claude.md:

Si la IA comete repetidamente el mismo error sin ella, entonces vale la pena anotarlo.

El contenido adecuado para un archivo de memoria global suele tener estas características:

Es duradero
Está fuertemente ligado al repositorio actual.
No se puede inferir naturalmente de la estructura del código.
Cambia claramente el comportamiento del modelo.
Es preferiblemente una restricción, prohibición, regla de ruta o comando fijo.

Por ejemplo:

For all Hugo posts, only edit index.zh-cn.md and do not automatically generate other language versions.
Article front matter must include title/date/draft/tags/categories/slug/description.
Do not modify generated artifacts under public/.
On PowerShell, use scripts/deploy.ps1 for deployment.

Estas no son sugerencias vagas. Están vinculados a cómo funciona realmente el repositorio. Si el modelo no los conoce puede cometer errores; una vez que los conoce, puede evitar verdaderos errores.

¿Qué debería quedar fuera?

Mucha gente convierte Claude.md en un manual de proyecto. Esto suele ser innecesario.

El contenido que generalmente no pertenece allí incluye:

Visión y antecedentes del proyecto.
Descripciones de estructuras de directorios grandes.
Planes de tareas temporales
Pasos únicos de depuración
Lemas de calidad de código abstracto.
Flujos de trabajo largos que solo son necesarios en algunas situaciones.

Por ejemplo, una descripción como “este es un proyecto de comercio electrónico con módulos de producto, pedido y usuario” ayuda muy poco con una tarea de codificación concreta. Durante el desarrollo real, el modelo debe depender de los requisitos, especificaciones, estructura del código y pruebas actuales, no de una introducción aproximada del proyecto en la memoria global.

Lo mismo se aplica a la estructura de directorios. A menos que un directorio tenga una convención especial, como “los componentes compartidos deben importarse desde este directorio”, no es necesario escribir el árbol completo en el archivo. El modelo puede leer el directorio del proyecto. Es fácil que una descripción de directorio estática quede obsoleta.

Los flujos de trabajo pertenecen a habilidades o comandos

Si una sección dice “primero haz esto, luego aquello y luego haz la tercera cosa”, es posible que no pertenezca a Claude.md.

Los flujos de trabajo de larga duración se pueden convertir en habilidades, scripts o comandos. El beneficio es que la memoria global solo necesita conservar el nombre y la condición de activación, mientras que los pasos detallados se cargan solo cuando es necesario.

Por ejemplo:

1
2

When the user asks to translate a Hugo post, use the post-translate skill.
When the user asks to deploy the site, run the hugo-rsync-deploy workflow.

Esto es más liviano que poner los procesos completos de traducción e implementación en Claude.md. La memoria global sigue siendo corta y los flujos de trabajo detallados se encuentran en herramientas activables.

El nuevo flujo de inicialización de Claude también avanza en esta dirección. No solo genera un Claude.md; también intenta dividir los flujos de trabajo reutilizables en habilidades y los eventos fijos en ganchos. La idea subyacente es clara: la memoria global debería ser un punto de entrada, mientras que los detalles deberían cargarse según demanda.

Claude.md necesita iteración

Claude.md no debe escribirse una vez y luego ignorarse.

Un mejor enfoque es ser breve al principio y dejar que las tareas reales expongan los problemas. Si ocurre un error una vez, manéjelo manualmente. Si el mismo tipo de error aparece dos o más veces, puede merecer convertirse en una regla global.

Este tipo de iteración es más útil que escribir un enorme conjunto de reglas al principio. Al principio, no sabes qué reglas son realmente útiles o qué líneas se convertirán en ruido. A medida que el proyecto crece, la colaboración aumenta y el comportamiento del modelo se vuelve más claro, puede agregar gradualmente problemas de alta frecuencia.

También hay una tendencia importante: cuanto más fuerte sea el modelo, más corto debería ser el archivo de memoria global. Muchos requisitos que alguna vez tuvieron que escribirse en indicaciones ahora son manejados naturalmente por el modelo. Continuar poniendo esos requisitos básicos en Claude.md solo aumenta la carga de contexto. La memoria global debería reducirse a medida que mejora la capacidad del modelo, manteniendo solo lo que es exclusivo de este repositorio y no se puede inferir automáticamente.

Una forma más práctica de escribirlo

Al escribir Claude.md, piense en este orden:

¿Qué convenciones especiales tiene este repositorio?
¿Qué errores ha cometido el modelo más de una vez?
¿Qué directorios, archivos o comandos nunca deben usarse indebidamente?
¿Qué flujos de trabajo deberían convertirse en habilidades, guiones o comandos en lugar de un contexto permanente?
¿Qué partes son meras introducciones y pueden eliminarse?

El archivo final puede tener sólo unas pocas docenas de líneas. No es necesario explicar completamente el proyecto. Necesita limitar el comportamiento con precisión.

Un buen Claude.md podría verse así:

# Working Rules

- Only edit files related to the current task.
- Do not modify generated artifact directories such as public/ or resources/.
- Hugo post rewrites only process index.zh-cn.md and do not generate other language versions.
- If deployment is involved, run the Hugo build first, then execute the existing rsync script.
- When there are existing user changes, do not revert them. Continue from the current state.

Es breve, pero cada línea afecta el comportamiento real. Ese es el tipo de contenido que vale la pena mantener en contexto permanentemente.

Pensamiento final

El valor de Claude.md no es hacer que la IA “sepa más”. Se trata de hacer que la IA “evite errores corregidos”.

No es una base de conocimientos ni una enciclopedia de proyectos. Es un archivo de restricciones de larga duración para la codificación AI.
Cuanto más específico, breve y cercano a los errores reales sea, más útil será. Cuanto más genérica, más larga y más parecida a una introducción de proyecto sea, más probable será que ralentice el modelo o incluso empeore los resultados.

Trate la memoria global como un recurso escaso, no como un bloc de notas ilimitado. Ese puede ser el principio más importante para escribir un buen Claude.md.

Codex está empezando a controlar la computadora. ¿Qué significa eso para el futuro?

Wed, 29 Apr 2026 11:28:25 +0800

La parte más importante de esta actualización del Codex no es que agregó otro botón común y corriente. Es que el Codex está empezando a avanzar hacia “controlar la computadora”.

En el pasado, usar IA generalmente significaba hacer preguntas en un cuadro de chat, copiar, pegar y luego operar manualmente el software.
Ahora ese límite se está ampliando: la IA no solo te responde. Puede operar aplicaciones de escritorio según su objetivo.

A corto plazo, esta es una característica nueva. A largo plazo, puede cambiar la cantidad de personas que usan computadoras.

¿Qué es esta característica?

En pocas palabras, la capacidad de uso de computadoras de Codex le permite acceder y operar el entorno de escritorio.

Puede hacer cosas como:

seleccionar y controlar una aplicación
recibir tareas en lenguaje natural
abrir navegadores, herramientas de inteligencia artificial, archivos locales u otro software
ingrese texto, haga clic en botones y espere resultados
conectar varios pasos en una tarea
seguir ejecutándose en segundo plano sin necesidad de que el usuario siga cada paso manualmente

Su función no es solo escribir un texto para usted, sino también completar un flujo de operación para usted.

Esa es la diferencia clave entre un Agente y un chatbot común y corriente:
un chatbot da principalmente respuestas; un Agente está más cerca de “recibir un objetivo y luego ejecutarlo”.

Por qué esto es importante

En el pasado, gran parte de la automatización requería que supieras escribir guiones.

Por ejemplo, supongamos que desea completar un flujo de trabajo entre software:

abrir una página web
encontrar información
copiar contenido
pásalo a otra herramienta de IA
guardar un archivo
abre el directorio local y comprueba el resultado

Para automatizar esto de forma tradicional, es posible que necesite scripts de navegador, API, programas locales e incluso automatización de ventanas.

Pero muchos usuarios comunes y corrientes no saben cómo escribir estas cosas.
Incluso si lo hacen, puede que no valga la pena escribir un guión para una tarea temporal.

Aquí es donde importa el uso de la computadora: empuja la “capacidad similar a un script” hacia el lenguaje natural.

No es necesario que le diga exactamente dónde hacer clic.
Puede decirle qué resultado desea y dejar que intente completar la tarea.

Flujos de trabajo que pueden cambiar

Creo que los primeros flujos de trabajo que cambiarán no serán trabajos extremadamente serios o de alto riesgo, sino tareas molestas, fragmentadas, repetitivas y para las que no vale la pena escribir un programa dedicado.

1. Mover información a través del software

El caso más típico es el de mover información entre aplicaciones.

Anteriormente, podía alternar entre un navegador, un documento, una ventana de chat y una carpeta local.
En el futuro, podrás encargar este tipo de tarea a un Agente:

encontrar cierto tipo de información
resumirlo en un documento
guárdelo en un directorio específico
abre el resultado para que lo revises

Este trabajo no es difícil, pero requiere atención.
El valor de un Agente es que absorbe estas pequeñas operaciones.

2. Coordinación entre múltiples herramientas de IA

El flujo de trabajo real de muchas personas ya no se basa en una única herramienta de inteligencia artificial.

Puede verse así:

una herramienta escribe código
una herramienta busca información
una herramienta genera imágenes
una herramienta organiza documentos

Anteriormente, estas herramientas se conectaban mediante copiar y pegar manualmente.
En el futuro, un Agente puede convertirse en la capa intermedia: abre herramientas, pasa contexto, espera resultados y organiza resultados. Esto puede convertir “múltiples herramientas de IA trabajando juntas” de un proceso manual a un proceso semiautomático.

3. Automatización del software de oficina

Las hojas de cálculo, las presentaciones, los documentos y el correo electrónico comparten una característica: son potentes, pero muchas operaciones están fragmentadas.

Si los agentes pueden controlar este software de forma fiable, la barrera a la automatización de oficinas disminuirá notablemente.

No es necesario recordar dónde está un menú ni aprender atajos complicados.
Solo necesitas describir el objetivo, como por ejemplo:

convierta esta hoja de cálculo en un informe mensual
hacer un resumen de una página de este documento
combinar estos materiales en una explicación claramente estructurada

Las tediosas operaciones de los botones quedarán gradualmente ocultas detrás del lenguaje natural.

Qué significa para los usuarios comunes

Para los usuarios comunes, este tipo de característica puede tener un impacto más directo que “el modelo se volvió un poco más inteligente”.

Porque reduce la barrera operativa, no sólo la barrera del conocimiento.

Muchas personas pueden describir lo que quieren, pero no saben dónde hacer clic o cómo combinar funciones dentro del software.
Si los Agentes pueden hacerse cargo de esta parte, el uso de una computadora puede convertirse en:

1
2
3

I describe the goal
Agent operates the software
I check the result

Esto está más cerca de la productividad real que un simple chat.

Su impacto en el software

Si este tipo de capacidad del Agente continúa madurando, el software en sí también se verá afectado.

En el pasado, el diseño de software se basaba principalmente en el clic humano.
En el futuro, es posible que también sea necesario que el software sirva para la operación del Agente.

Esto significa:

los elementos de la interfaz deben ser más claros
la retroalimentación de operación debe ser más estable
los permisos locales deben ser más granulares
el software puede proporcionar interfaces más adecuadas para las llamadas de los agentes
A los usuarios les puede interesar más si la IA puede operar el software sin problemas

A largo plazo, los límites entre las aplicaciones pueden volverse más delgados.
Es posible que a los usuarios les importe menos “qué aplicación debo abrir” y más “qué tarea quiero completar”.

No lo exageres todavía

Por supuesto, todavía no es momento de dejarlo ir por completo.

Este tipo de capacidad todavía tiene varias limitaciones claras:

la estabilidad aún necesita observación
las tareas complejas pueden fallar en el medio
los límites de los permisos deben manejarse con cuidado
Las operaciones de eliminación de cuentas, pagos y archivos no deben delegarse a la ligera.
el consumo de cuotas no es algo que puedas ignorar por completo

Entonces, en esta etapa, el mejor caso de uso es no dejar que se haga cargo de toda la computadora, sino permitir que maneje tareas de bajo riesgo, revisables y con muchos pasos.

Por ejemplo:

organización de materiales
generar borradores
mover contenido entre herramientas
abrir y comprobar archivos
ejecutar flujos de trabajo semiautomáticos que pueden ser revisados por un humano

Una última línea

La verdadera importancia de esta actualización del Codex es que empuja a la IA de “responder preguntas” a “operar el entorno”.

A corto plazo, es una característica del uso de la computadora.
A largo plazo, puede marcar un cambio en la forma en que se utilizan las computadoras personales.

En el futuro, es posible que dediquemos menos tiempo a recordar botones, buscar menús y cambiar de ventana.
Más a menudo, describiremos el objetivo, dejaremos que un Agente lo ejecute y luego dejaremos que los humanos tomen el juicio final.

¿Por qué existe una habilidad del Codex en el directorio pero aún no aparece?

Wed, 29 Apr 2026 11:18:00 +0800

Este problema era fácil de pasar por alto: varias habilidades ya estaban ubicadas en ~/.codex/skills, pero después de abrir un nuevo hilo del Codex, la barra lateral todavía mostraba solo un pequeño subconjunto de ellas.

Al principio, parecía un problema de caché o de indexación. La causa real fue más específica: varios archivos SKILL.md comenzaron con una lista de materiales UTF-8. El cargador de habilidades de Codex 0.111.0 no omitió esa secuencia de bytes, por lo que calculó erróneamente que los archivos no tenían contenido YAML válido.

Síntoma

El directorio local contenía estas habilidades:

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

Pero después de abrir un hilo nuevo, las habilidades realmente expuestas fueron solo:

1
2

bilibili-speech-transcriber
product-cutout-normalize

En otras palabras, un archivo existente en el disco no significa que la sesión actual pueda cargarlo correctamente. Codex analiza primero la portada de cada SKILL.md. Si el análisis falla, esa habilidad se excluye directamente.

Investigación

Iniciar una nueva sesión con codex exec mostró un error más directo. En VS Code u otros IDE, es posible que estos registros no sean visibles:

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

Visualmente, estos archivos parecían tener un encabezado normal:

---
name: post-rewrite
description: ...
---

El verdadero problema estaba en el nivel de bytes.

El comienzo de un archivo fallido fue:

`1`	`EF-BB-BF-2D-2D-2D`

El comienzo de un archivo que se cargó correctamente fue:

`1`	`2D-2D-2D`

2D-2D-2D es ---. El EF-BB-BF anterior es la lista de materiales UTF-8.

Causa

En Codex 0.111.0, el cargador de habilidades espera que el primer byte de SKILL.md sea el primer - en ---.

Si el archivo comienza con una lista de materiales UTF-8, el comienzo real será:

`1`	`BOM + ---`

Entonces, el cargador piensa que el archivo no comienza con el delimitador inicial e informa:

`1`	`missing YAML frontmatter delimited by ---`

El contenido de la habilidad no era incorrecto y el directorio tampoco era incorrecto. Un pequeño detalle de codificación impidió que el analizador reconociera el archivo.

Arreglar

Convierta los archivos SKILL.md afectados a UTF-8 sin BOM.

En PowerShell, esto se puede hacer así:

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

Después del procesamiento, el encabezado del archivo debería cambiar de:

`1`	`EF-BB-BF-2D-2D-2D`

`1`	`2D-2D-2D`

Verificación

Después de reiniciar una sesión del Codex, las habilidades visibles se restauraron en:

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

Si la barra lateral todavía muestra la lista anterior, cierre la barra lateral o ventana actual del Codex y vuelva a abrir el proyecto. La lista de habilidades generalmente se carga cuando comienza la sesión, por lo que es posible que los cambios realizados en mitad de una sesión no se actualicen inmediatamente.

Una última línea

Este tipo de problema es fácil de confundir con “El Codex no se volvió a indexar” o “la habilidad no se instaló correctamente”.

Al solucionar problemas, verifique primero estas tres cosas:

si SKILL.md está realmente en el directorio correcto
si el archivo tiene un texto inicial --- válido en la parte superior
si el archivo es UTF-8 sin BOM

La clave en este caso fue el tercer punto: el archivo se veía bien, pero su primer byte no era “-”, por lo que Codex no lo trató como una habilidad válida.

¿Cuál es la diferencia entre ~/.codex/skills y Project .codex/skills en Codex?

Wed, 29 Apr 2026 11:08:00 +0800

Al organizar las habilidades del Codex, la gente suele quedarse estancada en dos preguntas:

¿Cuál es la diferencia entre ~/.codex/skills y project/.codex/skills?
¿Por qué existe una habilidad en el directorio pero no aparece en la sesión actual?

Aquí está la versión corta.

La diferencia

La forma más sencilla de recordarlo:

~/.codex/skills es tu biblioteca de habilidades global
project/.codex/skills es la biblioteca de habilidades local para ese repositorio

`~/.codex/skills`

Úselo para:

Habilidades que reutilizas personalmente en todos los proyectos.
flujos de trabajo generales que no están vinculados a un repositorio específico
flujos de trabajo que claramente pertenecen a sus propios hábitos

Por ejemplo:

post-reescritura
post-traducir -git-commit-push -hugo-rsync-deploy
bilibili-transcriptor-de-voz

El rasgo clave de este tipo de habilidad es: todavía tiene sentido fuera del proyecto actual.

`proyecto/.codex/skills`

Úselo para:

flujos de trabajo que solo se aplican a este repositorio
reglas estrechamente acopladas a la estructura, scripts o plantillas del proyecto actual
Habilidades que deben ser compartidas por el equipo.

Por ejemplo:

un flujo de trabajo de publicación específico para este repositorio
una plantilla de generación que solo funciona en este proyecto
pasos de automatización estrechamente vinculados a scripts de proyectos privados

El rasgo clave de este tipo de habilidad es: deja de ser significativo una vez que sale de este repositorio.

Cuándo utilizar habilidades globales y cuándo utilizar habilidades de proyecto

Esta regla general es suficiente:

Si se trata de tus hábitos personales, ponlo en ~/.codex/skills
Si se trata de reglas del repositorio, colóquelo en project/.codex/skills
Si se puede reutilizar en todos los proyectos, prefiera global
Si debe ser compartido por varias personas y evolucionar con el repositorio, prefiera el nivel de proyecto

El repositorio actual

Basado en el estado actual:

su máquina tiene ~/.codex/skills
este repositorio no tiene .codex/skills

Así que ahora mismo dependes principalmente de las habilidades globales.

Eso significa que flujos de trabajo como “post-reescritura”, “post-traducción” y “git-commit-push” son actualmente más bien parte de su flujo de trabajo personal, no algo incluido explícitamente con este repositorio.

Por qué existe una habilidad en el disco pero puede no aparecer en la sesión actual

Hay dos cosas diferentes aquí:

Existente en el disco: el archivo de habilidad existe en un directorio local
Expuesto a la sesión: la sesión actual lo registró en la lista de habilidades disponibles

Estos no son lo mismo.

Entonces esto puede suceder:

ya existe una habilidad en ~/.codex/skills
pero no aparece en la lista después de /

Por lo general, esto no significa que la habilidad esté rota. Más a menudo significa: la sesión actual no la ha vuelto a indexar.

Cómo hacer que una habilidad esté disponible en la sesión actual

La lista de verificación práctica es breve.

1. Colóquelo en el directorio correcto

Mundiales:

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

Nivel de proyecto:

`1`	`project/.codex/skills/<skill-name>/SKILL.md`

2. Haga que el encabezado `SKILL.md` sea reconocible

Como mínimo, necesita:

---
name: your-skill-name
description: What this skill does
---

3. Abra una nueva sesión después de crearla o editarla

En muchos casos, una habilidad no aparece porque la sesión actual ya fijó su lista de habilidades disponibles cuando comenzó.

Entonces, si crea una habilidad en medio de una sesión, es posible que ya exista en el disco, pero es posible que esta sesión no la reconozca.

El flujo de trabajo más confiable es:

Ponga en práctica la habilidad
Finalizar la sesión actual
Vuelva a ingresar al proyecto.
Abre una nueva sesión
Compruebe si aparece debajo de /

4. Implemente las habilidades para el proyecto antes de comenzar

Si desea que project/.codex/skills se reconozca de manera más confiable, coloque esas habilidades en el proyecto antes de ingresar al repositorio e iniciar la sesión.

Una última línea

La conclusión más corta es:

~/.codex/skills es tu biblioteca de habilidades personales
project/.codex/skills es la biblioteca de reglas local del repositorio
una habilidad existente en el directorio no significa que la sesión actual siempre la mostrará
la solución más común es colocarlo en el directorio correcto, escribir un SKILL.md válido y luego iniciar una nueva sesión