步骤 1
先只讲目标，不急着讲实现
例如：“我想把每周项目例会后的信息整理成可执行的跟进流。” 先讲结果，OpenClaw 才能帮你判断这是不是一个 workflow。
Chapter 09
复杂任务编排
真正高价值的任务，很少是一句话直接生成结果，更像一条流水线：触发、取数、整理、判断、回写、提醒。OpenClaw 的高级用法，不是你预先把所有步骤写死，而是让它和你一起把这条流水线设计出来。
本章最重要的提醒
workflow 和 pipeline 不是固定模板，更不是每次都要你先自己写完。更有效的方式通常是：先把目标讲给 OpenClaw，让它先帮你拆、帮你画、帮你指出缺什么上下文，再由你确认和收敛。
先记住这张五段式画布
1. 触发
这件事是由对话发起、定时发起、周期巡查发起，还是由 webhook 事件发起。
2. 输入
需要读哪些真实资料。飞书官方文档支持的重点输入包括消息、云文档、多维表格、日历、任务。
3. 处理
把信息变成结构化结论，例如摘要、排序、标签、行动项、风险点。
4. 输出
结果是发回聊天、写回文档、更新多维表格、创建任务，还是只做预览等待确认。
5. 审核与复盘
哪些地方要人工确认，哪些结果可以自动推进，哪些做法值得沉淀成 skill 或稳定流程。
步骤 2
让它先画流程图
要求它先列出触发、输入、处理、输出、审核五段，而不是立刻开始写结果。这样你们是在一起设计，而不是你单方面命令。
步骤 3
再补上下文缺口
如果它指出缺飞书文档、缺历史记录、缺负责人规则，就先补这些上下文，而不是硬往下做。
步骤 4
把“写回哪里”说清楚
复杂工作流的关键不是“分析对不对”，而是结果能不能真正进入飞书文档、多维表格、任务或消息流。
步骤 5
最后才决定哪些自动、哪些人工
先看风险，再决定是否自动推进。涉及发消息、改文档、建任务、对外通知时，优先走“先预览，再确认”。
先选触发方式，再谈细节
| 触发方式 | 适合问题 | 典型场景 |
|---|---|---|
| 对话 | “现在帮我做” | 探索型任务、一次性任务、先共创流程 |
| Cron | “到这个时间就做” | 周报、日报、固定汇总、定时整理 |
| Heartbeat | “定期检查一次有没有新情况” | 进度巡查、状态扫描、异常提醒 |
| Webhook | “外部事件发生就做” | 新文件上传、新表单提交、新线索进入系统 |
案例 A：音频处理自动化
目标
把飞书群或飞书文档中的音频附件，自动整理成文字摘要、行动项和后续提醒。
为什么清晰
它的触发、输入、输出都非常明确：有音频文件进来，变成结构化文字，再回写到飞书。
| 环节 | 动作 |
|---|---|
| 触发 | 新音频文件上传到飞书文档或群文件 |
| 输入 | 音频文件、相关会议背景、项目页面 |
| 处理 | 转录文字，提炼摘要、行动项、风险、待确认问题 |
| 输出 | 写回飞书文档，必要时创建任务或发送消息提醒 |
| 审核 | 涉及对外发送或敏感结论时先人工确认 |
案例 B：团队项目推进自动整理
目标
把飞书里的会议纪要、任务状态、多维表格和日历安排连起来，自动形成项目推进视图。
适合谁
适合管理者、产品、软件、硬件、设计团队做跨职能推进，尤其适合每周例会、版本推进和评审后的跟进。
请先不要执行，先帮我把“项目推进自动整理”画成一个 workflow。
要求：
1. 先写触发方式：对话 / cron / heartbeat / webhook
2. 再写需要读取的飞书资料：文档、任务、多维表格、日历、群聊
3. 再写处理步骤：提炼、归类、排序、补充提醒
4. 最后写输出：写回哪里、谁来确认、哪些自动推进
你可以直接这样和 OpenClaw 共创 pipeline
我有一个复杂任务，但我不想先把流程写死。请你先和我一起设计 workflow。
目标：
[最后要得到什么结果]
请先输出：
1. 触发方式
2. 需要读取的资料
3. 中间处理步骤
4. 输出位置
5. 需要人工确认的节点
6. 可能缺失的上下文
等我确认后，再开始执行。
这一段不是“高级 prompt 技巧”，而是一种更好的默认习惯：复杂任务先共创流程，再执行流程。
什么时候考虑更确定的 workflow 壳
如果你的流程需要固定步骤、审批节点和中断恢复，就可以再考虑更确定的工作流外壳，例如 Lobster 这一类 typed workflow runtime。普通对话适合共创和探索，确定性工作流适合把成熟流程锁定下来。