“Please fix the formatting” sounds harmless. An AI assistant may return a polished headline, shorter paragraphs, bold highlights, and a few tasteful icons. A comparison with the source often reveals a different story: a number changed, a cautious claim became certain, or a new sentence appeared without evidence.
The model may not be the main problem. Formatting, editing, and rewriting are different jobs, but that short request gives the model no way to know which one you intended.
OpenAI’s prompt engineering guide organizes instructions around identity, rules, examples, and context. It also notes that model output is non-deterministic. Google’s prompt design guidance reaches a similar practical conclusion: state the goal clearly, separate sections consistently, define ambiguous parameters, and specify the expected output. Those ideas survive product redesigns and model changes because they describe the task, not the location of a button.
Resolve the contradiction before writing a prompt
You cannot require the model to preserve every character and the original structure while also asking it to add headings, subheadings, Markdown emphasis, or emoji.
A heading adds visible text. A new paragraph changes structure. Markdown bold markers add characters. If spaces, punctuation, and line breaks must remain byte-for-byte identical, no formatting operation is possible.
Choose one operating mode instead:
- Strict formatting keeps every existing letter, digit, and punctuation mark. It may only change whitespace and line breaks. Use it for quotations, notices, interview transcripts, and other material that needs close textual comparison.
- Editorial cleanup may add headings, adjust paragraphs, apply limited emphasis, or make light wording changes. Facts, numbers, claim order, and tone remain protected, and the model must report every substantive change.
This decision controls the result more effectively than calling the assistant a “world-class formatting master.” A grand persona cannot repair contradictory requirements.
Keep the method portable
The workflow works in ChatGPT, Doubao, Kimi, and other assistants that accept long-form text. Use official entry points rather than old tutorial links with tracking parameters:
- ChatGPT:
https://chatgpt.com/ - Doubao:
https://www.doubao.com/ - Kimi:
https://kimi.moonshot.cn/
Screenshots age quickly. Model names, upload limits, plan features, regional availability, and interface labels change as well. Check the current product page when a capability matters to your work.
Web access does not make generated text automatically reliable. Doubao’s own feature description warns that generated content may be inaccurate. In the 2025 Stack Overflow Developer Survey, 46% of 33,244 respondents to the accuracy question distrusted AI output, 33% trusted it, and only 3% reported high trust. Developers are not a proxy for every copywriter, so the result should not be generalized beyond that population. It still gives a useful reason to keep human review in any accountable workflow.
A reusable prompt skeleton
Replace the bracketed fields with real requirements. Do not select both modes.
# Role
You are a content editor. Organize the supplied material without inventing facts,
experiences, sources, or opinions for the author.
# Task
Prepare the source text for [blog / newsletter / email / social post] publication.
# Mode
[Strict formatting / Editorial cleanup]
# Audience and purpose
- Audience: [who will read it]
- Reading context: [quick mobile scan / focused desktop reading]
- Purpose: [explain / announce / promote / share an experience]
# Constraints
- Preserve every fact, number, date, proper noun, and the order of the claims.
- Do not add experiences, statistics, sources, or conclusions not found in the source.
- Flag ambiguous or contradictory passages instead of guessing.
- In strict formatting mode, change only whitespace and line breaks.
- In editorial cleanup mode, headings, paragraph changes, and limited emphasis are
allowed, but list every substantive edit.
- Do not repeat or expose passwords, tokens, identity numbers, internal addresses,
or other sensitive data found in the source.
# Output
- Format: [Markdown / plain text]
- Paragraph density: [mobile / desktop]
- Emoji: [none / no more than one per section / headings only]
- Return the edited text, followed by an "Edits and questions" list.
# Acceptance check
Compare the result with the source. Check numbers, dates, names, omissions, and
new claims. If two requirements conflict, explain the conflict and wait for a
choice instead of resolving it silently.
# Source
<original_text>
[paste the source text]
</original_text>
The role is intentionally short. The task, mode, constraints, and acceptance check carry most of the useful information. Delimiters around the source help distinguish content to be edited from instructions that control the edit.
Run the workflow in this order
Supply the complete source or describe the writing goal. If the document is long, attach it and identify the section that needs work.
Define the audience, purpose, and destination. A blog post, internal email, and social post need different paragraph lengths, heading depth, and visual emphasis even when they start from the same source.
Pick strict formatting or editorial cleanup. Without that decision, “make it easier to read” can easily turn into an unauthorized rewrite.
Review the first output with specific feedback. “Make it better” gives the model another broad guess. “Section two dropped two figures,” “the tone now sounds promotional,” or “keep the original conclusion order” creates a change that can be verified.
Compare the final result beside the source. Let the model run its own checklist, then have a person make the acceptance decision. The useful sequence from the original course material remains intact: provide the material, define the target, select the allowed operation, generate, revise, and verify. Short documents do not need a ceremonial “shall I continue?” after every step; provide the complete brief in one turn when the risk is low.
Review the fragile parts
- Numbers, dates, names, product terms, and URLs must match the source.
- Qualifiers must survive. “May” should not quietly become “will.”
- New examples, statistics, experiences, and benefit claims need evidence.
- The headline must not promise more than the body supports.
- Bold text, lists, and emoji should improve scanning rather than decorate every paragraph.
- Each item in the edits list should point to a concrete change or unresolved question.
Legal, medical, financial, and externally binding text requires qualified review. A careful prompt reduces accidental changes; it does not create professional accountability.
Longer prompts are not automatically safer
A multi-page instruction can bury the constraint that matters most. Remove duplicate rules and place non-negotiable requirements near the beginning.
Examples can also conflict with written rules. If the prompt says “no emoji” while every example uses them, output will be unstable. One short, genuinely acceptable input-output pair is more useful than a collection of vague style adjectives.
Requests to “show every reasoning step” are not a general quality control mechanism. What the editor needs is a verifiable result, a change list, and unresolved questions. A long reasoning narrative adds reading work without proving that the text is correct.
Treat the prompt as a maintained work order
A reliable prompt is not a spell. It records the input, permitted operations, protected information, and acceptance criteria.
After using the skeleton on several documents, add recurring failures to the checklist. When the publishing platform changes, keep the task and constraints while adjusting the output format. When the model changes, test the same representative text and compare factual fidelity, omissions, and tone before adopting it.
If you are designing a batch editing, knowledge-assisted writing, or automated publishing workflow, send me a redacted sample, the target platform, the permitted edit scope, and an example of acceptable output. I also publish implementation work and related technical material on GitHub.