thesis-standardizer

论文规范化工具

目的

默认只专注一项主要工作：将真实的程序转化为经得起检验的本科毕业论文。

始终以证据为依据：

1. 模板规则
2. 项目事实
3. 代码／数据库／API／测试证据
4. 章节计划
5. 正文
6. 图表
7. Word／PDF 检查

除非用户明确要求先写一份粗略草稿并接受证据缺失的风险，否则不要从自由发挥的正文开始。

不可妥协的完成门槛

此技能采用 Superpowers 风格的门槛结构：规则不是提醒，而是可执行的停止条件。

NO FINAL DOCX COMPLETION CLAIM WITHOUT FRESH AGGREGATE-GATE EVIDENCE

在称论文 .docx 已完成、合格、已修复或可以提交之前：

1. 确认最终 .docx、图示映射、预期的 Visio OLE 数量、标题最低要求以及论文规定长度。
2. 对当前文件运行 scripts/check_final_thesis_docx.ps1，而不是对之前的草稿运行。对于普通本科系统类论文，使用 -MinContentUnits 12000 -MinCjkChars 10000，除非学校模板另有规定。
3. 阅读输出结果和退出代码。
4. 如果任何门槛未通过，请修复文档或准确报告未通过的门槛。不要声称已完成。
5. 只有在所有门槛均通过后，才能报告验证证据。

出现以下警示时，必须停止并运行门槛检查：

• “表格规则已经写在技能里了。”
• “文档在 Word 里看起来没问题。”
• “三线表通过了，所以续表大概也没问题。”
• “之前的演示通过了。”
• “只做了一点小修改。”
• “Visio/OLE 与这次表格修改无关。”

主流程：从程序到论文

对于项目／代码仓库／系统源代码，请按以下流程执行：

1. 如果存在学校提供的 .docx 模板，请提取模板信息： scripts/extract_docx_template_profile.py <template.docx> --out paper-context/template-extract 然后构建面向组件的复现计划： scripts/build_thesis_structure_plan.py --template-profile paper-context/template-extract/template-profile.json --spec thesis-ai-standard/templates/thesis-ai-spec.yaml --out paper-context/template-extract/thesis-structure-plan.yaml 如果存在模板，请在起草或最终排版前阅读 references/template-replication-workflow.md。
2. 初始化／检查论文工作区： scripts/init_thesis_workspace.py <target-dir>
3. 构建项目证据： scripts/build_project_evidence.py <project-dir> --out paper-context/evidence
4. 填写或更新： thesis-ai-standard/templates/standard-profile.yaml thesis-ai-standard/templates/thesis-ai-spec.yaml thesis-ai-standard/templates/figure-registry.yaml
5. 在起草第 3 至第 6 章之前，先制定图表／截图计划： scripts/build_figure_plan.py thesis-ai-standard/templates/thesis-ai-spec.yaml --out paper-context/figure-plan 将计划中的图表合并到 figure-registry.yaml，或将该片段保留为起草检查清单。
6. 根据下方的章节映射，按章节起草。
7. 对于第 4 章，请在起草数据库／数据对象相关章节之前，构建数据库设计资源集： scripts/build_chapter4_database_assets.py <database-model.yaml> --out paper-context/database-design 如果不存在业务数据库，但项目包含真实的结构化配置／数据资源，例如 YAML、JSON、JSONL、Markdown 注册表、日志或生成的证据文件，请基于这些资源创建清晰标注的数据对象模型，并生成相同的总览 E-R 图、单实体 E-R 图和三线表资源。不要将其称为物理业务数据库。
8. 仅在章节需要时，生成必需的 Visio 图、截图占位符和三线表。 生成最终 .docx 时，如果可用 OfficeCLI 或 Word 自动化，请将结构化 .vsdx 图作为 Visio OLE 对象嵌入；.png 导出图仅用作预览缩略图。嵌入前请检查导出预览图的宽高比，并采用适配宽高比的 OLE 尺寸，而不要使用通用的固定矩形尺寸。
9. 运行最终检查： scripts/check_thesis_workspace.py <workspace> 如果生成了最终 .docx，还需运行 scripts/check_final_thesis_docx.ps1 <paper.docx> -FigureMap <visio-ole-figure-map.json> -ExpectedVisioOle <count> -MinContentUnits 12000 -MinCjkChars 10000 -RequireContinuationCaption。如果存在模板配置文件，请添加 -TemplateProfile <template-profile.json>。如果此综合检查未通过，不要将文档标记为已完成。

