Workflow Case

会议纪要 Skill 工作流案例

用基础链路和进阶链路说明会议纪要 Skill：先把会议变成可信纪要，再把校对后的事实、行动项和经验送进公司知识库与角色待办。

基础链路进阶链路角色待办

这页是业务案例页，不替代安装页和运行逻辑页。基础链路已经能解释纪要生成和校准；进阶链路解释校对完成后如何进入公司知识库、角色待办和后续提醒体系。

这条链路解决什么问题

会议纪要最容易出错的地方，不是标题写得不够好，而是原文证据不足、转写误差被当成事实、人名和项目名没有校准、后续纠错只停留在当前文档里。THX 会议纪要 Skill 的目标，不只是把会议整理成一份纪要，而是让会议材料进入公司协同系统：先生成可信纪要，再把确认后的事实、行动项和经验沉淀为可复用上下文。

会议纪要 Skill 基础链路和进阶链路流程图 — 左侧是基础链路：生成可信纪要；右侧是进阶链路：进入公司知识库、角色待办和提醒体系。

保留原始证据

优先使用逐字稿和时间线，不只依赖会议工具自动摘要。正式结论必须能回到原文。

校准公司语境

通过 GBrain¹ 和 THX 角色 MCP² 校准人员、业务线、产品、供应商、项目和常见转写误差。

正式产物分层

给同事、负责人或相关对象看的纪要保持干净；给知识库负责人看的校准反馈单独存放。

进入组织记忆

校对后的事实、行动项、经验和纠偏可进入审核流程，后续给角色 Agent 复用。

1 GBrain：THX 公司知识库，记录公司事实、人员角色、业务线、流程和术语。

2 THX 角色 MCP：按员工身份分配的公司上下文入口。普通同事不处理内部凭据，只使用已分配或已预置的连接能力。

完整工作流图

会议录音 -> 飞书妙记 / 转写稿 -> 原文抽取 -> THX-meeting-minutes -> 公司上下文校准 -> 正式纪要 -> 校对分流 -> GBrain / 会议档案 / 经验库 -> 角色待办 -> Agent 提醒与状态回流

输入层：先拿到可信原文

这条链路的第一步不是让 AI 直接写纪要，而是保证会议材料可追溯。会议可以来自录音硬件、飞书妙记、腾讯会议转写、人工整理稿或聊天记录。只要条件允许，优先使用带时间线、发言人和完整段落的逐字稿。

会议纪要 Skill 基础链路细节图 — 基础链路细节：从录音和转写稿开始，经过结构化初稿与 THX Skill 校准，最后形成可转发、可归档的纪要。

输入来源	使用方式	注意事项
录音硬件 / 会议录音	作为最接近会议过程的原始证据。	录音本身不直接进入正式文档，需要先形成可读取文本。
飞书妙记 / 会议转写	优先抽取逐字稿、章节、待办和摘要。	摘要只辅助判断范围，不能替代逐字稿。
人工粗纪要	用于补充会议背景、参会人和人工确认过的结论。	人工补充也要和原文区分，避免把推断当事实。
聊天记录或补充材料	用于补充行动项、附件、链接和后续确认。	需要标明哪些来自会议，哪些来自会后补充。

处理层：不是摘要，而是结构化判断

材料进入 Skill 后，会先判断任务类型和输出目标。它要知道这是一场周会、项目推进会、复盘会、主管沟通还是临时讨论；也要知道用户只要正式纪要，还是同时需要行动项、周报素材、知识库候选或返修建议。

会议类型

不同会议的结构不同。周会重进展和风险，复盘会重原因和经验，项目会重负责人和时间节点。

事实边界

原文没有负责人、金额、截止时间或判断依据时，不补成确定事实，只标待确认。

输出对象

给同事看的纪要、给负责人看的行动项、给知识库负责人的纠偏材料，不能混成一份。

校准层：用公司上下文纠偏

会议转写常见的问题，是声音听对了，但公司语境错了。比如人名同音、项目简称、产品版本、供应商名称、业务线归属、App 名称和店铺名称，都可能被转写工具识别成看似合理但业务上错误的词。

校准对象	Skill 会怎么处理	正式纪要里的口径
人员和别名	用人员名单、别名和上下文判断发言人或被提到的人。	使用公司标准称呼；不确定时标待确认。
产品和项目	检查产品名、版本、项目简称、渠道名是否符合公司常用口径。	优先写标准名，必要时在括号里保留原文疑似词。
供应商和方案方	区分供应商、方案厂、平台、渠道和内部业务线。	不把外部公司、平台和内部项目混写。
常见错词	把已确认的转写纠偏作为候选规则复用。	正式版写纠偏后的结果，校准反馈记录纠偏来源。

如果上下文查不到，Skill 不会为了让纪要完整而编造。它会把缺口写进待确认问题或校准反馈。

输出层：正式纪要和反馈材料分开

