专业系统需要的不只是一张风格参考。
一张漂亮截图不足以描述专业系统。Vertical Design MD 把领域、角色、任务、风险与状态写成可供 AI 读取和检查的设计材料。
把经验组织成可组合的领域包。
01
从领域到任务
组织领域、角色与关键流程,再定义交互和视觉,而不是反向套模板。
02
让遗漏可以被发现
将状态、权限与合规要求独立记录,配合结构校验和评估示例。
03
保持可组合与可追溯
领域包使用品牌中性的描述,并保留灵感来源与使用边界。
遗漏权限与状态,不能靠视觉润色补回来。
视觉提示词很容易遗漏权限、异常状态与高风险操作。需要让设计经验成为结构,而不是只成为形容词。
在画界面之前,先把问题写对。
- 01领域与角色
明确谁在何种业务环境中工作。
- 02任务与风险
定义目标、危险操作和不能省略的约束。
- 03状态与权限
把空态、失败态、陈旧数据和权限差异写成材料。
- 04交互与视觉
在已有业务模型上建立布局与表达。
一份领域包,分别约束哪些内容?
| 问题与场景 | 处理方式 | 取舍与依据 |
|---|---|---|
| DOMAIN / FLOWS | 领域、角色与任务路径 | 避免先套视觉模板、再猜业务 |
| STATES / PERMISSIONS | 状态与可操作范围 | 防止只生成正常状态和管理员视角 |
| COMPLIANCE / CONTENT | 风险边界与内容约束 | 把遗漏变成可检查问题,而非审美意见 |
校验器能证明结构完整,不能证明专业判断正确。
实现中的校验器检查必要字段和文件,并构建设计包预览。它可以发现缺页和结构问题,却不能替代专家审核或受控生成对比。项目明确保留 Awesome DESIGN.md 与 Google Stitch 的灵感来源,也不把目录截图包装成已上线医疗或交易软件。
交付与复盘
交付物
项目记录
已有验证记录
项目测试脚本执行结构校验与预览构建;这与“AI 生成质量提升”是不同层次的证据。
设计与代码的连接,可以从更好的问题描述开始。

