starter 输入字段总对照表
把 8 个高频 starter 的首轮输入字段、必填项和推荐填写方式整理成一页可查手册。
这页解决的是一个很实际的问题:
“我已经选了 starter,第一轮到底该填哪些字段?”
它不是节点开发文档,而是给中文用户的 starter 填写手册。
怎么使用这页
建议分两步看:
- 先看下面这张总览表,判断你手上的任务更接近哪条 starter。
- 再跳到对应 starter 小节,照着字段表和推荐输入去填第一轮测试数据。
8 个高频 starter 总览
| starter | 典型用途 | 必填字段数量 | 第一轮最该先确认什么 |
|---|---|---|---|
single_step | 单次总结、提取、一次能力调用 | 1 | 主题字段能不能顺利产出一个稳定结果 |
approval_flow | 高风险动作前插审批 | 1 | 审批是不是停在正确位置 |
review_publish | 批准 / 返工双分支发布 | 1 到 3 | reviewApproved 两条支路是否都成立 |
failure_inbox | 成功交付、失败进 Inbox | 1 | 失败时是不是保留了足够上下文 |
daily_ai_brief | 简报、日报、研究摘要发送 | 4 到 6 | 搜索、摘要、review、发送这四段是否顺 |
browser_desktop_submission_audit | 浏览器提交 + 桌面取证 | 7 到 9 | 提交前审批、提交后证据链是否完整 |
product_image_batch | 3 个 item 并行商品图处理 | 15 | 批次公共字段和 item 字段有没有分清 |
ai_cutout_white_background | 抠图、白底图、干净素材输出 | 4 到 6 | 输入图、输出目录、命名规则是否明确 |
通用填写规则
- 第一轮尽量用测试目标,不要直接连真实生产系统。
- 能先填测试目录,就先填测试目录。
- 带审批的 starter,第一次更建议把
reviewApproved设成false,先确认停得住。 - 带文件路径的字段,尽量写成清楚、稳定、别人也看得懂的路径。
- 如果字段看起来很多,先分清“公共字段”和“单条 item 字段”,不要混着填。
高风险字段速查
这张表适合在真正点击运行前再扫一眼。
| 字段类型 | 典型字段 | 为什么风险高 | 填错后常见结果 | 更稳的首轮做法 |
|---|---|---|---|---|
| 审批开关 | reviewApproved | 它直接决定流程会不会继续往真实动作走 | 可能提前发送、提交、对外发布 | 第一轮先设成 false,先验证是否能正确停住 |
| 目标地址 | portalUrl、deliveryChannel | 它决定动作到底打到哪里 | 测试内容误发到真实渠道,或打开错误页面 | 先用测试地址、测试频道、测试群组 |
| 文件路径 | uploadFileRefs、sourceImageRefs、item1References 等 | 路径一错,节点就拿不到素材 | 上传失败、找不到图、生成空结果 | 先用本地可确认存在的测试文件 |
| 输出目录 | outputDirectory | 结果会落到这里 | 产物找不到、旧文件被混进来、交付混乱 | 给每轮测试单独建一个清楚目录 |
| 命名规则 | namingPattern | 它影响批量结果是否好找、会不会互相覆盖 | 文件名混乱、覆盖旧结果、后续难追踪 | 先用稳定模板,例如 SKU 或原图名加版本号 |
| 主题字段 | topic、briefTopic | 主题太散,后面节点都会散 | 输出空泛、摘要跑偏、审批人看不懂 | 第一轮只写一个非常窄的问题 |
| 批量 item 字段 | item1Sku、item1Prompt、item1References 等 | 批量里一项错,不一定拖垮整批,但会让结果变脏 | 某个 item 单独失败,或产出错图 | 先拿 3 个最简单 item 跑,不要第一轮就上复杂组合 |
字段风险等级怎么理解
- 低风险,填错通常只是结果不理想,不太会误伤外部系统。
- 中风险,填错会让流程卡住、跑偏,或者产物难以追踪。
- 高风险,填错可能会误发、误提交、误覆盖,或者直接影响真实外部系统。
single_step
适合第一次验证最短主干。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
topic | 是 | 低 | 作为本次单步处理的主题输入 | 写成一句明确任务,比如“整理这 5 条访谈的共性问题” | 写得太大、太空,会让 summary 变得很泛 |
推荐首轮输入:
{
"topic": "整理本周 5 条客户访谈,输出共性问题和建议"
}配套细页:
approval_flow
适合先搭审批骨架,再决定审批后真正要做什么。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
topic | 是 | 中 | 让 collect 节点先收集待审批内容 | 写成“给审批人看的交付草稿要围绕什么生成” | 只写一个很泛的目标,会让审批材料不成形 |
这条 starter 默认固定输入很少,重点在节点之间传递这些运行中字段:
| 运行中字段 | 来自哪里 | 后面给谁用 |
|---|---|---|
sourceData | collect 节点输出 | 给审批节点当 draft |
approvalDecision | approval 节点输出 | 给后续交付节点决定怎么收口 |
推荐首轮输入:
{
"topic": "整理待发布版本变更说明,生成给审批人确认的交付草稿"
}配套细页:
review_publish
适合发布前一定要分成“批准继续”和“返回修改”两路的场景。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
topic | 是 | 中 | 生成待发布草稿 | 写成明确的发布任务 | 任务描述不清,会让草稿和提交目标对不上 |
reviewApproved | 否,但强烈建议首轮就填 | 高 | 控制走提交还是返工 | 第一轮先设成 false,先验证返工支路 | 一上来设成 true,可能直接触发真实提交 |
reviewSummary | 否 | 中 | 记录审批意见或提交说明 | 写成一句人工审核结论 | 写得太空,review 节点虽然过了,但后面没人知道为什么通过 |
推荐首轮输入:
{
"topic": "发布 7 月产品更新说明,面向现有用户",
"reviewApproved": false,
"reviewSummary": "先检查标题、正文和发布对象,再决定是否提交"
}配套细页:
failure_inbox
适合定时任务、拉取任务和容易偶发失败但不能静默丢失的流程。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
topic | 是 | 中 | 说明这次任务原本要完成什么 | 写成别人一看就知道意图的任务描述 | 题目太抽象,失败进 Inbox 后也看不出这次到底想做什么 |
这条 starter 不需要你手填错误字段。失败时会把运行时错误自动带到 Inbox。
推荐首轮输入:
{
"topic": "读取今天的行业快讯源并整理成内部简报,失败则进入待处理 Inbox"
}配套细页:
daily_ai_brief
适合把研究、摘要、review、发送收成一条稳定简报流。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
briefTopic | 是 | 中 | 定义研究和简报主题 | 写窄一点,不要太发散 | 主题太大,会导致搜索和摘要都发散 |
sourceRefs | 是 | 中 | 限定搜索来源或材料范围 | 列出来源名、链接集合或资料清单 | 来源写得过杂,会让 citations 不稳定 |
deliveryChannel | 是 | 高 | 指定发到哪里 | 第一轮先填测试频道 | 填成真实群组或真实外发渠道,可能误发 |
scheduleHint | 否 | 低 | 提示发送节奏 | 可写每天、每周几、几点前 | 写得太模糊,对后续排期帮助不大 |
reviewSummary | 否 | 中 | 记录人工 review 关注点 | 写成一句验收提醒 | 留空时,review 容易只看“有没有内容”,不看“能不能发” |
reviewApproved | 是 | 高 | 决定是否允许真正发送 | 第一轮更建议先设成 false | 首轮直接设成 true,可能把测试简报发到真实渠道 |
推荐首轮输入:
{
"briefTopic": "AI Agent 产品本周融资、发布与行业动向",
"sourceRefs": "OpenAI Blog\nAnthropic Newsroom\nVercel Changelog\n重点媒体 RSS",
"deliveryChannel": "内部晨报测试频道",
"scheduleHint": "每个工作日上午 9:30 前发送",
"reviewSummary": "先确认摘要长度、引用格式和发送对象",
"reviewApproved": false
}配套细页:
browser_desktop_submission_audit
适合网页提交之后,还要补桌面侧证据链的高风险流程。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
portalUrl | 是 | 高 | 指定要打开的提交通道 | 先用测试地址 | 一旦写成真实地址,后面的填表和提交流都会落到真实系统 |
accountName | 是 | 高 | 标记浏览器里要用的账号上下文 | 写测试账号名称 | 测试时误用正式账号,风险很高 |
submissionTitle | 是 | 中 | 填表标题 | 写成明确提交标题 | 标题和任务不匹配,后面很难核对 proof |
submissionBody | 是 | 中 | 填表正文 | 先用测试正文 | 直接贴正式内容,容易和测试流程混在一起 |
uploadFileRefs | 是 | 高 | 要上传的文件清单 | 推荐一行一个文件路径 | 文件不存在、路径写错、传错版本,最容易卡住上传节点 |
desktopAppName | 是 | 中 | 提交后要去取证的桌面应用 | 写开发版或测试版名称 | 应用名不准,会导致桌面取证节点找不到目标窗口 |
desktopEvidenceZone | 否 | 中 | 说明桌面上要观察哪里 | 比如通知中心、下载目录、状态栏 | 写得太笼统,后续取证截图不一定拍到关键位置 |
reviewSummary | 否 | 中 | 供审批或 review 记录 | 写当前检查重点 | 不写 review 重点,审批人很难知道这轮在检查什么 |
reviewApproved | 是 | 高 | 决定是否真的点击提交 | 第一轮更建议先设成 false | 一旦首轮就设成 true,最容易直接误提交 |
推荐首轮输入:
{
"portalUrl": "https://example.com/submit",
"accountName": "Raydo Ops Test Account",
"submissionTitle": "Raydo Desktop 功能演示素材提交通知",
"submissionBody": "本次提交用于验证浏览器提交流程和桌面取证链路。",
"uploadFileRefs": "/Users/AVIVA/Desktop/demo-cover.png\n/Users/AVIVA/Desktop/demo-script.pdf",
"desktopAppName": "Raydo Desktop Dev",
"desktopEvidenceZone": "提交完成后的通知中心与下载目录",
"reviewSummary": "先检查字段填写、附件上传和提交按钮状态",
"reviewApproved": false
}配套细页:
product_image_batch
适合已经明确要并行处理 3 个 item 的商品图场景。
批次公共字段
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
batchName | 是 | 低 | 标识这整批任务 | 用发布名、活动名或日期批次名 | 名字太随意,后面很难追踪是哪一批 |
outputDirectory | 是 | 高 | 指定整批输出目录 | 先用单独测试目录 | 和旧批次共用目录,最容易把结果混在一起 |
namingPattern | 是 | 高 | 统一命名规则 | 用稳定模板,不要临时乱写 | 模板不稳定,容易覆盖旧图或者命名混乱 |
generationPrompt | 是 | 中 | 整批共用的生成风格要求 | 写风格、构图、用途 | 写得太满,会和 item 自己的 prompt 打架 |
negativePrompt | 是 | 中 | 整批共用的避雷要求 | 写不要出现什么 | 写得太泛,起不到约束作用 |
qualityChecklist | 是 | 中 | 整批共用验收标准 | 写 3 到 5 条最关键标准 | 标准太多太散,第一轮反而没法判断结果好坏 |
每个 item 字段
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
item1Sku / item2Sku / item3Sku | 是 | 中 | 区分每个商品项 | 用真实 SKU 或稳定测试 SKU | SKU 命名乱,最后交付不好对号入座 |
item1Prompt / item2Prompt / item3Prompt | 是 | 中 | 每个 item 的个性化描述 | 写该 item 自己的卖点与画面要求 | 3 个 item prompt 写得几乎一样,跑出来没区分度 |
item1References / item2References / item3References | 是 | 高 | 每个 item 的参考图数组 | 每个 item 至少放 1 张有效参考图 | 最常见的问题就是某个 item 的参考图失效或放错商品 |
推荐首轮输入:
{
"batchName": "summer-drop-01",
"outputDirectory": "/Users/AVIVA/Desktop/raydo-image-batch",
"namingPattern": "{sku}_main_v1",
"generationPrompt": "统一输出电商主图风格,干净背景,主体居中,适合商品详情页首图",
"negativePrompt": "不要多余道具,不要文字水印,不要复杂背景",
"qualityChecklist": "主体完整;边缘干净;光线统一;比例适合电商主图",
"item1Sku": "RD-TSHIRT-BLK-M",
"item1Prompt": "黑色基础 T 恤平铺主图,突出面料和版型",
"item1References": [
"/Users/AVIVA/Desktop/refs/tshirt-front.png"
],
"item2Sku": "RD-HOODIE-GRY-L",
"item2Prompt": "灰色连帽卫衣主图,保留帽绳和口袋细节",
"item2References": [
"/Users/AVIVA/Desktop/refs/hoodie-front.png"
],
"item3Sku": "RD-CAP-WHT",
"item3Prompt": "白色棒球帽主图,突出帽檐和 logo 区域",
"item3References": [
"/Users/AVIVA/Desktop/refs/cap-front.png"
]
}配套细页:
ai_cutout_white_background
适合目标单一的图片处理场景,尤其是白底图和抠图交付。
| 字段 | 是否必填 | 风险等级 | 用来做什么 | 推荐首轮写法 | 容易填错的地方 |
|---|---|---|---|---|---|
sourceImageRefs | 是 | 高 | 指向待处理原图 | 先用 1 张最典型原图 | 路径失效或给错图片,会直接导致整个 cutout 结果不对 |
prompt | 是 | 中 | 描述抠图和清理要求 | 写边缘、阴影、背景要求 | 要求写得太多,反而把抠图任务写成复杂修图任务 |
backgroundMode | 是 | 中 | 指定背景模式 | 第一轮常见写 white | 白底、透明底、场景底写混,会让结果与预期相反 |
outputDirectory | 是 | 高 | 指定输出目录 | 先用独立测试目录 | 和旧结果共用目录,会让交付和验收很乱 |
namingPattern | 否 | 中 | 指定结果命名规则 | 用原图名 + 版本后缀 | 命名规则太随意,后面不好找结果 |
qualityChecklist | 否 | 低 | 补充验收标准 | 写主体完整、边缘干净这类标准 | 写成很长一段空话,对验收没帮助 |
推荐首轮输入:
{
"sourceImageRefs": "/Users/AVIVA/Desktop/raw/product-001.png",
"prompt": "保留商品主体边缘与真实阴影,输出适合电商平台使用的干净白底图",
"backgroundMode": "white",
"outputDirectory": "/Users/AVIVA/Desktop/raydo-cutout-output",
"namingPattern": "{original_name}_white_bg_v1",
"qualityChecklist": "主体完整;边缘不毛糙;白底干净;不要误删细小配件"
}配套细页:
如果你还是不知道该填什么
先不要补更多字段,先反过来问自己三件事:
- 这次任务的单一目标是什么?
- 第一轮到底要不要碰真实外部系统?
- 我现在缺的是“主题 / 素材 / 目标地址 / 审批开关”里的哪一个?
大多数 starter 第一轮跑不通,不是因为字段太少,而是因为:
- 主题写得太散
- 输入文件路径不清楚
- 一开始就接了真实目标
- 审批和提交一起上,没先拆开验证
如果你只是想快速自查,优先看这四类高风险字段:
reviewApproved- 各类路径字段,例如
uploadFileRefs、sourceImageRefs - 各类真实目标字段,例如
portalUrl、deliveryChannel - 各类输出收口字段,例如
outputDirectory、namingPattern