In the second article you saw this: the AI in the chat box does not learn while you type. It produces a continuation from the patterns it already has. That continuation depends largely on the sentence you give it. A vague question produces a vague answer. A clear question reduces the workload, makes checking easier, and makes made-up answers a little harder. This article is not a list of magic prompt phrases. My goal is to fix this idea: a good answer often comes from a good request.
This is part three of our Artificial Intelligence series. I give a skeleton that works in the workshop. You can use the same logic for Arduino, Python, or a homework text.
Saying write code is like saying buy something at the market. If you do not say what to buy, which product, and how much, a random bag arrives. If you say print the distance in centimetres from an HC-SR04 on an Arduino UNO to the Serial Monitor, keep it under ten lines, and do not suggest a library that does not exist, the job becomes clear and easier. You use the same tool in both cases. The difference is in your sentence.
Why does a vague question break things?
The model looks at the text you wrote and at what remains in that chat, then produces a possible continuation. If you say write code, it leans toward one of the thousands of code samples it saw in training. Which one? Arduino, Python, web, or a game? Is the board a UNO, a Nano, or an ESP32? When those facts are missing, the model fills the gaps. Filling gaps means inventing. The sentence still looks tidy. The pin may be wrong. A library name may sound nice and still be missing from Library Manager.
Also remember the context window from the second article. In a long chat, the board name you gave at the start can drop out. Putting the critical facts back inside every important question is not stubbornness. It is keeping the real data in view.
The skeleton of a clear request
Five parts are enough. You do not have to write a novel every time. But keep them in mind:
- What: What should be produced? Short code, an error comment, a summary, a list of ideas, a table.
- Where: Arduino UNO, Python 3, which lesson, which age?
- Limit: Keep it under ten lines. Do not suggest a missing library. Do not invent pins. Do not invent sources. Do not drive a motor.
- Output form: Code only? First three possible causes? Bullet points?
- Check: If you are not sure, say so. Do not write unofficial functions.
You can also give an example. In technical language this is sometimes called a few-shot request. You say: make the output look like this, then you write your own sample. The model works closer to your pattern instead of inventing into empty space. That is not magic. It is a clearer target.
| Weak request | Clearer request |
|---|---|
| Write code | Arduino UNO, HC-SR04, print distance in cm on Serial 9600. Use pulseIn. Keep it under ten lines. Do not suggest a missing library. |
| Do my homework | Explain this paragraph to a twelve-year-old in three bullets. Do not invent sources. Do not erase my sentences; simplify them. |
| Give me a robot idea | School yard, not a line follower, 4 weeks, 5 narrow problems possible with the UNO and 3 sensors on hand. Each idea needs a measurable test. |
| What is this error? | Comment on this error message line by line. First give 3 possible causes. Do not rewrite the whole sketch. Board: Arduino UNO. |
Split the work
If you ask for the chassis, the code, the report and the presentation in one message, the answer swells. A pin in the circuit can shift; a measurement in the report can be invented. In the workshop, splitting the job into three is cleaner: first read, then decide, then output. If distance is being read, ask about lighting an LED later. If the LED lights, ask about the motor later. That order matches the small-test logic in the Project Guide.
Getting two different drafts when you ask the same question twice can be normal. The model does not photocopy; it guesses. You choose which one is right by checking the board, the compiler, or the original text. A sentence you like is not always enough.
Do this / do not do this
- Do: Ask for one job at a time. Then ask for the next step.
- Do: Write the parts you have, the board, and the ban.
- Do: Say the output form you want: bullets, a table, code only.
- Do not: Skip details with write everything, you will understand.
- Do not: Upload to the board or paste into homework without reading the output.
What is next?
When the question is clear, the work speeds up. In the next part we reach the real line: the difference between helping with homework and cheating.
