chinese-thesis-workbench

中文论文工作台

工作模式

以标准和证据作为控制层，再以中文论文写作流程作为输出层。在正式撰写正文之前，先将学校模板、导师要求、任务书、范文、源代码、数据库、API、测试、文献 PDF、截图、Word 批注和现有草稿整理为结构化状态。

工作台分为两部分：

• 治理侧：paper-context/ 用于存储工作流状态、标准、证据、文献、AIGC 报告和 Word 批注修订记录。
• 交付侧：paper-output/ 用于存储论文 Markdown、DOCX、附录 DOCX、图表、截图、图片映射和参考文献核验材料。
• 面向用户的可见性与决策侧：paper-context/workflow/user-dashboard.md 汇总当前进度、缺失材料、需要用户决定的事项以及下一步建议操作。paper-context/workflow/content-decisions.md 在有候选内容时，记录可选的内容侧重与排除决定。paper-context/workflow/blocker-report.md 记录最新阻塞项、可选方案、建议以及有限继续状态。paper-context/workflow/user-decisions.md 记录经用户批准且会影响范围、证据、标准、提纲、交付或限制的选择。这些文件有助于提高透明度，但不会取代标准、证据或交付质量门槛。

必需工作流

除非用户只要求进行范围较窄的检查或修订，否则按以下顺序运行工作流：

1. intake_materials：收集材料，并在 paper-context/workflow/material-inventory.md 中记录优先级、缺口、缺失材料的影响、继续工作的限制以及用户后续步骤。
2. init_workspace：初始化 thesis-ai-standard/、paper-context/ 和工作流日志。
3. resolve_standards：填写 thesis-ai-standard/templates/standard-profile.yaml。
4. analyze_sample_and_template：起草前，将学校模板和范文解析器的输出规范化为轻量分析报告、提纲建议和字数预算；除非用户通过 --sample-analysis 明确选择按范文风格生成，或通过 --from-template 选择填充模板副本，否则解析器输出不会用于 DOCX 排版。
5. build_evidence：将项目事实提取到 paper-context/evidence/。
6. stop_and_report：只要证据、标准、图表、引文或 DOCX 交付无法核验，就停止或限制受影响的范围；在 blocker-report.md 中记录可选方案。
7. build_thesis_spec：填写 thesis-ai-standard/templates/thesis-ai-spec.yaml。
8. build_figure_registry：填写 thesis-ai-standard/templates/figure-registry.yaml。
9. confirm_outline：写作前确认章节结构、字数、范文／模板分析结果，以及任何已确定的内容侧重／排除决策。
10. draft_chapters：仅依据已确认的结构化事实和证据撰写。
11. produce_assets：生成或收集图表、示意图、截图、表格和附录来源材料。
12. produce_docx：根据记录的交付路径，在 paper-output/ 中生成或编辑主 DOCX 和附录 DOCX。
13. quality_gates：运行标准、证据、参考文献、图表、DOCX 和 AIGC 检查。
14. delivery_report：报告输出内容、限制、尚待人工决定的事项以及核验依据。

stop_and_report 是全局阻塞机制，不仅限于第 6 步。只要继续工作可能需要猜测，就应阅读 references/workflow/stop-and-report.md。

阶段 + 状态模型

在 paper-context/workflow/workflow-status.md 中使用此双层状态模型，并在 paper-context/workflow/user-dashboard.md 中同步面向用户的摘要：

字段	可用值
phase	intake_only、workspace_ready、standards_resolved、sample_analysis_done、evidence_built、spec_confirmed、outline_confirmed、writing_allowed、delivery_done
status	pending、in_progress、blocked、needs_review、done、deprecated

当状态变为 blocked 时，在状态文件中填写 blocked_reason、missing_materials、next_action 和 can_continue_with_limitations。不要只在聊天中提及阻塞事项。

每当阶段、阻塞事项、材料、大纲或交付范围发生实质性变化后，更新 user-dashboard.md，让用户能够查看：

• 当前阶段和状态
• 已完成的工作
• 等待用户确认的决策
• 缺失的材料及其影响
• 下一项建议操作
• 可继续推进的选项（如有）

决策树

1. 如果尚无工作区，运行 scripts/workspace/init_thesis_workspace.py。
2. 如果缺少学校／导师／模板规则，或这些规则相互冲突，先解决规范问题。
3. 如果尚未分析样例／模板，先完成分析，再处理 thesis-ai-spec.yaml。
4. 如果缺少来源证据或文献，先构建证据和参考资料池，再开始写作。
5. 如果 thesis-ai-spec.yaml 尚未确认，不要撰写正式论文正文。
6. 如果 figure-registry.yaml 尚未就绪，不要声称图表／截图已完成。
7. 如果用户要求修改 Word 批注，提取批注并返回 writing_allowed 阶段。
8. 如果用户要求最终交付，运行质量检查，并生成主文档和附录 DOCX。

硬性规则

