Removing the "AI Voice" in Novel Generation: A Layered Pipeline Approach

1. Conclusion First

To address the “machine voice” in AI-generated novels, simply polishing prompts will quickly hit a ceiling. A more effective approach is to break the creative process down into a layered pipeline:

1. Planning Layer: A highly capable model is tasked with outlining chapter plots and scene structures.
2. Scripting Layer: This layer organizes the key points of dialogue and essential actions for each scene, producing a semi-finished script.
3. Expansion Layer: A long-context generation model expands the script into full narrative text.
4. Dialogue Revision Layer: Noticeably unnatural dialogue segments are extracted and individually revised by a model better suited for organizing conversational flow.

Among these, the Scripting Layer and the Dialogue Revision Layer are the two pivot points for improving writing style. An unexpected bonus: after this workflow redesign, the generation time for a single chapter dropped from over thirty minutes to about twelve minutes. Even accounting for the new scripting phase, it still nets a saving of roughly ten minutes.

2. Diagnosing the “Machine Voice”

When reading AI-generated long-form fiction, there is often an indescribable “dryness.” Breaking it down, there are three main symptoms.

Symptom 1: Dialogue that is too neat for real humans. You can define five characters with entirely different backgrounds, personalities, and experiences, yet when they speak, it sounds like they all attended the same orientation training. Roles are clearly divided: one observes, one handles tech, one handles medical duties. If you hide the names, the five paragraphs sound like the same person taking turns giving a report. No matter how detailed the character cards are, the model interprets “personality settings” as information to be conveyed rather than a speaking style to be embodied.

Symptom 2: Abrupt and jarring emotional transitions. One second they are in the middle of an accident, and the next second they automatically switch to a calm situation report. As a train car is sliding off a cliff, a character’s first reaction isn’t to yell for help, but to补充 the time and location details. The information is correct, but the human reaction is not.

Symptom 3: Template-like environmental descriptions. Trains, night skies, wind— all the scene elements are present, but if you swap the scene name for another chapter, the description is almost entirely reusable.

These three symptoms point to the same root cause: the model is transmitting information, not playing a role. Its training objective dictates that it prioritizes explaining things clearly, completely, and logically. Fiction, however, requires humans in specific situations to explain things in their own way— less clearly, less completely, and tinged with emotion. This is a misalignment at the objective level, not a vocabulary issue.

3. Why Prompt Engineering Hits a Ceiling

The initial countermeasure was to keep adding rules to the system prompt:

• Don’t chop sentences too finely.
• Don’t insert “he said” every two sentences.
• Don’t repeatedly confirm the same thing.
• Characters should respond to each other’s attitudes, not just talk past one another.

There were indeed local improvements: short sentences merged, “he said” decreased, repetitive confirmations deleted. But after tweaking a few chapters, a pattern emerged: rules are effective on “points,” but useless on “structure.”

A typical scenario: Character A reads off two or three pieces of information in order, Character B confirms them sequentially, and Character C gives a concluding summary. Every single sentence can have its purpose explained, but together they read like meeting minutes. At this point, deleting a few repeated words or smoothing out transitions doesn’t help; the meeting is still happening, because the problem isn’t the words, but the “turn-by-turn reporting” dialogue skeleton.

The ceiling of rule-based prompting is that each rule can only describe a symptom, but cannot change the model’s default structural tendency when organizing dialogue. Once you patch up a dozen rules, the drafts still get stuck in the same spots, and the more rules there are, the more the model drops the ball trying to juggle them. At this stage, one must admit the wrong tool was chosen; continuing to tweak rules won’t solve a structural problem.

4. Shift in Thinking: From “One Model Does All” to “Division of Labor”

Before altering the workflow, we must face a practical constraint: API quotas. The most capable models have the tightest quotas, so it’s impossible to have them write every single word. Long-form text generation is a massive quota consumer. Therefore, the solution must simultaneously satisfy:

1. The vast majority of the body text must be handled by cost-effective models.
2. Critical stages like structural planning and dialogue revision must be centrally processed by more appropriate (and capable) models.
3. The output of each stage must be independently verifiable to avoid full-pipeline rework.

This replaces the old cycle of “one model writes, a reviewer model points out ‘this paragraph is unnatural’ in the final draft, and the writer model goes back to guess again” with a group assignment with clear responsibilities. In the old cycle, the reviewer couldn’t explain exactly how to fix it, so the writer could only blindly guess, resulting in massive information loss.

A practical tip: before starting, inventory all your available quotas, including free tiers across different platforms. These free quotas are often just enough to run lightweight revision tasks, saving your most expensive paid quotas for planning and final review.

