增长问题诊断与渠道行动导航

它解决什么问题

出海增长的问题往往分散且难以定位：排名波动、索引异常、内容方向不明、发布渠道选错，都可能导致流量停滞。用户常常知道自己想提升某个指标，却说不清症状出在哪个环节，也不知道该调用哪个具体能力。

如果一次性加载所有相关技能，又会让对话变得臃肿、决策路径变长。gr 作为主路由，先做一层分拣和诊断，把模糊的增长诉求映射到单一、明确的子技能上。

核心能力与决策流程

路由表匹配

根据用户描述的信号，gr 会推荐对应的子技能：

• SEO 排名或索引问题 → gr-seo-patrol
• 写博客或跨语言内容 → gr-blog-post
• 发布 Product Hunt → gr-ph-launch
• 开源项目增长 → gr-oss-marketing
• B2B/SaaS 增长策略 → gr-b2b-growth
• App Store 优化或冷启动 → gr-aso
• 用户访谈与 PMF 探索 → gr-user-interview
• 竞品分析 → gr-competitor
• 内容多平台分发 → gr-social-distill
• AI 引用优化 → gr-geo-cite
• 外链建设 → gr-backlinks

三步决策

1. 听主诉：先问清楚具体症状，例如哪个关键词排名掉了、从什么时候开始、影响多大。
2. 判断阶段：区分是还没启动（先做 benchmark 或 PH/OSS），还是已经上线（先做 SEO patrol 或 blog-post）。
3. 推荐单一子技能：明确告诉用户“我准备用 gr-xxx，要不要直接跑？”

一次只推一个，完成后再判断是否需要级联，避免把 11 个子技能一次性丢给用户。

级联推荐

某些任务完成后，gr 会根据结果自动建议下一步：

• gr-ph-launch 发布日后 7 天 → 推荐 gr-seo-patrol 做流量监控
• gr-seo-patrol 发现 canonical 冲突 → 推荐 gr-blog-post 修复
• gr-blog-post 发布后 → 推荐 gr-seo-patrol 加入每日监控
• gr-competitor 发现新打法 → 推荐 gr-blog-post 或 gr-ph-launch

这样形成闭环，而不是一次性执行就结束。

API keys 读取规范

所有 gr-* 子技能共享同一组 API keys。调用前需要确认 key 是否可用：

• 生产环境优先读取 Railway env vars
• 本地环境参考 docs/api-keys-template.md
• 完整 key 列表记录在 MEMORY.md 的 project_growth_tools.md 中

如果缺少必要 key，应先提示用户配置，而不是直接硬跑。

适用边界与设计原则

gr 不直接产出最终成果，而是负责路由和诊断。使用时要注意：

• 先问清症状再动手：用户说“SEO 下降”时，先确认关键词、幅度和时间点，而不是直接开跑。
• 数据先行：没有 SERP、GA4 或竞品情报时，不硬写内容，避免凭感觉决策。
• 文风统一：所有产出文本的子技能都需要遵循 Iris 文风规范，保证语气一致。

如果问题本身是具体的执行需求（例如直接写一篇博客），gr 会把它转交给对应子技能，而不是在这里展开详细操作。