Claude Design 写了 DESIGN.md，为什么设计还是不对？
Claude Design wrote DESIGN.md — why is the design still off?最近做产品时，我让 Claude Design 整理了一份 DESIGN.md。
里面有颜色、字体、间距、圆角、组件和响应式规则，也写了产品应该“简洁、专业、现代”。
看起来没有明显错误。
但我总觉得少了什么。
继续做了几个页面后，我才发现：
它解释了界面应该长什么样，却没有解释产品为什么应该这样设计。
DESIGN.md 和 Design System 不是一回事
简单来说：
Design System 是产品真实运行的设计体系。DESIGN.md 是帮助人和 AI 理解、使用和维护这套体系的说明与约束。
Design System 更接近真实资产：
- design tokens
- 组件库
- Figma library
- 代码实现
- 组件状态和使用规则
DESIGN.md 则应该解释：
- 产品最重要的体验目标是什么
- 信息应该怎样组织
- 关键流程应该遵守什么原则
- AI 输出怎样被展示和审核
- 哪些设计决策不能由 Agent 随意改变
它可以描述 Design System，但不等于 Design System。
很多 DESIGN.md，只覆盖了设计的最后两层
AI 很容易生成这样的规则：
Use an 8px spacing system. Use rounded cards. Keep the interface clean and modern. Buttons have primary and secondary variants.
这些规则能让界面更统一，但不能保证产品更合理。
如果把设计粗略拆开，大概是：
产品目标与用户任务
↓
信息架构与内容层级
↓
任务流程与页面关系
↓
交互行为与系统状态
↓
视觉语言与组件
↓
一致性与实现约束
很多 DESIGN.md 只写了最后两层。
但当一个页面“怎么看都不对”时，问题往往出在更上面。
这些梳理不只是给 Agent
很多时候，只有自己先想清楚：
- 产品到底在帮助用户完成什么
- 哪些信息最重要
- 信息之间是什么关系
- 哪些判断可以交给 AI
- 哪些控制权必须留给用户
才有可能有效地指导 Agent。
Agent 可以帮助拆问题、发现遗漏、提出不同方案。
但它不能替产品负责人决定：
这个产品真正应该强调什么。
如果自己也不清楚，再完整的 DESIGN.md，也可能只是让 Agent 更有条理地猜。
设计不好时，我会从上往下检查
1. 产品任务
先问：
- 用户来到这个页面要完成什么
- 最重要的判断是什么
- 最重要的动作是什么
- 页面是在展示信息，还是帮助用户做决定
例如，岗位匹配报告的目标不应该只是：
展示一份 AI 生成的分析。
而应该是：
帮助用户判断这个岗位是否值得投入，以及应该怎样定位自己。
前者容易做成一篇很长的报告。
后者需要突出结论、证据、风险和下一步行动。
2. 信息架构与层级
检查：
- 最重要的信息是否最先出现
- 事实、推论和建议是否混在一起
- 哪些内容应该并列，哪些应该从属
- 是否因为每项都重要，最后没有重点
- 每个卡片是否真的代表一个独立对象
AI 很喜欢把每个 section 都放进卡片。
最后页面很整齐，却没有清楚的主次。
卡片只是容器，不会自动产生信息层级。
3. 流程
信息架构解决“页面里放什么”。
流程解决“用户怎样完成任务”。
检查：
- 用户从哪里进入
- 下一步去哪里
- 是否要重复输入或确认
- AI 做什么，用户审核什么
- 异常情况时流程还能不能继续
- 单个页面放进完整流程后，是否仍有必要
有时页面单独看没问题，但放进整个任务里就显得重复或顺序错误。
4. 交互和状态
AI 产品不能只设计“成功生成结果”的截图。
还需要考虑：
- 生成前
- 生成中
- 生成失败
- 数据不足
- 用户修改
- 用户拒绝
- 重新生成
- 结果对比
- 保存和撤销
这些状态没有设计，产品通常只能用于展示，不能真正用于工作。
5. 视觉层级
前面的结构成立后，再检查：
- 字号和字重是否表达正确层级
- 留白是否帮助理解
- 对比度是否突出真正重要的信息
- 是否有太多边框、背景和容器
- 每个模块是否都在争夺注意力
- 信息密度是否符合任务场景
视觉设计不是给混乱的结构做美容。
它应该把已经想清楚的关系表达出来。
6. 系统与实现
最后检查：
- 是否复用了已有 tokens 和组件
- 相同模式在不同页面是否一致
- 是否为了修一个页面修改全局样式
- 是否为一次性差异创建共享组件
- Figma、代码和文档是否各说各话
如果前面的产品判断没有成立，系统做得越统一，只会让错误复制得越稳定。
一份好的 DESIGN.md，至少需要四类内容
产品体验原则
不要只写：
Clean, modern and intuitive.
更有用的是：
- 帮助用户做判断，而不只是展示 AI 输出
- 区分事实、推论和建议
- 重要结论必须能够查看依据
- AI 生成的修改必须可审核
- 不把不确定判断包装成精确答案
这些规则会真正改变设计结果。
产品特有的模式
例如 AI 产品常见的：
- recommendation + evidence
- AI output + human review
- original content + suggested changes
- confidence / uncertainty
- loading / failure / retry / approval
这些模式通常比按钮有几个尺寸更重要。
视觉和组件规则
包括：
- tokens
- typography
- layout
- spacing
- responsive behavior
- component usage
- loading、error、disabled 等状态
它们仍然需要，但不是全部。
Agent 和开发边界
例如：
- 优先复用已有组件
- 不直接写 raw hex value
- 不为一次性样式创建共享组件
- 不为修复局部问题修改全局规则
- 不自行发明业务概念
- 不在没有依据时改变信息层级
- 不把每个 section 都包装成 card
coding agent 的问题经常不是不会做。
而是它会在局部做出看似合理的决定，让整个产品逐渐漂移。
DESIGN.md 不是越长越好
判断一条规则是否值得留下，可以问：
它会不会帮助设计者、开发者或 Agent 做出不同的决定？
如果不会，它可能只是装饰。
如果无法执行或检查，它也很容易变成口号。
早期产品不需要一开始就建设一套庞大的 Design System。
更需要的是一套范围有限、但真正被执行的规则。
后来我才明白，我觉得那份 DESIGN.md 少了什么，并不是因为少写了几个组件。
它少的是更上层的设计判断：
用户在完成什么任务，信息应该怎样组织，AI 应该做什么，人又应该保留什么控制权。
所以，当 AI 做出的设计不好时，先不要急着要求它：
Make it cleaner. Make it more modern. Use better spacing.
先往前退几步。
不是为了写一份更复杂的 Prompt，而是先确认：
自己是否真的想清楚了，以及哪些设计判断不能交给 Agent 猜。