• 学校和导师的要求优先于默认规则。
• 在收集完材料或用户明确确认没有更多材料之前，不要撰写正式论文正文。
• 在材料收集阶段，将材料分类为 required、strongly_recommended 或 optional，并说明缺少每项必需或强烈建议材料的影响。
• 当用户提供功能、模块、实验或附录候选内容时，使用 content-decisions.md；但不要仅因用户尚未提供候选内容而阻断主要工作流。
• 将用户批准的范围、材料不可用、有限继续、标准冲突、内容排除、大纲、字数、DOCX、附录和文件名决策记录在 user-decisions.md 中。
• 面向用户的工作流文件仅用于辅助决策。它们不得削弱学校或导师的要求、证据要求、引用核验、图表溯源或 DOCX 交付检查。
• 在完成标准、样本或模板分析以及证据构建之前，不要撰写正式论文正文。
• 证据不足时，触发 stop_and_report；不得猜测缺失事实。
• 遇到阻碍时，将问题归类为 hard_blocker、limited_continue 或 user_choice_needed，然后提供用户选项和建议路径。
• thesis-ai-spec.yaml 是论文事实的唯一入口。
• figure-registry.yaml 是图、表、截图及示意图来源的唯一入口。
• 论文正文只能使用结构化事实和证据；不得直接依据 README 文件或旧笔记扩写。
• 不得撰写 content-decisions.md 标记为已拒绝、已排除或等待证据的内容。
• 不得编造功能、字段、API、测试结果、实验数据或参考文献。
• 证据链完整后再进行 AIGC 风格治理，且仅可改进学术表达、证据密度和含糊措辞。
• 论文正文不得暴露 AI 工作流相关表述。
• 第 4 章的实现内容必须对应真实模块、截图、核心代码、SQL 或等效证据。
• 没有 E-R 图或等效数据设计证据的系统设计类论文不得标记为已完成。
• 生成论文正文 DOCX 和附录 DOCX。学校格式要求严格时，优先使用 scripts/docx/apply_textual_edits.py --from-template 基于模板填充；否则使用默认样式或样例样式生成。不要承诺完整复刻模板。将示意图源文件、E-R 图源文件、流程图源文件及相关资源保留在附录中。
• 必须明确公式交付方式：latex_text 保留公式源文本，而 formula_image 需要匹配的图像资源。
• 输出文件名必须使用论文标题，不得使用 final、draft、paper-final 或 doc1 等通用名称。
• 文献工作流必须依次为：构建文献池 -> 核验 -> 筛选 -> 格式化 -> 生成核验清单。

资源索引

需求	资源
材料收集与快速工作流	references/workflow/intake.md、references/workflow/rapid-thesis-workflow.md
工作流状态、阻塞项与稀疏材料交接	references/workflow/workflow-state-management.md、references/workflow/stop-and-report.md、references/workflow/material-gap-handoff.md
标准与模板解析	references/standards/standards-and-template-resolution.md、references/standards/style-extraction.md、references/standards/default-style.md
证据提取	references/evidence/source-to-thesis-workflow.md、references/evidence/fact-extraction.md
文献/PDF 工作流	references/evidence/literature-and-pdf-workflow.md、scripts/literature/
写作与章节控制	references/writing/writing-pipeline.md、references/writing/chapter-patterns.md、references/writing/sample-analysis.md
AIGC 风格治理	references/writing/aigc-style-governance.md、scripts/review/analyze_aigc_style.py
DOCX 交付与 Word 批注	references/delivery/docx-delivery.md、references/delivery/word-comment-revision-workflow.md、scripts/docx/
图表与屏幕截图	scripts/figures/、scripts/screenshots/、thesis-ai-standard/templates/figure-registry.yaml
合并来源追溯	references/merge-map.md

质量检查关卡

在宣称交付质量达标前，请检查：

• standard-profile.yaml、thesis-ai-spec.yaml 和 figure-registry.yaml 均存在且内容前后一致。
• 每项重要事实主张都有 paper-context/evidence/ 中的来源或经过核验的文献作为依据。
• 每个图表都包含 source_kind、source_path、image_path、evidence_source、first_mention 和 status。
• 参考文献均真实存在、选自经过核验的文献池，并已生成核验清单。
• AIGC 风格调整不会添加事实。
• 主 DOCX 和附录 DOCX 均存在于 paper-output/ 中。
• 屏幕截图、图表和图像映射的路径在 Windows 上均可解析。
• 工作流日志反映当前阶段、状态、阻塞项和交付限制。
• user-dashboard.md 反映用户可见的进度、待决事项、缺失材料和后续操作。
• blocker-report.md 反映最新阻塞项、受影响范围、用户选项、建议方案，以及是否允许有限度继续处理。
• user-decisions.md 记录用户批准的选择，这些选择会影响范围、缺失材料处理方式、限制、标准、提纲或交付。
• 如果 content-decisions.md 中有待处理候选项，其已批准/已延期/已排除状态须与提纲、论文规范和图表登记表保持一致。

交付约定

将论文产物交付至 paper-output/：

• <论文标题>.md
• <论文标题>.docx
• <论文标题>-附件.docx
• <论文标题>-image-map.json
• <论文标题>-文献核验清单.json
• figures/
• screenshots/

报告已核验的内容、无法核验的内容，以及仍需人工确认的事项。如果无法运行核验，请说明所用命令及原因。