最近两天，X 上一条名为 “Shopify 内部备忘录” 的帖子火了，原文很长值得细品。其实在这个帖子之前，Andrej Karpathy 大神就提出过 “Vibe coding”。没想到短短两月，AI 就从氛围编程变成了职场必备技能！我很早也写过两篇关于 AI 的思考，提到过类似观点：关于 AI 时代的一些思考，AI 浪潮下的一些浅思。

📌 Vibe coding

Vibe coding（也称 vibecoding）是一种依赖大型语言模型（LLM）来生成软件的全新编程方式，由 Andrej Karpathy 于 2025 年 2 月提出，并被《韦氏词典》在次月收录为“俚语 & 热门”名词。其核心在于，开发者只需用自然语言向 LLM 提出需求或描述问题，即可让系统自动生成并修正代码。开发者更多地充当“提示提供者”和“测试者”的角色，而不是手动编写或阅读大量代码。在实践中，人们往往反复将需求或错误信息输入给 LLM，让它修复或改进代码，而不必深入理解技术细节。本质上，Vibe coding 让编程过程更偏向于“与 AI 协同对话”，甚至有时只需“看看、说说、跑一下、然后复制粘贴”，就能完成一个相对完整的项目或 Web 应用。

原文阅读

为避免歧义，除译文外，还放了原文。

在 Shopify，熟练使用 AI 已成为基本要求

背景：本文是 Shopify 的内部备忘录，因泄漏风险故主动公开，以防被恶意曲解。

我们正在步入一个空前的时代，更多商家和创业者可能涌现。我们经常提到，要降低创业的复杂性曲线，让更多人能将创业作为自己的事业。创业路上的每一步，都充满需要技能、判断力与知识的决策。如果 AI 能陪伴整个旅程，不仅提供咨询，甚至直接帮商家完成具体工作，这将是一场令人震惊的质变飞跃。

Shopify 的使命，就是让我们的软件成为未来最佳企业诞生的绝佳“画布”。我们要确保所有人始终站在前沿，提供最先进的工具，使商家能超越他们曾经的想象取得成功。为此，我们必须保持绝对领先。

从现在起，熟练且本能地使用 AI 是 Shopify 的基本要求。

或许你已经达到这个状态，并觉得本备忘录有些多余。你可能已经把 AI 作为自己的思想伙伴、深入研究的助手、批评家、导师，甚至是结对编程的同伴。我本人就经常如此使用 AI，但即使是我，也觉得目前只是冰山一角。这是我职业生涯中见过的最快速的工作方式转变，我在每周的视频、播客、公司大会、峰会上不断强调这一点。去年夏天，我用 AI Agent 制作了演讲，并以此为例，号召每个人积极尝试 AI，消除质疑与困惑。许多同事积极响应，亲自体验后，我们对 AI 增强技能、完善专业能力、补足短板的新能力感到惊叹。

到目前为止，我们发现，有效使用 AI 是一种特殊技能，只能通过频繁使用慢慢掌握。AI 与以往的工具截然不同。过去鼓励大家“尝试使用 AI” 还是一种建议，但今天我要把这种建议变成明确要求。AI 不同于以往工具，它本身就是一种效能倍增器。我们每个人身边都有一些卓越的同事，他们的贡献往往是常规预期的十倍，而现在，我们第一次看到工具本身也能达到 10 倍效能。我见过许多同事通过熟练、直觉性的使用 AI，成功完成了原本不可能或不敢触碰的任务，获得百倍成果。

几年前，我曾在《论领导力》中形容 Shopify 像《爱丽丝梦游仙境》里的“红皇后竞赛”，你必须拼命奔跑才能保持原地不落后。在一家每年增长 20-40% 的公司，你每年必须至少进步同样比例才能合格。这同样适用于我和每个人。

这听起来可能令人生畏，但考虑到如今 AI 的特性，我甚至觉得这种要求已经不算非常雄心勃勃了。而且，这恰恰是我们最顶尖员工最渴望的环境：与他人共同学习，解决有意义且充满挑战的问题。这正是 Shopify 创立的初心，紧密契合我们的核心价值观：“持续学习”与“拥抱变化”。

