workflow 模板 / starter catalog
基于桌面端真实 starter 模板，整理哪些适合直接起步，哪些适合二次改造。
这章不是在讲抽象方法论，而是在讲一个更实用的问题：
“如果我不想从空白画布开始，哪些 starter 值得直接拿来改？”
先理解 starter 的定位
starter 不是“最终成品”。
它更像一套已经替你搭好的骨架，帮你少走这几步：
- 想主干顺序
- 想审批位置
- 想交付收口
- 想失败后怎么分叉
真正上线前，你还是要把输入字段、目标系统、交付对象和审批边界改成你自己的。
先按“选型手册”方式往下读
如果你不想直接从一张大表里自己判断，可以先走这三条更快的入口：
按任务目标选 starter
研究、内容生产、浏览器提交、业务运营分别优先看哪些 starter。
按风险与审批需求选 starter
先看会不会改外部世界状态，再决定要不要优先选带审批骨架的 starter。
按改造难度选 starter
哪些适合直接改，哪些更适合拿来参考结构。
starter 输入字段总对照表
把 8 个高频 starter 的必填字段、推荐写法和首轮测试输入放在一页里查。
高频 starter 细页
逐个看 starter 适合谁、不适合谁、改哪里最安全。
从空白画布 vs 从 starter 起步
当你不确定该不该直接套模板时，用这页先做判断。
最推荐先看的几类 starter
一，基础控制型
适合先学 workflow 结构，而不是先学复杂业务。
| starter | 更适合什么任务 | 你会得到什么骨架 |
|---|---|---|
single_step | 单次提取、总结、一次能力调用 | Goal → Capability → Delivery |
approval_flow | 高风险动作前要人工确认 | Goal → Collect → Approve → Deliver |
review_publish | 发布前必须分成批准 / 返工两路 | Draft → Condition → Submit / Revise |
failure_inbox | 成功走交付，失败走待处理 | Run → Success? → Deliver / Inbox |
artifact_output | 先包装成成果物，再交付 | Goal → Source → Package → Deliver |
app_capsule_delivery | 需要预览壳、交付壳、结果壳 | Source → Capsule → Preview → Deliver |
二，图片与内容生产型
适合内容团队、电商团队、素材加工场景。
| starter | 更适合什么任务 | 典型主干 |
|---|---|---|
product_image_batch | 批量商品图处理 | Source → Manifest → Generate x3 → Deliver |
ai_cutout_white_background | 抠图、白底图、干净素材输出 | Source → Brief → Cutout → Deliver |
fashion_product_try_on | 服饰上身图、模特试穿图 | Source → Brief → Prompt → Generate → Review → Deliver |
xiaohongshu_publish | 小红书内容准备与提交流 | Source → Copy → Review → Submit |
shopify_product_launch | 商品上架、文案和草稿准备 | Source → Copy → Review → Submit |
三，研究与知识型
适合研究、知识库刷新、团队日报和摘要分发。
| starter | 更适合什么任务 | 典型主干 |
|---|---|---|
daily_ai_brief | 日报、简报、市场观察 | Search → Brief → Review → Send |
customer_knowledge_update | 更新知识库并验证回答 | Source → Refresh → Test → Deliver |
四，业务运营型
适合要跨系统流转、需要审批、需要写回记录的任务。
| starter | 更适合什么任务 | 典型主干 |
|---|---|---|
sales_follow_up | 销售跟进、外联、表格更新 | Leads → Copy → Review → Send |
campaign_launch_pack | 活动发布、素材与记录联动 | Research → Creative → Review → Publish → Record |
customer_onboarding_pack | 客户 onboarding 交付包 | Context → Policy → Plan → Review → Kickoff |
support_escalation_resolution | 客服升级工单处理 | Tickets → Policy → Reply → Review → Record |
browser_desktop_submission_audit | 浏览器提交加桌面侧取证 | Open → Fill → Upload → Review → Desktop → Deliver |
怎么选 starter，最不容易选错
先问自己三个问题：
- 这条流程的主目标是什么？
- 会不会改外部世界状态？
- 我是更缺“主干顺序”，还是更缺“业务内容”？
如果你：
- 只是想先跑通结构，先从基础控制型选；
- 主要做图片、视频、内容，先从图片与内容生产型选；
- 主要做研究、知识、日报，先从研究与知识型选；
- 主要做跨系统提交、发送、记录，先从业务运营型选。
如果你想更快做出判断，可以继续看：
哪些 starter 最适合直接改
最适合直接拿来改的，通常是这些：
single_stepapproval_flowreview_publishfailure_inboxdaily_ai_briefbrowser_desktop_submission_audit
原因很简单，它们的主干很清楚，后续换输入、换目标、换交付对象都相对容易。
哪些 starter 更适合“参考结构，不建议直接硬改”
这些更像场景样板，不是纯骨架：
fashion_product_try_onproduct_image_batchxiaohongshu_publishshopify_product_launchcampaign_launch_packcustomer_onboarding_pack
它们很有参考价值，但如果你的业务差别很大，直接硬改反而容易越改越乱。
第一次用 starter 的正确姿势
先按主目标选一条最接近的 starter，不要贪多。
先保留原有主干，只改输入、输出和交付对象。
第一轮先用测试数据验证结构，不要立刻上真实系统。
确认审批位置正确后，再接真实外部动作。
跑稳以后，再决定要不要升成 WorkPack。