My Blog
← Back to home

已安装 Skill 实战指南：从简单原型到微信小程序游戏

已安装 Skill 实战指南：从简单原型到微信小程序游戏

这份文档解决什么问题

你现在已经装了很多 Skill，但真正能提高开发效率的，往往不是“数量最多”的那些，而是能串成闭环的那几个：

  1. 先把需求拆清楚
  2. 再把计划变成任务
  3. 再写代码、查文档、测试、修 CI
  4. 最后把协作动作真正发到 GitHub、Slack、Linear、Notion

这份文档只挑我认为 最重要、最实用、最容易上手 的技能来讲，并给两个完整例子：

  • 一个简单例子：做一个记忆训练 H5 小游戏原型
  • 一个复杂例子：做一个考验人类记忆和推理能力的微信小程序游戏

先讲清楚：怎么“使用一个 Skill”

在 Codex 里，最简单、最稳的方式是 在对话里明确点名这个 Skill。

你可以这样写：

使用 $create-plan，为当前仓库做一个 1 周开发计划。

也可以这样写：

请使用 create-plan 技能，先不要写代码，只输出计划。

经验上，明确点名有三个好处：

  • 不容易触发错 Skill
  • 你能控制 Codex 当前这一轮的工作方式
  • 文档、计划、测试、CI 这些场景更稳定

有些 Skill 还会带脚本或外部依赖：

  • webapp-testing：带 Playwright 测试辅助脚本
  • gh-fix-ci：带 GitHub PR 检查脚本
  • connect：依赖 composio CLI
  • linear、notion-spec-to-implementation、openai-docs：依赖对应 MCP 连接

所以可以把 Skill 理解成两类：

  • 对话型 Skill：你在 Codex 对话里点名，它按说明工作
  • 工具型 Skill：除了对话，还会配合命令、脚本、MCP 或 CLI

我最推荐优先掌握的 Skill

下面这些不是“理论上很强”，而是 实际开发里最常用、最能省时间 的。

第一梯队：先学这 5 个

1. create-plan

适合什么

  • 需求刚来，还没想清楚怎么落地
  • 你想先让 Codex 给一个短小、能执行的计划
  • 你不想它一上来就乱改代码

不适合什么

  • 你已经知道要改哪几个文件，只差直接动手
  • 你要它直接实现，而不是先规划

最小用法

使用 $create-plan，为“记忆训练小游戏”做一个 MVP 开发计划。
要求只输出计划，不写代码。

你要知道的边界

  • 这个 Skill 的核心价值是“产出计划”
  • 它本身是读上下文、做拆解，不负责直接编码

2. openai-docs

适合什么

  • 你要接 OpenAI API
  • 你想确认“最新模型该怎么选”
  • 你需要官方文档、引用、升级建议

不适合什么

  • 你要查微信小程序 API 文档
  • 你要查通用前端框架文档

最小用法

使用 $openai-docs，帮我确认当前最适合做“推理提示”和“短答案判分”的 OpenAI 模型，
并给我一个最小后端调用样例。

你要知道的边界

  • 这个 Skill 优先依赖 OpenAI 官方文档 MCP
  • 如果你没配 openaiDeveloperDocs MCP，需要先连接再重启 Codex

常用准备命令

codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp

通常不需要单独登录。

3. webapp-testing

适合什么

  • 你有本地 Web 应用，需要 Playwright 自动化测试
  • 你要冒烟测试、点按钮、填表单、抓截图、看浏览器日志

不适合什么

  • 你想直接自动化微信开发者工具里的真小程序运行环境

最小用法

先看帮助：

python3 ~/.codex/skills/webapp-testing/scripts/with_server.py --help

然后用它托管本地服务并执行测试：

python3 ~/.codex/skills/webapp-testing/scripts/with_server.py \
  --server "npm run dev" \
  --port 5173 \
  -- python3 tests/smoke_memory_game.py

