Stai scrivendo queste istruzioni per un modello precedente?
"Leggi questo documento ogni volta", "Fai sempre un test", "Conferma prima di iniziare". Molte persone probabilmente hanno aggiunto queste istruzioni per evitare che Codex fallisse.
Poiché risolveva le cose senza leggere la documentazione, hai scritto di leggerla prima. Poiché procedeva senza permesso, hai scritto di confermare prima di andare avanti.
Sebbene quelle frasi avessero una ragione all'epoca, potrebbero non essere altrettanto utili quando il modello cambia.
Le procedure decise per assistere i modelli precedenti potrebbero essere troppo dettagliate per GPT-6 Astra. Al contrario, poiché non hai comunicato l'ambito previsto, potrebbe fermarsi per chiedere conferma inutilmente.
Ciò che deve essere rivisto non è solo la quantità di istruzioni. Si tratta di ridurre i compiti ripetitivi e chiarire gli scenari necessari e le condizioni di completamento.
Eric Provencher, che gestisce l'esperienza sviluppatore di Codex in OpenAI, affronta questo problema in un articolo intitolato "Ripensare competenze e prompt per GPT-6 Astra."
Questo copre non solo le richieste che scrivi in chat, ma anche "AGENTS.md", che trasmette le regole di lavoro per i file di progetto in un repository.
Le "Skills" sono raccolte di procedure e conoscenze utilizzate per attività specifiche. Le istruzioni salvate qui influenzano anche il modo in cui Codex procede.
In questo articolo, basandoci sulle spiegazioni di Eric e sulle immagini di riferimento, vedremo cosa ridurre, cosa mantenere e come riscrivere. Gli esempi creati per i lettori sono contrassegnati come "Esempi Applicativi" per distinguerli dagli esempi originali.
Non si tratta di incolpare tutti i fallimenti di Astra sulle vecchie istruzioni. È un articolo per revisionare le regole che hai accumulato per vedere quali non sono più adatte al lavoro corrente.
1. Perché Devi Rivedere le Istruzioni per Astra
Il punto di partenza di Eric è il cambiamento per cui le istruzioni destinate a "fare da babysitter" al modello stanno diventando meno necessarie rispetto a prima.
In precedenza, alcune attività non procedevano a meno che non specificassi ogni singolo passo in ordine. Per compensare l'ambiguità, abbiamo accumulato procedure e note dettagliate.
Tuttavia, il testo originale afferma che i modelli stanno diventando più bravi a gestire sottili differenze di significato e ambiguità. Sottolinea che le specifiche dettagliate che un tempo erano utili possono ora ostacolare i risultati.
Ciò che non dobbiamo fraintendere qui è che non si tratta di una conversazione sullo "smettere di fornire spiegazioni perché il modello è più intelligente."
Eric raccomanda anche di mantenere le indicazioni sui materiali necessari. Il testo originale chiede ancora spiegazioni riguardo all'ambito sicuro di avanzamento e al lavoro richiesto per il completamento.
Anche per la stessa istruzione, il modo in cui la rivedi cambia a seconda di ciò che quella frase intende comunicare.
Ad esempio, devi distinguere tra spiegazioni che trasmettono circostanze specifiche del progetto e quelle destinate a far seguire le procedure ai modelli precedenti.
"I vincoli di progettazione sono scritti in questo documento" è un indizio per trovare informazioni. D'altra parte, "Leggi questo intero documento dall'inizio per ogni modifica" fissa uniformemente i tempi di lettura.
Informare il modello dell'esistenza di un documento non equivale a fargli leggere tutto ogni volta.
Inoltre, "L'accesso alla produzione è vietato" e "Conferma anche prima di eseguire i test in locale" fermano azioni diverse.
Solo perché vuoi sostenere il primo non significa che il secondo sia sempre necessario. Tuttavia, se non è chiaro se qualcosa rimanga veramente in locale, non dovresti nemmeno saltare quella conferma.
Le Skills, AGENTS.md e le richieste quotidiane menzionate nel testo originale riguardano tutti questi giudizi. Anche se correggi una frase in chat, se la stessa restrizione rimane altrove, la revisione non è completa.
Ad esempio, cosa succede se scrivi "Finiscilo finché non funziona" in una richiesta, ma la procedura applicata dice ancora "Fermati sempre alla prima implementazione e richiedi una revisione"?
Questo è un esempio per spiegare istruzioni contrastanti. Come minimo, senza organizzare quale delle due l'utente desidera, il punto finale della richiesta non è allineato.
Quando rivedi, non giudicare in base a "è lungo, quindi taglialo." Guarda se quella frase trasmette conoscenze necessarie, determina l'ambito di lavoro o semplicemente fa ripetere al modello le procedure precedenti.
Anche se il testo è breve, se l'obiettivo di "conferma tutto" è vago, non è necessariamente una buona istruzione. A volte, anche se è un po' più lungo, è meglio comunicare l'intento chiarendo le condizioni di lettura o dove fermarsi.
2. Istruzioni da Ridurre: Caricamento Ripetitivo e Passi Eccessivamente Dettagliati
La prima cosa da revisionare sono le regole di caricamento che si attivano indipendentemente dal contenuto del lavoro.
Eric spiega che far leggere al modello enormi quantità di documentazione o l'intera guida del repository per una semplice correzione di un refuso è eccessivo.
Leggere i documenti inserisce quel contenuto nelle informazioni di lavoro del modello. Il testo originale sottolinea il problema di consumare il contesto disponibile e rallentare il lavoro caricando spiegazioni irrilevanti.
Il contesto qui si riferisce al fascio di informazioni a cui il modello fa riferimento per quel compito. Se continua ad aumentare, ci si avvicina al punto in cui la cronologia delle conversazioni e del lavoro deve essere compressa.
Pertanto, piuttosto che ridurre semplicemente il numero di riferimenti, distingui cosa deve essere letto per la richiesta corrente.
Esempio A: Traduzione Giapponese dell'Immagine di Riferimento
Prima della Revisione
Leggi sempre architecture.md, database.md e deployment.md per intero prima di modificare.
Dopo la Revisione
Fai riferimento a architecture.md quando gestisci i confini tra servizi, a database.md quando modifichi le strutture DB e a deployment.md quando ti prepari per il deployment.
Ciò che è stato mantenuto sono le guide ai tre documenti. Ciò che è stato modificato sono le condizioni per aprirli.
In questo esempio, architecture.md riguarda ruoli e connessioni tra servizi. database.md riguarda la struttura del database. deployment.md riguarda la riflessione di ciò che è stato creato nell'ambiente di esecuzione.
Nella versione "Prima", la regola "leggi tutto" si applica anche a una richiesta di correggere un singolo refuso. Nella versione "Dopo", se il compito è modificare la struttura del DB, si procede al corrispondente database.md.
Questo non significa che leggere altri documenti sia proibito. Se un compito abbraccia più aree, i documenti necessari non si limitano a uno.
Creare un'altra regola uniforme come "scegli solo un documento" da questo esempio si allontanerebbe dall'intento originale.
Non abbiamo eliminato documenti necessari o assottigliato il contenuto. Abbiamo riscritto la condizione che richiedeva di controllare tutti i documenti anche per piccole modifiche per adattarla al contenuto del lavoro.
Eric menziona anche di mantenere i documenti aggiornati. Anche se organizzi le condizioni di riferimento, è necessario un controllo separato per assicurarti che non rimangano vecchie spiegazioni a destinazione.
Esempio B: Esempio Applicativo Basato sul Testo Originale
Il prossimo è un esempio applicato a uno scenario in cui Codex è incaricato di articoli, video o post sui social media. Questa non è una procedura di produzione pubblicata da Eric stesso.
Prima della Revisione
Per la creazione di contenuti, leggi tutte le procedure per articoli, video e post sui social media.
Dopo la Revisione
Fai riferimento a writing.md per la scrittura di articoli, a video.md per la produzione video e a social.md per la creazione di post sui social media. Per richieste multi-formato, fai riferimento alle procedure pertinenti.
Ancora una volta, le procedure specifiche per articoli, video e social media sono mantenute. Ciò che è cambiato è la parte che faceva leggere al modello tutte le procedure sotto l'ampio ombrello di "creazione di contenuti."
Se chiedi un articolo, si procede alle istruzioni per l'articolo. Se chiedi un articolo e il suo post di annuncio insieme, si procede sia alle procedure per l'articolo che a quelle per i social media.
Se non c'è richiesta per un video, non richiede più il caricamento dell'intero processo di produzione video al punto di ingresso comune.
Il testo originale chiama questo approccio di fornire spiegazioni necessarie in fasi "divulgazione progressiva." È un metodo per posizionare le spiegazioni al punto di ingresso per giudicare la destinazione, separando al contempo conoscenze dettagliate e procedure in documenti successivi.
Ad esempio, se allinei le procedure complete per articoli, video e social media all'ingresso, ogni richiesta si traduce nella lettura di una spiegazione enorme.
Invece, limita il ruolo del punto di ingresso a una guida: "Se è un articolo, vai a questo documento; se è un video, vai a quell'altro." Mantieni le spiegazioni dettagliate senza scartarle, permettendo che vengano lette quando necessario.
Eric spiega che per le Skills con più procedure di lavoro, il documento iniziale dovrebbe essere una guida minima. Dovrebbe fornire informazioni appena sufficienti per procedere ai documenti correlati o agli script che eseguono il compito.
Crea uno stato in cui guardare solo il punto di ingresso ti dice a quale documento procedere. Riassumere semplicemente spiegazioni lunghe in brevi non completerà questa organizzazione dei riferimenti.
Se tralasci le precauzioni necessarie nel riassunto, diventa un problema diverso. Ciò che viene mantenuto nell'esempio applicativo sopra sono le procedure uniche per ogni formato.
Anche il Test è Impostato su "Sempre, a Prescindere da Tutto"?
Il testo originale afferma che i modelli precedenti dovevano essere sollecitati a testare e confermare il lavoro. D'altra parte, Astra lo fa da solo, quindi le stesse istruzioni possono portare a test ridondanti non necessari.
Non fraintendere questo come "Astra non ha bisogno di test." Il problema non è fermare i controlli, ma se le istruzioni stanno causando controlli ridondanti.
Se applichi questo alle tue impostazioni, guarda quale controllo stai richiedendo per quale modifica. Il contenuto delle ispezioni necessarie e le condizioni per ripeterle uniformemente ogni volta che fai qualcosa possono essere revisionati separatamente.
Poiché questo articolo non confronta il numero di test o il tempo di elaborazione, non mostra un effetto come "riscrivere farà risparmiare X minuti." L'obiettivo della revisione è se riesci a distinguere tra ispezioni necessarie e ripetizioni ridondanti.
3. Restringere le Istruzioni: Quando Dovrebbe Essere Usata Questa Skill?
Aggiungere più Skills non le rende necessariamente più facili da scegliere. Eric richiama l'attenzione sulla pratica di scaricare e aggiungere enormi quantità di Skills.
Secondo il testo originale, il nome e la descrizione di ogni Skill vengono caricati nel contesto affinché il modello giudichi quando usarle.
Qui, distingui tra caricare il nome/descrizione e caricare il corpo della Skill. Questo non significa che il modello legga ogni corpo di Skill dall'inizio.
Il modello usa prima il nome e la descrizione come indizi per giudicare quale usare questa volta. Se quelle descrizioni sono troppo lunghe o ci sono troppe Skills, il testo originale afferma che Codex accorcerà le descrizioni per adattarle.
Di conseguenza, il modello potrebbe vedere solo una parte della descrizione di ogni Skill, rendendo più difficile la scelta. Anche se le procedure necessarie sono salvate, la spiegazione del punto di ingresso potrebbe non essere completamente trasmessa.
Inoltre, Eric menziona contraddizioni tra descrizioni o descrizioni che cercano di farsi usare per tutto. Queste possono causare il caricamento di istruzioni che non sono utili per il compito.
Quindi, non si tratta di riempire le descrizioni con termini tecnici per far sembrare ampia la copertura. Crea la descrizione in modo che il modello sappia se deve essere chiamata per il lavoro corrente.
Traduzione Giapponese dell'Immagine di Riferimento
Prima della Revisione
Crea e verifica le migrazioni dello schema PostgreSQL. Usa per lavori che coinvolgono database, query, modelli e persistenza.
Dopo la Revisione
Crea e verifica le migrazioni dello schema PostgreSQL. Usa per aggiungere/modificare migrazioni o rivedere le procedure dell'applicazione.
PostgreSQL è un tipo di database. "Migrazione dello schema" si riferisce al compito di modificare la struttura delle tabelle e degli elementi che fungono da contenitori di dati e applicare tali modifiche.
Ad esempio, è uno scenario in cui modifichi la struttura del database per aumentare gli elementi da salvare. Qui, è citato come esempio di spiegazione del significato dei termini.
D'altra parte, le "query" nella descrizione "Prima" sono richieste per recuperare o manipolare dati. La "persistenza" si riferisce al salvataggio dei dati in modo che possano essere utilizzati in seguito.
Questi sono termini correlati ai DB, ma non tutto il lavoro che coinvolge i DB costituisce un compito di migrazione che modifica la struttura.
La prima frase della versione "Prima" mostra un compito specializzato: "Crea e verifica le migrazioni." Tuttavia, la seconda frase include un lavoro ampio relativo ai database nelle condizioni di utilizzo.
Questa discrepanza nell'ambito è ciò che viene corretto nell'immagine di riferimento. L'area di competenza della Skill e le condizioni di chiamata non corrispondono.
Dopo la revisione, il ruolo di "Crea e verifica le migrazioni dello schema PostgreSQL" rimane. Inoltre, è stato ristretto ai casi di aggiunta di migrazioni, modifica di migrazioni o revisione delle procedure dell'applicazione.
Ad esempio, se vuoi solo controllare una query per recuperare dati esistenti, non devi necessariamente chiamare questa Skill di migrazione solo perché è "correlata al database."
Al contrario, se si tratta di una revisione su come applicare le modifiche strutturali, è ancora un obiettivo nella descrizione "Dopo." Restringere il campo non ha perso il lavoro specializzato.
Il punto di conferma quando si correggono le descrizioni non è solo "di cosa è esperta questa Skill?" È se si può leggere "per quale richiesta verrà utilizzata e a quali richieste non verrà estesa?"
Se scrivi semplicemente "Skill DB" per renderlo più breve, le condizioni di chiamata scompaiono. Ciò che il testo originale chiede è di rendere la descrizione il più breve possibile mantenendo chiari gli scenari di utilizzo.
Puoi usare il "Prima/Dopo" sopra per verificare se il lavoro richiesto e le condizioni di applicazione corrispondono, piuttosto che fare affidamento sulla forza del nome o sulla lunghezza della descrizione.
4. Chiarire le Istruzioni: Quanto Andare Avanti e Cosa Definisce il Completamento
Da qui, parliamo di aggiungere spiegazioni necessarie. Solo ridurre il caricamento e le procedure non gestirà il problema di fermarsi a metà strada.
Eric afferma che mentre Astra lavora diligentemente, a volte può essere cauta su quanto andare avanti. Come comunicare l'intervallo in cui vuoi che continui è anche un obiettivo della revisione menzionata nel testo originale.
In particolare, se hai scritto "Conferma sempre prima" in modo forte perché un modello precedente si muoveva senza permesso, revisiona quel confine.
Ciò che il testo originale sottolinea è la possibilità di fermarsi in un punto in cui in realtà era okay continuare, solo per seguire rigorosamente il confine. Non si tratta di dire di ignorare le istruzioni di conferma, ma di riscrivere ciò che stavi permettendo.
A: Chiarire l'Ambito di Approvazione
Il testo originale ha un esempio di un test locale che utilizza dati di test usa e getta e non accede alla produzione. Questo è un esempio di permesso per quel compito specifico all'interno del tuo ambiente di lavoro.
Il seguente "Prima" è un esempio applicativo creato per contrasto. Il "Dopo" contiene una traduzione giapponese delle istruzioni per il test locale dal testo originale.
Prima della Revisione: Esempio Applicativo per Contrasto
Richiedi approvazione ogni singola volta prima di eseguire un test e prima di correggere un fallimento.
Dopo la Revisione: Traduzione dell'Esempio Originale
I test locali utilizzano dati di test usa e getta e non accedono alla produzione. Procedi senza cercare approvazione in ogni fase fino all'esecuzione dei test, alla correzione dei fallimenti causati dalle modifiche richieste e alla riesecuzione dei test interessati.
Ciò che è stato mantenuto sono l'ambiente di destinazione e l'ambito di lavoro. Ciò che è stato modificato è la condizione per cercare approvazione ogni volta all'interno di quell'ambito.
"Dati di test usa e getta" e "nessun accesso alla produzione" non sono prefazioni decorative. Sono premesse per giudicare se questa istruzione può essere utilizzata.
Se in realtà è un test che si connette alla produzione, scrivere "nessun accesso alla produzione" non cambia l'ambiente. A volte viene chiamato "locale" ma non è chiaro se soddisfi quelle condizioni. Lascia le condizioni non verificabili così come sono.
Inoltre, la correzione consentita è per "fallimenti causati dalle modifiche richieste." Non è un'istruzione estesa per permettere di correggere tutti i problemi trovati nel test.
L'obiettivo della riesecuzione è anche scritto come "test interessati." È diverso da una specifica uniforme per ripetere tutti i test ogni volta.
Questa frase specifica le azioni che possono procedere, ma non elimina l'approvazione per altri compiti. Mostra quanto delegare un insieme di compiti che sono stati confermati come sicuri.
Non devi arrivare fino a "permettere tutto perché fermarsi ogni volta è una seccatura." Se separi i compiti per cui non vuoi che si fermi da quelli per cui vuoi ancora che venga restituito un giudizio, il significato della richiesta cambia.
B: Chiarire le Condizioni di Completamento
Eric spiega che se sei abituato a GPT-5.6 Sol, che lavora a lungo, il modo di fermarsi di Astra potrebbe sembrare cauto.
Nella fase in cui l'implementazione iniziale è fatta, anche se rimane del lavoro, potrebbe tornare per richiedere una revisione. Pertanto, raccomanda di decidere le condizioni di completamento prima di iniziare.
Ciò che è necessario è solo l'implementazione, o fino all'esecuzione per confermare? Inoltre, è fino alla correzione dei bug trovati durante la conferma?
La persona che emette la richiesta organizza prima queste differenze. Un traguardo difficile da comunicare con solo "completalo" viene scritto come un compito.
Quello che segue è un esempio applicativo in cui la spiegazione originale viene sostituita con la creazione di un modulo di richiesta informazioni. Non è il testo della richiesta effettiva di Eric o un risultato della verifica del comportamento effettivo.
Prima della Revisione
Crea un modulo di richiesta informazioni. Fammi controllare una volta implementato.
Dopo la Revisione
Crea un modulo di richiesta informazioni. Questa volta, conferma in locale che può rilevare campi obbligatori vuoti e indirizzi email non validi e che la schermata di completamento appare dopo un invio di prova. Correggi eventuali bug causati da questa modifica e segnalali insieme ai risultati della conferma. Non pubblicare in produzione o inviare email reali.
Ciò che è stato mantenuto sono lo scopo di creare il modulo di richiesta informazioni e di segnalare i risultati a un umano. Ciò che è stato modificato è quanto verificare prima della segnalazione.
Nella versione "Prima", la richiesta è "Fammi controllare una volta implementato." Anche se si ferma al punto dell'implementazione iniziale, non si è discostato dalle istruzioni.
Se vuoi vedere il design a metà strada, quel modo di fermarsi ha un significato. Se è una fermata per confermare parti su cui non hai ancora deciso, è un'istruzione con una ragione per rimanere.
D'altra parte, se ciò che vuoi questa volta è un modulo che ha completato i controlli operativi, includi quei controlli nella richiesta. L'esempio elenca campi vuoti, email non valide e la visualizzazione dopo l'invio di prova.
Rispetto al semplice "controlla se funziona correttamente," gli stati da provare sono specifici. Se vengono trovati bug causati da questa modifica durante la conferma, l'obiettivo è impostato per la segnalazione dopo la correzione.
Allo stesso tempo, la pubblicazione in produzione e l'invio di email reali sono esclusi. Questo per evitare di confondere la verifica dell'invio di prova dello schermo con la consegna di email a destinatari reali.
Questa richiesta non tratta la funzione di invio email reale come verificata. Fai in modo che segnali quanto è stato confermato in locale come risultato.
Secondo il testo originale, se vuoi procedere oltre la prima implementazione, comunica cosa indagare e dove fermarsi.
Piuttosto che rafforzarlo semplicemente con "non fermarti a metà strada," elenca le conferme necessarie e le operazioni da non eseguire. In questo modo, puoi rivedere anche i punti in cui ritorna a un umano.
5. Revisionare le Tue Impostazioni
Alla fine del testo originale, Eric suggerisce di chiedere ad Astra una revisione basata su questo articolo. Una revisione significa leggere le istruzioni esistenti e controllare sovrapposizioni, discrepanze e aree che possono essere riviste.
Puoi anche aprire il tuo AGENTS.md o le tue Skills e guardare le frasi che ti incuriosiscono. Tuttavia, se vuoi organizzare dove e quali istruzioni hai scritto, puoi affidarti a una revisione prima di apportare modifiche.
L'approccio di eseguire solo la revisione prima senza modificare i file è una proposta di questo articolo. Non è una procedura obbligatoria specificata da Eric.
In tal caso, non chiedere di "eliminare tutte le istruzioni non necessarie" dall'inizio. Ciò che vuoi prima è materiale che ti permetta di confrontare le istruzioni originali con la proposta su come modificarle.
Un'altra nota dal testo originale: le Skills e le istruzioni inserite in un repository potrebbero essere utilizzate dalle IA di altri lavoratori.
Queste IA potrebbero non usare la stessa Astra. Eric sottolinea che le spiegazioni utili per Sol o Luna potrebbero aggiungere troppi vincoli per Astra.
Anche se a te che usi Astra sembra troppo dettagliato, potrebbe essere necessario per altri modelli. Se stai modificando regole condivise, chi usa quale modello è anche un fattore di giudizio.
Se lo stato di utilizzo è sconosciuto, non eliminare assumendo "solo Astra è usato." È sufficiente confermare i candidati alla correzione lasciando i punti poco chiari così come sono.
Il seguente prompt di revisione è stato creato per i lettori basandosi su questo articolo. Non è un prompt pubblicato da Eric nel testo originale.
Usalo nel progetto di destinazione e condividi il testo dell'articolo e il testo della richiesta che vuoi revisionare. Se l'intervallo leggibile è limitato, accettalo come risultato dell'ispezione all'interno di quell'intervallo.
Ti chiedo di verificare le istruzioni attuali basandoti sul commento condiviso dell'articolo di Eric Provencher. Esegui solo la verifica questa volta; non creare, modificare o eliminare file, né modificare le impostazioni.
I target sono il file AGENTS.md applicato a questo progetto, i nomi e le descrizioni delle Skill disponibili e i corpi necessari per la verifica, e il testo della richiesta giornaliera che ho condiviso. Elenca i target che sei riuscito a leggere.
Controlla la presenza dei seguenti problemi: ・Istruzioni duplicate in più posizioni ・Istruzioni che non possono essere seguite simultaneamente o che hanno endpoint contrastanti ・Regole uniformi eccessive che richiedono caricamento o conferma ogni volta indipendentemente dal contenuto del lavoro ・Condizioni di applicazione più ampie del ruolo effettivo della Skill ・Istruzioni in cui non è chiaro fino a che punto procedere o cosa definisce il completamento
Per le posizioni trovate, classificale in candidati per "Elimina", "Accorcia", "Modifica le Condizioni di Applicazione" o "Mantieni", e fornisci le motivazioni. Non fare della riduzione del numero di caratteri l'obiettivo stesso; elenca anche le istruzioni che devono essere mantenute.
Per ogni candidato, fornisci quanto segue: 1. Nome/posizione del file o la parte pertinente del testo della richiesta condivisa 2. Istruzione corrente 3. Problema ipotizzato e base del giudizio 4. Revisione proposta. Se si mantiene, la motivazione 5. Cosa mantenere e cosa cambiare 6. Condizioni che gli umani dovrebbero verificare prima di apportare modifiche
Non eliminare in blocco vincoli specifici del progetto, conoscenze specialistiche, test necessari o approvazioni necessarie. Proponi solo di consentire test locali o correzioni da continuare nell'ambito in cui le condizioni ambientali, come i dati di destinazione e l'assenza di accesso alla produzione, possono essere confermate.
Controlla se anche altri modelli come Sol o Luna utilizzano le stesse istruzioni. Se non lo sai, scrivi "Sconosciuto" e non dare per scontato che sia una regola solo per Astra.
Indica chiaramente i file che non è stato possibile leggere, le condizioni ambientali che non è stato possibile confermare e le informazioni mancanti per il giudizio. Distingui tra problemi spiegati nei materiali, problemi effettivamente riscontrati nelle impostazioni e candidati al miglioramento non verificati; non scrivere gli effetti del miglioramento come già misurati.
Infine, riassumi i candidati alla correzione da considerare con priorità, insieme alle motivazioni. L'esecuzione delle modifiche verrà richiesta separatamente dopo che avrò confermato i target e il contenuto.
Ciò che ricevi con questa richiesta non sono le impostazioni riviste, ma un elenco in cui le istruzioni attuali e le revisioni proposte corrispondono. Anche se è scritto come "candidato all'eliminazione", questo da solo non lo finalizza come non necessario.
La categorizzazione dei candidati è fornita in modo che le proposte di modifica delle condizioni di lettura non vengano raggruppate in "Elimina". Nel caso dell'esempio di riferimento al documento in questo articolo, il documento rimane, quindi l'attenzione è sulla modifica delle condizioni di applicazione.
Per le descrizioni delle Skill, il ruolo specializzato rimane, ma l'ambito di chiamata viene ristretto. In questo caso, se arriva una proposta di eliminare la conoscenza specializzata stessa, puoi verificare se ciò che viene mantenuto prima e dopo la revisione è diverso.
I candidati "Accorcia" servono per vedere se le stesse condizioni e gli stessi vincoli possono essere trasmessi in frasi più brevi. I candidati "Mantieni" chiedono la motivazione per cui è necessario mantenerli.
Guarda l'ambito della verifica insieme ai risultati. Se sia stato possibile leggere solo il nome e la descrizione della Skill, o se siano state lette le procedure effettive, è anche materiale per giudicare i risultati.
Se una descrizione è troppo ampia può essere verificato con la prima, ma se ci sono duplicati nelle procedure o se la conoscenza necessaria non è stata tagliata non può essere confermato a meno che non venga letto il corpo.
Se non hai condiviso testi di richieste giornaliere, anche le discrepanze con le condizioni di arresto lì sono non confermate. Leggere parte delle impostazioni non costituisce una verifica completata dell'intero ambiente di lavoro.
L'ordine da seguire è: istruzione originale, motivo per cui è diventata un candidato, vincoli rimanenti e condizioni non confermate. Ad esempio, se la presenza dell'accesso alla produzione è sconosciuta, la premessa per una proposta di saltare l'approvazione non è soddisfatta.
Puoi anche verificare se la conoscenza specializzata necessaria non è stata tagliata o se gli impatti su altri modelli non sono stati ipotizzati. Procedi mantenendo separati il sospetto trovato nella verifica dal giudizio che sia ok modificare.
Rileggi le istruzioni che hai continuato ad aggiungere per adattarle al tuo lavoro corrente. Il primo passo non è un'eliminazione in blocco delle impostazioni, ma questa verifica che non cambia nulla.
