af29b26fe8
Add vehicle-h2-fee-ledger, customer-management, lease and self-operated ledgers, annotation sources, agent skills, and vite annotation runtime support. Update vehicle management, contract templates, and lease contract flows. Co-authored-by: Cursor <cursoragent@cursor.com>
118 lines
6.7 KiB
Markdown
118 lines
6.7 KiB
Markdown
# 需求与设计对齐指南
|
|
|
|
用于新建或明显更新原型、主题、项目文档等资源时，先收敛产品需求，再确认设计方案。对齐贯穿全过程：读取资料、生成规格、计划实施和验收时，只要发现会改变方向、范围、成本或验收标准的问题，都应回到相应阶段继续确认。
|
|
|
|
核心流程：
|
|
|
|
```text
|
|
读取上下文 -> 产品需求对齐 -> 产品需求确认 -> DESIGN.md 候选确认 -> 设计方案对齐 -> 设计决策确认 -> 规格/计划 -> 实施验证
|
|
```
|
|
|
|
## 何时触发
|
|
|
|
- 新建原型页面、主题或项目文档。
|
|
- 明显重构信息架构、核心交互、页面流程或视觉方向。
|
|
- 用户需求模糊，例如只说“生成一个健身 APP”。
|
|
- 存在多种合理功能范围、布局方式、交互路径、内容组织或视觉方案。
|
|
- 用户明确要求先看方向、先出方案、先写规格或先出计划。
|
|
- 资料、主题、现有原型或资源目录之间有冲突，且会改变产出方向。
|
|
|
|
局部文案、样式、素材替换、明确 bug 修复等不改变产品范围、信息架构和视觉骨架的任务，可以跳过正式对齐；但仍要记录采用的假设，并在发现关键缺口时回到对齐流程。
|
|
|
|
## 上下文读取
|
|
|
|
提问前先读取可获得的信息，不把项目里能找到的问题抛给用户。
|
|
|
|
优先级：
|
|
|
|
1. 用户当前消息、附件、截图、链接和已给出的约束。
|
|
2. 当前目录最近的 `AGENTS.md`、`README.md` 和相关 `rules/`。
|
|
3. 关联原型：目录结构、入口文件、必要样式和已有交互。
|
|
4. 资源目录：只做目录级扫描，了解已有原型、主题、文档和资产。
|
|
5. 相关文件：只读取会影响本次判断的文件，不批量展开无关文件。
|
|
|
|
重点看：
|
|
|
|
- `src/prototypes/`：是否已有同类原型、参考页或可复用页面结构。
|
|
- `src/themes/`：是否已有相近主题或设计系统。
|
|
- `src/resources/`：是否已有业务说明、字段、流程资料或素材。
|
|
- 原型内 `assets/`、`canvas-assets/`：是否有用户提供或历史沉淀的素材。
|
|
|
|
## 产品需求对齐
|
|
|
|
产品需求阶段负责回答“做什么”，方向应以收敛为主。通常需要明确：
|
|
|
|
- 目标用户和核心任务。
|
|
- 本次范围、功能清单和不做什么。
|
|
- 页面或资源的核心内容、数据来源和素材来源。
|
|
- 关键状态、核心路径和必要交互。
|
|
- 用户最终如何判断结果可用。
|
|
|
|
只问会影响范围、成本或验收的问题。能从上下文推断的内容直接记为假设继续；如果缺失信息会导致不同功能范围、不同页面结构或不同验收标准，必须先问。
|
|
|
|
## 设计方案对齐
|
|
|
|
设计方案阶段负责回答“怎么表达”。进入视觉、主题或明显 UI 改版前，必须先让用户确认一个 `DESIGN.md` 作为设计基底：
|
|
|
|
1. 如果用户已指定 `DESIGN.md` 或主题，直接采用。
|
|
2. 如果用户未指定，先从项目默认主题、已有同类原型和 `src/themes/` 中整理 3-4 个最匹配候选，让用户选择。
|
|
3. 候选说明只写适用理由、主要风格、取舍和预览链接，不替用户决定最终基底。
|
|
4. 不自行新建 `DESIGN.md`；没有合适候选时，停止并请用户提供设计基底或主题方向。
|
|
|
|
整理候选时优先读取主题 `theme.json`，用 `tags.*`、`display.distributionTags`、`identity.title*/description*` 和 `display.variant` 做检索与候选说明；用 `identity.slug` 和 `assets.designMd.path` 校验目录与 `DESIGN.md` 路径。
|
|
|
|
候选必须提供可打开的主题预览链接。优先使用资源 metadata 里的 `clientUrl` / `previewUrl`；没有时使用 `/themes/<theme-slug>`。同时标出对应 `DESIGN.md` 路径，便于用户核对。
|
|
|
|
`DESIGN.md` 确定后，用户零散提出的颜色、字体、布局、动效、组件形态等需求，都作为基于该设计基底的调整处理，不另起一套视觉系统。
|
|
|
|
新建页面、大面积 UI 改版或模糊需求，设计阶段至少覆盖 5 个设计问题或设计决策变量；局部微调、明确 bug 修复或用户已给出完整设计约束时不受此下限限制。
|
|
|
|
常见设计问题包括：
|
|
|
|
- 首屏目标：主操作、信息概览、品牌表达或引导转化。
|
|
- 信息层级：哪些内容必须突出，哪些可以折叠或延后。
|
|
- 布局模式：看板、列表详情、仪表盘、向导、沉浸页或多步骤流程。
|
|
- 交互路径：高频用户效率优先，还是首次用户理解优先。
|
|
- 数据呈现：真实数据、文档推断、临时示例数据或空状态优先。
|
|
- 视觉语气：严格继承 `DESIGN.md`，还是在其基础上加强某种风格倾向。
|
|
|
|
落地时优先复用所选 `DESIGN.md` 对应的 CSS Variables、tokens 和组件习惯；缺少 token 时贴近所选基底的视觉语言，并在方案或交付说明中写明假设。
|
|
|
|
## 可视化对齐
|
|
|
|
对齐内容保持简洁，不做过度扩写；优先用轻量文本图帮助用户确认关键结构。
|
|
|
|
- 新建页面、大面积 UI 改版或布局不明确时，必须先用 ASCII Wireframe 对齐页面布局，再进入实现。
|
|
- ASCII Wireframe 用于表达区域、层级、主次关系和关键操作位置，不替代最终视觉设计。
|
|
- 流程、结构、关系和图表类内容，可按需使用 ASCII Diagram 辅助沟通；只有会帮助用户更快判断方向时才使用。
|
|
|
|
## 提问规则
|
|
|
|
- 先读上下文，能推断就不问。
|
|
- 默认一次只问一个决策点；同一主题下强相关的 2-3 个参数可以合并为一问。
|
|
- 尽量给出 2-3 个互斥选项，并标出推荐答案。
|
|
- 推荐答案要说明取舍，不只表达偏好。
|
|
- 不为了补齐形式追问已能从上下文判断的问题。
|
|
- 用户回答后继续收敛；如果出现新分支，再追加提问。
|
|
|
|
## 确认与记录
|
|
|
|
进入实现前必须让用户确认产品需求和设计方案。确认产物可以是中文规格文档、执行计划或方案摘要，但至少包含：
|
|
|
|
- 产品需求：目标用户、核心任务、范围、功能清单、内容/数据来源、验收重点。
|
|
- 设计方案：采用的 `DESIGN.md`、整体设计方向、关键设计决策、设计假设。
|
|
- 实施边界：本轮会做什么，不会做什么。
|
|
|
|
确认过的方案或规格需要归档为当时决策快照；未确认的不归档。
|
|
|
|
- 保存位置：原型相关内容保存到 `src/prototypes/<prototype-name>/.spec/`。
|
|
- 文件命名：文件名必须包含日期，建议使用 `YYYY-MM-DD-<topic>.md`。
|
|
- 归档内容：只记录已确认的需求问题、设计问题、用户选择和最终设计决策。
|
|
- 归档性质：只表示当下决策，不要求跟随后续实现继续同步变化。
|
|
|
|
触发过对齐时，本轮交付说明或确认产物中只需补充：
|
|
|
|
- 问题。
|
|
- 用户选择。
|
|
- 最终设计决策。
|