thesis-outline-planner

star 20

用于规划证据驱动的中文工程类毕业论文大纲。用户要求出大纲/列提纲/规划论文结构、 把任务书转成章节、design brief/research proposal/导师要求/论文题目转成章节规划、 建立文献池、literature-backed workflow、任务到章节映射、图表计划、Zotero-first 文献池 或 staged approval process 时使用。应在章节写作前运行。

little3tar By little3tar schedule Updated 6/8/2026

name: thesis-outline-planner description: >- 用于规划证据驱动的中文工程类毕业论文大纲。用户要求出大纲/列提纲/规划论文结构、 把任务书转成章节、design brief/research proposal/导师要求/论文题目转成章节规划、 建立文献池、literature-backed workflow、任务到章节映射、图表计划、Zotero-first 文献池 或 staged approval process 时使用。应在章节写作前运行。

Thesis Outline Planner

Red Flags(停止并检查)

AI的想法 正确做法
"任务书很详细,直接出大纲" 先检查是否缺研究对象边界、交付物列表、参考系统
"工程论文标准章节就是这几章" 按任务书实际要求映射,不强加固定章型
"文献池 30 篇够了,标准不用查" 标准规范是独立来源类型,需单独检索核验
"文献数量不够我凑几篇" 不编造文献凑数,缺口如实报告,给出检索方向
"章节类型固定,套模板就行" 按证据类型判断每章公式需求(无需/可选/建议/必须),不强加章型
"Zotero 题名太长,缩写一下方便读" Zotero 题名必须原样转录,不缩写、不翻译、不改写
"Web 搜到的文献,题名差不多就行" Web 来源也需原样记录检索到的题名,不确定时标注 [题名待核验]

将任务书、设计说明或导师要求转化为可审阅、可追踪证据来源的论文计划。作为 thesis workflow 第一步,在章节撰写前运行。

前置交互:当任务边界不明确时

当用户没有提供明确的任务书、设计说明或题目时,先通过对话确认以下信息,再进入正式大纲规划。如果用户已提供完整任务书,跳过本节。

交互原则

  • 一次只问一个问题,等待回答后再继续。
  • 根据已有信息给出推荐,让用户确认而非从零填写。
  • 工程类论文默认语言为中文。

确认流程

  1. 论文类型 → 本科/硕士/博士毕业论文?期刊/会议投稿?
  2. 学科方向 → 机械/土木/电气/计算机/化工/材料/…,影响证据类型和章节结构。
  3. 研究题目 → 暂定也可以,后续可调。
  4. 主要方法 → 仿真/实验/理论推导/设计计算/算法/数据分析,影响证据需求和公式计划。
  5. 设计边界确认(⭐ 关键步骤)→ 帮用户区分以下三类信息:
    • 完整定义和写作语气对照见 workflow §用户材料收录协议(user-material-protocol.md)。简要来说:A 类=产品公开规格(写作"XX 配备..."),B 类=用户设计选择(写作"本文选取..."),C 类=待推导验证(不可写成定论)。
    • 主动询问用户:"你提供的参数中,哪些是产品本身已有的公开规格(A 类),哪些是你自己分析后做的设计选择(B 类)?"给出初步分类建议让用户确认。
  6. 章节结构推荐 → 根据以上信息给出推荐结构,让用户确认或微调。
  7. 汇总确认 → 展示全部信息(含 A/B/C 分类结果),获得确认后进入正式大纲规划。