这意味着：

1. 熟练使用 AI 已成为每个 Shopify 员工的基本要求。 AI 是今天所有工作的工具，它的重要性只会增加。坦率地讲，拒绝学习 AI 技巧是不现实的，选择停滞即意味着失败。
2. GSD 原型阶段必须包含 AI 探索。 GSD 项目的原型阶段，应主要用于通过 AI 快速实验和学习。原型就是为了探索和创造信息，AI 极大地加速了这个过程。
3. 绩效考核和同侪评估中将增加对 AI 使用情况的考察。 很多人写了个 prompt 得不到想要结果就放弃了。掌握提示工程（prompting）和有效上下文加载技巧很关键，我们需要通过评估和反馈提高大家的使用能力。
4. 自我导向学习，但要共享成果。 公司已提供了 chat.shopify.io、proxy、Copilot、Cursor、Claude code 等先进工具供开发者使用。我们将在 Slack 和 Vault 上分享成功与失败案例，每月业务审查与产品开发周期也会纳入 AI 集成进度的汇报。
5. 各团队在申请额外人力和资源前，必须证明为什么不能用 AI 完成任务。 思考一下，如果你团队中已经有自动化 AI 代理，那会是什么样子？这类问题将带来有趣的讨论和创意。
6. 所有人都必须参与，包括我和高管团队。

前进之路：AI 将彻底改变 Shopify，我们的工作和生活。我完全投入其中，也想不到比在 Shopify 更好的地方参与这场空前变革。我们的任务，是重新定义一个全民 AI 的世界中，创业的模样。我相信，通过我们共同的努力，Shopify 的未来会更加接近我们的使命。我们需要每个人将自己的技能和抱负与 AI 倍增，共同造福于我们的商家。

小结

Shopify CEO 对 AI 的定位，意味着 AI 不再只是工具，而是企业生存和竞争的核心能力；将 “AI 使用能力”纳入绩效评估，使这一能力从可选变为必需，并要求在申请新资源前先尝试通过 AI 完成任务，凸显 “AI 优先”的资源配置理念和对“虚拟员工”角色的认同。此举或许看似严格，却也折射出企业在面对 AI 冲击的应对策略：持续学习，拥抱变化。在未来企业竞争中，谁能更快、更有效地运用 AI，谁就能在生产力、创新和原型开发等领域占得先机，无法适应 AI 的企业将逐渐被淘汰，这一趋势极有可能成为业界共识。

Vibe coding

读完 Shopify 内部备忘录，我们再来详细聊聊 vibe coding，这算是一个新兴的 AI 热门词，但社区讨论度却极高（搜索关键词，可以看到很多有趣的编程案例）。

“Vibe coding” 并不是让我们完全抛弃开发基础，而是将“构思—验证—迭代”这一过程与 AI 技术深度结合，用更自然的对话方式取代冗长的手动编码。只要你合理设置规则、分解需求、勤于测试和回退，就能在 AI 的辅助下，高效地完成各种个人或团队项目，并在这个过程中不断积累对技术和架构的理解。Peter Yang 大佬总结了 12 条 vibe 规则，我对其进行了二次梳理，给出以下更通用版本技巧。感兴趣的可以阅读原文：12 Rules to Vibe Code Without Frustration^[1]

Vibe 技巧

1. 以 “AI 需求沟通”为开端

在开始任何项目之前，先通过自然语言与 AI 讨论需求与目标，让 AI 为你生成一份简要规划，包括：

• 项目需求
• 技术栈建议
• 若干里程碑（如 3-5 个）

这一步相当于让 AI 先充当“项目经理（PM）”，你只需进行简单确认和微调。这样不仅帮你理清思路，也能让 AI 了解项目的整体方向。

2. 尽量选择简洁明了的技术栈

越复杂的技术栈，AI 引入问题的可能性越大。除非有特殊需求，否则你可以：

• 仅使用前端技术（HTML/CSS/JS 等）或极简的后端
• 不急于上线：先在本地或最基础的环境中跑起来

