Quando gli sviluppatori cercano "Figma inspector", di solito vogliono una di due cose: un modo per vedere i valori delle proprietà sui nodi senza un posto Dev Mode, o un modo per fornire contenuti Figma a un agente AI. La prima categoria è ben servita dai plugin. La seconda categoria è servita da quasi nulla — fino a figmascope.
Questo articolo confronta le due categorie, spiega perché risolvono problemi diversi, e mostra come appare in pratica un export nativo per agenti. Vai su figmascope.dev per provare l'export tu stesso, o continua a leggere per il confronto completo. Per il flusso di lavoro pratico, vedi Figma to Cursor o Figma to Claude Code.
Cosa fanno effettivamente gli strumenti "Figma inspector"
Il Figma inspector classico è il pannello di destra nell'interfaccia utente di Figma. Seleziona un nodo: vedi il suo riempimento, bordo, effetti, dimensioni, vincoli, tipografia. In Dev Mode (aggiunto nel 2023), questo pannello ottiene frammenti di codice — proprietà CSS dedotte dal nodo, auto-layout espresso come flexbox, colori con i loro nomi di variabile se le Variabili sono configurate.
Plugin come Inspect, Figma to Code, Anima e decine di altri estendono ulteriormente questo. Alcuni generano frammenti React o SwiftUI dai nodi selezionati. Alcuni esportano file CSS. Alcuni annotano la tela per le revisioni di handoff.
Tutti questi sono progettati per uno sviluppatore umano che guarda lo schermo. Mettono a disposizione informazioni su richiesta, nodo per nodo, selezionato da una persona che sa quale nodo gli interessa.
Perché questo modello non funziona per gli agenti AI
Un modello linguistico non è seduto in Figma a cliccare tra i nodi. Ha bisogno dell'intero contesto rilevante nella sua finestra di contesto prima di iniziare a generare codice. L'ispezione nodo per nodo produce frammenti. Ciò di cui l'agente ha bisogno è un documento strutturato che copra l'intera schermata: la gerarchia, i valori dei token, le stringhe, i riferimenti ai componenti — tutto in una volta.
C'è anche un problema di formato. Dev Mode produce frammenti CSS che sono vicini ma non del tutto corretti — i nomi delle proprietà differiscono tra i framework, le proprietà abbreviate richiedono espansione, i valori in pixel assoluti devono essere mappati al tuo sistema di token. Un agente che consuma l'output grezzo di Dev Mode riallucinera i nomi dei token, inventerà valori di spaziatura e produrrà codice che sembra sia stato progettato da qualcuno che ha visto il tuo design una sola volta.
Gli strumenti di ispezione rispondono a "cos'è questo nodo?" Gli strumenti per agenti rispondono a "cos'è questa intera schermata, in un formato su cui il modello può ragionare?"
figmascope come alternativa al Figma inspector
figmascope non è un pannello all'interno di Figma. Gira nel tuo browser, comunica direttamente con la REST API di Figma, ed esporta un bundle di contesto — uno zip strutturato contenente tutto ciò di cui un agente AI ha bisogno per implementare il design. Il formato dei token è documentato in dettaglio in Esportazione Token Design per Agenti AI, e la filosofia di handoff più ampia è trattata in Consegna Design AI.
L'export include:
- Un IR del layout per ogni frame, tipizzato e con riferimenti incrociati ai token, non un mucchio di CSS grezzo
- Design token in un formato JSON stabile, non una lista di valori hex senza nomi semantici
- Stringhe UI consolidate con chiavi di risorse, non valori di testo dispersi
- Render di riferimento a 2×, così l'agente ha una verità visiva insieme ai dati
- Un documento di specifica
CONTEXT.mdche l'agente legge prima, che spiega le convenzioni di denominazione dei token, l'ambito e qualsiasi anomalia
Confronto diretto
| Capacità | Figma Dev Mode | Plugin di Ispezione | figmascope |
|---|---|---|---|
| Valori di proprietà nodo singolo | Sì | Sì | No (non è questo il punto) |
| Esportazione albero layout schermata completa | No | Parziale | Sì — screens/*.json |
| Design token JSON tipizzati | No | Alcuni plugin | Sì — tokens.json |
| Documento di specifica per agente AI | No | No | Sì — CONTEXT.md |
| Stringhe consolidate con chiavi | No | No | Sì — strings.json |
| Inventario componenti | Parziale | Parziale | Sì — components/inventory.json |
| Render di riferimento | Esporta manualmente | No | Sì — screens/*.png (2×) |
| Inferenza di frequenza dei token | No | No | Sì — fallback per file senza Variabili |
| Richiede posto Figma | Posto Dev Mode richiesto | Varia | No — usa solo PAT |
| Privacy / no-upload | Dati elaborati da Figma | Varia per plugin | Lato client, token solo verso api.figma.com |
Figma Dev Mode — cosa fa bene e cosa fa male
Il pannello codice di Dev Mode è genuinamente utile per gli sviluppatori umani che hanno bisogno di leggere rapidamente un valore di spaziatura o controllare uno stack di font. Il suo collegamento alle Variabili è un passo nella giusta direzione — quando il file Figma usa le Variabili correttamente, Dev Mode mostra il nome della variabile insieme al valore risolto.
Dove non riesce per i flussi di lavoro AI:
- Nessun export a livello di file. Puoi leggere un nodo; non puoi esportare una rappresentazione leggibile dalla macchina dell'intera gerarchia di un frame.
- I frammenti CSS sono specifici del framework e spesso sbagliati per target non-web (iOS, Android, React Native).
- Nessun consolidamento delle stringhe. I valori di testo sono visibili per nodo ma non aggregati.
- Nessun documento di specifica leggibile dall'agente. Le annotazioni di Dev Mode sono per gli umani da leggere nell'app, non per i modelli linguistici da cui ragionare.
- Richiede un posto Dev Mode (45$/editor/mese dal 2025). figmascope ha bisogno solo di un Personal Access Token, che è gratuito.
Plugin Figma Inspector — il panorama
Ci sono circa tre categorie di plugin Figma inspector:
- Visualizzatori di proprietà — replicano ciò che mostra il pannello di destra di Dev Mode, spesso per gli utenti del piano gratuito che non hanno accesso a Dev Mode. Esempi: Figma Inspect, Handoff.
- Generatori di codice — producono codice specifico del framework dai nodi selezionati. Esempi: Figma to Code, Anima, Locofy. Questi generano codice dalla selezione individuale, non da un export strutturato dell'intero file.
- Esportatori di token — esportano design token dalle Variabili Figma. Esempi: Tokens Studio (ex Figma Tokens), Variables2JSON. Questi risolvono il problema dell'export dei token ma non l'IR del layout o i problemi delle specifiche per agenti.
figmascope non è nessuna di queste categorie. È più vicino alla categoria "esportatore di token" nello spirito, ma risolve un problema più ampio: produrre il contesto strutturato completo di cui un agente AI ha bisogno per implementare correttamente un'intera schermata.
Vedi figmascope vs plugin Figma per una suddivisione più dettagliata del panorama dei plugin.
Quando usare cosa
Questi strumenti non si escludono a vicenda. Un flusso di lavoro realistico:
- Usa Dev Mode o un plugin di ispezione quando sei uno sviluppatore che controlla i valori di un nodo specifico, conferma una decisione di spaziatura con il designer, o verifica a quale variabile si risolve un colore.
- Usa figmascope quando stai consegnando un'intera schermata (o file) a un agente AI per la generazione di codice. Eseguilo una volta per ogni milestone di design, commetti il bundle nel repo.
La distinzione è ispezione sincrona (l'umano legge un nodo alla volta) rispetto all'export in batch (l'agente ottiene il quadro completo in un unico documento strutturato).
Il PAT — cosa accede, cosa no
figmascope usa un Personal Access Token di Figma per leggere il file tramite REST API. Il token viene inserito nel tuo browser, vive nella memoria del browser per la sessione, e viene inviato solo come intestazione ad api.figma.com. Nessun server lo riceve. Quando chiudi la scheda, è sparito.
L'ambito minimo richiesto è File content: read-only. figmascope non scrive su Figma, non crea commenti, non accede ai file del team al di là di ciò che il token ha il permesso di leggere. Vedi sicurezza PAT e figmascope per il modello di minaccia completo.
Come appare l'output in un progetto reale
Dopo l'esportazione, il bundle di contesto si trova accanto al codice sorgente:
myapp/
├── src/
│ ├── screens/
│ └── components/
├── design/
│ ├── CONTEXT.md ← l'agente legge questo prima
│ ├── tokens.json ← design token tipizzati
│ ├── _meta.json ← manifesto di export, avvisi
│ ├── components/
│ │ └── inventory.json ← nomi e id canonici dei componenti
│ ├── screens/
│ │ ├── Home.json ← IR del layout
│ │ ├── Home.png ← render 2×
│ │ ├── Profile.json
│ │ └── Profile.png
│ └── strings.json ← tutto il testo UI, chiavi con notazione a punto
└── package.jsonQuesto è l'artefatto che commetti, referenzi in CLAUDE.md o .cursorrules, e su cui punti il tuo agente. Un solo export, tutto il contesto necessario.
Confronta questo con un tipico flusso di ispezione: lo sviluppatore apre Figma, clicca tra i nodi uno per uno, copia i valori nel codice, manca un nome di variabile, sbaglia la spaziatura sul padding mobile, passa venti minuti a riconciliare il design con l'implementazione. L'export strutturato elimina completamente quel ciclo quando è un agente a fare l'implementazione.
Riferimento al bundle nella configurazione AI del tuo progetto
Claude Code legge CLAUDE.md all'avvio della sessione. Cursor legge .cursorrules. Entrambi supportano un file di istruzioni a livello di progetto che orienta l'AI prima che faccia qualsiasi cosa. Aggiungi una breve sezione di design che punta alla tua directory design/:
# Per CLAUDE.md (Claude Code)
## Contesto design
Tutti i dati di design sono in `design/`. Prima di implementare qualsiasi UI:
1. Leggi `design/CONTEXT.md` per l'ambito e le convenzioni dei token
2. Usa `design/tokens.json` per tutti i valori di colore, spaziatura, raggio e tipografia
3. Usa `design/components/inventory.json` per i nomi canonici dei componenti
4. Usa `design/strings.json` per tutto il testo UI — referenzia tramite chiave con notazione a punto
5. Valida rispetto ai render `design/screens/*.png`# Per .cursorrules (Cursor)
Leggi sempre design/CONTEXT.md prima di implementare UI.
I valori dei token sono in design/tokens.json — non codificare mai colori o spaziature.
I nomi dei componenti vengono da design/components/inventory.json.
Le stringhe UI vengono da design/strings.json con chiavi con notazione a punto.Con questi in posizione, ogni sessione dell'agente nel progetto saprà automaticamente che esiste la directory design e come usarla — senza ripetere il prompt ogni volta.
L'alternativa MCP — e perché non è la stessa cosa
Il server Model Context Protocol (MCP) di Figma permette a un'AI di connettersi direttamente alla API di Figma e interrogare i nodi su richiesta. Questo è utile per il lavoro esplorativo — chiedere "che colore ha questo pulsante?" in una conversazione dal vivo. Non produce un artefatto riproducibile e controllato da versione. Ogni volta che l'agente esegue, rilegge il file Figma in tempo reale, che potrebbe essere cambiato. Non c'è CONTEXT.md che spieghi l'ambito. Non c'è un dizionario di token pre-generato con nomi stabili. Non c'è un sistema di avvisi per il layout anomalo.
figmascope e Figma MCP risolvono problemi diversi. MCP è online, in tempo reale, e buono per l'esplorazione interattiva. figmascope produce un artefatto offline, versionato, strutturato che è buono per la generazione di codice deterministica al momento dell'implementazione. Vedi figmascope vs Figma MCP per il confronto dettagliato, ed esplora il blog di figmascope per ulteriori approfondimenti sui flussi di lavoro di design AI.