让 AI 有章可循：从 Apple 的 iPhone Duo 设计指南说起

2.1 先说要达到什么结果

Apple 开头先说明希望应用带来怎样的体验：打开或合上手机时，用户可以接着完成手上的事。这样，后面的细则就有了共同目标。给 AI 写指南时，先写清结果，也能帮助它判断那些细则没有逐一说明的情况。

目标最好是用户能感受到的。例如：“页面布局变化时，已填写的内容不能丢失，用户可以继续填完表单。”AI 调整页面时就有了保留输入内容的依据，你也有一个明确的结果可以检查。

2.2 先把后面要用的名称说清楚

Apple 先介绍屏幕、铰链和相机，后面的布局要求就能直接使用这些名称。这种顺序建立了共同的用词，也让每条规则有明确的对象。AI 更容易把要求对应到正确的部分，不必每次都猜文中的名称指什么。

自己的指南可以先解释容易混淆的词：“卡片是结果列表中的一个项目；点击卡片后打开的是详情页。”这样，再说“修改卡片标题”就更明确。背景说明只保留会影响工作的内容，关键定义也更容易找到。

2.3 先列出变化，再找共用规则

Apple 列出几种使用姿态后，把它们归到少量布局类型中。这种写法把许多具体情况连到一套可以重复使用的判断方法上。给 AI 一连串单独答案，很容易漏掉下一个新情况；共用规则则能帮助它继续判断。

写规范前，先列出需要应对的变化：标题变长、切换语言、窗口变窄。再写它们共同要满足的要求，例如标题仍能完整阅读，操作仍然可用。用这些情况检查规则，确实需要不同处理时再补充例外。

2.4 先写要求，再解释和举例

Apple 的主要建议都先用加粗短句给出指令，再补充原因、例子和链接。读者能很快找到要做什么，也能就近了解为什么这样做。AI 从长指南中查找某一部分时，也更容易一起读到规则和使用它所需的背景。

例如，先写：“布局变化时，保留已填写的信息。”再解释原因，并给出检查场景：表单填到一半时调整窗口大小。把细节放在要求后面，下次查阅时就不用读完整段解释，才能找到真正要执行的那句话。

2.5 让规则能适应变化

Apple 用内容与可用空间的关系来说明布局要求。屏幕变了，这种关系仍然适用。这种写法值得借鉴：给 AI 写规范时，说明不同情况下都要满足什么要求，能减少它把某一个例子当成所有情况的固定答案。

例如，卡片规范可以写：“卡片宽度随容器调整；文字换行时，按钮仍须完整显示。”AI 可以据此处理不同宽度，你也能用同一条规则检查窄版和宽版的结果。

2.6 把条件和动作写在一起

“只有相机启用时才存在”给后面的要求加上了明确条件。Apple 还区分了系统会自动处理的变化，以及自定义组件需要处理的部分。这些说明让读者先判断是否需要改，再决定怎么改，避免把某种情况下的要求用到所有地方。

自己的规范也可以这样写：“列表为空时，显示原因说明和添加按钮。”先写条件，再写动作。检查时同时看空列表和有内容的列表，就能知道 AI 是否在正确的情况下执行了这条规则。

2.7 告诉 AI 可以用什么工具

Apple 把预期效果和标准组件的链接放在一起，让读者能从设计要求直接找到实现方法。对 AI 来说，明确的组件名称和准确的参考资料，可以减少需要自行选择和猜测的细节。规范也因此更容易落到实际修改上。

例如：“按钮使用团队组件库中已有的尺寸和颜色。如果现有组件不合适，先说明缺少什么，再提出新方案。”这样，AI 知道从哪里开始，也知道现有方法不够用时该怎么办。

2.8 写清楚每条指令管到哪里

Apple 先定义排列视图负责什么，再说明导航应该放在哪里。这一步把职责划清楚，让读者知道每件事应该由哪一部分处理。给 AI 写规范时，类似的边界能帮助它控制修改范围，减少顺手改动相关功能的情况。

例如：“调整卡片的排版，保留原有跳转目标和按钮行为。”前半句说明要做什么，后半句说明改到哪里为止。大家对修改范围有了共同理解，检查结果时也更容易判断。

2.9 把默认做法和例外放在一起

Apple 介绍按钮通常放在哪里时，紧接着就写出例外，再说明两个应用并排等情况。这种顺序让读者先有一个默认做法，再判断什么时候需要调整。AI 只查阅这一部分时，也更容易同时看到适用条件。

例如，表单规范可以写：“字段名称默认放在输入框上方；复选框的名称放在复选框旁边。”把两句放在一起，再让 AI 各检查一个例子，就能减少它把通用规则套错地方的情况。

2.10 要求冲突时，给出取舍顺序

空间不足时，所有按钮都保持可见就做不到了。Apple 给出优先顺序，并允许进一步区分整组和单个按钮的重要程度。这种写法的价值在于：提前告诉读者怎么取舍，避免到了必须删减时才临时决定。

简短总结也需要这样的规则：“保留决定、负责人和截止日期，先压缩背景讨论。”AI 有了删减依据，你也能按事先约定的顺序检查，而不用每次改写后再重新决定什么更重要。

2.11 把笼统目标写成能检查的要求

Apple 在按钮位置的要求后面，接着解释原因，并给出 Mail 的例子。读者能看到：按钮放在哪里，会影响用户判断它操作的是哪一部分。规则因此对应到一个看得见的结果，比单说“界面要清楚”更容易理解和执行。

自己的设计规范也可以这样写：“错误提示放在需要修改的输入框旁边，让用户知道该改哪里。”这句话包含具体做法、目的和检查方式。AI 设计页面时有依据，完成后也知道该检查什么。

2.12 写出做不到时的处理办法

Apple 遇到空间不足的问题时，用页面主要用于浏览还是完成任务来决定优先保留什么，还为放不下的操作指定了统一去处。这样的指令既说明如何选择，也交代了剩余内容怎么办，执行时少一个需要临时猜测的步骤。

例如：“总结超过一页时，把决定留在正文，支撑细节移到附录。”AI 知道怎样缩短，细节也有地方可放。如果这样仍会丢失重要内容，再写明需要把什么问题交给你决定。

2.13 让例子和参考资料解决具体疑问

一张图可以帮助读者看懂位置关系，准确的参考链接则方便查清实现细节，正文里的规则也能保持简洁。Apple 同时使用了这两种方式。我们可以借鉴的是：每份辅助资料都要有明确用途，要么展示结果，要么解答某个具体问题。

给 AI 一张示例页面时，顺便写明要看哪一处；需要使用组件时，链接到对应组件。关键要求仍要写在文字里，并检查工具是否能打开图片或链接。资料真正能被读取和使用，才会起作用。

查看 Apple 的图示

Apple 文件中的参考资料

以下是 Markdown 文件中的辅助链接。开发者参考名称保留原文，方便 AI 编程工具找到准确的资料。

2.14 让规则以后也容易核对和更新

Apple 的更新记录和页脚给指南留下了日期与来源。这些信息帮助读者追溯建议从哪里来，以及是否需要重新核对。反复交给 AI 使用的规范也需要这样的记录，因为产品变了，过去合适的规则可能就要调整。

更新时，记下改了什么、什么时候改，以及依据是什么。例如：“9 月 14 日：错误提示改为放在输入框旁，见已确认的表单示例。”这比只留一个日期更有用，下次设计变化时，你和 AI 都更容易找到需要更新的规则。

已于 2026 年 9 月 14 日核对本篇草稿所用的 Markdown 文件。