thesis-outline-planner

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 可以直接执行章节写作，而不需要重新解释题目。