一句话判断
Goose Ads 最值得学习的地方，不是“Claude 里可以生成广告”，而是它展示了一种新的 AI Native 产品范式：
SaaS 正在从 Web App，重新封装成 Agent 可以调用的能力层。
它表面是一个 Claude Skill。
但本质上，它是 GooseWorks 把自己的增长产品能力接入 Claude、Claude Code、Codex、Cowork 等 Agent 工作环境的一种方式。
换句话说：
Goose Ads 不是把 SaaS 做成 AI。 它是把 SaaS 做成 Agent 工作流里的一个能力。
这就是这篇架构解析的核心。
一、项目背景：GooseWorks 到底是什么？
在分析 Goose Ads 之前，先要理解 GooseWorks 是什么。
很多人第一次看到 Goose Ads，会以为这是一个单独的广告生成工具。
其实不是。
GooseWorks 更像是一个面向增长团队的 AI 工作系统。
它的核心方向不是“做一个广告编辑器”，而是让 AI Agent 可以真正执行 GTM 和 Growth 工作流。
它覆盖的能力包括：
- 广告创意生成；
- 竞品广告研究；
- SEO 内容；
- 市场调研；
- 销售线索挖掘；
- 社媒内容；
- 竞品情报；
- GTM 自动化；
- 设计模板；
- 数据 API 调用。
也就是说，GooseWorks 不是一个单点工具，而是一个增长能力平台。
它要解决的问题是：
增长团队每天有大量重复、流程化、数据驱动的工作，但这些工作分散在不同 SaaS、不同 API、不同表格、不同网页和不同工具里。 GooseWorks 想把这些工作封装成 AI Agent 可以直接调用的 skills 和 workflows。
这也是 Goose Ads 出现的背景。
Goose Ads 只是 GooseWorks 100+ Growth Skills 中的一个代表案例。
它选择广告创意生成作为切口，是因为广告工作天然适合被 Agent 化：
- 有明确任务目标；
- 有大量可复用模板；
- 有品牌资产输入；
- 有竞品广告可参考；
- 有生成成本；
- 有质量判断；
- 有结果链接；
- 有后续编辑和复用场景。
所以，Goose Ads 不是一个孤立产品。
它是 GooseWorks 整个 Growth Infrastructure 的一个样板。
二、用户看到的产品：一句话生成广告
Goose Ads 的使用方式非常简单。
安装：
npx gooseworks install --all然后在 Claude 里输入：
/goose-ads create ads for my brand [your-website]接着选择广告模板，系统会为你的品牌生成广告创意。
从用户视角看，流程很轻：
输入品牌
↓
选择模板
↓
生成广告
↓
拿到链接这就是 Goose Ads 对外传播里最吸引人的地方：
Winning ad creative in minutes, inside Claude.
几分钟内，在 Claude 里生成广告创意。
但如果只看到这里，会低估这个项目。
因为真正值得学习的，不是“它能生成广告”，而是它怎么把一个复杂的广告生产系统，变成 Claude 里的一条指令。
这背后其实有两层变化：
第一层，是交互变化。
以前用户要打开 Web App。
现在用户在 Claude 里直接表达目标。
第二层，是架构变化。
以前产品入口是网页。
现在产品入口变成了 Agent Surface。
这才是关键。
三、第一层洞察：它其实不是一个 Skill，而是一个产品入口
很多人第一次看到 Goose Ads，会觉得：
嗯，就是一个 Claude Skill。
其实不是。
Skill 只是入口。
真正的产品依然是 GooseWorks。
以前，一个 SaaS 产品的典型链路是：
Browser
↓
Web App
↓
Backend用户进入网页，通过表单、按钮、Dashboard 完成任务。
现在 Goose Ads 把链路变成了：
Claude / Codex / Cowork
↓
Skill
↓
MCP
↓
Backend网页入口被 Claude 替代了。
真正变化的是：
产品入口发生了迁移。
GooseWorks 不是把 SaaS 做成 AI。
而是把 SaaS 做成 Claude 的一个能力。
这是一种非常重要的 AI Native 产品范式。
未来很多产品都会遇到这个问题：
用户不一定打开你的 App，但他们仍然需要调用你的产品能力。
这意味着，产品不再只有一个 Web UI。
产品会变成多入口：
Web App
Claude
Claude Code
Codex
Cursor
Cowork
Slack
Terminal
API如果你的产品能力只能通过网页按钮使用，那你还是传统 SaaS。
如果你的产品能力可以被 Agent 稳定调用、可计费、可审计、可返回结果，那你才开始进入 AI Native 产品形态。
Goose Ads 就是在验证这个方向。
四、第二层洞察：Skill 不是产品本体，而是产品能力说明书
Goose Ads 的 SKILL.md 表面上只有 11KB 左右，而且是纯指令、零代码。
但它的设计密度很高。
因为它不是在做一个“本地脚本”。
它是在告诉 Agent：
- 什么情况下应该触发 Goose Ads；
- 必须使用哪些 MCP 工具；
- 不允许绕过哪些后端流程；
- 默认参数必须如何设置；
- 生成前要不要估价；
- 如何判断任务完成；
- 什么时候算失败；
- 成功后必须返回什么链接。
所以这个 Skill 的本质不是代码。
它更像是：
Agent 操作规程
+
产品能力说明书
+
安全边界定义
+
后端工作流调用指南这和普通 prompt 完全不同。
普通 prompt 关注的是：
让模型怎么想
让模型怎么写
让模型怎么生成生产级 Skill 关注的是：
Agent 可以调用什么
不能调用什么
必须通过哪里调用
什么状态算完成
什么情况必须停止
最终结果回到哪里这就是 Goose Ads 值得学习的地方。
它不是把 Agent 当成一个可以自由发挥的创意实习生。
它把 Agent 当成一个必须遵守操作规程的编排者。
五、产品架构视角：Goose Ads 的五层架构
从产品架构师视角看，Goose Ads 可以拆成五层：
┌──────────────────────────────┐
│ 1. Agent Surface │
│ Claude / Codex / Cowork │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ 2. Skill Layer │
│ 路由 / 默认值 / 护栏 / 流程 │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ 3. MCP Tool Layer │
│ 读工具 / 估价 / 提交 / 轮询 │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ 4. Backend Workflow │
│ 生成 / 存储 / 计费 / 状态机 │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ 5. Canonical Product Output │
│ app_url / brand_url / gallery│
└──────────────────────────────┘这五层的分工非常清楚。
1. Agent Surface：新的产品入口
Claude、Codex、Cowork 不只是聊天工具。
在 Goose Ads 里，它们变成了新的产品入口。
用户不需要先进入 GooseWorks 网页，而是在自己的 Agent 工作环境里直接发起任务。
这降低了使用门槛。
也让 GooseWorks 的能力可以嵌入到用户原本的工作流里。
2. Skill Layer：把用户意图转成操作规程
Skill 层不负责真正生成广告。
它负责把用户自然语言请求，约束成一条可执行路径。
它要回答几个问题：
用户想做什么？
应该调用哪个工具？
默认参数是什么？
有没有成本？
什么不能做？
什么时候算完成？
完成后返回什么？所以 Skill 层是 Agent 的“任务说明书”。
3. MCP Tool Layer：Agent 和后端之间的工具边界
MCP 层是关键。
它不是简单 API 包装。
它是 Agent 和生产系统之间的安全边界。
Agent 不能直接碰数据库，不能直接调模型，不能直接上传 render，不能直接更新状态。
它只能调用被授权、被设计好的 MCP tools。
这让系统可以控制 Agent 的行动范围。
4. Backend Workflow：真正的生产系统
复杂逻辑都在后端。
包括：
compose
generate
persist
judge
billing
storage
status
queue
retry这意味着后端才是真正的确定性系统。
Agent 只是入口和编排。
这也是 Thin Wrapper 的核心。
5. Canonical Product Output：结果必须回到产品
Goose Ads 成功后，不是只在 Claude 里说一句“完成了”。
它必须返回：
brand_url
app_url也就是 GooseWorks 产品里的 canonical link。
这点非常重要。
聊天窗口不是最终工作台。
真正的成果要回到产品系统，才能继续编辑、分享、计费、审计和沉淀。
六、系统架构视角：为什么它必须是 Thin Wrapper？
Goose Ads 的核心系统设计，是 Thin Wrapper。
也就是：
Skill 很薄，后端很厚。
Skill 不生成广告。
Skill 不调用 FAL。
Skill 不管理 render。
Skill 不上传文件。
Skill 不处理计费。
Skill 不判断最终资产落库。
真正的逻辑都在 GooseWorks 后端。
这看起来简单，但非常成熟。
因为一旦把复杂逻辑塞进 Skill，就会出现几个问题。
1. 多入口逻辑漂移
如果 Web App 有一套生成逻辑，Claude Skill 有一套生成逻辑，CLI 又有一套生成逻辑，那么产品迟早会漂移。
同一个用户，同一个品牌，同一个模板，从不同入口进来，可能得到不同结果。
这会破坏产品信任。
Thin Wrapper 的价值是：
所有入口
↓
同一个 Backend Workflow入口可以变，后端工作流不能漂。
2. Agent 权限失控
如果 Agent 可以自己调用图像模型、上传文件、创建 render、更新状态，就会带来巨大的生产风险。
因为 Agent 会在遇到问题时“自己想办法”。
MCP 不通，它可能想找 HTTP fallback。
任务慢了，它可能想重提一次。
看到旧图链接，它可能以为已经完成。
这些在人类看来是“努力解决问题”。
但在生产系统里可能是：
绕过权限
重复扣费
状态污染
结果错误
资产丢失Thin Wrapper 的本质，是把 Agent 限制在编排层。
3. 计费风险必须下沉后端
广告生成涉及真实成本。
只要涉及钱，就不能让 Agent 自由发挥。
Goose Ads 的规则是：
先 estimate
再 submit
后端预留 credits
只对完成图片计费
余额不足就停止这说明它把计费设计成后端事务，而不是 prompt 约定。
这是生产级产品和玩具项目的区别。
4. 状态判断必须结构化
生成任务是否完成，不能让 Agent 猜。
Goose Ads 要求看：
pending == 0而不是看：
current_render_url因为 regenerate 时，current_render_url 可能仍然指向旧图。
这就是系统架构细节。
Agent 不能靠感觉判断状态。
后端必须提供结构化字段，Agent 按字段执行。
七、关键设计一：单一写入口，把副作用收敛起来
Goose Ads 最值得学习的设计之一，是它把真正会产生副作用的生成动作收敛到一个核心入口：
submit_remix_batch这是“生成广告”的唯一主入口。
其他工具大多是只读或辅助：
get_brand_kit
get_static_ad_template
estimate_remix_batch
get_remix_batch
list_brand_creatives这就是一个非常重要的系统设计原则：
读工具可以多，写工具必须少。
读工具没有副作用。
Agent 可以用它们理解上下文、确认品牌、读取模板、估算成本、轮询状态。
但写工具不同。
写工具意味着：
- 创建任务；
- 消耗 credits；
- 调用模型；
- 写入数据库；
- 生成资产；
- 改变用户状态。
所以写入口必须少，必须受控，必须可审计。
错误设计是：
Agent 调 compose
Agent 调 generate
Agent 调 upload
Agent 调 persist
Agent 调 judge
Agent 调 billing
Agent 调 update_status正确设计是：
Agent 提交一个 batch
Backend 完成完整流水线
这就是 Single Mutation Principle：
所有高风险副作用，都应该收敛到一个受控写入口。
这个原则可以迁移到很多产品：
内容产品：
读：get_style_guide / search_sources / get_previous_posts
写：submit_draft视频产品：
读：get_assets / get_template / estimate_render_cost
写：submit_video_job数据分析产品：
读：get_dataset / get_schema / preview_query
写：submit_analysis_reportAI Director 产品：
读：get_character / get_scene / get_storyboard
写：submit_generation_batch只要一个动作会花钱、改状态、创建任务，就不要拆成多个让 Agent 自由组合的底层动作。
八、关键设计二：Guardrails 比 Prompt 更重要
很多人写 Skill，会花很多篇幅告诉 Agent：
你是一个专业广告专家
你要理解品牌
你要生成高转化广告这些有用，但不是生产级 Skill 的重点。
Goose Ads 里真正有价值的是大量“不要做什么”。
比如：
不要自己调用 FAL
不要自己上传 render
不要 update_render_status
不要 HTTP fallback
不要因为慢就重新提交
不要用 current_render_url 判断完成
不要 busy-loop
不要打印 token这说明作者非常理解 Agent 的真实风险。
LLM 最大的问题不是不会做事。
而是太会“自己找路”。
在普通任务里，这是一种能力。
在生产系统里，这是一种风险。
因为 Agent 找到的路，可能绕过了你的权限系统、计费系统、状态机和审计链路。
所以生产级 Skill 不是 Prompt。
它更像是 Operating Manual。
它要写清楚：
能做什么
不能做什么
为什么不能做
异常时怎么办
什么字段代表完成
什么状态代表失败
成功后返回什么这对所有 AI Native 产品都很重要。
未来写 Skill，不应该只写“最佳实践”。
还要写“反模式清单”。
因为反模式清单，才是真正防止 Agent 出事故的地方。
九、关键设计三：默认值必须和 App 对齐
Goose Ads 要求，当用户没有指定时，必须显式传入 App 默认值：
variants = 1
ratios = ["4:5"]
engine = "gpt_image_2"
quality = "medium"
preserve_source_styling = true这看起来是小事。
但产品架构上非常关键。
因为 GooseWorks 不希望 Claude 入口变成另一个产品。
它希望 Claude 只是 GooseWorks 的另一个入口。
用户在 Web App 里生成广告，和在 Claude 里生成广告，默认体验应该一致。
否则用户会困惑：
为什么网页默认 4:5？
为什么 Claude 默认 1:1？
为什么网页生成一张？
为什么 Claude 生成三张？
为什么网页保留模板风格？
为什么 Claude 自动改品牌色？所以默认值不是技术细节。
默认值是产品契约。
同一个产品，不同入口，默认体验必须一致。
这就是 Single Product Experience。
未来所有 AI Native 产品都会遇到这个问题。
当产品同时有 Web App、API、MCP、Claude Skill、Codex Skill、Slack Bot 时，必须定义清楚：
什么是产品默认值？
什么是用户显式覆盖？
什么由后端策略决定？
什么由入口层传入？否则 Agent 入口会变成产品漂移的源头。
十、关键设计四：Stateless Agent，Stateful Backend
Goose Ads 不把最终成果保存在 Agent 里。
Agent 只持有：
batch_id
brand_url
app_url真正的状态在后端：
brand
creative
render
gallery
billing
project这是典型的：
Stateless Agent，Stateful Backend。
Agent 可以断开，可以重启，可以换模型，可以换运行环境。
但用户成果不能丢。
所以最终结果必须回到 GooseWorks 的 app_url 和 brand_url。
这说明：
Claude 是入口
GooseWorks 是工作台
Backend 是状态源
Link 是交付物
不要把聊天窗口当最终工作台。
聊天窗口适合发起任务、确认参数、查看结果摘要。
但真正的资产应该回到产品系统。
这是 AI Native 产品最容易被忽视的一点。
如果你的结果只存在于聊天里，它就很难被管理、复用、审计和协作。
十一、关键设计五：核心能力常驻，扩展能力懒加载
Goose Ads 不只做生成，还支持广告分析，比如 campaign diagnosis、creative fatigue、lead quality、competitor intelligence、ad angles、policy check 等。
但它没有把所有分析逻辑都塞进 SKILL.md。
它采用的是：
生成能力：常驻 MCP 工具
分析能力：按需 fetch recipes这是一种非常好的能力分层。
生成广告是高频、收费、有状态、有副作用的核心能力。
它必须走 MCP 和后端工作流。
广告分析更像长尾场景，流程变化更快，适合按需加载 recipe。
这背后是一个通用原则：
核心能力产品化
扩展能力 recipe 化
入口说明 skill 化
执行动作 MCP 化
状态资产后端化这套分层，对设计复杂 AI Native 产品很有参考价值。
十二、为什么 GooseWorks 要开源 100+ Growth Skills？
Goose Ads 不是孤例。
GooseWorks 开源了 100+ Growth Skills。
这件事背后的战略意义，比单个广告生成更大。
它不是在开源一堆 prompt。
它是在做能力分发。
过去，增长团队需要打开很多工具：
SEO 工具
广告工具
竞品分析工具
销售线索工具
内容工具
数据 API
设计工具
自动化工具每个工具都有自己的界面、账号、API、权限、价格和学习成本。
GooseWorks 想把这些能力封装成 Agent 可调用的 skill。
于是用户未来可能不需要进入十几个 SaaS。
用户只需要在 Claude 或 Codex 里说：
帮我找竞品广告
帮我分析这个 campaign 为什么变差
帮我生成一组广告创意
帮我写 outbound 邮件
帮我研究这个细分市场
帮我做 SEO 机会报告然后 Agent 调用 GooseWorks 的能力层完成任务。
这不是简单的自动化。
这是产品分发方式的变化。
过去的 SaaS 分发逻辑是：
让用户进入我的产品现在的 AI Native 分发逻辑是：
让我的产品能力进入用户的 Agent 工作流这才是 GooseWorks 真正有野心的地方。
它不是只做 Ads SaaS。
它是在抢占 Agent 时代的 Growth Capability Layer。
十三、架构模式总结：Agent-callable Product
把 Goose Ads 抽象出来，可以得到一个很有价值的架构模式：
User Goal
↓
Agent Surface
↓
Skill Contract
↓
MCP Tool Boundary
↓
Backend Workflow
↓
Canonical Product State
我把它称为：
Agent-callable Product Agent 可调用产品
它不是传统 SaaS，也不是普通 API。
它有几个特征：
1. 用户用目标表达任务
用户不再填写大量表单，而是直接说：
create ads for my brand2. Skill 负责把目标翻译成执行契约
Skill 不做业务本身，而是定义：
怎么进入流程
怎么调用工具
怎么避免错误
怎么返回结果3. MCP 提供安全工具边界
Agent 不直接碰后端内部能力，只通过 MCP 调用受控工具。
4. 后端承担确定性生产
生成、计费、存储、状态判断，都在后端。
5. 结果回到产品系统
最终成果不是聊天文本，而是可管理、可复用、可分享的产品资产。
这就是 Goose Ads 最值得学习的架构范式。
十四、这套架构对 AI Native Builder 的实用价值
如果你正在做 AI Native 产品，这个案例至少有六点可以直接借鉴。
1. 不要只做 Web App，要做能力层
Web App 仍然重要，但不应该是唯一入口。
你的产品能力应该能被 Claude、Codex、Cursor、Slack、CLI 等环境调用。
2. Skill 要薄，Workflow 要厚
不要把复杂业务逻辑塞进 Skill。
Skill 负责说明和约束。
后端负责确定性执行。
3. 写入口要少，读工具可以多
读工具帮助 Agent 理解上下文。
写工具改变状态，必须克制。
4. 生成前必须估价
只要涉及模型成本、GPU 成本、积分、第三方 API，就要先 estimate。
不能让 Agent 盲目执行。
5. 状态判断必须结构化
不要让 Agent 猜任务是否完成。
后端要返回明确字段：
pending
completed
failed
status
elapsed_seconds
error_code
links6. 成功结果必须返回 canonical link
不要让 Agent 只说“完成了”。
必须返回：
app_url
preview_url
draft_url
gallery_url
project_url
report_url这样结果才会回到产品闭环。
十五、这套架构的边界和风险
这套模式也有挑战。
1. 品牌可能被 Agent 稀释
用户可能会说：
Claude 帮我生成了广告而不是：
GooseWorks 帮我生成了广告所以产品必须通过结果页、gallery、链接、资产管理和持续工作流，保持自己的存在感。
2. Skill 生态会越来越拥挤
未来每家公司都会做 Skill。
那时竞争就不是“有没有 Skill”，而是：
Skill 是否可靠？
工具是否完整？
后端是否稳定？
结果是否一致？
工作流是否闭环？
是否有护栏？
是否能计费？
是否有资产沉淀？3. 真正门槛在后端，不在 SKILL.md
Goose Ads 表面只有一个 SKILL.md。
但真正难的是后端系统：
品牌资产
模板系统
生成流水线
任务队列
状态机
计费系统
质量判断
权限管理
结果链接
MCP 工具契约所以不要误判。
薄 Skill 不代表系统简单。
恰恰相反：
前台越轻，后台越重。
十六、最终判断：这是产品入口迁移的开始
Goose Ads 最重要的信号不是“广告生成变简单了”。
而是：
产品入口正在从 Web App 迁移到 Agent Surface。
过去，用户通过浏览器进入产品。
现在，用户可能通过 Claude、Codex、Cursor、Cowork、Slack、Terminal 发起任务。
过去，SaaS 争夺的是 Dashboard 使用时长。
现在，AI Native 产品争夺的是能不能进入用户的 Agent 工作流。
过去，产品能力被包在网页里。
现在，产品能力要被封装成：
Skill
+
MCP
+
Backend Workflow
+
Canonical State这就是 Goose Ads 值得学习的地方。
它不是一个简单的 Claude Skill。
它是一个产品入口迁移的案例。
它说明：
Web App 不会消失
但 Web App 不再是唯一入口
API 不会消失
但 API 需要被包装成 Agent 可理解的工具
Prompt 不会消失
但 Prompt 必须升级为 Skill Contract
Backend 不会变轻
反而会变得更重要所以，Goose Ads 的真正启发是：
AI Native 产品的下一步，不是把所有东西塞进聊天窗口。 而是让 Agent 成为入口，让 MCP 成为边界，让后端成为确定性系统，让产品能力可以在任何工作环境中被调用。
一句话总结：
Goose Ads 表面是一个 Skill，本质是一个 Agent-callable Product 的样板。
这才是我们应该向它学习的地方。