# 用 AI 把会议记录整理成待办草稿：不要把讨论意见变成已经决定的任务

本文包含指向 SunAPI 的介绍性链接。文章中的会议、人员角色和项目均为虚构示例，用于说明文本整理应用的设计。AI 生成的待办不代表真实会议决定，也不表示 SunAPI 自带项目管理系统。讨论重点是怎样保留证据与状态，让负责人能在创建正式任务前看清每项建议来自哪里。

会议结束后，最常见的整理困难不是没有记录，而是记录里混着建议、问题、决定和临时想法。某人说“也许可以下周试一下”，并不等于他接受了一个下周必须完成的任务。若让模型直接提取所有动词并填入任务表，表格可能很整齐，却给团队增加了从未承诺的工作。好的整理工具应先识别语句的作用，再提出待办候选，而不是把语言流畅程度当作决定已经成立的证据。

虚构例子是一场资料库改版会议。参与者讨论分类名称、搜索说明和上线前检查。会议记录中有人提出增加示例，有人确认先修改帮助页，还有一项问题需要产品负责人进一步决定。工具要帮助整理这些差异，使会后确认更快。它不需要自动分派真实员工、修改项目权限或把候选任务直接写入正式系统。这里的负责人名称使用角色代号，不涉及个人绩效或能力评价。

# 明确整理结果是候选清单

在界面顶部写清楚“待确认草稿”，并说明它依据哪一份会议记录生成。不要在生成完成后显示“任务已创建”，除非应用确实经过适当确认并完成了写入。状态文字会影响使用者判断，不能把请求成功当成业务处理成功。若目前只生成候选项，就让所有后续动作围绕审阅展开。

清单可以分为已明确决定、提出但未决定、待澄清问题和背景信息。分类的定义需要团队共同理解。若模型不能确定一句话属于哪类，应允许它保留疑问。编辑可以调整分类并记录原因，而不是为了让表格没有空白，强迫每条讨论都成为行动。会议本来就可能包含没有结论的话题，整理结果应诚实反映这一点。

# 保留原文与稳定的段落编号

为记录中的段落或发言片段设置编号，保存原文和版本。每个候选任务都应引用相关片段。负责人审阅“修改搜索说明”时，可以立即看到是谁提出、是否有人确认、有没有附带条件。单纯显示一条润色后的任务名，会让人很难判断模型是否省略了重要限定。

编号应能在排序或复制后继续工作，不只依赖当前文档中的行号。如果会议记录后来补充或纠正，应用需要知道哪些候选项依赖旧文本。原始记录也不应被模型的整理结果覆盖。两者是不同层次：一份保留讨论发生时的表达，另一份提供结构化解释。保留这一区别，才能在出现争议时回到依据，而不是让草稿替代历史。

# 用语言证据区分建议与承诺

“可以考虑”“是否需要”和“我们确定先做”表达不同状态。模型可以协助识别这些线索，但不能只看某个关键词就下结论。上下文可能改变意思，例如“我们确定先做吗”仍然是问题。审阅规则应要求模型给出支持分类的片段，并说明还有什么不确定。

在虚构会议里，设计角色提出下周测试两个分类名称，主持角色表示需要先看资源安排。这不能直接成为已经排期的测试任务。清单应保留为待决定建议，并指出资源安排尚未确认。若后面另有明确决定，再引用后续片段更新状态。这样，工具帮助团队找到决定，而不是替会议补上一个更像项目计划的结尾。

# 不从发言者自动推断负责人

提出问题的人未必负责解决，提供建议的人也未必接受执行。只有记录明确说明负责角色，或会后审阅者确认后，才应填写负责人。缺少信息时使用待确认，而不是把任务默认分给提议者。这个设计能避免一次文本处理无意改变工作分工。

应用可以把“建议联系人”和“已确认负责人”分开，但不能用模糊字段掩盖两者差异。若团队需要选择负责人，应通过现有权限流程完成，而不是让模型根据职位名称猜谁最合适。本文只处理任务信息，不评价人员能力或优先安排个人工作。负责人最终确认后，保留确认时间与任务版本，方便后续知道分配是如何形成的。

# 截止日期必须有明确来源

“下周再讨论”通常是下一次讨论时间，不一定是任务完成期限。“月底前最好完成”也可能只是目标而非承诺。模型应区分日期的角色，并引用原文。没有具体日期时，不要为了填满字段自动选择一个常见周期。一个空的待确认日期，比虚构的期限更准确。

如果需要把相对日期换成日历日期，应用应先有明确会议日期与时区，并说明转换规则。转换后的结果也需要检查。不要把模型推算当成已经核对的日程。对于跨月或跨时区情境，界面应显示原表达和解释后的日期。负责人能够看到两者，才容易发现“下周一”被理解成不同时间的问题，并在正式创建任务前纠正。

# 把行动、交付物和完成条件分开

“优化帮助页”太宽泛，难以判断什么时候结束。若记录已有具体要求，可以整理成修改哪个页面、交付什么、由谁检查。若这些信息不存在，模型可以提出待澄清问题，而不是自行补出验收标准。任务草稿应保持与会议证据相同的确定程度。

