先装上，再回宿主开始真正的开发。
这页不是协议字典，而是把你从安装带到“宿主第一句”和“安装后 5 分钟”的公开主路径。真正重要的是：装完就回宿主，第一轮先 research，再写三文档并等待确认。
先安装 CLI。然后在终端输入 super-dev，进入宿主安装引导并写入所需接入面。
uv tool install super-dev
super-dev
super-dev update
super-dev uninstallv2.4.0 强化重点
v2.4.0 当前强化重点
2.4.0 继续把产品拉回“宿主内交付工具”这个核心：默认项目优先接入、统一宿主矩阵、标准流 / SEEAI 双模式准备度、宿主首句与恢复剧本、以及更清晰的安装后先验；同时把 UI 设计合同升级成更少 AI 味、更强调视觉方向和工艺审查的系统。
项目优先接入默认化
onboard / setup / install / start 默认只写项目级协议面；用户级 / 系统级 surface 改成显式 opt-in，不再默认污染全局 AGENTS。
统一宿主矩阵
CLI、IDE 和桌面助手都已并入统一矩阵；Claude / Claude Code、Codex / Codex CLI、Trae 系列都拆成了独立条目。
宿主首句与恢复剧本
每个宿主现在都明确给出标准流第一句、比赛流第一句、恢复方式和修复优先级，不再只有泛化触发词。
标准流 / SEEAI 双模式准备度
宿主报告会明确区分“标准流可直接开工”和“SEEAI 比赛模式可直接开工”，不再把文件已写入误判成宿主已跑通。
当前项目焦点
安装器和 smoke guide 会直接告诉用户当前项目更该先看哪类页面、哪类预览和哪类交付证据。
安装后先验
安装器会直接显示接入后应该先确认什么，避免用户一装完就误以为已经可以稳定开工。
项目级 SEEAI 补充面
标准项目接入之外，super-dev-seeai 的项目级 skill/plugin 补充面也进入正式闭环，比赛模式不再靠手工补文件。
UI 设计反 AI 味升级
UI 契约新增视觉方向候选、主视觉哲学、反 AI 味护栏和五维设计批评标尺；截图级视觉门会把过平、过空、模板味过强的页面直接卡在质量与交付链外。
核心路径
真正的开发，从回到宿主开始。
终端只做安装、升级和清理。真正的第一轮发生在宿主里：research、三文档、确认门、Spec、实现、预览验证、质量门和交付都沿着同一条主路径推进。
终端只做接入
安装器负责把当前宿主接好，让用户知道下一句该怎么说。
宿主里完成第一轮
research、三文档、确认门和第一轮前端预览都在宿主里推进。
关键产物都会落盘
research、PRD、Architecture、UI/UX、Spec、运行验证和交付证据都会写回项目。
安装方式
安装方式
终端只负责接入、升级和卸载。官网首页默认展示 uv 安装；源码安装和版本锁定安装都留在安装文档里。这里主要回答三件事：不会替你装哪些宿主本体、安装器会帮你写什么、以及回宿主后第一句输入什么。
安装说明
- 首页和主文档默认使用 uv 安装 Super Dev。
- 不会自动安装 Claude、Codex、Cursor、Trae、Gemini CLI 等宿主本体。
- 终端输入 super-dev 后，安装器会按项目优先写入当前宿主需要的接入文件；用户级增强面只在显式 opt-in 时补。
- 安装完成后会直接显示推荐宿主、标准流第一句、比赛流第一句和接入后先验；Droid CLI 已纳入统一矩阵。
uv tool install super-dev
# 打开安装引导
super-dev
# Droid CLI / Claude Code / Codex 等宿主都在安装器中统一接入
# 终端公开维护入口
super-dev update
super-dev uninstall安装后 5 分钟
安装后 5 分钟
这里决定用户会觉得产品丝滑，还是觉得只是又一个安装页。终端在安装后就应该退场，用户马上回宿主里复制首句、看框架焦点、按烟测指南确认宿主真的在按商业项目流程工作。
先离开终端
安装、升级、卸载都在终端里做；真正开发不要停留在终端维护命令里。
- 完全关闭宿主并重开项目
- 在新会话里继续，不要沿用旧聊天上下文
- 把终端留给 install / update / uninstall
直接复制宿主第一句
不要自己概括，不要先铺背景。先用安装后烟测指南里的标准流第一句或比赛流第一句，让宿主准确进入 Super Dev 流水线。
- 标准项目复制“标准流第一句”
- 比赛项目复制“比赛流第一句”
- 宿主第一轮必须明确 research 和三文档确认门
先按烟测和首句走
不要自己概括流程。先用安装器给出的标准流第一句或比赛流第一句，再按烟测确认宿主真的进入了 research → 三文档 → 等确认的主路径。
- 复制首句，不要自己改写
- 先用 smoke guide 看第一轮回复
- 确认 research / 三文档 / 等确认这三件事都被宿主明确说出来
把 UI 当交付门，而不是后修饰
截图级视觉门会正式卡掉过平、过空、模板味太重的页面，所以应该从第一轮 UI 方案就要求宿主做出更强的视觉方向。
- 先锁 art direction，再做页面
- 不要接受占位稿式的平 UI
- UI review / quality / release 会继续吃这一层信号
安装器会写什么
安装器会写什么
你不需要记住每个宿主的文件路径。安装器会把当前宿主需要的项目级接入文件写好，可选的用户级增强面只有在你显式选择时才补。
当前项目里的接入文件
默认先写当前项目真正需要的文件，让宿主在这个项目里知道什么时候进入 Super Dev。
- 优先当前项目
- 先让这个仓库跑通
- 不默认污染全局
可选的用户级增强面
只有你明确 opt-in 时，安装器才会补常用宿主的用户级增强面，用来减少后续重复接入。
- 不是默认路径
- 面向常用宿主和个人习惯
- 先以项目级为主
真正会持续累积的项目产物
研究、三文档、Spec、运行验证和交付证据，才是这条主路径真正会继续累积的东西。
- knowledge/
- output/*
- .super-dev/changes/*
宿主第一句
宿主第一句
大多数用户只需要记住自己宿主的第一句。Slash 宿主用 /super-dev，Codex CLI 用 $super-dev，文本宿主用 super-dev:；更细差异放到矩阵里。
Slash 宿主
Slash当安装器已经把当前宿主需要的项目级接入文件写好时，直接用这句进入 Super Dev。Codex App/Desktop 也会把启用的 super-dev Skill 暴露进 `/` 列表。
文本触发宿主
文本触发文本宿主不靠 slash 列表，直接把这句作为项目入口；安装器会告诉你它当前是不是已经 ready。
宿主矩阵
宿主矩阵
看这张表时只关心三件事：你会先输入什么、Super Dev 会先读什么、以及这个宿主现在是不是已经准备好进入标准项目或 SEEAI。
CLI
12IDE
9桌面助手
5流水线
流水线
入口命令很短，真正重要的是后面的阶段纪律。宿主接到需求后会按研究、文档、确认、实现、验证和交付推进。
同类产品研究
先使用宿主联网能力研究同类产品、交互模式、差异化机会和商业信号。
需求增强
把边界条件、异常路径、验收口径和优先级补足，避免模糊需求直接进编码。
三份核心文档
生成 PRD、Architecture、UI/UX 三文档，形成可审计的执行基线。
用户确认门
三文档完成后强制暂停，用户确认前不得创建 Spec 或继续编码。
Spec / Tasks
确认通过后生成变更提案与任务清单，收紧范围和顺序。
前端优先
先做前端、先跑起来、先可审查，再进入后端和联调。
后端与联调
完成 API、服务、数据层和真实交互闭环。
质量门禁
执行 UI Review、红队、安全、性能和架构阈值检查。
交付与最终检查
只有当交付包、预览验证和最后一轮检查都完成后，这个项目才算真的结束。
宿主里怎么继续
流程控制
公开主路径里，不再要求用户记住一串终端治理命令。安装完成后，继续、返工、确认、补充，都优先在宿主里用自然语言推进。
继续改三文档
用户补需求、业务范围变化、或者需要重做方案时，不用回终端跳阶段，直接在宿主里继续围绕三文档修改。
/super-dev 这里补一下业务范围，先继续改 PRD / Architecture / UIUX，不要开始编码
super-dev: 这个方案还不对，继续改三文档并等待我再次确认继续当前阶段
UI 重做、接口调整、交付前复检，都优先在宿主里继续当前流程，不再把普通用户赶回终端。
/super-dev 继续当前流程
/super-dev 现在下一步是什么
super-dev: 继续当前流程，不要重新开题确认关键门
文档确认、前端预览确认、UI 改版闭环、架构返工闭环、质量整改闭环，都优先在宿主里明确回复。
/super-dev 文档确认，可以继续
/super-dev 前端预览确认，可以继续
super-dev: UI 改版已完成，继续当前流程
super-dev: 质量整改已完成，继续当前流程研究、预览与交付门
研究、预览与交付门
真正把产品拉出“会写代码但交付不稳”的，是 research、预览验证和交付门，而不是一大串底层命令。
知识库优先
当 knowledge/ 和 knowledge-bundle 存在时，宿主必须先读本地知识，再做外部研究。
- research 前置知识读取
- PRD / Architecture / UI/UX 阶段化映射
- quality / delivery 继续复用基线
改动前先看影响范围
接手旧仓库、修改登录流、重构 API 或动关键状态流前，先跑 repo-map、feature-checklist 和 impact，把范围覆盖率、受影响模块和回归重点确认清楚。
- super-dev repo-map
- super-dev feature-checklist
- super-dev impact "变更描述" --files ...
代码库理解与回归守卫
复杂仓库不要靠宿主临场猜结构。先生成依赖图，再把影响分析转换成可执行的回归清单。
- super-dev dependency-graph
- super-dev regression-guard "变更描述" --files ...
- 先补回归重点再修改关键路径
前端运行验证门
必须有 frontend-runtime 报告通过，中后段才允许继续；如果当前项目冻结了 framework playbook，还要把框架专项执行与交付证据一起纳入验证。
- preview.html
- frontend-runtime.json
- 真实预览证据与交付材料
- 运行通过后再进后端
质量与交付门
UI 评审、规范完整度、交付包和最后一轮检查共同定义“是否可交付”；截图级视觉门会正式阻断那些仍然过平、过空、模板味太重的页面。
- UI Review
- Screenshot-level visual gate
- Spec Quality
- Final delivery checks
只需要记住的入口
只需要记住的入口
公开主路径只需要两个地方：终端里的安装/更新/卸载，和宿主里的第一句 / 继续 / 确认。其余 CLI 仍然存在，但属于维护和高级排障，不是普通用户日常操作面。
终端公开入口
uv tool install super-dev
super-dev # 进入宿主安装引导
super-dev update # 更新到最新版
super-dev uninstall # 清理宿主注入面宿主内正常使用
/super-dev 你的需求
/super-dev 继续当前流程
/super-dev 现在下一步是什么
/super-dev 文档确认，可以继续
super-dev: 你的需求
super-dev: 继续当前流程
super-dev: 质量整改已完成，继续当前流程排障
排障
大多数问题都出在宿主没有重新加载当前项目的接入文件。先确认安装器写出的项目级文件存在，再确认宿主已重开并用了新会话。
排查顺序
- 1重新运行 super-dev，确认安装器仍然识别到当前宿主。
- 2确认安装引导输出的项目级与用户级接入面真实存在。
- 3完全关闭宿主，重新打开项目，并新建一个会话。
- 4先用 smoke 触发语句。
- 5如果宿主直接开始开发，优先判断当前会话没有重新加载规则。
Smoke 验收
# slash 宿主
/super-dev "请先不要开始编码，只回复 SMOKE_OK，并说明你会先做 research、再写三文档并等待确认。"
# 非 slash 宿主
super-dev: 请先不要开始编码，只回复 SMOKE_OK，并说明你会先做 research、再写三文档并等待确认。