让AI画页面前，先判断是否需要对象关系图

让 AI 做一个预约页面，它很容易先画侧栏、表格和日历。但预约关联哪位医生、哪个地点，用户从哪里进入，改期前需要确认什么，往往比页面长什么样更早决定设计是否成立。

Design Decision Method 提出了一道「对象映射关卡」：涉及对象关系或导航结构的改动，先梳理对象，再做布局；只改文案、样式或局部组件，就跳过。它值得借鉴的地方，是给 AI 一条有明确触发条件的设计规则。

哪些改动需要先梳理对象

这里的对象，是用户能认出来的业务事物，例如预约、医生和地点。对象映射要回答的是：它们怎样关联，哪些属性影响决策，用户能对它们做什么。

方法只检查本次改动，寻找四种信号：

• 用户需要在两个或更多对象类型之间切换。
• 同一个对象可以从当前设计涉及的多个入口到达。
• 顶层导航需要新增或调整。
• 表单或页面会创建、编辑关联其他对象的记录，而且这种关联影响本次结构。

任意一个信号成立，就先产出简短的对象映射，或复用已经验证的映射。

限定「本次改动」很关键。产品原来很复杂，不代表每次改按钮颜色都要重新分析业务。纯文案调整、纯视觉换肤，以及结构不变的组件修复，都可以跳过。

这条规则试图解决的是执行成本：如果每次编辑都触发一套流程，开发者很快就会忽略它。

预约页面为什么不能从表格开始

原文用 example.com 上的小型预约网站举例：新增「My appointments」页面，同时允许用户移动预约时间。

这次改动有两个明显信号。预约关联医生和地点；同一笔预约又能从确认邮件和新页面进入。因此，Agent 应先梳理关系，再决定改期操作放在哪里，以及确认前需要展示哪些信息，包括新日期、医生和地点。

如果直接从表格布局出发，容易先决定列和按钮，再回头补业务关系。先做映射，则是让这些关系约束页面和路由。

映射应贴近用户的理解，而不是照搬数据库表结构。它是一份短工作笔记，也不代表完整执行过 ORCA 方法。原文提到了模板示例行，但提供的内容没有展示该行，无法据此还原具体表格格式。

每次判断还要留下一行记录，使用 Map: produced / reused / skipped，并附上简短原因。这三个状态分别表示新建、复用和跳过。

反过来，如果需求只是把按钮从「Reschedule」改成「Move appointment」，就没有触发信号。记录 Map: skipped，注明只是文案修改，然后直接改标签即可。

我的判断

我认同的是它把「先想业务」变成了一个可检查的条件，而不是要求 Agent 每次都写一大段设计分析。与直接生成页面相比，它更容易提前暴露入口、关联信息和操作位置之间的冲突；与每次都做完整对象建模相比，它的负担也更小。

但这里有两个前提。第一，Agent 得拿到足够的产品上下文，否则未必知道预约还可以从邮件进入。第二，「复用已验证的映射」依赖已有材料可信，原文没有说明验证标准，也没有说明关系变化后怎样维护。

作者明确承认，这套方法是否节省时间尚未测量。

因此，它目前更适合作为设计流程经验，不能据此宣称能提高多少开发效率或减少多少返工。

对象映射是整套方法六步中的第 3 步：建立上下文、选择视觉系统、布局前映射对象、写决策记录、组织各个视图，最后交付并验证，同时如实标注证据。它不能替代后续验证。

能拿来做什么

• 给 AI 下页面需求时，先让它按四种信号判断是否需要对象映射，并写出判断原因，再进入布局和编码。
• 新增预约列表、详情或改期入口时，先明确预约与医生、地点的关系，以及确认前必须展示的信息，再确定页面和路由。
• 修改文案、颜色或结构不变的组件时，允许明确记录跳过，避免小任务被流程拖长。
• 想接入现成流程，可以查阅项目 README 中 Claude Code、Cursor、Gemini CLI 和 Codex 的安装路径；该方法采用开放的 Agent Skills 格式，并使用 MIT 许可证。