企业官网建设流程全解析

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

导读

Writing Rationale Matrix（写作理据矩阵）是 PaperSpine 论文生产流程中"贡献优先（Contribution-First）"方法论落到写作环节的关键工具：在动笔或改写前，把每段、每个图注、每个承载论证的标题都拆成独立规划行，并让每一行都绑定已确认的贡献承诺（C1/C2…）、已确认动机、SOTA/范例结构迁移、目标场景规范和具体证据锚点。读完本文你将掌握：矩阵的十列结构如何建立、最小写作单元如何切分、行级理由质量门槛如何执行、改写（rewrite_existing）与从素材构建（build_from_materials）两条工作流如何使用同一张矩阵，以及它如何与confirmed_contribution.md、results_validation.md和证据台账联动，最终形成一份可学习、可审计的"设计备忘"而非"待办清单"。

一、矩阵在 PaperSpine 中的位置：何时使用

矩阵由编排器（orchestrator）在两种写作工作流中统一调用，完整定义见仓库中的 writing-rationale-matrix.md：

• rewrite_existing（改写既有稿件）：在实质性改写前应用矩阵的贡献、证据与结构提问，把有效决策记录到既有笔记、大纲或矩阵行中。一次窄幅编辑可以直接复用仍然有效的旧计划——矩阵的目的不是"每改必建"，而是确保改写背后的推理真实发生过。
• build_from_materials（从素材构建新稿）：在尚无真实草稿时，用矩阵逐行规划出完整的、证据约束下的论证，而非输出"模板壳"。

在 rewrite.md 与 build.md 两个阶段 playbook 中，矩阵被定位为Strict / Optional工具：严格模式（strict mode）或用户显式要求段落级理据追溯（rationale trace）时才要求完整应用矩阵；平衡模式（balanced mode）使用section_blueprints.md、证据台账与结果映射，不必为了凑行数而造段落行。这一点在 audit.md 的完成硬门禁中得到呼应：严格模式下"存在但泛泛的矩阵（generic rationale matrix）"直接判失败，平衡模式则不因缺少行级文书而阻塞一篇科学上站得住脚的论文。

重要边界：矩阵是内部脚手架，其价值在于"先推理、后成文"，绝不能用"事后补一张表"冒充写作前的规划（a post-hoc account is not evidence of prior planning）。

二、核心原则：为每一个"最小有用写作单元"建一行

矩阵的第一原则是行粒度由写作决策决定，而不是由章节模板决定。每一行对应一个"需要刻意决策的最小有用写作单元"，单元大小随任务类型变化：

• 期刊或会议论文：整体框架、标题/摘要单元、Introduction 的 moves、方法设计解释、结果证据单元、图/表所承载的断言、讨论 moves、图注，以及承载论证的标题；
• 报告或综述：执行摘要单元、问题/背景单元、分类（taxonomy）或对比单元、证据综合单元、建议单元、局限/未来工作单元，以及重要的标题/图/表；
• 竞赛论文或报告：问题重述、假设、符号、模型设计、求解步骤、验证、敏感性/稳健性、优势与劣势、建议，以及图表/表格断言。

同时有三条反模板约束：不要把任何任务都硬套进 Abstract/Introduction/Methods/Results/Discussion；不要只给每个顶层章节一行；每当写作决策发生变化，就把手稿切成段落级或断言级的单元。例如竞赛题解可能需要"假设—符号—模型推导—算法步骤—敏感性分析—建议"这类任务专属行，综述则需要"检索范围—纳入逻辑—分类维度—综合断言"行。

三、必填十列表格：矩阵的骨架

矩阵要求一张固定列头的十列 Markdown 表格，作为每一行的承载结构（以下为完整表头，可直接复制使用）：

十列的分工可概括为"三个锚 + 一个结果"：

1. Row ID：行标识（如 F1、R2、D3），便于跨文档引用；
2. Manuscript Unit：该行对应的具体写作单元（段落、图注、小节标题或整体框架）；
3. Current Problem or Planned Function：当前版本的问题，或该单元的计划功能；
4. Contribution Promise / Claim ID：该行推进、验证、解释或限定的贡献承诺编号；
5. Motivation Alignment：动机对齐——解释该承诺为什么重要，但不能替代承诺本身，也不得超出其声明边界；
6. Reference/SOTA Pattern Learned：从 SOTA/范例中迁移的结构性 moves；
7. Target Scene or Venue Norm：目标场景（期刊/会议/报告/竞赛）的规范；
8. User Evidence or Citation Anchor：具体的用户证据、图表、结果或引文锚点；
9. Planned Change/Text Move：计划中的文本动作；
10. Final Text Check：成文后的最终校验结论（见第六节）。

