结构化开发团队会议纪要整理提示词

角色定义与任务定位
你应以技术团队负责人或项目协调员的身份，使用这组提示词来生成或整理开发团队的会议纪要。目标是将会议中碎片化的讨论、技术决策、任务分配和后续跟进事项，转化为一份结构清晰、重点突出、可直接驱动团队行动的专业文档。你需要确保纪要具备可追溯性、责任明确性和时效性，让每位成员都能快速找到与自身相关的待办事项和决策依据。

适用场景

  每日站会、Sprint计划会、回顾会等敏捷迭代会议后的纪要整理
  技术方案评审会、Bug复盘会、架构决策讨论会等专业开发会议
  跨部门协作会议，需同时向产品、测试、运维等角色同步关键信息
  需要将会议录音或速记内容快速转为结构化Markdown/HTML文档的场景


核心提示词
以下为可直接复制使用的提示词模板，建议根据实际会议内容微调：

  基础结构提示词：“请以技术团队负责人的身份，整理本次开发例会的纪要，严格按照【会议主题｜日期｜参会人】→【议题1：讨论要点】→【最终决策】→【待办事项（责任人+优先级+截止时间）】→【下次会议确认项】的结构输出。每个议题单独分段，待办事项使用项目符号列表，责任人姓名加粗。” 
  技术评审专用提示词：“针对本次技术方案评审会，整理纪要时需突出【方案名称｜提出的问题｜备选方案对比｜最终选型理由】四个模块。在每个议题下增加一个‘风险与妥协’子段落，使用折线图标（可文本化）标明技术债或兼容性风险。” 
  问题复盘专用提示词：“请整理本次Bug复盘会议纪要，格式为【问题标题｜复现步骤｜根因分析｜修复方案｜回归测试责任人】。在每个问题末尾加入‘经验教训’部分，用一句话总结避免再次发生的策略。所有时间节点使用ISO 8601格式。” 


风格方向

  极简工程风：使用项目符号、缩进、分隔线、粗体/斜体，避免冗余描述，每个要点控制在3行以内。
  可执行导向：每个待办事项都有明确的动词（如“重构”“测试”“批准”“同步”），避免模糊表述如“讨论一下”。
  中立客观：不加入主观评价，仅记录事实、决策和行动，如“团队决定采用Event Sourcing方案”而非“大家一致认为很好”。


构图建议（文档布局参考）

  左列时间轴 + 右列卡片：左侧标记会议时间线（如 9:00 – 9:15 站会汇报，9:15 – 9:45 架构讨论），右侧用卡片形式展示该时段的关键决定与待办。
  优先级别色块：在待办事项前使用文本图标（如 [P0]、[P1]、[P2]）区分紧急程度，而非颜色（AIGC工具可能不支持彩色）。
  责任矩阵：对于跨团队协作会议，在纪要末尾追加一个表格（文本化）列出“事项｜主责｜协作者｜截止日”，便于快速分配。


细节强化

  状态标记：每个议题后标注【已决策】【待定】【需跟进外部】，帮助读者快速筛选重点。
  关联项链接：如果会议提到Jira Issues、PR、Wiki链接，在纪要中直接以文本形式列出（例如：JIRA-1234），方便复制跳转。
  时间精确性：所有截止日期精确到工作日，并加上“需在X月X日下班前确认”等自然语言，避免纯数字歧义。
  行动追踪闭环：在纪要末尾增加“下次会议前需完成检查项”列表，标注每个检查项对应的上次待办ID。


使用建议

  将上述核心提示词复制到ChatGPT/Claude等对话式AI工具中，或嵌入到Notion/GitHub Wiki的自定义模板里。
  如果使用语音转文字工具（如Otter.ai、飞书妙记），可将转写结果作为输入，配合“基础结构提示词”快速生成初稿，再手动修正技术术语。
  对于频繁迭代的Sprint会议，建议将提示词保存为团队文档模板，每次只需替换时间和议题细节，确保一致性。
  提醒团队成员在会议中使用统一的术语表（如“需求变更” vs “功能增补”），避免提示词理解偏差。