专业文稿终审｜事实、引用与一致性核查

让每个重要结论都有出处，让严肃文稿经得起追问。

Treat hallucination risk as an evidence problem: decompose material assertions into claims, sources, and verification states; expose unsupported or contradictory assertions; and never convert uncertainty into invented certainty. The skill cannot guarantee the elimination of every hallucination. It maximizes audit coverage within the available documents, accessible sources, tools, and time, and makes residual uncertainty explicit.

Help the author make a professional draft accurate, coherent, natural, and ready to deliver while preserving the author's intent and voice.

Mandatory two-stage boundary

Stage 1: audit only

• Treat every source file as read-only.
• Produce an independent review report; do not edit, overwrite, rename, or redline the source.
• Separate confirmed errors, matters requiring the author's decision, and optional refinements.
• Stop after the review and request explicit approval for the proposed revision scope.

Stage 2: revise an approved copy

Enter this stage only after the user explicitly approves revision.

• Create a new copy; never overwrite the source.
• Apply only approved changes. Preserve unapproved wording and formatting.
• Preserve the author's role, point of view, degree of certainty, and recognizable voice.
• Deliver the revised copy plus a change manifest linked to Stage 1 issue IDs.
• Render and visually inspect the full revised document before delivery when layout matters.

“Please polish it” authorizes a review, not silent full-document rewriting. If the requested edit scope is ambiguous, audit first.

Source priority

Apply standards in this order:

1. the user's explicit instruction for this draft;
2. the supplied template, style guide, terminology list, or authoritative wording;
3. the document's own established structure and voice;
4. applicable professional or official conventions;
5. general Chinese writing preferences.

Never impose a vendor-specific house style unless the user asks for it.

Select review depth

Workflow

1. Establish the writing brief

Identify or cautiously infer:

• purpose and desired reader action;
• audience and relationship to the author;
• author's role and level of authority;
• document type, stage, date/version, and delivery channel;
• mandatory terminology, template, length, and tone;
• which public sources may be checked and which internal source files are available.

Flag assumptions. Do not “improve” a sentence by changing the author's substantive position.

2. Preserve and inventory

• List source files and versions.
• Record SHA-256 hashes when practical.
• Note missing referenced attachments or inaccessible pages.
• Keep public sources, user-provided internal sources, and the draft itself as separate evidence classes.
• Keep source, review report, and any later revised copy separate.

3. Run deterministic preflight

For DOCX, run:

python scripts/analyze_chinese_docx.py draft.docx --out preflight.json
python scripts/build_evidence_ledger.py draft.docx --out evidence-ledger.json

The scripts only read the source and write separate reports. The first checks internal defects. The second extracts material factual claims, links, citation markers, footnotes/endnotes, source-list entries, and optional source-bundle hashes to seed the evidence ledger.

Treat extraction as a seed, not a complete inventory. Manually inspect headers, footers, text boxes, comments, tracked changes, images, embedded files, and complex fields that may not appear in the extracted body text.

Verify every automated lead against the source. Do not copy false positives into the review report, and do not skip a basic calculation because the script missed it.

Before turning a render anomaly into a document finding, separate source defects from review-environment limits:

• record the target delivery environment when known, the renderer actually used, and any missing-font or substitution warning;
• if missing glyphs, font substitution, pagination changes, or reflow appear only in a non-target test renderer, label them 测试环境限制/待复验, not P0/P1 against the document;
• retry with an available CJK fallback or a second valid renderer when practical, and do not infer source pagination from a render whose glyphs are missing;
• classify the document itself as P1 only when the defect is reproduced in the intended delivery environment, in the final exported deliverable, or through objective package evidence that directly affects the intended recipient.

An environment limitation may prevent visual QA from being declared complete, but it must not be presented as a confirmed source-file defect.

For PDF, render pages and preserve page references. For Markdown or plain text, assign stable paragraph IDs before review.

4. Perform the semantic review

Read review-framework.md completely for a full audit. Review from purpose and reasoning down to wording and layout:

purpose → structure → claims → evidence → calculations → consistency → language → presentation → delivery readiness

For each material problem, explain why it matters to the reader or the document's intended action.

5. Run the evidence gate

Read source-verification.md completely for every full audit or final-delivery QA.

