产品定位：

• 宿主负责模型调用、联网搜索、代码产出、终端执行与文件修改
• Super Dev 负责图纸生成、流程治理、设计约束、质量门禁、审计产物与交付标准

换句话说：

• 宿主是执行者
• Super Dev 是产品总监、架构师、设计总监、技术教练和 QA 负责人组成的指导系统

它解决的是“宿主会写代码，但不一定会稳定交付”的问题：

• 将需求沉淀为可落地工件：PRD、架构、UI/UX、Spec、任务清单与交付清单
• 将开发过程组织为标准化流水线：可追踪、可恢复、可审计、可复盘
• 将质量控制前置到每个阶段：策略治理、红队审查、质量门禁、发布演练
• 将多宿主协作统一到同一套工程规范：12 个 CLI、9 个 IDE、5 个桌面助手按项目优先注入，共享同一交付标准
• 将知识库与验证规则自动推送到每个阶段：知识驱动治理，而非依赖人工检查
• 将宿主训练成“能稳定做出精品商业项目”的团队，而不是让用户自己拼流程、拼审美、拼质量门

5 分钟上手

普通用户先记住 1 条安装命令和 3 个终端命令：

uv tool install super-dev

# 进入宿主接入引导
super-dev

# 更新到最新版，并迁移已接入宿主
super-dev update

# 清理已注入的宿主接入面
super-dev uninstall

5 分钟路径

1. 在项目目录运行 super-dev
2. 让安装器自动检测宿主并写入项目级接入面；只有明确需要跨项目复用时才补用户/全局接入面
3. 打开 output/maintenance/host-onboard-smoke-*.md
4. 先看 标准流第一句 / 比赛流第一句
5. 再看 接入后先验、框架焦点、官方工作流检查
6. 回到宿主里触发第一句，观察它是否按 research -> 三文档 -> 等待确认 进入流程

如果这 6 步成立，你拿到的不是“装好了一个工具”，而是“把当前宿主训练成了这个项目的交付教练”。

终端只做 3 件事

• 接入
• 升级
• 卸载 / 预演清理

接入完成后，正常使用都回到宿主里。普通用户第一眼只需要记住：

/super-dev 你的需求
super-dev: 你的需求
/super-dev-seeai 比赛需求

更细的入口差异不要靠记忆硬背，直接看安装后生成的 host-onboard-smoke，复制里面的 标准流第一句 或 比赛流第一句 即可。

正确心智：

• 终端只负责接入、升级与卸载
• 宿主才负责 baseline、research、三文档、确认门、Spec、实现、质量门禁与交付
• 普通开发不要离开宿主主路径；如果不是在做接入、诊断、治理收尾或兼容修复，就不要先回终端找阶段命令
• 自动判断会在接入/升级阶段发生，但不会在普通开发流程里越层改宿主配置
• 已接入 与 已验证 是两回事：文件落盘不代表宿主已经真实跑通
• 已有项目不是直接开干：evolve / variant / patch 必须先做 baseline -> baseline confirmation，再进入差量 research 和三文档
• 恢复是默认场景：关窗口、关电脑、第二天继续，都优先按 .super-dev/ 与 output/ 工件恢复当前流程

工作模式：

• new：从 0 到 1 的新项目
• evolve：已有项目增量迭代
• variant：基于现有项目派生 1-N+1 版本
• patch：已有项目缺陷修复
• resume：中断后的恢复继续

记住一个原则：安装完成后，终端基本就该退场。真正开发回到宿主里，先复制 标准流第一句 或 比赛流第一句，再按 smoke guide 做首轮验收。

SEEAI 赛事极速版：

• 入口：/super-dev-seeai 或 super-dev-seeai:
• 仍然保留 research -> 三文档 -> docs confirm -> spec
• 但 spec 之后直接进入前后端一体化快速开发，不再拆预览确认门
• 适合 30 分钟左右的官网、小游戏、展示型工具、单页 demo

只有在接入、诊断、兼容修复或治理收尾时，才需要回终端。普通用户只需要记住：