四、必填覆盖要求（Required Coverage）

除了表头，矩阵还规定了六条强制性覆盖规则：

1. 第一数据行必须是整体框架行：为全文框架、结构或主线索（throughline）提供完整辩护；
2. 每一行都必须声明其服务的贡献承诺（推进/验证/解释/限定），使用C1、C2… 编号，并与confirmed_contribution.md和results_validation.md保持一致；
3. 动机是独立的对齐列：它解释承诺为何重要，但不能充当承诺本身，也不得越过承诺的声明边界；
4. 后续每一行应对应手稿中的一个真实写作单元，且按手稿顺序排列；
5. 使用任务专属单元而非固定模板（竞赛/综述各有其专属行类型，见第二节）；
6. 标题、小节标题、图注、表注若承载论证逻辑，也必须纳入行规划。

关于行粒度的弹性规则：一个段落若承担两种独立功能，拆成两行；三个短段落若共享一种功能，可合并为一行覆盖该段落组。

五、理由质量门槛（Reason Quality Bar）

每一行必须包含具体推理，而不是泛泛的润色语言。理想情况下，一行应尽可能同时说明该单元如何：

• 推进、验证、解释或限定一个已确认的贡献承诺；
• 在不扩大承诺的前提下，将承诺与已确认动机对齐；
• 从 SOTA/范例中迁移结构 moves（迁移结构，绝不抄袭措辞或结果）；
• 匹配目标期刊/会议/报告/竞赛规范；
• 使用某一具体用户证据项、图、表、结果或引文锚点；
• 把证据移到其所支撑的断言旁边；
• 与更早或更晚的单元形成首尾呼应（front/back echo）；
• 修复原有逻辑缺陷；
• 防止超出可得证据的过度声明。

明确的禁用语：improve clarity（提升清晰度）、make academic（学术化）、polish wording（润色措辞）、add detail（补充细节）等泛化理由一律不通过。

六、最小深度要求（Minimum Depth Requirement）

• 粒度要覆盖真实写作决策：短文或窄幅修改可能只需要少数几行；复杂论证可能需要很多行。行数本身不构成深度——不以数量论英雄，而以"是否覆盖了实际决策"为准；
• 第一行（框架行）必须深度解释：哪个贡献契约统领全文、已确认动机如何确立必要性、迁移了哪个 SOTA/范例模式、如何匹配目标场景、以哪条用户证据为锚、后续章节将如何对照它被检查；
• 每个非平凡行必须"教会"这一写作决策，而非只写出章节名：必须包含贡献承诺、动机对齐、习得的参考/SOTA 模式、目标场景规范、证据/引文锚点、计划文本动作、最终校验；若某项不适用，必须说明为什么不适用；
• 禁止把大决策压缩成一句短语：像conservation-first abstract（守恒优先摘要）或add ablation section（加消融章节）这类行不合格——必须解释该 move 如何改变论文逻辑，以及最终文本将如何证明它。

七、改写与构建纪律（Rewrite And Build Discipline）

成文要逐行进行：最终手稿应逐行起草。改写任务中，每一行都应可追溯到原逻辑图（original logic map）和/或一次有意的结构变更；从素材构建任务中，每一行都应可追溯到源清单（source inventory）、证据库（evidence bank）、断言登记簿（claim register）或图表资产映射（figure asset map）。

脚手架内部化（Scaffolding stays internal）：矩阵只用于展开科学论证，不得把规划标签、修订物流说明、对导师/审稿人的回应叙述抄进手稿。必须保留要求的 AI 使用或写作辅助披露，以及属于研究 Methods 的评审程序。判定一段文字要看其科学或透明性功能，而非其中是否出现reviewer、draft等词。

Final Text Check 列（成文后回填）：该列取值必须以PASS或FAIL开头，随后给出最终位置或仍失败的原因。合格示例：

• PASS: Section 2 paragraph 3 now states the claim after citation C12.
• FAIL: no verified citation yet for this mechanism claim.

