103 lines
7.3 KiB
Markdown
103 lines
7.3 KiB
Markdown
# 临时-产品形态阶段化重设计计划
|
||
|
||
- 版本：v1
|
||
- 更新日期：2026-05-22
|
||
- 目标读者：产品 / 架构 / 前端 / 后端 / 文档维护者
|
||
- 文档性质：本轮设计变更的流程约束和阶段管理文档，不替代正式产品、架构、流程或实现文档。
|
||
|
||
## 0. 本次讨论的流程约束
|
||
|
||
本轮目标是按阶段、按顺序重新设计 Muse 的产品形态和后续设计文档，不做一次性全量缝合。
|
||
|
||
必须遵守以下要求：
|
||
|
||
1. 当前阶段只修改当前阶段文档，不跨阶段顺手修改后续文档。
|
||
2. 讨论设计时，以已经修改并确认过的文档为准；后面阶段文档只能作为参考，不能反向压当前阶段。
|
||
3. 每进入下一阶段，必须承接前面阶段已经确定的产品形态、边界、术语、非目标和硬约束，不能遗漏前面阶段设计。
|
||
4. 如果后续参考文档和前面已确认设计冲突，先记录冲突并提出决策问题，不擅自缝合。
|
||
5. 每个阶段结束时，必须形成可追溯的阶段结论，再进入下一个阶段。
|
||
6. 本计划文档负责管理阶段、约束、决策记录和冲突记录；正式设计内容仍落在对应 owner 文档中。
|
||
|
||
## 1. 工作目标
|
||
|
||
通过分阶段设计，重新收口 Muse 的产品形态、功能边界、用户旅程、流程、架构和后续实现文档，使整套设计文档从上到下保持一致。
|
||
|
||
本轮变更的核心不是局部润色，而是先确定产品形态，再让后续文档按顺序继承，不允许后续文档各自维护一套旧口径。
|
||
|
||
## 2. 阶段顺序
|
||
|
||
| 阶段 | 目标文档 | 阶段目标 | 状态 |
|
||
|---|---|---|---|
|
||
| 阶段 0 | `design-docs/临时-产品形态阶段化重设计计划.md` | 建立本轮设计变更流程约束、阶段顺序和记录方式 | 已完成 |
|
||
| 阶段 1 | `design-docs/产品-01-产品定位与核心价值.md` | 确认产品定位、产品空间、目标用户、核心价值、非目标和成功指标 | 已完成 |
|
||
| 阶段 2 | `design-docs/产品-02-核心功能与交互边界.md` | 承接产品形态，重写功能边界、角色边界、交互规则和非谈判项 | 进行中 |
|
||
| 阶段 3 | `design-docs/产品-03-用户旅程与操作流程.md` | 承接产品空间和功能边界，重写管理员、普通用户、智能体、市场等旅程 | 待开始 |
|
||
| 阶段 4 | `design-docs/流程-01-产品操作流程(用户视角).md` / `design-docs/流程-02-系统处理流程(系统视角).md` | 把已确认产品旅程拆成用户视角步骤和系统视角处理链路 | 待开始 |
|
||
| 阶段 5 | `design-docs/架构-01-系统全貌与边界上下文.md` / `design-docs/架构-02-核心数据结构与双轨模型.md` | 承接产品与流程，调整有界上下文、核心模型和双轨约束 | 待开始 |
|
||
| 阶段 6 | `design-docs/专题-*` | 按需要调整 AI 编排、质量门控、竞品取舍、正文建议接受等专题合同 | 待开始 |
|
||
| 阶段 7 | `design-docs/前端-*` / `design-docs/后端-*` | 承接产品、流程、架构结论，更新工程结构、Schema、API 和实现约束 | 待开始 |
|
||
| 阶段 8 | `design-docs/00-文档大纲.md` / `design-docs/内容映射表.md` | 最后统一索引、文档 owner 和内容映射，清理过期引用 | 待开始 |
|
||
|
||
## 3. 阶段门禁
|
||
|
||
每个阶段进入前，需要确认：
|
||
|
||
1. 上一阶段文档已经完成修改并被确认。
|
||
2. 本阶段要修改的文档 owner 明确。
|
||
3. 本阶段只处理当前 owner 文档的职责，不抢后续文档的精确归属。
|
||
4. 参考后续文档时，只抽取冲突和约束，不直接按后续文档反改当前阶段。
|
||
|
||
每个阶段结束前，需要确认：
|
||
|
||
1. 当前文档是否完整承接了前面阶段的已确认结论。
|
||
2. 是否留下与后续阶段有关但暂不修改的待承接事项。
|
||
3. 是否存在需要用户决策的冲突项。
|
||
4. 是否需要把阶段结论补充到本计划文档的决策记录中。
|
||
|
||
## 4. 设计讨论规则
|
||
|
||
讨论设计时，所有结论按以下优先级判断：
|
||
|
||
1. 已确认并已修改的前序阶段文档。
|
||
2. 当前阶段正在讨论和准备修改的目标文档。
|
||
3. 后续阶段文档中的参考信息。
|
||
4. 代码实现、旧文档、历史计划和外部竞品信息。
|
||
|
||
如果不同来源发生冲突：
|
||
|
||
- 前序阶段已确认内容优先。
|
||
- 后续阶段文档只能登记为待承接或待修正，不能反向否定前序阶段。
|
||
- 如果冲突会改变产品形态、权限边界、资产边界或数据模型，必须先提问确认。
|
||
|
||
## 5. 冲突记录
|
||
|
||
| 编号 | 发现阶段 | 冲突来源 | 冲突描述 | 处理方式 | 状态 |
|
||
|---|---|---|---|---|---|
|
||
| C-001 | 阶段 1 准备 | 新版 `产品-01` 与旧 `产品-02/03` | 新版引入智能体工作台、知识库工作台和市场空间，旧后续文档尚未承接 | 作为后续阶段 2 和阶段 3 的必承接事项，不在阶段 1 跨文档修改 | 待承接 |
|
||
|
||
## 6. 决策记录
|
||
|
||
| 编号 | 日期 | 阶段 | 决策 | 影响范围 |
|
||
|---|---|---|---|---|
|
||
| D-001 | 2026-05-22 | 阶段 0 | 本轮设计变更采用按阶段、按顺序推进；当前阶段只改当前阶段文档；后续文档只作为参考 | 全部设计文档 |
|
||
| D-002 | 2026-05-22 | 阶段 1 | `产品-01` 锁定六个产品空间：管理员控制台、用户工作区、智能体工作台、知识库工作台、市场、个人中心；知识库作为可管理、可复用、可上架市场的一级资产 | `产品-01` 已修改；后续 `产品-02/03`、流程、架构、前后端文档必须按阶段承接 |
|
||
| D-003 | 2026-05-22 | 阶段 1 | 管理员元数据治理必须保留；大量 AI 能力是系统预编排功能链路，用户只能替换开放槽位中的子智能体；输入输出合规、拆分切块、入 RAG、语义安全围栏、静态检查等系统保护节点不可替换 | `产品-01` 已修改；阶段 2 需要在 `产品-02` 中细化可替换槽位和不可替换系统节点 |
|
||
| D-004 | 2026-05-22 | 阶段 1 | 子代理评审后补强 `产品-01` 的 P0/P1 边界：主产品楔子与六空间优先级、市场授权不等于所有权转移、第三方市场资产默认不可信、正文保存与知识入库分层、替换槽位合同、管理员治理分权、信任与合规指标 | `产品-01` 已修改；阶段 2 起必须继续承接这些边界，不能把后续功能设计成越权、自动污染作品事实或单点超级权限 |
|
||
|
||
## 7. 阶段交付格式
|
||
|
||
每个阶段交付时，默认输出以下内容：
|
||
|
||
1. 结论：当前阶段文档是否可以进入修改或是否已经收口。
|
||
2. 本阶段修改范围：明确只改哪些文件。
|
||
3. 已承接的前序结论：列出来自前序阶段的关键约束。
|
||
4. 暂不处理的后续事项：列出需要后续阶段承接的内容。
|
||
5. 冲突和待确认问题：只保留会影响决策的问题。
|
||
6. 验证状态：说明已检查哪些引用、术语、边界或文档 owner。
|
||
|
||
## 8. 当前下一步
|
||
|
||
当前处于阶段 2 进行中：`产品-01-产品定位与核心价值.md` 已确认，开始更新 `产品-02-核心功能与交互边界.md`。
|
||
|
||
阶段 2 必须承接 `产品-01` 已确认的六个产品空间、管理员元数据治理、三类知识库、三类市场资产、系统功能编排、可替换子智能体槽位、不可替换系统保护节点、用户主权和市场资产不污染作品事实等约束。阶段 2 不修改 `产品-03`、流程、架构、专题、前端或后端文档。
|