5. Dialogue Revision: Extract and Refine Independently

The first change is to extract dialogue from the finished draft and give it a dedicated round of revision.

Why it must be revised independently. When dialogue is mixed into the body text, revision instructions get diluted by requirements like “maintain context coherence” and “do not change the plot.” The model naturally leans toward minor touch-ups, leaving things untouched if possible. By extracting it, the prompt can focus entirely on how they speak: addressing habits, sentence length, interruptions, talking over each other, answering out of context, and lingering emotions.

The revision prompt can focus on these points. An example structure:

Character Card (Background, Personality, Current Emotion, Relationship with others)
Scene Summary
Dialogue snippet to be revised
Requirements: Only change the speaking style; do not alter information volume or plot direction;
Each character must retain at least one identifiable speech habit;
Interruptions, pauses, and incomplete sentences are allowed.

How to verify. A low-tech method is the Name-Masking Test: hide the character names. If you can still distinguish the dialogue as coming from different people, it passes; if it sounds like one person talking to themselves, send it back for rework.

A counter-intuitive lesson on parameters. Early on, I tried having the text generation model self-revise its dialogue. Surprisingly, a low-randomness sampling setting performed best. The reason is worth pondering: under high randomness, the model tends to embellish towards something “refined and neat”—which is exactly what we want to remove. Under low randomness, it leans towards subtraction, deleting repetitions and merging short sentences. However, the limitation of self-revision is obvious: the words are updated, but the “meeting minutes” structure remains completely intact. This reiterates the analysis in Section 3: structural problems cannot be fixed by changing parameters.

Conclusion: Dialogue revision must be handed to a model better at organizing communication, and it must be given sufficient context (character cards, relationships, scene summaries). If you only feed it a snippet, it will just produce eloquent empty words.

6. Scripting Layer: Take Structural Decisions Away from Expansion

The second change is adding a scripting layer before expansion.

The workflow becomes: the planning model outputs a scene outline, the scripting phase determines the dialogue key points and essential actions for each scene, and the expansion model writes the body text using the script. Example format:

Scene: Military train ambushed (excerpt)
- Carriage starts sliding; Lao Zhou's first reaction is to yell at people to secure the cargo, not to explain principles
- Radio operator's speech is interrupted twice; the second time he just shouts
- Injured person only uses short phrases, no more than five words per sentence
- Chain of command: shout to the nearest person first, then to the commander

The value of this layer isn’t in literary quality, but in taking the dialogue skeleton away from the expansion model. The turn-by-turn reporting style stems from the expansion model’s default dialogue structure when left to自由发挥. Once the skeleton is locked by the script, it can only fill in the flesh and blood within that framework—and filling in flesh and blood is exactly what expansion models are best at.

Here is another unexpected bonus: efficiency. With a script in place, rework during expansion dropped drastically. A chapter that used to require several rounds of back-and-forth revisions now basically passes in one go. Total time per chapter dropped from over thirty minutes to about twelve, saving about ten minutes net even with the scripting phase included. The reason is straightforward: every round of rework requires re-reading the context and regenerating entire paragraphs of text. Front-loading a cheaper scripting phase eliminates the most expensive rewrite cycles.

7. Results Verification

• Dialogue: Characters now have distinct voices and pass the Name-Masking Test.
• Situational Logic: Characters in danger prioritize calling for help and passing messages, no longer standing at accident scenes delivering situation reports.
• Efficiency: Per-chapter generation time shortened by roughly 60%.
• Cost: Quotas are concentrated on critical stages like planning and revision, while long body text is handled by cost-effective models, keeping total costs manageable.

8. Three Transferable Methodologies

The core of this approach applies far beyond novel writing:

1. Separate structural decisions from text expansion. Structural errors are systemic; textual roughness is local. Local errors can be fixed with rules, but systemic errors require workflow changes.
2. Decouple revision from generation. Revision instructions mixed into general requirements will inevitably be diluted. By making it a separate round focused on a single objective, the model has the capacity to truly rewrite the speaking style.
3. Allocate quotas by capability, not by workflow position. The strongest models are used for planning and final review; mass production is handed off to cost-effective models. This mirrors the software engineering logic of separating architectural reviews from daily coding.

Finally, returning to the core issue: the “machine voice” is not a flaw unique to any specific model, but a structural bias between the training objective of “conveying information clearly” and the creative requirement of “bringing humans to life.” Once we acknowledge this, we stop obsessing over finding a magic prompt and return to good old engineering practices: splitting workflows, dividing roles, and setting acceptance criteria for every stage.