formal-document-editor

name

formal-document-editor

description

Use when the user wants to restructure, review, rewrite, or polish a formal document so that its logic, headings, paragraphs, terminology, tables, and language read like a clear professional report. Applies to research reports, technical documents, competitor analyses, investigation materials, policy papers, project summaries, executive briefs, and formal explanations. Trigger on requests such as 优化文档结构, 润色正式报告, 去除 AI 味, 重写报告, 规范语言, 调整标题, or 检查行文风格.

Formal Document Editor

Optimize document structure and language for formal, public-facing, professional reading. Preserve the author's facts and intended conclusion while removing unnecessary meta-commentary, repetition, vague claims, promotional wording, and mechanical AI patterns.

The default voice is formal report prose: objective, direct, restrained, specific, and easy to scan. A user-specified audience, house style, document template, or tone takes precedence over this default.

Operating Modes

Choose the mode from the user's request before taking action:

• Plan mode: When the user asks for a plan, scheme, diagnosis, or says not to edit, inspect the document and return a concrete modification plan only. Do not write files.
• Review mode: When the user asks for an audit or review only, return findings ordered by impact. Do not rewrite the document.
• Revision mode: When the user asks to optimize, rewrite, polish, or modify, implement the change and verify it.
• Comparison mode: When the user asks to preserve the original or compare versions, keep the source intact and create a clearly named revised copy unless the user explicitly requests overwrite.

If the requested audience or document purpose materially changes the structure, ask one focused question. Otherwise infer a formal public-facing report and proceed.

Workflow

1. Read the complete source document and any local style guide before rewriting.
2. Identify the document type, audience, purpose, decision or question, current outline, evidence or source conventions, and required output format.
3. Diagnose structure before wording: missing sections, misplaced sections, heading hierarchy, duplicated conclusions, unsupported jumps, tables that repeat prose, and paragraphs containing multiple unrelated claims.
4. Build a concise target outline. Give each section one job and make the order follow the reader's questions rather than the order in which materials were collected.
5. Rewrite in passes:
   • structure and headings;
   • section-level conclusions and paragraph order;
   • sentence clarity, rhythm, and directness;
   • terminology, abbreviations, tables, figure captions, and references;
   • final consistency and factual-preservation check.
6. Validate the result against the checklist below.
7. In revision mode, report the output path, the main changes, and any unresolved issue that materially affects correctness.

Do not force every paragraph into the same three-sentence formula. Use the lightest structure that makes the reasoning clear.

Default Formal Style

Use these principles unless the user supplies a different style:

• State the main fact or judgment early.
• Follow facts with the mechanism, consequence, comparison, or scope that the reader needs.
• Prefer concrete verbs such as “采用、构成、提供、支持、覆盖、对应、适用于、集中于、形成、连接、实现、列示”.
• Vary sentence length and openings naturally, while keeping the tone controlled.
• Trust the reader. Remove explanations that merely announce what the following sentence already says.
• Use positive scope statements where they are accurate. For example, write “研究对象为 10 例患者，结论对应小样本编程效率” instead of a generic disclaimer about what the study cannot prove.
• Keep necessary legal, technical, safety, regulatory, and research-boundary statements. Precision takes priority over a blanket ban on negative words.
• Use “说明” or “体现” only when the relationship is specific. Do not use “这说明了……” or “这体现了……” as a repeated conclusion template.

The style is formal, not promotional and not conversational. Do not add humour, personal feelings, sales language, motivational conclusions, or artificial “human” personality to a formal document.

Structure and Headings

Headings should name the subject, technical issue, result, comparison, or conclusion. They should not describe the writing process.

Prefer headings such as:

• 产品体系与核心参数
• 技术架构与工作机制
• 临床证据与应用表现
• 监管状态与系统适用性
• 平台能力与竞品定位
• 主要结论

Avoid headings such as:

• 报告结构
• 本章说明了什么
• 我们做了什么分析
• 管理层关注点
• 战略含义, when the document is not a strategy paper
• 证据层级 or 证据来源, when the document is intended for public reading

Do not add explanatory parentheses to headings by default. Keep product names and established abbreviations where they are necessary for identification.

Each section should answer one reader question. Remove a section when it only repeats an earlier summary. Keep the executive summary short enough to answer the document's purpose, key finding, evidence basis, and practical meaning without reproducing the body.

Paragraph and Sentence Rules

Choose the appropriate pattern for the paragraph rather than applying all patterns mechanically.

Product or system paragraph

Describe the model or component, its function, and its position in the system.

The product uses segmented directional contacts. The controller distributes current across contacts, creating a defined path for spatial field adjustment.

Technical paragraph

Describe the structure, working mechanism, and resulting control variable or user-visible function.

Research paragraph

Describe the study design, population, endpoint, result, and the capability to which the result relates. Keep study populations, endpoints, follow-up periods, and data types separate.

Comparison paragraph

Use the same comparison dimensions for each platform. State the observed technical difference before the interpretation. Do not create a cross-study efficacy ranking from non-equivalent research.

Avoid paragraphs that begin with “本报告将……” or end with “上述内容说明……”. Replace them with the actual subject and conclusion.

AI-pattern and Filler Control

Remove or replace these patterns when they add no specific information:

