Collaborative document creation workflow. Three stages: Context Gathering → Refinement & Structure → Reader Testing.
When to Offer This Workflow
Trigger conditions:
- The user mentions writing an article, writing a document, or co-authoring
- The user provides material and asks for content to be created
Briefly explain the process and then start directly; do not over-explain.
Stage 1: Context Gathering
Goal: Quickly gather enough context, including content direction and writing style.
Meta information (must ask)
- Document type? (WeChat official account/Xiaohongshu/technical documentation/proposal)
- Target readers?
- Expected effect after reading?
- Your personal viewpoint/angle?
- Length and style?
Writing style preferences (must ask)
Key: confirm the style in advance to avoid repeated revisions later.
Ask the user:
- Do you have reference materials? (If so, analyze their style first and follow it)
- Do you prefer concise or detailed?
- Are there any writing habits that need to be followed?
Reference material style analysis
If the user provides reference materials:
First read and analyze their writing style:
- Sentence characteristics (mainly short sentences? mainly long sentences?)
- Structural approach (are there subheadings? paragraph length?)
- Tone (colloquial? formal?)
- Patterns to avoid
After the analysis is complete, tell the user: "The reference material style has been learned, and subsequent writing will follow it."
Common writing anti-patterns (avoid by default)
Unless the user explicitly requests otherwise, avoid:
- Self-questioning and self-answering sentence patterns: ❌ "What does this mean? It means..." → ✅ State it directly
- Excessive contrast: ❌ Using "not... but..." multiple times in a row → ✅ Directly say what it is
- Subheading-segmented cases: ❌ Adding a bolded heading to every case → ✅ Merge into a smooth narrative
- Opening with a rhetorical question: ❌ "Why does this happen?" → ✅ Directly state the reason
- Repeated summaries: ❌ "In short, in summary, this means" → ✅ Omit or streamline
- Over-explanation: ❌ Explaining every concept in detail → ✅ Assume the reader has a foundation
When the user says "too wordy," streamline immediately; do not explain.
Material handling
If the user provides material files:
- Read directly
- Extract key information
- Do not ask too many questions; proceed directly to the next stage
If additional information is needed:
- You may search the internet for popular viewpoints, cases, and data
- Search proactively; do not ask "should I search?" every time
Exit conditions
After the user answers the meta information questions, proceed directly to Stage 2; do not repeatedly confirm.
Stage 2: Refinement & Structure
Goal: Brainstorm, filter, write, and iterate chapter by chapter.
Determine the structure
Based on the document type, suggest 3-6 chapters, create a file framework (Markdown file), and use [待撰写] as a placeholder.
Process for each chapter
Step 1: Brainstorm
List 8-15 possible points to include, presented with numbers.
**N 个可能包含的点：**
1. xxx
2. xxx
...
**保留哪些？** 比如：`1、3、5、7`
Step 2: Filter
After the user replies with their choice:
- If the user says "all" or "1-N": adopt all directly, no further confirmation
- If the user selects some: use only the selected ones
- Do not ask "are you sure"; go straight into writing
Step 3: Writing
Write the chapter based on the filtered results, and update the file directly.
After writing is complete:
- Show the chapter content (in blockquote format)
- Briefly ask: "Anything you want to change? If it's fine, just say 'continue'"
Step 4: Iteration
Rules for handling user feedback:
| User says | Action |
|---|---|
| "continue" | Move on to the next chapter |
| "too wordy" | Trim immediately, no explanation |
| "don't use the xxx sentence pattern" | Remember it, and follow it in subsequent chapters too |
| Specific revision suggestions | Make the revisions, show the result |
Iterate quickly. After the user gives feedback, revise immediately; once revised, show it immediately; no long explanations.
Style learning
During iteration, remember the user's style preferences:
- What the user deleted → avoid it later
- User says "too wordy" → be more concise later
- User says "don't ask and answer yourself" → avoid it in all chapters
After completing all chapters
Output the full text for the user to read through, and ask whether adjustments are needed.
Stage 3: Reader Testing (optional)
Goal: Use a fresh perspective to check whether the document is clear.
Only do this when the user requests it, or suggest it when the document is long/complex.
How to execute
- Predict possible reader questions (5-10)
- Use a sub-agent or suggest the user start a new conversation to test
- If problems are found, return to Stage 2 to fix them
Core principles
Efficiency first
- Don't confirm repeatedly; once the user says it, execute it
- After brainstorming, if the user selects "all", use it directly
- Iterate quickly; show it as soon as it's revised
Consistent style
- The style established in the first chapter should be followed in all subsequent chapters
- Remember the user's revision feedback and apply it by analogy
Concise expression
- Show content in blockquotes, concise
- One-sentence transitions: "Continue?" "Anything you want to change?"
- Don't give long explanations of the process
Quick responses to common feedback
| User says | Do immediately |
|---|---|
| "too wordy" | Trim by 50%, no explanation |
| "don't ask and answer yourself" | Rewrite, remove all rhetorical questions |
| "merge them together" | Remove subheadings, write in a flowing narrative |
| "continue" | Next chapter |
| "output the full text" | Read the file and show it in full |