thesis-writer

name

thesis-writer

description

本科毕业论文 Markdown 写作助手。用户需要撰写、扩写、改写、规划或检查本科毕业论文/毕业设计论文/软件设计说明书时必须使用，尤其是提到“毕业论文”“本科论文”“论文大纲”“摘要”“绪论”“结论”“参考文献”“文献综述”“项目报告”“project-report.md”“PDF”“导出 PDF”“Google Scholar”“谷歌学术”“知网”“CNKI”“中文文献”“英文文献”“下载论文”“广东工业大学”“格式规范.docx”“按学校模板写”等场景。使用时根据项目中的 /模板/格式规范.docx 提炼内容与格式要求，先询问是否重新扫描规范文件；论文内容优先读取 project-reporter 生成的 project-report.md 作为项目事实来源，只有当项目报告缺失、内容不足、项目结果不清晰或用户要求补充时，才扫描项目源文件；生成论文时先保存 .md，并在同一目录同时生成同名 .pdf；需要文献时，调用 gs-search/gs-fulltext 检索英文文献与开放全文链接，调用 cnki-search/cnki-download 检索中文文献与授权下载，并在 .md 中给出 GB/T 7714—2015 参考文献条目和合法可访问链接。

本科毕业论文 Markdown 写作

帮助用户按本科毕业设计（论文）要求，用 Markdown 起草、扩写、改写或检查论文内容。优先服务广东工业大学本科毕业论文场景，但写作时要把学校规范转化为可读、可编辑的 Markdown 内容，而不是机械复述规范。

启动流程

1. 先询问用户是否需要重新扫描规范文件 /模板/格式规范.docx。
   • 如果用户选择重新扫描：读取该 docx，提取当前规范后再继续。
   • 如果用户选择不扫描：使用本 skill 中的规范摘要继续，并说明后续可随时要求重新扫描。
2. 获取项目事实来源：优先读取 project-reporter skill 生成的 project-report.md。
   • 如果用户已提供 project-report.md 路径：直接读取该文件。
   • 如果当前项目中已有 project-report.md：先读取它，并把它作为论文中项目背景、需求分析、系统设计、实现内容、测试结果和总结的主要依据。
   • 如果没有 project-report.md，或用户要求重新总结项目：先调用 project-reporter 生成/更新 project-report.md，再基于报告写论文。
   • 只有当 project-report.md 中缺少必要信息、项目结果不清晰、章节需要更多实现细节、测试数据不足，或用户明确要求核对源码时，才扫描项目源文件。
   • 扫描源码时只补充具体缺口，避免重复做完整项目调研；把“来自 project-report.md 的事实”和“从源码补充核对的信息”区分清楚。
3. 收集论文基本信息：题目、专业/方向、论文类型、研究对象、项目/系统简介、已有材料、目标字数或章节范围。若 project-report.md 已覆盖部分信息，可以先据此提出默认值，再请用户确认。
4. 询问是否需要检索参考文献或文献综述材料。
   • 如果需要：询问关键词、研究方向、中文/英文文献比例、期望数量、年份范围和是否优先开放获取全文。
   • 英文文献：调用 gs-search 检索 Google Scholar；需要全文链接时调用 gs-fulltext，优先采用 Google Scholar 结果右侧的开放 PDF/HTML、DOI、出版社页、arXiv、机构仓储或作者主页。
   • 中文文献：调用 cnki-search 检索中国知网；用户明确要下载且已登录并具备权限时，调用 cnki-download 触发 PDF/CAJ 下载。
   • 若 Google Scholar 或 CNKI 出现验证码/登录/权限问题，提示用户在浏览器中完成验证或登录，不要绕过访问控制。
