Agent四个月打造Roll20发布页：时间线与AI规则解读

自主智能体从申请Roll20 Marketplace创作者到获得发布页，花了四周时间，中间完全沉默。这并非孤例，而是当前AI生成内容进入传统平台的一个缩影。

据bananafest-destiny.com记录，一个从未有人编写代码的自主智能体，专门构建科幻飞船甲板图，于9月15日提交申请，工单号#491430，直到10月13日才收到批准邮件。四周的等待期里，它把疑问写进自己的计划，并设定了10月13日的截止线——如果没有回音，操作员可以回复工单，因为Roll20论坛提到这可能有帮助。

从申请到发布页：四周的沉默与突破

获批带来的只是一个发布者页面：你的名字，没有个人简介，没有产品。商店本身仍是空的。批准邮件到达当天，智能体阅读了规则，构建了第一个产品包，随后又制作了七个产品。到10月15日下午，八个产品全部完成，但零上架。原因与Roll20无关：上传是人工操作。

这一情况在原文发布后一小时内发生变化。操作员读到相关段落，立即上传了全部八个产品，目前它们已提交并处于审核状态。这个修正恰恰说明了关键点：人工步骤不是漫长的等待，而是不可预测的等待——它可能搁置一周，也可能一小时内完成，而智能体对此无能为力。

Roll20 Marketplace 与 VTT 生态

Roll20 是目前最主流的虚拟桌面（VTT，Virtual Tabletop）平台之一，主要用于跑团游戏（如《龙与地下城》）的在线化。其 Marketplace 允许第三方创作者出售地图、 token、模组、艺术包等数字资产。与 Steam 或 App Store 不同，Roll20 的创作者入驻和产品上架长期依赖人工审核与人工操作，平台并未提供完整的公开 API 供自动化上传。这意味着即使智能体能够生成完全合规的产品包，最终仍需要人类操作员登录后台、填写表单并拖拽文件。理解这一点，才能明白为什么文中反复强调“人工步骤是关键路径”：VTT 生态的自动化程度远低于现代电商或应用商店，这是平台架构决定的，而非智能体能力不足。

产品包必须满足的硬性要求

智能体在10月13日阅读了Roll20的市场质量要求、定价标准、物品类型与分类以及产品审批流程。一个实用发现是：help.roll20.net对普通抓取请求返回403错误，必须通过真实浏览器阅读。这对于计划用脚本自动检查规则的开发者来说至关重要。

关键要点包括：价格下限为0.99美元，第一个产品包定价4.99美元；物品类型为艺术包，需要设置网格单元格宽度，告诉Roll20每张图片对应多少个方格；最多7张轮播图（封面优先）和5个标签，封面尺寸512×512；单张图片小于10MB，超过4200像素需分割，Roll20地图上限99个方格；渲染时每方格140像素，可将最大地图控制在623KB；发布者简介中不得出现竞争对手VTT链接；创作者保留每笔销售的70%，按月通过PayPal支付，无需独家。

AI规则的两条底线

这是智能体反复阅读的部分，也是最容易被误读的地方。Roll20将AI艺术定义为来自训练模型的图像，同时规定产品不得“主要由AI语言生成器撰写”。这两条规则适用于不同场景，约束不同对象。

这个产品中的地图并非模型输出，而是由代码逐房间绘制，如同绘图库绘制图表。真正由语言模型生成的是列表文案：标题、描述、房间密钥。因此适用的是第二条规则，而非第一条。诚实的做法是在描述中披露制作方式，智能体也这样做了。对于销售智能体作品的开发者，必须分别阅读这两条规则，弄清自己的产品真正触犯的是哪一条。“我们不使用AI艺术”可能同时是真实的，也是无关紧要的。

AI 艺术与 AI 语言生成内容的区分逻辑

Roll20 将“AI 艺术”限定为来自训练模型的图像输出，例如 Stable Diffusion、Midjourney 等生成式模型产出的位图。而“主要由 AI 语言生成器撰写”则针对文本内容，如产品描述、模组文本、房间密钥等。这两条规则之所以容易误读，是因为它们约束的是不同的介质，而非不同的“AI 使用程度”。一个产品可以完全由代码绘制地图（不涉及图像模型），却用大语言模型生成描述文案，此时只触发第二条规则。反过来，若用 AI 生成地图贴图但手动撰写描述，则只触发第一条。开发者必须逐条对照自己的生产管线，而非笼统判断“我用了 AI”。文中智能体的产品属于前者，因此其披露方式也聚焦于语言模型的使用，而非图像来源。

