AI 活动策划:准备活动执行流程表与异常交接
AI 活动策划可将所提供的环节笔记及场地或供应商确认信息整理成活动执行流程表草稿。为每个环节明确时间段、负责人及交接要求,在员工使用流程表前检查时间重叠及缺失的确认。在活动负责人确认其依据的执行信息之前,面向参加者的说明都应保留为草稿。
能力状态:已有文档说明。 Text Input、OpenAI、Structured Output 和 Update Range 已在组件目录中说明;Ai Flowi 尚未进行生产环境测试。这项研讨会设计没有已记录的活动当天执行结果。
作者:Ai Flowi · 发布日期
按确认需求选择活动任务
从团队提供的环节清单及实际确认记录出处开始。区分建议时段与已接受的场地使用时间,也要区分供应商的估计与已完成的设备布置。编排得再漂亮,也不能证明这些事实。
| 任务 | 有用的草稿 | 接受所需的证据 |
|---|---|---|
| 安排环节顺序 | 带有负责人及共享资源的起止时间段。 | 活动负责人检查时区、依赖关系及资源冲突。 |
| 场地或供应商交接 | 要求、确认记录出处及未解决的变化。 | 负责此事项的员工核实当前确认信息及交接情况。 |
| 参加者信息 | 措辞仅限于已接受的流程事实。 | 对外分发前,由对外信息审核人批准草稿。 |
| 预订或安全决定 | 不在此准备路径的范围内。 | 使用获授权的预订流程及由具备相应资质的人员执行的活动流程。 |
通用任务状态及依赖关系见 项目跟踪表。本台账增加活动当天的时间段、资源冲突及供应商交接证据;仅完成准备任务,不能放行某个环节。
相关内容:餐饮 AI 应用:核对菜单证据与咨询信息缺口。
复制活动当天的台账
每行代表某个流程修订版中的一个已排定环节。在来源材料包中保留原始的当地时间措辞;员工确认预期日期和时区后,才存储带时区的开始及结束时间。缺少时区信息会使顺序安排不确定。
schedule_revision, activity_id
start_at, end_at, timezone_name
activity, activity_owner, resource_ref
venue_requirement, venue_confirmation_ref
vendor_requirement, vendor_confirmation_ref
handoff_evidence_ref, state
attendee_draft, exception_note, reviewer_ref
如何维护已审核状态及其决定历史,见 任务状态指南。
本活动使用以下自行定义的标签: proposed、 ready_for_review、 accepted、 held、 cancelled 和 unknown。每个环节旁都应保留确认要求:场地准入、设备就绪及主持人是否能到场回答的是不同问题。已撤销的演示应保留取消引用,即使原时段已空出来。
演练虚构的研讨会执行流程表
这场虚构研讨会使用修订版 W-1 及时区 Asia/Kuala_Lumpur。以下时间均属于虚构的 2030 年 11 月 12 日,时区偏移为 +08:00;例如,09:00 单元格表示 2030-11-12T09:00:00+08:00。姓名、来源引用及要求均仅为本练习编造,不是真实活动记录。
| 环节 / 负责人 | 起止时间 / 资源 | 场地与供应商要求 | 证据 / 状态 |
|---|---|---|---|
| A-1 设备布置 / 布置负责人 | 08:30–09:00 / A 室 | 08:30 起可进入场地;开场前设备就绪。 | VEN-1 确认场地准入;SUP-1 预计 08:30 到达;是否完成未知 / 暂缓 |
| A-2 开场环节 / 主持人 | 09:00–09:20 / A 室 | 布置完成后场地可用;麦克风可用。 | VEN-1;缺少布置交接 / 暂缓 |
| A-3 小组活动 / 主持人 | 09:15–09:45 / A 室 | 开场已结束;使用同一场地及主持人。 | PLAN-1 建议时段;与开场重叠 / 暂缓 |
| A-4 可选演示 / 演示负责人 | 09:45–10:00 / A 室 | 需要供应商的演示设备套件。 | CANCEL-1 记录演示已撤销 / 已取消 |
供应商延误: 新提供的 SUP-2 笔记预计设备于 09:10 到达。保留 SUP-1、SUP-2 及各自版本,并标明估计时间的变化。09:10 到达比原定开场晚十分钟,但仍不能说明设备布置已经完成。布置负责人取得可信的完成时间段、活动负责人决定如何修订前,A-1 和 A-2 均保持暂缓。
交接需要布置负责人提供所需设备已就绪的证据,以及主持人确认 A 室符合使用要求。供应商估计、收到一条消息或模型的置信程度均不能替代放行依据。如果场地准入也发生变化,应单独重新确认。
环节时间重叠: A-2 与 A-3 在 09:15 至 09:20 期间共用 A 室及主持人,重叠五分钟。将 A-3 建议改为 09:20–09:50,只有在 A-2 实际于 09:20 结束时,才能消除两者重叠。应重新检查所有后续时间段及资源安排;这个改动不能解决设备延误,也不能恢复已取消的 A-4。
对 W-1,面向参加者的草稿不应保证 09:00 开始,而应说明开场时间尚待确认。这是建议措辞,不是已发送的更新。员工批准新修订版后,应将草稿关联到该修订版,并通过正常沟通流程停用早先措辞。
用已有文档说明的组件准备草稿
示例配置,并非实际测试记录
准备获授权的笔记、活动负责人、对外信息审核人、你自己的模型提供商账号/API 密钥,以及对独立草稿工作表有编辑权限的 Google 账号。模型使用费用由提供商另行收取。 连接指南 介绍保密凭据及 Google 授权。
- 汇总 W-1: 将研讨会笔记放入 Text Input 的
input_value,保留已确认的时区、VEN-1、SUP-1、SUP-2 和 CANCEL-1。区分 SUP-2 修订后的到达时间估计与设备布置已完成的证据。 - 配置 OpenAI 访问: 按照 模型提供商设置指南 配置研讨会所需的模型凭据。
- 定义流程表草稿: 在 Structured Output 中选择
schema_name=workshop_run_of_show,并围绕 17 个活动列构建output_schema。设置system_prompt,使每项确认关联到对应环节,保留 CANCEL-1,标记 A-2/A-3 共用场地和主持人的情况,并在缺少布置完成证据时,让参加者草稿保留条件限制。 - 检查建议的修订: 将 A-3 建议的 09:50 结束时间与 A 室的所有后续安排比较,包括这四行之外的安排。手动准备已接受的草稿表头及四个环节行;接受此草稿不等于允许 A-2 开始。
- 存储研讨会副本: 对 Update Range,使用
range_name=WorkshopDraft!A1:Q5及已审核的 17 列values数组,包含表头。选择导出的选项value_input_option="RAW";include_object_headers= false 可避免再次提供表头。已接受的活动当天流程表仍保留在单独的目标位置。
此手动准备步骤涉及的端口连接、结构定义准备及目标凭据,见 组件接口约定、 结构化输出参考 和 Sheets 操作指南。
在延后开场与调整顺序之间选择
假设在 SUP-2 预计的 09:10 到达之后,布置负责人能确认设备于 09:25 就绪。将 A-2 改为 09:25–09:45 可保留二十分钟时长,但 A-3 建议的 09:20 开始时间就太早了。新的小组活动方案 09:45–10:15 可保留三十分钟时长;员工仍需确保直到 10:15,场地都可进入,主持人也能在场。这些是带条件的策划计算,并非已确认的替代安排。
或者,主持人可能建议不用麦克风开场。修改设备依赖前,应检查这种方式是否满足环节要求。从台账删除依赖,不能证明口头讲解适合该场地或参加者。保留原要求,以及活动负责人接受任何替代方案的理由。
如果没有确认可行的场地时间段或设备替代方案,应保持开场暂缓,不要将布置压缩进缺乏依据的五分钟时段。此时,参加者草稿需要一个待确认问题,员工则需要具体的未解决依赖及负责解决的人。
活动放行前如何检查异常交接?
所需成果是草稿台账,包含明确时间段、保留的确认信息、A-1 尚未解决的设备问题、A-2/A-3 的资源冲突,以及 A-4 的取消。用缺失时区、供应商笔记没有环节引用,以及场地时间段改变的情形重新演练。每种情形都应产生明确可见的问题,而不是编造确认。
跨修订版维护决定时,请使用 跟踪表的更新与审核指引。
存储 W-1 后,检查 A-4 是否仍为已取消,且 SUP-2 在相关异常单元格中是否仍以估计呈现。如果员工编辑改变了 A-2 的开始时间,应先核对该编辑,再替换五行草稿区域。旧的 W-1 参加者段落不得配合新接受的开场时间使用。
供应商准入资料可参考 供应商准入流程,独立的住客请求可参考 酒店交接指南。本活动台账不提供预订、差旅采购、安全或人群管理计划,也不提供对外消息投递。需要这些行动时,应使用由具备相应资质的人员执行的运营流程。
套餐:Go 年付方案每月 USD8 起(月付 USD10),Plus 年付方案每月 USD16 起(月付 USD20),Pro 100 年付方案每月 USD80 起(月付 USD100),Pro 200 年付方案每月 USD160 起(月付 USD200),Pro 500 年付方案每月 USD400 起(月付 USD500),每月包含 5,000 至 250,000 个 Flowi Tokens,并支持充值;每次节点运行消耗 1 个 token;不包含第三方 API 和模型使用费用。