企业官网建设流程全解析

• AI 技能
• AI 写作
• 人工智能
• 深度研究
• AI 应用

导读

本文基于 PaperSpine 开源仓库中dist/codex/skills/paper-spine/agents/reviewer-writing.md这一 Agent 定义文档展开，全面讲解 Writing Reviewer Agent 的角色定位、审查输入与六大审查维度，并深入关联仓库中的审查策略、证据锚定协议与源码实现。读完本文，你将掌握该 Agent 如何在论文写作/修订流程中以"写作、结构、修辞"视角独立产出可追溯的评审意见，以及如何结合作者表达偏好（author voice）、多语言覆盖与语义不变量校验落实具体的编辑修订。

一、角色定位：写作 / 结构 / 修辞视角的独立评审

Writing Reviewer Agent 是 PaperSpine 独立评审体系中负责写作质量维度的专门 Agent，定义文件位于 reviewer-writing.md。它的 Goal 非常明确：

Goal:Review the manuscript from a writing / structure / rhetoric perspective.

即在论文提交独立评审环节，它不负责方法学正确性、也不负责引文真实性（这些由其他并行 Reviewer 承担），而是专门回答"这篇文章写得怎么样、结构是否成立、修辞与目标场景是否匹配"的问题。

1.1 与其他 Reviewer 的分工

仓库中同一目录下还有两个并行审查 Agent，三者构成视角互补的独立评审集合：

• Method Reviewer Agent：从方法/技术正确性视角审查，关注 method validity、evidence-to-claim mapping、missing controls 与 reproducibility；
• Evidence Reviewer Agent：从证据/引文质量视角审查，关注 claim support quality、citation relevance、source channel traceability 与文献覆盖缺口；
• Writing Reviewer Agent（本文主角）：从写作/结构/修辞视角审查，关注结构与论证流、段落连贯性、语域与目标场景适配、非科学工作流叙述、作者表达偏好与语言覆盖。

三个 Agent 各自独立形成发现，最后由 Editor（编辑器角色）依据 reviewer-persona-registry.json 中定义的角色分工进行合成。从该注册表可以看到，clarity角色专门负责 "Audit argument flow, reader effort, figure/table use, captions, and venue-facing clarity"，与 Writing Reviewer 的职责高度一致；methods与contribution则在strict策略下被激活，构成纵深审查。

1.2 审查输入（Context）

Writing Reviewer 的审查上下文（Context）明确列在定义文档中：

• 手稿文本（manuscript text）：必须基于真实存在的当前手稿，而非文件清单或历史记录；
• writing_rationale_matrix.md：写作理由矩阵，见 writing-rationale-matrix.md。该矩阵要求每个最小写作单元一行，逐行记录 Contribution Promise、动机对齐、SOTA/范本模式、目标场景规范、用户证据锚点与 Planned Change，是评审定位段落级弱点的直接依据；
• style_profile.md：风格画像，其模板与生成方法见 style-learning-workflow.md，包括 Corpus、Global Style、Section Profiles、Claim Strength Rules 等结构；
• exemplar_learning_dossier.md：范本学习档案，见 exemplar-learning-dossier.md，记录范本论文的写作逻辑（如何制造读者兴趣、如何收窄问题、每段功能、如何把测量转成声明等）。

定义文档同时强调："Use existing notes where available; missing historical filenames do not prevent reviewing actual prose, figures and rendered files."也就是说，这些笔记文件是"可用则用"的辅助材料，缺失历史文件名（如旧的 audit 记录、旧的样式收据）绝不能阻碍对真实散文、图表和渲染文件的审查——审查的锚永远是手稿本身。

二、审查前的准备：参考文档与视角校准

2.1 必读的三份参考文档

Writing Reviewer 在开始审查前必须先读三份参考文档：

这三份文档恰好对应 Writing Reviewer 的三个核心能力维度：语域（journal learning）、修辞（assertive writing）、结构（manuscript format）。

2.2 审查视角校准：复用公共任务配置

定义文档要求 Writing Reviewer：

• Use the same public task's saved configuration, target and article type to adjust the review perspective.
• Do not fabricate target venue or conference rules.

即必须复用当前公共任务中已保存的目标期刊/会议、文章类型与配置来校准视角，严禁臆造目标期刊或会议规则。这条规则与 review-policy.md 中"Independent review is read-only with respect to the manuscript"以及"do not fabricate"的一贯原则一致：评审只报告定位准确的、有证据支撑的发现，不创造规则、不要求超出已保存范围的新分析。

2.3 对照真实文件而非推断

