Ecco la traduzione in italiano del testo fornito, seguendo tutte le linee guida specificate.
"L'AI scrive così tanto che non lo leggo nemmeno per bene 😅"
"Spendo oltre 15.000 yen al mese per Claude Code, ma non sento di ottenere un buon rapporto qualità-prezzo."
Molte persone sono soddisfatte solo per il fatto di usare l'AI, ma solo pochi la trasformano effettivamente in risultati. È uno stato di "sensazione di averla usata".
Hai avuto queste esperienze con Claude Code?
- Lunedì mattina gli chiedi di "riassumere le tendenze della concorrenza della scorsa settimana" e lui restituisce un lungo report. Lo dai un'occhiata e lo lasci lì, non letto.
- Sospetti che se tu non leggi per bene i materiali generati dall'AI, non c'è modo che i tuoi colleghi li leggano.
- Paghi oltre 3.000 yen al mese per Claude Code, ma i risultati non sono mai stati usati in una riunione o in una proposta.
- ChatGPT e Claude.ai producono output bellissimi, ma perché Claude Code produce solo Markdown, rendendo tutto così faticoso da leggere?
Questo articolo è per quelle persone.
Quando avrai finito di leggere, sarai in grado di generare naturalmente da Claude Code materiali che sia tu che gli altri leggerete davvero.
Acquisirai anche la prospettiva che "il formato in cui si produce l'output" è un fattore molto più importante nel giudizio dell'utente rispetto a "cosa chiedi a Claude Code di fare".
Thariq Shihipar (@trq212), uno sviluppatore di Anthropic che costruisce effettivamente Claude Code, ha scritto su X di una mentalità che si sta diffondendo all'interno dell'azienda, ed è diventato uno dei post più salvati e condivisi nella community di Claude Code.
Ha ricevuto una risposta enorme immediatamente dopo la pubblicazione.
Non è solo un piccolo suggerimento per gli appassionati di AI; è la storia di chi ha costruito lo strumento che sfida il Markdown, che è stato lo standard implicito dell'industria dell'AI, dicendo "non è più così".
Ho pensato che fosse importante, quindi ho deciso di spiegarlo immediatamente in giapponese.
Due cose prima di iniziare a leggere:
- Metti questo articolo nei preferiti. Solo per questa settimana, ritagliati del tempo per provare a produrre output in HTML.
- Se hai colleghi che usano Claude Code, condividilo con loro. Il modo in cui i tuoi report settimanali e le tue revisioni delle PR vengono "letti" cambierà visibilmente a partire dalla prossima settimana.
Analizzerò e spiegherò il contenuto traducendolo in come funziona nel panorama business giapponese 👇
Post originale qui:
https://x.com/trq212/status/2052809885763747935
Lo Sviluppatore di Anthropic in Persona Non Usa Più il Markdown
Questo è il punto di partenza. Thariq Shihipar (@trq212), che ha scritto il post originale, è lo sviluppatore che sta costruendo Claude Code in Anthropic. Il comportamento in cui Claude fa domande all'utente in "modalità piano" per perfezionare i requisiti è una funzionalità che ha implementato personalmente.
Dice di non accettare più il Markdown dallo strumento che sta costruendo. Con le sue parole, il Markdown è diventato un formato restrittivo per lui.
Non è solo una preferenza personale. Thariq menziona che l'adozione dell'HTML si sta diffondendo all'interno del team di Claude Code stesso. Le persone che costruiscono lo strumento stanno abbandonando il Markdown che produce e passando all'HTML.
E la prova è tangibile. Sul sito demo https://thariqs.github.io/html-effectiveness/https://thariqs.github.io/html-effectiveness/), ci sono 20 esempi HTML autonomi. Un confronto di tre approcci alla ricerca con debounce, micro-interazioni che creano un senso di realizzazione per il completamento delle attività, elenchi di token del design system, spiegazioni a schede per esempi di codice e materiale di lettura con un glossario a margine. Tutti questi sono esempi reali di come sostituire "documenti a cui dai solo un'occhiata" con "documenti che vengono letti fino alla fine". Puoi aprirli nel tuo browser proprio ora.
Leggendo questo, dovresti renderti conto di qualcosa. Gli Artifacts che di solito ricevi in ChatGPT o Claude.ai — quelle "interfacce con schede", "diagrammi colorati" e "pulsanti interattivi" — sono in realtà prodotti come HTML. La realizzazione qui è: "Il motivo per cui sembravano così belli era la differenza nel formato stesso." Ora, quel stesso mondo può essere portato a portata di mano con Claude Code.
Fino ad ora, il testo generato dall'AI era quasi esclusivamente Markdown. La persona che lo costruisce sta silenziosamente iniziando a obiettare, dicendo "non più". Questo è il cuore della notizia. Ma per te, che lavori con l'AI ogni giorno, questa è una storia che sarà efficace dal lunedì mattina.
Il Markdown Era lo Standard Implicito dell'Industria dell'AI
Confermiamo le supposizioni che davamo per scontate. Senza questo, il passaggio all'HTML potrebbe sembrare solo una questione di gusti.
Fino ad ora, il Markdown era lo standard de facto per l'output dell'AI. Pensa al testo che vedi ogni giorno:
- CLAUDE.md nella root del progetto, *.md per le definizioni degli agenti, SKILL.md per le Skills.
- La documentazione ufficiale di Anthropic, l'aiuto di Claude.ai e varie guide di Claude Code.
- Strumenti di sviluppo AI concorrenti, regole di Cursor, istruzioni di GitHub Copilot e istruzioni di Cline sono tutte basate su .md.
- Wiki interni, README di GitHub, testo esportato da Notion e verbali di riunioni incollati in Slack.
- Testo riassuntivo copiato dalle chat di ChatGPT.
Tutto è stato costruito sul presupposto del Markdown. È più difficile trovare un formato diverso dal Markdown nelle informazioni testuali che incontri quando hai a che fare con l'AI.
Il fenomeno del pattern CLAUDE.md di Karpathy che ha raccolto oltre 80.000 stelle su GitHub è avvenuto proprio perché il Markdown era il linguaggio comune dell'industria.
Per usare le parole di Thariq, il Markdown è diventato il formato mainstream per gli agenti. Lui è qualcuno che ha costruito strumenti basati sul presupposto del Markdown per molto tempo.
Quella persona ora ha dichiarato chiaramente: Il Markdown è diventato un formato restrittivo per me. Questo è il momento in cui un insider di Anthropic ha lanciato una pietra contro il presupposto su cui tutta l'industria ha cavalcato.
Per dirla semplicemente: il Markdown che ottieni da Claude Code, le regole che Cursor legge e gli output dell'AI sul tuo Wiki interno facevano tutti parte dello stesso flusso "Il Markdown va bene". La persona che lo ha creato ha iniziato a tracciare un canale diverso.
Da qui, entreremo nei dettagli del perché il Markdown non raggiunge le persone e con cosa sostituirlo.
5 Motivi per Cui il Markdown Non Viene Letto
Organizziamo i limiti del Markdown. Non si tratta di specifiche tecniche; riguarda la tua esperienza quotidiana dal lunedì al venerdì. Ho elencato i vantaggi dell'HTML dall'articolo originale capovolgendoli per mostrare i punti deboli del Markdown.
① Se supera le 100 righe, non lo leggi nemmeno tu
Thariq stesso scrive che quando un file Markdown supera le 100 righe, smette di leggerlo.
Quando chiedi a Claude Code di "riassumere le tendenze della concorrenza della scorsa settimana", probabilmente ti è capitato di chiudere la risposta di 120 righe senza scorrere. Se la persona che lo ha generato non lo legge, nessuno del team lo farà. La realtà è che non solo l'autore, ma anche gli altri membri dell'organizzazione, stanno solo dando un'occhiata superficiale.
② Anche se condiviso, non si apre bene nel browser, quindi nessuno lo tocca
Il Markdown non viene renderizzato in modo nativo e gradevole nei browser. Le interruzioni di riga si rompono in Slack, la formattazione viene rovinata nelle email e richiede sforzo convertirlo in PDF o fare screenshot per le proposte.
Ogni volta che lo condividi, qualcuno deve fare il lavoro di convertirlo in una "forma leggibile". Il Markdown è un formato che crea attrito ogni volta che viene condiviso, al punto che spesso i link non vengono nemmeno cliccati.
③ Niente colori o diagrammi, quindi viene trasmesso solo lo schema
Vuoi enfatizzare una differenza nei numeri, mostrare un avviso in rosso o mostrare un flusso con frecce. Per farlo in Markdown, finisci per disegnare diagrammi con caratteri ASCII o esprimere i colori con caratteri Unicode per box drawing.
Nessuno vuole decifrare quello, e chi scrive si stanca. Anche se Claude si sforza di disegnare un diagramma, finisce per essere solo scorso superficialmente.
④ Non puoi toccarlo o spostarlo, quindi finisce con la sola lettura
Vuoi provare un colore leggermente più calmo, testare la velocità di un'animazione o vedere come appare se aumenti un valore di 1,5 volte.
Nel business, ci sono frequenti situazioni in cui hai bisogno di "provarlo" per prendere una decisione. Non puoi farlo con il Markdown. Lo leggi, lo simuli nella tua testa e poi rimandi indietro istruzioni in testo: un ciclo inefficiente.
⑤ Si rompe quando viene aperto su mobile
Slack, email o Notion in movimento. Nel panorama business giapponese, metà dei materiali condivisi vengono aperti prima su mobile.
I layout del Markdown non seguono la larghezza dello schermo. Le tabelle traboccano orizzontalmente, i blocchi di codice vengono avvolti in modo goffo e le gerarchie delle intestazioni diventano invisibili. La voglia di leggere svanisce in quel momento.
Diamo un nome a questo. Ogni volta che produci Markdown illeggibile, la fatica si accumula sia per il mittente che per il destinatario ancor prima di aprirlo. Il costo di scorrere 100 righe, sistemare le interruzioni di riga in Slack, il fallimento comunicativo dovuto alla mancanza di diagrammi e colore, il ritardo nel giudizio perché non puoi interagire e la rottura su mobile.
Tutti questi sono costi nascosti pagati ogni giorno. In questo articolo, lo chiamiamo "Tassa del Formato."
Questa non è una tassa piccola. Più della metà del valore di Claude Code è determinato non dal contenuto dell'output, ma da "chi raggiunge e quanto arriva lontano." Producendo output in un formato che non raggiunge le persone, stai essenzialmente buttando via metà del tuo abbonamento.
Come Passare: Basta Aggiungere "Produce output come file HTML"
Non devi pensarci troppo. C'è molto meno da fare di quanto pensi.
Basta aggiungere una riga alla fine della tua solita richiesta a Claude Code. Le seguenti tre significano la stessa cosa:
- "Produce output come file HTML"
- "Produce output come pagina HTML singola"
- "Fai in modo che sia HTML in modo che il lettore possa aprirlo direttamente"
Se ti senti più a tuo agio a scrivere in inglese, "make a HTML file" o "make a HTML artifact" va bene. Il risultato è lo stesso.
Claude Code può estrarre il contesto da MCP, browser, git e file system. Il punto di forza di Claude Code è che può raggruppare fonti di informazioni molto più ampie in un singolo HTML rispetto alle versioni chat web di ChatGPT o Claude.ai.
Questo si collega a ciò di cui abbiamo parlato prima. Gli Artifacts che hai ricevuto in ChatGPT o Claude.ai e che pensavi fossero "bellissimi" erano prodotti come HTML.
Ora puoi ricevere quello stesso mondo lato Claude Code. Non è una storia tecnica difficile; cambiando una riga nel modo in cui chiedi, usciranno materiali che raggiungono davvero le persone.
Thariq sottolinea un punto nel suo articolo: "Non voglio che questo venga ancora trasformato in una Skill /html; voglio che le persone si abituino prima attraverso i prompt." Questo nonostante sia uno sviluppatore del team Claude Code che produce Skills.
Non sta liquidando l'idea di trasformarlo in una Skill. Sta dicendo: "Se lo impacchetti prima che l'uso si consolidi, perderai le parti che sono veramente efficaci."
All'interno di Anthropic, gli output HTML che sono diventati frequenti stanno iniziando a essere componentizzati in cose come i plugin Playground. Invece di aspettare un prodotto finito dall'inizio, provalo prima con un prompt di una riga per trovare lo schema che si adatta al tuo lavoro. Solo dopo aver raggiunto quel punto dovresti passare a trasformarlo in una Skill.
Scrivere "produce output in HTML" in ogni prompt potrebbe sembrare un compito, ma scegliere il formato stesso non lo è. Nel momento in cui passi da Claude che produce Markdown a Claude che produce HTML, hai fatto mezzo passo verso essere colui che "progetta l'output prima di aspettare una Skill pre-progettata."
5 Scenari Business Che Cambiano Semplicemente Passando all'HTML
Questo capitolo è efficace per il lavoro reale dal lunedì al venerdì. Ho riordinato i cinque casi d'uso dell'articolo originale in ordine di frequenza nel panorama business giapponese: Report Settimanali/Riassunti di Ricerca, Confronto Parallelo di Proposte, Modifiche di Design, Schermate di Modifica per il Processo Decisionale e Revisioni PR/Specifiche.
Ogni scena è riassunta con il problema attuale, il Prima/Dopo e infine un'istruzione di esempio da dare a Claude Code.
[Scena 1] Consegna di Report Settimanali e Riassunti di Ricerca con Diagrammi
Un evento comune nel business giapponese. Lunedì mattina, il tuo capo chiede: "Riassumi le tendenze della scorsa settimana."
Prima: Incolli 120 righe di Markdown in Slack. Le interruzioni di riga si rompono. Il tuo capo non lo apre. Non viene incluso nei materiali delle riunioni dirigenziali. Finisci per spiegarlo verbalmente, dicendo: "L'ho fatto fare a Claude."
Dopo: Lo riassumi in una singola pagina HTML che incorpora i log di Slack, la cronologia dei ticket di Linear o Notion, i log git e i documenti interni. Includi un semplice diagramma di flusso business usando SVG e posizioni tre punti chiave in blocchi colorati in fondo.
Se metti questo nell'archivio interno e condividi l'URL, il tuo capo può aprirlo sul telefono mentre fa il pendolare, la direzione può citarlo e può essere incollato nei verbali delle riunioni.
Il punto chiave qui è che Claude Code può estrarre il contesto da MCP, browser, git e file system. Anche se chiedi a una chat web di "fare un HTML", è difficile raggruppare così tante fonti di informazioni in una sola. Questo è un report settimanale che solo Claude Code può creare.
Thariq stesso ha scritto di aver realizzato i diagrammi per i suoi articoli facendo leggere a Claude Code tutto l'HTML nella sua cartella di codice e riassumendoli in una pagina. Un "report settimanale che viene letto" e un "diagramma per un articolo esplicativo che viene letto" sono strutturalmente la stessa cosa.
▼ Istruzione di Esempio:
"Leggi tutte le interazioni Slack della scorsa settimana, i completamenti dei ticket Linear e i log git, e produci un report settimanale come singola pagina HTML che il mio capo possa capire in 1 minuto. Includi un semplice diagramma di flusso business in SVG e tre punti chiave in blocchi colorati in fondo. Assicurati che non si rompa quando viene aperto su uno smartphone."
[Scena 2] Mostrare 6 Opzioni di Proposta/Ricerca Affiancate
Quale direzione dovremmo prendere per la proposta della prossima settimana? Una scena comune nella pianificazione, nelle vendite e nella pianificazione aziendale in cui vengono create più opzioni e allineate con i decisori.
Prima: Invi sei opzioni in sei file Markdown separati. Il cliente non può aprirle e confrontarle una per una. Chiedono: "Qual è la tua raccomandazione principale?" e ti rendi conto che non le avevi confrontate completamente nemmeno tu.
Dopo: Disponi sei opzioni con toni, densità e pubblico di destinazione diversi in una griglia su una singola pagina HTML. Aggiungi un compromesso in una riga sotto ogni opzione. Il decisore le confronta tutte su uno schermo e risponde immediatamente: "Voglio mescolare questa e questa" o "Usa il target della #3 con la densità della #1." La risoluzione della discussione cambia nel momento in cui le mostri in parallelo.
Per un decisore, il tempo necessario per giudicare è abissalmente diverso tra ricevere sei file e avere sei opzioni allineate su uno schermo. Si tratta meno di "farle leggere" e più di "permettere loro di prendere una decisione."
▼ Istruzione di Esempio:
"Crea 6 opzioni di proposta per la presentazione della prossima settimana con toni, densità e pubblico di destinazione diversi, e disponile in una griglia su una singola pagina HTML. Scrivi un compromesso in una riga sotto ogni opzione. Inoltre, aggiungi un pulsante in fondo per copiare il risultato come Markdown una volta presa una decisione."
[Scena 3] Decidere su Design e Prototipi Toccandoli
Quando si decide su colori, dimensioni o movimenti, dovresti rinunciare ad allinearti tramite testo. Questa è una scena in cui marketing, PR e pianificazione vanno avanti e indietro molte volte su email di ringraziamento o pulsanti di landing page.
Prima: Comunichi con parole come "un blu leggermente più calmo" o "rendi il movimento morbido." L'immagine del destinatario si discosta ogni volta. Guardando la versione che torna dopo un giro, aggiungi più parole: "No, non quel tipo di calmo."
Dopo: Fai creare a Claude Code un HTML in cui puoi muovere cursori per il colore e la velocità dell'animazione. Crei prototipi per i pulsanti delle email di ringraziamento o i pulsanti CTA delle LP come singole pagine HTML e invii l'URL alle parti interessate. Tutti lo toccano, decidono i valori migliori e copiano semplicemente quei valori di nuovo a Claude. Lo scambio di testo diminuisce e il tempo per raggiungere un accordo si accorcia.
In relazione a questo, Anthropic Labs sta iniziando a formalizzare questo concetto di "tocca per decidere e copia l'operazione di nuovo a Claude" come plugin Playground. L'output HTML non è solo un piccolo trucco; è una direzione che Anthropic stessa sta coltivando come schema.
▼ Istruzione di Esempio:
"Crea un HTML in cui posso decidere il colore e la velocità dell'animazione del pulsante nell'email di ringraziamento usando tre tipi di cursori. Aggiungi un pulsante in fondo per copiare i valori decisi."
[Scena 4] Creare una Schermata di Giudizio in 3 Minuti
Quali misure dovrebbero essere assegnate a Ora, Prossimo, Dopo o Tagliato per il prossimo trimestre? Ordinare 30 ticket per decidere le priorità è un tipico "compito di giudizio" per PdM, pianificatori e pianificazione aziendale.
Prima: Allinei 30 elementi in un foglio di calcolo e compili manualmente la colonna delle priorità uno per uno. Ordini, ripensi, sposti in un altro foglio e sposti indietro. Alcuni giorni passi 30 minuti e non hai ancora una conclusione.
Dopo: Chiedi a Claude Code di "fare un HTML in cui posso trascinare e rilasciare gli elementi in quattro colonne: Ora, Prossimo, Dopo e Tagliato." Una schermata di modifica dedicata è pronta in 3 minuti. Trascini le 30 carte e, quando hai finito, copi i risultati. Il tempo per i compiti di giudizio si riduce di un ordine di grandezza.
C'è un principio di progettazione qui che è facile da trascurare ma molto efficace. È la frase in cui Thariq scrive: "Finisci sempre con un esportazione." Quando crei una schermata di modifica, includi sempre pulsanti per "Copia come JSON", "Copia come Prompt" o "Copia come Markdown."
Senza questo, non puoi restituire i risultati del tuo ordinamento a Claude e finisce solo come uno strumento per attività. Una schermata di modifica diventa un dispositivo di giudizio solo quando crei un ciclo: giudica in HTML, poi restituisci il risultato testuale strutturato a Claude.
Questa stessa idea può essere usata per modificare flag di funzionalità, editor di prompt di sistema affiancati o set di dati per approvare/rifiutare/etichettare. "Creare un'interfaccia utente dedicata e usa e getta in 3 minuti" è dove il vero valore di Claude Code è più chiaramente dimostrato.
▼ Istruzione di Esempio:
"Crea un HTML in cui posso trascinare e rilasciare 30 misure per il prossimo trimestre in quattro colonne: Ora, Prossimo, Dopo e Tagliato. Alla fine, posiziona un pulsante 'Copia come Markdown' in modo da poter produrre i risultati dell'ordinamento con le ragioni per ogni riga."
[Scena 5] Gestire la Condivisione di Revisioni PR e Specifiche con Differenze Colorate
Infine, una scena per collaborare con gli ingegneri. Anche se non leggi codice, come PdM, direttore o editor, potresti essere chiamato per revisioni PR o conferme di specifiche.
Prima: Ti viene chiesto di aprire la schermata delle differenze di GitHub. Non riesci a capire quale parte della differenza è importante e quale può essere ignorata solo guardando. Devi leggere i commenti per seguire la storia. Le persone che non leggono codice spesso dicono solo "fammi sapere se c'è qualcosa" e lo chiudono.
Dopo: Chiedi a Claude Code di "trasformare questa PR in un documento di revisione HTML che qualcuno che non legge codice possa capire in 30 secondi." I commenti sono allegati accanto alle differenze, l'ambito dell'impatto è colorato e viene fornito un riepilogo di tre preoccupazioni alla fine. Se carichi questo nell'archivio interno e condividi l'URL, i PdM e i direttori possono fornire feedback con un pulsante. Coloro che collaborano con gli ingegneri possono finalmente partecipare alle revisioni.
L'HTML non è un linguaggio per ingegneri; è uno strumento per consegnare una storia. Il significato della differenza, i rischi e l'ambito dell'impatto — queste "informazioni che richiedono decifrazione" vengono consegnate con annotazioni, colore e layout. Questo è il significato della conversione in HTML.
▼ Istruzione di Esempio:
"Trasforma questa PR in un documento di revisione HTML che qualcuno che non legge codice possa capire in 30 secondi. Allega commenti accanto alle differenze, mostra l'ambito dell'impatto con codifica a colori e riassumi tre preoccupazioni alla fine."
Mentre continui a produrre output in Markdown per queste cinque scene, la tassa del formato si accumula silenziosamente ma quotidianamente. Se la fermi nel momento in cui la noti farà la differenza a partire dalla prossima settimana.
6 Domande Che Sorgono Quando Si Passa all'HTML
Leggendo questo, probabilmente ti vengono in mente diverse domande. Ho riordinato la sezione FAQ dell'articolo originale nell'ordine in cui è probabile che i lettori business giapponesi le incontrino.
■ Usa più token?
Sì, li usa. L'articolo originale afferma che la generazione richiede da 2 a 4 volte più tempo rispetto al Markdown. Tuttavia, Opus 4.7 ha un contesto di 1 milione di token, quindi il rischio che le conversazioni si interrompano a causa dei limiti di contesto restituendo HTML è praticamente scomparso.
La conclusione di Thariq è: "I numeri aumentano, ma se scegli il risultato che viene letto, ripaga per il lavoro totale." È una scelta se usare il tuo contratto mensile di oltre 3.000 yen per 1.000 righe di Markdown illeggibile o una pagina HTML che viene aperta.
■ Il design non sarà brutto?
Questa è una preoccupazione valida, ma ci sono contromisure.
Una è usare i plugin di design frontend di Claude Code. Un'altra è fornire a Claude un esempio HTML dal sito della tua azienda o da materiali esistenti. Se fornisci un file di riferimento e dici "con questo tono" o "con questo font e questa palette", Claude produrrà HTML che corrisponde all'aspetto della tua azienda. Tenere un file come design-system.html nel tuo codebase ti permette di farvi riferimento ogni volta.
■ Modificare l'HTML non è una seccatura?
Non devi modificarlo tu stesso.
Thariq stesso scrive che non tocca direttamente l'HTML. Se dici a Claude: "Calma un po' questo colore" o "Rendi la terza sezione un po' più piccola", lo sistemerà per te. Finché lo usi per specifiche, brainstorming o materiali di riferimento, puoi lasciare tutte le modifiche a Claude.
■ Come lo apro? Come lo condivido?
Aprirlo è facile. Basta aprire il file HTML che Claude Code ha prodotto localmente nel tuo browser.
Puoi persino chiedere a Claude di "aprire questo file" e potrebbe aprirlo nel tuo browser per te. Quando lo condividi, il modo più semplice è caricarlo nell'archivio interno o su S3 e fornire l'URL. Se incolli il link in Slack o email, il destinatario può aprirlo nel suo browser. Quel passaggio extra di convertire il Markdown in PDF scompare completamente.
■ E il controllo versione?
Ad essere onesti, l'HTML non è molto adatto per la gestione delle differenze in Git. Sistemare una riga potrebbe spostare le differenze altrove a causa delle impostazioni del formattatore. Thariq stesso scrive che l'HTML è il punto debole più grande del controllo versione.
Ecco perché la soluzione pratica è: I "consegnabili per le persone" sono HTML, e le "specifiche o registrazioni di cui vuoi mantenere la cronologia" sono Markdown. Non si tratta di abolire il Markdown, ma di passare a una mentalità di scelta del formato in base allo scopo dell'output.
■ Posso smettere del tutto di usare il Markdown?
No. I registri, le cronologie delle modifiche e il testo strutturato che vuoi mantenere nel repository dovrebbero rimanere come Markdown.
CLAUDE.md e SKILL.md sono più facili da gestire e tracciare le differenze se rimangono come Markdown. L'HTML è adatto per "consegnare alle persone", "far toccare alle persone", "allineare più opzioni" e "far giudicare alle persone con il colore." Se lo capisci in generale come "Markdown per interagire con l'AI, HTML per distribuire alle persone", non ti perderai.
A questo punto, i tuoi dubbi iniziali dovrebbero essere chiariti. Un articolo che include gli svantaggi è più affidabile — questa è la mia convinzione come scrittore.
Continuerai a Pagare la Tassa del Formato o Passerai al Lato del Design?
Per concludere, alziamo la nostra prospettiva.
Abbiamo già parlato della "Prompt Tax" — il costo di riscrivere le stesse premesse a Claude. Poi, la storia del passaggio al livello di progettazione con la cartella .claude. Questa "Format Tax" è il terzo tema di quella serie. Dopo il livello conversazionale e il livello di progettazione, abbiamo ora affrontato il livello di output.
Definiamo "Format Tax" come qualcosa che possiamo condividere con i lettori:
Se continui a scegliere formati di output che nessuno legge, la fatica si accumula sia per te che per gli altri, ancor prima di aprirli. Paghi oltre 3.000 yen al mese per Claude Code, eppure i deliverable non vengono mai usati nelle riunioni. Quella sensazione deriva dal non aver fatto una scelta consapevole sul formato. Questa è la Format Tax.
Produrre output in Markdown è un compito. Scegliere HTML è una decisione. Anche usando lo stesso Claude Code, una singola decisione nella selezione del formato cambia significativamente la distanza che i tuoi deliverable possono raggiungere.
E HTML non è un linguaggio per ingegneri. È uno strumento per creare materiali che vengono letti. Metti da parte per un momento l'idea di costruire un sito web. Prova semplicemente a produrre in HTML il report settimanale, la proposta o il documento di revisione che stai scrivendo questa settimana. Basta questo.
Parliamo del quadro generale.
L'era in cui Markdown era lo standard implicito dell'industria AI sta silenziosamente finendo all'interno di Anthropic. Mentre CLAUDE.md, SKILL.md e le regole di Cursor erano tutte costruite su una premessa Markdown, il formato di output sta iniziando a cambiare per primo. I lettori che assistono al momento in cui lo standard cambia possono muoversi mezzo passo avanti.
Naturalmente, una volta che realizzi "lo faccio ogni settimana", puoi poi scegliere di evolvere questa pratica in una Skill.
All'interno di Anthropic, i pattern ad alta frequenza per l'output HTML, come i Playground legati al design, vengono gradualmente coltivati come componenti. Tuttavia, per la prima settimana, un prompt di una riga è sufficiente. Stasera, prova a produrre un solo report settimanale in HTML. La settimana prossima, prova a allineare sei opzioni di proposta in una singola griglia. Inizia da lì, e la Format Tax inizierà silenziosamente a diminuire.
Thariq stesso scrive alla fine del suo articolo: "Avevo paura di smettere di leggere approfonditamente Markdown e di lasciare tutte le decisioni a Claude. Da quando sono passato a HTML, sento di essere di nuovo nel loop con Claude, e soprattutto, è semplicemente divertente creare."
Scegliere un formato è un interruttore per riprendere l'iniziativa quando si lavora con l'AI, e allo stesso tempo, un interruttore per riportare un po' di calore nel tuo lavoro quotidiano.
Continuerai a produrre Markdown non letto, o passerai dalla parte di chi sceglie il formato? La prossima settimana sarà il confine.
Riepilogo
- Lo sviluppatore che costruisce Claude Code in Anthropic ha dichiarato di non usare più Markdown. L'adozione di HTML si sta diffondendo all'interno del team.
- Fino ad ora, Markdown era lo standard implicito per l'AI — da Claude Code e Cursor a GitHub Copilot, Cline, Wiki interni e output di ChatGPT. Il creatore ha ora sfidato quello standard di settore.
- Ci sono 5 motivi per cui Markdown non viene letto: non si può rileggere a 100 righe / si rompe quando viene condiviso / niente colori o diagrammi / non si può toccare per giudicare / si rompe su mobile. Questi costi nascosti sono la "Format Tax".
- Per cambiare, basta aggiungere una riga: "Output come file HTML." Trasformarlo in una Skill può aspettare fino a quando l'uso non sarà consolidato.
- 5 scenari lavorativi — report settimanali, proposte parallele, modifiche di design, schermate di giudizio e revisioni PR — si trasformano in materiali che vengono aperti, giudicati e restituiti semplicemente passando a HTML.
- Scegliere un formato è una decisione, non un compito. Produrre output in Markdown è un compito; scegliere HTML è una decisione. La differenza tra gli utenti di Claude Code si apre qui.
Per chi ha trovato utile questo articolo:
Il Laboratorio Claude Code dell'Università di Tokyo (@ClaudeCode_UT) è un account gestito seriamente da un team di studenti dell'UTokyo. Stiamo anche lavorando allo sviluppo congiunto di business Claude Code con grandi aziende, e condividiamo solo design e know-how che funzionano realmente sul campo.
Consegniamo ogni giorno informazioni e know-how "genuinamente utili" specializzati per il lavoro pratico 👇
■ Rilascio gratuito di competenze Claude Code utilizzabili nella pratica
■ Traduzione e ristrutturazione di informazioni primarie AI dall'estero in un contesto aziendale giapponese
■ Questo è l'unico posto dove ricevere gratuitamente competenze e strumenti sviluppati seriamente dal team UTokyo che sono "genuinamente utili" ❗️
Se sei interessato, seguici e dai un'occhiata.
LINE è qui ⇩
