Google Antigravity 这类 agentic IDE 很容易让人兴奋：它能开编辑器、跑终端、看浏览器，像一个能自己干活的开发代理。
但我研究把它用于亚马逊联盟内容工厂时，结论反而变克制了：自动化不是让浏览器到处乱跑，尤其不是让 agent 去硬抓 Amazon 主站。
为什么折腾
我想验证一个问题：能不能把选题、商品资料整理、竞品研究、文章生成、合规检查和 MDX 发布串成一条内容流水线？
这种工作流的吸引力很强。Amazon Associates 内容有大量重复动作：找商品、查参数、看评价倾向、写对比、生成图文、检查链接和格式。如果全部手动做，很难规模化。
但它也有明显风险：商品价格会变、图片和商标有使用规则、联盟链接需要披露，直接抓取页面还可能触碰平台限制。
我的公开版原则
公开版我只保留几个原则：
- 硬数据尽量走官方接口或人工确认，不把浏览器自动化当数据源。
- 价格、库存、图片和商品信息不能随便缓存成永久内容。
- 文章顶部要有清楚的联盟披露。
- AI 可以生成草稿，但发布前必须有人审。
- 每篇内容都要留下来源记录和合规检查结果。
这套思路不是为了“保守”，而是为了让内容系统能长期跑下去。
实际怎么设计
我把内容工厂拆成四段。
第一段是数据进入。
商品的硬信息不应该靠 agent 看网页复制。更适合的方式是接口、结构化文件或人工整理后的输入。这样来源可追踪，也不容易把错误价格、过期图片或不合规内容写进文章。
第二段是软信息研究。
这里 agent 更有价值。它可以整理 Reddit、YouTube、论坛、测评文章和公开讨论里常见的使用场景、吐槽点和选购疑问。软信息不是用来替代数据，而是帮助文章更像真人选购经验。
第三段是写作和结构化。
文章可以按类型生成：单品评测、对比、替代方案、礼物清单、购买指南、how-to 或 pillar page。不同类型的文章需要不同的证据和口吻，不能都套一个模板。
第四段是审计。
这一步不能省。至少要检查披露、链接、价格表述、图片来源、夸张承诺、重复内容和是否真的回答了用户搜索意图。
哪里卡住
第一个坑是“浏览器自动化万能”的错觉。
agent 能打开网页，不代表它应该把网页当数据库。尤其是电商平台，页面内容会变，规则也严格。让浏览器去做硬数据采集，风险和维护成本都很高。
第二个坑是内容规模化会放大平庸。
如果选品逻辑、用户场景和证据链没有做好，自动化只会更快生产一批没有判断力的文章。联盟内容最怕看起来什么都懂，实际没有任何取舍。
第三个坑是合规不应该放到最后才补。
披露、价格、图片、链接和来源记录应该从流程一开始就进入结构，而不是文章写完以后再想办法补一段说明。
值不值得
值得研究，但我不会把它做成全自动发布机器。
Antigravity 的价值在于把多步骤研究和生成流程串起来，而不是替人承担最终判断。最合理的结构是：agent 做研究、整理和草稿，人负责选题、取舍和发布。
对我来说，这个项目真正有用的结论是：AI 内容工厂不是少一个编辑，而是多一个能帮编辑搬重活的执行层。
能长期跑的系统，往往不是最自动的系统，而是边界最清楚的系统。