Cursor Team Kit 官方发布，团队使用 Cursor 最佳实践完全公开：17 Skills、1 Agent、2 Rules

Cursor Team Kit

Cursor 官方团队把自己在用的 CI、Code Review、发版、测试、清理代码、周报等工作流的 Skills 打包成一个 Plugin，一句指令就能安装：

/add-plugin cursor-team-kit

Cursor Team Kit^[1]

它在做一件容易被忽略的事

大多数 Plugins/Skills 的卖点是"功能"——接入某个服务、生成某种产物。Cursor Team Kit 的卖点不一样，它在做一件更底层的事：把自己团队的工程文化变成可以安装的文件，让我们安装后，就可以一键复制世界顶级 AI 团队的核心工作文化，甚至可以用来开发 Cursor 这样的产品。

官方描述里有两句话特别关键：

Internal workflows used by Cursor developers.

Designed to work without requiring third-party service integrations.

第一句说明它是内部流程的外化，源头来自工程师本人的工位，而不是产品经理画出来的功能列表。

第二句则是一个刻意的克制：它故意不绑 Linear、Jira、Slack、Notion 这类第三方系统。这种"刻意保守"让它具备很强的可移植性——只要你用 Git、GitHub Actions、命令行，这套东西就能直接跑起来。

整个 kit 由三类能力组成，对应 Cursor 体系里三种不同的执行模型：

• Skills（17 个）：模型在合适的时机自己读取并遵循的"操作手册"。
• Sub Agents（1 个）：常驻或可后台运行的角色。
• Rules（2 条）：写进 .cursor/rules/ 的硬性约束，每次生成代码都会作用。

数量分布本身已经透露了 Cursor 的工程偏好：离散、可命名、按需触发的小工具远多于"无所不能的大 Agent"。

Skills 全景：17 个技能拆成四组来读

1. CI 与构建闭环——整个 kit 的骨架

这一组体现的是 Cursor 内部一个非常明确的工程姿态："绿"是默认状态，红了就该有自动化的方式回到绿。loop-on-ci 与下面会讲到的 ci-watcher agent 配合，可以让 agent 在你做别的事时静默盯着流水线，等你回来时它已经把能修的修了。

2. PR 全生命周期——从开分支到合并

这里最值得单独拎出来讲的是 pr-review-canvas。它对应 Cursor 的 Canvas 能力，会把一份 PR 渲染成可点击、可折叠、按类别分组的可视化文档。Cursor 团队自己审 PR 的时候用的就是这个——比 GitHub 默认的 diff 列表信息密度高得多，尤其在 PR 横跨多个模块时差距会非常明显。

3. 验证与质量——这一组最能看出工程品味

verify-this 看似简单，背后的方法论却很硬：任何"我修好了""性能更快了"的结论，都必须配一组 baseline 和一组 treatment 的对照证据。它在用一种近乎科研的纪律，对抗 agent（和人类）最容易犯的错——靠感觉宣布完成。

control-cli 和 control-ui 则是整个 kit 里工程深度最高的两个。它们让 agent 不再停留在"读代码、写代码"，而是真的去运行、操作、量测自己的产物。control-ui 走的是 Chrome DevTools Protocol，等于给 agent 装上了眼睛和手——能截图、能跑 a11y 树、能做视觉 diff、能复现 UI bug。一旦你体验过 agent 自己点进自己写的页面发现问题，再回去看那种"看代码猜逻辑"的工作方式会觉得很原始。

4. 沉淀与回顾——把一次性对话变成长期资产

前两个比较好理解，是把"写周报"这件每个工程师都讨厌的事自动化掉。真正有意思的是 workflow-from-chats——它本质上是一个元技能。当你反复在对话里纠正 agent 的某种风格（比如"别用 inline import""switch 一定要穷尽分支"），它能把这些纠正沉淀下来，自动写成持久化的 rule，下次不必重复说。