定义文档明确要求审查对象是"actual current manuscript beside the local target-venue PDFs and relevant same-field passages"——即把真实手稿与本地目标期刊 PDF和同领域相关段落并排比对。同时特别指出：

Inspect citation markers, punctuation, bibliography targets and figure/table references;do not infer these from file existence or a previous revision's approval.

引用标记、标点、参考文献目标和图表引用的检查，必须基于实际文本内容逐项核实，不能因为"文件存在"或"上一版修订已通过"就推断它们正确。这与 manuscript-format.md 中"source and output correspondence / destination validity / actual rendering / actual reader interaction"四重检查的哲学完全一致——文件存在、构建成功、哈希一致都不等于内容正确。

三、六大审查维度详解（核心章节）

Writing Reviewer 的产出必须按以下六个维度组织发现（findings），这是定义文档给出的强制性组织框架。

3.1 结构与论证流（Structure and argument flow）

审查整篇手稿的结构骨架：标题-摘要-引言-方法-结果-讨论是否形成一条完整、连贯的论证主线；贡献声明是否在开头被提出、在证据中逐步支撑、在结尾被收束。这一维度可直接对照 writing-rationale-matrix.md 中"whole-work framework row"的要求：读者应能从有序的章节开头与图注中一句话说出 C1 贡献、它为何重要、哪条证据验证它、它不宣称什么。

从 journal-learning.md 的"Independent editorial review"一节看，审查者还要独立判断"读者能否用一句话陈述贡献、证据是否支撑完整论证、Discussion 是否增加洞见、每个主图是否配得上它的位置"——这正是 Structure 维度的实践化。

3.2 段落级连贯性（Paragraph-level coherence）

在段落粒度定位问题：每段的单一功能是否清晰、段落内证据是否紧贴其所支撑的声明、段间过渡是否自然、是否有段落承担了两个相互独立的功能（此时应拆成两段，见写作理由矩阵的拆分规则）。发现必须定位到具体段落并给出具体修订方案：

Locate editorial weaknesses in a specific passage and explain the needed revision.

3.3 语域与目标场景适配（Register and target-scene appropriateness）

判断手稿的语气、术语密度、篇幅与呈现方式是否适配目标场景。仓库中的 structured_review.py 在源码层面对这一维度提供了场景化支持：SCENE_VALID = {"journal", "conference", "report_review", "competition"}，且为每种场景定义了clarity角色的标准。例如：

• journal：Evaluate structure clarity, argument coherence, figure/table quality, and adherence to journal conventions；
• conference：Evaluate presentation quality, conciseness, visual clarity of figures/tables, and suitability for oral or poster presentation；
• report_review：Evaluate document organization, readability, heading structure, and whether findings are accessible to the intended audience；
• competition：Evaluate solution presentation, visual quality, result formatting, and overall persuasiveness for competition judges。

写作审查者在评估语域时，应当以这种场景化视角判断"这段写作是否对该目标受众成立"，同时遵守 journal-learning 中"official rules distinct from stylistic patterns"的边界——官方规范是硬要求，范本中观察到的风格是软参考。

3.4 非科学工作流叙述的甄别（Non-scientific workflow narration）

这是 Writing Reviewer 最具辨识度的审查职责之一。定义文档要求标记一类特殊缺陷：以草稿规划闲聊（draft-planning chatter）代替研究论证的叙述，典型例子是"向读者讲述这份草稿是如何被重新组织的"——例如"we have reorganized"这类写法。

同时定义文档给出了严格的边界，防止误删：

• 保留真实且必需的 AI 使用或写作辅助披露（truthful, required AI-use or writing-assistance disclosures）；
• 保留属于研究 Methods 一部分的审查程序（any review procedure that is part of the research Methods）；
• 判定标准是段落实际的科学或透明度功能，而非是否出现 "reviewer" 或 "draft" 等词——"The word 'reviewer' alone is not a reason to remove text."

这一规则在源码中也有对应实现。author_voice_check.py 中的DIAGNOSTIC_PATTERNS定义了一组writing_process_leak模式（如 "this section discusses"、"the following paragraph"、"we have reorganized"、"this manuscript has been revised" 以及中文的"本节将讨论""下文将""本文重新组织"），但脚本明确将这些命中的输出定位为advisory diagnostics（建议性诊断信号），并强调：

Pattern matches are diagnostic signals, not authorship judgments. A clean-text no-op is valid.

即模式命中只提示"此处可能泄漏了工作流叙述"，最终是否删除必须回到段落的科学功能判断，而不是机械执行黑名单删除。这与 assertive-scientific-writing.md 中"contextual editing, not a word blacklist or automatic deletion rule"的表述完全一致。