工作流程

  1. 收录用户材料

    • 检查用户消息中是否附带文件或资料。
    • 如已存在 .thesis-workflow/materials-inventory.md,读取全部已编目材料。
    • 如有新文件未编目,触发材料收录询问(见 thesis-writing-workflow 用户材料收录协议)。
    • 从材料中提取设计要求、已知参数、约束条件、导师意见。
    • 提取的信息作为后续规划的内部输入,不标记为正式引用。
  2. 解析任务来源

    • 提取研究对象、设计任务、交付物、方法、约束和具名参考系统,例如 JOY MC51。
    • 保留用户材料中的正式要求原文,不要擅自改写任务书措辞。
    • 如果是 validation 或 workflow dry-run 且没有真实任务书,创建明确标注的 synthetic task source,并说明它不是用户提供的论文证据。
    • 关键信息缺失时,只问最小必要确认问题。
  3. 确认输出格式

    • 文件产出规则遵循 workflow §输出与文件安全。本阶段产物为 .thesis-workflow/outline.md(总大纲,章→节→小节层级)、.thesis-workflow/literature-pool.md(文献池全表,按主题分组)和 .thesis-workflow/main-tex-context.md(项目上下文)。
    • 只有当交付格式影响工作时才问输出格式。如果用户要求 Word 文档,先以 .md.txt 完成并确认计划,再转换为 .docx
    • 创建项目上下文:确认输出格式后,读取 workflow 的 references/main-tex-context-template.md,将已确定的格式选择填入模板生成 .thesis-workflow/main-tex-context.md。当前无法确定的字段留空或标注”待确认”,后续阶段补充。
  4. 建立文献池

    • 遵循强制三级检索协议(见 workflow §来源策略):Zotero → 用户 → 网络,每项都要尝试,不得只查一项就停止。
    • 将行业标准、国家标准、规范、规程、验收要求和限值作为独立来源类型处理。此类来源不强求在 Zotero 中;按三级协议检索:Zotero → 询问用户 → 搜索官方标准平台、主管部门、标准发布机构、出版社页面或其他可靠来源。
    • 对已核验标准,规划其进入正文的位置和用途,例如设计依据、参数依据、验收依据、限值依据或安全裕量依据。
    • 文献数量按任务规模分层:真实完整论文计划 30-50 篇,单章 10+ 篇(小节 3+ 篇),workflow validation 或 minimal dry-run 2-5 篇。
    • 文献池分组原则:按研究主题/技术路线分组,不按论文章节分组,一篇文献可能支撑多章,不应在多组中重复出现。分组数量由实际研究主题数自然决定,不强定数字。标准规范和专利因元数据结构不同(缺作者/期刊,有标准号/专利号/发布机构),独立成组。每组内文献按相关度排列,每篇标注支撑章节(可并列多章)。分组由 outline-planner 初步确定后,写作和审计阶段可按需调整。
    • 记录每个来源的题名、作者/年份、来源类型、检索词和可支撑章节。
    • Zotero 笔记/标注参考:检索到文献后,通过 Zotero MCP 检查该文献是否有用户的笔记或标注。如有,主动询问用户:

      "检测到以下文献在 Zotero 中有笔记/标注:[文献题名列表]。是否允许我参考这些笔记内容,用于更准确地提取文献关键发现和支撑论点?"

      • 用户同意 → 读取笔记/标注,优先用标注中的核心结论替代从题名推测的内容
      • 用户不同意 → 仅使用题名、摘要等公开元数据
      • 这是一次性询问,同批文献只问一次
      • 笔记内容是用户个人理解,用作内部参考,不替代对文献原文的核实
    • 题名转录规则:从 Zotero 或 .bib 文件获取的文献,题名、作者、年份必须原样转录,保留特殊字符(希腊字母、上下标、变音符号)。英文题名保留原始大小写。Web 搜索获取的文献同样原样记录检索到的题名;不确定准确性时在题名后标注 [题名待核验] 并在 project ledger 中备注。
    • 保留校验基准:如通过 Zotero MCP 获取文献,将 Zotero 文献库导出为 .bib 文件放入 .thesis-workflow/evidence/zotero-export/ 目录,作为后续审计阶段的文献信息校验基准。
  5. 创建大纲

    • 输出完整章结构、节级内容和章节逻辑。
    • 把每条任务书要求映射到一个或多个章节。
    • 包含建议方法、仿真、计算、实验、算法、图表和附录。
    • 标注每章的证据类型:文献综述、设计推理、公式/计算、数据分析、实验/仿真、算法/建模或纯文档说明。
    • 标出需要用户后续补充的自有材料,例如图纸、结构尺寸、实验记录、仿真截图、设备选型依据、程序输出、现场照片或导师批注。
    • 不要在用户主题没有要求时强行塞入领域公式或固定章型。
    • [此处插入图片:...][此处插入表格:...] 放在大纲或草稿流程中第一次需要的位置;尾部图表清单只能汇总。
  6. 请求确认

    • 以明确确认问题收尾:“请确认是否按此总大纲进入第X章细纲设计;如需调整,请指出章节、研究重点或输出格式。”
    • 除非用户已经要求继续,否则不要直接进入完整章节写作。
    • 对多轮项目,若 .thesis-workflow/ 已存在或用户已进入论文工作流,主动创建或更新 .thesis-workflow/ledger/ 下相关文件(facts/decisions/chapter-status/questions)及 literature-pool.md,记录已确认事实、来源、公式和设计决策;只有保存位置或是否使用文件不明确时才询问。