复杂的框架、数据库或服务器配置会增加 AI 出错的几率，尤其当其对新版本库不够熟悉时。

3. 提前给 AI 充足的上下文与规则

• 了解 AI 的知识边界：AI 通常有特定的“知识截止”日期，可能对最新版本的库并不了解。你可以先问 AI 熟悉哪个版本，再按其范围引导，避免它出现版本混淆。
• 提供相关文档：需要集成特定 API 或框架？直接把官方文档或示例贴给 AI，它将更快、更准确地完成配置或调用。
• 设置通用与项目规则： 如“先让我确认再写代码”、“不重复已有代码”、“只修改指定部分”等。这些规则可以帮助 AI 避免大范围改动或做出无关修改。对于多次复用的策略，也可以整理成一份“全局规则”并在每个新项目中引用。

4. 先要思路，后要代码

一个很有效的提示语是：“先告诉我你的计划，不要急着写代码。”

• AI 往往喜欢做“超纲”操作，如果不给它展现思路的机会，就可能一次性写一堆冗余或复杂的代码。
• 让 AI 先说明实现方案，你可以对其做简化或方向调整，减少后续调试负担。

5. 要求多种可行方案，选最简单的

在遇到复杂功能时，可以让 AI 列出几个实现思路，从最简单的开始。然后根据项目需求与个人偏好，选择难度或复杂度适当的方案。

• 可以通过类似“请长时间思考，并提出你需要我补充的任何信息”来鼓励 AI 提问、澄清。
• 始终记住，“简单可行”往往比“花哨繁复”更省心。

6. 持续提醒 AI 保持简洁

AI 常常像一个过度热情的实习生，会自动添加额外功能或引入第三方库。若你只想先完成核心功能，可以在提示语里加入：

• “尽量保持简单”
• “只实现我能快速测试的部分”
• “请仅修改（指定文件）”

必要时，分拆需求到不同的对话或聊天窗口，避免让 AI 同时处理过多上下文而出错。

7. 借助图片或示例提升准确度

无论是设计界面还是定位某个 UI Bug，一张截图往往比长篇描述更有效。

• 贴上截图、错误提示或输出结果的截图，AI 会更清晰地理解问题场景。
• 对 AI 来说，这些视觉或示例数据就是重要的“上下文线索”。

8. 每次提交都进行小步测试

不管多小的改动，都应该在本地环境快速跑起来，看看是否有报错或新问题。

• 打开浏览器调试控制台（Console）查看报错信息
• 若有条件，可让 AI 辅助写自动化测试，但最基础的手动验证也必不可少
• 确保每个小里程碑都功能可用，才继续下一步，避免问题大规模积累

9. 果断回退，避免“越改越乱”

很多 IDE 或 AI 辅助工具都有“回退到历史版本”的功能。一旦觉得 AI 修改得离谱或出现死循环，不要犹豫，直接回退到先前稳定的版本。

• 定期让 AI 检测并报告可能的冗余或重复代码，以便及时清理
• 不要被“当前还能运行”蒙蔽，如果 AI 做了过多无关改动，将来维护成本可能会更高

10. 使用版本控制（如 GitHub）

对完全没编程基础的人而言，也建议学会最基础的 Git 提交流程：

1. 注册 GitHub 并创建仓库
2. 本地或通过 IDE（如 Cursor）的“一键提交”功能，将代码推送到远程仓库
3. 把里程碑或较大功能完成后再 commit，以便在出问题时还能回溯到任意阶段

GitHub 或类似平台是多一层安全保障，也是团队协作、分享代码的关键。

11. 语音交互让 “vibes” 更到位

如果你想将 “vibe coding” 变得更有沉浸感，可以使用语音识别/输入工具（如 Superwhisper^[2]、WisprFlow^[3]），一边说话一边让 AI 写代码。

• 这种方式类似于在和 “AI 开发助理”对话，效率和体验都相当不错
• 相比不停地打字，语音指令可能更具创造力，也更能激发灵感

12. 让 AI 帮你学习和理解

虽然 vibe coding 强调“快速产出”，但也可借机提升自己的技术洞察：