你要知道的边界

  • 它非常适合测 H5 原型、后台管理页、活动页
  • 对微信小游戏/小程序，建议先做一个 H5 原型或 H5 构建产物来测核心流程

4. gh-fix-ci

适合什么

  • GitHub PR 的 Actions 挂了
  • 你要先定位失败点，再修

不适合什么

  • 你根本没开 GitHub Actions
  • 失败的是外部 CI，日志不在 GitHub Actions

最小用法

先保证 gh 已登录：

gh auth login
gh auth status

检查 PR：

python3 ~/.codex/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --pr "123"

然后在 Codex 里这样说：

使用 $gh-fix-ci，检查当前 PR 的失败 CI。
先总结失败原因和修复计划，等我确认后再改代码。

你要知道的边界

  • 这个 Skill 的正确节奏是：先查日志，再出计划，再修
  • 不要跳过“先看失败上下文”这一步

5. gh-address-comments

适合什么

  • PR review 已经回来了
  • 你要系统性处理 reviewer 的意见

最小用法

先确保 gh 已登录，然后在当前分支 PR 上抓评论：

python3 ~/.codex/skills/gh-address-comments/scripts/fetch_comments.py

在 Codex 里这样说：

使用 $gh-address-comments，列出当前 PR 还需要处理的 review comments，
给每条评论编号并总结需要改什么，然后我会告诉你先处理哪几条。

你要知道的边界

  • 这个 Skill 不是“自动全改”
  • 正确方式是先编号、先归类、再选择性修复

第二梯队：一旦进入团队协作，会非常值钱

6. notion-spec-to-implementation

适合什么

  • 需求或 PRD 在 Notion
  • 你想把规范页直接变成实施计划和任务

最小用法

codex mcp add notion --url https://mcp.notion.com/mcp
codex mcp login notion

然后重启 Codex，再输入：

使用 $notion-spec-to-implementation，把 Notion 里的“记忆侦探”PRD
转成实施计划、任务拆分和进度跟踪页面。

你要知道的边界

  • 它非常适合“产品规范已经写好了”的团队
  • 如果你压根没有 Notion 规范，它就不是第一选择

7. linear

适合什么

  • 你们团队在用 Linear 管需求、缺陷、版本节奏

最小用法

codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp login linear

重启 Codex 后：

使用 $linear，把“记忆侦探”第一期功能拆成 6 个 issue，
挂到指定 team 和 project 下，并按优先级排序。

你要知道的边界

  • linear 是团队节奏工具，不是编码工具
  • 但它能把 Codex 的输出真正推进到项目管理层

8. connect

适合什么

  • 你不是只想“生成一段文案”
  • 你要真的发 Slack、建 GitHub issue、发邮件、改 Notion

准备命令

curl -fsSL https://composio.dev/install | bash
composio login
composio link github
composio link slack
composio link gmail

最小用法

先查工具：

composio search "create a github issue"
composio search "send a slack message"

然后执行：

composio execute GITHUB_CREATE_ISSUE -d '{
  "owner":"my-org",
  "repo":"memory-detective",
  "title":"Implement daily puzzle seed logic"
}'
composio execute SLACK_SEND_MESSAGE -d '{
  "channel":"game-dev",
  "text":"MVP branch is ready for review."
}'

你要知道的边界

  • connect 的价值在“真正执行动作”
  • 一旦配好，你就能把 Codex 从“建议型助手”变成“执行型助手”

9. mcp-builder

适合什么

  • 你想给模型做一个像样的 MCP server
  • 让 AI 可以安全、结构化地访问你自己的后端能力

最小用法

使用 $mcp-builder，为“记忆侦探”后端设计并实现一个 TypeScript MCP server。
工具至少包含 generate_daily_puzzle、judge_answer、get_hint。

你要知道的边界

  • 这个 Skill 很强，但它不是“所有项目都必需”
  • 当你真的需要“模型可调用的工具层”时，它非常关键