规划或执行完整流程时，请阅读 references/thesis-module-workflow.md。

技能完整性

编辑此技能后，在声明技能已就绪之前，请运行 scripts/check_skill_integrity.py。该脚本会检查 frontmatter、所引用的 scripts/ 和 references/ 文件、综合检查门控配置，以及变体工作流的可达性。

变体生成

当用户要求提供多个论文候选版本或希望比较优化策略时，请使用 references/variant-generation-workflow.md。

默认生成三个相互隔离的变体：

1. 模板优先：优先复现学校模板，并设置模板复现检查门槛。
2. 图示增强：优先规划第 3—6 章的图示、Visio 源文件、OLE 嵌入和图示映射检查门槛。
3. 叙述增强：优先打磨论文语气、章节连贯性和论文篇幅质量。

使用 scripts/generate_thesis_variants.py 创建变体矩阵和可选的隔离运行，然后使用 scripts/compare_thesis_variants.py 生成对比摘要。无论是获胜版本还是合并后的最终 .docx，都需要重新运行 scripts/check_final_thesis_docx.ps1；合并或编辑后，变体的检查证据不可沿用。

章节规划

• 第 1 章，绪论：背景、意义、研究现状、研究内容、论文结构。本章引用较多。
• 第 2 章，相关技术：说明各项技术及其在本系统中的应用。本章引用较多。
• 第 3 章，系统分析：可行性、角色、需求、非功能需求、用例图、核心业务流程图，以及有证据支持时的需求／功能分解图。
• 第 4 章，系统设计：功能架构图、总体架构图、有依据时的技术／部署架构图、E-R 总览图、单实体 E-R 图、数据库／数据对象三线表，以及设计依据。
• 第 5 章，系统实现：关键模块实现、实现流程图、登录／入口、主页和核心功能的真实程序截图；缺少真实截图时使用 needs_user_screenshot 占位符。本章不是测试章节。
• 第 6 章，系统测试：测试环境、测试方法、测试用例、日志／报告、存在真实证据时的测试结果截图，以及结果表格。不要在此放置常规程序功能截图。默认不要创建独立的第 7 章；需要结论内容时，在第 6 章末尾添加简洁的已完成工作、局限性和未来工作部分。仅当学校模板或用户明确要求时，才创建独立的第 7 章。

第 1—3 章是主要引用部分。除非某项论述确实需要文献支持，否则不要强行在实现或测试论述中加入引用。 起草或扩充论文正文之前，请先阅读 references/thesis-voice-and-style.md。证据文件用于辅助记忆和核验；论文正文必须直接描述系统。

图表路由

• 插图/截图规划：references/figure-and-screenshot-plan.md 起草第 3–6 章前，运行 build_figure_plan.py。常规系统论文应规划许多有证据支撑的插图，而不只是一个用例图和一个功能图。
• 提供带可编辑 Visio 的 Word 文档：阅读 references/docx-production-rules.md 对于生成的结构化 .vsdx 插图，运行 scripts/check_figure_preview_aspects.py，然后优先使用 scripts/embed_visio_ole_with_officecli.py --fit-preview-aspect --max-width 14cm --max-height 18cm，并使用 scripts/check_docx_visio_ole.py 和 scripts/check_docx_duplicate_figure_previews.py 检查最终的 .docx。Word 中的 PNG 预览不是可编辑的 Visio 图表，最终 Word 插图块不得同时包含 Visio OLE 对象和旧的静态 PNG 预览。
• 模板复刻：阅读 references/template-replication-workflow.md 存在学校/模板 .docx 时，不要只依赖视觉相似度。提取 template-profile.json，构建 thesis-structure-plan.yaml，并使用 scripts/check_docx_component_order.py、scripts/check_docx_style_profile.py、scripts/check_docx_page_model.py、scripts/check_docx_caption_numbering.py 和 scripts/report_template_replication_diff.py 验证最终输出。
• DOCX 硬性检查门槛：阅读 references/hard-gate-rule-catalog.md 最终论文 .docx 应通过组件完整性、引文闭环、参考文献超链接、题注闭环和结构规范检查。-SkipHardGateChecks 仅用于粗略的内部草稿，切勿用于交付声明。
• 用例图：references/visio-use-case-workflow.md 运行 layout_use_case_diagram.py、check_use_case_layout.py、generate_visio_use_case_diagram.ps1。
• 功能架构图：references/visio-function-architecture-workflow.md 运行 layout_function_architecture_diagram.py、check_function_architecture_layout.py、generate_visio_function_architecture_diagram.ps1。
• E-R 图：references/visio-diagram-workflow.md 运行 layout_er_diagram.py、check_er_layout.py、generate_visio_er_diagram.ps1。
• 第 4 章数据库资源：references/chapter-4-database-workflow.md 运行 build_chapter4_database_assets.py，然后使用 E-R Visio 流程渲染总览图和单实体 E-R JSON。
• 流程图：references/visio-flowchart-workflow.md 运行 layout_flowchart_diagram.py、check_flowchart_layout.py、generate_visio_flowchart_diagram.ps1。
• 三线表和跨页续表：阅读 references/docx-production-rules.md，然后使用 scripts/create_three_line_table.py。 Word 的 Table Grid 表格不是三线表。对于最终 DOCX 输出，运行 scripts/check_docx_table_continuations.ps1；如果表格跨页，则必须设置重复标题行、禁用行拆分，并在学校/模板或用户要求时显示续表题注。

