宿主负责模型和编码
Claude Code、Cursor、Codex、Trae 这些宿主继续负责联网、调用工具、改代码和运行项目。
- 支持宿主
- 17
- 流水线阶段
- 12
- 关键门禁
- 3
- 开源许可
- MIT
当前宿主覆盖
Why Super Dev
宿主继续写代码，Super Dev 负责把流程拉直。
接入后，宿主会按统一的研发顺序、门禁和交付要求工作。
Super Dev 负责流程治理
需求进入后先做 research、三文档和确认，再进入 Spec、实现、质量和交付。
输出是可审计交付资产
PRD、架构、UI/UX、Spec、运行验证、质量报告和交付归档都会落成产物。
Who It Is For
适合已经在用 AI coding、但不想继续靠运气交付的人。
它适合已经把 AI 放进日常开发、现在需要更稳流程和更强交付控制的人。
AI coding 重度个人开发者
你已经大量使用 Claude Code、Cursor、Codex 或 Trae，但希望每次输出都更稳、更完整、更接近真实交付。
小团队 / 创业团队
你们要快速做 MVP、快速验证商业可行性，但不想让 AI 开发过程失控，也不想把代码和决策都埋进聊天记录里。
需要规范宿主开发流程的项目团队
你们要让不同成员在不同宿主里保持同样的流程纪律、质量标准和交付证据。
Use Cases
四类最常见的落地场景。
下面这些场景最能体现它的价值。
从 0 到 1 做 MVP
输入需求后，先研究同类产品，再生成三文档、Spec 和前端验证，快速做出可演示、可验证的 MVP。
接手已有项目继续开发
先生成代码库地图，再分析改动影响范围，然后补文档和约束，让宿主按流水线接手。
统一团队里的 AI 开发流程
不同成员可以继续使用各自习惯的宿主，但 Super Dev 统一触发方式、协议面、质量门禁和交付产物。
把宿主从直接写代码拉回商业交付路径
当宿主倾向于直接开始开发时，Super Dev 强制它先 research、先三文档、先确认，再进入实现。
Pipeline
从需求到交付，固定走同一条路径。
入口很短，流程很固定。宿主接到需求后按研究、文档、确认、实现、验证、交付推进。
Research 与需求增强
先读取本地知识库，再联网研究同类产品，补全边界条件、异常路径和验收口径。
三文档与 Spec
先生成 PRD、Architecture、UI/UX，再让用户确认，确认通过后才创建 Spec 与任务清单。
前端优先与后端联调
先把前端做出来并运行验证，再进入后端与联调，避免在不可见状态下盲目堆代码。
质量与交付
UI Review、红队检查、交付包、发布演练和 release readiness 一起定义是否能交付。
关键门禁
三文档确认门
没有用户确认，不允许创建 Spec，也不允许开始编码。
前端运行验证门
没有 frontend runtime 通过证据，不允许进入后端与中后段。
交付 ready / rehearsal passed 门
交付包未 ready 或发布演练未通过，不能宣称完成交付。
Host Support
不同宿主，不同协议；触发方式只有两种。
先记住该输入什么。commands、AGENTS、steering、rules、skills 这些接入面放在文档里展开。
Slash 宿主
/super-dev这些宿主直接输入 /super-dev 你的需求。
Claude CodeCodeBuddy CLICodeBuddyCursor CLICursorGemini CLIiFlowKiro CLIOpenCodeQoder CLIQoderWindsurfAntigravity
Text-trigger 宿主
super-dev:这些宿主使用 super-dev: 你的需求。
Codex CLIKimi CLIKiroTrae
宿主矩阵
认证兼容实验性
| Host | 触发 | 协议面 | 成熟度 |
|---|---|---|---|
| Claude Code | /super-dev | commands + subagents | 认证 |
| CodeBuddy CLI | /super-dev | commands + skills | 兼容 |
| CodeBuddy | /super-dev | commands + skills | 实验性 |
| Codex CLI | super-dev: | AGENTS.md + skills | 兼容 |
| Cursor CLI | /super-dev | commands + rules | 兼容 |
| Cursor | /super-dev | commands + rules | 实验性 |
| Gemini CLI | /super-dev | commands + GEMINI.md | 兼容 |
| iFlow | /super-dev | commands + skills | 实验性 |
| Kimi CLI | super-dev: | AGENTS.md + text trigger | 兼容 |
| Kiro CLI | /super-dev | commands + AGENTS.md | 兼容 |
| Kiro | super-dev: | project steering + global steering | 实验性 |
| OpenCode | /super-dev | commands + skills | 实验性 |
| Qoder CLI | /super-dev | commands + skills | 兼容 |
| Qoder | /super-dev | commands + rules + skills | 实验性 |
| Windsurf | /super-dev | workflows + skills | 实验性 |
| Antigravity | /super-dev | commands + GEMINI.md + workflows | 兼容 |
| Trae | super-dev: | project rules + compatibility skill | 兼容 |
Proof / Trust
可信度来自可验证的证据。
开源、已发布、多宿主、本地知识库、质量门禁和交付产物，都直接展示给用户。
MIT 开源与 PyPI 发布
代码可见、安装路径清晰、版本可追踪，版本升级和分发路径也足够明确。
多宿主接入
同一套治理逻辑可安装到 CLI 和 IDE 宿主，不要求用户迁移到新的开发工具。
本地知识库优先
knowledge/ 和 knowledge bundle 会优先进入 research、三文档、Spec、质量与交付。
UI Review 与 Release Readiness
运行验证、质量门禁和发布检查都会明确产出结果，方便判断项目是否达到交付标准。
交付产物可审计
交付清单、质量报告、运行验证和 release readiness 都会落盘，便于复盘、交接和审查。
How it works
从安装到交付，入口始终很短。
先安装并进入宿主引导，再在宿主里触发流程。后续的文档、门禁、运行验证和交付产物会沿着这条路径持续生成。
Terminal
pip install -U super-dev
# 或
uv tool install super-dev
# 进入宿主安装引导
super-dev常见问题
这里说明产品定位、接入方式和工作流程。
宿主负责模型、联网、调用工具、改代码和运行项目。Super Dev 负责研究顺序、三文档、确认门、前端运行验证、质量门禁和交付标准。
提示词模板只影响当前对话。Super Dev 会安装到宿主接入面，并持续维护确认门、运行验证、质量门禁、交付状态和 release readiness。
Spec 工具主要规范项目规格。Super Dev 规范的是宿主里的 AI 开发过程，从 research、三文档、Spec、前后端、测试到交付都在同一条流水线上。
这类宿主使用 super-dev: 作为文本触发词，再通过 AGENTS、rules、steering 或 skills 等官方接入面理解并执行 Super Dev 流程。用户记住触发方式即可，不需要自己处理底层协议。
先接入宿主，再开始按流程开发。
安装 Super Dev，运行 super-dev 完成宿主接入，然后在宿主里输入 /super-dev 或 super-dev:。从 research 到交付的关键门禁会接管后续流程。
也可以使用 uv tool install super-dev