只写位置、写done或模糊备注的值不通过审计。这一规则在 rewrite.md 与 build.md 中被同样强制：每个Final Text Check值必须以PASS/FAIL开头，禁止done这类含糊写法。

八、细节标准（Detail Standard）：让矩阵成为"学习文档"而非"检查清单"

一行必须详细到读者能从中学到写作逻辑。禁止把graphic path fix（修图路径）或rewrite abstract（重写摘要）当作主要解释。每个非平凡行必须包含八项内容：

1. 该单元原本或计划要实现什么；
2. 为什么当前版本逻辑薄弱，或为什么需要该单元；
3. 哪个已确认贡献承诺统领该单元；
4. 已确认动机如何支撑该承诺；
5. 正在迁移哪个 SOTA/范例/目标场景模式；
6. 哪条用户证据、图、表、结果或引文锚点支撑它；
7. 将执行的精确修辞动作（rhetorical move）；
8. 最终文本应如何被检查。

对重要单元，单元格内优先写 2～4 句完整句子而非关键词。矩阵的价值定位是"可学习的文档"，而不仅是"审计勾选清单"。

九、深框架行示例（Deep Framework Row Example）：设计备忘而非 TODO

整体框架行应更像一份设计备忘（design memo），而不是一条待办事项。原文档给出了完整可用的 F1 行示例，此处完整复现并逐列拆解其写法逻辑：

逐列拆解可提炼出框架行的标准写法：

• Current Problem：点出"当前草稿可能含多个有效技术点，但论文需要一个主导贡献 + 一条让该贡献不可避免的证据序列"——这是框架行要解决的核心问题；
• Claim ID：明确C1是confirmed_contribution.md中的统领承诺，所有章节对其履行"确立需求 / 使其可测 / 验证 / 解释 / 划定边界"五类职责之一；次要工程选择除非单独确认为 C2/C3，否则只是机制（mechanism）；
• Motivation Alignment：写明动机的三段作用——先暴露未解问题、再说明设计响应为何必要、最后让证据在不膨胀承诺的前提下检验它；
• SOTA Pattern：强调"在结构层面学习（如何编排 gap、设计理据、证据顺序、失败模式、受限讨论），不抄措辞"；
• Target Scene：按目标场景差异给出论证架构——期刊要 IMRaD 与独立评估，竞赛报告要假设/模型逻辑/验证/敏感性/建议，课程报告要"评测量表可见"的证据；
• Evidence Anchor：锚定用户真实草稿/素材，并明确外部论文只能教结构、其发现必须保留归属、不得冒充本研究结果；
• Text Move：重构手稿使每个主要章节回答 C1 的一部分，直到证据序列与声明边界可见；
• Final Check：以PASS:开头，验收标准是"读者能按章节开头与图注依次说出 C1、它为何重要、哪条证据验证它、它不声称什么"。

十、与仓库核心方法的源码级联动

矩阵不是孤立表格，它与 PaperSpine 的贡献契约、结果验证和证据台账构成完整链条，可从仓库源码逐一印证：

1. 与 Contribution-First（贡献优先）的契约绑定

矩阵的Contribution Promise / Claim ID列直接来源于 contribution.md 定义的硬规则：正式动笔前，必须从同一任务已保存的选择或既有手稿中确定受支持的贡献及其边界。该文档明确指出"每个后续产物（章节蓝图、writing-rationale matrix、手稿本身）都必须追溯到这里的单一 Core 贡献陈述；如果一个段落不推进、不支持或不限定该陈述，它就不该存在"。矩阵的C1/C2编号体系即由此而来，且与动机严格分工：confirmed_motivation.md回答"该问题为何重要"，confirmed_contribution.md回答"这篇论文确立了此前不存在的东西、且能以多强语气声明"——没有贡献的动机只是文献综述，没有动机的贡献是无人问津的结果，两者都需要，且贡献居于主导。

contribution.md给出的confirmed_contribution.md四段结构（Core Contribution / Why This Contribution Is Needed / How This Paper Responds / Claim Boundary）中，"Evidence missing"与"Claim boundary"两栏正是矩阵行级"防止过度声明"的上游依据；而contribution_check.py把TODO、TBD、...等占位符视为失败，与矩阵"泛化理由不通过"的质量门槛一脉相承。测试 test_contribution_check.py 验证了"填充完整的 fixture 通过、缺文件失败、缺 Claim Boundary 章节失败、TODO 占位失败、空单元格失败"五类判定，可作为理解该门槛行为的参考。

