GPT-6 Astra has undergone significant changes compared to version 5.6. Yesterday, many fans asked G-Ge to produce a beginner's tutorial for GPT-6 that can be followed directly. Today, it's here! To write a long article worthy of everyone, I consumed 80% of my tokens for research to write content that is easy to understand yet teaches real knowledge. It is presented in story form so it won't be boring, taking you from small tasks to complete mastery.
I'll use a small family matter to explain GPT-6 Astra to you.
Suppose I want to make a mobile phone manual for the elders at home. The content isn't much: find old photos, send them to family, and learn how to answer video calls. Ideally, it should be printed out and placed next to the phone for easy reference.
This sounds simple. The hard part is that steps I think are clear might not work for someone else.
"Open the gallery, select the photo, click share." I get it instantly. But if the other person doesn't recognize the gallery icon, they stop at the first step, and no matter how detailed the rest is, it's useless.
So in this tutorial, I will create this booklet step-by-step: how to give instructions, how to provide materials, how to look at screenshots, how to correct wrong answers, and what kind of result counts as finished. The scenarios and dialogues in the text are examples written to explain the method.
I won't let it write a "complete tutorial" first
If I start by saying "help me write a mobile tutorial suitable for seniors," it has to guess too much.
What model is the phone? What operations does the person already know? Are they learning to take photos or find old ones? Is this tutorial for the phone or for paper?
"Suitable for seniors" doesn't answer these questions. I don't want it to treat the elder as an abstract reader: just making the font larger, the tone friendlier, and adding a few words of encouragement.
This time, I plan to write the instructions for a specific person. For the demo, I'll set the situation: the person can unlock the phone and answer regular calls; they get stuck on unfamiliar icons. The tutorial only solves these few operations, not a phone encyclopedia.
The first message I'll write is:
I want to make a mobile phone manual for an elder at home. They can unlock and answer regular calls but are unfamiliar with icon names. This time, only write three functions: finding photos, sending photos, and answering video calls. I will provide actual phone screenshots. Please write steps based on the screenshots, one action per step. Do not add buttons from memory that are not visible. First, help me list what screenshots are needed; do not write the whole tutorial yet.
The purpose of this message is to gather materials first. Without the phone interface, even if it writes a book, it might be wrong from the first page.
I don't really believe in the method where adding "you are a top expert" makes the answer transform. What really helps this task is knowing the person can unlock, doesn't know icons, and which phone I'm using. These things are much more specific than an expert title.
Sometimes I haven't thought through what I want. Then I don't rush to write long requirements; I tell it who I'm giving it to, where it will be used, and ask it to ask two questions that would affect the result. Once the direction is clear, then move forward.
For example, "making it a single sheet or a booklet" affects content arrangement; "whether to bold the title" isn't worth discussing yet.
Besides the model name, I also look at two places
Before uploading screenshots, I check the current model and whether there are entry points for image uploads or file processing near the chat box.
ChatGPT is the product I opened, and GPT-6 Astra is the model responsible for understanding and processing tasks. What the model can do versus what tools this window provides are two different things.
I can confirm in the official model description that Astra is geared towards complex reasoning, programming, research, computer operations, and document production, supporting text and image input. As for which functions my account can use, I have to look at the specific entry points. OpenAI Model Description
For instance, after I upload a screenshot, it can help me look at buttons and write descriptions; if the current environment lacks phone operation tools, I shouldn't assume it has already pressed the buttons on the phone just because it understood the image.
Files are the same. Arranging a few paragraphs of text in chat versus generating a downloadable file are two things that need separate confirmation. My request will leave a practical choice: give a file if possible, otherwise organize copyable content.
When starting out, I don't rush to study all parameters. First, let it read the text in one image correctly, then let it write a description as requested. I can judge the correctness of such tasks, and it's not easy to be intimidated by professional terms.
When encountering recently updated features, I'll have it check official documentation and provide the corresponding page. If there's no web tool, I'll leave the parts that need verification blank. Just because it speaks fluently doesn't mean the information is still valid.
If the corresponding option hasn't appeared in the model list, I'll first confirm the actual scope available to my account, rather than treating others' screenshots as my own interface. There's no need to gather all advanced tools just to practice the methods in this article.
Screenshots don't need to be many, let me know what each one is first
Next, I'll prepare the materials.
One of the phone home screen, one of the gallery interface, and one of the interface after selecting a photo. If video calls are also to be written, prepare those screens separately; don't mix functions together.
Name the images recognizably, like "Photo - Start Page" or "Photo - Selected." The names don't need to be professional, just so I know which step they explain later.
If I have an old tutorial, I'll mark it as "Old Version Reference." It helps understand how things were explained before but cannot determine what buttons look like today. If the phone was updated, old screenshots might be invalid.
The supplementary request doesn't need to be long:
The current phone screenshots are the basis for operation; the old tutorial is only for referencing the expression style. First, list in order which interfaces you read. If there are inconsistencies between the two materials, point them out; do not merge them into one set of steps yourself.
I want to see what it reads first. For example, if it can say one image is a photo list and another has a photo selected, it's easy for me to cross-check. A phrase like "fully mastered" doesn't show if it actually read it right.
Unclear text must also be counted in the material status. If text in a small icon is blurry, write that it's unclear; if the screenshot doesn't show the bottom of the page, state that part is missing. Don't let missing information silently become complete in its answer.
If I need to add a photo, I'll only add the missing one and specify which step it follows. Uploading a dozen similar photos at once makes it easy for even me to get confused.
The order of images is also worth time to organize. The same page before and after selecting a photo looks similar, but the clickable buttons might have changed. I'll write "Unselected" and "Selected" in the filenames to avoid mixing the two states.
To judge if materials are sufficient, I can ask it to repeat a process: starting from which image, passing through which, and ending where. If it skips intermediate screens or puts later screenshots first, it's not yet suitable for writing formal steps.
Sometimes adding one photo solves it; sometimes I need to explain what happened between images. For example, if a selection window popped up between two screenshots but I didn't capture it, that's a missing step. I'll go back to the phone to complete it, rather than letting it guess the intermediate operation from the final result.
There's also material not on the screen: family usage habits. For example, the person is used to saying "photos" instead of "gallery app"; they understand "press the screen and push up" better than "swipe up." These can be written as requirements to keep the expression consistent.
However, for actual button names on the screen, I won't change them for colloquialism. The explanation can be plain, but if a button is called "Done," write "Done." Otherwise, the person reading won't know which word to look for.
I'll try one page first to see if it works
Once materials are ready, I won't immediately ask for the full product.
First, write "Find a photo." This is a task small enough for me to check from start to finish. After it's written, I'll check it against the phone: is there a place to click for every step, and do I know what I'll see next after reading this sentence?
Please first write the page for "Find a photo." Specify the action for each step. If necessary, add a sentence about what will be seen after the action to judge if it's correct. List parts not supported by screenshots separately; do not put them in the formal steps.
If the first version is too long, I'll see why. Is one step doing two things, or is it explaining unnecessary background? These two problems need different fixes. Simply asking to be "shorter" might delete necessary prompts.
For example, "Open Gallery" is only two words, very short, but the information might not be enough. "Find the icon circled in the image on the home screen and tap it" is slightly longer, but the reader knows what to look for.
Keep information that helps operation, and delete sentences like "Next, we will enter the wonderful world of photos." If the tutorial is still building atmosphere at this point, I'd get impatient.
When trying this page, note down where you get stuck. Don't just reply "it's still unclear," but explain: "Step two tells me to click the top right, but there are two icons in the top right of the screenshot, I don't know which one it refers to."
It can then modify that specific part. I'll go through it again, and once it works, I'll ask it to use the same writing style for the rest. What's being reused is the explanation method; specific buttons still need to be confirmed image by image.
I like making small samples for a very practical reason: if one page is wrong, just fix one page. If all ten pages are written and then I find the whole book assumes the reader knows icons, there's too much rework.
Ask questions about images, I'll narrow the question to one action
Suppose when I get to "Send Photo," several buttons appear on the screen.
At this point, I won't just throw an image and ask "what to do." I'll include the current state and what I want to do next:
I have opened this photo and want to send it to family. Please look only at this screenshot and point out which button I should look for next. Explain the basis for your judgment; if the screenshot is insufficient, tell me which interface I still need to see. Give the next step first; wait for me to add photos for subsequent steps.
This limits the discussion to the immediate problem. It doesn't have to guess the next five pages, and I don't have to read a long list only to find the second step is inapplicable.
The buttons in the image are for explaining the writing style; actual names and positions should be checked against the phone in hand.
When taking screenshots, I'll keep information that shows position. Page titles, adjacent buttons, and pop-up prompts are sometimes more useful than the small icon itself. Cropping it down to just an arrow might make it impossible to tell if it's for returning, sending, or sharing.
If there are family names, chat content, or phone numbers in the image that are irrelevant, I'll blur them first. I only need it to recognize the operation entry point, not the full chat history.
If button text is unclear, the simplest way is to take another clear shot or type out the text I see. Repeatedly asking "look closely" won't make blurry pixels clear.
If the button names it gives are inconsistent with the actual interface, I'll trust the phone in front of me and add: "My screen shows these options." No need to look everywhere for a non-existent menu just to accommodate the answer.
The same questioning method can be applied to tables, web pages, and software errors. I explain where I'm stuck, what I originally wanted to do, and provide the screen that supports judgment. If the question is specific enough, I'll know how to verify the answer once received.
Ask what needs to be asked, no need to wait for me to decide even on the title
If it finds the phone model is missing or the text in the screenshot is unclear, it's normal for it to follow up. That information affects the operation steps.
But whether the title is "Send Photo" or "Send Photo to Family" can be decided by the AI first; no need to stop for every small detail.
My requirement is:
You handle chapter order and title wording. Ask me about issues that affect operation, such as phone model, unclear screenshots, or buttons that cannot be judged. Finish the parts that can be confirmed first. Don't stop other content just because one image is missing.
The official user guide mentions that Astra is more likely to ask clarifying questions when missing information might affect the result. I'll be specific about what I need to decide, letting it know where it can continue. OpenAI User Guide
I also won't go to the other extreme and ask it to ask nothing. For phone operations, guessing a button saves one follow-up but leaves an incorrect step.
Questions that can't be answered for now can be put on a to-do list. For example, if the video call interface screenshot isn't ready, leave that page blank for now; don't fill it with another phone's interface.
If many questions come at once, I'll have it pick the two most important ones to confirm first. Solve the things that would cause the whole manual to be wrong first; the rest can be filled in as we go.
Some questions reveal that I haven't thought things through myself. If I say "text must be large, paper must be minimal, and images must be complete," it needs to know which to prioritize when they conflict. I'll choose readability first, even if the page count increases. If requirements fight each other, don't expect it to guess my trade-off correctly.
Changing from mobile reading to printing, I only redo the affected parts
Suppose the first draft was intended for a family group chat, but later I decide to print it out.
The content is still those few functions, but the usage has changed. Small text can be zoomed on a screen but not on paper; colors that are close might be indistinguishable after printing.
I'll continue writing in the original dialogue:
The reading method has changed: this manual is to be printed, no longer formatted for mobile reading. Keep the confirmed operation steps. Please adjust font size, image/text positions, and paging to ensure images and corresponding descriptions are on the same page; check for phrases like "click the link" or "zoom in on the image" that aren't suitable for paper.
I'll be clear about which content remains valid in this modification. Otherwise, it might rewrite even the verified steps, giving me extra checking work.
If the tool provides an entry point for mid-way supplementary requirements, I can send them while it's working; if not, I'll wait for the current round to finish. I won't assume every chat window has the capabilities found in developer interfaces.
When changes accumulate, I'll have it list the current requirements—no long explanations, just the reading method, included functions, which screenshots are used, and which pages are unfinished.
Comparing against this record makes it easy to find conflicts. For example, if I've canceled "Answer Video Call" but it's still in the table of contents, I'll have it deleted. The body and the table of contents belong to the same file; they can't be modified separately.
I also don't recommend starting a new dialogue for every word change. That would require re-explaining the phone model, wording habits, and screenshot correspondences. If the task really changes, start a new segment and bring over the conclusions that need to be kept.
I don't want to write the instructions for family like a brochure
At this point, another problem might arise: the steps are basically correct, but the sentences don't sound like how people normally talk.
For example, the beginning might have a sentence like: "Master this skill and easily enjoy the convenience brought by digital life."
This sentence doesn't help anyone find a button, so I'll delete it. A manual doesn't owe the reader a passionate opening.
The phrase "remove AI flavor" is too broad. Specifically for this booklet, my requirement is:
Modify according to how I would teach my family in person. Keep the original button names from the screen, but use everyday words elsewhere. One sentence should only explain the immediate action. Delete slogans, encouraging clichés, and repetitive summaries at the end of each page. Do not add family experiences or touching plots. If a sentence is already short, accurate, and followable, keep it.
"Execute image sharing operation" can be written as "Send this photo out." But if the button on the interface is called "Share," I'll still keep those two words in the steps for easy reference.
I'll also watch for two actions hidden in one sentence. Something like "After opening the photo, click share, then select a contact" sounds smooth to someone familiar with phones; for this manual, splitting it into several lines makes it easier to complete one by one. Short sentences have a purpose here, not just to mimic a writing style.
Conversely, a naturally smooth sentence doesn't need to be cut into several segments. Changing lines every three words reads like video subtitles and wastes paper when printed. How to split paragraphs depends on where the reader will stop to operate.
If I have instructions I usually write, I can give it a small segment for reference. I'll specify to only learn the phrasing, not to move names, devices, or dates from the example into the new draft. Referencing style and copying content are two separate things.
Most importantly, don't make up a sentence like "Dad finally showed a smile" just to seem warm. If it didn't happen, don't use it to decorate the tutorial. Explaining "where to click" clearly is already more useful than that sentence.
What I want is a booklet, not production suggestions
When it comes to delivery, I'll state the result more directly.
Please organize the confirmed content into a printable user manual, filling in the body and corresponding images; do not just give a table of contents or template. If the current environment supports file generation, please give me a downloadable version; otherwise, organize the content by page so I can easily copy it into a document for layout. Put unverified steps in a separate to-do list; do not mix them into the main text for family.
When I receive the reply, I first look at what was actually delivered. A file link, a copyable body, or a sentence like "you can use document software to make it" are very different. The last kind of answer hasn't finished the work I assigned.
If the file function is available, I won't just look at the preview in chat and stop. Download it, open it, and see if images are missing, if text overlaps buttons, or if paging splits a single step.
When laying it out, estimate the length first. Suppose three functions have six steps each, eighteen steps total; four steps per page, four pages are enough. After actually putting in images, check if each page still has enough reading space; don't shrink the text just for page count.
Name the file "Phone User Manual - Current Version" and note the corresponding phone model or interface version within the document. When the phone updates later, at least you'll know if the manual in hand is still applicable.
If I also want to send it to a family group, I'll separate publishing from production: "Show me the final file first, and I'll send it after confirmation." If there's no sending tool, I'll send it myself. The goal of this tutorial is to get a usable manual, not to prove AI can take over all actions.
Even if I understand it, the check isn't finished
In the final round, I'll take the phone and go through it from the beginning.
Are buttons wrong, are steps skipped, do images correspond to the page—check item by item. The AI already knows what the whole tutorial is for and might automatically fill in unwritten actions during checking; I can't do the same.
Please check this manual, looking only for issues that affect operation: button names inconsistent with screenshots, missing prerequisite steps, inconsistent order of images and text, and content relying on guesses. Point out specific locations item by item. Correct those that can be fixed based on materials; leave those lacking materials for confirmation, don't end with "it should be fine."
This helps me do a preliminary check, but someone still needs to use it. The most suitable person is the one the manual was originally intended for.
When testing, I try not to rush in with explanations. If the other person finishes the first sentence and still has to ask "which one are you talking about," that sentence needs to be changed. The manual is still missing information to help them select the correct position.
Note down problems in their original words. The person saying "I don't know what this arrow is for" is more useful than me summarizing it as "interaction cognitive barrier." Bringing that original sentence back and requiring a corresponding explanation allows for further modification.
Solve only the currently discovered problem each time. If the button is already correct, don't change the button name; if only the font is small, adjust the font. Repeatedly rewriting the whole piece makes it easy to turn checked content back into items needing checking.
If a certain function never works, take that page out for now and don't deliver it. Giving a usable short manual is better than gathering all chapters and handing over the problems together.
At this point, this exercise has a judgeable result: can the person who got the booklet complete the operation in front of them. I can't judge this just by looking at word count and layout.
Next time I encounter other things, what requirements will I leave behind
After finishing this example, I'll save the few agreements that affected the result so I don't have to flip through the whole chat next time.
For example, tell it who the content is for first; mark the purpose of materials clearly; only do a small sample the first time; point out what's missing if unsure; explain which old requirements are still valid when changing needs; open and check after delivery.
For work-related tasks, I'll rewrite these agreements according to the actual situation. For meeting minutes, check the person in charge and the date; for explaining tables, check units and calculation methods; for modifying an email, check if the other person can understand what I want them to do. Different scenarios require checking different things.
If you just want to practice once, I'll pick a screenshot of software I'm familiar with, let Astra write the next step, and then check it against the interface. If it's wrong, I can point out the specific location; if it's right, continue to the next step. No need to arrange a huge project for yourself on the first day.
Keep only three sentences in your notes: where I was stuck, what I supplemented, and what changed after supplementing. Next time you're stuck in the same place, this note is easier to find than a long collection of prompts.
Sometimes, after several rounds of modification, it's still wrong, and I'll look back at my own requirements. Am I asking for both detail and extreme brevity? Has a new screenshot changed, but the text is still referencing the old page? Clear these contradictions first before letting it continue.
If it still can't do it after clearing, let it explain where it stopped, what has been confirmed, and what is still missing. I'll take this information and check it myself or ask someone familiar for help, which is more useful than just saying "be more serious."
I hope that after using GPT-6 Astra for the first time, you'll have one more usable thing in your hand. Even if it's just a one-page phone manual, it's enough for me to judge: which part it helped me with this time, and what else I need to clarify next time.
Wait until this page can really be followed before turning the page.
Alright! I'm G-Ge. If you find this article helpful, I suggest you bookmark it and also follow me @goan999999 to grow together!