保留可编辑源文件：Visio 插图使用 .vsdx，最终表格使用脚本/Word 源文件。 交付 Word 文档时，插入正文的 PNG 仅为预览图。除非 .docx 包含 Visio OLE 对象，且已通过 scripts/check_docx_visio_ole.py 验证，否则不得称插图为“可在 Word 中编辑的 Visio 图”。

硬性规则

• 学校和导师的规定优先于默认规则。
• 绝不虚构项目功能、API、数据库字段、测试、截图、实验、引文、DOI 值或学校规定。
• 如果缺少证据，应列出缺失材料，而不是假装材料齐全。
• 不要默默跳过第 4 章数据库/数据对象设计。如果存在架构/实体/迁移/SQL 证据，则生成概览 E-R 图、单实体 E-R 图和数据库三线表。如果没有业务数据库证据，但项目存在真实的结构化配置或证据材料，则根据这些材料生成明确标注的数据对象 E-R 模型和三线表。如果两者都不存在，应在起草第 4 章之前指出证据缺口。
• 默认不要将实现内容合并到第 4 章。对于普通系统类论文，第 4 章为设计，第 5 章为实现，第 6 章为测试。除非学校模板或用户明确要求单独设立结论章，否则不要创建第 7 章。
• 普通系统类论文的图表规划不应过少。如果第 3 至第 6 章计划的图少于 8 幅，应说明项目范围较小或证据缺失。
• 绝不伪造第 5 章程序截图。第 5 章是实现章节，应包含已实现功能的真实运行程序截图。如果应用无法运行或未提供截图，应在 figure-registry.yaml 中创建 needs_user_screenshot 条目，并将其列为证据缺口。
• 三线表仅指包含顶线、表头底线和底线的表格。不得包含竖线或内部网格线，也不得使用 Word 的 Table Grid 样式。生成 .docx 后，使用 scripts/check_docx_three_line_tables.py 验证最终 DOCX 表格。
• 三线表验证必须能检测表级边框和继承的 insideH / insideV 单元格边框，而不只是明显的左右网格线。
• 不得将跨页表格交由 Word 默认处理。应将表头行设为重复行，禁止行跨页拆分；需要续表标题时，应添加可见的 续表 x.x / 表 x.x（续） 标题。使用 scripts/check_docx_table_continuations.ps1 验证；不要只依赖目视检查。
• 最终论文 .docx 必须通过总检门槛 scripts/check_final_thesis_docx.ps1。该检查包括三线表边框、续表分页、标题级别、论文语体、Visio OLE 嵌入、重复预览检测、图形纵横比检查、文档组件/顺序检查、引文闭合检查、参考文献超链接检查、题注闭合检查以及 DOCX 结构完整性检查。如果总检门槛未通过，应修正文档或报告阻塞情况。
• 正文中的参考文献标记（如 [1]）必须是 Word 内部超链接，按住 Ctrl 并单击时能跳转到对应参考文献条目的书签，而不能只是纯文本。对于生成或修复的 DOCX 文件，运行 scripts/apply_docx_reference_hyperlinks.py <paper.docx>，并使用 scripts/check_docx_reference_hyperlinks.py <paper.docx> 验证。仅凭引文文本闭合，不能声称参考文献处理已完成。
• 嵌入正文的引文标记（例如 相关研究[1]表明）仍需修复超链接和上标；不能因为参考文献中存在相应编号，就将纯文本标记视为合格。
• 提供模板配置时，总检门槛还必须运行模板样式、页面模型和复刻差异检查。不能仅凭目视检查声称已复刻模板。
• 如果学校没有规定其他目标，普通本科系统设计类论文的中文内容量应约为 12000 单位。使用 scripts/check_docx_thesis_quality.py 或总检门槛选项 -MinContentUnits 12000 -MinCjkChars 10000 验证；不要将 4000 词的演示稿当作达到论文篇幅要求的成稿交付。
• 论文最终正文应具有学生论文的风格，而不是审计报告或助手工作日志。将源证据保留在工作区文件和报告中，但不要在论文正文中使用 证据、当前材料、根据源码、README、PRD、不编造、占位 或 待补 等措辞。使用 scripts/check_docx_thesis_voice.py 或总检门槛验证。
• 如果最终 .docx 在成功通过总检后又发生更改，则总检证据已失效。在声称完成前，必须重新运行 scripts/check_final_thesis_docx.ps1。
• 交付最终 .docx 时，除非无法进行 OLE 嵌入且已明确报告，否则不得仅将结构性 Visio 图表作为静态 PNG 提供。优先运行 scripts/embed_visio_ole_with_officecli.py --fit-preview-aspect，然后使用 scripts/check_docx_visio_ole.py 和 scripts/check_docx_duplicate_figure_previews.py 验证。
• 仅有 Visio o:OLEObject 标签并不足够。check_docx_visio_ole.py 还必须检测到 word/embeddings/ 下的非外部关系目标；缺少嵌入文件将阻止交付。
• 不要强制所有 Visio OLE 对象使用同一固定显示尺寸，例如 14cm x 8cm。应保留预览图的纵横比。如果 scripts/check_figure_preview_aspects.py 报告图形过于扁平或过于细长，应在最终交付前重新布局或拆分源图。
• 对于生成的流程图 .vsdx 图形，不要只依赖 Visio 自动布线。运行 layout_flowchart_diagram.py，为每条边设置正交路径点；然后运行 check_flowchart_layout.py，并要求 connectorCrossings: 0，之后再渲染或嵌入图形。
• 对于生成的 E-R .vsdx 图形，在运行 layout_er_diagram.py 后，应运行 check_er_layout.py，并要求 overlapPairs: 0 且 connectorCrossings: 0。如果概览 E-R 图过于拥挤，概览图中仅放置实体和关系，将属性移至单实体 E-R 图和三线表。
• 单实体 E-R 图应使用分散的边界连接点，而不是共用一个中心点。优先使用架构注释中的简短中文字段标签，并去掉括号中的实现说明，例如枚举值或加密细节。
• 每幅图、每张表、每个公式和每张截图都必须在 figure-registry.yaml 中记录源文件、适用时的导出文件、首次提及位置和状态。
• 不要在论文正文中暴露 AI 工作流相关措辞。
• 对于稳定的最终 .docx 文件，除非用户接受版式风险，否则应避免对整个文档进行 Markdown 往返转换。Markdown 到 Word/Pandoc 的输出仍须通过 check_docx_three_line_tables.py、check_docx_visio_ole.py、Office/OpenXML 验证和图形纵横比检查，之后才能视为可交付成果。

最少阅读内容

当 thesis-ai-standard/ 存在时，先阅读以下文件，除非需要更多详细信息，否则停止：

1. thesis-ai-standard/templates/standard-profile.yaml
2. thesis-ai-standard/templates/thesis-ai-spec.yaml
3. thesis-ai-standard/templates/figure-registry.yaml
4. paper-context/evidence/，如果存在
5. paper-context/template-extract/template-rule-overrides.yaml，如果存在
6. paper-context/template-extract/template-profile.json，如果存在
7. paper-context/template-extract/thesis-structure-plan.yaml，如果存在
8. paper-context/database-design/，如果存在
9. paper-context/figure-plan/，如果存在

仅在当前任务需要时，才查阅更深入的参考文件。