一个简单例子：做一个记忆训练 H5 小游戏原型

这个例子故意选得很小，目标是让你看到：几个 Skill 串起来以后，工作流会非常顺。

目标

做一个最小可玩的 H5 游戏：

  • 开始页
  • 记忆页：显示一串数字 5 秒
  • 答题页：让玩家输入刚才看到的数字
  • 结果页：显示正确与否和得分

技术假设：

  • Vite + React
  • 本地开发端口 5173

第 1 步：让 Codex 先出计划

在项目根目录打开 Codex，对它说：

使用 $create-plan，为一个“短时记忆训练”H5 小游戏做 MVP 开发计划。
要求范围只包含开始页、记忆页、答题页、结果页和本地分数统计。
先不要写代码。

这一步的价值是：

  • 先把范围钉住
  • 避免一上来做成“大而全”

第 2 步：让 Codex 按计划实现

计划确认后，直接推进：

按刚才的计划直接实现。
技术栈用 Vite + React，优先保证流程能玩通，再补样式。

第 3 步：用 webapp-testing 做冒烟测试

先创建一个 Playwright 脚本，比如 tests/smoke_memory_game.py：

from playwright.sync_api import sync_playwright
 
with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto("http://127.0.0.1:5173")
    page.wait_for_load_state("networkidle")
 
    page.get_by_role("button", name="开始游戏").click()
    page.wait_for_timeout(5500)
    page.get_by_placeholder("请输入你记住的数字").fill("123456")
    page.get_by_role("button", name="提交答案").click()
    page.wait_for_load_state("networkidle")
 
    assert page.get_by_text("本轮结果").is_visible()
    browser.close()

然后运行：

python3 ~/.codex/skills/webapp-testing/scripts/with_server.py --help
python3 ~/.codex/skills/webapp-testing/scripts/with_server.py \
  --server "npm run dev" \
  --port 5173 \
  -- python3 tests/smoke_memory_game.py

如果你不想自己写测试脚本，也可以直接让 Codex 来写：

使用 $webapp-testing，为当前 H5 小游戏写一个 Playwright 冒烟测试，
覆盖开始游戏、等待记忆结束、提交答案、看到结果页这条主流程。

第 4 步：如果 PR 的 CI 挂了，用 gh-fix-ci

gh auth login
gh auth status
python3 ~/.codex/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --pr "123"

然后在 Codex 里说：

使用 $gh-fix-ci，检查 PR #123 的失败 CI。
先总结失败点和修复计划，等我确认后再改代码。

第 5 步：如果 review 回来了，用 gh-address-comments

python3 ~/.codex/skills/gh-address-comments/scripts/fetch_comments.py

然后这样说：

使用 $gh-address-comments，列出当前 PR 还没处理的 review comments，
按编号总结修改点。我准备先处理前 3 条。

这个简单例子里，Skill 的分工

  • create-plan：先缩范围
  • webapp-testing：保证主流程可玩
  • gh-fix-ci：修 GitHub Actions 问题
  • gh-address-comments：处理 reviewer 反馈

这就是一个很实用的最小闭环。

一个复杂例子：微信小程序《记忆侦探》

现在看一个更像真实项目的例子。

游戏设定

项目名：记忆侦探

核心玩法：

  • 每一局先给玩家一段线索：数字、词语、图案顺序、人物口供
  • 玩家需要在有限时间内记住信息
  • 然后系统提出推理题，例如：
    • “第三个出现的图案是什么？”
    • “证词里谁和时间线矛盾？”
    • “两轮线索合并后，保险箱密码是多少？”
  • 游戏评分同时考验：
    • 记忆准确度
    • 推理正确率
    • 反应时间