• Inventory every material factual claim, direct quote, consequential number, policy/legal statement, superlative, and externally attributed conclusion.
• Open each cited public source; a title, search snippet, citation string, or working URL is not proof.
• Verify source identity, authority, date/version, exact supporting passage, entity, period, unit, scope, and degree of certainty.
• For internal facts, verify only against user-provided source files and label the result 已对提供材料核对; do not present it as public verification.
• Mark every unresolved claim. Never invent, repair, or substitute a citation silently.
• Apply the delivery blockers in the reference before assigning the overall delivery judgment.

6. Classify findings

Use these statuses:

• 已证实错误: directly demonstrable from the supplied material;
• 待作者确认: several valid formulations or a substantive choice exists;
• 待补证: a claim, number, source, or attachment lacks support;
• 测试环境限制/待复验: the available toolchain cannot reliably determine whether a visual anomaly belongs to the source or only to the review environment;
• 建议优化: optional improvement that does not correct an error.

Use these priorities:

• P0: wrong fact, material contradiction, fabricated or misrepresented citation, calculation error, legal/compliance risk, or defect that can reverse the conclusion;
• P1: important missing/inaccessible evidence, partial source support, stale source, logic, terminology, table, date, or structural defect;
• P2: language, concision, clarity, or non-material formatting issue;
• P3: preference-level refinement.

Never label a style preference as a factual error.

7. Deliver Stage 1

Read output-contract.md and follow its Stage 1 structure. Lead with the delivery judgment and P0/P1 findings. Put low-level typos and formatting issues in an appendix so they do not bury substantive problems.

End with a proposed revision scope divided into:

• safe mechanical corrections;
• wording changes requiring author confirmation;
• substantive changes that must not be made without an explicit decision.

Then stop and wait for approval.

8. Deliver Stage 2 after approval

Follow the Stage 2 contract in output-contract.md:

1. duplicate the source into a clearly named revision copy;
2. apply only approved issue IDs;
3. preserve layout and styles unless a layout change was approved;
4. create a change manifest;
5. rerun deterministic checks;
6. render every page and inspect for clipping, overflow, broken tables, headings, fields, and pagination;
7. verify the original hash is unchanged.

Language principles

• Preserve the author's degree of certainty. Do not turn “建议”“拟”“初步判断” into a categorical conclusion.
• Prefer precise verbs and explicit subjects over generic “持续推动、全面加强、不断提升”.
• Remove repetition and empty transitions only when meaning is preserved.
• Treat “AI-like” as a pattern to verify, not an accusation. Point to repetition, symmetry, abstraction, or unsupported certainty.
• Keep necessary institutional and professional language even if it is less conversational.
• Do not invent data, sources, policy names, legal conclusions, or management commitments.

External verification boundary

Use public sources when allowed and required by the task. Prefer primary and authoritative sources; cite the exact page supporting each finding. Never search for unpublished operating data, upload confidential material, or infer that an unavailable source supports a claim. If verification cannot be performed, say so and keep the claim unresolved.

Final self-check

• Was the source left unchanged?
• Are all P0/P1 findings tied to exact evidence?
• Were calculations independently recomputed?
• Was every material factual claim assigned an evidence status?
• Was each public citation actually opened and checked for entailment, not merely existence?
• Were internal-source checks distinguished from public verification?
• Are unresolved, contradicted, stale, or suspicious citations blocking delivery as required?
• Were false positives removed?
• Were renderer-only limitations kept separate from source-document defects?
• Were the author's role, intent, and voice preserved?
• Does every proposed change have a clear reason?
• Is the remaining uncertainty explicit?
• Did Stage 2 wait for explicit approval?

Resource routing

• Read review-framework.md for every full audit.
• Read source-verification.md for every full audit, final-delivery QA, or citation/hallucination check.
• Read output-contract.md before producing either stage's deliverables.
• Run analyze_chinese_docx.py for DOCX when python-docx is available; disclose when the deterministic pass cannot run.
• Run build_evidence_ledger.py for DOCX to seed claim/source review; never treat its extraction output as verification.

Author and license

• Author: CuteSoda
• License: Apache License 2.0 (Apache-2.0)
• See LICENSE and NOTICE in this distribution.