例如，记录明确决定新增一个筛选示例，则交付物是该示例，完成条件可能需要负责人另行确认。不能从“新增示例”推导出必须覆盖全部场景或达到某个效果指标。AI 可以建议如何让任务更清楚，但建议部分必须与已决定内容分开。这样，审阅者能够有意识地补充条件，而不是在接受一个语句更漂亮的任务名时顺带接受额外要求。

# 识别依赖而不创造排期

某项任务可能需要等待另一项决定，例如分类名称确认后才能更新帮助页。记录中若明确表达这种关系，可以提出依赖。若只是一般经验上的先后顺序，应标为建议供审阅。不要因为系统支持甘特图，就让模型为每条候选任务安排日期与资源。

依赖数据需要稳定任务编号，应用应检查是否存在不存在的引用或循环关系。模型生成的结构即使语法正确，也可能无法形成有效流程。负责人确认依赖后，再由正常项目流程决定排期。文本整理工具可以帮助看清阻碍，但不应假装已经完成资源协调。把依赖和时间承诺分开，会使会后确认更加具体，也减少团队对草稿含义的误解。

# 通过 SunAPI 生成结构化候选项

开发团队可以参考 SunAPI 文档，核对当前请求方式和响应结构。应用向接口提供已经允许处理的记录片段、分类定义和输出要求。会议文件访问、人员权限和正式任务写入都由应用另外管理，不会因为一次文本生成而自动获得。

密钥保存在服务端。保存会议记录版本、提示规则和候选结果，以便复查。如果记录含有不必要的私人信息，应先按适用流程处理，不能把方便当成扩大传输范围的理由。验证时可使用虚构会议，检查模型是否会把问题当决定、把日期当期限或把发言者当负责人。选择配置需要看这些实际错误，而不是只看任务标题写得是否像专业项目文档。

# 将待澄清问题作为正常输出

一份有用的结果可能包含少量明确任务和多条待确认问题。这不是生成失败。真正的问题是模型为了显得完整，把不确定部分藏在确定语气里。应用应支持审阅者先处理澄清项，再把得到确认的信息更新到候选任务。

问题要具体，例如“这项建议是否已决定实施”或“这里的下周是讨论时间还是完成时间”。避免提出笼统的“请补充更多信息”，让负责人重新阅读全部记录。AI 可以整理问题，但不能把没有回复视为默认同意。等待状态应保持，直到授权人员提供明确确认。这个原则让草稿能够反映真实进展，而不是通过时间流逝把悬而未决的讨论变成正式承诺。

# 防止合并时丢失独立条件

两条任务看似相似，可能面向不同页面或不同读者。模型建议合并时，应说明共同点与差异，保留各自来源。若条件不同，合并后的描述必须仍能看出范围。不能因为都含有“更新说明”，就把帮助页修改与内部培训资料修改合成一个没有边界的大任务。

重复讨论也不一定需要重复任务。若同一决定在会议后半段被再次确认，可合并来源，但要保留最后确认的状态。应用可以显示候选合并供审阅，不直接删除原项。合并会影响负责人、期限和依赖，因此应被当作实际任务结构变化，而不只是文字去重。清楚展示这些影响，能够减少一次便捷操作造成的工作遗漏。

# 在正式写入之前展示差异与范围

审阅完成后，系统可以显示将创建的任务、仍待确认的项和明确排除的讨论。每条正式任务对应被批准的版本。若要写入项目工具，使用已有权限和适当确认流程，而不是让模型自行选择项目或接收人员。生成候选与执行写入是两个不同阶段。

写入后还应记录成功与失败，避免把部分完成显示为全部完成。失败项可以重试，但需要防止重复创建已经成功的任务。应用可以使用内部对应关系识别重复提交。这里的可靠性来自软件状态管理，而不是要求模型在下一次回复里记住哪些任务已经创建。模型适合整理表达，业务系统负责确保每个动作可追踪且只在正确范围内发生。

# 测试不完整和相互矛盾的会议记录

验证集应包括没有结论的话题、负责人不明确的行动、相对日期、后续否定前面建议的片段，以及一条真正明确的决定。提前写好期望分类，检查模型是否保留证据和不确定性。再测试无效编号、重复项、处理中断和记录更新后的旧结果，确保界面不会将它们误当成可直接写入的清单。

团队还可以检查审阅者需要多久找到依据、哪些问题最常被修改。评价不应只统计提取出多少任务。提取过多可能意味着把讨论错误地转成了承诺。报告结果时说明记录类型和检查范围，不根据少数样例声称系统能保证会议决策准确。实际帮助是减少整理负担，并让人更容易发现需要确认的地方。

会后整理最重要的不是让记录看起来像一份完整计划，而是忠实地区分已经决定、仍在讨论和需要澄清的事项。AI 可以帮助找出候选行动、连接来源并改写标题；应用需要保护版本、分配权限与正式写入边界。只要这些层次清楚，团队就能更快完成确认，同时避免把一场开放讨论变成参与者从未接受过的任务清单。