为了把例子讲清楚，我先做几个假设：

  • 前端：Taro + React，同时保留 H5 构建用于快速验证
  • 后端：Node.js
  • 需求文档在 Notion
  • 团队任务在 Linear
  • 代码托管在 GitHub
  • 进度通知发到 Slack
  • 游戏中“提示卡”和“每日谜题草案”由 OpenAI 提供辅助生成

总流程概览

这个项目我建议用下面这条链路：

  1. notion-spec-to-implementation：把 PRD 变成实施计划和任务
  2. linear：把关键任务落到团队协作系统
  3. create-plan：基于当前仓库做实际编码计划
  4. openai-docs：确认 OpenAI 能力怎么接最稳
  5. mcp-builder：给题库/提示系统做 MCP server
  6. 普通编码实现：做小程序和后端
  7. webapp-testing：先测 H5 原型和后台，不直接测真机小程序环境
  8. connect：真正创建 issue、发 Slack 消息、同步协作动作
  9. gh-fix-ci：修 CI
  10. gh-address-comments：处理 code review

复杂例子的完整命令和流程

第 0 步：准备外部连接

0.1 连接 Notion

codex mcp add notion --url https://mcp.notion.com/mcp
codex mcp login notion

0.2 连接 Linear

codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp login linear

0.3 连接 OpenAI 文档 MCP

codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp

0.4 安装并登录 Composio

curl -fsSL https://composio.dev/install | bash
composio login
composio link github
composio link slack
composio link notion

注意

  • 上面这些 MCP/登录动作做完以后，通常要重启 Codex
  • 不重启时，新的连接有时不会在当前会话里生效

第 1 步：把 PRD 变成实施计划

在 Codex 里输入：

使用 $notion-spec-to-implementation，把 Notion 里的“记忆侦探”PRD
转成实施计划、任务页面和进度跟踪结构。
请先提炼需求、验收标准、风险点，再创建 plan 和 tasks。

你希望它产出的不是一堆散乱文字，而是：

  • 一个实施计划页面
  • 一组可以执行的任务
  • 明确的验收标准
  • 需要澄清的风险和假设

第 2 步：把关键任务同步到 Linear

使用 $linear，把“记忆侦探”第一期拆成 6 个 issue：
1. 游戏循环
2. 题库结构
3. 每日挑战
4. 积分与排行
5. 分享与拉新
6. 埋点与基础监控
请挂到指定项目并按优先级排序。

这样做的好处是：

  • PRD 不会停留在文档层
  • 开发、测试、产品都能在同一个节奏上协作

第 3 步：回到代码仓库，生成真正的开发计划

使用 $create-plan，基于当前仓库给“记忆侦探”输出 2 周开发计划。
范围限定为第一期：单人模式、每日挑战、基础排行榜、分享卡片。
先不要写代码。

这是非常关键的一步，因为：

  • Notion 计划偏产品和任务
  • create-plan 更偏代码改动顺序、文件影响面、测试策略

第 4 步：确认 OpenAI 在这个项目里怎么接

这个项目里，OpenAI 最适合放在两个地方：

  • 生成“提示卡”草案
  • 生成“每日谜题”候选题，并由你自己的规则系统二次过滤

在 Codex 里这样问：

使用 $openai-docs，帮我确认当前适合做“每日谜题草案生成”和“推理提示卡生成”的 OpenAI 模型。
要求：
1. 优先官方最新文档
2. 给我一个 Node.js 后端最小调用样例
3. 说明哪些部分适合让模型做，哪些部分必须由规则引擎兜底

这一步的核心不是“让模型直接决定答案”，而是：

  • 让模型负责生成候选内容
  • 让你的后端规则系统负责校验正确性和可玩性

这很重要。涉及分数、公平性、题目唯一解时，不要把最终判定全交给模型。

第 5 步：如果要做智能工具层，用 mcp-builder

假设你希望把题库、提示、判题做成一个 MCP server，供未来的运营工具、审核工具、AI 助手共用。

可以直接这样说：