• 对单个文件，可以让 AI 用通俗易懂的方式解释其逻辑或加上详细注释
• 对整个项目，可以把全部代码合并后，让大模型做整体架构分析
• 通过“读”代码理解它的运作方式，而不是机械地记代码语法

当你明白了各部分是怎么协作的，就算不精通编程，也能对项目有全局把握。

案例分享

氛围编程时代，prompt 依然很重要。上面的技巧描述可能有些抽象，为了更直观具体，@mattpocockuk^[4] 大佬写了一个关于 MCP 的开发教程，以 prompt 形式呈现。如果还不了解 MCP，可以看之前的文章：深度解析：Anthropic MCP 协议，浅谈 Agent、MCP、OpenAI Responses API。

Prompt 放在 Gist 上（Build an MCP server in Cursor^[5]），方便大家阅读，我把它整理出来了，分为 5 个 markdown 文件。

Prompt 1

核心需求：我们要使用 TypeScript 搭建一个新的 MCP 服务器。开始是一个空目录，需要创建项目的基本骨架，安装必须的依赖，搭好项目结构，并且在每次提交时，都要记录“重要文件”到 .cursor/rules/important-files.mdc 中。

需要做什么？

1. 在空目录下初始化一个 TypeScript 项目。
2. 使用 pnpm 安装依赖，比如 @modelcontextprotocol/sdk, zod 等，以及对应的开发依赖（TypeScript、tsx、@types/node）。
3. 设置 package.json，包括 scripts（如 build、dev）和基本项目元信息（bin, type 等）。
4. 配置 tsconfig.json，启用严格模式以及一些推荐的编译选项，把编译结果放到 dist 目录下。
5. 创建一个简单的入口文件 src/main.ts，其中示例演示了如何创建一个 MCP Server，定义简单的工具（如加法工具），以及如何用 stdio 传输。
6. 建立并更新 .cursor/rules/important-files.mdc，列出项目中“重要”的文件路径，保证每次新增文件都记录进去。
7. 运行 pnpm build 验证能否成功编译。

一句话概括：用 TypeScript、pnpm 初始化一个 MCP 服务器项目，写好 package.json、tsconfig.json、src/main.ts 入口文件，并确保所有关键文件都写进 .cursor/rules/important-files.mdc。

## Problem

We want to set up a new MCP server, written in TypeScript. We are starting from an empty directory.

We are writing this in Cursor, so recording the important files in a `.cursor/rules/important-files.mdc` file is important.

We need to set up the basic file system for the project, install necessary dependencies, and set up the project structure.

## Supporting Information

### Tools

#### `pnpm`

Use `pnpm` as the package manager.

### File Structure

Recommended file structure:

#### `.cursor/rules/important-files.mdc`

A file that lists the important files for the project, which should be included in every chat.

Use the `mdc` format, which is a markdown format with these frontmatter fields:

```md
---
globs: **/**
alwaysApply: true
---

...content goes here...
```

Make sure to add a directive at the end of the file that if new files are added, they should be added to the `important-files.mdc` file.

#### `package.json`

The package.json file for the project.

Recommended scripts:

`build`: Builds the project using `tsc`.
`dev`: Runs the project in development mode using `tsx watch src/main.ts`.

Dependencies:

- `@modelcontextprotocol/sdk`: The MCP SDK. Latest version is `0.9.0`.
- `zod`: A schema declaration and validation library for TypeScript.

Dev dependencies:

- `tsx`: A faster version of `ts-node` that is optimized for the CLI.
- `typescript`: The TypeScript compiler, latest version: `5.8`
- `@types/node`: The types for Node.js, for 22+

`bin` should be set to `dist/main.js`.

`type` should be set to `module`.

#### `tsconfig.json`

The TypeScript configuration file for the project. Here is the recommended configuration from Matt Pocock's TSConfig cheat sheet.

```jsonc
{
  "compilerOptions": {
    /* Base Options: */
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "allowJs": true,
    "resolveJsonModule": true,
    "moduleDetection": "force",
    "isolatedModules": true,
    "verbatimModuleSyntax": true,

    /* Strictness */
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,

    /* If transpiling with TypeScript: */
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "sourceMap": true,

    /* AND if you're building for a library: */
    "declaration": true,

    /* If your code doesn't run in the DOM: */
    "lib": ["es2022"]
  },
  "include": ["src"]
}
```

