RaydoRaydo Book

starter 输入字段总对照表

把 8 个高频 starter 的首轮输入字段、必填项和推荐填写方式整理成一页可查手册。

这页解决的是一个很实际的问题:

“我已经选了 starter,第一轮到底该填哪些字段?”

它不是节点开发文档,而是给中文用户的 starter 填写手册。

怎么使用这页

建议分两步看:

  1. 先看下面这张总览表,判断你手上的任务更接近哪条 starter。
  2. 再跳到对应 starter 小节,照着字段表和推荐输入去填第一轮测试数据。

8 个高频 starter 总览

starter典型用途必填字段数量第一轮最该先确认什么
single_step单次总结、提取、一次能力调用1主题字段能不能顺利产出一个稳定结果
approval_flow高风险动作前插审批1审批是不是停在正确位置
review_publish批准 / 返工双分支发布1 到 3reviewApproved 两条支路是否都成立
failure_inbox成功交付、失败进 Inbox1失败时是不是保留了足够上下文
daily_ai_brief简报、日报、研究摘要发送4 到 6搜索、摘要、review、发送这四段是否顺
browser_desktop_submission_audit浏览器提交 + 桌面取证7 到 9提交前审批、提交后证据链是否完整
product_image_batch3 个 item 并行商品图处理15批次公共字段和 item 字段有没有分清
ai_cutout_white_background抠图、白底图、干净素材输出4 到 6输入图、输出目录、命名规则是否明确

通用填写规则

  • 第一轮尽量用测试目标,不要直接连真实生产系统。
  • 能先填测试目录,就先填测试目录。
  • 带审批的 starter,第一次更建议把 reviewApproved 设成 false,先确认停得住。
  • 带文件路径的字段,尽量写成清楚、稳定、别人也看得懂的路径。
  • 如果字段看起来很多,先分清“公共字段”和“单条 item 字段”,不要混着填。

高风险字段速查

这张表适合在真正点击运行前再扫一眼。

字段类型典型字段为什么风险高填错后常见结果更稳的首轮做法
审批开关reviewApproved它直接决定流程会不会继续往真实动作走可能提前发送、提交、对外发布第一轮先设成 false,先验证是否能正确停住
目标地址portalUrldeliveryChannel它决定动作到底打到哪里测试内容误发到真实渠道,或打开错误页面先用测试地址、测试频道、测试群组
文件路径uploadFileRefssourceImageRefsitem1References路径一错,节点就拿不到素材上传失败、找不到图、生成空结果先用本地可确认存在的测试文件
输出目录outputDirectory结果会落到这里产物找不到、旧文件被混进来、交付混乱给每轮测试单独建一个清楚目录
命名规则namingPattern它影响批量结果是否好找、会不会互相覆盖文件名混乱、覆盖旧结果、后续难追踪先用稳定模板,例如 SKU 或原图名加版本号
主题字段topicbriefTopic主题太散,后面节点都会散输出空泛、摘要跑偏、审批人看不懂第一轮只写一个非常窄的问题
批量 item 字段item1Skuitem1Promptitem1References批量里一项错,不一定拖垮整批,但会让结果变脏某个 item 单独失败,或产出错图先拿 3 个最简单 item 跑,不要第一轮就上复杂组合

字段风险等级怎么理解

  • 低风险,填错通常只是结果不理想,不太会误伤外部系统。
  • 中风险,填错会让流程卡住、跑偏,或者产物难以追踪。
  • 高风险,填错可能会误发、误提交、误覆盖,或者直接影响真实外部系统。

single_step

适合第一次验证最短主干。

字段是否必填风险等级用来做什么推荐首轮写法容易填错的地方
topic作为本次单步处理的主题输入写成一句明确任务,比如“整理这 5 条访谈的共性问题”写得太大、太空,会让 summary 变得很泛

推荐首轮输入:

{
  "topic": "整理本周 5 条客户访谈,输出共性问题和建议"
}

配套细页:

approval_flow

适合先搭审批骨架,再决定审批后真正要做什么。

字段是否必填风险等级用来做什么推荐首轮写法容易填错的地方
topic让 collect 节点先收集待审批内容写成“给审批人看的交付草稿要围绕什么生成”只写一个很泛的目标,会让审批材料不成形

这条 starter 默认固定输入很少,重点在节点之间传递这些运行中字段:

运行中字段来自哪里后面给谁用
sourceDatacollect 节点输出给审批节点当 draft
approvalDecisionapproval 节点输出给后续交付节点决定怎么收口

推荐首轮输入:

{
  "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 或稳定测试 SKUSKU 命名乱,最后交付不好对号入座
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": "主体完整;边缘不毛糙;白底干净;不要误删细小配件"
}

配套细页:

如果你还是不知道该填什么

先不要补更多字段,先反过来问自己三件事:

  1. 这次任务的单一目标是什么?
  2. 第一轮到底要不要碰真实外部系统?
  3. 我现在缺的是“主题 / 素材 / 目标地址 / 审批开关”里的哪一个?

大多数 starter 第一轮跑不通,不是因为字段太少,而是因为:

  • 主题写得太散
  • 输入文件路径不清楚
  • 一开始就接了真实目标
  • 审批和提交一起上,没先拆开验证

如果你只是想快速自查,优先看这四类高风险字段:

  • reviewApproved
  • 各类路径字段,例如 uploadFileRefssourceImageRefs
  • 各类真实目标字段,例如 portalUrldeliveryChannel
  • 各类输出收口字段,例如 outputDirectorynamingPattern

配套阅读