使用 $mcp-builder，为“记忆侦探”后端设计并实现一个 TypeScript MCP server。
至少提供以下工具：
1. generate_daily_puzzle
2. validate_puzzle
3. judge_player_answer
4. get_hint_card
要求：
1. 工具返回结果尽量高信号，不要冗长
2. 错误信息要能指导下一步操作
3. 先给出工具设计，再开始实现

这一步适合的场景是：

  • 你后面想做运营后台 AI
  • 想做自动化审题
  • 想让其他 Agent 安全调用这些能力

如果你只是做一个普通后端接口，这一步可以先跳过。

第 6 步：开始真正编码

这一步不一定要点名 Skill，直接让 Codex 写代码即可：

按刚才确认的计划开始实现第一期功能。
技术栈：
- Taro + React
- Node.js API
优先顺序：
1. 游戏循环
2. 每日挑战
3. 判题与计分
4. 分享卡片
每完成一个模块都补最小测试。

这里的关键是：前面 1 到 5 步已经把“方向、协作、文档、模型能力、工具层”理顺了，编码阶段会顺很多。

第 7 步：用 webapp-testing 测 H5 原型和后台

这里要特别强调一遍：

webapp-testing 适合测 H5 构建产物、活动页、后台管理页，不直接替代微信开发者工具里的真实小程序环境。

正确用法是：

  • 小程序核心玩法先做一个 H5 原型或 H5 构建
  • 用 Playwright 验主流程
  • 真机和微信开发者工具的验证另做补充

先写一个 H5 测试脚本，比如 tests/e2e_memory_detective.py：

from playwright.sync_api import sync_playwright
 
with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto("http://127.0.0.1:3000")
    page.wait_for_load_state("networkidle")
 
    page.get_by_role("button", name="开始侦探挑战").click()
    page.wait_for_timeout(3000)
    page.get_by_role("button", name="进入答题").click()
    page.get_by_label("第一个问题").fill("蓝色钥匙")
    page.get_by_role("button", name="提交本轮答案").click()
    page.wait_for_load_state("networkidle")
 
    assert page.get_by_text("本轮得分").is_visible()
    browser.close()

然后用 Skill 自带脚本托管服务：

python3 ~/.codex/skills/webapp-testing/scripts/with_server.py --help
python3 ~/.codex/skills/webapp-testing/scripts/with_server.py \
  --server "npm run dev:h5" \
  --port 3000 \
  -- python3 tests/e2e_memory_detective.py

如果你的后台管理页也要测，可以再加一个 server：

python3 ~/.codex/skills/webapp-testing/scripts/with_server.py \
  --server "npm run dev:api" \
  --port 4000 \
  --server "npm run dev:h5" \
  --port 3000 \
  -- python3 tests/e2e_memory_detective.py

第 8 步：用 connect 真正推动协作动作

比如你想在阶段 1 完成后：

  • 在 GitHub 建 3 个 issue
  • 往 Slack 发一条同步消息

可以先查工具：

composio search "create a github issue"
composio search "send a slack message"
composio execute GITHUB_CREATE_ISSUE --get-schema
composio execute SLACK_SEND_MESSAGE --get-schema

然后真正执行：

composio execute GITHUB_CREATE_ISSUE -d '{
  "owner":"my-org",
  "repo":"memory-detective",
  "title":"Implement daily puzzle seed and deterministic replay"
}'
composio execute GITHUB_CREATE_ISSUE -d '{
  "owner":"my-org",
  "repo":"memory-detective",
  "title":"Build scoring rules for memory + reasoning rounds"
}'
composio execute SLACK_SEND_MESSAGE -d '{
  "channel":"game-dev",
  "text":"记忆侦探第一期进入联调阶段：H5 原型可玩，题库和计分逻辑已接通。"
}'

如果你更希望 Codex 代你执行，可以直接这样说：

