ProjectType 模板管理
在管理后台 CRUD ProjectType、关联 ConfigUnit、控制项目模板版本
ProjectType 是项目模板：定义一个项目可以有哪些 DocType（BRD / PRD / URS / 设计系统 …）、绑定哪些实体 Schema、用哪些 Skill 来辅助 AI Copilot 写作。一个 Studio 实例通常会沉淀几个 ProjectType（例如「基本标准」「电商商品」「内部工具」），新建项目时从中挑一个。
1. 项目类型列表
侧栏「管理控制台」进入 /admin/project-types：
每个卡片是一个 ProjectType。点「新建」可以从 0 创建，或者基于已有类型 fork。
「全部类型 / 最近使用」两个 tab 用来快速过滤。
2. 项目类型详情
点卡片进入详情页 /admin/project-types/{id}：
左侧有三个 tab：
| Tab | 管什么 |
|---|---|
| 基本信息 | 名称、描述、文档类型清单（绑定到该项目类型下的 ConfigUnit） |
| 配置单元 | CRUD 这个 ProjectType 下的 ConfigUnit（DocType + Entity + 章节模板） |
| Skills | 上传、管理 AI Skill 包，并把 Skill 关联到具体配置单元 |
右侧是统计仪表板：字段总数 / 文档类型数 / 实体数 / 在用项目数 + 最近动态。
基本配置
「基本信息」页可以改：
- 名称（如「基本标准」）
- 描述（用途和适用场景）
- 文档类型列表（从该 ProjectType 已注册的 ConfigUnit 中勾选启用项 + 排序）
底部「文档类型」区把绑定的 DocType 平铺展示；点卡片直接跳到对应配置单元。「配置单元管理」按钮等价于切到下一个 tab。
为什么 ProjectType 和 ConfigUnit 分两层
ConfigUnit 是可独立演进、可跨 ProjectType 复用的最小单位。同一个 BRD 配置单元既能挂到「基本标准」，也能挂到「电商商品」，独立版本号，独立发布。这一层抽象让你改 BRD 不会影响 PRD、升 BRD 不会强制升所有 ProjectType。
3. 配置单元（ConfigUnit）
切到「配置单元」tab：
每个 ConfigUnit 卡片显示：
- 类型标签：
文档配置/标准规范 - 绑定状态：实体已绑定 ✓ / 文档已绑定 ✓
- 版本号：
v2/v5，每次发布递增
页面顶部支持搜索 + 类型过滤（全部 / 文档配置 / 标准规范）。底部状态栏显示「N 个配置单元 / X 文档配置 / Y 标准规范」。
配置单元详情
点 BRD 卡片进入：
这是 Studio 后台最重要的一页，里面分三段：
① 文档类型信息 名称（如「业务需求文档 BRD」）+ 系统提示词（System Prompt，决定 AI Copilot 在这个 DocType 下的行为）。 左下角「文档类型提示词」展开可看完整提示词，是个很长的领域工程产物（角色定义、写作准则、章节字段映射、Skill 调用流程……）。
② Skills 这个 ConfigUnit 启用的 Skill 列表（如 BRD 用了 20 个），每个 Skill 在写作流程的特定阶段被加载。详见下方 §5 Skills。
③ 编排流程（Orchestration） DocType 的写作流是分阶段的：
- brainstorming（头脑风暴 / 需求澄清）
- 骨架生成（写章节框架）
- 内容生成（按章节填充内容）
- 润色与一致性自检
每个阶段绑定一组 Skills + 一个 system prompt 片段。运行时 Copilot 根据当前阶段加载对应的能力包。「添加编排节点」可以增加自定义阶段。
右侧主视图分两栏：
- 章节预览：从 Definition Set 推导出的目录结构（如 BRD 的 1～5 章）
- 节点详情：选中某个章节后看字段配置、绑定的实体路径
顶部按钮：
| 按钮 | 作用 |
|---|---|
| 保存草稿 | 保存改动但不发布给项目 |
| 发布 v3 | 发布新版本，存量项目不受影响（按版本号绑定） |
| 测试 | 在沙箱环境跑一遍，验证 Skill / 提示词改动 |
| 系统提示词 | 编辑文档类型级 system prompt |
| 导出 / 导入 JSON | 跨实例迁移 ConfigUnit |
4. 实体 vs 文档
每个 ConfigUnit 关联两类对象：
- 实体（Entity）：结构化数据 schema，定义字段名、类型、约束（详见 DocType 与 Entity）
- 文档（Document Definition）：章节目录 + 字段映射（哪个章节渲染哪个实体字段）
详情页顶部「实体 / 文档」按钮在两个视图间切换。
5. Skills：让 AI Copilot 学会你团队的写作方法论
「Skills」tab 是 ProjectType 的能力市场——你在这里上传、管理一组可被 AI Copilot 加载的技能包，然后在某个配置单元里「关联」它们，业务用户在工作台用对应文档类型时，Copilot 就能调用这些技能。
为什么需要 Skill
通用 LLM 不知道你团队是怎么写 BRD 的——是先做头脑风暴还是直接写骨架？涉众分析有没有特定模板？流程图用什么风格？这些写作方法论沉淀进 Skill 之后，Copilot 才能"按你团队的路数"写文档，而不是按它训练数据里的通用方式。
举几个真实场景里的 Skill 例子：
| Skill 名 | 干什么 | 在哪个阶段触发 |
|---|---|---|
| brainstorming | 通过 A/B/C 选项题帮用户澄清需求范围、通知机制、审批规则 | BRD brainstorming 阶段 |
| brd-write-pipeline | 写入全链路：缺口扫描 + 校验 + 质量评估 + 写回自检 | BRD 骨架 / 内容生成 |
| brd-pattern | 模式匹配——命中行业模式后给追问加经验提示 | BRD 每轮对话 |
| brd-research | 知识库检索 + 联网搜索行业资料 | 用户要参考案例 / 陌生行业时 |
| deep-thinking-engine | 跨章节一致性自检（痛点是否都有目标？角色是否都在流程图里？） | 一致性自检阶段 |
一份 BRD 配置单元通常会绑 15~20 个 Skill。
上传 Skill
「Skills」tab 顶部「上传 Skill」按钮：
- 格式：一个压缩包，里面是
SKILL.md（说明 + 提示词片段）+ 可选的 Python / JS 脚本 - 元信息：上传后填名称、描述、标签（用于后续关联时检索）
- 版本号：每次上传新版自动递增；旧版项目不受影响
上传完成的 Skill 进入这个 ProjectType 的「Skill 库」，可以被该 ProjectType 下任意配置单元关联。
关联 Skill 到配置单元
进入某个配置单元（比如 BRD）的详情页，点中间的 「技能 N」 入口：
- 从 Skill 库里勾选要绑的 Skill
- 给每个 Skill 配触发条件（哪个编排阶段加载、哪类用户输入触发）
- 调整加载顺序（前置 Skill 的输出会被后置 Skill 读到）
保存后，业务用户用这个 DocType 写文档时，Copilot 就会按编排自动加载这些 Skill。
为什么把 Skill 挂到配置单元而不是 ProjectType
不同文档类型需要的方法论完全不一样——BRD 偏需求澄清，PRD 偏功能拆解，技术设计偏架构权衡。把 Skill 挂到具体配置单元（=具体 DocType）而不是整个 ProjectType，能让同一个 ProjectType 里不同 DocType 用各自适配的能力包。
Skill 的协作面
- 管理员：上传、迭代 Skill；调整 Skill ↔ 配置单元的关联
- 业务用户：完全无感——Copilot 自动加载，他们只看到 AI 的对话变得更"懂行"了
- Skill 作者（解决方案架构师 / 资深业务）：把团队的写作方法论沉淀成 Skill 包，让全团队的 AI 协作都受益
详细的 Skill 编写规范见 DocType 与 Entity 设计。
6. 版本治理
ConfigUnit 用语义版本号：每次「发布」自动 vN → vN+1。
- 已存在的项目绑定到具体版本号——升级 ConfigUnit 不会改动它们
- 新建项目时默认用最新版
- 想强制全部升级：在「在用项目」里批量切版（管理员特权操作）
发布前先在沙箱测一遍
ConfigUnit 改坏（提示词漏字段、Skill 引用错路径）后，新项目创建会失败，已绑旧版的项目不受影响。所以先用「测试」按钮跑一遍 brainstorming → 内容生成的全流程，再正式发布。
7. 推荐的开局
刚开始用 Studio 想跑起来：
- 直接用「基本标准」——它已经把 BRD / PRD / URS / 设计系统四个文档类型装好了，每个文档类型都关联了对应 Skill 包
- 业务团队用这个模板新建项目即可，开箱可用
- 等积累了实际写作反馈，再 fork 一份自定义版本：改 BRD 章节、加自家 Skill、调整阶段编排
下一步
- DocType 与 Entity —— 文档章节结构和数据字段怎么定
- 配置单元 DSL —— 章节结构、字段映射的 DSL 语法
- 发布流程 —— 草稿 → 测试 → 发布的细节