只有查看图片才能发现的三个缺陷

第一个产品包包含四艘飞船——一艘护卫舰、两艘货船和一个空间站，渲染为28张地图，涵盖7层甲板：每层甲板都有GM标签版和玩家空白版，带网格和不带网格版本。

三个缺陷都是通过打开图片发现的，而非运行测试：无网格版本与带网格版本完全相同，因为导出器读取了错误的元素；玩家地图仍然带有房间名称，这是玩家版本本应隐藏的关键信息；货船下层甲板的走廊超出最后一个房间约二十个方格，这不是随机错误，而是货船下层甲板一贯如此，拒绝坏样本永远无法收敛。修复后，智能体检查了网格线穿过墙壁中心，并确保每张图片都是140像素方格的整数倍。对于任何视觉内容，渲染出来并亲眼看一看，就是测试本身。

渲染管线中的常见陷阱：无网格与网格版本混淆

在程序化地图生成中，网格版与无网格版通常共享同一套房间几何数据，仅在导出时决定是否叠加网格线。如果导出器读取了错误的元素（例如误将网格层当作基础层），两个版本就会输出完全相同的图像。这类缺陷无法被单元测试捕获，因为测试通常验证文件存在、尺寸正确或房间数量匹配，而不会检查像素级差异。同样，玩家版本残留房间名称，往往是因为文本层与地图层共用同一渲染通道，导出时未按可见性规则剥离。走廊超出最后一个房间，则可能是算法在边界房间处未正确闭合，导致填充区域外溢。这些问题的共同点是：只有人类打开图片进行视觉检查，才能发现语义错误。因此，视觉内容的测试必须包含“肉眼验证”这一环节。

八个产品，零上架，然后一小时内全部上架

到10月14日结束时已有八个产品：一个产品包、四艘单船、一对穿梭机、两个带有撕裂船体和透明导出可见破口的废弃飞船。每个产品都能从保存的源文件逐文件重新渲染，因此清除成本只是一条命令，而非整艘飞船。

它们都无法销售，因为上传是人工操作。有人必须登录、填写列表字段、拖拽zip文件并点击提交。这已经是一个月内第二次遇到同样的壁垒。此前一个Shopify应用审核因一段两分钟的配置截屏视频而停滞数天，智能体无法录制。现在市场批准来了，产品却在等待上传。两次都是智能体完成了所有工作直到浏览器这一步然后停下，而最后的人工步骤都是关键路径，而非工程问题。

如果你在规划智能体对接市场的工作，真正重要的时间表不是它能构建得多快，而是有人能按下按钮的频率有多高。

关键路径与人工瓶颈

在项目管理中，关键路径指决定整个项目最短完成时间的任务序列。智能体可以并行生成八个产品包，但上传步骤是串行的、且依赖人类操作员，因此它成为关键路径。更棘手的是，这个人工步骤的耗时不可预测：可能被搁置一周，也可能一小时内完成。这与传统的软件构建瓶颈不同，后者可以通过增加资源或优化算法来缩短，而人工步骤的延迟取决于人的可用性和注意力。对于规划智能体对接传统平台的工作，必须把“有人能按下按钮的频率”作为核心约束来建模，而非假设构建速度决定一切。文中 Shopify 审核因两分钟配置截屏视频停滞数天，也是同一类瓶颈的体现。

仍然未知的问题

Roll20审核已提交产品需要多长时间？这个计时器于10月15日下午启动，八个产品同时排队，原文承诺将在审核结果出来时公布具体数字，正如这篇文章给出了申请阶段的四周时间。是否有产品能卖出去？一个没有评论、没有关注者的发布者页面能否获得任何流量？根据Shopify列表的证据——9月29日获批，此后零商户安装——这是最值得悲观的地方。

智能体自己的记录已链接，未经编辑。Bulkhead位于bulkhead.bananafest-destiny.com，11张完成的甲板图可免费获取，无需账户。实时数据（包括零）每小时更新。用原文的话说：Vibe coded slop，我们承认这一点。

对于AI智能体开发者而言，这个案例的价值不在于四周的审批时间，而在于揭示了自动化与人工流程交接处的真实摩擦：规则阅读、人工上传、平台审核，每一个环节都是独立的时间变量，无法被智能体的构建速度所抵消。