证据规则

涉及文献检索、source marker 设计或来源 fallback 时读取 references/evidence-rules.md

规划阶段使用的 source marker 遵循 citation-key-rules.md(chapter-writer 参考文件)统一定义,此处不重述。缺失来源记录在 证据缺口清单 或 project ledger。

不要编造设备参数、性能结论、标准、实验结果或具名文献。看似合理但无来源的内容不进入正文;只在 证据缺口清单 中写明需要的证据类型、检索词、可能标准号或待核验版本。已核验标准可进入正文作为正式支撑;只有用户确认的设计假设可以进入正文,并必须标明为 design assumption。

参考文件

文件 用途
references/evidence-rules.md 文献检索、source marker 设计和来源 fallback
references/figures-guide.md 图表生成路径、流程图提示词模板和表格规范
见 workflow router 参考文件 user-material-protocol.md 用户材料收录协议(A/B/C 分类、编目、消化规则)
见 chapter-writer 参考文件 citation-key-rules.md Source marker 格式统一定义
见 chapter-writer 参考文件 figure-data-manifest-rules.md 图表数据溯源规则(Figure ID、数据文件、生成脚本、状态)

输出结构

outline.md 仅含以下四段。不写入文献池摘要、图表溯源、设计参数、决策、进度或证据缺口。

  1. 任务理解(精简版,≤10行。不列参数清单,参数见 ledger/facts.md
  2. 论文总章节规划(到小节标题层级。图表占位符内嵌在各节标题下,不单独成节。段落级细纲写入 chapters/chX/detailed-outline.md
  3. 任务书要求与章节对应关系
  4. 公式/数据/证据需求判断

项目上下文信息写入 main-tex-context.md(按 workflow 模板填充)。

以下产物直接写入各自专属文件,其内容不进入 outline.md:

  • 文献池全表 → literature-pool.md
  • 图表清单框架(Figure ID + 占位符名)→ figure-data-manifest.md(写作阶段逐图补充数据文件、来源说明和生成脚本,见 chapter-writer 参考文件 figure-data-manifest-rules.md §生命周期)
  • 设计参数 → ledger/facts.md
  • 设计决策 → ledger/decisions.md
  • 待确认问题 → ledger/questions.md
  • 章节进展 → ledger/chapter-status.md(运行时产物,非规划阶段写入)

outline.md 规划确认后内容冻结。仅用户主动要求调整章节结构时修改 §二。后续运行时信息(进度/事实/证据缺口)写入各自的 ledger/chapters/chX/ 文件,不回写 outline.md。

计划要具体到后续 agent 可以直接执行章节写作,而不需要重新解释题目。

Install via CLI
npx skills add https://github.com/little3tar/paper-anti-aigc --skill thesis-outline-planner
Repository Details
star Stars 20
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator