官方 Hub 模板示例

这页不是再讲一遍规范。

这页直接给你样板。

也就是说，如果你已经看过：

• Hub 发布前检查表 / 发布规范
• Hub 模板说明书写法 / 模板描述规范

那这页回答的是最后一个问题：

真正写出来，长什么样。

这页怎么用

下面挑的是 5 条已经有文档基础、也比较适合做 Hub 示范的 starter：

• single_step
• daily_ai_brief
• browser_desktop_submission_audit
• ai_cutout_white_background
• product_image_batch

你可以把它们理解成 5 种不同类型的标准写法：

• 最短主干型
• 研究与发送型
• 高风险浏览器提交型
• 单图图片处理型
• 批量图片处理型

如果你后面要发 Hub，最简单的用法就是：

找一条最接近你场景的，照着改。

示例 1：single_step

标题

单步内容处理与交付

一句话摘要

把一个明确主题交给单个能力节点处理，并把结果交付到指定位置，适合第一次验证最短 workflow 主干。

适合谁

• 第一次接触 workflow 的用户
• 只想验证一个 capability 能不能接通的人
• 做一次性总结、提取、转换短任务的人

不适合谁

• 需要审批的人
• 需要成功 / 失败分叉的人
• 需要浏览器提交或外部写入的人

输入字段说明

输出与交付

• 最终输出：单次能力处理结果，如摘要、提取文本或结构化内容
• 默认交付：delivery 节点指向的测试目录或测试目标
• 中间产物：节点运行回执

风险与审批提示

• 这条模板默认更适合低风险只读或轻处理任务
• 如果你要接外部发送、提交、写回，建议先换成更合适的 starter

首次使用建议

1. 先只改中间 capability，不先改整体结构
2. 用最小测试输入跑通 Goal → Capability → Delivery
3. 输出稳定后，再决定是否升级成更复杂模板

可以安全修改的地方

• 中间 capability
• topic 字段提示
• 最终 delivery 目标

不建议随便修改的地方

• 主干顺序
• 在第一轮就加很多审批和分叉

示例 2：daily_ai_brief

标题

每日 AI 简报生成与复核

一句话摘要

围绕一个固定主题收集来源、生成简报、保留 review，并在确认后发送到指定渠道，适合日报、周报和研究摘要分发。

适合谁

• 做 AI 晨报、周报、市场观察的人
• 需要“研究后再发送”的内容团队
• 已经知道固定发送渠道的团队

不适合谁

• 需要长篇深度研究而不是短简报的人
• 根本不需要发送的人
• 研究主题还非常发散的人

输入字段说明

输出与交付

• 最终输出：一份结构化简报
• 中间产物：搜索摘要、引用、review 结论、send receipt
• 默认交付：测试发送渠道

风险与审批提示

• 不建议第一轮直连真实发送渠道
• 建议保留 review，不要一上来删除
• 如果简报会对外发送，review 应该保留为正式收口

首次使用建议

1. 先用一个窄主题跑通 Search → Brief
2. 确认 review 能看懂摘要和引用
3. 最后再接真实发送渠道

可以安全修改的地方

• briefTopic
• sourceRefs
• deliveryChannel
• scheduleHint
• reviewSummary

不建议随便修改的地方

• Search → Brief → Review → Send 四段主干
• 引用保留逻辑
• review 阶段的位置

示例 3：browser_desktop_submission_audit

标题

浏览器提交前审核与桌面留痕

一句话摘要

在浏览器里完成填写、上传和提交前复核，提交后补浏览器 proof 与桌面证据，适合高风险表单提交和审计留痕场景。

适合谁

• 需要浏览器提交的人
• 提交后还要保留审计证据的人
• 跨网页和桌面系统联动的人

不适合谁

• 只是做普通内容草稿的人
• 没有真实提交动作的人
• 不需要证据链的人

输入字段说明

输出与交付