2. 与 Results-as-Validation（结果即验证）的编号一致性

矩阵要求C1、C2… 与results_validation.md保持一致，后者定义于 results-validation.md：每个主要 Results 单元必须把"贡献断言 / 证据 / 图表明细 / 确认条件 / 允许解释 / 不允许解释"映射成行，且每个贡献至少需要一行。该文档特别警告：Interpretation NOT Allowed留空是审稿人"过度声明"投诉最常见的原因——这与矩阵"禁止超出证据的过度声明"的八条理由栏完全同构。其检查命令为：

python src/scripts/results_validation_check.py paper_rewriting_output --markdown --write

测试 test_results_validation_check.py 展示了其判定逻辑：贡献列被留空的"纯指标行（metric-only row）"是硬失败，映射了断言与证据的行才通过（输出Status: PASS）。

3. 与科学证据台账的机器可检查链路

矩阵的用户证据锚点列，最终应能穿透到 scientific-evidence-ledger.md 定义的scientific_evidence_ledger.json——该台账用S###（来源）、C###（断言）、N###（数值事实）、M###（方法）、O###（结果）、R###（结果记录）六类记录承载验证状态，其生命周期要求"投稿前每个用于终稿的记录必须为verified、user_authoritative或not_applicable"。矩阵负责"解释贡献逻辑"，台账负责"保留科学粒度和验证状态"，二者互补而非替代：

python src/scripts/scientific_evidence_check.py paper_rewriting_output --phase planning --markdown --write python src/scripts/scientific_evidence_check.py paper_rewriting_output --phase final --markdown --write

4. 在编排器审计中的角色与失败判定

• audit.md 的完成硬门禁明确列出："strict-mode rationale matrix is generic（严格模式矩阵泛泛而谈）"属于不完整的任务状态，不得声明完成；writing_rationale_matrix.md属于工作流产物，应位于paper_rewriting_output/目录内；
• orchestrator-branch-map.md 在"不支持的断言"分支中把矩阵列为检查对象；
• SKILL.md 同时给出边界：工具成功、哈希与任务状态不构成科学/编辑/视觉/投稿就绪度证明——矩阵通过审计只意味着"计划推理充分"，不意味着"稿件科学上正确"。

十一、矩阵的完整落地工作流（速查）

综合 writing-rationale-matrix.md、rewrite.md、build.md 与 motivation-thread-writing.md，一张矩阵从建立到验收的完整步骤如下：

1. 锁贡献契约：从同一任务的confirmed_contribution.md取得统领承诺 C1（及其边界），从confirmed_motivation.md取得对齐动机；
2. 建首行：撰写 F1 框架行，按第九节"设计备忘"标准深度辩护整体结构；
3. 切单元：按任务类型（期刊/综述/竞赛）把稿件切成段落级或断言级单元，标题、图注、表注若承载论证也必须成行；
4. 逐行填锚：每行补齐贡献承诺、动机对齐、SOTA/范例模式、目标场景规范、证据/引文锚点、计划文本动作六要素；不适用的要素说明理由；
5. 逐行成文：按行起草/改写，改写行可追溯原逻辑图，构建行可追溯源清单/证据库/断言登记簿/图表资产映射；脚手架标签不得进入手稿正文；
6. 回填校验：成文后更新Final Text Check列，取值以PASS/FAIL开头并给出最终位置或失败原因；
7. 联动审计：证据承载场景下先跑results_validation_check.py，投稿前让证据台账记录达到verified/user_authoritative状态；严格模式下最终审计以"矩阵是否具体而非泛泛"为通过条件之一。

十二、常见误区与对照

结语

Writing Rationale Matrix 的本质，是把"这篇论文为什么必须存在、每个写作单元如何为它服务、证据如何锚定每个断言"三件事从隐性直觉变成显式行记录。它既是一份写作前的设计备忘，也是一份成文后的可审计凭证：审稿人可以从矩阵读到论证编排，作者可以从矩阵学到下一次写作的决策逻辑，而仓库中的contribution_check.py、results_validation_check.py、scientific_evidence_check.py及配套测试则为这套推理提供了机器可检查的落点。严格模式下，一张"具体而非泛泛"的矩阵，是 PaperSpine 论文从规划走向可交付稿件的一道真实门禁。

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