会议纪要与待办

会议纪要写得再全，如果没人跟进，它就只是一份归档文件。真实情况往往是：决议写在文档里，待办散在聊天记录里，到期没人核对，下次开会把上次定过的事重新讨论一遍。

还有一类更隐蔽的损耗——纪要把"有分歧"写成了"已决议"。为了让文档看起来齐整，把几方没谈拢的意见折中成一句话，结果执行时各按各的理解来。

转写服务用插件封装成一次 REST API 调用，在工作流里用插件节点触发。转写是典型的"给文件拿结果"，不需要用技能或 MCP 这类更重的封装。

拿到文本后，先用代码执行节点按时间戳和发言人切块，再用 LLM 节点按议题归并。这个顺序不能反——整段丢给模型做摘要，跨议题的内容会被揉在一起，责任人和事项就对不上了。一小时的会通常涉及三到五个议题，切开处理，每个议题的上下文才是干净的。

LLM 节点输出格式选 JSON，每条行动项落成固定字段：事项、责任人、期限、验收标准。

自由文本形式的待办没法被后续流程消费。"小王下周跟进一下"这种表述，既不知道具体做什么，也不知道怎么算做完。要求模型必须填满四个字段，填不出来的就标为"信息不足待确认"——这比生成一条含糊的待办有用。

角色设定里明确区分三类内容：已决议（有明确结论）、有分歧（记录各方意见，不强行收敛）、待确认（缺少关键信息）。

把"没定下来"如实标出来，短期看纪要不够漂亮，长期看这是纪要还有没有人信的关键。一份把分歧抹平的纪要，用过两次大家就知道不能当依据了。

按待办期限配定时任务，到期自动触发，把未完成项汇总推送给责任人和会议召集人。定时任务支持按天、按周等频率配置。

纪要因此从一份静态文档变成一条带回路的流程——这是它和"把录音转成文字"的本质区别。