• 最终输出：提交 receipt、browser proof、desktop evidence
• 中间产物：字段填写回执、上传回执、review 结论
• 默认交付：测试留痕目录或测试归档位置

风险与审批提示

• 这是高风险模板，审批不建议移到 submit 之后
• 第一次试跑不要直点真实提交
• 如果页面状态不稳定，先查 proof 和真实状态，不要整条重跑

首次使用建议

1. 第一轮只验证打开、填写、上传
2. 第二轮验证 review 是否停在正确位置
3. 第三轮再测试真实 submit、browser proof 和 desktop evidence

可以安全修改的地方

• portalUrl
• 表单字段内容
• 上传文件清单
• 桌面证据区域说明

不建议随便修改的地方

• Open → Fill → Upload → Review → Submit → Browser proof → Desktop evidence 主干
• 审批前后顺序
• proof / evidence 节点

示例 4：ai_cutout_white_background

标题

商品图白底抠图与交付

一句话摘要

把一张或少量商品图做去背与白底清理，并按命名规则交付到指定目录，适合电商主图和干净商品素材输出。

适合谁

• 做商品抠图和白底图的人
• 想快速验证图片处理和交付链路的人
• 需要干净商品素材的电商团队

不适合谁

• 想做复杂风格出图的人
• 想一条流程里同时做抠图、审批、发布的人
• 想把它直接改成长链路内容生产线的人

输入字段说明

输出与交付

• 最终输出：白底图或透明底图
• 中间产物：artifact path、preview URI、处理回执
• 默认交付：测试图片输出目录

风险与审批提示

• 这条模板风险相对低，但仍建议先核对输出目录
• 如果后面要接发布或批量处理，建议拆到更合适的模板里完成

首次使用建议

1. 先用一张最典型商品图跑一轮
2. 确认 cutout 结果、artifact path、preview URI 正常
3. 再决定是否接 review 或批量流程

可以安全修改的地方

• sourceImageRefs
• prompt
• backgroundMode
• outputDirectory
• namingPattern

不建议随便修改的地方

• Prepare brief → Cutout → Deliver 主干
• 把 delivery 当成结果修正节点

示例 5：product_image_batch

标题

批量商品图处理与分项交付

一句话摘要

把多个商品 item 按统一规则并行处理、分别交付，并最终汇总批次 receipt，适合 SKU 图清洗、商品图批量生成和分项落盘场景。

适合谁

• 批量商品图处理的人
• SKU 图清洗和变体图处理的人
• 想先验证多 item 并行骨架的人

不适合谁

• 只做单张图的人
• 还没想清命名规则和输出目录的人
• 想一上来改成完全不同媒体流的人

输入字段说明

输出与交付

• 最终输出：每个 item 独立结果 + 整批汇总 receipt
• 中间产物：每个 item 的生成结果、分项 delivery 回执
• 默认交付：测试批量目录

风险与审批提示

• 这条模板最大的风险不是“出不出图”，而是命名、目录和单 item 失败处理
• 如果你不需要 batch，不要硬把它改成单图模板

首次使用建议

1. 先用 3 个最简单 item 跑一次
2. 确认每个 item 都有独立结果和交付回执
3. 确认单个 item 失败时，不会把整批一起拖垮

可以安全修改的地方

• batchName
• outputDirectory
• namingPattern
• 每个 item 的 prompt 和 references

不建议随便修改的地方

• 并行骨架
• 分项 delivery 逻辑
• 汇总 receipt 的收口方式

怎么把这页当成内部样板库

后面你们只要做两件事，这页就会很实用：

1. 新发一个 Hub 模板前，先在这里找最像的一条
2. 按它的标题、摘要、字段说明、风险提示结构去改

这会比每次从空白说明书开始写，稳很多。

配套阅读

• Hub 模板说明书写法 / 模板描述规范
• Hub 发布前检查表 / 发布规范
• workflow 模板 / starter catalog

常见问题