关于 gr-readme
面向 GitHub 项目维护者的 README 写作技能，提供从首屏定位到快速开始、功能展示和社区支持的结构指南。强调明确、可验证的信息，并将 README 写作原则与技能描述设计联系起来。
主要功能
- 01首屏定位与标语设计
- 02README 分区结构指南
- 03快速开始指引
- 04按用户需求组织功能
- 05AI Agent 集成说明建议
适用场景
- 01为 GitHub 项目重写 README
- 02精简首屏并明确目标读者
- 03编写可执行的安装与启动说明
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/gr-readme确认已加载。
详细介绍
GitHub README 撰写系统
本系统源自将 AFFiNE 从 0 星做到 6 万星的实践。README 不只是介绍产品——在最初的 30 天里，它本身就是产品。
—（AFFiNE 案例，Iris Wei @WeiYipei，ep01/ep03/ep06）
双重视角 / README 撰写 = 技能描述撰写
Claude Code Skills 中有一条适用于 README 撰写的见解：
“Claude 会使用
description字段来判断何时应用该技能。”
README 的标语遵循完全相同的逻辑：**用一句话描述，让合适的读者主动认定这正是自己需要的内容。**如果 Claude 无法从技能的描述中判断何时使用它，访客也无法从 README 中判断自己为什么需要它。
下表展示了两者之间的对应关系：
| README 元素 | 技能 frontmatter 字段 | 共同原则 |
|---|---|---|
| 标语（第一行） | description 的第一句 | 具体、易于浏览，能吸引合适的读者 |
| 补充描述（2–3 句） | description 正文 | 问题 + 解决方案 + 差异化特点 |
| README 中的触发短语 | when_to_use | 消除歧义——何时使用这个，而不是其他内容 |
| 架构 / 工作原理 | 支持文件（reference.md） | 按需提供细节，而非始终放在上下文中 |
| 快速入门命令 | allowed-tools + shell 代码块 | 具体、可执行、可验证 |
这并非比喻，而是一种实用的检验方法。如果你无法为 README 写出一句达到技能 description 同等标准的标语，那 README 就还需要打磨。
核心原则 / 核心原则
原则 1：README 是产品的第一个落地页
README 只有一个任务：让 GitHub 访客在首次滚动页面后的 3 秒内点星、复刻或安装。其他一切都次之。
原则 2：产品不够成熟，README 仍然可以很出色
AFFiNE 开源时产品还是「套壳」demo，README 写对了照样火。 —（AFFiNE 案例，Iris Wei @WeiYipei，ep03/ep06）
README 是你的叙事。你推介的是愿景和解决的痛点，而不是当前的功能集。完成度只有 30% 但 README 清晰说明“你为什么需要它”的产品，会胜过只有功能罗列的成品。
原则 3：优先使用英文，首屏须在 <3 秒内读懂
README 英文主，首屏 <3 秒读懂。 —（AFFiNE 案例，Iris Wei @WeiYipei，ep03）
GitHub 页面的首屏约为 600–800px。首屏可见的所有内容都必须回答：这是什么？为什么重要？面向谁？
原则 4：具体、可验证的说明胜过笼统的说法
摘自 Anthropic 提示词工程 和 CLAUDE.md 有效说明：
“使用 2 个空格缩进”胜过“正确格式化代码。” “提交前运行
npm test”胜过“测试你的更改。”
用同样的标准检查 README 文案：
- “支持离线使用——无需联网，所有数据均存储在本地” ✅
- “强大的离线支持” ❌
README 中的每句话都是给读者大脑的一条指令。要写得足够具体，让人能够验证。
README 结构框架 / README 结构框架
基于对 insforge（Agent 编码后端）、dify（拥有 6 万多个星标的大模型平台）以及 AFFiNE 从 0 到 6 万星增长过程的分析。
[Logo + Project Name]
[One-line Tagline] ← most critical, non-skippable
[Badges] ← signals, not decoration
[Hero image / Demo video] ← show product in <30 seconds
[What is this? 2–3 sentences] ← first screen core
[Quick Start] ← shorter = better; just get it running
[Key Features] ← sorted by user pain, not tech checklist
[Architecture / How it works] ← optional; use for complex projects
[Deployment options] ← cloud / local / one-click
[Claude Code / AI Agent Integration] ← new section; see below
[Contributing] ← short, link to CONTRIBUTING.md
[Community & Support] ← Discord / X / Discussions
[License]
[Star CTA GIF] ← ❗️ FIRST 3 SCREENS — inline with hero or after Quick Start
[Star History] ← social proof, bottom (optional extra)
首屏 3 秒法则 / 首屏 3 秒法则
原则： 首屏内容必须让读者无需思考，就能找到以下三个问题的答案。
| 问题 | 回答位置 |
|---|---|
| 这是什么？ | 标语（1 句话） |
| 我为什么要在意？ | 补充描述或问题陈述（2–3 句话） |
| 这是真的吗？值得信赖吗？ | 徽章：星标、许可证、下载量、最近一次提交 |
insforge 做得好的地方： Logo → 一句话标语 → 演示视频 → 3 句话的补充说明。内容一目了然。视频无需文字就能展示产品。
dify 做得好的地方： 主视觉图片 → 简洁的徽章行 → 1 段描述，用通俗语言列出 7 项具体功能 → 立即提供快速入门。
常见失误： 在任何视觉内容之前，先放一段冗长的“关于本项目”。开发者会寻找关键信息，而不是阅读介绍。
各板块写法指南 / 各板块写法指南
Section 1：标语
这是整个 README 最重要的一行。
好的标语会同时做到三件事：
- 说明产品是什么（类别）
- 说明产品面向谁（受众）
- 说明产品能解决什么痛点
标语公式（任选其一）：
[Adjective] [category] for [audience]
→ "Open-source backend platform for AI coding agents"
[Category] without [pain point]
→ "Note-taking without the cloud lock-in"
[Familiar reference] + [key differentiator]
→ "Open source Notion alternative — offline-first, privacy-focused"
[Outcome verb phrase]
→ "Ship full-stack apps from your AI agent, end to end"
AFFiNE 案例：
标语：“开源 Notion 替代品” 6 个词击中 3 个痛点：Notion 无法离线使用、数据导出不便、隐私问题。 —（Iris Wei @WeiYipei，ep01）
标语借助 Notion 的品牌知名度（无需解释），而“替代品”则同时传达了开源、可自托管，以及“保留你需要的功能，去掉你讨厌的部分”。
规则：
- ≤ 12 个词
- 不使用需要读者事先了解项目的行话
- 脱离上下文也必须成立——想象有人只看到这一行
- 切勿以“A powerful...”或“An amazing...”开头——这表明作者不知道产品的特别之处
与技能设计的关联： 这与 Skills 文档 中 description 字段的规则完全相同：“先写关键用例。”技能列表中的描述会被截断，GitHub 搜索结果中也一样。
Section 2：主视觉图片 / 演示视频
先展示，再介绍。
一段 30–60 秒的演示视频可将认知负担降低约 80%。如果没有视频，对于 UI 产品来说，展示实际使用场景的高质量截图或 GIF 必不可少。
对于 CLI / SDK 工具，mermaid 架构图加安装命令可起到同样的作用。
规则：
- 视频 ≤ 60 秒，并配有字幕（非英语使用者在受众中占很大比例）
- 截图应展示产品正在使用中，而非空状态
- 上传到 GitHub 自带的 CDN——将文件拖入 issue 编辑器，不要使用外部 CDN
- 如果支持，提供深色和浅色模式版本
Section 3：快速入门
本节唯一的目标：尽可能快速地让用户运行起一个实例。
# 3–5 commands max. No explanations between commands.
git clone https://github.com/yourorg/yourrepo
cd yourrepo
docker compose up -d
# → open http://localhost:3000
规则：
- 如果设置需要超过 5 条命令，问题出在上手流程，而不是 README
- 前置条件应放在命令上方，不要藏在脚注里
- 提供云端/托管版本链接作为替代方案——“不想自托管？试试 cloud.yourproject.com”
- 这些命令必须能在全新机器上正常运行。请实际测试。
dify 做得好的地方： 快速入门实际上是描述之后的第二个板块。先列出最低系统要求（CPU/RAM），再给出 4 条命令。不先写架构长文。先让用户运行起来，再作解释。
Section 4：主要功能
按用户痛点排序，而不是按技术实现排序。
❌ 错误（技术列表）：
- WebSocket support
- Plugin architecture
- REST API
- TypeScript SDK
✅ 正确（痛点优先）：
- Works offline — no internet required, all data stored locally
- Export everything — Markdown, PDF, raw JSON, always your data
- Self-hostable — deploy to your own server in 5 minutes
- Plugin API — extend with your own tools
规则：
- 主要列表中最多列出 7 项功能。超过 7 项，就说明“我们还不知道自己是什么”。
- 每个项目符号：先写痛点，再写实现细节
- 将关键词加粗——GitHub 会在功能列表中渲染粗体；这是免费的层级呈现
- 如果星标数很高，可含蓄地提及（“已有 X 位开发者在使用”）——在功能部分展示社会认同
第 5 节：架构 / 工作原理（可选）
适用于以下情况：
- 项目具有不明显的组件结构（后端平台、分布式系统）
- 开发者需要了解架构，才能决定是否参与贡献
- 面向需要集成项目而不只是使用项目的开发者
规则：
- 使用
mermaid— 可在 GitHub 上原生渲染。一张图 = 200 字。 - 图表节点不超过 8 个
- 将此部分放在快速入门之后
graph TD
A[User / AI Agent] --> B[Your Product Core]
B --> C[Service A]
B --> D[Service B]
B --> E[Service C]
第 6 节：部署选项
覆盖开发者的三种使用模式：本地开发、可自托管生产环境、云端。
| Method | Link | When to use |
|--------|------|-------------|
| Cloud (hosted) | [yourproject.com](link) | Zero setup, try now |
| Docker Compose | [Quick Start](#quick-start) | Self-hosted, recommended |
| Railway / Render | [one-click deploy](link) | Self-hosted, no Docker |
| From source | [Dev Guide](link) | Contributing |
一键部署按钮（Railway、Render、Zeabur、Sealos）是强有力的信任信号，也能让非 Docker 用户轻松上手。
第 7 节：Claude Code / AI Agent 集成 ← 新增章节
如果你的项目符合以下情况，请添加此章节：
- 可用作 Claude Code 技能或 MCP 插件
- 提供 AI Agent 可调用的 CLI
- 提供 Agent 工作流可调用的 API
## Claude Code / AI Agent Integration
Install as a skill (Claude Code):
\```
npx skills add your-project-name
\```
Or reference directly in your `CLAUDE.md`:
\```markdown
@your-project/README
\```
For MCP integration:
\```json
{
"mcpServers": {
"your-project": {
"command": "npx",
"args": ["-y", "@your-org/your-mcp-server"]
}
}
}
\```
这很重要，原因如下：
- Claude Code 技能从
~/.claude/skills/或.claude/skills/加载 — README 通常是技能系统了解项目功能时首先读取的内容 (技能文档) - 捆绑的
/run和/verify技能会根据 README 推断如何启动项目 — 清晰的快速入门章节能直接改善 AI Agent 的上手体验 - GEO（生成式引擎优化）：结构化、机器可读的 README 章节可提高 AI 系统准确引用你项目的概率
第 8 节：贡献
保持简短。指南见 CONTRIBUTING.md。
## Contributing
PRs welcome. See [CONTRIBUTING.md](CONTRIBUTING.md) for setup.
Questions? Join [Discord](link) or open a [Discussion](link).
不要在 README 中放入完整的贡献指南。这会打断阅读流程，还会让 CTA 淹没在正文中。
第 9 节：社区与支持
根据行动类型选择相应渠道 — 不要只列出渠道，却不说明用途：
## Community & Support
- **Discord** — questions, help, show what you built
- **GitHub Discussions** — feature requests, long-form questions
- **GitHub Issues** — bugs only
- **X / Twitter** — announcements, follow for updates
- **Email** — security issues, enterprise inquiries
第 10 节：Star 历史图表
放在底部。用于展示社交认同，而非导航。
[](https://star-history.com/#yourorg/yourrepo&Date)
陡峭的上升曲线表明“这个项目是真实的”。投资人也会看这个。
投资人专门写爬虫查 Star 真假，说明真实口碑就是你最有力的信号。 — (AFFiNE case, Iris Wei @WeiYipei, ep03)
第 11 节：Star CTA GIF——最容易被忽视的转化技巧
一段展示鼠标点击 ★ Star 按钮的短 GIF，能把路过的访客转化为 Star 用户。听起来微不足道，但确实有效。
为什么有效：
- 消除不确定性：许多初次访问者不知道该在哪里点击 Star
- 促成微承诺：观看动画会让人更愿意采取行动
- 感觉自然、不像垃圾信息——不像醒目的「请给我们 Star」文本块
如何制作 GIF（3 种方法）：
| 选项 | 工具 | 耗时 | 质量 |
|---|---|---|---|
| 屏幕录制 + 转换 | QuickTime（Mac）+ Gifox / LICEcap / ScreenToGif | 5 分钟 | ★★★★ |
| 浏览器扩展 | Screencastify 或 Loom → 导出 GIF | 3 分钟 | ★★★ |
| 在线录制工具 | Giphy Capture（Mac） | 3 分钟 | ★★★ |
录制内容（确切步骤）：
- 在浏览器中打开你的仓库，将缩放比例调至 125%
- 缓慢地将鼠标移至 ★ Star 按钮（右上方区域）
- 暂停 1 秒
- 点击——让动画播放（Star 变成黄色）
- 总时长：3–5 秒，循环播放要流畅衔接
GIF 规格：
- 尺寸：宽 400–600px，高度自动
- 时长：3–5 秒，循环播放
- 文件大小：控制在 1MB 以下（确保 GitHub CDN 流畅加载）
- 如果超过 1MB，使用 Ezgif 优化
README 中的放置位置：前三屏，而不是底部
❗️ 大多数仓库都把 Star CTA 藏在底部。到了那时，80% 以上的访客已经离开。 把它放在人们真正能看到的位置。
选项 A——与 Hero 并列（推荐）： 放在标语和徽章之后、Quick Start 之前。趁访客还在考虑是否关注时吸引他们。
## About
Open source Notion alternative. [tagline...]
⭐ **If this looks useful, star it** — it helps others find the project.
选项 B——放在 Quick Start 之后（次优）： 等用户成功运行项目后，趁热打铁。
## Quick Start
```bash
npm install yourproject
觉得有用吗？⭐ 给这个仓库点个 Star——只需 2 秒。
**Option C — Star History at the bottom (in addition to A or B, not instead):**
```markdown
## ⭐ Star History
[](https://star-history.com/#yourorg/yourrepo&Date)
规则：始终使用 A 或 B。C 仅作为额外选项。
将 GIF 存放在仓库中：
yourrepo/
└── assets/
└── star-demo.gif ← commit this
语气建议：
- ✅
"如果这个项目对你有帮助，点个 Star 对我们意义重大" - ✅
"给我们点个 Star，及时获取更新" - ❌
"请务必给我们点个 Star！！！" - ❌
"别忘了点 Star！"（暗示这是义务）
让 GIF 来提出请求，文字就不必开口了。
徽章使用原则 / 徽章使用原则
徽章是信号，不是装饰。每个徽章都在回答开发者的一个问题。
| 徽章类型 | 回答的问题 | 是否添加？ |
|---|---|---|
| 许可证 | 「我可以将其用于商业用途吗？」 | 始终添加 |
| Stars | 「它受欢迎吗／有人维护吗？」 | 始终添加 |
| 最近一次提交 | 「它是不是已经没人维护了？」 | 添加 |
| 构建／CI 状态 | 「它真的能用吗？」 | 添加 |
| 下载量（npm/docker/pypi） | 「真的有人在用吗？」 | 超过 1K 时添加 |
| 代码覆盖率 | 「代码质量是真的吗？」 | 仅当超过 70% 时添加 |
| 版本 | 「哪个版本稳定？」 | 库项目添加 |
| 「使用 X 制作」合作徽章 | — | 除非有要求，否则省略 |
规则：
- 首行徽章不超过 8 个。更多会造成视觉干扰。
- 按含义分组：身份 → 健康状况 → 社区
- 绝不要使用失败的徽章。红色的 CI 徽章比没有 CI 徽章更糟。
常见反模式 / README 常见失败模式
❌ 失败模式 1：罗列功能，却不说明问题背景
Features:
- Real-time collaboration
- Markdown support
- Plugin system
- REST API
- Mobile app
- Dark mode
这完全没告诉我它适合谁，也没说明我为什么需要它。
改进： 从痛点切入。「如果你曾因 [X 发生] 而丢失工作成果，MyApp 可以解决这个问题。」
❌ 失败模式 2：把 Quick Start 藏得太深
Quick Start 排在第二次滚动之后，意味着 60% 的开发者已经离开。
改进： Quick Start 应是第 2 或第 3 节，最多如此。
❌ 死亡模式 3：泛泛的标语
A powerful, flexible, and extensible framework for modern developers.
“强大”“灵活”“可扩展”——每个项目都会这么说。这些都是噪音。
**改进方法：**说清具体痛点、具体类别和具体用户。
**提示词工程中的相似之处：**根据 Anthropic 的指导，含糊的指令（“正确地格式化代码”）会产生不一致的结果。道理相同：含糊的标语会导致读者行为不一致。
❌ 死亡模式 4：首屏没有视觉内容
文字墙 → 文字墙 → 文字墙。开发者会浏览，不会细读。
**改进方法：**在标语之后立即放置主视觉图片或演示 GIF。对 UI 产品而言，这一点不容妥协。
❌ 死亡模式 5：README 只有母语版本
README 以英文为主，首屏 <3 秒读懂。 —（AFFiNE 案例，Iris Wei @WeiYipei，ep03）
README 只有中文或日文，会限制潜在受众。GitHub Trending、HN、Reddit——这些平台都以英语为主。
**改进方法：**以英文作为主要文档。通过徽章或 /i18n/ 文件夹提供翻译版本。
❌ 死亡模式 6：将贡献指南写成文字墙
如果 README 中的 ## Contributing 长达 400 行，它就会被埋在大段文字里，无人阅读。
**改进方法：**用一段话说明，并链接到 CONTRIBUTING.md。README 是落地页。
❌ 死亡模式 7：把 Star 当作虚荣指标
Star 是传播信号。GitHub Trending、搜索排名、投资者尽职调查——这些场景都会用 Star 增长速度作为可信度的替代指标。
AFFiNE 第一周达到 6K Star，第一个月达到 10K Star，累计超过 60K Star。连续 28 次登上 GitHub Trending，背后是两周近乎狂热的社区互动。 —（Iris Wei @WeiYipei，ep01/ep06）
高转化率的 README 能推动 Star 增长 → 带动项目登上 Trending → 带来更多 Star。README 是这个循环的入口。
❌ 死亡模式 8：没有 AI Agent / Claude Code 章节（2025 年及以后）
截至 2025 年，相当一部分 GitHub 访客是 AI 编码 Agent，或者是会通过 Claude Code、Cursor 等工具尝试使用你项目的用户。README 如果没有 AI Agent 集成章节，就错过了一条快速增长的安装路径。
**改进方法：**添加第 7 节：Claude Code / AI Agent 集成。
AFFiNE 核心数据 / AFFiNE 背景数据
以下数据均来自 Iris Wei（@WeiYipei）的播客节目（ep01 / ep03 / ep06）：
| 指标 | 数值 | 来源 |
|---|---|---|
| 第一周 Star 数 | 6,000 | ep01/ep03 |
| 第一个月 Star 数 | 10,000 | ep01 |
| 累计 Star 数 | 60,000+ | ep01/ep03 |
| 登上 GitHub Trending 的次数 | 连续 28 次 | ep06 |
| 标语策略 | “开源版 Notion 替代品”——针对离线使用 / 数据导出 / 隐私痛点 | ep01 |
| 发布时的产品状态 | “套壳”演示（封装演示，尚未完成） | ep03/ep06 |
| 持续登上 Trending 的原因 | 前两周近乎狂热地回复社区消息 | ep06 |
| 首次发布成功的原因 | 发布前准备好开发文档、流量漏斗和内容 | ep01 |
| 投资者信号 | 投资者编写了爬虫来验证 Star 的真实性 | ep03 |
**关键洞察：**产品发布时只是一个封装演示。README 准确击中了痛点。结果：第一周获得 6,000 Star。README 不是产品功能，而是营销层；即使产品尚未完善，它也能独立发挥作用。
发布前自检清单 / 发布前检查清单
每次发布 README 或进行重大更新前都要检查。
首屏（无需滚动）
- Logo / 项目名称清晰可见
- 标语不超过 12 个词，并回答：是什么 + 面向谁 + 解决什么痛点
- 首屏内包含主视觉图片、GIF 或演示视频
- 包含徽章行，徽章不超过 8 个
- 任何视觉元素出现之前都没有文字墙
内容
- 快速入门位于前 3 个章节中
- 快速入门包含 ≤ 5 条命令，并且在全新机器上可运行
- 功能按用户痛点排序，而非按技术实现排序
- 每条功能要点都先说明收益，而非实现机制
- 贡献指南章节 ≤ 1 段，并附上指向 CONTRIBUTING.md 的链接
语言与语气
- 主要语言为英语
- 不使用“powerful”“flexible”“amazing”“robust”——用具体描述替代
- 不要以“我们相信开源”作为前言——直奔主题
- 标语不要以“A”或“An”开头
信任信号
- 提供许可证徽章
- 提供 CI / 构建状态徽章，且状态为通过
- 在页面底部展示 Star 历史图表
- 在前 3 屏内放置 Star CTA GIF（assets/star-demo.gif，<1MB，循环播放 3–5 秒）——不要放在底部
- README 中包含 Discord / 社区链接
- 如果 Star 数 >500，在徽章中显示数量
技术
- 已测试所有链接（无 404）
- 图片托管在 GitHub CDN 上（而非外部）
-
mermaid图表在 GitHub 预览中正常渲染 - 已测试一键部署按钮（如适用）
- README 在移动设备上正常显示（检查 GitHub 移动端）
AI 时代新增项
- **适配 skill：**是否提供清晰的
npx skills add或 MCP 安装命令？ - **适配 GEO：**README 是否包含结构化、机器可读的章节（表格、标题、代码块），方便 AI 系统准确引用？
- **适配 Agent 的快速入门：**Claude Code 的
/runskill 能否从 README 中推断出启动命令，无需自定义 skill 设置？
快速诊断 / 快速诊断
2026 年激活门槛
README 是激活入口，而非宣传册。首屏应将清晰的承诺与直观的演示和最短的可运行路径结合起来。按日期分组跟踪 README visit → install/start → first successful outcome → return。如果用户点了 Star，却无法在约 3 分钟内达到第一个成果，应优先完善前置条件、可复制粘贴的命令、预期输出、故障排查和集成示例，再增加引流。基准数据应标注日期，并注明哪些证据来自自我报告。
有人请你审阅 README 时，请按以下顺序检查：
-
**只读首屏（模拟不滚动页面）。**你对产品了解多少？它面向谁？为什么重要？如果这三个问题无法全部回答，就需要重写标语或主视觉区。
-
**找到快速入门。**数一下它是第几个章节。如果 ≥ 5，就应该上移。
-
**大声读出标语。**它听起来像真人推介，还是功能列表？如果是后者，请按痛点优先的公式重写。
-
**数一数功能。**如果 >7 条要点，请问：哪 3 项能让用户安装？保留这 3 项，其余删掉。
-
**查找大段文字。**贡献指南章节之前，任何超过 5 行的段落都可能是在解释某些图表或演示能更好说明的内容。
-
**检查语言。**主要语言是英语吗？
-
**检查 AI 集成。**是否有 Claude Code / AI Agent 章节？快速入门是否适用于自动安装？（2025 年新增。）
参考资料
Claude Code 官方文档
- Skills — frontmatter 规范、context:fork、allowed-tools、when_to_use
- Memory — CLAUDE.md 四层作用域、有效指令、具体性规则
- 提示工程概览
- Claude Code 文档主页
- 子 Agent
Anthropic 课程
提示工程 / 提示工程
社区资源 / 社区
案例 README / 案例 README
- AFFiNE — 0→60K 星标案例研究（主要参考）
- Dify — 星标数超过 60K 的大模型平台，醒目地放置快速入门内容
- InsForge — Agent 编码后端，简洁的标语 + mermaid 架构图
作者：Iris（生姜 Iris）· AFFiNE 前 COO（0 → 60k★）
整体开源软件增长策略 → 使用 gr-oss-marketing 或 gingiris-opensource
专门用于编写 README → 使用此技能
加入出海社群与购买资料包 · 社区与资源
-
加入出海社群： 微信添加 staywildgrow，留言「加入社群」即可。
-
购买资料包： 微信添加 staywildgrow，咨询购买 Gingiris 出海资料包，价格 599 元人民币。
-
加入全球增长社群： 在微信添加 staywildgrow，发送 “加入社群”。
-
获取资料包： 在微信添加 staywildgrow，购买 Gingiris 全球增长资料包，价格为 599 元人民币。
社群与资料包为可选入口，不影响本开源 Skill 的安装和使用。
社群和付费资料包均为可选内容；安装或使用此开源技能无需加入社群或购买资料包。