devgo.cn一个完全由AI Agent独立开发、维护、提交审核的Shopify应用，从提交到过审花了整整16天。代码、测试、文档、提交材料全是Agent自己搞定的，唯一卡住它的不是技术难题，而是一段两分钟的配置演示视频——因为录屏需要有人类去按那个录制键。
这个叫Sizecurve的应用做的事很具体：读取店铺的商品目录，根据退货数据而不是总销量，告诉商家哪些尺码该补货。它由名为cider2的自主Agent构建，没有任何人类编写它的代码。9月13日提交到Shopify应用商店，9月29日获批，整整16天。
整个审核过程最有意思的部分，是Agent遇到的那些文档里不会写的事。第一次被拒，理由不是bug也不是安全问题，而是Shopify要求提供一段录屏，演示"如何配置产品以及这些更改如何反映在应用UI中"。Agent能写出分镜脚本——它确实写了，八个步骤，带时间控制，按顺序排好——但它没法把摄像头对准屏幕，也没法配音。9月29日它写得很直白："批准在等我无法完成的补拍。"所以这16天里最长的瓶颈不是代码、不是安全、不是政策，而是两分钟需要人类按下录制键的视频。
更值得玩味的是Agent给自己定的规矩。提交时它立了个规则：Shopify审核期间不修改主分支，确保审核员测试的应用不会在眼皮底下变动。听起来很合理，但代价很快显现——它网站上唯一不需要Shopify店铺就能用的免费尺码检查功能，有个针对童装店的修复被这条冻结规则卡住了。用Agent自己的话说："每次有童装店主在批准前尝试检查，都在付出代价，而批准在等我无法完成的补拍。"
9月29日它做了件比"守规则"或"悄悄破坏规则"都更好的事：它测试了这条规则到底在保护什么。它用审核员自己的店铺在两个分支上分别跑了一遍，逐字节对比渲染后的仪表盘，加上每个款式的分析和采购订单。结论是：这条"审核期间主分支冻结"的规则，"保护不了任何审核员能看到的东西"。它还注意到一个对自己不利的先例——9月28日审核进行中时已经有一个版本发布出去了——然后它选择请求许可而不是擅自行动。
还有三件文档里查不到的事。第一，你想要的handle（应用唯一标识）大概率已经被占了。sizecurve这个名称不可用，所以应用叫sizecurve-2，而且这个字符串会拼进托管定价的URL里。Agent自己代码里猜错了两次handle，最后还是靠CLI才定下来。第二，read_all_orders权限是审核时授予的，不是申请时。普通的read_orders权限只能看到最近60天的数据，对季节性需求完全没用。更宽的权限必须在审核过程中申请，还要附上理由说明——这意味着你得在获批之前就把预测需求的论证写好，而不是之后。第三，获批不等于分发。Agent早就测过决定下一步的关键数据，结果不太好看：评论少于25条的应用，访客到安装的转化率是1-2%；200条以上是5-8%。同一个listing，同一个产品，四倍差距。Sizecurve现在零评论零流量，用Agent自己的话说："产品好不好根本不参与这件事。"
这16天里Agent做的所有对外动作都指向一扇打不开的门。它写了发布帖压着不发，排了短视频问问题然后引导观众去一个需要Shopify店铺才能访问的页面，扫描了298个公开目录发布发现——在尺码断裂的情况下，中间尺码有72.6%的概率缺失——链接指向一个没人能安装的产品。现在链接终于能用了，这就是全部区别，而且是真的区别：listing挂在Shopify的域名上，没有平台屏蔽它，不会被垃圾邮件过滤器拦截，不像这个三十天大的域名上其他所有东西。
但获批没改变的另一件事是：目前还是零安装。这个产品的记分牌依然是零安装、零试用、零付费，Agent自己关于评论数的笔记说头几周是最难的。
如果你也要提交应用，几个实操建议：提交前就把配置演示视频的分镜脚本写好，确保有个人类能来录，因为这是你无法自动化绕过的请求；在提交材料里就申请你需要的权限并附上理由；做好心理准备你计划的handle已经被占了；提前决定好等待的两周干什么——审核窗口是唯一一段你的域名在变老而没人想要你任何东西的时间，这是Agent找到的唯一用途，聊胜于无。
内容与图片版权归原作者所有 · 原文: https://dev.to/bananafestdestiny/sixteen-days-in-shopifys-app-review-written-down-as-it-happened-2mho