You will be able to write revision instructions that change the parts you name and leave the rest alone.
Most of the feedback people give an AI assistant is vague: "make it better", "more friendly", "too long", "try again". It's the same kind of note people scribble on a colleague's draft at the end of a long day, and it gets the same result. The next version comes back different, but not in the way you wanted, and sometimes it's worse than the one before.
What you want from a revision is a better second draft, and a merely different one doesn't get you there. Four habits make that happen. Quote the part you want changed. Give the reason. Keep each round to one or two changes. Say what must stay the same.
Vague feedback is any instruction that doesn't say which part to change, what is wrong with it, or what better looks like. "Make it better" gives the model nothing to act on. It doesn't know which part you mean, what you think is wrong, or what a better version would look like. So it changes a little of everything, and the parts you liked are as likely to change as the parts you disliked.
Quote the exact sentence you want changed, or name the exact section, such as "the first paragraph" or "the bullet about response times". The model then knows exactly where to work. Quoting also prevents a quiet misunderstanding. If you say "the ending is too formal", the model has to decide where the ending starts. If you quote the ending, there is nothing left for it to decide.
The quote tells the model what to change. The reason tells it why, and the reason lets the fix carry through the rest of the draft. Compare "Make the closing line less formal" with a version that explains the client is long-standing, that you usually message him on WhatsApp, and asks for the line to sound like how you would really end a note to him. The second version fixes the closing line and also tells the model about the whole relationship. That makes it far more likely to soften stiff phrasing elsewhere in the draft too.
A reason is context you add at the point you found out it was missing. It is usually about either the reader or the situation. "Too formal for a long-time client" is information about the reader. "Too long because he reads email on his phone between site visits" is information about the situation. Each reason gives the model a little more of the context that lesson 1.2, "Give context the way you would brief a colleague", asked you to provide.
When a draft has several problems, it's tempting to list them all at once: change the opening, move the fee down, cut the second paragraph, make the tone warmer, add a line about the new helpdesk, remove the jargon, shorten the subject line. Long edit lists like this often get partly ignored. The model handles some edits well and some halfway, and drops one or two altogether. You then have to reread the whole draft to find out which.
One or two changes per round works better. Start with the change that matters most. That is usually structure or content, then tone, then wording. Each round is quicker to check because you know exactly what should have changed. Lesson 4.4, "Take a draft through three rounds", gives you an order to follow for these rounds.
Even a clear, quoted instruction can set off a rewrite of the whole draft. Models tend to treat a revision request as an invitation to produce a fresh version. Along the way, paragraphs you were happy with get reworded, facts get rounded and good lines disappear. So say explicitly what not to touch, for example: "Change only the opening paragraph and the closing line, and keep everything else exactly as it is, including the fee and the start date." For a long document, ask for the revised section on its own and paste it into place yourself. That way the rest of the document can't drift.
Marcus is the account manager from lesson 4.1. He had marked up his renewal email against his brief, so he knew what to keep and what to change. His client has been with the company for nine years. Marcus usually messages him on WhatsApp, and the client reads email on his phone between site visits.
Marcus's first round of feedback asked for two changes. In the first, he explained that the email opened with the fee increase, which made it read like a bill to a nine-year client. He asked for an opening line about working together, with the fee moved to the second paragraph. In the second, he quoted the closing line, "Please let us know at your earliest convenience if you would like to arrange a call", and said it was too formal for this client. He asked for an ending that sounded like one of his WhatsApp messages to him, something short such as offering to drop by. He then told the assistant not to change anything else, and to keep the fee, the start date and the helpdesk paragraph exactly as written.
The second draft opened warmly, put the fee where he wanted it and closed with a line he would actually say. Everything else was left alone. It needed one more small round, on the subject line. Each time, check the new draft for exactly the changes you asked for before you move on to the next round.
Precise feedback takes a minute longer to write than "make it friendlier", and it saves you several rounds of guessing. The quickest way to build the habit is to look at feedback you have already given and see how it would read rewritten with a quote, a reason, one or two changes and a clear statement of what stays the same.
Scroll back through your recent chats for three of your own vague revision requests.
Take three vague pieces of feedback you have given an assistant, rewrite each as a quoted instruction with a reason, and run them to compare the results.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).