#### `src/main.ts`

The entry point for the project.

```ts
import {
  McpServer,
  ResourceTemplate,
} from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// Create an MCP server
const server = new McpServer({
  name: "Demo",
  version: "1.0.0",
});

// Add an addition tool
server.tool("add", { a: z.number(), b: z.number() }, async ({ a, b }) => ({
  content: [{ type: "text", text: String(a + b) }],
}));

// Add a dynamic greeting resource
server.resource(
  "greeting",
  new ResourceTemplate("greeting://{name}", { list: undefined }),
  async (uri, { name }) => ({
    contents: [
      {
        uri: uri.href,
        text: `Hello, ${name}!`,
      },
    ],
  })
);

// Start receiving messages on stdin and sending messages on stdout
const transport = new StdioServerTransport();
await server.connect(transport);
```

#### `.gitignore`

A file that lists the files to ignore in the project. `dist` should be ignored since it is the output directory.

## Steps To Complete

- Create the `package.json` file with the recommended scripts and dependencies.
- Use a `pnpm add` command to install the dependencies so that they are pinned to the current version. Do NOT use `latest` or `next`.
- Install the dependencies.
- Create the `tsconfig.json` file with the recommended configuration.
- Create the other files described above.
- Run `pnpm build` to build the project.

Prompt 2

核心需求：把 MCP 服务器和 GitHub 连接起来，能对 GitHub 的 issues 和 pull requests 做一些操作。要使用 Octokit 库，并且要将和 GitHub 交互的函数以及相关的 MCP 工具都写好。

需要做什么？

1. 添加 .env 文件来存放 GitHub 的访问令牌等敏感信息，并把 .env 加入到 .gitignore 中，确保不会被提交到版本库。
2. 安装 octokit，用它和 GitHub API 交互（获取 issue、PR 数据，创建评论等）。
3. 在 src/github.ts 或类似文件中封装和 GitHub 的通信逻辑，比如：获取 issue、获取 PR、创建/更新 issue/PR、列出 issue/PR 等。
4. 在 MCP 服务器里，通过 server.tool() 方式把这些封装好的操作暴露出去，每个工具都要带有名称和描述（方便 MCP 客户端知道这个工具是干什么的）。
5. 删除示例中的“加法工具”等不再需要的 demo 工具，换成 GitHub 相关的工具。
6. 依旧要维护好 .cursor/rules/important-files.mdc 文件，把所有关键文件加进去。

一句话概括：把 octokit 引入项目，用 .env 管理 GitHub 凭证，编写并注册新的工具让 MCP 服务器可以对 GitHub issues 和 PRs 进行操作。

## Problem

Our MCP server currently doesn't do anything. We want to hook it up to GitHub so that it can respond to issues and pull requests.

## Supporting Information

### Octokit

We are using Octokit to interact with GitHub.

`pnpm add octokit`

Octokit methods should be put in their own file, in `src/github.ts`.

```ts
import { Octokit } from "octokit";

const octokit = new Octokit({ auth: `personal-access-token123` });
```

Environment variables can be put in a `.env` file.

### `tsx` and `.env`

You can pass `.env` to `tsx` by using the `--env-file` flag.

```bash
tsx watch --env-file=.env src/main.ts
```

### Always Declare Tool Descriptions.

When calling `server.tool()`, you can pass in both a name and a description. For instance:

```ts
server.tool(
  "createPullRequestComment",
  "Create a comment on a pull request",
  {
    owner: z.string(),
    repo: z.string(),
    pullNumber: z.number(),
    body: z.string(),
  },
  async ({ owner, repo, pullNumber, body }) => {
    const comment = await github.createPullRequestComment(
      { owner, repo },
      pullNumber,
      body
    );
    return {
      content: [{ type: "text", text: JSON.stringify(comment, null, 2) }],
    };
  }
);
```

This should be done for all tools, since it helps the MCP client understand the tool and its capabilities.