super-dev
super-dev update
super-dev uninstall

维护者补充：

• 安装/接入后烟测指南会落到 output/maintenance/host-onboard-smoke-*.md
• 如果当前项目已经冻结了 framework playbook，安装后烟测指南会直接显示 框架焦点（Framework Coaching Focus）、必验场景和交付证据
• 卸载预演或正式清理会落到 output/maintenance/host-cleanup-*.json/.md
• 如果只是想先看会删什么，用 super-dev uninstall --dry-run
• 升级完成后先重开终端并执行 super-dev --version；如果宿主没有进入 research -> 三文档 -> 等待确认，再回终端跑 doctor
• 如果第一轮 UI 看起来过平、过空、模板味太重，不要指望“最后再补美化”；截图级 UI gate 会在 UI review、quality gate、proof-pack 和 release readiness 里继续拦截
• 正式发版文档 docs/PUBLISHING.md 与 docs/RELEASE_RUNBOOK.md 只属于维护者，不是普通用户上手路径。

其余 detect / doctor / review / quality / release / spec / task 都属于维护面，只在报告明确要求时由维护者进入。

说明：

• skill / integrate 只用于宿主接入、兼容性审计和真人验收，不属于日常开发主路径
• config / enforce / generate 属于内部维护能力，不是普通用户入口
• onboard / detect / doctor / run / review / release 允许保留，但应视为维护面而不是普通用户心智
• 真正的项目开发仍应回到宿主里，优先使用 /super-dev 或 super-dev: 开题，并直接说“继续当前流程”“现在下一步是什么”
• 如果你在已有项目里做增量开发，不要先在终端里手工跳阶段，先让宿主完成 baseline -> baseline confirmation，再进入差量文档和实现
• 如果只是回来继续昨天的活，不要先回终端找 run / jump / confirm，优先在宿主里直接说“继续当前流程”

交付与卡点处理仍然存在治理入口，但它们属于维护面，不应当成普通用户命令目录：

• product-audit：范围缺口与实施覆盖率体检
• release readiness / proof-pack：发布证据与交付闭环
• review *：维护者同步 gate 状态或修订状态

普通用户仍应优先回宿主里说“继续当前流程”“现在下一步是什么”。

核心功能

1. 11 专家 Agent 架构

当前内置 11 个领域专家 Agent，每个专家在对应阶段自动注入到 AI 提示词中，约束宿主按专业标准执行：

| 专家 | 角色 | 注入阶段 | |------|------|----------| | PRODUCT | 产品负责人 | research, prd, quality, delivery | | PM | 产品经理 | research, prd | | ARCHITECT | 系统架构师 | architecture | | UI | 界面设计师 | uiux, frontend | | UX | 交互设计师 | uiux, frontend | | SECURITY | 安全工程师 | architecture, backend, quality | | CODE | 开发工程师 | frontend, backend | | DBA | 数据库工程师 | architecture, backend | | QA | 质量工程师 | quality | | DEVOPS | 运维工程师 | delivery | | RCA | 根因分析师 | quality, delivery |

每个专家具备四层武装：Profile（目标定义、背景故事、思维框架、质量标准）+ Knowledge（阶段知识自动推送）+ Rules（验证规则绑定）+ Protocol（交叉审查协议）。每位专家配备 350+ 行深度 Playbook 操作手册，生成的 AI 提示词超过 600 行，确保每个阶段的输出符合该领域的专业基线。

2. UI 智能设计系统

内置完整的设计智能引擎，直接约束前端实现阶段的视觉质量：

• 119 套配色方案：84 套产品配色 + 35 套美学配色，全部自动生成暗色模式
• 39 个组件库：覆盖 11 个前端技术栈（React 15 / Vue 9 / Angular 4 / Svelte 2 / 其他）
• 17 套字体预设：基于 Google Fonts 中国镜像，按产品调性分类
• 完整 Design Token 体系：色阶、阴影、动效、排版、间距
• 12 项交付前检查清单：A11y、响应式、暗色模式、加载态、空态、错误态等
• 10 个行业定制：教育、医疗、电商、金融科技、SaaS、社交、内容、企业、工具、游戏

