fishinfo

# fishinfo ## 核心定义 `fishinfo` 不是“把会议做得好看”，而是把口语化会议还原成一张可以反复阅读、回忆、转发和继续行动的**会议理解地图**。 最终读者即使没有听过录音，也应当能够回答： 1. 这场会从什么事件开始，经过了哪些议题转折？ 2. 每个人带来了什么经历、判断、困惑和变化？ 3. 每个核心议题的主张、证据、反例和未解决部分是什么？ 4. 哪些话是原话，哪些是整理者的归纳？ 5. 这场会真正留下了什么方法、问题和下一步？ 如果信息图只剩“会议主题 + 三条总结 + 几句金句”，视为失败，即使视觉设计很漂亮也要返工。上一轮实践还证明：单纯增加卡片数量也不够；主题卡可能重复，而逐字稿中的中段转折、人物互动和具体细节仍会消失。因此，必须先做覆盖审计，再做视觉压缩。 ## 输出 对每个输入文件输出同目录下两个文件： 1. `[原文件名]_会议纪要.md` 2. `[原文件名]_信息图.html` HTML 必须可以直接用浏览器打开，并提供： - 保存为 PDF：调用 `window.print()`。 - 下载 PNG：用 `html2canvas`，优先 `toBlob()`；本地图片必须内嵌为 data URI。 - 适合桌面阅读，也能在手机宽度下折叠为单列。 ## 质量门槛 ### 内容完整度 对于 30 分钟以上、多人参与的会议，默认至少包含： - 会议定调 / 一眼看懂：4–8 个事实性判断 - 议题时间线：5–10 个转折节点 - 参与者观察：每位发言者一个独立模块，至少写清“角色、核心能力、带入的问题、对话中的变化” - 核心议题：不少于 5 个；每个议题至少包含主张、会议证据、张力或未决问题 - 关键案例：不少于 2 个；还原“发生了什么—为什么重要—大家如何重新解释” - 方法论：不少于 5 个，必须能执行，不得只写抽象价值观 - 原话：6–12 句，标明说话人，只保留有判断力的原话 - 开放问题 / 后续方向：只写真实出现或由讨论明确打开的问题 如果会议实际较短或参与者较少，可以按信息量缩减，不为了凑数量制造内容。 ### 新增硬标准：覆盖优先于卡片数量 在生成 HTML 之前，先建立一张内部覆盖矩阵，不需要全部展示给用户，但必须逐项核对： | 覆盖对象 | 最低要求 | |---|---| | 时间段 | 以 5–10 分钟为单位切段；每段记录事件/主张、发言人、证据、转折和去向。长会议不得只写开头与结尾。 | | 发言人 | 每人至少 3 条具体贡献；安静参与者也要说明她提出了什么问题、回应了谁、带来了什么角度。 | | 议题 | 每条主线必须有入口、展开、转折、暂时落点和未决部分。只出现一次的关键词不够资格成为议题。 | | 案例 | 每个核心案例保留具体人物、场景、冲突、利益/情绪关系和讨论后的重新解释。 | | 互动 | 至少记录 3 组“谁回应了谁、怎样改变了讨论方向”的关系，而不是把每个人拆成孤立卡片。 | | 证据 | 每个高层判断至少绑定一条原话、时间戳或具体故事；无法绑定时降级为“整理者观察”。 | 对 60 分钟以上的多人会议，默认使用以下内容预算作为提醒，而不是机械凑数： - 每 5–10 分钟至少留下一个有信息量的时间线节点。 - 每个主要议题至少 4 个信息块：问题、经验/证据、讨论推进、未决张力。 - 3 小时左右的会议通常需要 8–12 个时间线节点、6–10 条议题线、4–8 个案例、每人 2–4 个具体贡献块；如果逐字稿更丰富，继续增加。 - HTML 的文字量不能显著低于经过整理的 Markdown 纪要；信息图可以长，不能为了“像海报”删掉关键内容。 ### 逐段覆盖审计 生成前后都要回答： 1. 开头 10 分钟的闲聊中，是否有能解释关系、气氛或后续主题的内容被保留？ 2. 中段最长的案例是否被完整还原，而不是被压成一句“讨论了职场问题”？ 3. 会议后 20% 的内容是否发生了主题升级或新的落点？ 4. 每一位参与者是否至少在两个不同议题中出现，而不是只在人物画像区出现？ 5. 是否存在“原文中说了，但 Markdown 和 HTML 都没有”的重要对象、数字、条件或反例？ 若发现遗漏，优先增加“时间线补充”“案例还原”“互动关系”模块，而不是继续增加抽象总结卡。 ### 证据纪律 - 每个重要判断都尽量绑定一条逐字稿中的事件、例子、说法或时间点。 - 区分三种文字：`原话`、`会议中明确说出的归纳`、`整理者的分析`。 - 对人物的观察只能基于表达、故事和互动，不做心理诊断，不把一次发言固化成性格标签。 - 不能把开放讨论写成“会议达成共识”。没有明确决定时，使用“形成倾向”“打开问题”“出现一种可能解释”。 - 没有明确负责人、时间和承诺时，不生成 TODO；可以放入“待继续讨论”。 - 不为了版面制造关键数字。时长、人数、时间节点只有在有解释力时使用。 ## 工作流程 ### Step 1：读取与切分 根据文件类型读取： - txt / md：直接读取。 - docx：`textutil -convert txt -stdout`。 - pdf：使用 PDF 工具提取文本，必要时渲染页面核对。 识别并保留：说话人、时间戳、原句、议题转换、重复出现的概念、案例、提问、回应和未完成句子。先建立逐段数据，再开始写总结。 建议内部形成以下记录： ```text speaker | timestamp | raw_text | topic_guess | claim | evidence | emotional/role shift ``` 不要一边读一边凭印象写一段总评，否则容易遗漏安静参与者、后半场转折和不同意见。 ### Step 2：建立会议骨架 按时间回答： 1. 开场发生了什么？ 2. 第一个真正有信息量的转折是什么？ 3. 哪个故事把对话带入更深层？ 4. 哪个参与者改变了讨论方向？ 5. 后半场是否从个人经验进入方法、组织、社会或人生系统？ 6. 最后停在结论、行动、共识，还是一个开放问题？ 输出“议题链”，格式建议： `事件入口 → 个人感受 → 概念澄清 → 真实案例 → 重新解释 → 方法交换 → 系统问题 → 开放出口` ### Step 3：写每个人的观察 每位参与者单独建立画像，但禁止写成空泛的性格测试。使用四层： 1. **带入什么**：她带来的事件、问题、经验或观察。 2. **如何表达**：她是提问、叙事、拆解、安慰、挑战还是提供方法。 3. **发生了什么变化**：她在对话中从哪里走到哪里。 4. **她的下一层问题**：对话结束后，真正还没有解决什么。 推荐句式： > `[姓名]` 在本场不是“某种人格”，而是在处理 `[具体处境]`。她通过 `[表达/行动方式]` 推动了 `[议题]`，并从 `[原先位置]` 走向 `[新的理解或待验证方向]`。 ### Step 4：建立议题卡 每个核心议题至少写出： - **议题名称**：具体，不要只写“成长”“关系”“工作”。 - **核心问题**：大家到底在争论或探索什么。 - **会议中的主张**：谁说了什么。 - **证据 / 案例**：发生过什么，为什么能支撑这个主张。 - **张力**：另一种可能是什么，哪里没有解决。 - **可迁移方法**：读者可以如何使用。 议题不能只按关键词分类。要保留“一个议题如何变成下一个议题”的因果关系。 ### Step 4.5：建立互动与观点轨迹 这是多人聊天会议区别于单人文章的核心。额外提取： - **回应链**：A 提问 → B 分享案例 → C 重新命名问题 → A/B 修正理解。 - **观点轨迹**：一个人从“我不知道怎么办”走向“我需要改变角色、环境或方法”的过程。 - **关系功能**：谁在安慰，谁在追问，谁在挑战，谁在提供现实路径，谁把抽象问题落回自身。 - **未完成的回应**：被打断、没有被回答、或最后仍然悬置的问题。 HTML 至少加入一个“互动关系/观点轨迹”板块。没有互动证据时，不得凭空制造关系图。 ### Step 5：提取金句与方法 金句优先选择：反常识判断、个人边界、利益与权力判断、方法论、身份转折、带有具体画面的表达。不要把普通寒暄和温柔鼓励冒充金句。 方法必须写成动作： - 不写“要接纳自己”，写“先用第三方视角记录：我观察到自己正在出现……”。 - 不写“要做好管理”，写“把个人冲突改写成角色、职责、资源和备选方案”。 - 不写“要照顾自己”，写“允许可接受的任务停在 80 分，为主要目标保留心力”。 ## Markdown 纪要结构 按以下顺序组织，信息多时继续扩展，不要删到只剩模板： ```markdown # [主题] · 会议纪要 ## 基本信息 ## 一、这场会真正发生了什么 ## 二、议题时间线 ## 三、参与者观察 ### 1. [姓名] ## 四、核心议题地图 ### 1. [具体议题] ## 五、关键案例还原 ## 六、方法与可迁移框架 ## 七、分歧、张力与未决问题 ## 八、明确决策与 TODO ## 九、原话摘录 ## 十、下次会议可继续追踪 ## 备注与证据边界 ``` “明确决策与 TODO”没有内容时删除，不要用建议填充。 ## HTML 信息图结构 优先采用 820–960px 画布、01fish 的深绿 + 珊瑚红 + 明黄，底色使用浅纸张色。卡片可以密集，但要有清晰层级和足够行距。 页面按信息量取用以下模块： 1. **页头**：主题、副标题、日期/频率、时长、参与者。 2. **一眼看懂**：用 4–8 张卡解释会议主线，不写泛泛口号。 3. **议题时间线**：按时间点呈现转折，说明“发生了什么 → 讨论变深在哪里”。 4. **参与者观察**：每人独立横向卡片，至少 4–6 行，不压缩成一个形容词。 5. **议题地图**：每个议题用三列或两列卡片呈现主张、证据、张力/方法。 6. **案例还原**：采用“事件—冲突—重新解释—可迁移”的结构。 7. **关键概念关系**：用箭头或流程展示概念如何互相推动，例如“事件 → 情绪 → 觉察 → 边界 → 系统”。 8. **方法工具箱**：5–10 个可执行方法。 9. **原话证据**：6–12 句，标注发言人。 10. **开放问题 / 后续**：区分明确行动、建议方向和未决问题。 11. **页脚**：来源、整理边界、会议频率。 12. **完整度导航**：在长图顶部或开头提供章节索引，让读者知道后面还有哪些内容；长图不应靠无限滚动让人迷路。 ### 信息密度规则 - 每张卡 2–6 行，必要时可以 8 行；优先增加卡片数量，不要把不同逻辑挤在一张卡里。 - 参与者模块允许比普通卡更长。 - 议题多时使用 2 列，不要为了三列而缩小字号。 - 同一观点只在“人物观察、议题卡、金句”中各出现一次，其他位置用交叉引用，不要机械重复。 - 把“原话”与“整理分析”用不同颜色、边框或标签区分。 - 长页面是可以接受的；用户要求掌握全部精华时，完整度优先于一屏展示。 - 不要用同义改写把同一观点重复填满页面；增加内容必须来自新的时间段、人物互动、案例条件、反例或未决问题。 - 对 2 小时以上会议，优先生成“完整版”，可以另外提供“精华版”；不能用精华版冒充完整信息图。 ## 交付前检查 在回复用户前逐项检查： 1. 是否有安静参与者被遗漏？ 2. 是否覆盖了会议后半场？ 3. 是否至少还原两个关键案例？ 4. 每个重要判断是否有会议证据？ 5. 有没有把开放讨论误写成结论？ 6. 有没有把建议包装成真实 TODO？ 7. 用户只看信息图，能否说出会议主线、每个人的贡献和未决问题？ 8. HTML 能否打开、打印、下载 PNG？ 9. 覆盖矩阵是否完成？是否存在超过 10 分钟没有任何信息块的时间段？ 10. HTML 是否保留了 Markdown 中的关键案例、人物差异和后半场内容？ 如果第 7、9、10 项不能通过，继续补内容，不要只调整颜色和排版。 ## 参考资源 - `references/fishinfo-template.html`：01fish 高密度信息图基础模板。 - 旧版 `meeting-infographic` 仅作兼容参考，不作为内容完整度标准。