## Steps To Complete

- Ensure that `.env` is added to the `.gitignore` file.
- Get the user to add a GitHub token to `.env`.
- Ensure that `.env` is being loaded into the environment when running the `dev` script.
- Install `octokit` as a dependency.
- Create functions for issues and pull requests:
  -`getIssue`: Get an issue by number.
  -`getPullRequest`: Get a pull request by number.
  -`createIssueComment`: Create a comment on an issue.
  -`createPullRequestComment`: Create a comment on a pull request.
  -`updateIssue`: Update an issue.
  -`updatePullRequest`: Update a pull request.
  -`listIssues`: List issues for a repository.
  -`listPullRequests`: List pull requests for a repository.
- Remove the demo tools from the existing MCP server.
- Add those tools to the MCP server.
- Ensure that all major files are added to the `.cursor/rules/important-files.mdc` file.

Prompt 3

核心需求：将服务器原本依赖的 stdio 传输方式替换成基于 SSE（Server-Sent Events） 的传输方式，以便我们可以用更灵活的方式和服务通信。需要引入 express 并用它来实现 SSE。

需要做什么？

1. 安装 express，并且添加对应的类型声明包（如 @express/types）。
2. 在代码中移除对 StdioServerTransport 的依赖，改用 SSEServerTransport。
3. 用 Express 搭建一个简易的服务端接口：
• GET /sse 用于初始化 SSE 连接
• POST /messages 用于接收消息并转发给服务器
4. 让原本的 MCP 服务器实例（server.connect(transport)) 通过 SSE 方式来发送和接收数据。
5. 继续保持 .cursor/rules/important-files.mdc 的更新，保证新增或修改的文件都被记录。

一句话概括：使用 express+SSE 替换之前的 stdio 传输方案，添加对应的路由代码，并完成 SSE 连接，让 MCP 服务器通过 SSE 与外部交互。

## Problem

Our server currently only works over `stdio`. We may want to convert it to work over SSE instead.

## Supporting Information

So far, I have only been able to get SSE working using the `express` framework.

Latest version is `5.1.0`. Latest version of `@express/types` is `5.0.1`.

```bash
pnpm add express
```

```ts
import express from "express";
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";

const app = express();

let transport: SSEServerTransport | undefined = undefined;

app.get("/sse", async (req, res) => {
  transport = new SSEServerTransport("/messages", res);
  await server.connect(transport);
});

app.post("/messages", async (req, res) => {
  if (!transport) {
    res.status(400);
    res.json({ error: "No transport" });
    return;
  }
  await transport.handlePostMessage(req, res);
});

app.listen(8080, () => {
  console.log("Server is running on port 8080");
});
```

## Steps To Complete

- Install `express`
- Remove the `stdio` transport.
- Add the `sse` transport.
- Ensure that all major files are added to the `.cursor/rules/important-files.mdc` file.

Prompt 4

核心需求：项目里的文件变得过大，为了让 Cursor 或其他协作方容易理解代码，我们要把它拆分成更细的模块，比如按 “GitHub 相关功能” 和 “工具相关逻辑” 分目录存放。

需要做什么？

1. 识别现在的代码里有哪些功能混在一起，可以拆分的部分有两类：
• github-functions：跟 GitHub 交互有关的内容
• tools：要提供给 MCP 服务器的各种工具（这些工具可能会用到 github-functions）。
2. 根据功能、领域不同，把大文件拆分成多个小文件，目录层次大致像：

    src/
      github-functions/
       ...
      tools/
       ...
   

3. 每个新文件只负责一块相对单一的逻辑，比如 github-functions/issues.ts 专门处理 issue 相关的函数，tools/issueTools.ts 专门定义 issue 工具等。
4. 更新 .cursor/rules/important-files.mdc，保证拆分后生成的所有重要文件都列出来。

一句话概括：按照 “GitHub 函数”和“工具”两个主题，把代码整理到不同文件和目录里，让每个文件的职责单一，便于后续维护。

## Problem

The files are getting a bit too big. We want to break them up into smaller chunks to make them easier for the Cursor agent to understand.

## Supporting Information

