discussion-report-synthesizer

讨论报告综合器

将零散的学术对话整理成一份连贯易读的文档，让未参与讨论的人也能理解并使用。

适用场景

• 用户在一次会话中通过多轮问答探讨了某个主题，现在想要一份综合性的文稿。
• 对话涵盖了多个相关子主题，但尚未将它们串联起来。
• 用户要求“梳理”“报告”“记录”或“总结”讨论内容。
• 输出是一份独立的 Markdown 文件，而不是论文的一部分或文献综述。

不适用场景

• 用户想撰写研究论文的某个部分——改用 method-section-writer、abstract-and-intro-writer 或 results-writeup。
• 用户想要有依据的文献综述——改用 literature-triangulation 或 related-work-writer。
• 对话涉及实验日志或运行结果——改用 results-writeup 或 experiment-design。
• 对话只有一个问题和一个回答——简短直接地回复比撰写完整报告更合适。

工作流

步骤 1：提取对话中的所有不同观点

阅读完整对话，并以不分类的清单列出其中出现的每一个独立观点、问题、主张、定义、示例和子主题。暂不归类或综合。标记任何带有不确定性或尚未解决的内容。

哪些内容算作独立观点：

• 用户要求解释的定义或说明
• 对概念进行的比较或对照
• 提出的主张（由用户或助手提出）
• 引入的示例或类比
• 提出但未得到完整回答的问题
• 引向有用方向的旁支话题

步骤 2：归纳主题并确定统一主题

将清单归纳为 3–6 个连贯主题，并为每个主题拟定一个简短的描述性标题。然后确定总主题：用一句话说明整个对话讨论的内容。

如果无法明确归类，则按以下结构组织：（1）基础知识／定义；（2）机制／工作原理；（3）应用／影响；（4）开放问题。

步骤 3：找出空缺

起草前，找出以下内容：

• 未解决的问题——对话中提出但尚未解决的问题
• 缺失的背景信息——暗示了但从未明确说明的内容（范围、受众、领域、动机）
• 讨论不足的内容——简要提及、但报告中可能值得深入探讨的主题
• 矛盾或张力——对话中出现的、彼此不完全一致的观点

步骤 4：提出澄清问题

提出 2–4 个有针对性的问题，以解决最重要的空缺。等待用户回答后再起草。

可以询问：

• 报告的目标读者是谁（专家、学生、普通读者、未来的自己）
• 是否应扩展或删去某个主题
• 哪些缺失的背景信息会影响某一部分的表述方式（例如，暗示了但未明确说明的具体领域、应用或限制）
• 用户希望强调的哪些关键观点在对话中可能没有得到足够重视

不要询问：

• “要我写这份报告吗？”——用户已经提出要求，直接撰写即可
• 模糊的偏好问题（“希望写多长？”）——根据内容确定合适的篇幅
• 可以根据对话合理推断答案的问题

提问格式： 将需要澄清的问题以简短的编号列表呈现，而不是开放式提问。让用户可以轻松回答或跳过。

示例：

起草前，我想确认几件事：

1. 目标读者是谁——已经熟悉［主题］的人，还是初学者？
2. 讨论简要提到了［X］——需要扩展，还是将其作为旁注？
3. 是否有特定背景（例如［领域］）作为讨论框架，还是让报告保持通用？

第 5 步：起草报告

获得答案（或采用合理的默认值）后，按照以下输出格式撰写报告。只使用实际讨论过的内容，不要添加对话中未出现的主张、示例或引文。如果存在不确定或有争议之处，请明确指出。

输出格式

# [Topic Title]

## Overview
[2–4 sentences: what this conversation explored, why it matters, and what the report covers]

## [Theme 1 Title]
[Synthesized prose covering the ideas from this theme. Each paragraph should make one clear point. Use inline emphasis for key terms the first time they appear.]

## [Theme 2 Title]
...

## [Theme N Title]
...

## Open Questions
[Bulleted list of questions raised but not resolved. Phrase each as a genuine question, not a hedge.]

## Key Takeaways
[3–5 bullet points: the most important, transferable insights from the discussion]

格式规则：

• 使用 H2（##）作为主题章节；除非某个主题确实包含明显不同的子部分，否则避免使用 H3。
• 概述部分应以事实为主，不作评价——描述讨论了什么，而不是讨论得好不好。
• 关键要点仅限于对话实际得出的结论，不要写成期望实现的结论。
• 如果对话中包含完整示例或比较，请在相关章节中保留，不要将其抽象化。

澄清问题指南

澄清问题的目的是弥补信息缺口，以免你不得不编造内容，或作出无法推断的重要框架选择。好的问题应当：

• 具体：“第 2 节应涵盖 X，还是留待后续工作？”而不是“我应该写些什么？”
• 一句话即可回答：不要提出需要用户思考十分钟的问题。
• 影响重大：如果答案不会改变草稿，就不要问。

如果用户没有回答澄清问题，或说“直接写吧”，请采用合理的默认设置：面向普通读者，均衡涵盖所有主题，报告篇幅与对话深度相称。

质量标准

一份好的报告应让一位未参与原始对话的人能够：

1. 理解探讨了什么主题，以及它为何重要
2. 无需阅读原始对话，也能理解每个主题
3. 知道还有哪些问题尚未解决，以及原因
4. 最终记住 3–5 条可操作或令人印象深刻的见解

如果某个章节必须结合原始对话才能理解，那么该章节就需要补充更多背景信息，或应予以删去。

应避免的问题

• 照搬对话记录：不要以问答形式复述对话。应将内容综合成一份文档，而不是聊天记录。
• 过度含糊：“对话似乎表明 X 或许可能成立”——如果对话说的是 X，就直接写 X；如果只是暂定结论，只需说一次“暂定”。
• 凭空编造内容：不要添加对话中未出现的事实、引文或示例，即使这些内容准确无误。明确标注任何推断（“这意味着……”或“一个自然的延伸是……”）。
• 结构平铺直叙：不要让每个章节都只是要点列表。应尽量综合成段落，并保持逻辑清晰。
• 遗漏未决问题：未解决的问题往往最有价值。不要将其埋没或略过。