UI/UX 文档不再只是建议，而是会冻结成一份真正的 UI 契约：

• output/*-uiux.md
• output/*-ui-contract.json
• output/frontend/design-tokens.css
• output/*-ui-contract-alignment.md
• output/*-ui-contract-alignment.json

宿主提示词、实现约束、UI review、frontend runtime、quality gate、proof-pack、release readiness 都会围绕这份 UI 契约继续执行。

关键治理证据：

• UI review 与 UI contract alignment
• frontend runtime 运行证据
• proof-pack 与 release readiness 摘要

它们共同用于持续检查 UI 契约有没有真的落到源码和交付结果中。

3. 流水线编排引擎

• 新项目主链：research -> docs -> docs_confirm -> spec -> frontend -> preview_confirm -> backend -> quality -> delivery
• 已有项目主链：baseline -> baseline_confirm -> delta research -> docs -> docs_confirm -> spec -> frontend -> preview_confirm -> backend -> quality -> delivery
• 检查点与中断续传：流水线中断后可从断点恢复，不丢失进度
• 阶段超时保护：每个阶段设有超时机制，防止无限等待
• 确认门控制：三文档完成后必须等待用户确认，前端预览完成后必须等待用户确认
• 阶段恢复：宿主可以通过自然语言恢复到目标阶段，高级阶段跳转只保留给维护场景
• UI 改版回路：UI 不满意时可在宿主里发起正式改版回路，先更新 UIUX 文档再重做前端
• 适配 0-1 与 1-N+1：新建项目走完整流水线，已有项目先 baseline 再走增量分析路径
• 继续当前流程路由：内部恢复与状态命令共享同一套 workflow state 与 action card
• 恢复状态卡：.super-dev/SESSION_BRIEF.md 和 .super-dev/workflow-state.json 会沉淀“当前动作 / 宿主第一句 / 机器侧动作 / 连续性规则”
• 关键时间线：流程快照、语义事件、Hook 事件会汇总成统一的 recent timeline，进入 SESSION_BRIEF、Workflow Harness、proof-pack 与 release readiness
• 返工优先级：文档确认门、预览确认门、UI 改版、架构返工、质量整改都进入统一状态机，不再靠用户记命令

4. 文档生成引擎

Super Dev 为每个阶段生成初始文档框架，宿主大模型在此基础上结合用户需求、联网研究和专家知识进行深度完善：

| 文档 | 内容 | |------|------| | PRD | 用户画像、功能矩阵、验收标准、竞品对标、商业规则 | | Architecture | 系统架构、数据模型、接口契约、安全策略、部署方案 | | UIUX | 设计 Token、页面骨架、组件清单、交互状态、响应式策略 |

宿主根据需求深度生成文档内容，最终产出的文档规模取决于项目复杂度和需求范围。支持 10 个行业领域定制：教育、医疗、电商、金融科技、SaaS、社交、内容、企业、工具、游戏。

补充说明：

• 新功能开发默认走完整流水线：research -> 三文档 -> 用户确认 -> Spec / tasks -> 前端运行验证 -> 后端 / 测试 / 交付
• 缺陷修复同样不会直接跳过文档；会走轻量补丁路径，先整理问题现象、复现条件、影响范围和回归风险，再更新补丁文档与验证结果
• 分析阶段默认排除 .venv、site-packages、node_modules 等非项目源码目录

5. 质量门禁体系

• 验证规则引擎：25 条 YAML 声明式规则（14 默认 + 11 红队），支持项目级自定义覆盖
• 质量顾问：不只说"不达标"，还给出具体修复建议（Quick Wins 优先排序）
• Spec-Code 一致性检测：自动比对 Spec 描述与实际代码实现，防止偏离
• A11y 无障碍检查：自动验证页面的无障碍标准合规性
• 性能预算校验：检查资源大小、加载时间等性能指标
• 红队审查：从安全、性能、架构三个维度对系统进行攻防审查
• 修复命令建议：检测到问题后直接给出可执行的修复指令
• 策略治理：default / balanced / enterprise 三级预设
• Spec 质量评分：对任务规格进行结构化评分
• 发布就绪面板：统一展示发布前所有门禁检查结果
• UI 契约执行检查：质量门禁会检查 ui-contract.json、design-tokens.css、frontend runtime 与 UI 对齐报告是否一致

6. 宿主接入治理

• 支持 26 个主流宿主统一接入（12 CLI + 9 IDE + 5 桌面助手）
• 新增 Droid CLI 官方 .factory 宿主接入：AGENTS.md + .factory/rules + .factory/skills，.factory/commands 仅作为兼容增强面
• 自动生成宿主规则文件、/super-dev 映射、Skill 目录
• detect / onboard / doctor / setup / install / start 形成接入闭环
• 通过宿主能力边界建模，明确哪些宿主是 Certified / Compatible / Experimental
• --dry-run 预览模式与 --stable-only 稳定模式
• --save-profile 写入 super-dev.yaml 并用于质量门禁
• doctor、detect、start 默认会输出决策卡：推荐宿主、推荐理由、第一步动作、候选宿主、路径覆盖修复提示
• 决策卡、安装向导与 runtime 报告会直接给出 标准流第一句 / 比赛流第一句 / 接入后先验 / 官方工作流检查 / 修复剧本
• 宿主准备度会明确区分 标准流可直接开工 和 SEEAI 比赛模式可直接开工
• 支持 Windows 注册信息、shim 目录、常见路径和 SUPER_DEV_HOST_PATH_<HOST> 自定义路径覆盖
• 显式指定宿主时，系统会围绕你指定的宿主给建议，不再被自动检测结果带偏

7. 产品审计与范围缺口

• product-audit：从产品、交互、闭环和代码结构角度生成总审查报告
• 区分“流水线已经走完”和“范围是否真的做完”
• 为 proof-pack、release readiness、质量整改提供范围缺口输入

8. 可审计交付

• proof-pack：交付证据汇总与 executive summary
• release readiness：发布就绪度检查
• frontend runtime / UI Contract Alignment / quality gate：前端、设计契约与质量门禁闭环
• delivery manifest/report/archive：交付包与归档产物
• pipeline metrics / knowledge tracking / validation report：作为内部证据进入交付闭环，不属于普通用户主入口

9. 知识库系统

Super Dev 内置结构化知识库（knowledge/ 目录），270+ 个知识文件、15 万行深度内容，覆盖 23 个技术领域：

• 架构：微服务、API 网关、分布式事务、配置管理、服务治理
• 安全：DevSecOps、SAST/DAST/SCA、容器安全、合规自动化、密钥管理
• 运维：可观测性、AIOps 异常检测、容量规划、混沌工程、SLO/SLI
• 云原生：容器编排、服务网格、无服务器架构
• 数据工程：数据管线、流处理、数据治理
• 设计：UI 全生命周期跨平台手册
• 移动端：跨平台开发、原生性能优化
• 更多领域：CI/CD、测试、产品、低代码、边缘/IoT、区块链、量子计算

知识推送引擎：

• 阶段精准映射：306 个知识文件建立索引，7 个 pipeline 阶段精准推送相关约束
• 渐进式加载：L1 索引（目录级快速匹配）/ L2 详情（文件级内容推送）/ L3 深度引用（段落级精准引用），token 预算控制
• 知识自演化：SQLite 追踪每条知识的使用效果（采纳率、命中率），数据驱动权重优化
• 宿主进入流水线后，Super Dev 会自动检索 knowledge/ 下与当前需求相关的知识文件
• 匹配到的本地标准、场景包和检查清单作为硬约束注入到三文档、Spec 和实现阶段
• 如果已生成 output/knowledge-cache/*-knowledge-bundle.json，宿主会继承其中的本地知识命中结果
• 同时支持联网研究增强，将 Web 搜索结果与本地知识合并