We have two concepts in the repo: `tools` and `github-functions`.

-`github-functions` are the way that we connect to GitHub
-`tools` are the things that get attached to the MCP server. `tools` contain `github-functions`.

We want to break up the large files we have into smaller chunks, using a file structure which reflects the relationship between `tools` and `github-functions`.

## Steps To Complete

- Break up the large files into smaller chunks, using the file structure above.

- Each file may contain multiple `github-functions` or `tools`, but they should be split by domain.

- Ensure that all major files are added to the `.cursor/rules/important-files.mdc` file.

Prompt 5

核心需求：在 MCP 服务器中添加一组函数和工具，用来查看和管理 GitHub Actions 的状态（比如列出 Actions、查看状态、获取详情、取消或者重试等）。

需要做什么？

1. 先看看已有的 GitHub 连接逻辑，复用或在原有基础上新增针对 GitHub Actions 的 API 调用。
2. 在 github-functions 相关文件里，新增相应的函数：
• listActions / getActionStatus / getActionDetails / cancelAction / retryAction，并注意一定要包含 page 和 per_page 参数。
3. 在 tools 里，把这些操作包装成 MCP 工具（server.tool()），方便外部调用。
4. 继续更新 .cursor/rules/important-files.mdc，把新增文件或修改的地方列入其中。

一句话概括：添加针对 GitHub Actions 的查询、管理功能（列出、查看、取消、重试等），将对应函数作为新工具接入 MCP 服务器，确保 .cursor/rules/important-files.mdc 得到更新。

## Problem

I want to be able to check the status of actions on the MCP server.

## Supporting Information

Always ensure that `page` and `per_page` are included in the request parameters, even if the API doesn't require them.

## Steps To Complete

- Look at the existing implementations of functions and tools in the correct directory. Load them into your context window.

- Add functions to:

  - List the actions in a repository.
  - Get the status of an action.
  - Get the details of an action.
  - Cancel an action.
  - Retry an action.

- Add those functions as tools to the MCP server.

- Ensure that all major files are added to the `.cursor/rules/important-files.mdc` file.

33 条致胜创意

最后，我想分享 @gregisenberg^[6] 给出的 33 条小建议，希望它们可以成为你 “vibe coding” 路上的参考：

1. 定价即产品，不仅仅是数字
2. 有用的东西会被使用，美观的东西会被分享
3. 在「vibe coding」之前，先让市场感受到氛围（vibe market）
4. 打造一款「截图也好看」的产品
5. 与产品「谈恋爱」，与趋势「结婚」
6. 在某一件事上做到 10 倍提升，而不是在所有事上仅 10% 提升
7. 先拥有受众，再打造产品
8. 从看起来「太小」的利基市场开始
9. 累积小优势：域名、设计、分发渠道
10. 在不为人知时默默打磨，上线时要像名人般亮相
11. 坏点子很礼貌，好点子则显得有点疯狂
12. 先关注「激活」，再考虑「获客」
13. 跟着「特立独行」的人走，他们总是先发现未来
14. 添加社交功能应像送礼物，而不是增加义务
15. 无视竞争对手，多研究追随者
16. 做产品时可以「丑陋快速」，宣传时要「精美得体」
17. 你的第一个产品只是楔子，并不是终局
18. 令人愉悦的体验是“软而暖”的功能，可带来持续回报
19. 把最初的 100 位用户当作联合创始人对待
20. 解决「问题背后的问题」
21. 创造有趣的内容，让你的产品自然而然地成为解决方案
22. 围绕内容创作建立系统
23. 对品牌和名字要极度关注——这是人们记住的核心
24. 小步快跑，频繁发布
25. 将「达成价值」的时间比竞争对手做得更短
26. 在他人隐瞒时，选择透明
27. 做出用得越久越好的产品
28. 站在两个趋势的交汇处
29. 让超级粉丝成为分销者
30. 让每个用户/粉丝都有机会成为联盟合伙人
31. 把产品流程设计成一连串的「小胜利」
32. 当别人都在走企业化路线时，你要更「私人化」
33. 社会变革无法通过 A/B 测试来验证

References