完整链路会把产物分成三组：一组给人直接阅读，一组给系统和负责人继续迭代，一组给角色后续执行。正式纪要越干净越好，校准反馈越可追踪越好，行动项越容易落到角色待办越好。

产物	读者	内容边界
Word 会议纪要	同事、主管、管理层、相关外发对象	只保留正式会议内容、结论、行动项、风险和待确认问题；不出现工具调用和知识库命中过程。
Markdown 会议纪要	Agent、本地归档、后续处理	保留结构化内容，方便继续生成周报素材、复盘草稿或任务清单。
校准反馈	知识库负责人、Skill 负责人	记录人名纠偏、术语候选、项目归属、上下文缺口和 Skill 规则问题。
GBrain 待审核候选	知识库负责人	只有被用户确认过、可复用、非敏感的公司事实才进入候选。
角色待办候选	对应负责人、岗位 Agent、管理层 Agent	从行动项里提取负责人、事项、截止时间、依赖和状态，后续可进入提醒与跟进体系。

进阶链路：知识库、角色待办和提醒

基础链路到“正式纪要”和“校准反馈”还不够。校对完成后，会议里的事实、经验、风险和行动项应该继续分流：可复用事实进入公司知识库候选，岗位经验进入经验库候选，行动项进入角色待办候选。未来角色 Agent 不只是拿 MCP 数据做查询，也应该能看到“公司里有什么需要我做、哪些事项需要我跟进、哪些背景和我有关”。

会议纪要 Skill 进阶链路细节图 — 进阶链路细节：校对完成后的内容先进入候选和审核，再分流到知识库、角色待办、Agent 提醒和状态回流。

材料类型	进入哪里	后续用途
已确认公司事实	GBrain 待审核候选	后续会议纪要、周报、业务问答和角色 Agent 查询时复用。
项目进展和会议结论	会议档案 / 项目对象页	让后续项目复盘、交接和管理层校准有上下文。
岗位经验和方法	THX-Experience-Base 候选	沉淀为岗位经验，给同类场景和新同事复用。
行动项和责任人	角色待办候选	后续可以被对应角色 Agent 读取、提醒和跟踪状态。
风险、缺口、待确认问题	负责人审核队列	避免把未确认内容直接写成事实，同时给负责人明确下一步。

定时提醒属于进阶能力，需要后续和角色权限、待办状态、日历或通知系统打通。当前页面先把这条产品链路讲清楚，不把它写成已经完全上线。

反馈闭环：让下一次更准

当用户指出“不是 A，是 B”时，会议纪要助手不能只把当前文档改对。它要判断这是不是可复用的公司规则：如果只是本次措辞，就留在本次返修；如果是人员、项目、产品、供应商或流程事实，就整理成 GBrain 待审核候选。

用户纠正 -> 判断是否可复用 -> 敏感边界检查 -> 形成待审核候选 -> 负责人确认 -> GBrain 更新 -> 后续 Skill 自动复用

只改当前文档

排版偏好、一次性措辞、会议里临时修改的标题，不需要进入 GBrain。

进入候选池

稳定人名、部门归属、项目简称、产品名、供应商关系和常见转写纠偏，适合交给负责人审核。

和普通会议纪要工具的区别

普通会议纪要工具	THX 会议纪要 Skill
主要生成一份摘要。	先拿原文证据，再结构化生成正式纪要、行动项和校准反馈。
人名、项目名和业务线主要靠当前文本猜。	结合 GBrain 和 THX 角色 MCP 校准公司语境。
错了通常只改当前文档。	稳定纠错可进入 GBrain 待审核候选，后续会议复用。
输出和内部处理过程容易混在一起。	正式纪要、Markdown 归档、校准反馈分开交付。
使用越多，材料仍然散在不同工具里。	使用越多，公司术语、流程、角色待办和纠偏会逐步沉淀。

边界和适用范围

情况	处理方式
飞书或其他工具转写不稳定	保留疑似词，结合上下文校准；查不到的标待确认。
涉及财务、合同、人员评价、CEO 私密判断	不进入普通 GBrain，不在普通员工页面展开，先提示需要负责人确认处理方式。
会议里出现新的业务事实	先整理为待审核候选，不直接写入 GBrain 主库。
会议里出现角色待办	先整理为角色待办候选，负责人确认后再进入提醒或跟进体系。
用户只想要一份普通纪要	可以只输出正式 Word / Markdown，不强制生成知识库反馈。

实际开始时怎么说

业务同事不需要描述完整链路，只要上传或粘贴转写稿，并说明想要哪些产物。

请整理这份 THX 会议转写稿。请先做公司上下文校准，输出： 1. 正式会议纪要； 2. 行动项； 3. 风险和待确认问题； 4. 如有可复用纠偏，单独整理为 GBrain 待审核候选； 5. 如有明确负责人和截止时间，单独整理为角色待办候选。

如果只要可以转发的纪要，可以删掉第 4、5 项；如果要接入知识库或后续跟进，就保留它们。