这是把"教 AI"这件事，从一次性的口头指令，升级成了可累积的组织知识。

Sub Agent 只有一个，但选得很克制

整个 kit 里只有一个 sub agent：

• ci-watcher：监控当前分支的 GitHub Actions，输出简洁的通过/失败汇总，并附上失败任务的链接。设计上鼓励主动调用——你提完 PR，它在后台帮你盯，省去手动刷 GitHub。

只放一个 sub agent 是有意为之的。Cursor 显然把"长期常驻角色"控制在最小集，把更多复杂逻辑下放给按需触发的 skills。这背后其实是一个很有判断力的取舍：常驻 sub agent 越多，上下文越混乱，行为越难预测。少而精的 sub agent + 大量小 skill，反而更可调试、更可控。

Rules 只有两条，但每一条都"很 Cursor"

• typescript-exhaustive-switch：对联合类型/枚举的 switch 必须穷尽所有分支（通常用 never 兜底）。
• no-inline-imports：所有 import 放文件顶部，禁止函数体内的内联或动态 import。

这两条规则都不花哨，关心的都是同一件事：让代码可以被静态分析、可以被人一眼扫描。它也顺带透露了 Cursor 内部代码库以 TypeScript 为主，并且对"代码可读性"的要求高于对"写法自由度"的容忍。

读完之后，我想说几件更大的事

第一，它把工程文化变成了可分发的文件。

团队文化通常是隐性的——新人靠观察老人慢慢学，文档写了也没人看。Cursor 的做法是把"我们怎么开 PR、怎么修 CI、怎么 review、怎么写周报"全部写成 markdown，交给 agent 执行。这等于把组织 know-how 变成了可以 git clone 的资产。这件事的长远影响可能比这个 kit 本身大得多。

第二，它对"agent 该做什么"给出了一个清晰判断。

17 个 skill，1 个 agent，2 条 rule——这个分布几乎是对当下 agent 行业的一种回应。很多团队在追"超级 agent"，期待一个 agent 能搞定一切；Cursor 内部的实践却显示，把工作流切成离散、可命名、可单独触发的 skill，比一个无所不能的大脑更工程化、更可调试，也更接近真实工程师的工作节奏。

第三，它对"证据"这件事极其较真。

verify-this 要求 baseline/treatment 对照；control-cli 和 control-ui 让 agent 真的去运行；check-compiler-errors 和 run-smoke-tests 都把"执行结果"作为反馈源。这一整套设计透露出一种姿态——对模型的输出天然不信任，凡事要看证据。这种纪律在 LLM 时代格外珍贵。

第四，它的克制比它的功能更值得学习。

没有 Linear、没有 Jira、没有 Slack、没有任何外部 SaaS。这种"刻意不做"的选择，让它能直接落到外部团队的项目里，也让它的核心价值集中在工作方式本身，而不是某个特定生态。

最后：它适合谁，不适合谁

适合：

• 已经在 Cursor 里干活的小团队，想直接借用 Cursor 团队自己的工程节奏。
• 想学习"如何把团队工作流写成 skill"的人——这是目前最权威的开源范例之一。
• 想要一套轻量、不绑 SaaS 的 agent 化 PR/CI 流水线。

不太适合：

• 重度依赖 Linear/Jira 等外部 issue tracker、希望 agent 跨系统串联的团队——这个 kit 故意不碰这一层。
• 不用 GitHub Actions 的项目——大量 skill 需要重写。

一句话总结

Cursor Team Kit 是 Cursor 团队"如何使用 Cursor"的开源版本。

它最大的价值不在于哪个 skill 写得有多神奇，而在于它示范了一种工作方式——把工程纪律、品味、肌肉记忆，统统写进 agent 的配置文件里，让团队的隐性知识变成可执行、可分享、可复用的代码。对任何认真想把 AI agent 嵌进日常开发的人，这都是目前最值得花一个下午通读一遍的参考实现。