• “从……来看”“总体而言”“综合来看”；
• “可以看出”“不难发现”“值得注意的是”“需要指出的是”；
• “上述资料共同支持”“这说明了”“这体现了”；
• “本报告将”“正文依次介绍”“见下一章”；
• repeated “此外、同时、进一步、因此” at paragraph openings;
• vague attributions such as “业内人士认为”“多项资料显示” without a named source;
• promotional adjectives such as “领先、卓越、全面、强大、先进、独特、无缝、赋能”；
• stacked abstract nouns and empty phrases such as “形成了重要支撑”“发挥关键作用” without a specified mechanism;
• formulaic “挑战与展望” sections that do not contain concrete events, actions, data, or decisions;
• mechanically repeated three-item lists, binary “不仅……而且……” constructions, and artificial “从 A 到 B” ranges;
• excessive em dashes, bold emphasis, decorative symbols, or inline label lists.

Do not replace every instance with a synonym. Delete filler or write the precise fact instead.

Positive Scope and Evidence Boundaries

Rewrite uncertain or internal-sounding statements as precise scope statements:

• “公开专利描述相关电路架构；商用产品参数按产品手册列示。”
• “该研究结果对应小样本交叉试验中的编程效率。”
• “模型输出用于呈现刺激场与解剖结构的空间关系；临床疗效采用研究终点评价。”
• “MRI 适用范围由植入组件、设备状态、场强、线圈和扫描条件共同确定。”

Keep the distinction between:

• a patent example and a commercial product specification;
• a software function and a clinical outcome;
• an estimated or simulated model output and a direct biological measurement;
• a manufacturer data page and a peer-reviewed study;
• a label or regulatory condition and a general product claim.

Do not invent a source, move a citation to support a different claim, change a number, or turn a qualified result into a universal conclusion. When the input contains an unresolved factual conflict, preserve the conflict in the review output or ask the user; do not silently choose a value.

Terminology and Abbreviations

Define a non-obvious abbreviation at first use, then use the short form consistently. By default use “缩写，即中文名称” or the user's established house style. Do not append English full names to every Chinese term unless requested.

Keep widely recognized professional abbreviations when the document's readers use them routinely. Do not translate or expand every abbreviation. Check that a reader can understand each uncommon abbreviation at its first meaningful occurrence, including abbreviations in tables and figure captions.

Use one term for one concept. Do not alternate between near-synonyms only to avoid repetition. Preserve official product names, model numbers, legal names, units, capitalization, and symbols.

Tables, Figures, and References

Tables should help a reader compare or retrieve information quickly. Prefer columns for:

• item, model, parameter, function, comparison dimension, research design, result, or platform position;
• a compact summary of facts already established in the text.

Remove internal workflow columns such as “证据层级、资料来源、内部判断、做不到什么、修改状态” unless the user explicitly requests an internal review matrix. Put citations in the caption, table note, or reference list according to the existing citation convention rather than expanding every table with a source column.

Figure captions should state what the figure contains and, when needed, whether it is an original figure, source figure, or conceptual diagram. Keep complete source links in the reference section. The paragraph before a figure should pose the technical or analytical question; the paragraph after it should state the one or two relationships that matter. Do not repeat the caption three times.

Preserve existing figure paths, table numbers, citation numbering, URLs, page references, units, and source metadata unless the user explicitly requests a reference audit.

Document-type Adaptation

Adapt the same principles to the document's purpose:

• Research or investigation report: prioritize question, method, findings, interpretation, limitations, and conclusion.
• Technical report: prioritize architecture, mechanism, parameters, interfaces, test results, and applicable conditions.
• Competitor analysis: use a fixed comparison matrix and separate observed platform differences from market or strategic recommendations.
• Executive brief: put the decision, evidence, impact, and required action first; compress technical detail into tables or an appendix.
• Policy or official document: use precise definitions, scope, responsibilities, conditions, and enforceable wording.
• Project summary: organize around objective, completed work, results, issues, decisions, and next steps.

Do not add a “recommendations”, “future outlook”, or “management implications” section merely because it is common in templates. Add it only when the document's purpose requires it and the source material supports it.

Preservation and Editing Boundaries

Before editing, record the source file and any user-specified preservation requirements. By default:

• preserve the original file;
• create a revised copy with a clear name;
• retain factual content, data, citations, and source links;
• preserve required tables, figures, and attachments;
• do not perform unrelated refactoring or formatting churn.

If the user asks for style only, do not change the substantive conclusion. If the document contains obvious factual, numerical, or citation problems, report them separately unless the user also asks for a content audit.

Validation Checklist

Complete these checks before delivering a revision:

• The document's purpose and main conclusion are clear in the opening section.
• The heading hierarchy is consistent and every section has one job.
• The order follows the reader's questions rather than source-collection order.
• No section, paragraph, table, or figure repeats the same conclusion without adding information.
• Titles contain subjects or judgments, not writing-process descriptions.
• AI filler, vague attribution, promotional wording, and mechanical transitions have been removed where they add no meaning.
• Sentences state the actor, fact, mechanism, result, or scope directly.
• Necessary research, regulatory, safety, and applicability conditions remain precise.
• Uncommon abbreviations are defined at first use and later used consistently.
• Tables summarize comparable information and do not expose internal workflow unless requested.
• Figure captions, table numbers, references, units, and links remain consistent.
• No unsupported facts, changed numbers, fabricated sources, or cross-study conclusions were introduced.
• The output format and file-preservation requirements are satisfied.

Output

For plan mode, return the diagnosis, proposed structure, priority edits, and validation criteria without editing files.

For review mode, list findings by severity with file or section references, then state residual risks and test gaps. Do not silently rewrite.

For revision mode, provide the revised file path, a concise summary of structural and language changes, and any unresolved factual or formatting issue.

For comparison mode, provide both the preserved source and revised output paths, plus a short summary of material differences.

Completion means the document reads as a coherent formal document, the requested audience can locate the main conclusion quickly, and the revision preserves the source's supported facts and references.