3.5 作者表达偏好（Author-expression preference）

当同一任务保存了作者表达偏好（即configuration.author_voice_restoration）且处于启用状态时，Writing Reviewer 必须：

• 依据 assertive-scientific-writing.md比较原文与修订后的段落；
• 检查四类要素是否被保存：意义（meaning）、术语（terminology）、强调（emphasis）、声明强度（claim strength）；
• 不需要遗留的 voice receipt、检测器分数（detector score），不允许对已经清晰无误的文本进行强制改写（no forced rewrite of already-clear text）。

作者表达偏好本身有三个档位（见 assertive-scientific-writing.md 的 "Apply the saved author-expression preference" 一节）：

三个档位都不允许改变结果、声明强度或科学含义。修订后段落必须与原段落在数字、否定、限定语、归属与结论强度上可比对。

源码级支撑：语义不变量（Semantic Invariants）校验

author_voice_check.py 正是把"修订不得改变科学含义"落实为机器可校验不变量（invariants）的实现。其invariant_extractors定义包括：

• numbers_units：数字与单位（支持%、mg、μL、°C等数十种单位后缀）；
• citations：LaTeX\cite与 Pandoc[@key]引用键；
• formulas：行内/展示/环境公式（$...$、\[...\]、equation/align/gather/multline）；
• protected_terms：作者受保护术语；
• negation：否定词（英文 not/no/never/neither/without/lack…，中文 不/未/无/没有/并非…）；
• causal_direction：因果方向词（because/therefore/leads to/导致/引起/归因于…）；
• modality_uncertainty_claim_strength：情态不确定性词（may/might/could/suggest/可能/或许/提示…）。

任何不变量在 voice restoration 前后发生漂移（_counter_diff非空），都会产生semantic_invariant_drift的BLOCKER级硬发现（hard finding），直接导致结果BLOCKED。同时脚本还校验：rewrite 模式必须有非空、含 locator/reason/evidence 字段的变更日志；语义审计必须由独立于改写者的身份完成（independent_agent）；作者确认必须绑定当前修订版哈希。这套源码从工程层面印证了 Writing Reviewer 审查"声明强度与术语保存"时的机器可查基础。

此外脚本输出中style_deviation仅是描述性距离（descriptive distance only, not authorship evidence），再次呼应文档"detector score 不是评审依据"的立场。

3.6 请求的语言覆盖（Requested language coverage）

对于多语言工作（multilingual或other输出语言），Writing Reviewer 必须：

• 比较完整语言版本：标题、摘要、正文、图注、表格、注释及相关补充材料都要逐语言对比；
• 比较数字、引用、图注与实际渲染结果；
• 明确一条硬边界："A translated summary or internal report does not establish a complete translated manuscript."——翻译摘要或内部报告不能算作完整翻译手稿。

这条规则的工程依据同样存在于仓库。manuscript-format.md的 "Apply the requested output language" 一节要求为每种请求语言产出完整手稿（含标题、摘要、正文、图注、表格、注释和相关补充材料），使用单一科学来源与对应语言版本、稳定引用键/对象 ID，且"translations may differ in wording and layout, not findings"（翻译可以在措辞与版式上有差异，但结论不能变）。配套的 translate_guard.py 与 translation-package.md 进一步约束翻译包结构与完整性校验。Writing Reviewer 的语言覆盖检查正是这套多语言产线的质量验收环节：不能只看渲染页数或字数，而要逐语言、逐数字、逐引用比对。

四、独立评审纪律：先形成发现，再读并行意见

定义文档最后一段给出了 Writing Reviewer 的评审纪律，这也是整套独立评审体系信任模型的核心：

Form this round's findings independently before reading parallel reviewers' unsubmitted opinions.

即本轮评审意见必须在阅读并行评审者（Method/Evidence Reviewer）尚未提交的意见之前独立形成，避免锚定效应。同时：

Prior user-provided reviews, responses and revision diffs remain valid inputs when checking a revision. Write your own review file.

先前用户提供的评审、作者回复与修订差异，在检查修订版时依然是有效输入（因为修订本身就是对它们的回应）；但 Writing Reviewer 必须写出属于自己的评审文件，不能继承他人（或自己上一轮）的结论。

