让 Gemini agent 整理会议纪要时，真正需要人工把关的不是“它写得好不好”，而是“它写了什么不该写的东西”。通常的判断标准是：凡是没有在输入记录里明确出现、没有在会议中被确认、或者不适合在纪要分发范围内传播的内容，都不应让 agent 直接成稿。可行做法是把“整理”和“判断”拆开——agent 只负责把已确认信息归纳成条目，未确认、有争议、涉及敏感范围的内容一律保留原始表述或标成待办，由人决定是否写进结果。

会议纪要场景下，Gemini agent 的输出边界建议这样划：只整理会前资料中已定稿的部分、会中明确达成一致的记录、会后书面确认的结论；主观判断、未决议题、个人意见、敏感信息（人名与薪酬、金额与报价、未发布计划）都不进入正文。落地方式是给输入打可信度标签、在任务描述里写死输出范围、再用事实一致性、结论归属、待办明确性三项逐条核对原文。任何拿不准的条目，宁可留在“待确认”区，也不要让它以陈述句形式出现在纪要里。

分会前资料、会中记录、会后结论三类输入

Gemini agent 容易出错的地方在于，它会把不同可信度的材料揉成同一段平滑的文字。所以给输入加标注是第一步，也是后面所有复核的基准。建议在传给 agent 的材料里用统一前缀标记来源类别，让标注本身成为提示的一部分：

[会前-定稿] 需求文档 v3，已评审通过，可作为结论依据
[会前-草稿] 排期初稿，未评审，仅作背景，不得写成结论
[会中-原话] 张三：这个接口下周大概能给出来（未承诺，无具体日期）
[会中-共识] 全体确认：本期不做多语言
[会后-确认] 邮件回复：上线时间定在下月第二个周二

三类输入的可信度需要区别对待：会前资料只有标为“定稿/已评审”的部分才能当依据，草稿和初稿只能作为背景，不能让 agent 据此推断结论；会中记录里，明确说“确认、定了、就这么办”的才算共识，带“大概、可能、看看、尽量”的表述一律按未确认处理；会后结论要等到有书面确认（邮件、工单、文档更新）才提升为结论级别。验证方式是抽几条 agent 输出的结论句，回到标注过的输入里找对应原句，找不到就是它自己补的。

标出纪要中容易混入的主观判断

大模型在整理会议纪要时有一个常见倾向：为了让文字通顺，把零散讨论补成完整逻辑。这类补写读起来很像真的，但原始记录里并没有。需要重点盯三类风险内容：

• 主观判断：例如把“这个方案感觉不太稳”写成“会议认为该方案风险较高”。评价性词语被强化成集体判断，属于典型的改写越界。
• 未决议题：讨论过但没有结论的话题，被 agent 归纳成“已确定按 X 执行”。这类错误影响最大，因为它会变成后续执行的依据。
• 个人意见：某一个人的提议被写成“会议决定”。归属错了，责任就错了，事后很难追溯。

处理方式是在任务描述里要求 agent 对这三类内容使用固定标记，例如未决议题统一写成“【待确认】xxx，会上未达成一致，参与意见：A 建议…／B 保留…”。这样读者一眼能看出哪些是结论、哪些只是讨论。核对时可以用关键词扫一遍输出：出现“决定、确认、一致同意、结论是”的句子，逐条回原文找依据；出现“认为、建议、倾向于”的句子，确认主体是人还是会议。

检查敏感信息和未公开信息

纪要是要分发的文档，一旦发出去就收不回来。让 agent 直接成稿前，先明确哪些内容即使会上说过也不该进纪要正文。建议按下面这份清单排查：

• 人名与个人信息：涉及绩效评价、薪酬调整、个人健康、离职意向的具体人名，只写“相关人员”或会后单独沟通，不进正文。
• 金额与商务条款：报价、折扣、预算上限、供应商比价、合同金额，除非纪要分发范围已明确包含这些信息，否则用“商务条款另行确认”替代。
• 未发布计划：尚未对外公布的产品功能、上线时间、组织调整、客户名称，按未公开信息处理，纪要里只留内部代号或干脆不写。
• 权限与账号信息：会议中贴出的地址、密钥、内部链接、测试账号，整理时应删除，不能因为“会上展示过”就保留下来。
• 对第三方的评价：对同事、合作方、客户的负面评价，写进纪要会带来不必要的麻烦，建议直接剔除。

具体做法是在给 agent 的指令里列出排除项，同时在输出后做一次人工扫描：搜索数字、金额符号、人名列表、产品代号。这一步无法完全交给 agent 自查，需要结合所在团队的保密要求和纪要分发范围确认。

在任务描述中限定只整理已确认内容

与其事后删改，不如在给 Gemini agent 的指令里把输出边界写死。下面这个模板可以直接改字段使用，重点是最后三条约束：

你是一名会议纪要整理助手。请基于我提供的记录整理纪要，严格遵守以下规则：

1. 输入材料已用 [会前-定稿] [会前-草稿] [会中-原话] [会中-共识] [会后-确认] 标注来源。
2. 只把标注为 [会中-共识] 和 [会后-确认] 的内容写成结论句；[会前-定稿] 可作为背景说明。
3. [会前-草稿] 和 [会中-原话] 中带“大概、可能、看情况、尽量”的表述，一律不作为结论，放入“待确认”区并保留原话。
4. 涉及人名、金额、报价、未发布产品信息、内部链接与账号的内容，不要写入正文，统一列在“需线下确认的信息”清单里，只写类别不写细节。
5. 不要补全任何缺失信息，不要推测会议未讨论的内容，不要用“会议认为”替代个人发言。
6. 输出结构固定为：一、已确认事项；二、待确认事项（含原始表述与发言人）；三、待办（含负责人与时间，未明确写“未指定”）；四、需线下确认的信息。
7. 每条已确认事项后面附上对应的输入原句编号，便于我核对。

第 7 条很关键：要求 agent 回标原句编号，等于让它自己给出可核验的出处。执行位置可以是任何支持长文本输入的对话界面或接口，把会议记录按标注格式贴进去即可。验证方式是先拿一份已知结论的旧会议记录试跑，看它是否会把草稿内容误升为结论；如果会，说明规则约束还不够紧，需要把第 3 条写得更具体。

逐条对照原始记录复核输出

agent 输出不能直接发，复核这一步省不掉。建议按三项逐条过一遍，尤其是结论段落：

复核时可以先扫结论词（决定、确认、一致同意、结论），再扫敏感词（人名、金额、日期、产品名），最后看待办清单是否每条都能落到人。这套检查不能保证纪要完全无遗漏，但能把“agent 替会议做决定”这类最麻烦的问题挡在分发之前。团队如果对纪要格式有固定要求，可以把上面三项做成模板里的勾选项，每份纪要发布前走一遍。