使用 $connect，在 GitHub 为当前项目创建 2 个 issue，
并向 Slack 的 game-dev 频道发送一条进度同步消息。

第 9 步：PR 挂了，用 gh-fix-ci

gh auth login
gh auth status
python3 ~/.codex/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --pr "123"

然后对 Codex 说：

使用 $gh-fix-ci，检查 PR #123 的失败 Actions。
先告诉我哪一步挂了、关键日志片段是什么、你准备怎么修。
我确认后你再改代码。

这一步的重点是：

  • 让修复建立在日志和上下文上
  • 而不是“凭感觉乱改”

第 10 步：review 回来了，用 gh-address-comments

python3 ~/.codex/skills/gh-address-comments/scripts/fetch_comments.py

在 Codex 里输入：

使用 $gh-address-comments，列出当前 PR 的 review threads 和 comments，
为每条评论编号并总结改动范围。
我会先让你处理 1、2、5 号评论。

然后继续：

先处理 1、2、5 号评论，改完后告诉我每条评论分别改了什么。

这样你能把 review 过程变得非常清晰，而不是在 PR 页面里来回翻。

复杂例子里，最值得你记住的 5 个原则

1. 先把“文档世界”和“代码世界”打通

  • notion-spec-to-implementation 负责把 PRD 变成计划和任务
  • create-plan 负责把计划变成代码层面的执行顺序

这两个不要混为一谈。

2. 不要把“模型能力”直接当成“业务真相”

在《记忆侦探》这种有分数、公平性、可复盘要求的游戏里：

  • 模型可以生成候选题和提示
  • 规则系统必须负责校验、计分、唯一解和复盘

3. webapp-testing 先打 H5 原型，不要硬碰真机环境

这是非常实用的工程策略。

你先把核心玩法在 H5 上自动化回归，很多逻辑 bug 会提前暴露出来。

4. 协作动作要真正发出去

如果你只让 Codex“帮你写一段 issue 文案”，那价值其实很有限。

connect 的价值是：

  • 真创建 issue
  • 真发 Slack
  • 真把动作落到外部系统

5. CI 和 review 是闭环，不是收尾小事

很多团队的问题不在“不会写代码”，而在：

  • 计划做了，但 CI 不稳
  • 代码交了，但 review 改不动

所以 gh-fix-ci 和 gh-address-comments 非常值得早学。

我会怎么给这些 Skill 排学习顺序

如果你现在就开始练，我建议顺序是：

  1. create-plan
  2. webapp-testing
  3. gh-fix-ci
  4. gh-address-comments
  5. openai-docs
  6. connect
  7. notion-spec-to-implementation
  8. linear
  9. mcp-builder

理由很简单：

  • 前 4 个最贴近日常编码闭环
  • 第 5 个解决“如何正确接 OpenAI”
  • 第 6 到 8 个解决团队协作落地
  • 第 9 个是更偏平台化、Agent 化的进阶能力

最后给一个最短可抄的使用模板

如果你以后拿到一个新项目，不知道该怎么用这些 Skill，直接照这个顺序开始：

1. 使用 $create-plan，先输出开发计划，不写代码。
2. 按计划开始实现 MVP。
3. 使用 $webapp-testing，为主流程写 Playwright 冒烟测试。
4. 如果要接 OpenAI，使用 $openai-docs 查官方最新方案。
5. 如果要同步外部系统，使用 $connect 执行真实动作。
6. 如果 GitHub CI 挂了，使用 $gh-fix-ci。
7. 如果 PR review 回来了，使用 $gh-address-comments。

如果这个项目本来就有 PRD 和团队协作系统，再加上：

8. 使用 $notion-spec-to-implementation，把 PRD 变成实施计划和任务。
9. 使用 $linear，把任务真正落到团队节奏里。
10. 如果要做模型可调用的工具层，使用 $mcp-builder。

这套方法最大的价值不是“会很多 Skill”，而是你开始拥有一条稳定的工程工作流。