Appearance
表格发起任务，群聊接收通知
飞书多维表 · 任务入口
顺序商品提示词负责人
- 生图
- ZIP 归档
- 回写状态
机器人通知负责人任务结果 · 本地产物路径
单次执行 / 按需开启轮询
它解决什么问题
把表格中的生图需求与本地执行衔接起来，减少逐项调用服务、整理图片、更新进度和通知负责人的重复操作。
适合谁使用
希望用飞书多维表管理商品生图任务、查看执行状态，并接收完成通知的电商运营人员。
它如何工作
录入任务
在表格中记录任务 ID、顺序号、商品名称、提示词与负责人，将任务状态设为待处理，作为本地工作流的统一入口。
- 输入
- 商品名称、生图提示词与负责人
- 产出
- 飞书多维表中的待处理记录
任务图片示例
这两张图片取自工作流已经保存的商品测试任务目录，分别展示手机宣传图与笔记本桌面场景。用户可以先看到图片输出的形式，再了解它如何从任务表进入生成、归档和通知流程。
手机商品场景图查看大图 ↗
商品主体、山景背景和英文标题组合成一张方形宣传图。可以直观看到生图任务最终保存的图片形式。
笔记本桌面场景图查看大图 ↗
围绕商品组织桌面、光线与配件，形成另一种商品展示场景。图片按任务归档后，可进入后续选图与使用环节。
这里展示的是图片产物。多维表状态、ZIP 归档和机器人通知的处理方式见下方说明；本次维护没有重新调用图片接口或运行飞书任务。具体商品细节仍需在使用图片前对照实物资料复核。
使用方式
这是一套以飞书多维表为任务入口、在本地执行的电商生图工作流。表格记录商品名称、生图提示词、负责人、任务顺序和状态，本地程序读取可执行任务，调用图片服务、整理产物，再把进度与结果写回表格。
首次使用需要配置飞书应用、目标多维表、群机器人和所选图片服务。默认使用 Mock 图片联调，先验证读表、状态回写、ZIP 归档和通知链路，再切换到真实生图接口。
可以单次执行，也可以明确开启自动轮询，按配置间隔扫描任务。自动轮询默认关闭；本地同一轮询进程会避免批次重叠，正在执行的一批完成后才能开始下一批。
表格驱动的执行过程
普通批次只读取「待处理」和「失败待重试」记录，按任务顺序号依次执行。生成过程中，表格会更新为排队中、生成中、打包中和发送中，便于查看当前进度。
图片按任务 ID 保存到本地目录，同时生成对应 ZIP 文件。机器人通知包含任务结果、本地产物路径，并提及负责人；通知发送完成后，任务标记为已完成。ZIP 留在运行机器上，团队领取产物时需要可访问的文件共享方式。
异常与人工重跑
某个任务执行失败时，表格写入「失败待重试」与错误说明，后续扫描可以再次处理。已完成任务不进入普通批次；如需重新制作，通过人工重跑入口明确确认后，先重置该记录，再执行一次待处理批次。
任务队列、生图服务、归档和飞书通知分别由独立模块处理。这种结构便于先用模拟图片验证链路，再替换为真实服务，也便于根据运行状态定位问题。
可以带走什么
主要产物是按任务归档的图片与 ZIP，以及多维表里的进度、产物路径和失败备注。机器人通知把任务结果交给负责人查看，减少完成后再逐项手动更新表格和发送提醒的操作。
项目还提供 Mock ERP 运营日报示例：用模拟的销售、订单、广告花费等数据生成 CSV，并通过飞书发送摘要与文件路径。这部分用于验证报表与通知流程，当前数据来源是本地模拟数据。
当前范围
当前版本是 MVP，重点验证「飞书任务 → 图片生成 → 本地归档 → 状态与通知」的完整链路。真实生图使用商品名称与提示词发起生成请求，按接口实际返回的图片归档；表格中的图片数量字段用于 Mock 联调，真实多张生成仍需扩展。
它与电商模板生图工作流分别解决两个环节：模板工作流负责版式复用与产品复核，飞书工作流负责任务执行、归档和通知。两者目前作为独立作品展示。
技术实现：Node.js + TypeScript，飞书多维表 API、群机器人、OpenAI 兼容图片接口和 ZIP 归档。