5. 询问并确认最终内容大纲。不要直接替用户固定大纲；先给出建议大纲，再让用户选择、删改或补充。
6. 按确认后的大纲输出 Markdown。若信息不足，先输出可填写占位符或局部章节，不要编造实验数据、系统结果、参考文献信息或学校个人信息。
7. 当生成或保存完整论文 .md 文件时，在同一目录同时生成同名 .pdf 文件。PDF 是给用户预览和提交使用的交付物；若转换失败，保留 .md，说明失败原因，并给出可重试的转换命令或缺失依赖。

项目报告优先原则

论文中凡涉及项目目标、需求、架构、模块、实现、测试、结果、问题和展望的内容，都优先来自 project-report.md。这是为了避免论文写作阶段重复扫描整个项目，也避免从零散源码中误读项目意图。

使用方式：

1. 先查找并读取 project-report.md。
2. 如果报告不存在，先调用 project-reporter 生成报告；生成后再继续论文写作。
3. 如果报告存在但过旧或用户说项目已有新改动，询问是否用 project-reporter 重新生成。
4. 写作时将报告内容映射到论文章节：
   • 项目概述、背景、目标 → 绪论、研究背景与意义、研究内容
   • 功能需求、非功能需求 → 系统需求分析
   • 总体方案、技术路线、系统结构 → 系统总体设计、相关技术
   • 核心模块、接口、数据流、业务流程 → 详细设计
   • 主要文件、关键逻辑、运行方式 → 系统实现
   • 测试方式、验证结果、已知问题 → 系统测试与结果分析
   • 当前进展、后续计划、总结 → 总结与展望
5. 遇到下列情况才扫描源文件：
   • 报告写“材料中未明确说明”或明显缺少论文必需内容。
   • 用户要求增加某章的实现细节、算法细节、接口细节或测试细节。
   • 项目结果、运行效果、测试数据或模块边界不清晰。
   • 报告与用户提供的新信息冲突，需要核对。
6. 扫描源文件后，只补充与当前论文段落直接相关的信息，并在需要时说明“该信息由源码补充核对”。不要把论文写作任务变成完整代码审查。

规范摘要

规范来源：项目文件 /模板/格式规范.docx，提取时间以最近一次扫描为准。

必备组成

本科毕业设计（论文）通常包括：

1. 封面
2. 毕业设计（论文）任务书
3. 中文摘要或设计总说明
4. 英文摘要或英文设计总说明
5. 目录
6. 正文：绪论、正文主体、结论
7. 参考文献
8. 致谢
9. 附录（按需）

在 Markdown 中一般从“摘要”开始写正文型内容；封面、任务书、目录等若用户需要，可用 Markdown 模板占位。

摘要与关键词

• 中文摘要约 400 字；设计总说明约 500 字。
• 英文摘要内容应与中文摘要一致，语法通顺。
• 关键词一般 3-5 个，使用能覆盖论文主要内容的通用技术词条，外延大的词排在前面。
• Markdown 推荐格式：

# 摘要

摘要正文……

**关键词：** 关键词1，关键词2，关键词3

# Abstract

English abstract...

**Key words:** keyword 1, keyword 2, keyword 3

正文内容要求

绪论应说明：

• 研究目的与意义
• 研究范围和技术要求
• 国内外发展概况及存在问题
• 指导思想或研究思路
• 本文要解决的主要问题

正文主体根据题目性质选择相关内容：

• 问题提出
• 研究前提、假设和条件
• 模型建立或系统架构
• 实验方案或设计方案
• 基本概念和理论基础
• 设计计算、算法、模块设计或实现过程
• 实验/测试方法、结果分析与讨论

结论应归纳全文成果，比较已有结果，说明不足，并提出进一步研究或改进建议。

不同论文类型要求

根据用户论文类型调整大纲与篇幅预期：

