thesis-writer

# 本科毕业论文 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 推荐格式： ```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 推荐使用： ```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 推荐格式： ```markdown # 参考文献 [1] 作者. 题名[J]. 期刊名, 年份, 卷(期): 页码. 链接：https://doi.org/xxxxx 获取方式：DOI/出版社页面，若学校已订阅可下载全文 [2] 作者. 题名[EB/OL]. arXiv, 年份. 链接：https://arxiv.org/abs/xxxxx 获取方式：开放获取全文 [3] 作者. 题名[J]. 期刊名, 年份, 卷(期): 页码. 链接：CNKI 详情页 URL 获取方式：CNKI 授权下载或学校图书馆访问 ``` ## 大纲确认方式 先根据论文类型提出建议大纲，再询问用户确认。对于计算机软件研制类，优先建议： ```markdown # 摘要 # 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`，可优先尝试： ```bash pandoc input.md -o input.pdf --pdf-engine=xelatex -V CJKmainfont="SimSun" ``` 5. 如果缺少 LaTeX/PDF 引擎，可尝试先转 HTML 再打印为 PDF，或说明缺失依赖并保留 `.md`。 6. 不要因为 PDF 转换失败而删除或覆盖已经生成的 `.md` 文件。 ## 常见交互模板 ### 首次接到写论文请求 ```text 我可以按本科毕业论文规范帮你写成 Markdown。是否需要我重新扫描 `/模板/格式规范.docx`，以确保使用最新规范？ 论文内容我会优先读取 project-reporter 生成的 `project-report.md` 作为项目事实来源；如果没有该文件或需要更新，我会先生成/更新项目报告。只有当报告内容不足、项目结果不清晰或你要求补充细节时，我才会扫描项目源文件。 另外请确认：论文题目、论文类型、专业方向、已有材料、希望先写完整大纲还是某一章。 ``` ### 询问大纲确认 ```text 根据你的题目和规范，我建议采用下面的大纲。你可以直接确认，也可以指定增删章节或调整章节名称： [大纲] ``` ### 信息不足时 ```text 这部分需要真实项目材料支撑。我可以先给出符合论文语体的 Markdown 框架，并用【待补充：...】标出需要你提供的数据、截图、实验结果或参考文献。 ```