这条纪律与 evidence-grounded-review.md 的"Controlling rule"衔接：每条可操作发现必须携带四个链接——① 精确的手稿定位符（页/行/段/图/表/公式/附录坐标）加短引用，或对"要求内容缺失"的穷尽式缺席扫描收据；② 提出该发现的审查者及其评审收据；③ 用于得出该发现的读取/搜索/标注工具收据；④ 具体的修订建议、置信度、严重度与处置。未定位的意见只是 advisory note，不是科学/编辑阻断项——这正是 Writing Reviewer"locate editorial weaknesses in a specific passage"要求的证据化延伸。

五、与审查策略（review-policy）的衔接

Writing Reviewer 在哪种审查策略下运行、如何确定发现严重度，由 review-policy.md 决定：

• Balanced（默认）：Editor 通读手稿与渲染成品，Writing 维度的编辑意见被要求"ground every actionable editorial comment in a precise manuscript location and short excerpt"，但不强制三个人物、逐段理由矩阵或独立 objection 登记。CRITICAL 科学缺陷阻断；MAJOR 仅在影响主声明、图表/文本身份、引文真实性或交付可用性时阻断；MINOR/风格意见为建议性。一个 gate 可以报告PASS_WITH_ADVISORIES而不必把建议转成更多表单。
• Strict：在用户明确要求严格审计/投稿认证/合规审查时启用，额外激活 Methods、Contribution、Clarity 等专业视角，其中 Clarity 即对应写作/修辞维度。Strict 依然禁止"以官僚流程奖励"——产物通过是因为捕获了有用的决策或可核实的事实，而不是因为够长。

对 Writing Reviewer 而言，其"写作/结构/修辞"发现天然属于 Clarity 路线：结构清晰性、读者负担、图表使用、图注与面向目标场景的清晰度（见 structured_review.py 中 clarity 角色的场景化标准）。而 reviewer-audit.md 则要求把 Clarity 评审的实际发现转化为Reviewer Objection Register中"审稿人会怎么攻击这篇稿子"的预判条目（如"key claim 被拆到两个章节、迫使读者来回翻"），为每条给出预防性修复与状态——这正是"以写作审查者的发现反哺投稿前防御"的落地场景。

六、实操要点：如何用好 Writing Reviewer Agent

综合定义文档与仓库实践，可以把 Writing Reviewer 的运作归纳为以下可执行流程：

1. 准备输入：确认当前任务保存的 target、文章类型、configuration.author_voice_restoration、configuration.output_language与review_policy（缺失/未知时默认balanced，见 review-policy.md 的 Policy Resolution）；
2. 阅读参考：先读 journal-learning.md、assertive-scientific-writing.md、manuscript-format.md；
3. 并排对照：把当前手稿、本地目标期刊 PDF 与同领域段落并排放置，逐段、逐图、逐引用检查实际内容；
4. 按六维度组织发现：结构与论证流 → 段落连贯性 → 语域与场景适配 → 非科学工作流叙述 → 作者表达偏好 → 语言覆盖；每条发现定位到具体段落/行/图并给出具体修订；
5. 先独立、后合流：独立成稿后，才可与并行 Reviewer 的未提交意见对照，由 Editor 按 reviewer-persona-registry.json 的角色分工合成（balanced 下 Editor 单一合成，strict 下先 Methods/Contribution/Clarity 独立再审）；
6. 写自己的评审文件：产出属于本轮、绑定当前修订版文件与哈希的评审记录，并在其中注明检查过的材料与剩余缺口，不继承历史 PASS。

七、总结

Writing Reviewer Agent 是 PaperSpine 独立评审体系中专司"写作质量"的守门人。它把结构与论证流、段落连贯性、语域与场景适配、非科学工作流叙述、作者表达偏好、语言覆盖六个维度固化为可执行的评审框架，并以"真实手稿 + 本地目标期刊 PDF"为唯一审查对象，拒绝从文件存在、历史收据或检测器分数推断质量。

其工程支撑遍布仓库：写作理由矩阵 writing-rationale-matrix.md 提供段落级定位坐标，author_voice_check.py 以数字/单位/引用/公式/否定/因果/情态七类语义不变量守护"修订不改变科学含义"，structured_review.py 提供四种目标场景的 clarity 评判标准，evidence-grounded-review.md 则要求每条发现都携带定位符、评审收据、工具收据与处置建议。理解这套 Agent 定义，等于同时理解了"独立评审不替代作者判断、检测分数不替代人工阅读、文件存在不替代内容核对"这三条 PaperSpine 评审哲学。

如果你正在搭建自己的论文多视角评审管线，或想了解 Agent 化评审如何做到"既有定位精度、又有防误删边界"，Writing Reviewer Agent 的定义文档与上述配套实现是一套可以直接参考的最小完整范例。

• AI 技能
• AI 写作
• 人工智能
• 深度研究
• AI 应用