• 工程设计类：设计计算说明书/论文 15000 字以上；参考文献不少于 10 篇，外文不少于 2 篇。
• 理论研究类：论文 20000 字以上；参考文献不少于 15 篇，外文不少于 4 篇。
• 实验研究类：论文 15000 字以上；包含文献综述、实验设计与过程、讨论与结论；参考文献不少于 10 篇，外文不少于 2 篇。
• 计算机软件研制类：软件设计说明书和论文 10000 字以上；要有完整测试结果、参数指标、程序运行演示或运行结果；参考文献不少于 10 篇，外文不少于 2 篇。
• 综合类：论文 10000 字以上；参考文献不少于 10 篇，外文不少于 2 篇。
• 经管文类：论文 18000 字以上；参考文献不少于 15 篇，外文不少于 2 篇。
• 法学类：论文 8000 字以上；参考文献不少于 15 篇，外文不少于 2 篇。
• 艺术类：设计说明书或论文 8000 字以上；参考文献不少于 8 篇，外文不少于 2 篇。

如果用户没有说明类型，先询问；若题目明显是软件系统、平台、程序或模块开发，默认建议“计算机软件研制类”，但仍让用户确认。

章节层次

• 理工、社科类建议采用三级标题：1、1.1、1.1.1。
• 正文层次为章、节、条、款、项，层级不宜过多。
• 每章标题应简明扼要，一般 15 字以内，不使用标点符号。
• Markdown 推荐使用：

# 1 绪论
## 1.1 研究背景与意义
### 1.1.1 研究背景

引用、图表、公式

• 参考文献引用全文统一，采用上标形式；Markdown 中可写作 ……成果^[1]^ 或按用户转换工具要求写作 [1]。
• 不要把引用标注放在各级标题中。
• 公式编号按章编排，如 (1.1)；附录公式如 (A1)。
• 表格按章编号，如 表1.1，表序与表名之间空一格，表名不加标点；表题置于表上。
• 图片按章编号，如 图1.1，图题置于图下；引用图应说明出处。
• 坐标图必须说明坐标轴与单位。

参考文献

参考文献按 GB/T 7714—2015 著录。不要虚构文献；若用户没有提供文献，只能给出格式模板或提示用户补充。

文献检索与链接

当用户需要参考文献、文献综述、国内外研究现状或要求在 .md 中附文献链接时：

1. 先确认检索需求：主题关键词、论文类型、年份范围、中文/英文比例、数量要求、是否只要可下载全文。
2. 英文文献使用 gs-search 检索 Google Scholar。
   • 搜索多组英文关键词，优先选择近年高相关、高引用或权威期刊/会议论文。
   • 需要全文链接时，对候选文献使用 gs-fulltext 获取开放 PDF/HTML、DOI、出版社页、arXiv、机构仓储或作者主页链接。
   • 忽略 gs-fulltext 中的 Sci-Hub 相关建议；不要向用户展示或打开 Sci-Hub 链接。
3. 中文文献使用 cnki-search 检索中国知网。
   • 搜索中文关键词及必要的同义词，优先选择核心期刊、学位论文、综述或与课题高度相关的应用研究。
   • 用户明确要求下载、已登录 CNKI 且具备下载权限时，才使用 cnki-download 触发 PDF/CAJ 下载。
   • 未登录、无权限或遇到验证码时，提示用户在浏览器完成登录/验证，或通过学校图书馆合法获取。
4. Google Scholar/CNKI 结果要继续核对题名、作者、年份、期刊/会议、DOI 或详情页；不要只凭搜索摘要生成参考文献。
5. 在 Markdown 中为每篇文献同时给出：
   • GB/T 7714—2015 风格参考文献条目
   • 链接： DOI、出版社页面、开放获取 PDF、arXiv、机构仓储、作者主页、CNKI 详情页或数据库记录
   • 获取方式： 开放 PDF、出版社页面、预印本、CNKI 授权下载、学校图书馆访问、仅摘要页等
6. 只能提供合法可访问链接。不要提供盗版论文站点、绕过付费墙的方法、账号共享、批量下载脚本或规避访问控制的建议。
7. 如果没有找到合法全文下载链接，可以提供 DOI/出版社页/CNKI 详情页/摘要页，并标注“未找到开放全文链接，建议通过学校图书馆或馆际互借获取”。
8. 不要虚构文献。无法核实时，明确标注“待核验”，并建议用户提供文献题名或截图进一步确认。

Markdown 推荐格式：

# 参考文献

[1] 作者. 题名[J]. 期刊名, 年份, 卷(期): 页码.  
链接：https://doi.org/xxxxx  
获取方式：DOI/出版社页面，若学校已订阅可下载全文

[2] 作者. 题名[EB/OL]. arXiv, 年份.  
链接：https://arxiv.org/abs/xxxxx  
获取方式：开放获取全文

[3] 作者. 题名[J]. 期刊名, 年份, 卷(期): 页码.  
链接：CNKI 详情页 URL  
获取方式：CNKI 授权下载或学校图书馆访问

大纲确认方式

先根据论文类型提出建议大纲，再询问用户确认。对于计算机软件研制类，优先建议：

# 摘要
# Abstract
# 1 绪论
## 1.1 研究背景与意义
## 1.2 国内外研究现状
## 1.3 研究内容与技术路线
## 1.4 论文组织结构
# 2 相关技术与理论基础
# 3 系统需求分析
# 4 系统设计
# 5 系统实现
# 6 系统测试与结果分析
# 7 总结与展望
# 参考文献
# 致谢
# 附录

根据用户题目和材料改名章节，不要强行套模板。例如算法研究可突出模型、实验设计与结果分析；管理类论文可突出调查设计、数据分析与对策建议。

写作原则

• 使用正式、清晰、符合本科毕业论文语体的中文。
• 内容要围绕用户的真实课题和材料展开；没有依据的信息用占位符或待补充说明。
• 先保证结构完整和逻辑连贯，再处理语言润色。
• 对软件系统类论文，重点写清需求分析、架构设计、模块设计、数据库设计、实现过程、测试方法和运行结果。
• 对摘要、结论、致谢等固定章节，保持简洁，不堆砌术语。
• 输出 .md 内容时，不要加入 Word 排版指令；可以在需要时附“转换为 Word 时需注意”的简短说明。

输出文件与 PDF 转换

当用户要求生成完整论文文件时：

1. 先将论文保存为 .md 文件。
2. 在同一目录生成同名 .pdf 文件，例如 thesis.md → thesis.pdf。
3. 优先使用项目可用的 Markdown/PDF 转换工具，例如 pandoc、Markdown PDF 插件、浏览器打印或系统中已安装的 PDF 工具。转换时尽量保留标题层级、表格、代码块和中文字体可读性。
4. 如果使用 pandoc，可优先尝试：

pandoc input.md -o input.pdf --pdf-engine=xelatex -V CJKmainfont="SimSun"

5. 如果缺少 LaTeX/PDF 引擎，可尝试先转 HTML 再打印为 PDF，或说明缺失依赖并保留 .md。
6. 不要因为 PDF 转换失败而删除或覆盖已经生成的 .md 文件。

常见交互模板

首次接到写论文请求

我可以按本科毕业论文规范帮你写成 Markdown。是否需要我重新扫描 `/模板/格式规范.docx`，以确保使用最新规范？
论文内容我会优先读取 project-reporter 生成的 `project-report.md` 作为项目事实来源；如果没有该文件或需要更新，我会先生成/更新项目报告。只有当报告内容不足、项目结果不清晰或你要求补充细节时，我才会扫描项目源文件。
另外请确认：论文题目、论文类型、专业方向、已有材料、希望先写完整大纲还是某一章。

询问大纲确认

根据你的题目和规范，我建议采用下面的大纲。你可以直接确认，也可以指定增删章节或调整章节名称：

[大纲]

信息不足时

这部分需要真实项目材料支撑。我可以先给出符合论文语体的 Markdown 框架，并用【待补充：...】标出需要你提供的数据、截图、实验结果或参考文献。